Quando si esegue lo stesso arricchimento su più modelli di IA, Entity Enricher può fondere i risultati in un unico output ad alta affidabilità. La fusione rileva i conflitti tra gli output dei modelli e li risolve con regole deterministiche o mediante arbitrato basato su LLM.
Il rilevatore di conflitti confronta ogni campo tra tutti gli output dei modelli. I campi su cui tutti i modelli concordano vengono lasciati invariati. I campi su cui i modelli non concordano vengono segnalati come conflitti da risolvere.
| Tipo | Metodo di confronto | Significato dell'accordo |
|---|---|---|
| Scalar | Corrispondenza esatta normalizzata (senza spazi, in minuscolo, arrotondata) | Tutti i valori sono uguali dopo la normalizzazione |
| Multilingua | Decide la lingua principale dell'esecuzione; le differenze di traduzione attivano soltanto un'unione per lingua | Stesso testo nella lingua principale — le varianti di formulazione di una traduzione non sono discordanze |
| Array | Confronto tra insiemi (indipendente dall'ordine) sulla vista in lingua principale degli elementi | Stessi elementi indipendentemente dall'ordine o dalla formulazione della traduzione |
| Oggetto | Per proprietà finché i campi identità dimostrano che entrambi i modelli descrivono la stessa cosa — altrimenti l'intero oggetto costituisce un unico conflitto | Tutte le proprietà nidificate corrispondono |
| Null / vuoto | Un valore null, stringa vuota o array vuoto è un'astensione, non un'affermazione | Il valore compilato prevale senza conteggiare un conflitto |
I conflitti vengono risolti con uno di due metodi, a seconda che sia stato selezionato un model di arbitration nella barra laterale.
Vengono applicate regole deterministiche in base al tipo di dato di ciascun campo. Quasi sempre non è necessaria alcuna chiamata LLM: la risoluzione è immediata e gratuita. L'unica eccezione sono i numeri su cui i modelli divergono radicalmente, che nessuna regola può dirimere onestamente; si veda più avanti.
| Tipo di campo | Regola | Motivazione |
|---|---|---|
| Stringa | Voto a maggioranza; in caso di parità vince il valore più lungo | In genere, più dettagli sono meglio |
| Numero | Valore del model più vicino alla mediana | Robusto rispetto ai valori anomali, mai una media inventata |
| Booleano | Maggioranza; in caso di parità vince true | Impostazione predefinita conservativa |
| Multilingua | Voto a maggioranza per lingua, unione delle lingue | Ogni lingua risolta in modo indipendente |
| Array | Unione basata sulle chiavi: gli elementi si raggruppano in base ai campi chiave, le varianti di scrittura vengono unificate, gli elementi corrispondenti vengono uniti campo per campo | Una riga per ogni entity logica, senza perdere nulla |
| Oggetto | Per campo quando l'identità coincide; altrimenti si prende per intero l'oggetto di un solo modello | Fondere due oggetti che descrivono entità diverse inventerebbe un terzo oggetto che nessuno dei due modelli ha restituito |
| Null vs Valore | Preferisci il valore compilato | Un dato mancante è peggiore di qualsiasi valore |
Criterio di spareggio: in caso di parità di voti prevale il valore del modello dal prezzo più alto (come indicatore indiretto della capacità), seguito dall'ordine alfabetico del nome del modello. Per un intero oggetto considerato in modo atomico, tra i due criteri si inserisce la completezza — il numero di foglie valorizzate: non essendoci nulla che dimostri quale entità sia quella reale, si preferisce il modello più forte e poi la risposta che porta più informazioni.
Unire un oggetto annidato campo per campo è sicuro solo finché entrambi i modelli descrivono la stessa cosa. Quando i campi di identità non lo dimostrano — chiavi diverse, oppure nessuna chiave e un reale disaccordo sottostante — l'oggetto diventa un unico conflitto e la versione di uno solo dei modelli viene presa alla lettera. Altrimenti la fusione assemblerebbe una chimera: l'indirizzo di un modello sull'azienda di un altro. Una conseguenza è deliberata, ma vale la pena conoscerla: il vincitore viene preso con i suoi vuoti inclusi, quindi un campo lasciato vuoto dal vincitore resta vuoto — il che può bloccare l'entità al varco di ammissione nel database. Il motivo viene riportato tra gli avvisi di validazione dell'esecuzione.
“Il più vicino alla mediana” è il criterio giusto per modelli che arrotondano in modo diverso ed è sbagliato per modelli che si contraddicono a vicenda: 0 contro 1854 non è una differenza di arrotondamento. Quando la dispersione relativa dei valori raggiunge il 20%, quel campo viene sottoposto a un arbitro LLM scelto automaticamente tramite la consueta selezione dei modelli della sua organizzazione, e la chiamata viene fatturata come qualsiasi altra. Tali campi sono contrassegnati come sottoposti automaticamente ad arbitraggio nella traccia di audit della fusione, così che un'unione che ha consumato token indichi sempre quali campi l'hanno causata.
Quando si seleziona un modello di arbitrato nella barra laterale, i conflitti vengono inviati a un LLM per una risoluzione intelligente. L'arbitro riceve il contesto dell'entità, le descrizioni dei campi dello schema e tutti i valori in conflitto, quindi prende decisioni motivate.
Fallback: se il modello di arbitraggio fallisce (timeout, errore), il sistema ricorre automaticamente all'unione basata su regole in modo da ottenere sempre un risultato.
Dopo la risoluzione dei conflitti, il sistema crea un unico risultato unito e lo memorizza come record di “arbitrato” nel database. Ogni risultato unito include una traccia di controllo che consente di ricostruire come è stato risolto ciascun conflitto.
Ogni risultato unito include metadati che documentano il processo di fusion:
Lo stesso audit trail viene mostrato per qualsiasi record unito nella pagina Cronologia, nella relativa scheda Panoramica. Un record unito elenca i modelli che ha unito anziché un proprio modello — e quando l'unione è basata su regole non è stata effettuata alcuna chiamata LLM, quindi non comporta alcun prompt, alcun token né alcun costo.
Al termine della fusione, la scheda “Unito” nel pannello dei risultati mostra:
Nell'arricchimento in batch, la fusione avviene automaticamente quando si selezionano due o più modelli. Non è necessario fare clic manualmente su “Unisci risultati”: non appena tutti i modelli hanno avuto esito positivo per un'entità, la fusione viene eseguita e il risultato unito appare accanto agli output dei singoli modelli. Un'esecuzione in cui un modello è fallito non viene fusa, deliberatamente: unire ciò che resta pubblicherebbe silenziosamente una risposta parziale come se fosse quella condivisa. Recuperi prima il modello mancante — ripetendo le sue competenze fallite l'esecuzione viene fusa automaticamente non appena torna completa.
fusion_started, conflicts_detected e fusion_completed.