Alucinação em produção

A resposta curta

Um modelo não sabe que está errado. Ele produz a continuação mais plausível dado o que lhe foi mostrado, e quando não foi mostrado o suficiente, plausível e correto se separam.

Então alucinação não é defeito que se corrige com remendo. É o comportamento padrão da tecnologia, e o trabalho é restringir as condições em que ela acontece e detectar quando acontece.

O que é de fato

O modelo não está recuperando um fato e errando. Está gerando texto que se encaixa no padrão de uma resposta correta. Fluência e acurácia são produzidas pelo mesmo mecanismo, e é por isso que resposta alucinada soa exatamente tão confiante quanto verdadeira.

É essa propriedade que torna aquilo perigoso em uso corporativo. Um sistema que falhasse de forma óbvia seria seguro. Um sistema que falha bonito exige alguém conferindo.

As três causas

Sem ancoragem. Perguntaram ao modelo algo para o qual ele não tem fonte, e ele preencheu a lacuna. A causa mais comum e a mais corrigível.

Recuperação ruim. Material foi fornecido, mas o material errado, então o modelo raciocinou corretamente sobre documento irrelevante. Isso é diagnosticado como problema de modelo o tempo todo, e não é.

Pressão para responder. O sistema foi construído sem uma forma aceitável de dizer que não sabe, então ele produz alguma coisa. Recusa precisa ser desenhada, ou o modelo sempre vai preferir um chute confiante. A metade de recuperação disso está em RAG.

Por que piora em produção

Em teste, as perguntas vêm de quem sabe para que serve o sistema. Em produção vêm de todo mundo, inclusive de quem pergunta sobre coisas que ele nunca deveria cobrir.

Enquanto isso o acervo deriva. Documentos são adicionados, políticas mudam, e versões antigas continuam no índice. O modelo agora está ancorado em material que se contradiz, e ele vai escolher um com confiança.

Nada disso aparece como erro. Latência normal, nenhuma exceção lançada, e o único sinal é que as respostas estão silenciosamente menos certas do que eram.

Ancoragem é a correção principal

Dê o material ao modelo e exija que a resposta venha dali. Essa mudança sozinha remove a maior parte da alucinação na maioria dos sistemas corporativos, porque a maior parte era o modelo preenchendo uma lacuna que não precisava existir.

A disciplina é tornar a ancoragem verificável em vez de pedida. Cheque se as afirmações da saída são sustentadas pelos trechos fornecidos, e trate resposta não sustentada como falha mesmo quando ela por acaso está certa, porque na próxima vez não estará.

Citação e verificação

Exigir que o sistema cite qual trecho sustenta cada afirmação faz duas coisas. Dá ao humano um jeito rápido de verificar, e torna o modo de falha visível: resposta sem citação vira alerta em vez de risco silencioso.

Saiba que citação também pode ser fabricada. Verifique se o trecho citado existe e contém de fato o que é alegado, em vez de confiar na referência porque ela parece uma.

Recusa é recurso

Um sistema que diz não ter a informação vale mais que um que sempre responde, e a maioria dos times constrói o segundo por acidente, porque recusa parece fracasso numa demo.

Desenhe o caminho da recusa de propósito: o que dispara, o que o usuário vê, para onde escala. Depois meça a taxa de recusa, porque as duas direções informam. Baixa demais significa que está chutando. Alta demais significa que a recuperação está falhando. Isso faz parte da mesma estratificação de guardrails.

Meça a taxa

Pare de discutir se o sistema alucina e produza um número. Pegue um conjunto de referência com respostas conhecidas, rode, e pontue com que frequência a saída não é sustentada pela fonte. Depois amostre tráfego de produção e pontue igual. O método está em evals de LLM e o encanamento em observabilidade.

Quando existe número e tendência, a conversa deixa de ser opinião e vira engenharia, e você consegue dizer se a mudança de prompt da semana passada ajudou ou atrapalhou.

Quando chega no cliente

Tenha o caminho decidido antes de acontecer: quem é avisado, como a resposta é recuperada e corrigida, e como o caso entra no conjunto de avaliação para não poder se repetir em silêncio.

A falha organizacional é tratar cada incidente como um pedido de desculpas isolado em vez de como dado. Toda alucinação que chega no cliente é um caso de teste que você não tinha, e adicioná-lo é a melhoria mais barata disponível. Esse ciclo é central em como construímos IA em produção, ponta a ponta.