Detetar alucinações da IA: 3 mecanismos de proteção para equipas B2B

Como se manifestam as alucinações da IA nos fluxos de trabalho B2B

Uma alucinação é quando o modelo gera uma resposta com tom seguro mas errada. No B2B aparece em três formas clássicas: (1) inventar um número de encomenda que não existe para um pedido de suporte, (2) "citar" uma data que não está realmente no contrato ao resumi-lo, (3) inventar uma categoria nova ao classificar faturas fora do conjunto definido.

As três partilham o mesmo padrão: sem âncora real, o modelo preenche o vazio. O problema é que a saída parece confiante — mesmo quando errada. "A IA erra" não é acionável; é preciso saber onde e porquê. Os três mecanismos de proteção abaixo fazem isso.

Três mecanismos de proteção: fonte, regras e revisão humana

Verificação de fontes: mostre o documento e o trecho que sustentam a resposta; confirme a relação com a afirmação, não apenas a existência de uma referência. Provas ausentes ou contraditórias devem seguir para revisão.

Verificação de regras: confirme na aplicação a existência da encomenda, a autorização, o montante e a categoria permitida. Um formato válido não demonstra exatidão factual.

Aprovação humana: antes de um pagamento, reembolso ou mensagem vinculativa, uma pessoa autorizada deve ver o resultado exato. Alterações exigem nova aprovação. Não existe uma taxa universal de sucesso. Teste casos corretos, errados e sem fonte: os resultados inválidos devem parar e a fila de revisão deve chegar ao responsável.

Construir um processo de avaliação (eval) antes de lançar

Não é possível detetar uma taxa de alucinação apenas olhando para os resultados; é preciso um conjunto de teste. Construa um "golden set" de 50 a 200 exemplos reais com respostas corretas conhecidas, e garanta que cobre casos-limite — dados em falta, consultas ambíguas, pedidos fora do âmbito. Execute os testes com esse conjunto após cada alteração das instruções (prompts) ou do modelo e antes de colocar a nova versão em produção, não apenas no lançamento inicial.

Acompanhe dois indicadores distintos: a exatidão das respostas e a taxa de abstenção, isto é, a frequência com que o modelo se abstém de responder. Avalie também se essas abstenções são adequadas aos casos em questão. Um modelo que nunca se abstém pode ocultar erros; abster-se muitas vezes reduz a utilidade e, por si só, não demonstra maior segurança. O limiar adequado depende do custo de uma resposta errada e do custo de não responder.

Os testes adversariais são tão importantes como os testes de casos normais — alimente deliberadamente o modelo com consultas concebidas para provocar alucinações: perguntas sobre entidades que não existem, pedidos que misturam dois registos, prompts que pedem para extrapolar para além do documento de origem. Se não conseguir falhar de forma controlada num teste, também não vai falhar de forma controlada em produção.

Trate a avaliação como um processo contínuo, não como uma verificação que se faz apenas uma vez. Sempre que alterar o prompt, trocar de modelo ou adicionar uma nova fonte de documentos, corra novamente o conjunto de avaliação e compare os novos números de exatidão e abstenção com a sua base de referência antes de implementar em produção. É a mesma disciplina dos testes de regressão no software tradicional — só que testa julgamento em vez de lógica.

Que tarefas apresentam maior risco de alucinação

O risco não depende apenas de o texto ser livre ou estruturado. Um lançamento contabilístico errado numa categoria válida também pode causar danos. Avalie impacto, reversibilidade, sensibilidade dos dados e destinatários. Preparar rascunhos não deve dar as mesmas permissões que contactar clientes ou movimentar dinheiro.