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 |
Le regole deterministiche vengono eseguite a ogni fusione e risolvono tutto ciò che i valori stessi dei modelli possono dimostrare. Ciò per cui possono solo preferire una risposta — un valore contraddetto, un oggetto annidato che i modelli descrivono in modo diverso, un elemento prodotto da un solo modello — viene affidato a un risolutore. Selezionando un modello di arbitraggio nella barra laterale si stabilisce chi sia tale risolutore: le regole stesse oppure un LLM.
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 arbitraggio nella barra laterale, le domande che le regole non hanno potuto risolvere vengono poste a quell'LLM. Esso vede l'identità dell'entità, la descrizione di ogni campo e il valore di ciascun modello mostrato nella lingua di arricchimento principale — e risponde indicando una scelta, senza mai scrivere un valore proprio.
Le domande vengono poste livello per livello: prima l'entità stessa, poi ogni elemento di array corrispondente in una chiamata dedicata, con la propria identità come contesto (“Atto I di questa opera”) — e un elemento scartato dall'arbitro non viene mai più riproposto. La parte condivisa del prompt viene memorizzata in cache dalla prima chiamata, così le chiamate più profonde vengono eseguite in parallelo a una frazione del costo.
Fallback: se il modello di arbitraggio non riesce (timeout, errore), restano valide le decisioni basate sulle regole: si ottiene sempre un risultato e il record indica quale metodo è stato applicato.
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:
La stessa traccia di controllo è disponibile per qualsiasi record unito nella pagina Cronologia, nella scheda Panoramica. Vengono elencate anche le decisioni prese all'interno di un array — un campo di un elemento corrispondente, un elemento mantenuto o scartato — così ciò che è stato escluso è visibile quanto ciò che è stato mantenuto. Un record arbitrato da un LLM indica come proprio modello l'arbitro; una fusione basata su regole elenca invece i modelli che ha unito, poiché non ha effettuato alcuna chiamata a un LLM e non comporta prompt, token né costi.
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.