Um demonstrador de IA generativa impressiona em minutos. Escreve-se um prompt, a resposta parece boa, e a sala assente. O problema começa quando esse mesmo sistema passa a responder a milhares de perguntas reais, de utilizadores reais, sobre casos que ninguém testou. É aí que a pergunta muda de "parece bom?" para "como sei que é bom, de forma consistente e mensurável?".
Avaliar um sistema de IA generativa é diferente de avaliar software tradicional. Não há um resultado "certo" único: a mesma pergunta admite várias respostas aceitáveis e muitas respostas erradas com ar convincente. Além disso, o comportamento muda quando se altera o prompt, a base de conhecimento ou a versão do modelo. Sem um processo de avaliação, cada alteração é um salto no escuro.
Este artigo propõe uma forma prática de avaliar estes sistemas — do primeiro protótipo à produção — sem cair no exagero das métricas académicas nem na ingenuidade de confiar na primeira demonstração. A ideia central é simples: definir o que é sucesso, medir de forma repetível e olhar para qualidade, custo e risco em conjunto.
O que significa "avaliar" um sistema de IA generativa
Avaliar não é dar uma nota subjetiva a uma resposta isolada. É medir, de forma repetível, se o sistema cumpre o objetivo para que foi construído, ao longo de muitos casos representativos. Um assistente de apoio ao cliente, um gerador de resumos e um copiloto de código têm objetivos distintos e, por isso, critérios de avaliação distintos.
Convém separar três camadas que muitas vezes se confundem. A primeira é o modelo em si, por exemplo um LLM. A segunda é o sistema à volta dele: prompts, recuperação de contexto por RAG, regras, filtros e ferramentas. A terceira é a experiência do utilizador final. Uma resposta pode estar tecnicamente correta e, ainda assim, falhar por ser demasiado longa, chegar tarde ou não citar a fonte. Avaliar bem obriga a olhar para as três.
Definir a tarefa e os critérios de sucesso antes das métricas
O erro mais comum é escolher métricas antes de definir o que se quer. A ordem certa é a inversa: primeiro descreve-se a tarefa com precisão, depois o que conta como resposta boa, e só no fim se escolhe como medir.
Vale a pena escrever, em linguagem simples, três coisas: o que o sistema deve fazer, o que nunca deve fazer, e o que é uma resposta suficientemente boa. Num assistente interno de recursos humanos, por exemplo, uma resposta boa cita a política correta, não inventa valores e encaminha para uma pessoa quando o caso é sensível. Estes critérios tornam-se depois a base dos testes.
Construir um conjunto de avaliação representativo
Não se avalia um sistema com três perguntas escolhidas a dedo. Precisa-se de um conjunto de casos — por vezes chamado golden set — que represente o uso real: perguntas frequentes, casos difíceis, pedidos ambíguos e situações que o sistema deve recusar. Cinquenta a duzentos casos bem escolhidos valem mais do que milhares gerados ao acaso.
Alguns princípios ajudam a montar este conjunto:
- Cobertura: incluir os temas e intenções mais comuns, mas também os raros e arriscados.
- Casos negativos: perguntas fora do âmbito, para verificar se o sistema recusa ou encaminha em vez de inventar.
- Respostas de referência: sempre que possível, uma resposta ideal ou os factos que a resposta tem de conter.
- Atualização: rever o conjunto quando surgem novos tipos de pergunta em produção.
Métricas que fazem sentido: qualidade, fidelidade e segurança
Não existe uma métrica única. Convém combinar algumas, consoante a tarefa. Para tarefas com resposta bem definida — classificar, extrair, responder a factos — medem-se coisas como exatidão, cobertura e precisão. Para texto livre, as métricas automáticas de sobreposição de palavras dizem pouco sobre a qualidade real; é preciso avaliar fidelidade ao contexto, relevância e clareza.
Três dimensões costumam ser decisivas: a qualidade (a resposta é correta, completa e útil?), a fidelidade (a resposta apoia-se nas fontes fornecidas ou inventa?) e a segurança (a resposta evita conteúdo perigoso, fugas de dados e tom inadequado?). Medir só a primeira e ignorar as outras duas é como validar um carro pela velocidade, sem olhar para os travões.
Avaliação automática, humana e o modelo como juiz
Há três formas de pontuar respostas, e o bom senso está em combiná-las. A avaliação humana é a mais fiável para nuances, mas é lenta e cara. A avaliação automática por regras funciona quando há uma resposta verificável: um número, um código, um facto. E há a abordagem de usar um modelo para avaliar outro, o chamado LLM as a judge.
Usar um LLM como juiz é atraente porque é rápido e barato, mas exige cuidado. O juiz pode ter os mesmos enviesamentos do modelo avaliado, favorecer respostas longas ou ser sensível à ordem das opções. A prática saudável é calibrar o juiz contra um conjunto avaliado por pessoas e usá-lo para triagem, não como veredicto final em decisões críticas.
Alucinações e fidelidade à fonte
A alucinação — quando o modelo afirma algo falso com confiança — é o risco que mais mina a confiança dos utilizadores. Em sistemas com RAG, a pergunta-chave não é apenas "a resposta está certa?", mas "a resposta está apoiada nos documentos recuperados?". Uma resposta certa por acaso, sem suporte nas fontes, é um problema à espera de acontecer.
Para medir isto, verifica-se se cada afirmação relevante da resposta se encontra no contexto fornecido. Pode fazer-se com revisão humana em amostras e com verificações automáticas que comparam a resposta às fontes. Quando a taxa de afirmações não suportadas sobe, o problema costuma estar na recuperação — documentos errados ou insuficientes — e não no modelo.
Custo, latência e robustez: avaliar para além da qualidade
Um sistema excelente que custa demasiado ou demora demasiado não chega a produção. A avaliação séria mede também o custo por resposta (número de tokens e chamadas), a latência (tempo até à primeira palavra e tempo total) e a robustez (o que acontece com perguntas mal escritas, muito longas ou em várias línguas).
Vale ainda testar a estabilidade: a mesma pergunta feita várias vezes deve dar respostas coerentes. Variação enorme entre execuções é sinal de que o sistema é frágil e difícil de controlar. Estas medidas não são detalhes técnicos; são o que separa um protótipo de um produto.
Erros comuns ao avaliar IA generativa
Alguns padrões repetem-se em muitas equipas. O primeiro é avaliar só com exemplos fáceis e concluir que funciona sempre. O segundo é confiar numa métrica automática de texto como se fosse verdade absoluta. O terceiro é testar uma vez, aprovar e nunca mais medir — quando basta uma mudança de versão do modelo para tudo mudar.
Há ainda o erro de misturar o conjunto de avaliação com os exemplos usados para afinar prompts: se o sistema estudou para o teste, os resultados enganam. E, por fim, o erro de olhar só para a média e ignorar os piores casos — muitas vezes é uma resposta má, num momento sensível, que destrói a confiança de um cliente.
Mini-caso: um assistente interno numa empresa de serviços
Uma empresa de serviços financeiros construiu um assistente para responder a perguntas de colaboradores sobre políticas internas, com RAG sobre os seus documentos. Na demonstração, tudo parecia perfeito. Antes de abrir a toda a empresa, a equipa preparou um conjunto de 120 perguntas reais, com respostas de referência aprovadas pela área de conformidade.
A primeira avaliação foi reveladora: 82% das respostas estavam corretas, mas 15% continham afirmações não suportadas pelos documentos, e o tempo médio de resposta era de nove segundos. Ao investigar, a equipa percebeu que o problema estava na recuperação, que trazia documentos desatualizados. Melhorou a indexação e acrescentou uma instrução para o sistema recusar quando não encontrasse base. Numa segunda ronda, as afirmações não suportadas caíram para 4% e a latência para quatro segundos. Só então avançou — e manteve a avaliação a correr semanalmente para detetar regressões.
Na prática
Avaliar um sistema de IA generativa não é um exame único, é um hábito. Começa por definir o que é sucesso, monta um conjunto de casos representativo, mede qualidade, fidelidade e segurança em conjunto e não te esqueças do custo e da latência. Usa avaliação humana onde importa e automatiza o resto para poder repetir a medição a cada mudança.
A recompensa é dupla: menos surpresas desagradáveis em produção e uma base objetiva para decidir. Em IA generativa, a diferença entre um brinquedo impressionante e um produto de confiança não está no modelo — está na disciplina com que o avaliamos.
