Capítulo 10 — Principais Frameworks de Avaliação

Décimo post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Em que a Tríade ganha um toolkit — oito frameworks em dois sabores — e uma admissão honesta sobre a parte da avaliação que nenhum deles ainda resolve.

Por que este capítulo existe

A Tríade do Capítulo 9 disse o que medir. Não disse nada sobre como rodar essas medições em produção. As métricas são conceitos. Suas implementações são prompts para o juiz, lógica de decomposição para afirmações, escolhas de embedding para similaridade, estratégias de amostragem para custo, dashboards, alertas e loops de revisão humana. Nenhum time constrói tudo isso do zero.

Os frameworks se separaram por um eixo reconhecível. De um lado, as bibliotecas focadas em métrica — RAGAS, TruLens, DeepEval — computando a Tríade com metodologia documentada e reprodutível. Do outro, as plataformas de observabilidade — Braintrust, LangSmith, Phoenix, Galileo, Opik — começando por traces de produção e integrando avaliação como uma feature em um workflow maior. Escolher entre elas é menos uma comparação de features e mais uma questão do que o time precisa que o sistema faça no dia depois do lançamento.

10.1 As bibliotecas focadas em métrica — RAGAS, TruLens, DeepEval

RAGAS é o mais próximo de uma implementação de referência da Tríade que o campo tem. Conjunto de métricas conservador, prompts documentados, toda chamada de LLM exposta. O pipeline de Faithfulness é uma cadeia de dois estágios — decompor a resposta em afirmações, checar cada afirmação contra o contexto — e a lista intermediária de afirmações volta no resultado, então um engenheiro consegue apontar para a afirmação específica que o framework decidiu sem suporte. Para pesquisa, indústrias reguladas ou qualquer time que precise defender sua metodologia, RAGAS é o default. O custo é que parece acadêmico. Computa métricas; não entrega dashboard.

TruLens fica entre biblioteca de métrica e plataforma de observabilidade. Sua ênfase é instrumentação: o framework embrulha a aplicação no nível de função, capturando toda chamada de recuperação e toda resposta do modelo num Trace estruturado, e depois roda a Tríade contra os traces. As métricas da Tríade são expostas como feedback functions — pequenas unidades componíveis, fácil escrever as suas. TruLens é a escolha certa quando as necessidades de avaliação do time vão além do conjunto padrão, ou quando o workflow gira em torno de inspecionar falhas individuais em vez de dashboards agregados.

DeepEval assume uma terceira postura: avaliação como pytest. Casos de teste são escritos e rodados com uma CLI ao estilo pytest; falhas barram o PR; o conjunto de métricas é o mais amplo dos três, incluindo verificações de viés, toxicidade e alucinação ao lado da Tríade. O tradeoff é que a amplitude vem com rigor desigual. Pegue uma métrica do menu sem ler sua implementação e você pode acabar reportando números que não significam o que você acha. A disciplina certa é escolher um conjunto pequeno, ler os prompts, calibrar contra rótulos à mão e tratar o resto como inspiração.

10.2 As plataformas de observabilidade — Braintrust, LangSmith, Phoenix, Galileo, Opik

As bibliotecas focadas em métrica respondem "como computo a Tríade". As plataformas de observabilidade respondem "como rodo um sistema RAG em produção". Elas partem da suposição de que o time vai estar escrevendo prompts, comparando versões de modelo, ingerindo traces e olhando dashboards no horizonte previsível. Avaliação é uma feature; versionamento de prompt, exploração de trace, teste A/B e alerting são igualmente parte do valor.

Braintrust lidera por experiência do desenvolvedor — o experimento, um registro versionado do comportamento do modelo sobre um dataset, com diffs de nota lado a lado em uma UI genuinamente agradável de usar. LangSmith é a escolha natural para times já fundo em LangChain; espera estar no centro da instrumentação da aplicação e recompensa esse comprometimento com profundidade. Phoenix, da Arize, é a opção open-source, distinguida por análise de drift e cluster de embeddings que as outras subestimam — viável para times que não podem enviar traces a um endpoint SaaS. Galileo é a plataforma focada em empresa, com uma nota Correctness proprietária e deploy on-prem para indústrias reguladas. Opik, da Comet, é a entrante mais recente, open-source-first como Phoenix, polida como Braintrust, com a vantagem adicional de unificar observabilidade de LLM e ML clássico numa só plataforma.

A escolha entre as cinco é menos sobre features e mais sobre fit organizacional. Loja LangChain vai de LangSmith. Time greenfield de produto-engenharia vai de Braintrust. Time open-source-first vai de Phoenix. Empresa regulada vai de Galileo. Loja Comet vai de Opik. Qualidade de métrica nas cinco é amplamente comparável — todas implementam a Tríade, todas usam LLM-como-Juiz, todas carregam as mesmas limitações fundamentais que o Capítulo 9 nomeou. As diferenças são workflow, não medição.

10.3 O Gap de Avaliação e o padrão de três loops

Aqui está o fato desconfortável que o tour pelos frameworks acabou de passar por cima. Quase toda ferramenta acima avalia na camada de inferência: dado que a recuperação já aconteceu, o modelo honrou os chunks, a resposta encaixou na pergunta, os chunks estavam no tópico. Nenhuma delas, em sentido profundo, te diz se a recuperação achou os chunks certos para começo de conversa. A saída do retriever é a entrada da camada de inferência, e as métricas da camada de inferência medem a saída mas não a entrada. Se a recuperação consistentemente perde um documento importante, a Fidelidade fica alta (o modelo honrou o que recebeu), a Relevância da Resposta fica alta (a resposta encaixou no formato da pergunta), e os usuários ganham a resposta errada de qualquer jeito.

Esse é o Gap de Avaliação. A razão estrutural é que avaliação na camada de inferência é sem referência, enquanto avaliação rigorosa na camada de contexto precisa saber quais eram os chunks certos — o que exige ou um conjunto rotulado ou um sintético. Os contornos — geração sintética de perguntas, sondagens needle-in-a-haystack, proxies de impacto a jusante, auditoria de recuperação condicionada por query, recuperação-contra-si — são todos úteis e todos incompletos. O resumo honesto é que avaliação na camada de contexto é a fronteira aberta e times devem esperar investir parte da própria engenharia direto em qualidade de recuperação. Os frameworks ajudam com o loop de inferência; deixam o loop de recuperação majoritariamente para o time.

O padrão para o qual times maduros convergem são três loops, não um. Loop interno: uma biblioteca focada em métrica (tipicamente RAGAS ou DeepEval) roda a Tríade sobre um conjunto fixo de regressão a cada mudança significativa, rápido e determinístico, orientado a pegar regressões. Loop externo: uma plataforma de observabilidade cuida do armazenamento de traces de produção, computação online de métricas sobre tráfego amostrado, dashboards e alertas — orientado ao drift que o conjunto de regressão vai perder. Loop lento: uma pequena função de revisão humana calibra os juízes LLM, audita traces marcados, e mantém o conjunto de regressão conforme o produto evolui. Um time só com loop interno entrega produção com drift. Um time só com loop externo vê o drift mas não consegue depurar. Um time com os dois mas sem revisão humana confia em juízes que estão silenciosamente errando. Os três são necessários, e o valor dos frameworks é quanto de cada loop eles facilitam.

O que o Capítulo 10 prepara

Entre a Tríade do Capítulo 9 e os frameworks do Capítulo 10, um time tem o que precisa para medir um sistema RAG: um vocabulário, uma contabilidade honesta do que o vocabulário perde, e um conjunto pequeno de ferramentas que transforma as medições em dashboards. O sistema vai ser legível. Mas medição é só metade da história de produção. Um sistema que é medido mas não é mantido vai degradar de qualquer jeito, porque os documentos mudam, os usuários mudam e os modelos subjacentes mudam. Saber que a qualidade caiu não é o mesmo que conseguir restaurá-la.

Próximo — Capítulo 11: Atualizações Contínuas e Otimização do Pipeline. CDC e indexação incremental, semantic caching e tiering de modelo, e o loop de feedback de quatro estágios que transforma telemetria de produção no tipo de sistema que de fato fica melhor quanto mais tempo roda.