Con l'enrichment tramite LLM, il costo è dato dai token. Entity Enricher è progettato per inviare il minor numero possibile di token fatturati senza sacrificare la precisione — grazie in primis al caching dei prompt, e supportato dallo scoping degli schema, dal gating intelligente e da un minor numero di retry sprecati. La maggior parte avviene automaticamente; nulla qui richiede configurazioni aggiuntive.
Ogni chiamata di enrichment paga i token di input (il prompt, lo schema e gli eventuali documenti allegati), i token di output (il risultato strutturato) e — se abilitate — le query di ricerca sul web. La parte più grande e ripetitiva è di solito l'input: le stesse istruzioni di sistema, la descrizione dello schema e i documenti sorgente vengono inviati nuovamente a ogni chiamata. Mettere in cache questo input condiviso è la leva di gran lunga più efficace, per questo viene per prima.
Prompt + schema + allegati. Ampi e altamente ripetitivi tra le chiamate — l'obiettivo principale per il caching e la definizione degli ambiti.
Il risultato strutturato. Mantenuto essenziale chiedendo a ciascun modello solo i campi di sua effettiva competenza.
Tentativi falliti, sovraccarico dei limiti di frequenza ed enrichment dell'entity sbagliata. Eliminati a monte anziché pagati.
Quando viene eseguito un arricchimento multi-competenza, vengono effettuate diverse chiamate LLM per la stessa entità — una per ogni dominio di competenza. Ognuna di queste chiamate condivide lo stesso contesto iniziale: le istruzioni di sistema generiche e gli eventuali documenti di testo inline allegati. Entity Enricher mantiene tale prefisso condiviso identico byte per byte tra le chiamate e lo contrassegna come memorizzabile nella cache, così il provider lo archivia una sola volta e lo rilegge a ogni chiamata successiva a circa un decimo del prezzo di input normale.
Ciascuna delle N chiamate reinvia l'intero contesto condiviso al prezzo pieno dell'input. Cinque expertise significano pagare cinque volte per quel grande blocco condiviso.
Il blocco condiviso viene scritto nella cache una volta, quindi riletto nelle altre quattro chiamate a circa il 10% del prezzo di input. Il risparmio cresce con ogni competenza, lingua e documento allegato aggiuntivi.
Le cache dei provider sono leggibili solo dopo il completamento della prima richiesta che le scrive. Se tutte le chiamate ai domini di competenza partissero insieme, nessuna troverebbe una cache pronta e ciascuna scriverebbe in modo ridondante la propria copia. Perciò, quando il caching è applicabile, la prima chiamata viene eseguita da sola, si concede un breve istante affinché la cache si propaghi, e solo allora vengono avviate in parallelo le chiamate rimanenti — così ciascuna legge la cache già pronta anziché pagare per riscriverla.
I modelli Anthropic memorizzano nella cache le istruzioni condivise in modo esplicito; i PDF e le immagini allegati vengono memorizzati nella cache in loco; e i provider con caching automatico del prefisso (OpenAI, xAI, DeepSeek e altri) beneficiano dello stesso prefisso identico byte per byte. Il caching risulta più vantaggioso proprio quando l'input è di grandi dimensioni — molti domini di competenza, più lingue o documenti allegati.
Il calcolo dei costi tiene conto della cache: i token di input memorizzati nella cache vengono fatturati alla tariffa di lettura della cache del modello (una frazione della tariffa di input) e solo i token effettivamente nuovi vengono fatturati a prezzo pieno. Il risparmio compare direttamente nelle analisi dei costi, non solo in teoria.
Oltre a memorizzare nella cache il prefisso condiviso, Entity Enricher riduce la parte di ogni chiamata che non è condivisa.
Ogni chiamata di expertise riceve solo la porzione dello schema di cui è responsabile, non l'intero schema.
Un esperto finanziario non vede mai i campi normativi. Meno campi significa meno token in entrata e in uscita — e la risposta viene ridotta alla sua porzione prima della fusione.
Quando sono presenti documenti allegati e non è stata attivata una modalità di output strutturato rigorosa, l'elenco dei campi risiede solo nel prompt leggibile — nessuno schema viene duplicato in transito.
Questo elimina completamente i token dello schema e mantiene identico il prefisso condiviso (quindi la cache funziona meglio). La risposta viene comunque validata lato client, con autocorrezione automatica in caso di deriva.
La classificazione preliminare opzionale esegue un unico modello economico e veloce per verificare se un'entità corrisponde effettivamente al vostro schema prima che inizi qualsiasi costoso arricchimento multi-modello. Una discordanza — come una luna inviata a uno schema “Pianeta” — viene rilevata per una frazione di centesimo invece di consumare un intero arricchimento su diversi modelli premium.
È non bloccante (se il controllo fallisce, l'enrichment procede comunque) e annullabile, così non inizierà mai a pagare per modelli che ha deciso di saltare.
Un ciclo di validazione fallito è una chiamata LLM a prezzo pieno senza nulla da mostrare. Due meccanismi mantengono i tentativi rari e produttivi.
Le peculiarità comuni dell'output degli LLM — oggetti con chiavi indice che dovrebbero essere array, la stringa 'null', virgolette con escape isolate — vengono corrette prima dell'esecuzione della validazione.
Molti potenziali errori di validazione vengono corretti in modo silenzioso, così non attivano mai un nuovo tentativo a pagamento.
Quando un nuovo tentativo è realmente necessario, l'errore di validazione esatto viene restituito al modello affinché possa correggere quel problema specifico.
Un feedback chiaro e specifico aumenta le probabilità che il tentativo successivo vada a buon fine, invece di sprecare tentativi con indicazioni vaghe.
Il passaggio singolo è il più economico per gli schema di piccole dimensioni; la multi-competenza è pensata per quelli di grandi dimensioni, dove la cache e la delimitazione per competenza ripagano ampiamente le chiamate aggiuntive. Consultare Strategie per sapere quando usare ciascuno.
Un limite di concorrenza per provider evita che i job martellino un provider fino a generare errori di limite di frequenza, che altrimenti attiverebbero backoff e tentativi — token e tempo sprecati. Una concorrenza regolata e costante è più economica che combattere contro i 429.
Ogni enrichment registra i conteggi reali dei token — comprese le letture dalla cache — e il costo risultante. La Dashboard dei costi li trasforma in grafici temporali e ripartizioni per modello, così potete vedere esattamente dove va la spesa e verificare che la cache e la definizione dell'ambito stiano svolgendo il loro compito. Il prezzo che vedete è il prezzo che vi viene addebitato; i costi grezzi del provider e qualsiasi ricarico della piattaforma restano trasparenti.