O que são alucinações e porque surgem
Uma alucinação num LLM é a geração de informação que soa credível mas é factualmente falsa ou injustificada. Não é um „erro” no sentido de falha do sistema — é uma consequência da forma como os modelos de linguagem funcionam. O LLM não „sabe” da mesma forma que uma base de dados — prevê o token seguinte mais provável, com base nas estatísticas do treino. Quando no prompt surge uma pergunta para a qual o modelo não tem boa cobertura nos dados de treino, gera uma resposta „com a sonoridade mais provável”. Frequentemente essa resposta está correcta. Por vezes — não.
Cenários típicos de alucinação em aplicações de negócio:
- Citação de acórdãos ou artigos de lei inexistentes em aconselhamento jurídico
- Invenção de nomes de funções, classes ou bibliotecas ao gerar código
- Apresentação de estatísticas ou datas incorrectas em relatórios
- Invenção de contactos, moradas, números de telefone
- Mistura de factos relativos a diferentes empresas ou pessoas com nomes parecidos
Camada 1 — Grounding (RAG)
A técnica isolada mais eficaz para reduzir alucinações é o grounding — fornecer ao modelo documentos ou dados concretos como contexto a partir do qual deve retirar as respostas. RAG clássico (Retrieval-Augmented Generation):
- Pergunta do utilizador → pesquisa dos fragmentos de documentos mais relevantes (vector search em pgvector / Qdrant / Milvus)
- Fragmentos + pergunta → prompt com a instrução „responde exclusivamente com base nos documentos abaixo”
- Resposta do modelo → verificação de que contém citações/referências às fontes
O RAG reduz tipicamente as alucinações em 60-80% em aplicações do tipo „responde a perguntas sobre a nossa base de conhecimento”. Não as elimina completamente — o modelo pode ainda „interpretar” os documentos de forma indevida. Daí a necessidade de camadas adicionais.
Camada 2 — Self-consistency e ensemble
Self-consistency é a técnica que consiste em colocar a mesma pergunta várias vezes (ou a vários modelos diferentes) e comparar as respostas. Quando as respostas são consistentes — alta confiança. Quando divergem — sinal de que o tema é incerto.
Variante prática: pergunta a Claude Sonnet, Llama 70B e Bielik a mesma pergunta. Se os três devolvem o mesmo número, data ou facto — provavelmente está correcto. Se divergem — escalada para humano ou para um modelo mais caro (Opus). Este padrão, implementado num routing LLM de 8 níveis, combina redução de custo com melhoria de fiabilidade.
Camada 3 — Evaluation pipelines
Uma implementação de LLM em produção sem evaluation pipeline é como escrever código sem testes. Métricas concretas:
- Faithfulness — se a resposta decorre dos documentos fornecidos. Medida por outro modelo de IA (LLM-as-judge) ou por bibliotecas como RAGAS, deepeval.
- Answer relevance — se a resposta endereça a pergunta do utilizador.
- Context precision — se os melhores fragmentos foram devolvidos pelo retrieval (qualidade do vector search).
- Groundedness score — percentagem de afirmações na resposta para as quais é possível indicar uma fonte no contexto.
Cada nova build de uma aplicação baseada em LLM deve passar um conjunto de 50-500 perguntas de avaliação com ground truth conhecido. Se faithfulness cai abaixo de 90% — deployment blocked.
Camada 4 — Guardrails e validação de output
Guardrails são regras que validam o output do LLM antes da entrega ao utilizador. Exemplos:
- Schema validation — o output tem de cumprir um esquema concreto (JSON Schema, Pydantic). Alucinações do tipo „campos inventados” são detectadas mecanicamente.
- Forbidden patterns — detecção e bloqueio de padrões inaceitáveis (PII sem mascaramento, dados financeiros fora de contexto, conteúdo potencialmente nocivo).
- Citation enforcement — cada afirmação factual tem de ter citação da fonte. Se o modelo não cita — a resposta é rejeitada.
- Numeric range validation — os números no output são verificados quanto a sentido (por exemplo preço > 0, data ≤ hoje, percentagem no intervalo 0-100).
- Cross-reference check — comparação do output com uma base de factos (por exemplo KRS, dicionário de citações de leis).
Bibliotecas: Guardrails AI, NeMo Guardrails, instructor (para schema enforcement). A implementação própria é frequentemente mais simples e barata de manter.
Camada 5 — Human-in-the-loop
Para aplicações de alto risco (decisões jurídicas, médicas, financeiras, de recursos humanos) a camada human-in-the-loop é indispensável. Os modelos de IA não tomam a decisão final — apoiam o humano. Padrões concretos:
- Draft + review — a IA gera a primeira versão do documento/resposta, o humano verifica e aceita antes do envio.
- Confidence threshold — respostas de baixa confiança (de self-consistency ou de explicit confidence asking) são automaticamente escaladas para o humano.
- Random sampling QA — 5-10% de todas as respostas do LLM são auditadas manualmente, independentemente da confiança — métrica de qualidade ao longo do tempo.
- Feedback loop — o utilizador pode marcar uma resposta como incorrecta; o sistema aprende e melhora retrieval, prompts, parâmetros.
Medição — como saber que a redução funciona
Métricas concretas de produção que vale a pena monitorizar:
- Hallucination rate — percentagem de respostas classificadas como alucinação em avaliação manual (sampling). Objectivo: abaixo de 2% em aplicações business-critical.
- User feedback rate — percentagem de utilizadores que marcaram uma resposta como errada.
- Escalation rate — percentagem de pedidos escalados para humano. Demasiado baixo (abaixo de 5%) — o sistema provavelmente ignora casos incertos. Demasiado alto (acima de 30%) — o sistema não entrega valor de automatização.
- Faithfulness score em testes de regressão — tendência mensal.
- Time-to-correction — da detecção da alucinação à implementação da correcção (melhor retrieval, novo guardrail, fine-tuning).
Conclusões para decisores
As alucinações são geríveis — exigem investimento em arquitectura defensiva multi-camada. As empresas que implementam LLM sem esta arquitectura encontrarão mais tarde ou mais cedo um incidente grave (publicação de informação errada a um cliente, decisão incorrecta com base em dados alucinados, dano reputacional). O custo de construir um stack defensivo completo (RAG + evaluation + guardrails + human-in-the-loop) é tipicamente 15-30% do custo da própria implementação do LLM — e é um investimento absolutamente necessário para utilizações em produção. As consequências de o ignorar são assimétricas: baixo custo da omissão em 95% dos casos, catastrófico em 5%.