Prevenção de alucinações - Documentação do Entity Enricher

Prevenção de alucinações

Quando os LLMs produzem dados estruturados, podem fabricar factos com aparência plausível. O Entity Enricher utiliza 8 camadas de defesa para garantir que obtém dados precisos ou nenhum dado — nunca ficção com ar de certeza.

O Problema da Alucinação Estruturada

Em texto livre, uma frase alucinada é obviamente vaga. Num output estruturado, um campo alucinado como "founded_year": 1987 parece fidedigno e é quase impossível de distinguir de um valor correto. Três fatores tornam isto particularmente perigoso:

Falsa Precisão

Um valor JSON alucinado parece exatamente igual a um real. Não há reservas, não há “aproximadamente” — apenas um dado limpo e confiante que, por acaso, está errado.

Pressão do Esquema

Os campos obrigatórios forçam o LLM a produzir um valor mesmo quando não tem conhecimento. O modelo inventa dados em vez de deixar uma lacuna na estrutura.

Propagação silenciosa

Os dados estruturados alimentam diretamente bases de dados, análises e automações. Um valor incorreto propaga-se pelos pipelines sem revisão humana.

Padrões comuns de alucinação

PadrãoExemploCausa
Fabricação confiante"ceo": "John Smith"O LLM preenche um campo obrigatório com um nome plausível
Confusão temporal"revenue": "$2.3B"Data-limite dos dados de treino ou fusão de períodos
Conflação de entitiesAtributos da Empresa A na Empresa BNomes semelhantes em dados de treino sobrepostos
Valores predefinidos plausíveis"employees": 500O LLM escolhe um número “razoável” em vez de admitir que não sabe
Relações inventadas"subsidiary_of": "Alphabet"O LLM infere uma relação que não existe

8 Camadas de Defesa

O Entity Enricher não depende de uma única técnica. Empilha 8 camadas de defesa independentes, cada uma visando um modo de falha diferente. Se uma camada deixar passar uma alucinação, a seguinte apanha-a.

1
Classificação prévia

Antes de o enriquecimento começar, um LLM rápido classifica se a entidade corresponde ao tipo do esquema. Isto bloqueia a alucinação de entidades inteiras na origem.

Exemplo: “Titan” contra um schema de “Planeta” é assinalado como uma lua — os modelos de enriquecimento recebem este contexto e usam null nos campos específicos de planetas.

2
Campos Anuláveis e Prompting Conservador

Todas as estratégias instruem o LLM: «Seja preciso e conservador — prefira null a adivinhar.» Os campos de schema anuláveis dão ao modelo permissão explícita para dizer «Não sei.»

Isto aborda diretamente a pressão do esquema — a causa n.º 1 de alucinação estruturada.

3
Definição do Âmbito dos Domínios de Especialização

As propriedades do esquema são agrupadas por domínio de especialização. Cada chamada ao LLM só vê os campos do seu domínio, com instruções para se focar exclusivamente nessa área.

Um âmbito mais restrito significa menos oportunidades de alucinar. Um especialista financeiro nunca adivinha dados regulatórios.

4
A Focar a Chave de Pesquisa

As propriedades-chave (marcadas com is_key: true) são destacadas nos prompts para ancorar o LLM na informação de identificação antes de preencher os restantes campos.

Isto assenta o modelo em factos conhecidos, reduzindo o desvio em direção a detalhes fabricados.

5
Validação de Esquemas e Autocorreção

8 regras de validação verificam a saída do LLM em busca de incompatibilidades de tipo, referências inválidas e erros estruturais. Uma validação falhada aciona o ModelRetry — os erros são reenviados ao LLM para correção.

Até 6 tentativas automáticas de correção numa única execução do agente. O LLM corrige os seus próprios erros.

6
Preservar lógica

Os campos marcados com preserve: true (IDs, SKUs, timestamps) são restaurados para os seus valores de entrada originais após o enriquecimento. O LLM não pode substituir os dados de referência.

Campos protegidos: IDs de entidade, códigos de sistema (EAN, SKU), identificadores de importação, marcas temporais de criação.

7
Consenso multi-modelo

Executar a mesma entidade em 2 ou mais modelos independentes e comparar os resultados campo a campo. As discordâncias são assinaladas como potenciais alucinações.

Se o Claude disser que a receita é de 2,3 mil milhões de dólares e o GPT-4 disser 1,8 mil milhões — esse conflito é detetado e apresentado.

8
Resolução de conflitos e arbitragem

Os conflitos detetados são resolvidos por votação baseada em regras (maioria, mediana, união) ou por um arbitrador LLM dedicado que avalia a exatidão, a completude e a consistência.

Cada decisão de arbitragem inclui o raciocínio e o nível de confiança — total transparência sobre como os conflitos foram resolvidos.

Pipeline de defesa

1Classificação préviaBloquear tipos de entidade errados
2Anulável + Prompts ConservadoresReduzir a pressão do esquema
3Definição do Âmbito dos Domínios de EspecializaçãoRestringir o que o LLM tem de responder
4Foco da Chave de PesquisaAncore-se nos identificadores
5Validação e autocorreçãoCorrigir erros estruturais
6Preservar lógicaProteger a verdade de referência
7Consenso multi-modeloDetetar divergências
8Arbitragem de conflitosResolver com raciocínio
Pré-enriquecimento
Durante o enriquecimento
Pós-enriquecimento

Filosofia de Design

Princípio Fundamental

Dados em falta são sempre melhores do que dados errados. Cada camada reforça este princípio — o sistema foi concebido para devolver null em vez de uma invenção plausível.

O Que o Entity Enricher Faz
  • Dá aos LLMs permissão explícita para devolver null
  • Faz validação cruzada com vários modelos independentes
  • Protege dados válidos conhecidos contra substituição
  • Mostra total transparência na resolução de conflitos
O Que as Ferramentas Típicas Fazem
  • Forçar os LLMs a preencher todos os campos, aconteça o que acontecer
  • Depender de um único modelo sem validação cruzada
  • Permitir que o LLM substitua livremente os dados de entrada
  • Devolver resultados como uma caixa negra sem trilho de auditoria