Alucinação é propriedade do sistema, não bug do modelo

Quando uma feature afirma algo falso com confiança, o post-mortem geralmente termina numa palavra: alucinação. Como se o modelo tivesse um defeito que um modelo melhor vai consertar. Eu leio esses post-mortems de outro jeito. O modelo fez o que um modelo de linguagem faz: produziu a continuação mais plausível do contexto que recebeu. O sistema fez uma pergunta que o contexto não respondia, não deu a ele nenhuma forma de dizer isso e entregou o resultado ao usuário sem nenhuma verificação no meio. A afirmação falsa é propriedade desse arranjo inteiro, não dos pesos.

O modelo está fazendo o trabalho dele

Um modelo de linguagem é um motor de plausibilidade. Dado um contexto, produz texto que parece pertencer ali. Quando o contexto contém a resposta, plausível e verdadeiro coincidem. Quando não contém, o modelo produz texto plausível mesmo assim, porque é a única coisa que ele consegue fazer. Chamar isso de bug é como chamar de bug um buscador que retorna resultados para uma consulta sem bons matches. O motor ranqueou o que tinha. Se o primeiro resultado deve ser mostrado como resposta é decisão de quem chamou.

Onde o sistema convida a alucinação

Costumo prever onde uma feature vai alucinar só lendo a arquitetura. Retrieval que não retorna nada relevante, seguido de um prompt que diz "responda a pergunta" sem permissão para recusar. Contextos truncados em silêncio, de modo que o modelo nunca vê a frase que importava. Perguntas sobre números, datas e nomes, que são exatamente as coisas que um modelo pior gera e melhor extrai. Prompts abertos onde um estruturado teria obrigado o modelo a citar ou se abster. Cada um desses é uma escolha de design, e cada um torna a saída falsa mais provável, independente do modelo por baixo.

Design que reduz

As contramedidas são estruturais, não engenhosas. Dê ao modelo os fatos e diga para usar só aqueles. Dê uma saída explícita: um campo no structured output que diz "não encontrado no contexto", que a interface mostra com honestidade. Verifique em código as partes extraíveis: se o modelo cita um trecho, confira que o trecho existe e contém a afirmação. Separe geração de decisão: o modelo rascunha, o código valida, uma pessoa aprova onde o risco exige. E meça a taxa: amostre saídas de produção, rotule, acompanhe a fração sem sustentação. Uma taxa que você mede cai. Uma taxa que você nomeia e nunca mede fica onde está.

Meça como taxa

A palavra alucinação esconde um número, e o número é o que importa. Numa feature com boa camada de retrieval, caminho explícito de abstenção e validação dos fatos citados, a taxa de afirmações sem suporte pode ser muito baixa, e baixa o bastante para o produto. Numa feature sem nada disso, pode ser alta o suficiente para que a escolha do modelo quase não importe. Quando audito, peço a taxa e o conjunto de evals que a produziu. Times que têm o número já tratam o problema como propriedade do sistema. Times que têm a palavra ainda estão esperando um modelo melhor.

Responsabilidade

Isso importa mais onde a saída alimenta uma decisão real. Em trabalho que toca saúde, ciência ou dinheiro, toda afirmação precisa de evidência, todo resultado precisa de validação e toda decisão precisa de uma pessoa com o nome nela. Esse é o princípio por trás da ELUCENIA, e não é uma restrição sobre o modelo. É a arquitetura que torna o modelo seguro de usar. Alucinação é o que acontece quando um sistema pula uma dessas etapas e torce para que plausibilidade baste. Às vezes basta. Nos lugares que importam, nunca.