Uma equipe de operações jurídicas implanta um sistema RAG para revisão de contratos. O sistema funciona bem no lançamento. Seis meses depois, a equipe atualiza o corpus de documentos. Um advogado sênior percebe que o sistema está citando disposições que não se aplicam mais. Ninguém sabe quando a regressão aconteceu. O harness de avaliação nunca foi construído. Cada mudança desde o lançamento foi uma suposição.
É assim que a implantação sem evals parece na prática: não uma falha dramática, mas uma deriva lenta não detectada que aparece no pior momento possível.
O harness de avaliação não é a última coisa que você constrói. É o que torna todo o resto estável o suficiente para confiar.
Implantar Sem Evals Não é Mais Rápido
As equipes pulam os harnesses de avaliação porque parecem overhead. Escrever perguntas de teste, curar respostas de referência, instrumentar métricas antes de o sistema ter um único usuário: é esforço visível gasto em algo que parece hipotético quando o sistema ainda não está em produção.
A contabilidade real é diferente. Um sistema RAG sem um harness de avaliação não tem como determinar se uma mudança melhorou ou degradou a qualidade. Cada ajuste de prompt é um salto de fé. Cada atualização de estratégia de chunking é não testada. Cada atualização do provedor de modelo, cada adição de corpus, cada mudança de parâmetro de recuperação: cada uma é uma melhoria ou uma regressão, e sem o harness não há instrumento para dizer qual.
Sem evals, um sistema em produção acumula regressões não detectadas até que uma falha visível force a investigação. A essa altura, a causa está enterrada sob semanas ou meses de mudanças, cada uma individualmente plausível, nenhuma individualmente rastreada. A investigação custa mais do que o harness teria custado. A remediação interrompe usuários que tinham começado a confiar no sistema.
O harness de avaliação não é um conjunto de testes escrito após o sistema estar estável. É o instrumento usado para tornar o sistema estável em primeiro lugar. Construí-lo depois do fato é como calibrar uma balança após pesar todas as amostras.
As Quatro Métricas RAGAS Que Importam
O RAGAS (Retrieval Augmented Generation Assessment) é um framework de avaliação open-source que mede a qualidade do RAG em quatro dimensões. Cada métrica aponta para uma camada diferente do sistema, o que é o que torna o framework útil para diagnóstico em vez de apenas pontuação.
Faithfulness (Fidelidade) mede se a resposta gerada contém apenas afirmações suportadas pelo contexto recuperado. Uma resposta fiel não introduz informações que os documentos recuperados não contêm. Baixa Fidelidade significa que a camada de geração está alucinando: produzindo afirmações com som plausível que não têm base nas evidências recuperadas. Em uma aplicação jurídica, médica ou financeira, isso não é um problema de qualidade. É uma responsabilidade.
Answer Relevancy (Relevância da Resposta) mede se a resposta gerada realmente aborda a pergunta feita. Um sistema pode ser perfeitamente fiel enquanto ainda falha em responder à pergunta: resume com precisão os documentos recuperados sem abordar o que o usuário precisava. Baixa Relevância da Resposta aponta para uma incompatibilidade entre a compreensão da consulta e o enquadramento da geração.
Context Precision (Precisão do Contexto) mede qual proporção dos chunks recuperados foi realmente relevante para responder à pergunta. Os sistemas de recuperação frequentemente buscam documentos que são semanticamente adjacentes à consulta, mas não contêm a evidência necessária. Esses chunks irrelevantes diluem o contexto e podem ativamente induzir a camada de geração em erro. Baixa Precisão do Contexto aponta para o ranking de recuperação: o sistema está recuperando muito ruído junto com o sinal.
Context Recall (Recall do Contexto) mede se a recuperação surfaceou todos os chunks necessários para responder completamente à pergunta. Um sistema pode recuperar documentos relevantes e ainda perder a peça crítica de evidência. Baixo Recall do Contexto aponta para ingestão ou chunking: a evidência existe no corpus, mas está ou não ingerida ou fragmentada de uma forma que a torna irrecuperável para a consulta específica.
O valor diagnóstico do framework de quatro métricas é que cada métrica implica um componente diferente. Você não depura um problema de recuperação com correções de geração, e vice-versa. As métricas separam o sinal.
Construindo o Conjunto de Perguntas
O harness de avaliação exige um conjunto de testes de perguntas com respostas de referência. É aqui que a maioria das equipes subestima o investimento, e onde a maior parte do valor realmente reside.
O conjunto de testes não é uma amostra representativa de possíveis consultas. É um conjunto curado de perguntas que cobre os modos de falha que o sistema não deve exibir. As categorias a cobrir:
Recall factual: uma informação específica de um documento conhecido. O teste verifica se a recuperação encontra o documento certo e se a geração extrai o fato correto.
Síntese de múltiplos documentos: a resposta correta exige combinar informações de duas ou mais fontes. Isso testa se a recuperação surfaceou o conjunto completo de evidências e se a geração integra entre fontes sem introduzir contradições.
Espaço negativo: a pergunta não pode ser respondida a partir do corpus. A resposta correta é um reconhecimento explícito de que a informação não está disponível, não uma resposta alucinada que preenche a lacuna com conteúdo de som plausível. Este é frequentemente o teste mais importante para sistemas empresariais, onde uma resposta confiante e errada é pior do que um honesto “não tenho essa informação.”
Adversarial: formulações que podem acionar alucinação. Consultas que usam terminologia presente no corpus, mas em um contexto diferente, ou que introduzem uma premissa falsa e veem se o sistema a corrige ou aceita.
Casos extremos específicos do domínio: as perguntas que os profissionais de domínio experientes reconhecem como as mais propensas a falhar. Elas vêm das mesmas entrevistas com especialistas usadas para construir o sistema de conhecimento.
O conjunto de perguntas deve ser escrito por especialistas do domínio, não pela equipe que construiu o sistema. A equipe que construiu o sistema sabe o que o sistema consegue responder. Os especialistas sabem o que os usuários realmente perguntarão. A lacuna entre esses dois conjuntos de perguntas é onde as falhas mais importantes residem.
Conjunto de testes mínimo viável: cinquenta perguntas nas principais categorias de documentos do corpus. Execute-as em relação a uma baseline de referência antes do go-live. O conjunto de testes não é estático: cada consulta do usuário que produz uma resposta errada ou incompleta é candidata a inclusão. O harness cresce à medida que o sistema é usado, o que significa que captura novos modos de falha à medida que surgem, em vez de apenas os visíveis antes do lançamento.
Instrumentação Antes do Lançamento
O harness de avaliação tem dois modos de operação: avaliação offline antes da implantação e monitoramento online em produção.
A avaliação offline executa o conjunto de testes em relação ao sistema antes de qualquer mudança ser implantada. A pontuação em cada uma das quatro métricas RAGAS estabelece a baseline. Cada mudança subsequente, de reformulação de prompt a atualização de corpus a mudança de versão de modelo, deve passar no teste de regressão antes da implantação.
O monitoramento online amosta consultas de produção quase em tempo real e as avalia em relação às mesmas métricas. A taxa de amostragem depende do volume e da sensibilidade: uma ferramenta interna de baixo volume pode avaliar cada consulta; um sistema voltado ao cliente de alto volume pode amostrar a cinco por cento e sinalizar desvios estatísticos.
Para observabilidade online, o LangSmith rastreia cada etapa do RAG, registrando os chunks recuperados, a resposta gerada, uso de tokens e latência por etapa. Para ambientes com restrições de residência de dados, onde enviar consultas de produção para um serviço de observabilidade em nuvem é uma preocupação de conformidade, o Langfuse fornece uma alternativa self-hosted. A escolha entre eles é uma decisão de governança de dados, não de capacidade: ambos fornecem a observabilidade necessária para a camada de monitoramento.
O que registrar no mínimo: o texto da consulta, os chunks recuperados com metadados de origem e identificadores de documento, a resposta gerada, sinais de confiança onde disponíveis e feedback do usuário quando a interface o captura. Os logs são a matéria-prima para o conjunto de testes. Cada vez que um usuário sinaliza uma resposta como errada, essa consulta e a resposta correta entram no conjunto de testes para a próxima execução de avaliação offline.
Os limiares de alerta devem ser definidos antes do lançamento: qual pontuação de Fidelidade aciona uma revisão humana das consultas recentes; qual queda de Recall do Contexto aciona uma auditoria de ingestão; qual aumento de latência aciona uma revisão de infraestrutura. Os limiares são decisões organizacionais, não padrões de engenharia. Refletem a tolerância ao risco da aplicação específica.
O Protocolo de Teste de Regressão
Cada mudança em um sistema RAG é um risco de regressão.
Mudanças de prompt afetam o comportamento de geração de maneiras às vezes imprevisíveis. Atualizações de estratégia de chunking mudam quais evidências estão disponíveis para recuperação. Mudanças de modelo de embedding alteram o espaço semântico usado para ranking de recuperação. Ajustes de parâmetros de recuperação mudam o volume e a composição do contexto recuperado. Atualizações do corpus de documentos adicionam, modificam ou substituem conteúdo que a camada de geração aprendeu a usar.
Cada uma dessas mudanças pode melhorar o sistema no caso específico que motivou a mudança enquanto o degrada em casos não considerados. Sem um protocolo de teste de regressão, a equipe não tem como detectar a degradação até que ela apareça como uma reclamação de usuário ou uma falha visível.
O protocolo de regressão: implemente a mudança em um ambiente de staging, execute o conjunto de testes completo, compare as quatro pontuações RAGAS em relação à baseline, investigue qualquer métrica que caia e implante apenas quando a qualidade agregada estiver estável ou melhorada. O protocolo não exige perfeição em cada teste. Exige que nenhuma métrica caia abaixo de um limiar definido sem aceitação explícita.
Para um sistema RAG jurídico, uma queda de cinco pontos na Fidelidade após uma atualização de corpus significa que o sistema está produzindo mais citações para disposições que não se aplicam. Isso é um risco de conformidade. O teste de regressão o detecta antes de chegar aos usuários que dependem do sistema para decisões reais.
Evals como Capacidade Organizacional
A Casetext, uma empresa de IA jurídica adquirida pela Thomson Reuters por USD 650 milhões [unverified: valor citado de comunicados de imprensa públicos; verificar relatórios atuais antes de citar], construiu sua disciplina de avaliação antes de produtizar suas features de IA. O harness de avaliação não era um artefato técnico. Era o mecanismo pelo qual a equipe construiu confiança em um sistema que precisava operar em um contexto de responsabilidade profissional.
A dimensão organizacional dos evals é o que a maioria das discussões perde. A equipe que constrói o conjunto de testes, revisa as pontuações RAGAS e investiga cada regressão aprende algo sobre seu domínio e seus usuários que nenhuma quantidade de monitoramento de logs consegue replicar. Eles aprendem quais consultas são difíceis. Aprendem quais tipos de documento produzem falhas de recuperação. Aprendem onde a camada de geração é frágil e por quê.
Um sistema RAG com um harness de avaliação melhora deliberadamente. A equipe tem um loop de feedback com resolução suficiente para identificar causas e testar correções. Um sistema RAG sem um melhora acidentalmente ou degrada silenciosamente. A equipe responde a falhas visíveis, mas não tem instrumento para detectar as falhas que ainda não surgiram de uma maneira que os usuários consigam articular.
O ponto de partida é mais simples do que parece. Não espere o sistema estar pronto para produção antes de construir as primeiras cinquenta perguntas. Construa-as a partir das mesmas sessões com especialistas usadas para discovery. Execute-as em relação ao protótipo. As lacunas que o harness revela na fase de protótipo moldarão a arquitetura do sistema antes de uma única consulta de produção chegar. Esse é o momento certo para descobri-las.
O harness de avaliação não é overhead. É o que torna o sistema confiável o suficiente para depender.
A Terraris.ai projeta e implanta sistemas RAG em produção com harnesses de avaliação incorporados desde o primeiro dia. Explore como abordamos a implementação de RAG empresarial.