Fusão Multi-Modelo - Documentação do Entity Enricher

Fusão Multi-Modelo

Quando executa o mesmo enrichment em vários modelos de IA, o Entity Enricher pode fundir os resultados num único resultado de elevada confiança. A fusion deteta conflitos entre os resultados dos modelos e resolve-os através de regras determinísticas ou de arbitration com recurso a LLM.

Pipeline de Fusão

Saídas do modelo
Resultado do Claude
Resultado do GPT-4
Resultado Gemini
Deteção de conflitos
Compare todos os campos
em todos os modelos
Resolução
Combinação baseada em regras
ou
Arbitragem por LLM
Resultado combinado
Uma única saída com
trilho de auditoria de conflitos

Passo 1: Deteção de Conflitos

O detetor de conflitos compara todos os campos em todos os resultados dos modelos. Os campos em que todos os modelos concordam passam inalterados. Os campos em que os modelos discordam são assinalados como conflitos que precisam de resolução.

Regras de comparação por tipo de campo
TipoComo ComparadoConcordância significa
EscalarCorrespondência exata normalizada (sem espaços, em minúsculas, arredondada)Todos os valores iguais após normalização
MultilingueO idioma principal da execução decide; as diferenças de tradução apenas desencadeiam uma fusão por idiomaO mesmo texto no idioma principal — as variantes de formulação de uma tradução não são discordâncias
ArrayComparação de conjuntos (independente da ordem) na vista dos itens no idioma principalOs mesmos itens independentemente da ordem ou da formulação da tradução
ObjetoPor propriedade enquanto os campos de identidade provarem que ambos os modelos descrevem a mesma coisa — caso contrário, todo o objeto constitui um único conflitoTodas as propriedades aninhadas correspondem
Nulo / vazioUm valor nulo, uma string vazia ou um array vazio constituem uma abstenção, não uma afirmaçãoO valor preenchido prevalece sem contabilizar um conflito
Exemplo: enriquecer “Sanofi” com 2 modelos
Output do Claude
revenue: 42.2
gmp_status: true
description: “Sanofi is a global...”
Saída do GPT-4
revenue: 44.1
gmp_status: true
description: “Sanofi SA is a...”
Resultado: gmp_status = agreed | revenue = conflict (42.2 vs. 44.1) | description = conflict (texto diferente)

Passo 2: Resolução de Conflitos

Os conflitos são resolvidos através de um de dois métodos, consoante tenha selecionado um modelo de arbitragem na barra lateral.

Opção A

Combinação baseada em regras

São aplicadas regras determinísticas com base no tipo de dados de cada campo. Quase sempre isto dispensa por completo qualquer chamada ao LLM — a resolução é instantânea e gratuita. A única exceção são os números em que os modelos divergem drasticamente, que nenhuma regra consegue resolver honestamente; veja abaixo.

Tipo de campoRegraJustificação
StringVoto maioritário; em caso de empate, prevalece o valor mais longoNormalmente, quanto mais detalhe, melhor
NúmeroValor do modelo mais próximo da medianaRobusto a valores atípicos, nunca uma média fabricada
BooleanoMaioria; em caso de empate, vence truePredefinição conservadora
MultilingueVoto maioritário por idioma, união dos idiomasCada idioma resolvido de forma independente
ArrayUnião ciente da chave: os itens agrupam-se pelos respetivos campos-chave, as variantes de grafia fundem-se e os itens correspondentes são combinados campo a campoUma linha por entidade lógica, sem perder nada
ObjetoPor campo quando a identidade coincide; caso contrário, o objeto de um dos modelos é usado por inteiroMisturar dois objetos que descrevem entidades diferentes criaria um terceiro que nenhum dos modelos devolveu
Null vs ValorPreferir o valor preenchidoDados em falta são piores do que qualquer valor

Critério de desempate: Em caso de empate nos votos, vence o valor do modelo mais caro (como aproximação da capacidade), seguindo-se a ordenação alfabética do nome do modelo. Para um objeto inteiro tratado de forma atómica, a completude — o número de folhas preenchidas — fica entre os dois: sem nada que prove qual a entidade real, prefere-se o modelo mais forte e, depois, a resposta que transporta mais informação.

Os objetos aninhados são fundidos por inteiro, não misturados

Fundir um objeto aninhado campo a campo só é seguro enquanto ambos os modelos descreverem a mesma coisa. Quando os campos de identidade não o provam — chaves diferentes, ou nenhuma chave e uma verdadeira divergência por baixo —, o objeto passa a ser um único conflito e a versão de um dos modelos é assumida tal como está. Caso contrário, a fusão montaria uma quimera: a morada deste modelo na empresa daquele. Uma consequência é deliberada, mas convém conhecê-la: o vencedor é assumido com os seus vazios incluídos, pelo que um campo que o vencedor deixou vazio permanece vazio — o que pode travar a entidade à entrada da base de dados. O motivo segue nos avisos de validação da execução.

Quando os números divergem demasiado para serem fundidos

“O mais próximo da mediana” é adequado para modelos que arredondam de forma diferente e inadequado para modelos que se contradizem — 0 versus 1854 não é uma diferença de arredondamento. Quando a dispersão relativa dos valores atinge 20%, esse campo é escalado para um árbitro LLM escolhido automaticamente através da seleção de modelos habitual da sua organização, e a chamada é faturada como qualquer outra. Esses campos são assinalados como escalados automaticamente no registo de auditoria da fusão, para que uma fusão que consumiu tokens indique sempre quais os campos que a provocaram.

Opção B

Arbitragem por LLM

Quando seleciona um modelo de arbitration na barra lateral, os conflitos são enviados para um LLM para resolução inteligente. O árbitro recebe o contexto da entity, as descrições dos campos do schema e todos os valores em conflito e, em seguida, toma decisões fundamentadas.

O Que o Árbitro Devolve
Valor escolhidoO valor que considera mais exato
Modelo de origemDe que modelo veio o valor escolhido
RaciocínioPor que motivo escolheu esse valor em vez das alternativas
ConfiançaQuão confiante está na decisão (alta, média, baixa)

Alternativa: Se o modelo de arbitragem falhar (tempo limite, erro), o sistema recorre automaticamente à fusão baseada em regras para que obtenha sempre um resultado.

Passo 3: O Resultado Combinado

Após a resolução de conflitos, o sistema constrói um único resultado combinado e armazena-o como um registo de “arbitragem” na base de dados. Cada resultado combinado inclui um registo de auditoria para que possa rastrear como cada conflito foi resolvido.

Registo de Auditoria (Metadados de arbitragem)

Cada resultado combinado inclui metadados que documentam o processo de fusão:

“method”: “rule_based” | “llm”
“source_record_ids”: [“uuid-1”, “uuid-2”]
“total_fields”: 23
“agreed_fields”: 18
“conflicted_fields”: 5
“decisions”: [{ path, chosen_value, rule_used, ... }]

O mesmo registo de auditoria é apresentado para qualquer registo combinado na página Histórico, no respetivo separador Visão geral. Um registo combinado lista os modelos que combinou em vez de ter um modelo próprio — e quando a combinação se baseou em regras, não fez qualquer chamada de LLM, pelo que não tem prompt, nem tokens nem custo.

O Que Vê na Interface

Após a conclusão da fusão, o separador “Combinado” no painel de resultados mostra:

1
Cabeçalho de resumo
Mostra o método de resolução (baseado em regras ou LLM) e uma contagem como “18 em acordo / 5 resolvidos / 23 campos no total”.
2
JSON combinado
A saída estruturada completa que combina valores acordados e conflitos resolvidos num único documento JSON.
3
Relatório de conflitos
Cartões expansíveis para cada conflito que mostram: o caminho do campo, o selo do método de resolução (Voto Maioritário, Mediana, União, etc.), todos os valores dos modelos com o escolhido destacado e o texto de raciocínio se tiver sido usada arbitragem por LLM.

Fusão automática no processamento em lote

No enriquecimento em lote, a fusão acontece automaticamente quando seleciona dois ou mais modelos. Não precisa de clicar em “Combinar Resultados” manualmente — assim que todos os modelos tiverem tido êxito para uma entidade, a fusão é executada e o resultado combinado aparece junto aos resultados individuais de cada modelo. Uma execução em que um modelo falhou não é fundida de propósito: combinar o que resta publicaria silenciosamente uma resposta parcial como se fosse a resposta acordada. Recupere primeiro o modelo em falta — repetir os domínios de especialidade que falharam funde a execução automaticamente assim que esta estiver de novo completa.

Fusão em streaming: Durante o enriquecimento de entidade única e em lote, o progresso da fusão é transmitido via Server-Sent Events. Vê os eventos fusion_started, conflicts_detected e fusion_completed em tempo real.

Regras vs arbitragem por LLM: quando usar cada uma

Baseado em regras (instantâneo, quase sempre gratuito)
  • Dados maioritariamente factuais/numéricos onde a lógica de votação funciona bem
  • Grande volume ou processamento em lote onde o custo é importante
  • Esquemas simples com poucos conflitos esperados
  • Quando pretende resultados determinísticos e reproduzíveis
Arbitragem por LLM (custo adicional)
  • Schemas complexos onde o contexto é importante para a resolução
  • Dados textuais (descrições, resumos) onde a votação é insuficiente
  • Quando precisa de decisões explicáveis com raciocínio
  • Enriquecimentos críticos onde a precisão compensa o custo adicional