Avaliações: dos experimentos com IA à produção com confiança

• Embora os modelos de base tenham melhorado, a verdadeira mudança que permite usá-los em produção com confiança vem de práticas de avaliação rigorosas.

• Avaliações bem elaboradas ajudam gerentes de produto, líderes de governança de IA e CTOs a implantar agentes de IA com segurança e em escala, transformando a IA de um recurso experimental e isolado em vantagem competitiva.

• Essa confiança vem da avaliação do comportamento dos agentes de IA diante de consultas reais de usuários, casos extremos e cenários específicos do domínio que reflitam o contexto real da empresa, e não de um benchmark público que afirme que “este modelo é o melhor”.

• O objetivo é justificar essa confiança por meio de resultados mensuráveis. Ter sucesso significa definir "bom" em termos concretos e mensuráveis, alinhados às necessidades da empresa e à sua tolerância a riscos — seja em precisão factual, tom adequado, velocidade ou eficiência de custos.

• Ao incorporar a avaliação em todo o sistema — instrumentação, registros, testes A/B e mecanismos de proteção — e equilibrar rigor e eficiência, as equipes conseguem implantar com mais rapidez e robustez.

A maioria das empresas não vê problema em seus funcionários experimentarem o ChatGPT ou o Gemini. Mas o uso de LLMs em fluxos de trabalho ou ambientes de alto risco ainda é menos comum.

As razões muitas vezes foram justificadas: a qualidade era inconsistente, e o risco de alucinações ou comportamentos indesejáveis superava os possíveis benefícios da tecnologia.

Esse equilíbrio entre risco e benefício mudou significativamente no último ano. Embora parte disso possa ser atribuída à melhoria do desempenho dos modelos de base, muito se deve ao rigor crescente em torno das avaliações, ou “evals”. As avaliações dão a nós e a nossos clientes confiança para implantar agentes em larga escala e voltados ao público em questão de semanas.

Este guia explica os fundamentos das avaliações e como elaborá-las, implementá-las e operá-las em casos de uso em produção.

O objetivo da avaliação não é encontrar um modelo perfeito, mas gerar confiança fundamentada de que ele se comporta de acordo com as necessidades da empresa, as expectativas dos usuários e a tolerância a riscos da organização.

Na base de qualquer estratégia de avaliação há uma pergunta simples: O que significa ser “bom”? A resposta deve ser específica. Para uma organização, ser “bom” pode significar precisão factual dentro de tolerâncias rigorosas; para outra, pode significar priorizar velocidade, eficiência de custos ou um tom de voz marcante. Cada restrição aplicável, dos dados que podem ser usados às obrigações regulatórias, molda essa definição.

Acima de tudo, ser 'bom' precisa envolver componentes que possam ser medidos de fato. Se sucesso significa oferecer orientação financeira útil, essa utilidade precisa ser expressa por atributos: exatidão factual, ressalvas adequadas, raciocínio personalizado e limites seguros. Depois de definir “bom” em termos mensuráveis, a próxima pergunta é como analisar e interpretar os resultados. É agir com base nesses resultados que transforma a avaliação em um método, em vez de uma simples série de julgamentos.

Todo pipeline de avaliação se apoia em três pilares interligados:

1. Entradas/benchmarks: exemplos representativos do mundo real para avaliar o desempenho geral e conjuntos de dados internos selecionados para testar a viabilidade no domínio.

2. Comportamento do modelo: como o modelo é acionado — geração aumentada por recuperação, sumarização, recuperação estruturada de informações e uso de ferramentas.

3. Métricas: como medir e interpretar o desempenho.

As entradas devem representar o mundo que seu sistema encontrará. Os insights mais relevantes vêm de exemplos reais: consultas de clientes, cenários financeiros ou casos específicos do setor. Somente ao testar esses exemplos é possível saber se o modelo realmente compreende as nuances exigidas pelos usuários e atende à necessidade da empresa.

O comportamento do modelo — como recebe prompts, como a recuperação ou o uso de ferramentas é orquestrado e como o contexto é fornecido — importa tanto quanto o próprio modelo. Dois modelos idênticos podem se comportar de maneiras muito diferentes, dependendo de como são implantados. Portanto, essa camada deve fazer parte do projeto de avaliação.

Por fim, temos as métricas. Números isolados raramente contam toda a história, mas métricas bem escolhidas tornam o comportamento do sistema compreensível. Latência, precisão, segurança, coerência, viés, custo e satisfação do usuário formam, em conjunto, uma visão multidimensional de um sistema em produção. O segredo está em escolher métricas alinhadas aos KPIs do projeto ou da empresa e que evidenciem as qualidades mais importantes para os usuários. Métricas mais simples costumam ser mais precisas e econômicas, enquanto escolhas inadequadas podem levar as equipes a conclusões erradas. Veja como pensar na escolha de métricas:

Exemplos de boas escolhas de métricas:

• Chatbot de atendimento ao cliente: taxa de resolução no primeiro contato — o problema do usuário foi resolvido sem escalonamento? —, tempo médio de atendimento, índice de satisfação do usuário e taxa de encaminhamento para agentes humanos.

• Ferramenta de pesquisa financeira: precisão das citações — percentual de alegações com fontes adequadas —, precisão factual validada em relação à referência correta, relevância da recuperação — encontrou os documentos certos? — e coerência do raciocínio avaliada por especialistas do domínio.

• Assistente de geração de código: correção sintática, taxa de aprovação nos testes, número de vulnerabilidades de segurança e tempo até chegar a uma solução funcional.

Exemplos de escolhas ruins de métricas:

• Usar apenas o tamanho da resposta como indicador de qualidade — maior ≠ melhor.

• Medir a velocidade sem considerar as concessões em termos de precisão.

• Acompanhar os índices de confiança do modelo sem validá-los em relação à correção real.

• Depender apenas da perplexidade interna do modelo, sem validação voltada ao usuário.

Armadilhas comuns de métricas que devem ser evitadas:

• Métricas conflitantes: otimizar simultaneamente velocidade e abrangência sem reconhecer a concessão necessária entre elas.

• Sobreajuste aos benchmarks: atingir 95% no conjunto de testes, mas falhar em produção porque os usuários reais se comportam de outra forma.

Para um cliente do setor de serviços financeiros altamente regulamentado, a precisão da solução de pesquisa aprofundada era fundamental. Criamos conjuntos de dados de perguntas e respostas elaborados por especialistas e os combinamos a conjuntos gerados por ferramentas. Assim, pudemos avaliar a precisão, a capacidade do sistema de selecionar as ferramentas certas e de recuperar as informações corretas, obtendo uma visão equilibrada da precisão e da qualidade do raciocínio. O essencial foi medir várias dimensões: precisão factual — validação por especialistas —, qualidade da recuperação — precisão e revocação de documentos relevantes — e coerência do raciocínio — avaliação estruturada do fluxo lógico.

Quando usar LLM como avaliador para analisar aspectos subjetivos da qualidade

A abordagem de LLM como avaliador usa um segundo modelo de IA para fazer a avaliação, substituindo a análise humana por uma pontuação de qualidade automatizada e escalável. É comum usar LLM como avaliador de forma inadequada quando métricas mais simples já oferecem a precisão necessária. Essa abordagem pode ser útil quando verificações determinísticas não captam a qualidade, como em métricas semânticas — utilidade, fundamentação, qualidade do raciocínio, tom ou interpretação de políticas — e quando não é possível usar pontuação determinística. Talvez seja necessário obter feedback escalável para muitas variantes de prompt e modelo, além de definir uma rubrica clara e um schema de saída estruturada. Para aplicar essa abordagem com eficácia, siga estas etapas:

• Defina explicitamente as dimensões da rubrica: correção, fundamentação, conformidade com políticas, aplicabilidade e tom.

• Use saídas estruturadas — schema JSON — nas respostas do avaliador.

• Registre tanto as pontuações binárias dos critérios de aprovação quanto o texto de diagnóstico para analisar falhas.

• Calibre as saídas do avaliador usando amostras rotuladas por humanos a cada ciclo de lançamento.

• Use dois avaliadores ou verificações periódicas de consenso em domínios de alto risco.

• Acompanhe ao longo do tempo os desvios do avaliador e a taxa de divergência.

Um conjunto de dados de benchmark é uma coleção fixa e selecionada de exemplos de teste com respostas conhecidas, usada para avaliar modelos de forma consistente e comparar resultados entre versões com imparcialidade. Geralmente, inclui entradas — como consultas de usuários —, saídas esperadas ou avaliações de referência e critérios ou rótulos de avaliação para atribuir pontuações. Os testes de benchmarks públicos são usados para comparar o desempenho de modelos de ponta e podem servir como referência inicial ao projetar o sistema e decidir quais modelos são bons candidatos.

No entanto, em seu próprio sistema, você não pode usar esses benchmarks como indicadores do desempenho no contexto da empresa, pois eles apresentam problemas conhecidos:

• Contaminação: os modelos podem ter sido treinados com os dados do benchmark; avaliá-los com o mesmo conjunto de dados é como corrigir uma prova com o gabarito à mão.

• Saturação: todos os principais modelos já atingem pontuações máximas. Assim, a melhoria ou degradação do desempenho fica limitada a poucos pontos percentuais e muitas vezes dentro da variabilidade natural dos resultados.

• Escopo restrito: os dados dos benchmarks não refletem suas tarefas reais, pois são altamente selecionados e tratados. Alguns são até gerados por LLMs e não refletem a complexidade nem os casos extremos presentes nos seus dados, como erros de digitação, construções incomuns e imagens com ruído.

Um estudante pede que a aplicação ajude a resolver problemas matemáticos contextualizados.

Exemplo de benchmark público que pode ser usado: GSM8K — raciocínio matemático do ensino fundamental.

• Conjunto mais difícil opcional: MATH.

Por que esse benchmark é útil:

• Permite comparar rapidamente qual modelo é melhor em raciocínio matemático geral.

• É um bom primeiro filtro antes de investir em avaliações completas do produto.

Por que você ainda precisa do seu próprio conjunto de dados:

Sua aplicação tem requisitos que o GSM8K não testa:

• A terminologia e a ordem dos tópicos do seu currículo.

• O estilo de explicação adequado à faixa etária.

• Como lidar com perguntas ambíguas ou repletas de erros de digitação.

• Regras de política — por exemplo, quando dar dicas em vez de respostas completas.

Uma validação eficaz depende da criação de benchmarks de avaliação específicos para a aplicação. Esses conjuntos de dados devem se basear em interações reais, casos extremos típicos e modos de falha plausíveis. Essa pode ser uma tarefa difícil ao implementar um novo produto ou processo. No entanto, na maioria dos casos, é possível coletar dados de um produto existente ou começar o quanto antes, inclusive durante a fase inicial de testes. Após o desenvolvimento da aplicação, esses benchmarks devem evoluir junto com o produto, tornando-se mais completos e representativos ao longo do tempo.

A conexão entre o benchmark específico da aplicação e a seleção do modelo é essencial. O benchmark revela não apenas se uma solução funciona, mas também qual combinação de tamanho de modelo e técnicas de pós-treinamento oferece o desempenho necessário com a melhor relação custo-benefício. As melhorias mais poderosas para modelos pré-treinados — o “PT” de ChatGPT — não vêm de um novo treinamento, mas de métodos de "pós-treinamento".

Esses métodos se concentram em definir a quais informações o modelo tem acesso, como elas são estruturadas e como o modelo é orientado e orquestrado durante a inferência. Técnicas de pós-treinamento, como:

• Prompts de cadeia de pensamento e alocação dinâmica de recursos computacionais — pensar mais em problemas mais difíceis.

• Autoconsistência, em que várias saídas são geradas e a melhor é selecionada.

• Construção e orquestração de contexto, como geração aumentada por recuperação — RAG —, exemplos few-shot e fluxos de trabalho com agentes de IA.

• Uso de ferramentas e acesso a conhecimento externo, permitindo que o modelo atue além de seus parâmetros internos.

• Estratégias de representação e armazenamento de conhecimento, elaboradas para recuperar informações e raciocinar com eficiência sobre dados estruturados e não estruturados.

Embora essas técnicas de pós-treinamento possam melhorar significativamente o desempenho do sistema, elas também exigem concessões. Cada camada adicional de orquestração, recuperação ou raciocínio aumenta a complexidade do sistema, o tempo de inferência e o custo operacional. Quando aplicada com cuidado, porém, a combinação certa de técnicas de pós-treinamento muitas vezes permite usar modelos menores, mais rápidos e mais econômicos sem deixar de atender aos requisitos de desempenho. Em vez de aumentar o tamanho do modelo, o desempenho é alcançado por meio de um projeto de sistema melhor.

Encontrar esse equilíbrio é algo inerentemente específico de cada aplicação e deve se basear em avaliações próprias para determinar a combinação ideal de técnicas. Elas permitem identificar o ponto em que a orquestração adicional deixa de gerar ganhos relevantes, ajudando as equipes a escolher o nível mínimo de complexidade de pós-treinamento necessário para alcançar o desempenho desejado.

Uma solução de IA precisa ser considerada como um sistema completo: bancos de dados, APIs, interfaces de usuário, camadas de orquestração, infraestrutura de monitoramento e muito mais. Portanto, a avaliação deve abranger toda a pilha tecnológica. Monitore as principais partes do sistema para manter a visibilidade sobre possíveis problemas e avançar de forma responsável.

Monitorar as principais partes do sistema significa:

• Instrumentar os pipelines para produzir resultados mensuráveis.

• Registrar os experimentos para observar o efeito de cada ajuste.

• Usar comparações A/B simples antes de implantar grandes mudanças para testar possíveis regressões.

A iteração orientada por dados encurta o caminho do protótipo à produção, sem pontos cegos. O registro e o monitoramento também são importantes para entender o uso da aplicação no mundo real. Veja um exemplo de como garantir a observabilidade:

• Etapa 1: a solicitação do usuário entra com request_id, user_segment e intent.

• Etapa 2: o rastreamento registra a versão do modelo, a versão do prompt, os documentos recuperados e as chamadas de ferramentas.

• Etapa 3: o LLM avaliador pontua a resposta — correção, fundamentação e policy_risk.

• Etapa 4: o mecanismo de regras avalia os limites.

• Etapa 5: se um limite for violado, um alerta é acionado e a solicitação é encaminhada à alternativa de contingência ou à análise humana.

• Etapa 6: a falha é adicionada à fila de triagem e depois à lista de pendências do benchmark.

Usuários reais raramente se comportam exatamente como os responsáveis pelo projeto esperam. Alguns interpretarão as instruções de forma errada. Outros testarão deliberadamente os pontos fracos. Esses casos extremos não são anomalias, mas sinais valiosos. Um pipeline de avaliação bem implementado os registra, analisa e incorpora a testes futuros. Iterar rapidamente e sem pontos cegos só é possível quando a avaliação é integrada ao sistema, e não acrescentada após o desenvolvimento.

Recomendamos incorporar mecanismos de proteção e monitoramento desde o primeiro dia:

• Acompanhe regularmente as métricas e regressões do modelo usando o benchmark específico da aplicação.

• Registre e analise casos extremos ou entradas adversariais — e adicione-os ao conjunto de dados do benchmark específico da aplicação.

• Garanta que essas métricas de avaliação estejam alinhadas aos seus principais KPIs.

• Questione regularmente seu conjunto de dados e benchmark para garantir que você não esteja ignorando novos riscos nem sujeito a vieses.

• Implemente alertas automáticos para a degradação de métricas — por exemplo, se a precisão cair abaixo de 85%, acione uma análise.

• Mantenha um processo de análise humana para decisões de alto risco, como aconselhamento jurídico, orientação médica e transações financeiras.

Cada execução de um benchmark consome recursos computacionais e energia. Cada experimento redundante aumenta o custo. Uma avaliação responsável deve equilibrar rigor e eficiência.

Algumas medidas práticas podem evitar que o consumo de energia e os custos saiam do controle:

• Use modelos menores sempre que possível: execute os experimentos iniciais em modelos mais econômicos e aumente a escala somente depois de validar a abordagem.

• Armazene prompts e chamadas de API em cache.

• Adote um agendamento atento ao consumo de energia — processamento em lote, instâncias spot e prioridade flexível.

• Acompanhe o uso de recursos computacionais junto com o desempenho.

Da mesma forma, acompanhe as novas regulamentações de IA. Mesmo quando não há uma lei específica, estruturas existentes e medidas necessárias continuam sendo aplicáveis, como:

Proteção de dados:

• Garanta que os conjuntos de dados dos benchmarks não contenham informações de identificação pessoal sem o devido consentimento.

• Implemente políticas de retenção de dados para consultas registradas.

• Ofereça mecanismos para solicitações de exclusão de dados.

Igualdade e viés:

• Teste o desempenho em diferentes grupos demográficos.

• Inclua representatividade diversa na criação do benchmark.

Direitos humanos e transparência:

• Documente claramente para os usuários as limitações do modelo.

• Explique as decisões de alto risco.

• Permita a supervisão humana em aplicações críticas.

A avaliação não é um evento pontual, mas um sistema em evolução. Em um campo que avança rapidamente, sua vantagem está na capacidade de testar, aprender e se adaptar com agilidade para implantar modelos e novas soluções com mais eficácia.

Ao incorporar a avaliação como atividade central de engenharia e gestão de produtos, as equipes podem inovar com mais rapidez e segurança. Comece definindo o que significa ser bom no contexto da sua aplicação de IA, configure uma plataforma de avaliação e aprimore-a até ter um benchmark específico da aplicação que, a cada iteração, dê confiança de que ela está pronta para produção.