Início › Guias › governanca-e-operacao-de-ia
Guia

Como avaliar prompts e modelos de IA com métricas simples (sem virar laboratório)

Atualizado em 2026-10-24 · por Redação Treinamento de IA
Profissionais avaliando respostas de IA com planilha de métricas em escritório no Brasil
Resposta rápida: Para avaliar prompts e modelos de IA sem complicar, defina 1 tarefa real, crie 10 a 20 casos de teste, rode as mesmas entradas em 2 ou 3 opções e pontue quatro coisas: acerto (qualidade), consistência, tempo de retrabalho e risco (alucinação/vazamento). A escolha quase sempre fica clara quando você mede e registra.
· espaço publicitário ·
Em resumo
  • Escolha uma tarefa única (ex.: responder e-mail, resumir reunião, classificar tickets) e avalie só isso
  • Use casos de teste representativos, incluindo “casos chatos” e “casos perigosos”
  • Compare com uma rubrica simples (0–2 ou 0–5) para reduzir discussão subjetiva
  • Meça retrabalho e risco junto com qualidade — é aí que o ROI aparece
  • Registre versão do prompt, modelo e configurações (temperatura/top_p) para repetir depois
  1. 1) Defina o objetivo de negócio (em 1 frase)

    Não é “melhorar o prompt”. É algo como: “Reduzir o tempo para responder clientes mantendo tom profissional e evitando promessas indevidas”. Um objetivo curto evita que o teste vire disputa estética.

  2. 2) Escolha uma única tarefa e um formato de saída

    Exemplos: (a) e-mail de resposta com 120–180 palavras; (b) resumo de reunião com tópicos + decisões + próximos passos; (c) classificação de ticket com categoria e urgência. Fixe o formato para comparar maçã com maçã.

  3. 3) Monte um conjunto de casos de teste (10–20)

    Pegue entradas reais (anonimizadas) e inclua: casos comuns, casos longos, casos com ambiguidade e pelo menos 2 casos “armadilha” (pedindo algo que o modelo não deveria inventar). Se você não pode usar dados reais, crie sintéticos que imitem o seu cenário.

  4. 4) Crie uma rubrica de avaliação (nota curta + critério claro)

    Use uma escala simples (0–2 ou 0–5) e critérios escritos. Ex.: 0 = errado/inútil; 1 = parcialmente correto; 2 = correto e pronto para enviar. Adicione critérios separados para “tom” e “fidelidade ao contexto” se isso importa no seu negócio.

  5. 5) Rode o teste de forma controlada

    Use o mesmo conjunto de entradas para cada variação (Prompt A, Prompt B, Modelo X). Mantenha constantes as configurações sempre que possível. Se mudar temperatura/top_p, trate como outra versão a ser comparada.

  6. 6) Meça o que dói: retrabalho, consistência e risco

    Além da nota de qualidade, registre: tempo para editar até ficar publicável (ou número de edições), frequência de respostas inconsistentes e ocorrências de alucinação (dados inventados) ou vazamento (pedir/usar dado sensível). Nem sempre dá para medir “custo” com precisão sem acesso à cobrança; se não tiver, registre proxy: tamanho médio da resposta e número de chamadas.

  7. 7) Decida com regra simples e documente

    Defina antes a regra, por exemplo: “aprovado se média ≥ 1,6/2 e zero alucinações críticas”. Salve o prompt vencedor com versão, data, exemplos de entrada/saída e o que ele não deve fazer. Isso vira padrão interno e reduz regressão.

O erro clássico: testar “no feeling” e com exemplos bonitos

Quando alguém compara modelos/prompts com 2 ou 3 exemplos escolhidos a dedo, o resultado costuma enganar. IA parece ótima nos casos fáceis e derrapa justamente onde sua operação sofre: ambiguidade, falta de contexto, exceções e pedidos indevidos.

Um teste decente não precisa de estatística avançada. Precisa de disciplina: casos reais, critérios claros e registro.

Checklist do conjunto de testes (o que não pode faltar)

Se você quer que a IA seja confiável no trabalho, seu conjunto de testes precisa representar o ambiente real — inclusive as mensagens mal escritas e os pedidos confusos.

  • Casos comuns (os 60% que aparecem todo dia)
  • Casos longos (muito contexto, histórico, anexos colados em texto)
  • Casos ambíguos (faltando informação essencial — a IA deve perguntar, não inventar)
  • Casos com restrições (LGPD, compliance, linguagem proibida, promessas/garantias)
  • Casos “armadilha” (pedindo número, fonte, link ou fato específico que não foi fornecido)

Rubrica pronta: notas rápidas que evitam discussão infinita

A melhor rubrica é a que você consegue usar sem treinamento longo. Abaixo vai um modelo simples que funciona para a maioria das tarefas de texto.

CritérioNota 0Nota 1Nota 2
Correção/precisãoErra o pedido ou inventa informaçãoAcerta parte, mas com lacunasAcerta e não inventa nada
Aderência ao formatoIgnora o formato combinadoCumpre parcialmenteSegue o formato certinho
Tom e clarezaSoa inadequado/duro/confusoOk, mas precisa ajustesPronto para uso
Segurança (risco)Vaza dado, faz promessa indevida ou alucina “fato”Sinal amarelo (insinua/pressupõe)Seguro e faz perguntas quando falta info

Como comparar prompts vs. comparar modelos (não é a mesma briga)

Se a qualidade está instável, muitas vezes o problema é o prompt (ou o contexto), não o modelo. Trocar de modelo pode melhorar, mas é mais caro e mais difícil de padronizar.

Sugestão prática: primeiro otimize 1–2 versões de prompt no mesmo modelo. Só depois compare modelos diferentes com o prompt vencedor (ou o mais neutro possível).

Decisão rápida: a regra dos “3 sinais”

Quando duas opções parecem próximas, eu uso três sinais que costumam desempatar em operação real:

  • Qual opção exige menos edição humana para ficar publicável?
  • Qual opção erra de um jeito mais “seguro” (faz pergunta em vez de inventar)?
  • Qual opção é mais consistente quando você roda o mesmo caso 3 vezes?

Perguntas frequentes

Quantos casos de teste eu preciso para avaliar um prompt?
Para começar sem travar: 10 a 20 casos já dão um sinal forte, desde que sejam variados e incluam exceções. Se a tarefa for crítica (jurídico, saúde, finanças), aumente e inclua revisão humana mais rigorosa, porque “pareceu bom” não é critério.
Como medir “alucinação” na prática?
Marque como alucinação sempre que a IA afirmar como fato algo que não estava na entrada, em base confiável fornecida, ou em regra explícita. Se você não consegue checar a verdade, trate como risco: a saída deve virar pergunta (“você confirma X?”) em vez de afirmação.
Temperatura e top_p mudam muito o resultado do teste?
Mudam, principalmente consistência e criatividade. Para tarefas operacionais (resumo, classificação, e-mail padrão), a tendência é usar configurações mais conservadoras para reduzir variação. O importante é registrar as configurações como parte da versão testada.
Dá para avaliar custo sem saber tokens e preços?
Dá para usar proxies: tamanho médio das respostas, número de rodadas (reperguntas) e tempo de retrabalho humano. Quando você tiver acesso a dados de cobrança, substitui o proxy por custo real — mas a decisão inicial pode ser bem informada mesmo sem o número exato.

Leia também