Cerebro Secundario: Convierte las transcripciones de reuniones en un grafo de conocimiento 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.

Lo que se necesitaba era un sistema capaz de procesar transcripciones a gran escala, extraer automáticamente conocimiento estructurado y permitir que las personas consultaran ese conocimiento usando un inglés sencillo, todo ello mientras se creaba un mapa dinámico de relaciones que se enriquecía con cada reunión añadida. A este sistema se le dio el nombre de Second Brain.

La visión: un grafo de conocimiento dinámico por proyecto

La idea subyacente es sencilla. Cada vez que se carga una transcripción de reunión, el sistema la analiza para determinar quién habló sobre qué proyecto, qué decisiones se tomaron, qué riesgos surgieron y quién es responsable de cada acción posterior. Todo esto se almacena en Azure Cosmos DB. A partir de allí, se puede hacer una pregunta en lenguaje natural y recibir una respuesta con viñetas y referencias.

A medida que se acumulan más transcripciones, un gráfico de conocimiento toma forma de manera natural: una red en constante evolución que conecta a personas, decisiones, acciones y riesgos en cada sesión grabada.

La interfaz de la solución

El sistema ofrece una UI interactiva que permite a los usuarios cargar transcripciones, explorar las entidades extraídas, hacer preguntas en lenguaje natural y visualizar el gráfico de conocimiento resultante.

Un vistazo más detallado a los componentes

1. Extract_Entities_Tool — Extracción paralelizada

Esta herramienta se encarga de la labor más compleja. Dada una cadena de texto en bruto, divide la transcripción en fragmentos agrupados por párrafos, realiza la extracción de entidades en cada fragmento de forma concurrente utilizando un ThreadPoolExecutor, y luego fusiona los resultados comparando cada valor distinto según el grado de confianza en su extracción y la frecuencia con que aparece.

Se definen siete tipos de entidades utilizando un formato delimitado por barras que el modelo de lenguaje puede seguir de manera consistente.

Como resultado, el modelo genera salidas como "Arquitectura de revisión | Propietario: Archana | Fecha límite: Próximo sprint" — una cadena que la aplicación puede luego analizar para convertirla en diccionarios estructurados {task, owner, due}, listos para su renderizado detallado y para crear conexiones en el grafo.

Detección autónoma de términos del dominio

Una decisión importante en el diseño fue eliminar por completo el parámetro de entrada domain_context y, en su lugar, permitir que el modelo descubra por sí mismo el vocabulario específico del dominio. Cada prompt utilizado para la extracción de fragmentos incluye una sección dedicada que le pide al modelo que identifique los términos del dominio, abreviaturas y nombres de sistemas que encuentra en el texto.

2. Text2SQL_CosmosDB_Tool — Recuperación en lenguaje natural

CONTAINS() en campos de array. La solución fue proporcionarle a la herramienta una pista de esquema explícita que describa cómo se deben consultar los arrays en su lugar.

3. Cosmos DB como el propio cerebro

Esta base de datos se encuentra en el núcleo de todo el sistema. No funciona como caché ni como almacén de registros; Cosmos DB es, en efecto, el Segundo Cerebro, la capa de memoria persistente donde se almacena, acumula y hace consultable cada fragmento de conocimiento extraído.

Cada documento de extracción de reuniones almacena cada entidad dos veces: una vez como un array plano de cadenas, lo que permite consultas basadas en SQL, y otra vez como un array de objetos estructurados, lo que facilita la renderización detallada en la interfaz de usuario y la generación de aristas en el grafo. Esta duplicación añade una cantidad modesta de almacenamiento adicional por documento, pero evita la necesidad de analizar cualquier dato en la capa de aplicación una vez que los datos regresan desde la base de datos.

La analogía con el cerebro: dos modos de memoria

La memoria humana funciona en dos modos distintos: la memoria episódica, que registra lo que realmente ocurrió durante un evento, y la memoria semántica, que almacena hechos generales y definiciones —qué significa una abreviatura, quién es una persona en particular. El modelo de datos Cosmos se diseñó intencionadamente para reflejar esta división, almacenando los registros episódicos específicos de las reuniones por separado del glosario semántico acumulado de personas, términos y sistemas.

Decisiones técnicas clave

Varias elecciones deliberadas determinaron el funcionamiento del sistema, desde la decisión de eliminar la configuración manual del dominio en favor del descubrimiento automático, hasta el almacenamiento redundante de entidades para satisfacer tanto las necesidades de SQL como las de la interfaz de usuario, y hasta el hecho de limitar estrictamente el papel del LLM a la extracción de información y la generación de consultas, en lugar de permitirle gestionar el formato o las reglas comerciales.

Aprendizajes obtenidos

1. El comportamiento de reejecución de Streamlit exige un manejo deliberado del estado. Cada clic en el botón hace que todo el script se ejecute nuevamente desde el principio. Todo aquello que debe persistir entre interacciones debe escribirse en st.session_state antes de que se muestre el botón que activa la reejecución, y no después.
2. El dialecto SQL de Cosmos DB no es ANSI SQL estándar. La función CONTAINS() solo funciona con cadenas de texto, no con arrays, por lo que el modelo necesita indicaciones explícitas en la sugerencia de esquema, incluyendo al menos un ejemplo de cómo escribir incorrectamente la consulta.

No se puede confiar en que los modelos de lenguaje sigan siempre las instrucciones de formato de salida. Incluso con instrucciones claras de síntesis, el modelo a veces devuelve únicamente una breve oración introductoria en lugar de la respuesta completa. Por esta razón, contar con una solución alternativa determinista que construya la respuesta directamente a partir de los datos brutos obtenidos no es un detalle opcional, sino una red de seguridad necesaria.

Las herramientas deben tener responsabilidades estrechas y bien definidas. Es tentador incorporar directamente la lógica de formato, las reglas empresariales o el conocimiento del dominio en una herramienta, pero se debe resistir a esa tentación: una herramienta debería estar encargada únicamente de una tarea específica.

Para renderizar gráficos de Pyvis dentro de Streamlit es necesario escribir en un archivo temporal en lugar de pasar una cadena en memoria. Utilice tempfile.NamedTemporaryFile y recuerde eliminarlo posteriormente. También cabe señalar que st.components.v1.html estará en vías de ser eliminado a partir del 1 de junio de 2026, por lo que en el futuro se debe utilizar st.iframe.

La idea central del diseño

La verdadera inteligencia en un sistema como este no proviene del modelo de lenguaje, sino del almacén de memoria que está detrás de él.

El modelo en sí no tiene ninguna memoria; es intrínsecamente sin estado. Lee un fragmento de transcripción y genera un conjunto de entidades. Lee una pregunta y genera una consulta SQL. Nada persiste entre llamadas: cada invocación comienza completamente desde cero.

Cosmos DB es donde reside la memoria real. En el instante en que algo se guarda en el cerebro, lo que antes era una extracción temporal del modelo se convierte en un registro duradero, estructurado y buscable. El glosario de términos del dominio sigue creciendo. La red de relaciones se expande. El conocimiento se construye sobre sí mismo con el paso del tiempo.

Todo el sistema funciona gracias a una infraestructura ya existente: Azure VMs, Azure Functions, Azure Cosmos DB y Azure OpenAI, coordinadas a través del AGF Hub. No se introdujeron servicios nuevos ni fue necesario ningún proceso complejo. Lo que permitió que funcionara fue un almacén de memoria cuidadosamente diseñado, límites claros respecto a las responsabilidades de cada herramienta y un modelo de lenguaje cuya función es simplemente leer las reuniones para que la gente no tenga que hacerlo.

Lecturas relacionadas

• Por qué el coste de la IA agente explota: un modelo de costes centrado en la arquitectura — Explica por qué los costes de los agentes de LLM deben medirse por tarea completada y no por llamada, y describe mecanismos arquitectónicos como el enrutamiento de modelos, los presupuestos de contexto y el caché para controlar los gastos.
• Comprendiendo los agentes de IA: objetivos, herramientas, memoria y el bucle del agente — Una explicación sencilla para principiantes sobre cómo difieren los agentes de IA de los chatbots, abordando sus componentes esenciales, el bucle de toma de decisiones, los niveles de autonomía y casos de uso en el mundo real.

RAG vs Agentic RAG vs Graph RAG: Elegir la arquitectura de recuperación adecuada — Aprenda cómo el RAG simple falla con preguntas de múltiples pasos y datos estructurados, y cómo los bucles agenciales y la recuperación basada en grafos resuelven respectivamente diferentes debilidades.

Reducir las halucinaciones en un pipeline de chatbot RAG médico — Aprenda cómo la búsqueda híbrida, el reclasificado y una política estricta de no fabricar información se combinan para crear un chatbot RAG de investigación médica más fiable.

Explicación de la generación reforzada por recuperación de información: Cómo corregir las lagunas de conocimiento en los LLM — Aprenda por qué los LLM generan información falsa y pierden actualidad, y luego vea paso a paso cómo RAG recupera datos, los divide en fragmentos, los incrusta y refuerza las instrucciones para solucionarlo.