For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegação principal
Theme

Boas práticas de avaliação

Conheça boas práticas para criar avaliações que testem o desempenho dos modelos em ambientes de produção.

Os resultados da IA generativa variam. Às vezes, um modelo produz saídas diferentes para a mesma entrada. Por isso, os métodos tradicionais de teste de software são insuficientes para arquiteturas de IA. As avaliações (evals) permitem testar seu sistema de IA mesmo com essa variabilidade.

Este guia apresenta orientações gerais para criar avaliações. Para começar a usar a API Evals, veja como avaliar o desempenho dos modelos.

A OpenAI está descontinuando a plataforma Evals. O conteúdo das avaliações existentes continuará disponível durante o período de transição. Em 31 de outubro de 2026, a plataforma Evals passará para o modo somente leitura para quem já a utiliza. O encerramento está previsto para 30 de novembro de 2026. Consulte o cronograma atualizado na página de descontinuações.

O que são avaliações?

Avaliações são testes estruturados que medem o desempenho de um modelo. Elas ajudam a garantir exatidão, desempenho e confiabilidade, mesmo com o comportamento não determinístico dos sistemas de IA. Também são uma das poucas maneiras de melhorar o desempenho de um aplicativo baseado em LLM (por meio de ajuste fino).

Tipos de avaliação

O termo “evals” pode se referir a:

  • Benchmarks usados no setor para comparar modelos testados isoladamente, como o MMLU e os benchmarks listados no ranking da Hugging Face
  • Métricas numéricas padronizadas, como ROUGE e BERTScore, que você pode usar ao criar avaliações para seu caso de uso
  • Testes específicos que você implementa para medir o desempenho do seu aplicativo baseado em LLM

Este guia aborda o terceiro tipo: como criar suas próprias avaliações.

Como interpretar avaliações

É comum encontrar pontuações entre 0 e 1. Mas a pontuação é apenas parte da avaliação. Combine métricas com julgamento humano para ter certeza de que está respondendo às perguntas certas.

Dicas para avaliações


  • Adote o desenvolvimento orientado por avaliações: comece a avaliar cedo e repita as avaliações com frequência. Escreva testes com escopo delimitado em cada etapa.
  • Crie avaliações específicas para cada tarefa: os testes devem refletir a capacidade do modelo diante da distribuição dos dados observada no uso real.
  • Registre tudo: mantenha logs durante o desenvolvimento para encontrar bons casos de avaliação nesses registros.
  • Automatize quando possível: estruture as avaliações de modo que seja possível atribuir pontuações automaticamente.
  • Avalie ao longo de todo o percurso: a avaliação é um processo contínuo.
  • Mantenha a concordância com as avaliações humanas: use o feedback de pessoas para calibrar a pontuação automática.

Antipadrões


  • Métricas genéricas demais: usar exclusivamente métricas acadêmicas, como perplexidade ou pontuação BLEU.
  • Avaliações enviesadas: criar conjuntos de dados de avaliação que não reproduzam fielmente os padrões de tráfego em produção.
  • Avaliações baseadas em impressões: adotar “parece que está funcionando” como estratégia de avaliação ou esperar até o lançamento para implementar os primeiros testes.
  • Desconsideração do feedback humano: deixar de calibrar as métricas automatizadas com base em avaliações humanas.

Planeje seu processo de avaliação

Um fluxo de avaliação tem algumas etapas importantes:

  1. Defina o objetivo da avaliação. Quais são os critérios de sucesso?
  2. Reúna os dados. Quais dados ajudarão você a avaliar se atingiu o objetivo? Considere dados de avaliação sintéticos, específicos do domínio, comprados ou selecionados por pessoas, além de dados de produção e dados históricos.
  3. Defina as métricas de avaliação. Como você vai verificar se os critérios de sucesso foram atendidos?
  4. Execute e compare as avaliações. A cada rodada, use os resultados para melhorar o desempenho do modelo na tarefa ou no sistema.
  5. Avalie continuamente. Configure a avaliação contínua (CE) para executar testes a cada alteração, monitore seu aplicativo para identificar novos casos de comportamento não determinístico e amplie o conjunto de avaliação ao longo do tempo.

Veja alguns exemplos.

Exemplo: resumo de transcrições

Para testar a capacidade do seu aplicativo baseado em LLM de resumir transcrições, você pode estruturar a avaliação assim:

  1. Defina o objetivo da avaliação
    O modelo deve produzir resumos comparáveis aos de referência em relevância e exatidão.
  2. Reúna os dados
    Para definir o que é um “bom” resumo, combine dados de produção (obtidos a partir do feedback dos usuários sobre os resumos gerados) com conjuntos de dados criados por especialistas da área (redatores).
  3. Defina as métricas de avaliação
    Em um conjunto de 1.000 pares de transcrição e resumo de referência reservado para testes, a implementação deve obter pelo menos 0,40 na métrica ROUGE-L e pelo menos 80% na pontuação de coerência medida pelo G-Eval.
  4. Execute e compare as avaliações
    Use a API Evals para criar e executar avaliações no painel da OpenAI.
  5. Avalie continuamente
    Configure a avaliação contínua (CE) para executar testes a cada alteração, monitore seu aplicativo para identificar novos casos de comportamento não determinístico e amplie o conjunto de avaliação ao longo do tempo.

Os LLMs se saem melhor ao distinguir entre opções. Por isso, dê preferência a tarefas como comparação de pares, classificação ou atribuição de notas com base em critérios específicos, em vez de pedir que o modelo gere uma resposta aberta. Métodos que aproveitam essa capacidade de comparação tornam mais confiáveis tanto as avaliações das saídas de um LLM quanto as comparações entre modelos.

Exemplo: perguntas e respostas com base em documentos

Para testar a capacidade do seu aplicativo baseado em LLM de responder a perguntas com base em documentos, você pode estruturar a avaliação assim:

  1. Defina o objetivo da avaliação
    O modelo deve responder com precisão, recuperar o contexto necessário para raciocinar sobre os prompts dos usuários e dar uma resposta que atenda à necessidade de quem fez a pergunta.
  2. Reúna os dados
    Combine dados de produção (obtidos a partir da satisfação dos usuários com as respostas recebidas), respostas corretas predefinidas para perguntas elaboradas por especialistas da área e dados históricos dos logs.
  3. Defina as métricas de avaliação
    Exija recall de contexto de pelo menos 0,85, precisão de contexto acima de 0,7 e pelo menos 70% de respostas avaliadas positivamente.
  4. Execute e compare as avaliações
    Use a API Evals para criar e executar avaliações no painel da OpenAI.
  5. Avalie continuamente
    Configure a avaliação contínua (CE) para executar testes a cada alteração, monitore seu aplicativo para identificar novos casos de comportamento não determinístico e amplie o conjunto de avaliação ao longo do tempo.

Ao criar um conjunto de dados de avaliação, você pode usar o modelo

gpt-6-astra

para reunir exemplos de avaliação e casos extremos. Considere usá-lo para gerar dados de teste variados que cubram diferentes cenários. Inclua casos típicos, extremos e adversariais. Recorra a anotadores especializados na área.

Identifique onde você precisa de avaliações

A complexidade do sistema aumenta à medida que você passa de arquiteturas básicas para outras mais complexas. Veja quatro padrões comuns de arquitetura:

Nas descrições a seguir, identifique em quais pontos cada arquitetura introduz comportamento não determinístico no seu sistema. São esses os pontos em que vale a pena implementar avaliações.

Interações de um único turno com o modelo

Nesse tipo de arquitetura, o usuário fornece uma entrada ao modelo. O modelo processa essa entrada junto com os prompts que o desenvolvedor tiver fornecido e gera a saída correspondente.

Exemplo

Considere uma loja on-line. O prompt do sistema instrui o modelo a classificar a pergunta do cliente em uma das seguintes categorias:

  • order_status
  • return_policy
  • technical_issue
  • cancel_order
  • other

Para que a experiência do usuário seja consistente e eficiente, o modelo deve retornar apenas o rótulo que corresponde à intenção do usuário. Suponha que o cliente pergunte: “Qual é o status do meu pedido?”

Fonte de comportamento não determinísticoO que avaliarExemplos de perguntas de avaliação
Entradas fornecidas pelo desenvolvedor e pelo usuário

Cumprimento das instruções: o modelo entende corretamente as instruções recebidas e age de acordo com elas?



Cumprimento das instruções: o modelo prioriza o prompt do sistema quando o prompt do usuário entra em conflito com ele?

O modelo mantém o foco na triagem ou a pergunta do usuário o desvia da tarefa?

Saídas geradas pelo modelo

Correção funcional: as saídas do modelo são corretas, relevantes e completas o suficiente para realizar a tarefa ou atingir o objetivo previsto?

A intenção identificada pelo modelo corresponde à intenção esperada?

Arquiteturas de fluxo de trabalho

Para resolver problemas mais complexos, você provavelmente passará de uma interação de um único turno com o modelo para um fluxo de trabalho com várias etapas que encadeia chamadas ao modelo. Os fluxos de trabalho não introduzem novas fontes de comportamento não determinístico, mas envolvem várias interações com o modelo que você pode avaliar isoladamente.

Exemplo

Retome o exemplo do cliente que pergunta sobre o status do pedido. Uma arquitetura de fluxo de trabalho faz a triagem da solicitação e a encaminha para um processo em etapas:

  1. Extrair o ID do pedido
  2. Consultar os detalhes do pedido
  3. Enviar os detalhes ao modelo para que ele formule a resposta final

Cada etapa tem um prompt do sistema próprio que o modelo deve seguir para apresentar todos os dados obtidos em uma resposta fácil de entender.

Fonte de comportamento não determinísticoO que avaliarExemplos de perguntas de avaliação
Entradas fornecidas pelo desenvolvedor e pelo usuário

Cumprimento das instruções: o modelo entende corretamente as instruções recebidas e age de acordo com elas?



Cumprimento das instruções: o modelo prioriza o prompt do sistema quando o prompt do usuário entra em conflito com ele?

O modelo mantém o foco na triagem ou a pergunta do usuário o desvia da tarefa?



O modelo segue as instruções para tentar extrair o ID do pedido?



A resposta final inclui o status do pedido, a data prevista de entrega e o código de rastreamento?

Saídas geradas pelo modelo

Correção funcional: as saídas do modelo são corretas, relevantes e completas o suficiente para realizar a tarefa ou atingir o objetivo previsto?

A intenção identificada pelo modelo corresponde à intenção esperada?



O status do pedido, a data prevista de entrega e o código de rastreamento informados na resposta final estão corretos?

Arquiteturas com um único agente

Ao contrário dos fluxos de trabalho, os agentes resolvem problemas não estruturados que exigem flexibilidade na tomada de decisões. Um agente recebe instruções e um conjunto de ferramentas e escolhe dinamicamente qual delas usar. Essa escolha introduz uma nova fonte de comportamento não determinístico.

Ferramentas são trechos de código que o desenvolvedor define e que o modelo pode executar. Podem ser pequenas funções auxiliares ou chamadas de API para serviços existentes. Por exemplo, check_order_status(order_id) poderia ser uma ferramenta que recebe o argumento order_id e chama uma API para consultar o status do pedido.

Exemplo

Vamos adaptar o exemplo de atendimento ao cliente para usar um único agente. Ele tem acesso a três ferramentas distintas:

  • Ferramenta de consulta de pedidos
  • Ferramenta de redefinição de senha
  • Ferramenta de perguntas frequentes sobre produtos

Quando o cliente pergunta sobre o status do pedido, o agente decide dinamicamente se chama uma ferramenta ou responde ao cliente. Por exemplo, se o cliente perguntar “Qual é o status do meu pedido?”, o agente agora pode pedir que ele informe o ID do pedido. Isso torna a interação mais natural.

Fonte de comportamento não determinísticoO que avaliarExemplos de perguntas de avaliação
Entradas fornecidas pelo desenvolvedor e pelo usuário

Cumprimento das instruções: o modelo entende corretamente as instruções recebidas e age de acordo com elas?



Cumprimento das instruções: o modelo prioriza o prompt do sistema quando o prompt do usuário entra em conflito com ele?

O modelo mantém o foco na triagem ou a pergunta do usuário o desvia da tarefa?



O modelo segue as instruções para tentar extrair o ID do pedido?

Saídas geradas pelo modelo

Correção funcional: as saídas do modelo são corretas, relevantes e completas o suficiente para realizar a tarefa ou atingir o objetivo previsto?

A intenção identificada pelo modelo corresponde à intenção esperada?

Ferramentas escolhidas pelo modelo

Seleção de ferramentas: avaliações que verificam se o agente consegue escolher a ferramenta correta.



Precisão dos dados: avaliações que verificam se o agente chama a ferramenta com os argumentos corretos. Como esses argumentos geralmente vêm do histórico da conversa, o objetivo é verificar se foram extraídos corretamente.

Quando o usuário pergunta sobre o status do pedido, o modelo recomenda corretamente a chamada à ferramenta de consulta de pedidos?



O modelo extrai corretamente o ID do pedido informado pelo usuário e o passa à ferramenta de consulta?

Arquiteturas com múltiplos agentes

À medida que você acrescenta ferramentas e tarefas a uma arquitetura com um único agente, o modelo pode ter dificuldade para seguir as instruções ou escolher a ferramenta correta. As arquiteturas com múltiplos agentes ajudam a resolver isso ao distribuir o trabalho entre agentes especializados em diferentes áreas. A triagem e a transferência de solicitações entre agentes introduzem uma nova fonte de comportamento não determinístico.

Use os resultados das avaliações para decidir se deve adotar uma arquitetura com múltiplos agentes. Começar com vários agentes acrescenta uma complexidade desnecessária que pode atrasar a entrada em produção.

Exemplo

Ao dividir o trabalho do agente do exemplo anterior em uma arquitetura com múltiplos agentes, teremos quatro agentes distintos:

  1. Agente de triagem
  2. Agente de pedidos
  3. Agente de gerenciamento de contas
  4. Agente de vendas

Quando o cliente pergunta sobre o status do pedido, o agente de triagem pode transferir a conversa para o agente de pedidos fazer a consulta. Se o cliente mudar de assunto e perguntar sobre um produto, o agente de pedidos deve devolver a solicitação ao agente de triagem. Este a encaminha ao agente de vendas, que busca as informações sobre o produto.

Fonte de comportamento não determinísticoO que avaliarExemplos de perguntas de avaliação
Entradas fornecidas pelo desenvolvedor e pelo usuárioCumprimento das instruções: o modelo entende corretamente as instruções recebidas e age de acordo com elas?

Cumprimento das instruções: o modelo prioriza o prompt do sistema quando o prompt do usuário entra em conflito com ele?
O modelo mantém o foco na triagem ou a pergunta do usuário o desvia da tarefa?

Supondo que a chamada a lookup_order tenha retornado, o agente de pedidos informa um código de rastreamento e uma data de entrega (mesmo que estejam incorretos)?
Saídas geradas pelo modeloCorreção funcional: as saídas do modelo são corretas, relevantes e completas o suficiente para realizar a tarefa ou atingir o objetivo previsto?A intenção identificada pelo modelo corresponde à intenção esperada?

Supondo que a chamada a lookup_order tenha retornado, o agente de pedidos informa o código de rastreamento e a data de entrega corretos na resposta?

O agente de pedidos segue as instruções do sistema e pergunta ao cliente o motivo da devolução antes de processá-la?
Ferramentas escolhidas pelo modeloSeleção de ferramentas: avaliações que verificam se o agente consegue escolher a ferramenta correta.

Precisão dos dados: avaliações que verificam se o agente chama a ferramenta com os argumentos corretos. Como esses argumentos geralmente vêm do histórico da conversa, o objetivo é verificar se foram extraídos corretamente.
O agente de pedidos chama corretamente a ferramenta de consulta de pedidos?

O agente de pedidos chama corretamente a ferramenta refund_order?

O agente de pedidos chama a ferramenta de consulta com o ID do pedido correto?

O agente de gerenciamento de contas chama corretamente a ferramenta reset_password com o ID da conta correto?
Transferência entre agentesExatidão das transferências entre agentes: avaliações que verificam se cada agente reconhece corretamente quando deve encaminhar a solicitação a outro agenteQuando o usuário pergunta sobre o status do pedido, o agente de triagem encaminha a solicitação corretamente ao agente de pedidos?

Quando o usuário muda de assunto para falar sobre o produto mais recente, o agente de pedidos devolve o controle ao agente de triagem?

Crie e combine diferentes tipos de avaliadores

Ao criar suas avaliações, você pode escolher entre vários tipos de avaliadores. Uma forma de orientar a escolha é pensar no papel que você quer atribuir a cada avaliador.

Avaliações baseadas em métricas

As avaliações quantitativas produzem uma pontuação numérica que você pode usar para filtrar e ordenar resultados. Elas fornecem referências úteis para testes de regressão automatizados.

  • Exemplos: correspondência exata, correspondência de strings, pontuação ROUGE/BLEU, acurácia das chamadas de função e avaliações executáveis (que verificam a funcionalidade ou o comportamento por meio da execução, como em text2sql)
  • Desafios: podem não se adequar a casos de uso específicos e deixar escapar nuances

Avaliações humanas

As avaliações baseadas em julgamento humano oferecem a melhor qualidade, mas são demoradas e caras.

  • Exemplos: examine rapidamente as saídas do sistema para ter uma ideia de quais parecem melhores ou piores. Crie um teste cego e aleatorizado em que funcionários, prestadores de serviço ou empresas terceirizadas de rotulagem avaliem a qualidade das saídas (por exemplo, ordenando um pequeno conjunto de saídas possíveis por qualidade ou dando a cada uma nota de 1 a 5)
  • Desafios: divergências entre especialistas, custo alto e demora
  • Recomendações:
    • Faça várias rodadas de revisão humana detalhada para refinar a ficha de avaliação
    • Mostre o que cada nota significa com exemplos concretos de diferentes níveis de pontuação (por exemplo, notas 1, 3 e 8 em uma escala de 10)
    • Além da pontuação numérica, defina um limiar de aprovação ou reprovação
    • Uma forma de combinar as avaliações de várias pessoas é usar uma votação para chegar a um consenso

LLM como juiz e modelos que atribuem notas

Usar modelos para julgar as saídas custa menos e facilita a avaliação em escala em comparação com a avaliação humana. Quando precisar de um LLM com bom desempenho como juiz, comece com gpt-6-astra. Antes de otimizar o custo ou a latência, verifique se os julgamentos do modelo concordam com os rótulos atribuídos por pessoas.

  • Exemplos:
    • Comparação de pares: apresente duas respostas ao modelo que atua como juiz e peça que ele determine qual é a melhor com base em critérios específicos
    • Avaliação de uma única resposta: o modelo julga uma resposta isoladamente e atribui uma pontuação ou classificação com base em métricas de qualidade predefinidas
    • Avaliação com base em uma referência: forneça ao modelo uma resposta de referência ou “padrão-ouro” para que ele a use como parâmetro ao avaliar a resposta recebida
  • Desafios: viés de posição (influência da ordem das respostas) e viés de verbosidade (preferência por respostas mais longas)
  • Recomendações:
    • Use comparações de pares ou critérios de aprovação e reprovação para obter resultados mais confiáveis
    • Se possível, use o modelo mais capaz para atribuir notas. Comece com gpt-6-astra e verifique se um modelo de raciocínio especializado tem desempenho melhor com seus critérios de avaliação ou seu conjunto de respostas de referência
    • Controle o comprimento das respostas, pois os LLMs tendem a favorecer respostas mais longas
    • Inclua o raciocínio e a cadeia de pensamento, pois raciocinar antes de atribuir a nota melhora o desempenho da avaliação
    • Amplie a escala quando o LLM que atua como juiz for mais rápido, tiver menor custo e concordar de forma consistente com as anotações humanas
    • Estruture as perguntas de forma que seja possível atribuir notas automaticamente sem comprometer a integridade da tarefa. Uma abordagem comum é reformular as perguntas no formato de múltipla escolha
    • Defina critérios de avaliação claros e detalhados

Nenhuma estratégia é perfeita. A qualidade dos julgamentos de um LLM varia conforme o contexto do problema, enquanto recorrer a especialistas para atribuir rótulos de referência é caro e demorado.

Como lidar com casos extremos

Suas avaliações devem cobrir os principais cenários em que tudo ocorre como esperado em cada arquitetura. No uso real, porém, os sistemas de IA encontram com frequência casos extremos que colocam seu desempenho à prova. Avaliar esses casos é importante para garantir a confiabilidade do sistema e uma boa experiência para o usuário.

Esses casos extremos costumam se dividir em algumas categorias:

Variabilidade das entradas

Como os usuários fornecem as entradas ao modelo, o sistema precisa ter flexibilidade para lidar com diferentes formas de interação, como:

  • Entradas em idiomas diferentes do inglês ou em vários idiomas
  • Formatos diferentes de texto simples (por exemplo, XML, JSON, Markdown e CSV)
  • Diferentes modalidades de entrada (por exemplo, imagens)

Suas avaliações de cumprimento das instruções e de correção funcional precisam contemplar as entradas que os usuários podem tentar fornecer.

Complexidade do contexto

Muitos aplicativos baseados em LLM falham por interpretar mal o contexto da solicitação. Esse contexto pode vir do usuário ou conter ruído de interações anteriores no histórico da conversa.

Alguns exemplos:

  • Várias perguntas ou intenções em uma única solicitação
  • Erros de digitação e de ortografia
  • Solicitações curtas com pouco contexto (por exemplo, quando o usuário diz apenas “devoluções”)
  • Contextos extensos ou conversas prolongadas
  • Chamadas de ferramentas que retornam dados com nomes de propriedades ambíguos (por exemplo, "on: 123", em que “on” indica o número do pedido)
  • Várias chamadas de ferramentas, que às vezes resultam no uso de argumentos incorretos
  • Várias transferências entre agentes, que às vezes encaminham a solicitação em círculos

Personalização e customização

A IA melhora a experiência do usuário ao se adaptar a solicitações específicas, mas essa flexibilidade introduz muitos casos extremos. Defina avaliações claras para os casos de uso que você quer aceitar ou bloquear explicitamente:

  • Tentativas de jailbreak para fazer o modelo agir de outra maneira
  • Solicitações de formatação (por exemplo, formatar a saída como JSON ou usar uma lista com marcadores)
  • Casos em que os prompts do usuário entram em conflito com os prompts do sistema

Use as avaliações para melhorar o desempenho

Quando suas avaliações estiverem maduras o suficiente para medir o desempenho de forma consistente, passe a usar os dados obtidos para melhorar o desempenho do aplicativo.

Outros recursos

Para encontrar mais ideias, visite o OpenAI Cookbook, que reúne exemplos de código e links para recursos de terceiros, ou saiba mais sobre nossas ferramentas de avaliação: