¿Cómo gestionar el contexto de los agentes? RAG, LLM Wiki y GraphRAG

Recuerdo perfectamente ser pequeño, con 10 u 11 años, cuando vivíamos en Ponta Delgada y llegaba a casa emocionadísimo para ver los documentales del Canal Historia y de Discovery. Todos los días, sin excepción, mi cabeza memorizaba miles de detalles: «¡Ah, los antiguos griegos tenían máquinas en algunos templos que dispensaban agua bendita a cambio de monedas!». Fueron años y años creando un hábito que todavía conservo. En estos últimos (casi) 36 años, debo de haber visto decenas de miles de documentales y vídeos de divulgación científica, historia, filosofía y otros temas. Y la verdad (evidente) es que el 99,9 % de lo que oí, vi y leí no se quedó en ningún rincón de mi cabeza.

Hubo datos que sí se quedaron, por ser tan curiosos como lo de las máquinas de los griegos, o porque los anoté y acabé leyéndolos de nuevo, o porque los interioricé tanto que ya forman parte de mi cultura general, o porque están asociados a otros recuerdos importantes, o porque el recuerdo aún es reciente.

De aquí podemos sacar una analogía interesante, aunque no sea una equivalencia. Los foundation models (modelos de AI entrenados con grandes volúmenes de datos diversos, que pueden adaptarse a distintas tareas) tampoco tienen todo disponible en todo momento. Pero conviene distinguir el conocimiento aprendido durante el entrenamiento del contexto activo, la información que reciben para una llamada concreta al modelo.

Durante el entrenamiento, se exponen a más datos de los que cualquier humano podría consumir en toda su vida. Parte de ese contenido se suma a la amalgama de conocimientos de base del modelo. Incluso, al igual que los humanos, los modelos pueden asimilar fake news e ideas falsas.

En su uso habitual, los modelos combinan ese conocimiento de base con diversas fuentes de contexto. Si quiero que un agente de AI automatice el filtrado y la priorización de mi bandeja de email, utilizará el conocimiento de base que trae, el conocimiento del proceso (instrucciones) que le he dado y los datos de los propios emails (conocimiento de la tarea concreta). Pero ahí nos encontramos con una de las mayores limitaciones de esta tecnología: los modelos tienen una ventana de contexto limitada. Hay modelos de frontera con ventanas del orden de 1 millón de tokens. Cada token equivale, de media y como aproximación para textos en inglés, a unos cuatro caracteres. Por tanto, un millón de tokens equivale aproximadamente a una vez y media el texto de los tres volúmenes de El Señor de los Anillos, en su original inglés.

Aquí defino un agente como un programa que utiliza un foundation model (FM) para tomar decisiones y usar herramientas. Cada vez que necesita recibir información y tomar una decisión, llama al modelo. La información que no se incluya en esa llamada no estará disponible como contexto, aunque haya aparecido en una llamada anterior. La industria ha ido evolucionando para sortear esta limitación. Al conjunto de prácticas utilizadas para proporcionar al agente el contexto que necesita, cuando lo necesita, lo llamo aquí técnicas de gestión de contexto. Una de las ideas de base es la progressive disclosure of information, es decir, cómo se va proporcionando contexto a lo largo del tiempo, junto con herramientas para que el agente busque la información que necesita.

Al ser un campo relativamente reciente, no existe una solución one-size-fits-all. Hay varias heurísticas habituales en la industria, y una de las más utilizadas es la Retrieval-Augmented Generation (RAG). Con esta técnica, los documentos suelen dividirse en fragmentos según distintos criterios, como tamaño fijo, contexto semántico o jerarquía del documento. Muchas veces, esos fragmentos se convierten en representaciones numéricas que llamamos embeddings.¹ Cuando hace falta, el agente busca en esa información, recibe los fragmentos considerados relevantes para su tarea y los utiliza para generar la respuesta. Normalmente, puede realizar una búsqueda léxica (busca términos concretos), semántica (busca fragmentos con significados similares a lo que pide la tarea) o híbrida (ambas). Esto resulta excelente cuando es necesario encontrar información específica en documentos muy extensos, como en el ejemplo clásico de extraer información relevante de un contrato de 500 páginas. Sin embargo, aunque el agente formule bien la búsqueda, puede no recibir todos los fragmentos necesarios para resolver la tarea y quedarse con un contexto incompleto. Aun así, tanto en la industria como en el ámbito académico se sigue hablando mucho de esta técnica, y se ha utilizado en prácticamente todos los casos de implementación que he visto.

Pero no es la única forma de hacerlo. Uno de los nombres más citados en el mundo de la AI generativa, Andrej Karpathy, propuso la LLM Wiki.² Este enfoque utiliza archivos Markdown (.md), que no son más que archivos de texto con un formato específico, para mantener un índice y páginas interconectadas de conocimiento sintetizado a partir de las fuentes. El agente puede consultar las páginas pertinentes, completas, cuando las necesita. Equivale a consultar el manual de un objeto nuevo y leer, eligiendo a partir del índice, solo las referencias que me interesan. Ha sido mi enfoque preferido para varios casos de uso, por su consistencia y por lo fácil que resulta mantenerlo o ajustarlo manualmente. Eso sí, en casos de uso complejos puede generar una carga de mantenimiento mayor que, por ejemplo, crear los embeddings de una nueva versión de un documento y actualizar el índice. Podemos crear pipelines de destilación de información (me refiero a reducir la cantidad de texto manteniendo su densidad informativa) para mantener una LLM Wiki. De hecho, eso es lo que propone Karpathy. Sin embargo, según mi experiencia, los modelos todavía fallan bastante en esa destilación: a menudo se les escapan matices de la información original y la visión de conjunto del objetivo del documento. Y el esfuerzo de curación se vuelve pesado rápidamente.

Por último, como el texto ya se está alargando y no quiero desanimar a quien haya llegado hasta aquí, me gustaría repasar brevemente el enfoque GraphRAG, o Graph Retrieval-Augmented Generation. Quizá convenga empezar por qué es un grafo: una estructura matemática o computacional formada por un conjunto de vértices (nodos) conectados mediante aristas (o enlaces)... pausa para respirar. Simplificando, es una manera de representar información y las relaciones entre los datos, como se muestra abajo. Un buen ejemplo es una red social, donde puede haber nombres de varias personas conectadas entre sí, pero las conexiones tienen una dirección: Joaquina sigue a Manuel, que sigue a Ramiro, que a su vez sigue a Joaquina. Eso no significa que Manuel siga a Joaquina ni que Joaquina siga a Ramiro. Las personas son nodos; las conexiones son los follows. La información puede tener una dirección y las relaciones son explícitas.

Una flecha de A a B significa «A sigue a B». La relación inversa no está implícita.

GraphRAG utiliza un grafo de conocimiento, con entidades (conceptos, objetos, personas) y relaciones entre ellas, para crear una red que se puede consultar. Facilita que un agente siga un recorrido de investigación a través de esas relaciones en busca de información para completar una tarea. La información encontrada se pasa después al modelo como contexto para producir la respuesta. Esta capacidad puede resultar especialmente útil cuando hay que cruzar información de varios documentos. Como en los otros enfoques, es necesario curar la información y las relaciones, especialmente cuando las produce el agente de forma autónoma. Por ejemplo, si las relaciones son incorrectas, incompletas o están desactualizadas, el agente puede omitir información importante o fundamentar su respuesta en conexiones que ya no tienen sentido. Me ha pasado aplicar este enfoque y acabar con una red tan compleja que ni yo ni el agente (shoutout al Sr. Alfredo) entendíamos qué había allí.

Estos tres enfoques no son mutuamente excluyentes, y un proyecto de implementación empresarial relativamente complejo y con un enfoque maduro podría llegar a utilizar los tres, según el caso. Una wiki puede consultarse mediante RAG, y el propio GraphRAG es una forma de apoyar la generación con información recuperada. Aquí va el resumen de mi modelo mental sobre cuándo utilizar cada uno:

Pero la gestión de contexto no termina aquí. Este es solo el primer artículo de una serie en la que abordaré este tema. Más adelante hablaremos de caching, compaction, context pruning y aislamiento de contexto con subagentes. Nos vemos pronto.