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.
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:
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.
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.
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ão | Exemplo | Causa |
|---|---|---|
| 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 entities | Atributos da Empresa A na Empresa B | Nomes semelhantes em dados de treino sobrepostos |
| Valores predefinidos plausíveis | "employees": 500 | O 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 |
Vários destes padrões têm origem no esquema, e não no modelo: uma propriedade como revenue deixa em aberto a moeda, o período e o âmbito (grupo ou entidade), e um nome para algo que a entidade simplesmente não tem não deixa ao modelo nada para procurar. A verificação de ambiguidade assinala ambos os casos, enumera as leituras que a propriedade admite e sugere a renomeação ou a descrição que fixa exatamente uma delas.
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.
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.
Todas as estratégias instruem o LLM: «Seja preciso e conservador — nunca invente um valor.» O modelo declara os campos que não conseguiu determinar em vez de preencher marcadores de posição, e essas declarações tornam-se nulos honestos no resultado.
Isto aborda diretamente a pressão do esquema — a causa #1 de alucinação estruturada. Um desconhecido declarado também desambigua as respostas reais: um 0 que o modelo assume é dados, um 0 declarado nã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.
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.
O resultado do enriquecimento é validado face aos tipos, formatos e estrutura do esquema. Uma falha desencadeia ModelRetry — o erro específico é devolvido ao LLM para correção, e a reparação é cirúrgica: apenas as folhas que vieram erradas são pedidas de novo, não a resposta inteira.
Até 5 tentativas de correção automática dentro de uma única execução do agente. (A geração de schemas corrige-se de outra forma — por passo, com fallbacks deterministas.)
Os campos marcados com preserve: true (IDs, SKUs, identificadores de importação) são restaurados para os respetivos valores de entrada originais após o enrichment — o LLM não pode substituir dados de referência (ground truth). Os pedidos de enrichment têm de fornecer um valor para cada campo preservado, para que nada seja alguma vez fixado a null nem inventado.
Dentro de arrays, os itens enriquecidos são associados de novo aos seus itens de entrada pelos respetivos campos de chave; os itens que a IA descobre recebem null em vez de um identificador inventado.
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.
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.
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.