Cerveau secondaire : transformer les transcriptions de réunions en un graphique de connaissances consultable

The Problem

Nearly every organization depends on meetings to move work forward — planning discussions, calls with clients, sprint retrospectives, workshops for discovery. Each of these generates a steady flow of decisions, action items, risks, and commitments. And almost without exception, that information simply evaporates afterward.

The transcript gets dropped into a shared drive somewhere. Action items sit in someone's notebook for a while, then fade from memory. Weeks later, someone asks what was actually decided about a particular approach, and nobody can give a clear answer.

This isn't really a storage issue — the data exists somewhere. The real problem is that meeting content is unstructured, scattered across tools, and effectively invisible to any kind of search.

Il fallait un système capable d’ingérer des transcriptions à grande échelle, d’en extraire automatiquement des connaissances structurées et de permettre aux utilisateurs de consulter ces connaissances en langue anglaise simple — tout en créant une carte dynamique des relations qui s’enrichit à chaque réunion ajoutée. Ce système a été nommé Second Brain.

La vision : un graphe de connaissances dynamique par projet

L’idée de base est simple. Chaque fois qu’une transcription de réunion est téléchargée, le système la analyse pour déterminer qui a parlé de quel projet, quelles décisions ont été prises, quels risques sont apparus et qui est responsable de quelle action de suivi. Tout cela est enregistré dans Azure Cosmos DB. À partir de là, vous pouvez poser une question en langage naturel et recevoir une réponse présentée sous forme de listes avec des références.

Au fur et à mesure que de plus en plus de transcriptions s’accumulent, un graphe de connaissances se forme naturellement — un réseau en évolution qui relie des personnes, des décisions, des actions et des risques au sein de chaque session enregistrée.

L’interface de solution

Le système propose une interface utilisateur interactive permettant aux utilisateurs de télécharger des transcriptions, d’examiner les entités extraites, de poser des questions en langage naturel et d’explorer visuellement le graphe de connaissances généré.

Un aperçu plus détaillé des composants

1. Extract_Entities_Tool — Extraction parallélisée

Cet outil s’occupe de la tâche principale. À partir d’une chaîne de texte brute, il divise la transcription en segments regroupés par paragraphe, effectue l’extraction d’entités sur chaque segment en même temps à l’aide d’un ThreadPoolExecutor, puis fusionne les résultats en évaluant chaque valeur distincte en fonction du degré de confiance de l’extraction et de sa fréquence d’apparition.

Sept types d’entités sont définis selon un format séparé par des pipes, que le modèle de langage peut suivre de manière cohérente.

Ainsi, le modèle génère des résultats tels que "Architecture de l’évaluation | Responsable : Archana | Échéance : Prochain sprint" — une chaîne de caractères que l’application peut ensuite parser en dictionnaires structurés {task, owner, due}, prêts à être affichés en détail et à servir à créer des liens dans le graphe.

Découverte autonome des termes de domaine

L’une des décisions de conception importantes a été d’éliminer complètement le paramètre d’entrée domain_context et de laisser plutôt le modèle découvrir lui-même le vocabulaire spécifique au domaine. Chaque demande utilisée pour l’extraction par blocs comprend une section dédiée demandant au modèle d’identifier les termes de domaine, les abréviations et les noms de systèmes qu’il rencontre dans le texte.

2. Text2SQL_CosmosDB_Tool — Rappel en langage naturel

Cet élément accepte une question en langue anglaise simple ainsi qu’un indice décrivant le schéma de Cosmos, le convertit en une requête Cosmos SQL, l’exécute, puis produit une réponse citée à partir des résultats. La partie délicate réside dans le fait que le dialecte SQL NoSQL de Cosmos DB ne permet pas d’appeler directement CONTAINS() sur des champs de type tableau. La solution consiste à fournir à l’outil un indice de schéma explicite décrivant comment interroger ces tableaux.

3. Cosmos DB en tant que cerveau principal

Cette base de données occupe le cœur de tout le système. Elle ne fonctionne ni comme cache ni comme stockage de journaux — Cosmos DB est en réalité le deuxième cerveau, la couche de mémoire persistante où chaque élément de connaissance extrait est stocké, accumulé et rendable consultable.

Chaque document de extraction de réunions stocke chaque entité deux fois : une fois sous forme d’array plat de chaînes de caractères, ce qui permet des requêtes basées sur SQL, et une fois sous forme d’array d’objets structurés, ce qui facilite l’affichage détaillé dans l’interface utilisateur ainsi que la génération des arêtes du graphe. Cette duplication entraîne une petite augmentation de l’espace de stockage par document, mais elle évite la nécessité d’analyser les données au niveau de l’application une fois qu’elles sont revenues de la base de données.

L’analogie avec le cerveau — Deux modes de mémoire

La mémoire humaine fonctionne en deux modes distincts : la mémoire épisodique, qui conserve ce qui s’est réellement produit lors d’un événement, et la mémoire sémantique, qui enregistre des faits généraux et des définitions — ce que signifie une abréviation, qui est une personne donnée. Le modèle de données Cosmos a été conçu délibérément pour refléter cette séparation, en stockant les données épisodiques spécifiques aux réunions séparément du glossaire sémantique qui accumule des informations sur les personnes, les termes et les systèmes.

Décisions techniques clés

Plusieurs choix délibérés ont influencé le fonctionnement du système, allant de la décision d’éliminer la configuration manuelle des domaines au profit de la découverte automatique, en passant par le stockage redondant des entités pour répondre aux besoins tant SQL qu’UI, jusqu’à la limitation du rôle du LLM à l’extraction d’informations et à la génération de requêtes, sans lui permettre de gérer le formatage ou les règles métier.

Leçons apprises

1. Le comportement de réexécution de Streamlit exige une gestion délibérée de l’état. Chaque clic sur un bouton fait exécuter à nouveau tout le script depuis le début. Tout ce qui doit persister entre les interactions doit être enregistré dans st.session_state avant que le bouton déclenchant la réexécution ne soit affiché, et non après.
2. Le dialecte SQL de Cosmos DB n’est pas du ANSI SQL standard. La fonction CONTAINS() ne fonctionne que sur des chaînes de caractères, pas sur des tableaux ; par conséquent, le modèle nécessite des indications explicites dans les indications de schéma — y compris au moins un exemple de la manière incorrecte d’écrire la requête.

On ne peut pas compter sur les modèles de langage pour suivre toujours les instructions relatives au format de sortie. Même avec des instructions de synthèse claires, le modèle renvoie parfois uniquement une courte phrase d’introduction au lieu de la réponse complète. Pour cette raison, un mécanisme de secours déterministe qui construit directement la réponse à partir des données brutes obtenues n’est pas une simple touche finale optionnelle — c’est un filet de sécurité indispensable.

Les outils doivent avoir des responsabilités étroites et bien définies. Il est tentant d’intégrer directement dans un outil de la logique de mise en forme, des règles métier ou des connaissances sectorielles, mais cette tentation doit être résistée — un outil ne devrait être chargé que d’une seule tâche.

Pour afficher des graphiques Pyvis à l’intérieur de Streamlit, il est nécessaire d’écrire dans un fichier temporaire plutôt que de passer une chaîne en mémoire. Utilisez tempfile.NamedTemporaryFile et n’oubliez pas de le nettoyer par la suite. Il convient également de noter que st.components.v1.html sera déprécié à partir du 1er juin 2026, il faudra donc utiliser st.iframe à l’avenir.

La principale idée de conception

La véritable intelligence d’un système comme celui-ci ne provient pas du modèle de langage — elle provient du stockage en mémoire qui le soutient.

Le modèle lui-même ne dispose d’aucune mémoire ; il est par nature sans état. Il lit un fragment de transcription et génère un ensemble d’entités. Il lit une question et génère une requête SQL. Rien n’est conservé entre les appels — chaque invocation commence complètement à zéro.

Cosmos DB est l’endroit où réside la mémoire réelle. Dès qu’une information est enregistrée dans le cerveau, ce qui n’était qu’un extrait temporaire du modèle se transforme en un enregistrement durable, structuré et recherchable. Le glossaire des termes de domaine continue de s’élargir. Le réseau de relations se développe. Les connaissances s’accumulent avec le temps.

Tout le système fonctionne grâce à des infrastructures déjà en place — Azure VMs, Azure Functions, Azure Cosmos DB et Azure OpenAI — coordonnées via le AGF Hub. Aucun nouveau service n’a été introduit, et aucun pipeline complexe n’était nécessaire. Ce qui a permis au système de fonctionner, c’est un stockage de mémoire soigneusement conçu, des limites claires quant aux responsabilités de chaque outil, ainsi qu’un modèle linguistique dont la fonction est simplement de lire les réunions afin que les gens n’aient pas à le faire eux-mêmes.

Lectures complémentaires

• Pourquoi le coût de l’IA agentiel explose : un modèle de coûts basé sur l’architecture — Explique pourquoi les coûts des agents LLM doivent être mesurés par tâche accomplie et non par appel, et présente des leviers architecturaux tels que le routage des modèles, les budgets de contexte et le cache pour contrôler les dépenses.
• Comprendre les agents IA : objectifs, outils, mémoire et la boucle de l’agent — Une explication adaptée aux débutants sur les différences entre les agents IA et les chatbots, abordant les composants clés, la boucle de décision, les niveaux d’autonomie et les cas d’usage concrets.

RAG vs Agentic RAG vs Graph RAG : Comment choisir la bonne architecture de récupération — Découvrez pourquoi le RAG naïf échoue face aux questions à plusieurs étapes et aux données structurées, ainsi comment les boucles agentiques et la récupération basée sur des graphes compensent respectivement ces faiblesses.

Réduire les hallucinations dans un pipeline de chatbot RAG médical — Apprenez comment la recherche hybride, le réclassement et une politique stricte d’interdiction de fabriquer des informations permettent de créer un chatbot RAG pour la recherche médicale plus fiable.

Retrieval-Augmented Generation expliquée : comment corriger les écarts de connaissances des LLM — Découvrez pourquoi les LLM génèrent des informations erronées ou deviennent obsolètes, puis suivez pas à pas comment la technologie RAG récupère des données, les divise en segments, les incorpore et enrichit les prompts pour y remédier.