Capítulo 9 — A Tríade de Avaliação de RAG

Nono post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Em que três falhas distintas colapsam num sintoma — e o campo inventa uma métrica de três cabeças que finalmente diz ao time qual sintoma é qual.

Por que este capítulo existe

Um sistema RAG pode falhar em três lugares distintos, e de fora as falhas parecem idênticas. O retriever traz o contexto errado. O modelo ignora o contexto certo. O modelo honra o contexto mas responde a uma pergunta diferente da que foi feita. Todo time de produção, em algum momento, tentou consertar uma dessas falhas enquanto media outra. Este capítulo é sobre o vocabulário pequeno e teimoso que evita esse erro.

É também um capítulo sobre uma virada. Recuperação de informação clássica era avaliada contra ground truth rotulado — queries com documentos corretos conhecidos, precisão e recall computados contra os rótulos. RAG opera num mundo em que tais rótulos não existem. Perguntas são abertas, respostas são generativas, o contexto relevante é o que o modelo precisa naquele momento. A Tríade foi desenhada para esse mundo. Mede consistência entre estágios, não concordância com uma referência.

9.1 Por que três sinais, não um

O instinto de um time novo é dar nota à resposta final. O usuário digitou uma pergunta, o sistema produziu uma resposta, ou a resposta está correta ou não. O instinto falha porque a resposta final é um composto de cada estágio, e quando falha o composto não te diz qual estágio corrigir. O documento certo foi perdido? Foi recuperado e ignorado? Foi usado mas respondendo a outra pergunta? Três bugs distintos, três correções distintas, um sintoma indistinguível.

A Tríade separa o pipeline nos três lugares em que a informação sobrevive ou se perde. Recuperação, fundamentação, resposta. Cada um ganha sua métrica: Relevância de Contexto, Fidelidade, Relevância da Resposta. O que torna a estrutura útil não é serem exaustivas — não são —, mas serem independentes. Um sistema pode pontuar bem numa e mal noutra, e quando isso acontece o time sabe para onde olhar. Quando um novo modelo de embedding sobe, a Relevância de Contexto deve mover. Quando um novo prompt sobe, a Fidelidade deve mover. Quando a métrica que deveria mover move, o time sabe que a mudança funcionou. Uma nota única fim-a-fim colapsa tudo isso em algo que não pode ser depurado.

9.2 Relevância de Contexto — você recuperou o contexto certo?

A Relevância de Contexto pergunta se os chunks recuperados são sobre a pergunta, frase por frase, pontuados por um juiz LLM. Captura precisão de recuperação — a fração da janela de contexto gasta em material relevante. Nota alta significa que o retriever não está desperdiçando tokens. Nota baixa significa que está trazendo ruído, e o modelo paga por esse ruído em latência e em qualidade, porque contextos longos e irrelevantes mostraram repetidamente degradar a geração.

O que a Relevância de Contexto não captura é recall — se todos os chunks de que o modelo precisaria foram realmente recuperados. Um retriever que traz um chunk perfeito e mais nada pontua perfeitamente, mesmo se a resposta exigia dois e o segundo foi perdido. Recall é seu próprio problema, medido contra conjuntos golden curados em que se conhece os documentos portadores da resposta. O capítulo também nomeia dois artefatos que vale conhecer: chunking agressivo infla a Relevância de Contexto sem necessariamente melhorar a resposta, e média não ponderada sobre um top-k fixo pode fazer um retriever parecer ruim quando os chunks irrelevantes nas posições quatro a dez quase não afetam o modelo.

9.3 Fidelidade — o modelo honrou o contexto?

Fidelidade, às vezes chamada Groundedness, faz a pergunta oposta: das afirmações que o modelo produziu, que fração pode ser sustentada pelo contexto recuperado? A computação padrão decompõe a resposta em afirmações atômicas e pergunta ao juiz, para cada uma, se o contexto a sustenta. A decomposição é a parte que importa. Uma resposta longa avaliada como bloco único tende a pontuar como totalmente fundamentada ou totalmente sem fundamento, com o juiz se resolvendo na direção do espírito geral. Afirmações atômicas forçam o juiz a avaliar cada asserção independentemente — o que pega a falha comum em que uma resposta majoritariamente correta contém uma frase que o contexto nunca sustentou.

O capítulo é honesto sobre a assimetria da Fidelidade: ela penaliza invenção mas não omissão. Um modelo que se recusa a responder pontua perfeitamente. Um modelo que dá uma resposta correta e bem fundamentada mas deixa cair um ressalva crucial do contexto também pontua bem. É também a métrica mais provável de revelar problema de prompt em vez de problema de modelo. Quando a Relevância de Contexto está alta e a Fidelidade está baixa, a resposta quase sempre está no system prompt, não no modelo — as instruções são frouxas demais para manter o modelo dentro do contexto. Aperte o prompt antes de culpar o modelo.

9.4 Relevância da Resposta e a virada sem referência

A Relevância da Resposta é a mais fácil de entender errado. Não mede correção, e não mede fundamentação. Mede se a resposta endereça a pergunta feita. Uma resposta factualmente correta que responde a uma pergunta levemente diferente pontua mal. Uma recusa educada pontua mal. A computação padrão é uma inversão esperta: dada a resposta, gere as perguntas das quais ela poderia plausivelmente ser resposta, e compare essas perguntas geradas à original. Se forem próximas, a resposta está no alvo. Se derivam, o modelo se perdeu.

A Relevância da Resposta é também onde a virada sem referência morde mais forte. Nenhuma destas métricas pode ser computada por comparação contra uma resposta correta rotulada — o espaço de respostas aceitáveis é infinito e não enumerável. Então o campo convergiu para LLM-como-Juiz: um modelo de fronteira dá nota a cada métrica usando um prompt documentado. A técnica escala. É barata. Correlaciona grosso modo com julgamento humano. Tem também modos de falha bem documentados — viés de posição em comparações pareadas, viés de comprimento, viés de família de modelo, drift de calibração ao longo de atualizações silenciosas de modelo, e o problema mais profundo de que juízes e geradores compartilham corpora de treino e por isso falham de modo correlato. A defesa não é técnica e sim operacional: prenda o modelo juiz e o prompt, calibre contra um conjunto pequeno rotulado à mão, encaminhe uma pequena fração das saídas julgadas para revisão humana, e trate qualquer mudança de juiz como evento de rebaseline que invalida comparações históricas.

O que o Capítulo 9 prepara

A Tríade dá um vocabulário para o que medir. Não diz como rodar as medições — os prompts do juiz, a lógica de decomposição, a escolha de embedding, a taxa de amostragem, os dashboards, o alerting. Nada disso se constrói do zero. Nos últimos dois anos um pequeno número de frameworks surgiu para tornar a Tríade mensurável na prática, cada um com suas próprias opiniões sobre como avaliação em produção deveria parecer. O Capítulo 10 percorre todos lado a lado.

Próximo — Capítulo 10: Principais Frameworks de Avaliação. RAGAS, TruLens, DeepEval, e as plataformas de observabilidade — para que serve cada um, onde as bibliotecas focadas em métrica acabam e onde as plataformas de produção começam, e o Gap de Avaliação que nenhum deles ainda fechou.