Por que um agente de IA não encontra uma resposta que está na sua base de conhecimento

Você pergunta algo ao seu agente de IA sobre um tema que sabe estar documentado: no manual do produto, numa política interna, no histórico de tickets. E o agente responde "não tenho essa informação" ou, pior, inventa algo parecido mas incorreto. A suspeita imediata costuma ser que o modelo é ruim. A causa real, quase sempre, é outra: o modelo nunca chegou a ler o trecho correto.

Por que um agente falha se a resposta já está nos seus documentos?

Porque a maioria dos agentes conectados a uma base de conhecimento não lê todos os documentos toda vez que alguém pergunta algo. Primeiro buscam os trechos que parecem mais relevantes para aquela pergunta específica (a técnica se chama RAG, retrieval augmented generation) e só esses trechos chegam ao modelo que gera a resposta. Se a busca traz os trechos errados, ou não traz nenhum, o modelo nunca tem a chance de responder bem. Não importa quão bom seja esse modelo.

Um artigo da Universidade Deakin estudou isso em três casos reais: dois sistemas já em uso (um para pesquisadores, outro para estudantes) e um terceiro experimento em maior escala, com 15.000 documentos e 1.000 perguntas sobre temas biomédicos. Disso saiu um catálogo de sete pontos de falha distintos. Três desses sete acontecem antes de o modelo gerador ler uma única palavra: falta a informação na base, o trecho correto existe mas não ficou entre os melhores resultados da busca, ou ficou entre os resultados mas se perdeu na etapa que junta e corta tudo antes de mandar para o modelo. O erro foi cometido na busca, não na resposta.

Buscar por palavras ou buscar por significado: os dois falham, de formas diferentes

Antes dos LLMs, buscar informação entre muitos documentos já era um problema resolvido, ainda que de outra forma: por palavras-chave, indexando qual termo aparece em qual documento (a técnica clássica se chama BM25). Esse método falha quando o cliente escreve diferente de como está escrito no documento: pergunta sobre "cancelar minha assinatura" e o documento diz "dar baixa no plano".

A busca semântica que um RAG usa resolve exatamente isso: transforma a pergunta e cada trecho de documento num vetor, e busca os vetores mais próximos em significado, não em texto exato. O custo aparece em outro lugar, em como cada documento é cortado em trechos. Um trecho muito pequeno não tem contexto suficiente para responder perguntas que cruzam duas ideias. Um muito longo dilui a parte relevante entre texto que não vem ao caso, e essa parte extra acaba competindo com a resposta real quando o modelo precisa decidir o que usar. (Como escolher o modelo de embeddings mais apropriado para cada domínio é outra discussão, que daria um artigo à parte.)

Adicionar mais contexto resolve isso?

Às vezes. O mesmo estudo encontrou que ampliar o contexto passado ao modelo, de 4.000 para 8.000 tokens no caso deles, melhorou as respostas. Mas há um limite, e não é só de tamanho: outra pesquisa sobre como os modelos de linguagem usam contextos longos (Liu et al., 2023, "Lost in the Middle: How Language Models Use Long Contexts") encontrou que a precisão cai quando a informação relevante fica no meio de um contexto longo, nem no início nem no fim. Colocar mais documentos "por precaução" não compensa uma busca malfeita. Em alguns casos piora, porque adiciona mais lugares onde a resposta correta pode se perder de vista.

O que já sabíamos antes de os LLMs existirem

Encontrar o dado correto entre muitos documentos não é um problema que os modelos de linguagem inventaram. Existia em buscadores, em sistemas de recomendação, em qualquer pipeline de machine learning de antes de 2020. E a lição daquela época continua valendo intacta: a qualidade do que entra num sistema (como está indexado, como está segmentado, quão bem pré-processado está) define o teto do que esse sistema consegue responder, além de quão sofisticada seja a etapa final. Trocar "modelo estatístico" por "modelo de linguagem" não muda essa dependência; só a esconde melhor, porque a etapa final agora escreve em prosa convincente mesmo quando não tinha com o que.

Antes, treinávamos na mão o modelo que precisava corrigir esse tipo de erro. Hoje se escreve um prompt mais cuidadoso esperando o mesmo efeito. O problema de fundo, se o dado correto chegou ou não, é o mesmo de sempre.

O que olhar antes de trocar de modelo

Quando um agente responde mal algo que está documentado, vale olhar um passo antes de tocar no prompt ou trocar de modelo: qual trecho chegou a essa resposta. Na maioria das vezes, a resposta correta nunca esteve na mesa. Essa etapa (o que foi buscado, o que foi encontrado, o que disso foi mostrado ao modelo) é mais fácil de auditar do que de adivinhar, e é aí que vale olhar primeiro.

---

Fontes: Barnett, Kurniawan, Thudumu, Brannelly e Abdelrazek, "Seven Failure Points When Engineering a Retrieval Augmented Generation System", Universidade Deakin, 2024 (arxiv.org/abs/2401.05856). Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", 2023.