Capítulo 5 — Avaliando Aplicações LLM
Quinto post do passeio capítulo a capítulo pelo LLM Primer V: Construindo Aplicações LLM Reais. O capítulo que admite que assertEqual morreu para saídas de LLM e reconstrói a disciplina de teste em torno de juízes ancorados, da Tríade RAG e de testes de trajetória.
Por que este capítulo existe
Testes clássicos de software se apoiam na hipótese de que uma saída correta é uma saída específica — a função retorna 42, a string é igual a "Hello, world", o JSON casa com o fixture. Sistemas LLM produzem paráfrases equivalentes em significado mas diferentes em caractere, e a asserção de exact-match que ancorou o teste de software por cinquenta anos colapsa na primeira regeneração. Times então recorrem a BLEU, ROUGE, ou similaridade de cosseno de embedding e descobrem que essas métricas correlacionam fracamente com o julgamento humano nas coisas que importam — a resposta está certa, está ancorada, está de fato tratando da pergunta? O Capítulo 5 reconstrói a disciplina de teste em torno do que de fato funciona: rubricas ancoradas de LLM-como-juiz, a Tríade RAG, testes de trajetória de agente, e um loop contínuo em que traces de produção alimentam o conjunto de avaliação que segura o próximo release.
5.1 A lacuna de avaliação e LLM-como-juiz
A lacuna de avaliação é a distância entre o que um teste clássico consegue medir e o que uma saída de LLM de fato precisa que seja medido. Exact-match e métricas de string de referência capturam nenhuma das falhas interessantes em tarefas ricas em paráfrase. LLM-como-juiz é o cavalo de batalha que fecha a lacuna, com duas disciplinas que o separam de um truque de festa. Primeiro, a rubrica do juiz é ancorada: cada valor de nota tem uma definição escrita, idealmente com um exemplo, para que o juiz não esteja associando um número livremente. Segundo, o juiz produz raciocínio antes da nota, porque um juiz que tem de escrever o próprio raciocínio é um juiz que pontua com mais consistência. Verificações programáticas complementam o juiz para o que é verificável de modo determinístico — o JSON dá parse, os campos exigidos estão presentes, nenhuma string proibida, tamanho de resposta dentro dos limites. O juiz não é universal; é o que cobre o terreno que as verificações determinísticas não cobrem.
5.2 A Tríade RAG — contexto, groundedness, relevância da resposta
Para sistemas de recuperação, o padrão que se cristalizou é pontuar três vértices de forma independente. Relevância de contexto pergunta se os chunks recuperados são de fato relevantes para a consulta, e isola falhas de recuperação de falhas de geração. Groundedness pergunta se a resposta gerada se sustenta a partir do contexto recuperado, e captura alucinações que passam pela validação de formato. Relevância da resposta pergunta se a resposta trata da pergunta que o usuário de fato fez. Pontuados de forma independente, os três vértices localizam falhas: uma nota baixa em relevância de contexto aponta para a recuperação, uma nota baixa em groundedness aponta para o gerador, uma nota baixa em relevância da resposta aponta ou para o roteador ou para um sistema que está respondendo a uma pergunta adjacente. RAGAS operacionaliza a Tríade como um pipeline em lote; a qualidade do modelo-juiz domina a qualidade das notas, então o próprio juiz é um componente que o time avalia.
5.3 Nichos de framework e regressão de agente
Três frameworks ocupam nichos distintos. RAGAS roda a Tríade RAG em lote contra um dataset de pares pergunta-resposta e é a ferramenta certa para avaliação periódica de dataset. TruLens conecta feedback functions ao tráfego de produção ao vivo e computa a tríade sobre os próprios traces, fechando o loop entre produção e avaliação. DeepEval roda testes de LLM como gates de CI do jeito que pytest roda testes unitários, com limiares por métrica. Agentes estendem tudo isso em três direções: snapshot tests de trajetória asseveram o formato da sequência de chamadas de ferramenta para uma entrada fixa, capturando drift estrutural; asserções de invariante verificam que o agente não chamou uma ferramenta proibida ou pulou uma aprovação exigida; testes de rubrica pontuam a própria trajetória por se o caminho foi razoável. Um agente que dá a resposta certa do jeito errado está a uma mudança de prompt de dar a resposta errada do mesmo jeito, e o teste de trajetória é a disciplina que pega isso.
O que o Capítulo 5 prepara
Avaliações precisam de traces de produção para amostrar. Gates de CI precisam de regressões reais para guardar. O loop de melhoria contínua só funciona se houver uma camada de observabilidade capturando cada passo de cada invocação — as chamadas de modelo, as chamadas de ferramenta, os resultados de recuperação, os saltos de sub-agente, o custo, a latência, o feedback do usuário. O Capítulo 6 é essa camada. Ele percorre OpenTelemetry com convenções semânticas de GenAI, as métricas que de fato importam para sistemas LLM, as escolhas de plataforma e — mais importante — o pipeline de export que roteia traces de baixa pontuação de volta para o conjunto de avaliação que segura o próximo release.
Próximo — Capítulo 6: Observabilidade e Tracing de IA. O substrato que torna avaliação e debug possíveis — um trace aninhado por invocação, com custo e qualidade anexados como atributos de primeira classe.
