Obter uma resposta de um modelo de IA por si só ainda não significa que o sistema funcione corretamente. No caso de software clássico, muitas vezes conseguimos verificar de forma inequívoca se uma função retornou o resultado esperado. Em sistemas de IA, a resposta pode ser fluida, lógica e convincente, e mesmo assim conter erros.
Por isso, junto com o desenvolvimento da IA, surge um novo problema de engenharia: como medir sistematicamente a qualidade de um sistema cujas respostas nem sempre são idênticas?
É exatamente essa a área de AI evaluation, ou seja, a avaliação de sistemas de inteligência artificial.
E ela é muito mais ampla do que verificar se um chatbot “responde bem”.
Testar software clássico e testar IA não é a mesma coisa
Vamos imaginar uma função simples em um aplicativo.
O usuário digita: 2 + 2
O sistema deve retornar: 4
Se retornar 5, temos um erro inequívoco.
Podemos preparar um teste: expect(calculate("2 + 2")).toBe(4)
e sempre obteremos um resultado claro: o teste passa ou não passa.
Em sistemas de IA, a situação é diferente.
O usuário pode perguntar: "Escreva uma resposta curta para um cliente que pergunta sobre o prazo de entrega do pedido."
O sistema pode gerar várias respostas diferentes. Todas podem estar linguisticamente corretas. Todas podem soar profissionais. Mas uma pode conter um prazo falso, outra pode ser longa demais, a terceira pode omitir uma informação importante e a quarta pode ser perfeita.
Portanto, não basta verificar se a resposta foi tecnicamente gerada.
É preciso verificar se ela atende a critérios específicos de qualidade.
Primeiro problema: uma boa resposta nem sempre é verdadeira
Essa é uma das características mais marcantes da IA generativa.
O modelo pode gerar uma resposta que soa muito convincente, mas não tem respaldo nas fontes de dados.
No caso de um sistema que usa RAG, o problema é ainda mais interessante. O sistema pode receber uma pergunta, buscar alguns trechos da documentação e então gerar uma resposta.
Nesse caso, é preciso verificar pelo menos três coisas:
- As informações corretas foram encontradas? O mecanismo de busca recuperou trechos realmente relacionados à pergunta?
- A resposta usa as informações encontradas? O modelo não acrescentou algo que não existia nas fontes?
- A resposta realmente responde à pergunta? Pode haver um retrieval funcionando corretamente, mas uma resposta final ruim.
É justamente por isso que a avaliação de RAG separa, entre outros, aspectos como relevância do contexto recuperado, completude da busca, correção da resposta e sua conformidade com as fontes.
Essa é uma mudança importante na forma de pensar os testes.
Já não testamos apenas: pergunta → resposta
mas toda a cadeia: pergunta → busca → contexto → modelo → resposta
É possível ter um bom modelo e um mau sistema de IA
Essa é outra coisa que é fácil de esquecer.
Uma empresa pode escolher um modelo de linguagem muito bom e, ainda assim, criar um produto de IA ruim.
Por quê? Porque a qualidade do sistema final não depende apenas do modelo.
Também contam:
- a qualidade dos dados,
- a forma de preparar o contexto,
- o prompt,
- a forma de buscar informações,
- os parâmetros do modelo,
- as ferramentas disponibilizadas à IA,
- a lógica do aplicativo,
- a memória,
- a forma de tratar erros,
- as proteções,
- a forma de avaliar as respostas.
Isso significa que a pergunta: "Qual modelo é o melhor?"
muitas vezes é menos útil do que: "Qual modelo funciona melhor no nosso caso de uso específico?"
Um modelo que se sai muito bem na geração de conteúdo de marketing não precisa ser a melhor solução para classificação de documentos, análise de dados ou execução de processos de negócios.
Por isso, a comparação entre modelos deve acontecer com base em tarefas reais que o sistema precisa executar.
Primeiro, é preciso criar seu próprio conjunto de testes
Não dá para avaliar um sistema de IA de forma sensata se não soubermos o que esperamos dele.
Por isso, um dos elementos mais importantes da avaliação é a preparação de um dataset de teste, ou seja, um conjunto de casos reais ou representativos.
Por exemplo, uma empresa está construindo uma IA para o atendimento ao cliente.
Em vez de verificar manualmente uma resposta após cada mudança de prompt, é possível preparar algumas centenas de casos:
- perguntas simples,
- perguntas ambíguas,
- perguntas que contenham pressupostos incorretos,
- perguntas que exijam buscar um documento,
- perguntas sobre exceções,
- perguntas sobre reclamações,
- perguntas que exijam recusa,
- perguntas que contenham dados que a IA não deve revelar.
Cada mudança no sistema pode então ser executada sobre o mesmo conjunto.
E é justamente aqui que a IA começa a se parecer com software clássico.
Já não testamos uma resposta isolada. Testamos o comportamento do sistema em todo o conjunto de casos.
O prompt também pode ser testado
Muitas vezes, o prompt é tratado como um texto que alguém escreveu uma vez e deixou em produção.
Na realidade, ele pode ser parte da lógica do aplicativo.
Mudar uma única frase pode causar:
- melhoria da resposta em um cenário,
- piora da resposta em outro,
- maior tendência a recusar,
- mais alucinações,
- respostas mais longas,
- custo mais alto,
- maior consumo de tokens.
Por isso, o prompt deve ser tratado de forma semelhante ao código.
Se mudamos o prompt, vale a pena saber:
- o que melhorou?
- o que piorou?
- houve regressão?
É justamente por isso que a avaliação automática está ganhando cada vez mais importância, e não a avaliação manual de algumas respostas de exemplo.
A IA pode passar no teste e ainda ser um mau produto
Vamos supor que preparamos 100 casos de teste.
O sistema respondeu corretamente em 95. O resultado parece excelente. Mas e se as cinco respostas erradas disserem respeito a situações críticas?
Se um chatbot responde a perguntas sobre horário de funcionamento, cinco erros podem ser um problema.
Se a IA ajuda um funcionário a analisar documentos financeiros, médicos ou jurídicos, a importância desses erros pode ser completamente diferente.
Por isso, a média sozinha não basta.
Também precisamos de ponderação dos casos.
Podemos considerar que:
- uma pergunta comum tem peso 1,
- um erro importante tem peso 5,
- um erro de segurança tem peso 10,
- a divulgação de uma informação confidencial tem peso 100.
Então o sistema não recebe “95 por cento”. Recebemos uma imagem muito mais útil do risco.
Nem tudo pode ser medido com um único número
Este é um dos problemas mais importantes da avaliação de IA.
Podemos ter várias métricas:
- Accuracy - a resposta está correta?
- Relevance - responde à pergunta?
- Faithfulness / groundedness - baseia-se nas fontes fornecidas?
- Context precision - os trechos recuperados são relevantes?
- Context recall - o sistema encontrou as informações necessárias?
- Safety - não executa ações indesejadas?
- Latency - quanto tempo o usuário espera?
- Cost - quanto custa executar a tarefa?
Assim, um RAG pode ter uma qualidade de resposta muito boa, mas ao mesmo tempo consumir uma enorme quantidade de contexto e gerar um custo inaceitável.
Outro sistema pode ser muito barato e rápido, mas cometer erros demais.
Portanto, não existe um único número universal que diga se a IA é “boa”. A qualidade precisa ser definida no contexto de uma aplicação concreta.
E quanto a avaliar a IA por outra IA?
Aqui surge outro mecanismo interessante.
Uma das formas de automatizar a avaliação é usar o modelo como juiz, ou seja, LLM-as-a-judge.
Por exemplo:
O modelo A gera a resposta.
O modelo B recebe a pergunta, a resposta e critérios específicos.
Em seguida, ele avalia:
- correção,
- aderência à instrução,
- completude,
- estilo,
- segurança.
As ferramentas modernas de avaliação também permitem combinar essa avaliação com comparações textuais clássicas, scripts próprios ou graders baseados em regras específicas.
Isso aumenta enormemente a escala de testes. Mas não significa que o ser humano deixe de ser necessário. O modelo avaliador também pode errar. Por isso, em sistemas de maior importância para o negócio, vale combinar avaliações automáticas com revisão periódica de especialistas.
O maior problema: regressão
Imagine um sistema que funciona muito bem. A equipe muda o modelo para uma versão mais nova. A nova versão é mais rápida e mais barata. Parece, então, que tudo está indo na direção certa.
Após a implantação, porém, descobre-se que:
- as respostas são menos precisas,
- o modelo recusa responder com mais frequência,
- usa pior a documentação,
- interpreta as instruções de forma diferente,
- em alguns cenários começa a fornecer informações incorretas.
Isso é justamente AI regression.
No software clássico, conhecemos regressão há anos. Na IA também precisamos detectá-la, mas o problema é mais difícil, porque o comportamento do sistema pode mudar sem um “erro” clássico. Por isso, toda mudança maior deve ser comparada com a versão anterior.
Modelo.
Prompt.
Embedding.
Retriever.
Documentação.
Lógica do agente.
Parâmetros.
Cada um desses elementos pode influenciar o resultado.
Não basta avaliar o agente apenas pela resposta final
Fica ainda mais difícil no caso de agentes de IA.
Um chatbot clássico pode executar uma única tarefa: pergunta → resposta.
Um agente pode agir de forma completamente diferente: objetivo → plano → ferramenta → resultado → próximo passo → decisão → ação → resposta.
Se o agente não atingiu o objetivo, queremos saber não apenas que ele falhou.
Queremos saber: onde ele errou?
- Entendeu mal a tarefa?
- Escolheu a ferramenta errada?
- Passou um parâmetro incorreto?
- Buscou os dados errados?
- Tomou a decisão errada depois de receber o resultado?
- Executou passos demais?
- Parou cedo demais?
Nas pesquisas sobre avaliação de agentes, cada vez mais se analisa não apenas o resultado final, mas também o percurso da ação, o uso de ferramentas, o planejamento, a memória, a confiabilidade e a segurança.
Isso significa que o futuro dos testes de IA estará em grande parte ligado à análise de traces, isto é, ao percurso completo de funcionamento do sistema.
A IA precisa de algo semelhante a CI/CD
Se a IA faz parte do produto, não se pode testá-la apenas antes do primeiro deployment.
O sistema vai mudar.
O modelo vai mudar.
O prompt vai mudar.
A base de conhecimento vai mudar.
A forma de busca vai mudar.
A configuração vai mudar.
Por isso, a avaliação deve entrar no processo de desenvolvimento.
O esquema pode ser o seguinte: mudança → testes → avaliação → comparação com a versão anterior → decisão de implantação
Se a nova versão melhora a qualidade em uma área, mas ultrapassa o limite definido de erros em outra, o deployment pode ser interrompido.
É uma filosofia muito parecida com a do CI/CD clássico, mas os critérios são diferentes.
No caso de aplicações de IA, podemos verificar ao mesmo tempo a qualidade da resposta, a correção, a segurança, o custo e a latência. Já existem soluções de pesquisa que combinam avaliação com observability e gates de qualidade no processo de implantação de sistemas LLM/RAG.
Então, é possível testar IA da mesma forma que software clássico?
Sim, mas apenas em parte.
A abordagem clássica continua necessária.
Testamos:
- API,
- integrações,
- permissões,
- validação de dados,
- erros,
- timeouts,
- segurança,
- desempenho,
- lógica da aplicação.
Mas não podemos parar aí.
Surge uma segunda camada: avaliação do comportamento da IA.
- A resposta está correta?
- Ela está de acordo com as fontes?
- O modelo segue as instruções?
- O sistema se comporta corretamente em situações inesperadas?
- O agente escolhe as ferramentas certas?
- A nova versão não piorou a qualidade?
- O custo de operação continua aceitável?
- O usuário realmente recebe valor?
Isso já não é um teste unitário clássico.
O melhor teste de IA nem sempre é um teste de laboratório
Há ainda outro elemento muito importante.
O sistema pode ter um ótimo desempenho em um conjunto de testes preparado, e mesmo assim ter problemas no mundo real. Por isso vale a pena observar também as interações reais. Não para que cada usuário vire testador. A ideia é que o sistema possa ser continuamente aprimorado com base em casos reais:
- onde os usuários corrigem a IA,
- onde pedem para repetir a პასუხa,
- onde interrompem a conversa,
- onde escalam o caso para um humano,
- onde o agente não atinge o objetivo,
- onde surgem perguntas atípicas.
Dessa forma surge um ciclo contínuo de avaliação: usuário → ação da IA → resultado → análise → novo caso de teste → nova versão do sistema
Esse é um modelo de desenvolvimento completamente diferente de um simples “implementamos IA e ela funciona”.
A IA não deve ser avaliada com a pergunta “isso funciona?”
Isso é pouco demais.
Melhores perguntas são:
- Com que frequência ela funciona corretamente?
- Em quais situações ela erra?
- Quão graves são esses erros?
- A nova versão é melhor do que a anterior?
- O sistema é seguro o suficiente?
- As respostas se baseiam nos dados corretos?
- Quanto custa alcançar um resultado específico?
Só esse conjunto de perguntas permite falar de um sistema de IA maduro.
A mudança mais importante de mentalidade
Durante anos, no desenvolvimento de software, vigorou uma regra simples: o código deve funcionar.
Em sistemas de IA, é preciso ampliá-la: o sistema deve funcionar bem, de forma previsível e mensurável.
Isso faz uma enorme diferença. Porque a IA não é uma função que sempre retorna o mesmo resultado. É um sistema probabilístico, cujo comportamento depende do modelo, dos dados, do contexto, das instruções e de toda a arquitetura ao seu redor.
Por isso, uma implementação profissional de IA não termina no momento em que o modelo começa a responder.
É aí que começa a pergunta: como sabemos que podemos confiar nele?
E é justamente essa pergunta que uma avaliação bem projetada deve responder.
No futuro, testar sistemas de IA provavelmente se tornará um elemento tão natural do processo de desenvolvimento quanto testes unitários, testes de integração ou monitoramento. Não porque a IA seja “perigosa por definição”. Simplesmente porque um sistema cujo resultado nem sempre é determinístico exige outra forma de medir a qualidade.
E quanto mais a IA passa de gerar texto para lidar com processos reais, usar dados, RAG e executar ações por meio de agentes, mais importante se torna não apenas a pergunta “a IA consegue fazer isso?”, mas também: “conseguimos provar que ela faz isso bem o suficiente?”
