Os modelos de linguagem não cometem apenas erros — fabricam a realidade com total confiança. Um Agente de IA pode alegar que criou registos de base de dados que não existem, ou insistir que executou ações que nunca tentou. Para equipas que implementam estes sistemas em produção, essa distinção determina como resolve o problema.
Dmytro Kyiashko é especialista em testar sistemas de IA. O seu trabalho foca-se numa questão: como detetar sistematicamente quando um modelo mente?
O problema de testar disparates confiantes
O software tradicional falha de forma previsível. Uma função quebrada retorna um erro. Uma API mal configurada fornece um sinal de falha determinístico — tipicamente um código de estado HTTP padrão e uma mensagem de erro legível que explica o que correu mal.
Os modelos de linguagem quebram de forma diferente. Relatam a conclusão de tarefas que nunca iniciaram, recuperam informação de bases de dados que nunca consultaram e descrevem ações que existem apenas nos seus dados de treino. As respostas parecem corretas. O conteúdo é fabricado.
"Cada Agente de IA opera de acordo com instruções preparadas por engenheiros", explica Kyiashko. "Sabemos exatamente o que o nosso agente pode e não pode fazer." Esse conhecimento torna-se a base para distinguir alucinações de erros.
Se um agente treinado para consultar uma base de dados falha silenciosamente, isso é um erro. Mas se retorna resultados detalhados de consulta sem tocar na base de dados? Isso é uma alucinação. O modelo inventou resultados plausíveis com base em padrões de treino.
Verificação contra a verdade fundamental
A abordagem de Kyiashko centra-se na verificação contra o estado real do sistema. Quando um agente alega ter criado registos, os seus testes verificam se esses registos existem. A resposta do agente não importa se o sistema a contradiz.
"Normalmente uso diferentes tipos de testes negativos — tanto unitários como de integração — para verificar alucinações de LLM", nota. Estes testes solicitam deliberadamente ações para as quais o agente não tem permissão, depois validam que o agente não confirma falsamente o sucesso e que o estado do sistema permanece inalterado.
Uma técnica testa contra restrições conhecidas. Um agente sem permissões de escrita na base de dados é solicitado a criar registos. O teste valida que não apareceram dados não autorizados e que a resposta não alega sucesso.
O método mais eficaz usa dados de produção. "Uso o histórico de conversas de clientes, converto tudo para formato JSON e executo os meus testes usando este ficheiro JSON." Cada conversa torna-se um caso de teste que analisa se os agentes fizeram alegações que contradizem os registos do sistema.
Isto deteta padrões que os testes sintéticos perdem. Utilizadores reais criam condições que expõem casos extremos. Os registos de produção revelam onde os modelos alucinam durante o uso real.
Duas estratégias de avaliação
Kyiashko usa duas abordagens complementares para avaliar sistemas de IA.
Avaliadores baseados em código tratam da verificação objetiva. "Os avaliadores baseados em código são ideais quando a definição de falha é objetiva e pode ser verificada com regras. Por exemplo: analisar estrutura, verificar validade JSON ou sintaxe SQL", explica.
Mas algumas falhas resistem à classificação binária. O tom foi apropriado? O resumo foi fiel? A resposta foi útil? "Os avaliadores LLM-as-Judge são usados quando o modo de falha envolve interpretação ou nuances que o código não consegue capturar."
Para a abordagem LLM-as-Judge, Kyiashko confia no LangGraph. Nenhuma abordagem funciona sozinha. Estruturas eficazes usam ambas.
O que a formação QA clássica não aborda
Engenheiros de qualidade experientes têm dificuldades quando testam sistemas de IA pela primeira vez. As suposições que os tornaram eficazes não se transferem.
"No QA clássico, sabemos exatamente o formato de resposta do sistema, sabemos exatamente o formato dos dados de entrada e saída", explica Kyiashko. "No teste de sistemas de IA, não há tal coisa." Os dados de entrada são um prompt — e as variações na forma como os clientes formulam pedidos são infinitas.
Isto exige monitorização contínua. Kyiashko chama-lhe "análise contínua de erros" — rever regularmente como os agentes respondem a utilizadores reais, identificar onde fabricam informação e atualizar os conjuntos de testes em conformidade.
O desafio agrava-se com o volume de instruções. Os sistemas de IA requerem prompts extensos que definem comportamento e restrições. Cada instrução pode interagir de forma imprevisível com as outras. "Um dos problemas dos sistemas de IA é o enorme número de instruções que precisam constantemente de ser atualizadas e testadas", nota.
A lacuna de conhecimento é significativa. A maioria dos engenheiros carece de compreensão clara sobre métricas apropriadas, preparação eficaz de conjuntos de dados ou métodos fiáveis para validar resultados que mudam a cada execução. "Criar um Agente de IA não é difícil", observa Kyiashko. "Automatizar o teste desse agente é o principal desafio. Das minhas observações e experiência, gasta-se mais tempo a testar e otimizar sistemas de IA do que a criá-los."
Lançamentos semanais fiáveis
As alucinações corroem a confiança mais rapidamente do que os erros. Uma funcionalidade quebrada frustra utilizadores. Um agente que fornece informação falsa com confiança destrói a credibilidade.
A metodologia de teste de Kyiashko permite lançamentos semanais fiáveis. A validação automatizada deteta regressões antes da implementação. Sistemas treinados e testados com dados reais tratam a maioria dos pedidos de clientes corretamente.
A iteração semanal gera vantagem competitiva. Os sistemas de IA melhoram através da adição de capacidades, refinamento de respostas e expansão de domínios.
Porque é que isto importa para a engenharia de qualidade
Empresas que integram IA crescem diariamente. "O mundo já viu os benefícios de usar IA, por isso não há volta a dar", argumenta Kyiashko. A adoção de IA acelera em todos os setores — mais startups a lançar, mais empresas a integrar inteligência em produtos principais.
Se os engenheiros constroem sistemas de IA, devem compreender como testá-los. "Mesmo hoje, precisamos de compreender como os LLMs funcionam, como os Agentes de IA são construídos, como estes agentes são testados e como automatizar estas verificações."
A engenharia de prompts está a tornar-se obrigatória para engenheiros de qualidade. O teste de dados e a validação dinâmica de dados seguem a mesma trajetória. "Estas já devem ser as competências básicas dos engenheiros de teste."
Os padrões que Kyiashko vê em todo o setor confirmam esta mudança. Através do seu trabalho a rever artigos técnicos sobre avaliação de IA e a avaliar arquiteturas de startups em fóruns técnicos, as mesmas questões aparecem repetidamente: equipas em todo o lado enfrentam problemas idênticos. Os desafios de validação que resolveu em produção há anos estão agora a tornar-se preocupações universais à medida que a implementação de IA escala.
Infraestrutura de teste escalável
A metodologia de Kyiashko aborda princípios de avaliação, avaliação de conversas com múltiplas voltas e métricas para diferentes modos de falha.
O conceito central: testes diversificados. A validação ao nível do código deteta erros estruturais. A avaliação LLM-as-Judge permite avaliar a eficácia e precisão do sistema de IA dependendo de qual versão de LLM está a ser usada. A análise manual de erros identifica padrões. Os testes RAG verificam que os agentes usam o contexto fornecido em vez de inventar detalhes.
"A estrutura que descrevo baseia-se no conceito de uma abordagem diversificada aos testes de sistemas de IA. Usamos cobertura ao nível do código, avaliadores LLM-as-Judge, análise manual de erros e Evaluating Retrieval-Augmented Generation." Múltiplos métodos de validação a trabalhar em conjunto detetam diferentes tipos de alucinação que abordagens únicas perdem.
O que vem a seguir
O campo define melhores práticas em tempo real através de falhas de produção e refinamento iterativo. Mais empresas implementam IA generativa. Mais modelos tomam decisões autónomas. Os sistemas tornam-se mais capazes, o que significa que as alucinações se tornam mais plausíveis.
Mas testes sistemáticos detetam fabricações antes que os utilizadores as encontrem. Testar alucinações não é sobre perfeição — os modelos terão sempre casos extremos onde fabricam. É sobre detetar fabricações sistematicamente e impedir que cheguem à produção.
As técnicas funcionam quando aplicadas corretamente. O que falta é compreensão generalizada de como implementá-las em ambientes de produção onde a fiabilidade importa.
Dmytro Kyiashko é um Software Developer in Test especializado em testes de sistemas de IA, com experiência na construção de estruturas de teste para IA conversacional e agentes autónomos. O seu trabalho examina desafios de fiabilidade e validação em sistemas de IA multimodais.
