---
title: "AI Evals: como avaliar produtos e experiências com IA"
date: 2026-09-08T17:45:38Z
modified: 2026-09-08T17:56:34Z
permalink: "https://camaraux.com.br/ai-evals/"
type: post
status: publish
excerpt: AI Evals transformam “parece bom” em critérios testáveis. Veja como combinar métricas automáticas, avaliação humana, LLM-as-a-judge, UX Research e monitoramento para avaliar produtos com IA de ponta a ponta.
wpid: 13627
categories:
  - UX & IA
rank_math_title: "AI Evals: como avaliar produtos com IA  %sep% %sitename%"
rank_math_description: Entenda o que são AI Evals e como avaliar qualidade, experiência, segurança, agentes e RAG em produtos com IA com métricas, rubricas e testes.
rank_math_focus_keyword: AI Evals,avaliação de IA,avaliação de produtos com IA,LLM evaluation,UX Evals,avaliação de agentes de IA
featured_image: /wp-content/uploads/2026/09/AI-Evals.png
featured_image_alt: AI Evals - Pessoa analisando interface com ícones de avaliação de dados e inteligência artificial
author: Lucas Camara
timestamp: 2026-09-08T17:56:34Z
tags:
  - UX & IA
---

**AI Evals são testes repetíveis usados para verificar se um produto ou sistema com inteligência artificial está fazendo o que deveria fazer, com qualidade suficiente para pessoas e contextos reais.** Em vez de avaliar uma resposta isolada e concluir que “parece boa”, uma equipe transforma expectativas, riscos e necessidades do usuário em critérios que podem ser testados, comparados e acompanhados ao longo do tempo.

Isso muda bastante a forma de avaliar produtos com IA. Um modelo pode ter bom desempenho em um benchmark e ainda gerar uma experiência ruim. Pode responder corretamente, mas demorar demais. Pode ser útil em média, mas falhar justamente nos casos críticos. Pode ter uma resposta tecnicamente válida que a pessoa não entende, não consegue revisar ou confia mais do que deveria.

> **Resposta rápida:** um bom AI Eval não pergunta apenas “o modelo respondeu certo?”. Ele verifica se o sistema ajuda a pessoa a concluir uma tarefa, se o resultado é confiável, se falhas importantes são controladas e se a qualidade continua aceitável depois de mudanças em prompts, modelos, dados, ferramentas ou interface.

Esse assunto se conecta diretamente ao que já discutimos sobre [dívida de experiência na era da IA](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/divida-de-experiencia-ia.md). Produzir mais rápido não resolve o problema de decidir o que realmente está bom. AI Evals ajudam a transformar essa decisão em um processo mais explícito e verificável.

## O que são AI Evals?

**AI Eval** é uma abreviação de _AI evaluation_. Na prática, é uma avaliação estruturada de algum comportamento de um sistema de IA. A equipe fornece casos de teste, executa o sistema e aplica critérios para decidir quão bem ele se saiu.

A documentação de avaliação da OpenAI diferencia benchmarks genéricos de avaliações específicas construídas para uma aplicação. A recomendação é definir o objetivo, reunir dados adequados, escolher métricas, comparar versões e continuar avaliando conforme o sistema muda. A Anthropic segue uma lógica semelhante para agentes, tratando evals como testes compostos por tarefas, tentativas e formas de avaliação do resultado ou da trajetória executada.

Fontes: [OpenAI, Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices) e [Anthropic, Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).

Em um produto real, a unidade de análise não precisa ser apenas o modelo. Ela pode incluir prompt, contexto, mecanismo de recuperação de informações, ferramentas, regras de negócio, interface, comportamento do usuário, latência e custo.

## Avaliar o modelo não é o mesmo que avaliar o produto

Benchmarks são úteis para comparar capacidades. Eles ajudam, por exemplo, a descobrir se um modelo tende a ser melhor em raciocínio, código, recuperação ou determinadas tarefas. O problema aparece quando essa medida é usada como prova de que a experiência inteira funciona.

Para um usuário, o sistema não termina no modelo. Imagine um assistente que responde perguntas sobre políticas internas de uma empresa. Mesmo com um bom LLM, a experiência pode falhar porque o mecanismo de busca recuperou o documento errado, a resposta não deixou claro de onde a informação veio, uma ferramenta executou a ação incorreta ou o usuário não percebeu que deveria revisar a recomendação antes de usá-la.

Por isso, uma avaliação útil precisa começar pela pergunta que o produto pretende responder:

- Que tarefa a pessoa está tentando concluir?
- O que caracteriza uma resposta realmente útil?
- Quais erros são toleráveis?
- Quais erros não podem acontecer?
- Como saberemos que uma nova versão ficou melhor?
- O que precisa continuar funcionando depois de uma alteração?

A própria OpenAI recomenda evitar avaliações genéricas e datasets distantes da distribuição real de uso. O objetivo é testar a aplicação contra situações que representem o que ela encontrará em produção.

## AI Evals, teste de usabilidade e métricas de produto respondem perguntas diferentes

AI Evals não substituem UX Research, analytics ou experimentação. Eles acrescentam uma nova camada de observação para sistemas cujo comportamento pode variar mesmo quando a interface ou a tarefa permanecem iguais.



| Método | Pergunta principal | Exemplo |
| --- | --- | --- |
| **AI Eval** | O sistema está se comportando de acordo com os critérios esperados? | Verificar se respostas estão fundamentadas, se ferramentas são usadas corretamente e se uma mudança criou regressões. |
| **Teste de usabilidade** | Como pessoas reais realizam uma tarefa e onde encontram dificuldades? | Observar se usuários entendem a resposta, conseguem corrigir um erro e sabem como continuar. |
| **Analytics** | O que está acontecendo em escala no produto? | Acompanhar adoção, abandono, recorrência, tempo, conversão ou uso de determinada funcionalidade. |
| **Teste A/B** | Uma alternativa causa um resultado melhor que outra? | Comparar duas experiências depois que ambas passaram pelos critérios mínimos de segurança e qualidade. |

Se você precisa observar diretamente como pessoas usam uma interface, veja também o guia de [teste de usabilidade](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/implementando-testes-de-usabilidade-guia-completo.md). Em produtos com IA, a combinação dos métodos tende a ser mais informativa do que tentar transformar um deles em resposta para todas as perguntas.

## Uma matriz de quatro camadas para avaliar produtos com IA

Uma forma prática de organizar AI Evals é separar a avaliação em quatro camadas. Esta é uma síntese proposta pela CamaraUX a partir da literatura e das práticas atuais de avaliação de IA, produto e Human-AI Interaction.



| Camada | Pergunta | O que avaliar |
| --- | --- | --- |
| **Produto e experiência** | A IA ajuda a pessoa a alcançar o objetivo? | Sucesso da tarefa, utilidade, compreensão, confiança calibrada, retrabalho, controle e recuperação de erros. |
| **Sistema** | A aplicação produz resultados tecnicamente adequados? | Correção, factualidade, groundedness, recuperação de contexto, aderência às instruções, execução de ferramentas, latência e custo. |
| **Risco** | O sistema evita falhas que seriam inaceitáveis? | Segurança, privacidade, vieses, vazamento de dados, jailbreaks, ações indevidas e recusas inadequadas. |
| **Operação** | A qualidade continua aceitável depois de mudanças? | Regressões, traces de produção, incidentes, novos casos de teste, mudanças de comportamento e monitoramento contínuo. |

### 1. Produto e experiência

É a camada mais próxima da intenção do usuário. Um sistema pode responder algo factual e ainda não resolver a necessidade. Por isso, medidas de experiência precisam observar o que acontece depois da resposta.

- A pessoa concluiu a tarefa?
- Precisou corrigir muito do resultado?
- Entendeu as limitações da resposta?
- Conseguiu identificar e recuperar um erro?
- Teve controle suficiente antes de uma ação importante?
- A confiança depositada no sistema era compatível com sua qualidade real?

As [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/), da Microsoft Research, ajudam a mostrar por que essas dimensões importam. Elas incluem tornar capacidades e limitações claras, permitir correção, apoiar o usuário quando a IA está errada e adaptar o comportamento ao longo do tempo.

### 2. Sistema

Aqui entram critérios que podem ser medidos diretamente na aplicação. Dependendo do problema, isso pode significar verificar uma resposta exata, testar se uma informação está apoiada pelas fontes recuperadas, validar a estrutura de um JSON, verificar parâmetros enviados a uma ferramenta ou comparar respostas contra uma rubrica.

Nem toda métrica faz sentido para toda tarefa. Classificação pode permitir exact match, precisão e recall. Uma resposta aberta exige critérios diferentes, como correção factual, relevância, completude ou aderência às instruções.

### 3. Risco

Alguns critérios não deveriam funcionar como uma nota que pode ser compensada por outra. Se uma aplicação possui risco de expor dados pessoais ou executar uma operação crítica incorreta, uma melhoria em fluência não compensa esse problema.

O [Generative AI Profile do NIST AI Risk Management Framework](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) reforça a necessidade de integrar considerações de confiabilidade e risco ao desenvolvimento, uso e avaliação de produtos e sistemas de IA.

Na prática, isso leva a uma regra importante: **algumas métricas são objetivos de melhoria, enquanto outras funcionam como gates de lançamento.**

### 4. Operação

O conjunto de evals não deveria ser um documento congelado antes do lançamento. Quando um novo erro aparece em produção, ele pode se transformar em um caso de regressão. Quando o produto passa a atender outro público, o dataset precisa representar essa mudança. Quando prompt, modelo, ferramenta ou mecanismo de recuperação muda, a suíte é executada novamente.

Esse ciclo transforma avaliação em infraestrutura de decisão, e não apenas em uma etapa de QA no final do projeto.

[![Comparação entre uma única saída de IA e uma avaliação com múltiplos inputs e execuções repetidas.](https://media.nngroup.com/media/editor/2026/08/11/1.png)

](https://www.nngroup.com/articles/eval-ai-output/)Uma saída isolada mostra apenas que o sistema conseguiu executar uma tarefa uma vez. Uma avaliação usa diferentes entradas, execuções repetidas e analisa a variabilidade dos resultados. Fonte: Nielsen Norman Group, 2026.## Como criar AI Evals na prática

### 1. Comece pela tarefa, não pela métrica

Defina primeiro o que a pessoa precisa alcançar. “Responder bem” é vago demais. “Identificar corretamente a política aplicável, explicar a resposta e mostrar a fonte utilizada” já produz critérios que podem ser avaliados.

Depois, descreva as principais formas de falha. Essa taxonomia costuma ser mais útil do que escolher dez métricas antes de entender o problema.

### 2. Monte um conjunto representativo de casos

O dataset de avaliação pode combinar exemplos construídos por especialistas, situações reais de produção, casos extremos, inputs adversariais e cenários sintéticos criados para ampliar a cobertura.

Esse conjunto é frequentemente chamado de **golden set** quando reúne exemplos revisados e expectativas suficientemente confiáveis para servir de referência. O nome não significa que cada caso precisa ter uma única resposta textual perfeita. Uma rubrica também pode definir o que caracteriza sucesso.

A Anthropic recomenda começar cedo. Em sistemas ainda novos, algumas dezenas de tarefas realistas podem revelar mudanças importantes de comportamento, enquanto aplicações maduras tendem a precisar de conjuntos muito maiores e continuamente atualizados.

### 3. Defina critérios e rubricas antes de comparar versões

Se duas pessoas avaliam a mesma resposta e usam definições diferentes de “boa”, o resultado do eval será difícil de interpretar. Uma rubrica explicita o que cada critério significa.

Para um resumo gerado por IA, por exemplo, a equipe pode separar:

- **Factualidade:** nenhuma afirmação deve contradizer a fonte.
- **Cobertura:** as informações essenciais precisam estar presentes.
- **Relevância:** o resumo deve priorizar o que importa para a tarefa.
- **Clareza:** a pessoa precisa compreender o resultado sem esforço desnecessário.

Critérios separados produzem diagnósticos melhores. Uma nota genérica de “qualidade: 8/10” não informa qual parte do sistema deve ser melhorada.

### 4. Escolha o avaliador adequado para cada critério

Existem três famílias especialmente úteis.



| Tipo | Quando funciona bem | Exemplos |
| --- | --- | --- |
| **Baseado em código** | Existe uma condição verificável de forma determinística. | Exact match, regex, schema válido, testes unitários, estado final de uma ferramenta. |
| **Modelo como avaliador** | O critério envolve linguagem aberta ou julgamento semântico em escala. | Relevância, aderência à instrução, completude, comparação entre duas respostas. |
| **Avaliação humana** | O critério depende de contexto, especialidade ou experiência humana difícil de automatizar. | Utilidade percebida, adequação ao domínio, confiança, clareza e revisão de casos críticos. |

Um sistema maduro normalmente combina os três. Automatizar tudo pode esconder problemas do avaliador. Avaliar tudo manualmente pode tornar o ciclo lento e caro.

### 5. Execute mais de uma tentativa quando a variabilidade importa

Sistemas generativos são não determinísticos. O mesmo caso pode passar em uma tentativa e falhar em outra. Para tarefas críticas, uma única execução pode produzir uma sensação falsa de estabilidade.

Em avaliações de agentes, a Anthropic diferencia medidas que observam se pelo menos uma de várias tentativas teve sucesso das que verificam se todas as tentativas foram bem-sucedidas. A segunda pergunta costuma ser mais importante quando consistência é parte da qualidade esperada.

### 6. Transforme falhas reais em novos testes

Depois do lançamento, logs, traces, feedback de usuários, tickets, revisões humanas e incidentes começam a mostrar situações que o conjunto inicial não previa. Bons programas de avaliação incorporam esses exemplos ao dataset.

O resultado é um ciclo:

1. observar uma falha;
2. entender por que ela aconteceu;
3. transformá-la em caso de teste;
4. corrigir o sistema;
5. rodar os evals novamente;
6. impedir que a mesma regressão volte despercebida.

### Vídeo: evals da pesquisa à produção

Esta apresentação da OpenAI mostra como avaliações são usadas desde pesquisa de fronteira até aplicações em produção e ajuda a visualizar evals como um processo contínuo, e não apenas como um benchmark de modelo.



## Quais métricas usar em AI Evals?

Não existe um conjunto universal. A métrica precisa acompanhar a tarefa, o risco e a decisão que será tomada. Em vez de procurar um número único para representar a qualidade, vale construir uma scorecard multidimensional.



| Dimensão | Possíveis métricas |
| --- | --- |
| **Resultado da tarefa** | Task success, tempo até sucesso, abandono, retrabalho, correções necessárias. |
| **Qualidade da resposta** | Correção, factualidade, relevância, completude, aderência à instrução. |
| **RAG** | Context precision, context recall, groundedness, faithfulness, relevância da resposta. |
| **Agentes** | Sucesso da tarefa, execução correta de ferramentas, estado final, número de tentativas, falhas de trajetória. |
| **Experiência** | Compreensão, satisfação, confiança calibrada, facilidade de correção, esforço e percepção de controle. |
| **Segurança** | Taxa de ações inseguras, sucesso de ataques, vazamento de dados, recusas inadequadas. |
| **Operação** | Latência p50/p95, custo por tarefa bem-sucedida, retries, regressões, incidentes. |

Uma consequência importante dessa abordagem é que **custo por chamada costuma ser menos informativo do que custo por tarefa bem-sucedida**. Um modelo barato pode exigir mais tentativas, gerar mais correções ou falhar com mais frequência. O mesmo raciocínio vale para latência: velocidade só é uma vantagem quando o resultado continua útil.

## LLM-as-a-judge: quando usar um modelo para avaliar outro modelo

**LLM-as-a-judge** é o uso de um modelo de linguagem como avaliador de respostas geradas por outro sistema. É especialmente útil quando a saída é aberta demais para um teste determinístico, mas existem critérios claros que podem ser transformados em uma rubrica.

Em vez de perguntar “dê uma nota para esta resposta”, é melhor fornecer critérios específicos. Outra alternativa é mostrar duas respostas e pedir qual atende melhor à rubrica.

Pesquisas como [G-Eval](https://arxiv.org/abs/2303.16634) e [MT-Bench e Chatbot Arena](https://arxiv.org/abs/2306.05685) ajudaram a demonstrar o potencial desse método, mas também documentaram limitações. Juízes baseados em LLM podem apresentar preferência por posição, verbosidade, estilo ou determinados tipos de resposta.

Por isso, LLM-as-a-judge funciona melhor como uma forma de **escalar critérios que já foram calibrados com pessoas**. Monte um conjunto rotulado por avaliadores humanos, compare a concordância do juiz automático e investigue os casos em que os dois divergem.

> O objetivo não é retirar humanos da avaliação. É usar revisão humana onde o julgamento humano acrescenta mais valor e automatizar o que pode ser repetido com confiabilidade suficiente.

## Como avaliar sistemas RAG

Em sistemas de **Retrieval-Augmented Generation (RAG)**, avaliar apenas a resposta final esconde onde o problema aconteceu. Uma resposta ruim pode surgir porque o mecanismo de busca não encontrou a informação adequada ou porque o modelo recebeu a evidência correta e mesmo assim a utilizou mal.

O framework [RAGAS](https://arxiv.org/abs/2309.15217) foi proposto justamente para decompor esse problema. Entre as dimensões importantes estão a qualidade do contexto recuperado e a fidelidade da resposta às evidências fornecidas.

Na prática, vale separar pelo menos quatro perguntas:

- O sistema recuperou as fontes relevantes?
- O contexto recuperado contém informação suficiente?
- A resposta está apoiada nesse contexto?
- A resposta final realmente atende à necessidade do usuário?

Essa decomposição reduz o risco de tentar corrigir o prompt quando o problema está no retrieval, ou trocar o modelo quando o problema está na base de conhecimento.

## Como avaliar agentes de IA

Agentes tornam a avaliação mais complexa porque não produzem apenas uma saída. Eles podem planejar, chamar ferramentas, alterar estado, consultar dados, executar várias etapas e decidir o próximo movimento com base no resultado anterior.

A Anthropic propõe olhar tanto para a **trajetória** quanto para o **resultado final**. Um agente pode chegar à resposta correta usando um caminho perigoso, caro ou desnecessário. Em outros casos, exigir uma trajetória rígida demais pode penalizar soluções válidas que chegaram ao mesmo resultado por outro caminho.

Por isso, uma avaliação de agentes pode combinar:

- verificação determinística do estado final;
- validação das ferramentas utilizadas;
- critérios sobre ações proibidas;
- avaliação do resultado por rubrica;
- análise de traces e transcrições;
- repetição da mesma tarefa para medir consistência.

Quanto maior a autonomia, maior tende a ser a importância de avaliar não apenas “o que respondeu”, mas também “o que fez”.

## Onde entram UX Evals e usuários reais?

Um movimento recente tenta aproximar ainda mais avaliação de IA e pesquisa com usuários. Em 2026, a Outset publicou a metodologia que chama de **UX Evals**, desenvolvida em colaboração com integrantes do time do Microsoft Copilot. O ponto de partida foi a percepção de que métricas existentes não capturavam toda a diversidade e complexidade das experiências que as pessoas tinham com o produto.

A abordagem enfatiza experiências em primeira pessoa, interações com múltiplos turnos e objetivos reais, em vez de fornecer a todos o mesmo prompt artificial. Fonte: [Outset, Introducing UX Evals](https://outset.ai/resources/blog/introducing-ux-evals).

É importante tratar UX Evals como uma metodologia emergente, e não como um padrão universal já estabelecido. A fonte também é a própria empresa que oferece a solução. Ainda assim, o problema que ela aponta é relevante: uma suíte automática pode dizer que uma resposta atende à rubrica sem explicar se a experiência ajudou a pessoa a avançar, tomar uma decisão ou perceber corretamente os limites do sistema.

Esse é um bom exemplo de por que AI Evals e UX Research devem se complementar.

## Um scorecard de lançamento precisa de gates, não apenas de uma média

Imagine um assistente de IA que recebeu as seguintes notas: qualidade 92, experiência 90, latência 85 e segurança 40. Calcular uma média e concluir que o sistema obteve uma nota aceitável seria uma decisão ruim.

Nem todos os critérios possuem o mesmo papel. Uma scorecard de release pode separar:



| Tipo | Exemplo | Decisão |
| --- | --- | --- |
| **Gate obrigatório** | Nenhuma ação crítica insegura no conjunto definido para release. | Se falhar, não lança. |
| **Threshold** | Taxa mínima de sucesso na tarefa. | Abaixo do limite, revisar. |
| **Objetivo de otimização** | Reduzir custo por tarefa bem-sucedida. | Comparar alternativas. |
| **Guardrail** | Não aumentar abandono ou retrabalho. | Evitar ganho local com perda na experiência. |

Os números concretos precisam ser definidos pelo produto, risco e contexto. Não existe um threshold universal que transforme uma aplicação de IA em “boa”.

## Exemplo real: medir o resultado humano, não apenas a saída da IA

Um experimento controlado com o GitHub Copilot ajuda a visualizar essa diferença. Desenvolvedores foram convidados a implementar um servidor HTTP em JavaScript. O grupo com acesso ao Copilot concluiu a tarefa experimental 55,8% mais rápido que o grupo de controle.

O estudo não é um modelo universal de AI Eval e não prova que o mesmo efeito apareça em qualquer contexto. Seu valor aqui está na unidade de análise: a pergunta principal era o que aconteceu com a **tarefa humana**, e não simplesmente quantos trechos de código gerados pelo sistema estavam tecnicamente corretos.

Fonte: [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot](https://arxiv.org/abs/2302.06590).

## Erros comuns ao criar AI Evals

### Usar benchmark como acceptance test do produto

Um benchmark ajuda a caracterizar capacidade. A avaliação do seu produto precisa representar a tarefa, os dados, os usuários e os riscos da sua aplicação.

### Testar uma resposta e concluir que está funcionando

Uma resposta é um exemplo. Sistemas não determinísticos precisam de casos diversos e, quando necessário, múltiplas execuções do mesmo caso.

### Resumir tudo em uma única nota

Uma média pode esconder exatamente a falha que deveria impedir o lançamento. Segurança, privacidade e outros riscos críticos precisam de tratamento próprio.

### Usar LLM-as-a-judge sem calibrar

Um modelo avaliador também possui vieses e limitações. Compare seu julgamento com labels humanos antes de confiar nele em grande escala.

### Construir um dataset perfeito e nunca atualizá-lo

Produção cria casos que o time não imaginou. O conjunto de avaliação precisa incorporar falhas reais e mudanças na distribuição de uso.

### Medir adoção como se fosse valor

Mais prompts, sessões ou mensagens mostram uso. Não demonstram automaticamente que a pessoa concluiu melhor a tarefa, tomou uma decisão melhor ou obteve um resultado mais valioso.

## Quem deveria definir os evals?

AI Evals não deveriam ser responsabilidade exclusiva de engenharia. A qualidade esperada de um produto com IA envolve decisões técnicas, humanas e de negócio.



| Disciplina | Contribuição |
| --- | --- |
| **Product** | Objetivo, contexto, trade-offs, impacto e critérios de release. |
| **UX Research** | Necessidades humanas, rubricas, estudos, percepção, comportamento e validação qualitativa. |
| **Product Design** | Interação, controle, feedback, recuperação de erros e experiência resultante. |
| **Engenharia** | Harness de avaliação, instrumentação, automação, traces e integração ao desenvolvimento. |
| **Especialistas do domínio** | Ground truth, critérios profissionais e revisão de erros específicos. |
| **Segurança, privacidade e governança** | Falhas críticas, políticas, threat modeling e limites de uso. |

A contribuição de UX é especialmente importante porque “boa resposta” não é apenas uma propriedade linguística. Ela depende da intenção, do momento, da consequência do erro e do que a pessoa precisa conseguir fazer depois.

## AI Evals precisam fazer parte do ciclo de produto

O maior ganho acontece quando a avaliação deixa de ser um ritual antes do lançamento e passa a acompanhar as decisões do produto.

Uma mudança de prompt roda regressões. Um modelo novo é comparado com o baseline. Uma falha de produção vira caso de teste. Uma avaliação humana revela um critério que ainda não estava na rubrica. Um experimento mostra que a melhoria offline não produziu benefício para usuários. O dataset é atualizado e o ciclo continua.

É exatamente o oposto de avaliar “no feeling”. E é uma capacidade que tende a ganhar importância conforme produtos passam de respostas simples para sistemas com RAG, múltiplas ferramentas, agentes e maior autonomia.

Se você está acompanhando como essas mudanças afetam o trabalho de design, o guia de [inteligência artificial para designers](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/post/inteligencia-artificial-para-designers.md) organiza o restante desse território na CamaraUX.

## Conclusão

AI Evals são uma forma de tornar explícita uma pergunta que produtos com IA não conseguem evitar: **como sabemos que isso está bom o suficiente para ser usado?**

A resposta não cabe em um benchmark, uma taxa de alucinação ou uma pesquisa de satisfação isolada. Produtos com IA precisam combinar qualidade técnica, resultado da tarefa, experiência humana, risco e operação contínua.

O melhor conjunto de evals não é o que possui mais métricas. É o que consegue transformar expectativas importantes em critérios observáveis, detectar regressões antes que elas cheguem às pessoas e incorporar as falhas do mundo real ao próximo ciclo de melhoria.

## Perguntas frequentes sobre AI Evals

### O que significa AI Evals?

AI Evals significa AI Evaluations. São testes e processos usados para medir se um sistema ou produto com inteligência artificial atende aos critérios esperados de qualidade, utilidade, segurança e desempenho.





### Qual é a diferença entre AI Evals e teste de usabilidade?

AI Evals verificam comportamentos e resultados de sistemas de IA contra critérios definidos. Testes de usabilidade observam pessoas representativas realizando tarefas para entender dificuldades e comportamentos. Em produtos com IA, os dois métodos podem ser complementares.





### O que é LLM-as-a-judge?

LLM-as-a-judge é o uso de um modelo de linguagem para avaliar respostas de outro sistema segundo uma rubrica. O método permite escalar avaliações abertas, mas deve ser calibrado com julgamento humano porque modelos avaliadores também apresentam vieses e limitações.





### Como avaliar um sistema RAG?

A avaliação de RAG deve separar a qualidade da recuperação da qualidade da geração. É importante verificar se fontes relevantes foram recuperadas, se o contexto é suficiente, se a resposta está fundamentada nesse contexto e se o resultado atende à necessidade do usuário.





### Como avaliar agentes de IA?

Agentes podem ser avaliados pelo resultado final, uso correto de ferramentas, trajetória, estado produzido, segurança e consistência entre múltiplas tentativas. O conjunto de critérios depende do nível de autonomia e da tarefa executada.





### AI Evals precisam continuar depois do lançamento?

Sim. Sistemas de IA mudam com modelos, prompts, dados, ferramentas e comportamento real dos usuários. Casos de produção, incidentes e novas falhas devem alimentar o conjunto de avaliação e os testes de regressão.









## Fontes e referências

1. [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents). Estrutura e práticas para avaliação de agentes em sistemas reais.
2. [OpenAI: Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices). Processo de definição de objetivos, datasets, métricas, avaliação contínua e calibração humana.
3. [NIST: Artificial Intelligence Risk Management Framework, Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence). Gestão de riscos e avaliação de sistemas de IA generativa.
4. [Microsoft Research: Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/). Diretrizes baseadas em evidências para experiências humano-IA.
5. [Product Talk: AI Evals, A Hands-On Guide for Product Teams](https://www.producttalk.org/ai-evals/). Perspectiva de Product Discovery e uso de evals por times de produto.
6. [Amplitude: AI evals for product managers](https://amplitude.com/blog/ai-evals-for-product-managers). Relação entre qualidade de agentes e resultados de produto.
7. [Outset: Introducing UX Evals](https://outset.ai/resources/blog/introducing-ux-evals). Metodologia emergente orientada à avaliação da experiência com sistemas de IA.
8. [RAGAS: Automated Evaluation of Retrieval Augmented Generation](https://arxiv.org/abs/2309.15217). Framework para avaliação de sistemas RAG.
9. [G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment](https://arxiv.org/abs/2303.16634). Pesquisa sobre avaliação de linguagem usando LLMs.
10. [Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena](https://arxiv.org/abs/2306.05685). Estudo de desempenho e vieses de modelos usados como avaliadores.
11. [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot](https://arxiv.org/abs/2302.06590). Experimento controlado sobre resultado humano em uma tarefa assistida por IA.

## Topics

**Categorias:** [UX & IA](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/ux-e-ia.md)