Alucinação de IA
Originada da natureza probabilística da geração, a alucinação de IA ocorre quando o modelo produz conteúdo plausível, porém falso, fabricado ou não apoiado pelas evidências fornecidas. Pode envolver fatos, citações, dispositivos, estados, números, procedimentos ou chamadas de ferramenta. Em casa inteligente, uma alucinação sobre “porta trancada” é mais grave que um erro de redação. Grounding, RAG, ferramentas, validação e respostas de incerteza reduzem o problema, mas não o eliminam. Fluência e confiança textual não são indicadores confiáveis de correção.
A evolução dos modelos generativos tornou as respostas mais fluentes, mas não eliminou a possibilidade de produzir afirmações sem suporte. Alucinação de IA é o nome usado para fatos, referências, detalhes, estados ou relações inventadas, incorretas ou inconsistentes com a entrada e as fontes. O termo é discutido porque o modelo não percebe a realidade como uma pessoa; tecnicamente, ele gera tokens prováveis. Ainda assim, descreve um risco operacional. Em casa inteligente, uma resposta pode inventar um dispositivo, atribuir estado desatualizado, criar procedimento inexistente ou afirmar que uma ação ocorreu. O impacto depende do domínio. A mitigação combina fontes, ferramentas, validação, incerteza e restrição de ações. Nenhuma técnica garante taxa zero.
- Há diferentes formas. Alucinação factual contradiz o mundo ou a fonte: informar tensão errada. Alucinação intrínseca contradiz o contexto fornecido. Extrínseca acrescenta informação não sustentada. Citação fabricada inventa documento, página ou URL. Entidade inventada cria um dispositivo. Estado alucinado diz que a luz está apagada sem consulta. Ferramenta alucinada chama função inexistente ou argumentos. Em resumo, o modelo pode errar conteúdo e execução. A classificação ajuda a medir. O conjunto de testes deve refletir. Uma resposta pode conter várias. Não basta perguntar ao próprio modelo se está correto; ele pode confirmar o erro.
- As causas incluem conhecimento paramétrico incompleto ou desatualizado, decodificação, ambiguidade, contexto insuficiente, recuperação ruim, instruções conflitantes e pressão para responder. Modelos são treinados para continuar texto, não para consultar verdade automaticamente. Alinhamento pode incentivar utilidade e reduzir “não sei”, levando a preencher lacunas. Temperatura menor reduz variabilidade, não garante fatos. Modelo maior pode alucinar menos em alguns benchmarks e ainda errar. Uma janela maior pode introduzir mais ruído. RAG pode trazer trecho errado. A ferramenta pode devolver dado desatualizado. A mitigação precisa olhar sistema inteiro. Não existe um botão “sem alucinação”.
- Grounding conecta afirmações a fontes ou dados. Para estado da casa, use APIs com timestamp. Para manuais, RAG com citações. Para cálculos, código. Para previsão, serviço meteorológico. O modelo verbaliza. O prompt manda declarar ausência. A aplicação pode exigir citação por frase e verificar entailment, mas verificadores também falham. Uma abordagem forte restringe a resposta a template preenchido por dados. Em ações críticas, o modelo não é a fonte de estado. O controlador confirma. A UI pode mostrar sensor diretamente. Se há conflito entre sensores, apresenta. A linguagem deve distinguir “o sensor informa”, “o modelo estima” e “não há dado”.
- A recuperação pode reduzir ou aumentar. Se o corpus está completo e o retriever encontra trecho, melhora. Se o chunk é de modelo errado ou está obsoleto, o modelo pode responder com falsa autoridade e citação. Metadados, filtros, versionamento e reranking são necessários. O sistema avalia retrieval separado de generation. Uma resposta não sustentada pode ocorrer mesmo com trecho correto. Métricas como faithfulness e groundedness ajudam, mas avaliação humana em casos críticos. Citações precisam apontar para fonte real. Não gerar referência por memória. Se não há fonte, dizer. Em uma casa, um procedimento elétrico sem manual correto deve ser encaminhado a profissional, não completado.
- Calibração e incerteza melhoram comunicação, mas o texto “tenho 90% de certeza” não é probabilidade validada. Modelos frequentemente são mal calibrados. Use sinais externos: score de intenção, qualidade de recuperação, concordância de sensores, cobertura do schema e histórico de desempenho. A resposta pode dizer “não consegui confirmar”. Para ações, limiares e confirmação. O sistema não deve esconder falha para parecer inteligente. Usuários tendem a confiar em linguagem detalhada. Design reduz: respostas curtas, fonte, timestamp e distinção. Educação explica que a IA pode errar. O controle manual e o log original ficam acessíveis.
- A avaliação precisa de taxonomia e impacto. Crie perguntas com resposta conhecida, sem resposta, conflitantes e adversariais. Meça factualidade, suporte por fonte, citações, estado, argumentos e ações. Para casa, priorize falsos sucessos: afirmar que portão fechou sem sensor. Teste que a resposta diga falha. Monitore em produção com amostragem e feedback. Novas versões podem melhorar média e piorar um idioma. O português e termos técnicos precisam. Incidentes viram casos. O sistema pode bloquear geração livre para segurança física e usar templates. A alucinação é um risco residual a ser controlado, não uma razão para delegar menos validação.