Avaliação de LLM em produção: como medir o que importa

Seu agente passou em todos os testes que você rodou no notebook. Foi pra produção. Duas semanas depois, o time de suporte está reclamando que as respostas estão estranhas, o cliente abriu chamado falando que a recomendação não fez sentido e ninguém consegue explicar exatamente o que mudou. A pergunta que todo mundo evita aparecer no canal é a mesma: como a gente sabe que esse modelo está funcionando?

Pois é. Essa cena é mais comum do que se admite em reunião.

Trabalho com LLMs em produção há um tempo, em contextos onde a saída do modelo chega direto no usuário final, e venho vendo o mesmo padrão se repetir em times muito diferentes. O problema raramente é o modelo. Quase sempre é a camada de avaliação que não existe. Demos passam, produção quebra, e a falha foi não medir o que importava antes do deploy.

Esse artigo vai te mostrar como estruturar avaliação de LLM em produção de um jeito que sobreviva ao primeiro contato com dados reais. Vou cobrir o que conta como avaliar, quais métricas formam a base, quando automatizar e quando deixar humano no loop, e quais sinais indicam que sua avaliação está mentindo pra você. Tudo do ponto de vista de quem precisa que o modelo entregue valor, não só pareça entregar.

O que significa avaliar um LLM em produção

Avaliar um LLM em produção é manter uma camada contínua de medição que responde a uma pergunta só: a saída do modelo está fazendo o que precisa fazer pro negócio? Não é rodar benchmark uma vez antes do deploy. Não é olhar accuracy em dataset acadêmico. É um sistema vivo que pega amostras reais, aplica critérios definidos antes e devolve um sinal interpretável pro time.

Essa camada tem três partes que precisam coexistir: critério de qualidade definido por escrito, instrumentação que coleta cada saída relevante e mecanismo de revisão que combina checagem automática com revisão humana em casos específicos.

Sem essas três partes coexistindo, você não tem avaliação. Você tem esperança organizada.

Quando você precisa de avaliação de LLM em produção

Nem todo uso de LLM precisa do mesmo nível de avaliação. Mas tem cenários onde a ausência da camada se paga em incidente, churn ou multa.

Saída do modelo é entrega final ao usuário

Quando o output chega direto no produto, sem revisão humana intermediária, você precisa de avaliação contínua. Chatbot de atendimento, resumo automático, recomendação personalizada. O usuário consome o que o modelo gerou, então a degradação do modelo é degradação do produto.

Custo por request é alto e cresce com volume

Em volume relevante, alguns pontos percentuais de qualidade decidem se vale Sonnet ou Haiku, GPT-4o ou variante mais barata, modelo grande ou ajuste fino. Sem métrica, essa decisão vira opinião. Com métrica, vira projeção. Vale acompanhar de perto o custo e latência de LLMs em paralelo com qualidade, porque os três se movem juntos.

Regulamento ou contrato exige rastreabilidade

Em setor regulado, você precisa provar que o modelo passou por avaliação documentada antes do deploy e que continua sendo monitorado. Não é nice-to-have. É requisito mínimo de compliance em vários contextos hoje.

Como funciona uma camada de avaliação de LLM em produção na prática

Aqui vai a estrutura que tem se mostrado robusta em times que entregam produto sério com LLM.

Métrica automática (heurística + LLM-as-judge)

A primeira linha de defesa é avaliação automática. Mistura regras simples (tamanho da resposta, presença de campo obrigatório, conformidade com formato) com avaliação por outro LLM atuando como juiz. O juiz recebe a saída e um critério escrito (“essa resposta é factualmente consistente com o contexto fornecido?”, “a recomendação respeita as restrições do usuário?”) e devolve um score.

A vantagem é cobertura. Você consegue rodar essa avaliação em uma fração das requisições, todo dia. A desvantagem é que LLM-as-judge tem seus vieses e precisa ser calibrado, ou você acaba confiando num juiz que erra no mesmo lugar que o modelo avaliado.

Métrica humana (sample manual)

Em paralelo, você precisa de revisão humana de uma fatia pequena mas constante. Estatísticamente significativa o suficiente pra calibrar o juiz automático e pegar padrões de falha que a métrica automática não captura. Funciona assim: amostra aleatória semanal, revisada por alguém do time que entende o domínio, com rubrica clara do que conta como bom e o que conta como ruim.

Métrica de negócio (a que importa de verdade)

No final das contas, a única métrica que decide se o LLM está funcionando é a de negócio. Taxa de resolução no suporte, conversão depois da recomendação, tempo médio de tratamento, NPS. Métrica técnica precisa ter relação clara com a de negócio, ou você está otimizando o errado.

Esse princípio fica claro quando você lê sobre como avaliar respostas de LLM em produção sem depender de achismo, que cobre a calibração entre métrica técnica e métrica de negócio em mais detalhe.

Métrica automática vs métrica humana (qual escolher)

Spoiler: você precisa das duas, mas em proporções diferentes dependendo do estágio.

Quando o produto é novo, métrica humana puxa mais peso. Você ainda não conhece os modos de falha, então amostra revisada por humano descobre padrões. Conforme o produto amadurece, os padrões se cristalizam em rubricas, as rubricas viram critérios pro juiz automático, e a métrica humana diminui em volume mas continua existindo pra calibrar a automática.

Olha, na minha experiência, time que tenta automatizar tudo desde o começo acaba criando juiz que premia respostas com a mesma falha sistemática que o modelo avaliado tem. E time que fica só com humano não consegue rodar avaliação em volume relevante. O balanço se ajusta com o tempo, mas começa com mais peso humano.

O que esperar quando começar a avaliar

Ajustar expectativa antes de montar a camada economiza frustração e retrabalho.

• Boa parte das falhas vai estar nos dados upstream, não no modelo: input ruim gera output ruim. Avaliação vai expor isso primeiro.
• O juiz automático precisa de calibração inicial: rodar com humano em paralelo nas primeiras semanas é obrigatório, não opcional.
• Rubrica vai mudar várias vezes: a primeira versão sempre tem ambiguidade. Espere reescrever três ou quatro vezes nos primeiros meses.
• Métrica de negócio reage mais devagar que técnica: você vê drop em métrica técnica em horas, em negócio em semanas. Não deixe a defasagem te confundir.
• Custo da camada de avaliação é real: rodar juiz LLM em 10% das requisições adiciona custo mensurável. Vale, mas precisa entrar no orçamento.

Sinais de que sua avaliação está mentindo pra você

Esse é o cenário que mais machuca: você tem dashboard, número subiu, mas o cliente reclama. Os sinais aparecem antes de virar incidente.

O primeiro sinal é divergência entre métrica técnica e relato do usuário. Quando o juiz automático diz 95% e o suporte recebe reclamação crescente, a métrica está medindo o que é fácil medir, não o que importa.

O segundo é estabilidade suspeita. Métrica que não oscila nada com mudança real no input quase sempre está medindo algo trivial. Métrica saudável reflete variação real, com tendência clara mas com ruído natural.

O terceiro é falta de correlação com métrica de negócio. Se a métrica técnica sobe e a de negócio fica plana, alguma das duas está mal definida.

O quarto, e o mais traiçoeiro, é viés sistemático no juiz. Se o juiz automático foi treinado ou prompted com base nas mesmas amostras que ensinaram o modelo principal, ele tende a aprovar erros que o modelo também comete. Vale dizer: a forma mais simples de detectar é amostragem cega revisada por humano que não participou do design da rubrica.

O impacto de não ter avaliação de LLM em produção

Sem essa camada, o time vive em modo reativo. Descobre o problema porque cliente reclamou. Tenta reproduzir, não consegue. Faz mudança baseada em hipótese, não em medida. E daí o ciclo recomeça.

O custo aparece em três lugares. Primeiro, em incidente: cada drop não detectado de qualidade tem custo de suporte, churn e retrabalho. Segundo, em decisão errada: sem métrica, escolha de modelo, prompt e parâmetro vira opinião do mais barulhento. Terceiro, em paralisia: sem confiança no que está rodando, o time fica com medo de mexer, e o sistema vira artefato congelado.

Nenhum desses três custos aparece no dashboard. Aparecem em pesquisa de satisfação, em ticket recorrente e em reunião onde ninguém propõe nada novo.

Quando você já tem a camada de avaliação rodando, faz muito mais sentido pensar em estruturar experimentos A/B com IA em cima dela, porque o ponto de comparação vira sólido em vez de impressão.

Dúvidas comuns sobre avaliação de LLM em produção

Preciso ter dataset de referência pra começar?

Não pra começar, sim pra evoluir. O primeiro passo é definir rubrica e revisar amostras. À medida que você revisa, vai acumulando o dataset com saída + score humano. Em três meses, você tem material pra calibrar juiz automático e fazer regressão antes de mudar prompt ou modelo.

Dá pra confiar em LLM-as-judge?

Em parte. LLM-as-judge é útil pra cobertura e velocidade, mas tem viés conhecido e precisa de calibração contínua. A regra que tenho usado é: nunca confie no juiz sozinho, sempre mantenha amostra humana em paralelo, e cheque divergência entre juiz e humano periodicamente. Quando a divergência cresce, é hora de revisar a rubrica do juiz.

Quantos exemplos preciso ter pra começar a avaliar?

Pra rubrica humana, 50 exemplos bem revisados já dão sinal direcional. Pra calibrar juiz automático, vale ter pelo menos 200 com score humano. Pra decidir mudança importante de modelo, mire em 500+ com cobertura de casos representativos, incluindo edge cases que machucam quando saem errados.

Avaliação automática substitui revisão humana?

Não. Reduz volume da humana, ajuda priorização, mas não substitui. A humana é o que mantém o juiz automático honesto. Quando você tira a humana, em algum momento o juiz começa a errar de um jeito que ninguém percebe.

Por onde começo se hoje não tenho nada?

Começa pela rubrica. Escreve, com o time de produto e domínio, o que conta como saída boa e o que conta como saída ruim, com exemplos concretos dos dois lados. Depois define amostragem. Depois roda revisão humana por um mês. Só depois disso entra juiz automático. A ordem importa: rubrica primeiro, métrica depois.

Conclusão e próximo passo

Avaliação de LLM em produção é o que separa modelo que entrega valor de modelo que parece entregar. A combinação que funciona tem três peças: rubrica clara de qualidade, métrica automática com LLM-as-judge calibrado e amostragem humana constante. Métrica de negócio fecha o circuito, validando que o que você mede importa de verdade.

Sem essas peças, você vive em modo reativo, descobrindo problema pelo canal de suporte. Com elas, você consegue medir antes do incidente, decidir com base em dado e mudar modelo, prompt ou pipeline com confiança em vez de torcida.

Se você quer começar a estruturar essa camada na próxima sprint, o próximo passo é:

• Escrever uma rubrica de qualidade em uma página, com cinco a dez exemplos do que é bom e do que é ruim, validada com produto e domínio.
• Definir amostragem mínima (entre 20 e 50 requisições por semana) pra revisão humana e começar a rodar antes de pensar em qualquer juiz automático.
• Definir uma métrica de negócio que se conecte com a rubrica e acompanhar ela junto com a métrica técnica desde a primeira semana.

Pra aprofundar, vale ler a documentação oficial de avaliação de modelos da Anthropic, que cobre padrões de design de eval e armadilhas comuns. E dentro do blog, vale entender também como funciona a janela de contexto de LLMs, porque grande parte das falhas de qualidade em produção têm raiz em uso ineficiente de contexto, não em capacidade do modelo.