Arricchisca lo stesso tipo di entità ripetutamente e continuerà a riscoprire le stesse cose del mondo reale — la stessa azienda, lo stesso effetto collaterale di un farmaco, la stessa persona — descritte ogni volta con parole leggermente diverse. Un ID semantico è un identificatore stabile, con ambito a livello di organizzazione, che Entity Enricher assegna a un oggetto a partire dai suoi campi chiave, così quei quasi-duplicati collassano in un'unica identità su cui è possibile raggruppare, deduplicare e unire i dati.
L'identità di un oggetto è costruita a partire dai suoi campi chiave — che possono essere uno o più. Due esempi:
nameCompare come Headache, Céphalée e Cephalalgia nelle diverse esecuzioni e lingue. Un solo campo chiave, tre grafie, un unico concetto reale.
nome + paeseAcme Inc. · Stati Uniti e Acme Incorporated · Stati Uniti sono la stessa azienda — mentre Acme Inc. · Germania è un'altra. La seconda chiave disambigua; ecco perché un oggetto può contenerne più di una.
Il semplice confronto di stringhe fallisce in tutti questi casi; una persona sa quali sono uguali. Gli ID semantici codificano automaticamente quel giudizio.
string su un oggetto (denominata id per impostazione predefinita), che contiene un identificatore opaco e stabile.preserve): sempre una stringa, mai una chiave, mai multilingue, al massimo uno per oggetto.manufacturer) o ogni elemento di un array (ad es. ogni side_effect).Dopo che il modello restituisce il risultato, Entity Enricher risolve ciascun ID semantico in quattro fasi — a partire dalla più economica:
“Acme Inc.” e“Acme Incorporated” finiscono l'uno accanto all'altro.0.92, regolabile per proprietà), l'ID di quel concetto viene riutilizzato. In caso contrario viene generato un ID nuovo di zecca e archiviato per la volta successiva.Compromesso sulla soglia: una soglia più alta è più rigida (meno unioni accidentali); una più bassa è più permissiva (deduplicazione più aggressiva). Regolala per proprietà quando il valore predefinito di 0,92 unisce troppo o troppo poco.
Se un ID venga generato dipende dal fatto che ne sia già presente uno nell'input per quell'oggetto. È questo che consente il round-trip: arricchire una volta per ottenere gli ID, quindi restituire un ID noto nelle esecuzioni successive per associare nuovi dati alla stessa identità — più economico e privo di ambiguità.
Se l'oggetto che invia ha già un ID semantico, viene trattato come un lookup: l'ID viene mantenuto letteralmente, il record viene collegato a quel concetto esistente e non c'è alcun embedding — nessun costo, nessun match-or-mint. Sta dicendo alla piattaforma “questo oggetto è già identificato nel nostro database”.
Se l'oggetto non ha un ID semantico, la piattaforma ne genera uno con i quattro passaggi precedenti. Da quel momento quell'ID diventa l'identificatore stabile dell'oggetto nel database della sua organizzazione.
Un valore presente ma non riconoscibile (non un vero ID di concetto) viene ignorato e al suo posto viene generato un ID.
La risoluzione comporta un piccolo consumo di embedding per ogni arricchimento (conteggiato come qualsiasi chiamata al modello). La cache a corrispondenza esatta rende gratuite le ripetizioni e gli ID forniti in input non hanno alcun costo.
Gli ID risolti compaiono nel JSON di output dell'arricchimento (il campo id di ciascun oggetto) e nei concetti semantici del dettaglio del record. Utilizzarli per:
La fusione riconcilia i disaccordi tra modelli all'interno di una singola esecuzione; gli ID semantici riconciliano la stessa entità tra esecuzioni e nel tempo. I due meccanismi lavorano insieme.