Flusso di arricchimento - Documentazione di Entity Enricher

Flusso di arricchimento

Una guida passo passo su come Entity Enricher elabora una singola entità — dall'input, attraverso la classificazione e l'esecuzione parallela dei modelli, fino all'output strutturato.

La pipeline in breve

Input
JSON dell'entità
+ Schema
Classification
Controllo del tipo
opzionale
Modelli paralleli
Claude
finanziario
normativo
generale
GPT-4
finanziario
normativo
generale
Convalida
Controllo del tipo
Autocorrezione
Output
Strutturato
JSON per modello

Passaggio 1: configura l'arricchimento

Apra la pagina Workflow Editor e configuri il suo arricchimento. Uno stepper del workflow la guida attraverso le fasi della pipeline: Sample Data, Schema, Enrichment e Results — oltre a una fase Database Ready quando lo schema è collegato a un Database Sync, che conferma che le modifiche dell'esecuzione sono state messe in coda per il suo database (o spiega perché il salvataggio è stato rifiutato).

Pannello dello schema (a sinistra)

Incolla un JSON di esempio per generare automaticamente uno schema, poi esplora l'albero interattivo delle proprietà. Modifica le proprietà, aggiungi domini di competenza e contrassegna i campi come chiavi di ricerca o come conservati.

Pannello di arricchimento (a destra)

Configura le opzioni di enrichment (strategia, model, lingue, classification, oltre allo schema di risposta e agli interruttori per l'output strutturato rigoroso) e compila le chiavi di ricerca dell'entity (nome, sito web, paese, ecc.) per identificare l'entity.

Pannello dei risultati

Mostra l'avanzamento e i risultati in tempo reale per ogni modello. Quando si utilizzano più modelli, viene visualizzato un pulsante “Unisci risultati” per la fusione.

Che cosa viene verificato prima di spendere token

Alcune richieste non possono in alcun modo produrre un risultato utilizzabile, e il momento più economico per scoprirlo è prima della prima chiamata LLM. Due contratti vengono applicati fin da subito.

Il contratto di input

Uno schema dichiara ciò che il suo input deve contenere: i campi chiave che indicano quale entità sia, una chiave su ogni elemento di un array fornito e un valore per ogni campo marcato come preserve (non si può preservare ciò che non è mai stato fornito). Una richiesta a cui manchi anche solo uno di questi elementi viene rifiutata con un unico errore che elenca tutte le violazioni in una volta, oltre al contratto completo dello schema: così può correggere tutto in un solo passaggio invece di scoprire i requisiti un rifiuto alla volta. Il contratto è pubblicato su ogni schema salvato, quindi un client può verificarlo prima di inviare.

Il contratto ad array chiuso

Un array per cui si forniscono gli elementi viene arricchito esattamente: il modello completa ciò che sa su ciascun elemento e non può né aggiungerne né eliminarne. Se invia cinque voci, ne riceve cinque. Un elemento che il modello non ha rivendicato viene reinserito alla lettera anziché andare perso, mentre un elemento inventato viene scartato. Gli array lasciati vuoti restano invece aperti: è il modello a scoprire nuovi fatti, ed è proprio questo lo scopo.

Passaggio 2: classificazione preliminare (opzionale)

Se ha selezionato un modello di classificazione, viene prima eseguita una chiamata LLM rapida ed economica per verificare che l'entità corrisponda al tipo di schema. Ciò evita di sprecare token per l'arricchimento quando l'entità non corrisponde. Maggiori informazioni nella documentazione sulla classificazione.

Non bloccante: Se la classification fallisce per qualsiasi motivo, l'enrichment prosegue normalmente. La classification è puramente indicativa — aggiunge contesto ai prompt di enrichment ma non blocca mai la pipeline.

Passaggio 3: esecuzione della strategia

Ogni modello selezionato elabora l'entità utilizzando la strategia indicata — oppure, per impostazione predefinita, quella scelta automaticamente in base alla struttura del suo schema, che l'esecuzione segnala all'avvio. Quando sono selezionati più modelli, questi vengono eseguiti in parallelo tra i provider (Claude e GPT-4 vengono eseguiti simultaneamente), mentre i modelli dello stesso provider vengono eseguiti in sequenza per rispettare i limiti di frequenza.

Esempio multi-competenza (3 domini)
1
Suddividi lo schema per competenza
Le proprietà sono raggruppate per dominio di competenza: campi finanziari, campi normativi, campi generali.
2
Esegui chiamate LLM in parallelo
Ogni expertise ottiene il proprio prompt mirato con solo le proprietà dello schema pertinenti. Vengono eseguite tutte simultaneamente.
3
Unisci i risultati progressivamente
Man mano che ogni competenza viene completata, il suo output viene unito al risultato accumulato. I risultati parziali vengono visualizzati in tempo reale.
4
Applica logica di conservazione
I valori originali dei campi contrassegnati come 'preserve' vengono ripristinati, garantendo che i dati di input restino intatti. All'interno degli array, gli elementi arricchiti vengono ricollegati agli elementi di input in base ai loro campi chiave anziché alla posizione, così anche una risposta con ordine diverso ripristina i valori corretti.

Passaggio 4: Convalida e autocorrezione

Ogni risposta dell'LLM viene validata rispetto al vostro schema in tempo reale. Quando l'output non corrisponde ai tipi o ai vincoli previsti, il sistema invia automaticamente gli errori all'LLM per la correzione.

Che cosa viene corretto automaticamente:
Stringa invece di numero
"42.2" diventa 42.2
Oggetti indicizzati come array
{"0": "a", "1": "b"} diventa ["a", "b"]
Null come stringhe
"null" o "None" diventa un null effettivo
Valori che il modello non è riuscito a determinare
Li dichiara anziché inventarli — quei percorsi diventano null

Fino a 5 tentativi automatici per ogni chiamata LLM. Ogni tentativo include l'errore di validazione specifico, così l'LLM sa esattamente cosa correggere — e la riparazione è chirurgica: vengono richieste di nuovo solo le foglie risultate errate, non l'intera risposta.

Si noti ciò che non compare in questo elenco: un valore che il modello non è riuscito a determinare non è un errore da riprovare. Ogni campo può risultare assente e il modello dichiara ciò che non ha trovato, quindi “sconosciuto” è una risposta, non un fallimento. Se un valore mancante sia accettabile viene deciso più tardi, quando l'entità viene ammessa nel proprio database — non costringendo il modello a tirare a indovinare.

Imporre l'output alla fonte

Due interruttori facoltativi chiedono al provider di vincolare l'output prima che venga restituito, così che meno risposte debbano essere corrette in partenza. Entrambi si applicano solo ai modelli che li supportano; tutto ricade comunque nel ciclo di validazione e nuovo tentativo descritto sopra.

Schema di risposta
Invia lo schema tramite il canale nativo di response-schema del provider, così il JSON viene applicato lato server. Disattivato per impostazione predefinita — altrimenti i modelli compatibili usano il canale di tool-call.
Output strutturato rigoroso
Vincola la decodifica allo schema (nessuna deriva) sul canale strutturato utilizzato. Attiva per impostazione predefinita; ignorata silenziosamente dai modelli che non possono applicarla.

Passaggio 5: Streaming in tempo reale

Entity Enricher utilizza gli Server-Sent Events (SSE) per trasmettere l'avanzamento in tempo reale. Non dovete attendere il completamento di tutti i modelli — i risultati appaiono progressivamente man mano che ciascun dominio di competenza o modello termina.

Cronologia degli eventi (esempio con 2 modelli, 3 domini di competenza)
0.0sstartedIl job inizia, 2 modelli in coda
0.1sclassification_startedInizio del controllo preliminare
0.8sclassification_completedEntità confermata come "match" (95%)
0.9smodel_startedClaude e GPT-4 si avviano in parallelo
1.2sexpertise_completedClaude: parte finanziaria completata, risultato parziale in streaming
1.5sexpertise_completedClaude: parte generale completata, risultato aggiornato
1.8sexpertise_completedClaude: normativa completata, risultato completo pronto
1.9smodel_completedClaude ha terminato con output strutturato completo
2.5smodel_completedGPT-4 ha terminato con output strutturato completo
2.5scompletedTutti i modelli completati, lo stream si chiude

Passaggio 6: Revisione dei risultati

Ogni model ottiene il proprio pannello dei risultati che mostra l'output JSON strutturato, i badge di avanzamento per expertise, l'utilizzo dei token, il costo e il tempo di elaborazione. Quando si utilizza la strategia multi-expertise, i badge delle expertise si aggiornano in tempo reale man mano che ciascun domain viene completato.

Che cosa si vede per ogni modello:
  • Badge di stato — In attesa, In esecuzione, Riuscito, Fallito o Parziale
  • Badge delle competenze — Pillole colorate che mostrano l'avanzamento per dominio (blu = in corso, verde = completato, rosso = fallito)
  • JSON progressivo — L'output si aggiorna al completamento di ogni expertise domain
  • Metriche — Tempo di elaborazione, numero di token, costo in USD
  • Log di avanzamento — Voci con marca temporale per ogni evento

Gestione del successo parziale

Quando si utilizza la strategia multi-competenza, alcune competenze possono fallire mentre altre riescono. Anziché scartare tutto, Entity Enricher restituisce l'output unito delle competenze riuscite con stato “Parziale”. È quindi possibile riprovare solo le competenze fallite senza rieseguire l'intero arricchimento.

Esempio: se 2 competenze su 3 hanno successo, si ottiene un output strutturato che copre i domini riusciti. La competenza fallita può essere ritentata e i suoi risultati verranno uniti all'output esistente.

Che cosa succede dopo?

Al termine dell'arricchimento, i risultati vengono salvati nella pagina Cronologia per riferimento futuro. Se sono stati utilizzati più modelli, è possibile unire i risultati tramite Multi-Model Fusion.