Leonardo Peron5 min de leitura
O cliente pergunta pelo status da compra e o agente responde citando um número de pedido que não existe em sistema nenhum. Ou informa um prazo de troca que ninguém na empresa escreveu, no mesmo tom natural do resto da conversa.
Isso tem nome — alucinação — e o nome atrapalha, porque sugere defeito. Não é defeito de configuração nem sinal de modelo mal escolhido: é consequência de como a ferramenta funciona.
O texto vizinho trata do caso depois que ele precisa chegar a uma pessoa. Este trata da etapa anterior: reduzir a chance de a invenção acontecer.
O modelo não distingue lembrar de inventar
Um modelo de linguagem produz a continuação mais plausível do texto que recebeu. Quando a informação estava presente no que ele leu, o plausível coincide com o verdadeiro. Quando não estava, ele continua produzindo o plausível, agora sem nada por trás.
De fora, os dois casos são idênticos: mesmo tom, mesma fluência, mesma estrutura. Não existe hesitação nem marca que separe um do outro, e é isso que torna o problema caro — ninguém confere o que soa certo. Pedir ao modelo que não invente ajuda pouco: ele não tem como saber que está inventando.
Reduzir e eliminar são promessas diferentes
Instrução melhor, exemplos no formato certo, permissão explícita para admitir desconhecimento: tudo isso reduz a frequência, e nada zera.
A distinção é de projeto, não filosófica. Quem assume que dá para reduzir convive com o resto por meio de verificação e amostragem. Quem promete eliminar tira a verificação, que era o que segurava o problema.
E o que muda o patamar de verdade não é a instrução. É tirar a informação de dentro do modelo.
Ancorar em fonte verificável
O número do pedido não deveria vir da memória do modelo, e sim de uma consulta ao sistema que tem os pedidos, feita na hora. A política de troca não deveria ser recontada de cabeça: deveria vir do documento em que está escrita.
Nesse arranjo o modelo muda de papel: deixa de ser a fonte e passa a ser o redator — entende a pergunta, busca, lê o que voltou e escreve. Continua podendo errar, lendo mal ou misturando registros, mas erra sobre algo que existe. E erro sobre algo que existe é conferível.
Três consequências de desenho vêm junto:
O agente não responde sobre o que não consultou. Se a pergunta é sobre um pedido e a consulta não foi feita, não há resposta a dar.
Quando a busca não retorna nada, a saída é dizer que não encontrou. Parece óbvio e quase nunca está implementado, porque exige que o processo aceite essa saída sem tratá-la como falha. Se a métrica interna pune "não encontrei", a pressão empurra o sistema de volta à invenção.
A resposta carrega de onde saiu. O identificador do registro, o trecho do documento, a data da versão consultada.
Exigir a citação muda o sistema, não o prompt
Este é o ponto que costuma ser lido como detalhe e é estrutural: para o agente citar a fonte, precisa existir algo citável.
Isso significa documento com identificador estável, versão e data. Significa trecho recuperável, não um arquivo inteiro anexado para alguém procurar. Significa registro com chave. Se a política de troca só existe na cabeça de quem atende, não há fonte para citar — e o problema deixou de ser de IA muito antes de alguém pensar em IA.
Significa também que a citação precisa ser conferível por quem lê. Apontar para um documento que ninguém consegue abrir é pior do que não citar: cria aparência de rastreabilidade e desliga a desconfiança de quem revisa.
A parte boa é que essa exigência se verifica sozinha. Se o agente não conseguiu citar, ou citou algo que não abre, o caso não sai — e a checagem é mecânica.
A verificação barata que pega a classe inteira
O caso mais perigoso não é a resposta esquisita. É a invenção com o formato certo: identificador com a quantidade certa de dígitos, data no padrão da casa, prazo que soa como prazo de política. Nada dispara suspeita humana.
Contra isso, a defesa não pode ser humana. Antes de a resposta sair, o sistema confere: esse identificador existe na base? O documento citado está no índice? Esse valor bate com o registro? Se não bater, a resposta não é enviada — vai para revisão ou volta para nova tentativa com o dado real.
É barato, roda em milissegundos e cobre a classe inteira de invenções que referenciam algo que deveria existir. Sobra a invenção sobre o que não tem registro — interpretação, opinião, promessa — contida limitando o que o agente tem permissão de afirmar.
Toda invenção aponta para uma lacuna
Quando acontecer, corrigir a resposta é a parte pequena. A pergunta útil é outra: de onde essa informação deveria ter vindo?
Quase sempre a resposta revela um campo que o agente precisava e não tinha, um documento que não está indexado, ou uma regra que a empresa aplica todo dia e nunca escreveu. Anotadas, viram uma lista de lacunas — a melhor lista de melhorias que um projeto de IA produz, porque sai do uso real, não de reunião.
A checagem
Pegue uma resposta que o agente já deu e separe cada afirmação factual: o número, a data, o prazo, o nome, a condição. Para cada uma, aponte o registro ou o trecho que a sustenta.
O que sobrar sem origem é o que ele inventou. E se sobrou nesta resposta, já sobrou em outras — a diferença é que ninguém tinha parado para olhar.