Como gerir o contexto dos agentes? RAG, LLM Wiki e GraphRAG

Lembro-me distintamente de ser pequeno, com 10 ou 11 anos, quando vivíamos em Ponta Delgada e chegava a casa superentusiasmado para ver os documentários do Canal História e do Discovery. Todos os dias, sem exceção, a minha cabeça memorizava milhares de pormenores: «Oh, os gregos antigos tinham máquinas que dispensavam água abençoada em troca de moedas em alguns templos!». Foram anos e anos a criar um hábito que ainda hoje tenho. Nestes últimos (quase) 36 anos, devo ter visto dezenas de milhares de documentários e vídeos de comunicação científica, história, filosofia e outros temas. E a (óbvia) verdade é que 99,9% do que ouvi, vi e li não ficou em lado nenhum na minha cabeça.

Houve factos que ficaram, por serem tão curiosos como o das máquinas dos gregos, ou porque os anotei e eventualmente li de novo, ou porque os interiorizei de tal forma que já fazem parte do meu conhecimento geral, ou porque estão associados a outras memórias marcantes, ou porque a memória ainda é fresca.

Podemos tirar daqui uma analogia interessante, embora não seja uma equivalência. Os foundation models (modelos de AI treinados com grandes volumes de dados diversificados, que podem ser adaptados a diferentes tarefas) também não têm tudo disponível a cada instante. Mas convém distinguir o conhecimento aprendido durante o treino do contexto ativo, a informação que recebem para uma determinada chamada ao modelo.

Quando são treinados, são expostos a mais dados do que algum humano conseguiria consumir na sua vida inteira. Parte desse conteúdo junta-se à amálgama do conhecimento de base do modelo. Inclusivamente, tal como os humanos, os modelos podem assimilar fake news e ideias falsas.

Na sua utilização normal do dia a dia, os modelos aliam este conhecimento de base a uma série de fontes de contexto. Se eu quero que um agente de AI automatize a filtragem e priorização da minha caixa de email, ele vai usar o conhecimento de base que traz, o conhecimento do processo (instruções) que lhe dei e os dados dos próprios emails (conhecimento da tarefa específica). Mas aí tropeçamos numa das maiores limitações desta tecnologia: os modelos têm uma janela de contexto limitada. Há modelos de fronteira com janelas na ordem de 1 milhão de tokens. Cada token corresponde, em média e como aproximação para texto em inglês, a cerca de quatro caracteres. Um milhão de tokens, portanto, equivale aproximadamente a uma vez e meia o texto dos três volumes de O Senhor dos Anéis, no original inglês.

Defino aqui um agente como um programa que usa um foundation model (FM) para tomar decisões e usar ferramentas. De cada vez que tem de receber informação e tomar uma decisão, vai chamar o modelo. A informação que não for incluída nessa chamada não estará disponível como contexto, mesmo que tenha aparecido numa chamada anterior. A indústria tem evoluído para contornar esta limitação. Ao conjunto de práticas que se usam para passar o contexto que é preciso, quando é preciso, ao agente, chamo aqui técnicas de gestão de contexto. Uma das ideias-base é a progressive disclosure of information, ou seja, a forma como se vai dando contexto ao longo do tempo, acompanhada de ferramentas para o agente ir buscar a informação de que necessita.

Sendo toda uma área relativamente recente, não há uma solução one-size-fits-all. Existem várias heurísticas comuns na indústria, sendo que uma das mais utilizadas é a Retrieval-Augmented Generation (RAG). Com esta técnica, os documentos são normalmente divididos em segmentos, segundo diferentes critérios: tamanho fixo, contexto semântico, hierarquia do documento, entre outros. Muitas vezes, esses segmentos são convertidos em representações numéricas, a que chamamos embeddings.¹ Quando há necessidade, o agente faz uma pesquisa sobre essa informação, recebe os segmentos considerados relevantes para a sua tarefa e usa-os para gerar a resposta. Tipicamente, pode fazer uma pesquisa léxica (procura termos específicos), semântica (procura segmentos com significados semelhantes ao que é pedido pela tarefa) ou híbrida (ambas). Isto é excelente quando é necessário encontrar informação específica em documentos bastante grandes, como no clássico exemplo de retirar informação relevante de um contrato de 500 páginas. No entanto, mesmo que o agente formule bem a pesquisa, pode não receber todos os segmentos necessários para responder à tarefa, ficando com contexto incompleto. Não obstante, tanto na indústria como na academia, ainda se fala bastante desta técnica, e tem sido utilizada em praticamente todos os casos de implementação que já vi.

Mas não é a única forma de o fazer. Um dos nomes mais referenciados neste mundo da AI generativa, Andrej Karpathy, propôs a LLM Wiki.² Esta abordagem utiliza ficheiros Markdown (.md), que são apenas ficheiros de texto com uma formatação específica, para manter um índice e páginas interligadas de conhecimento sintetizado a partir das fontes. O agente pode consultar as páginas relevantes, na íntegra, quando necessita. É o equivalente a quando eu vou consultar o manual de utilização de um objeto novo e leio, escolhendo com base no índice, apenas as referências relevantes para mim. Tem sido a minha abordagem preferida para vários casos de uso, pela consistência e pela facilidade de manutenção ou ajuste manual. Pode é criar, em casos de uso complexos, um encargo de manutenção maior do que, por exemplo, gerar os embeddings de uma nova versão de um documento e atualizar o índice. Podemos criar pipelines de destilação de informação (refiro-me a reduzir a quantidade de texto, mantendo a densidade de informação) para fazer a manutenção de uma LLM Wiki. Aliás, é isso que Karpathy propõe. Da minha experiência, no entanto, esta destilação de informação ainda é bastante falível por parte dos modelos, aos quais escapam frequentemente nuances da informação original e a visão de conjunto do objetivo do documento. E o esforço de curadoria rapidamente se torna pesado.

Por fim, como o texto já vai longo e não quero desanimar quem até aqui o leu, gostava de passar brevemente pela abordagem GraphRAG, ou Graph Retrieval-Augmented Generation. Se calhar começamos pelo que é um grafo: uma estrutura matemática ou computacional formada por um conjunto de vértices (nós) ligados por arestas (ou ligações)... pausa para respirar. Simplificando, é uma maneira de representar informação e as relações entre os dados, como abaixo. Um bom exemplo é uma rede social, em que pode haver nomes de várias pessoas ligadas entre si, mas as ligações têm uma direção: a Joaquina segue o Manuel, que segue o Ramiro, que, por sua vez, segue a Joaquina. Isso não significa que o Manuel siga a Joaquina, nem que a Joaquina siga o Ramiro. As pessoas são nós; as ligações são os follows. É possível ter uma direção na informação, e as relações são explícitas.

Uma seta de A para B significa «A segue B». A relação inversa não está implícita.

GraphRAG usa um grafo de conhecimento, com entidades (conceitos, objetos, pessoas) e relações entre elas, para criar uma teia que pode ser consultada. Torna mais simples, para um agente, seguir um percurso de pesquisa através dessas relações à procura de informação para completar uma tarefa. A informação encontrada é depois passada ao modelo como contexto para produzir a resposta. Esta capacidade pode ser especialmente útil quando é preciso cruzar informação de vários documentos. Como nas outras abordagens, tem de haver curadoria da informação e das relações, em particular quando são produzidas de forma autónoma pelo agente. Por exemplo, se as relações estiverem erradas, incompletas ou desatualizadas, o agente pode deixar informação importante de fora ou apoiar a resposta em ligações que já não fazem sentido. Já me aconteceu aplicar esta abordagem e ficar com uma rede tão complexa que nem eu nem o agente (shoutout ao Sr. Alfredo) percebíamos o que estava lá.

Estas três abordagens não são mutuamente exclusivas, e um projeto de implementação empresarial relativamente complexo e com uma abordagem madura poderá, no limite, utilizar as três, consoante o caso. Uma wiki pode ser pesquisada por RAG, e o próprio GraphRAG é uma forma de apoiar a geração com informação recuperada. Aqui vai o resumo do meu modelo mental sobre quando usar cada uma:

Mas o tema da gestão de contexto não se esgota aqui. Este é apenas o primeiro artigo de uma série em que vou abordar esta temática. Futuramente, vamos falar de caching, compaction, context pruning e isolamento de contexto com subagentes. Vemo-nos em breve.