Quanto costa davvero fare ingest di 46.844 documenti con un LLM

Risposta diretta: il costo di un ingest di massa con un LLM non si calcola sul numero di documenti, ma sul numero di chiamate che la tua pipeline fa per documento — che nei sistemi di estrazione di conoscenza è tipicamente da 2 a 5 volte il numero di chunk, non di documenti. Su 46.844 discorsi parlamentari, la differenza fra il conto ingenuo e quello vero è di due ordini di grandezza, e il free tier su cui hai testato il prototipo è inutilizzabile: 20 richieste al giorno significa oltre quindici anni di elaborazione.
TL;DR
- Il conto ingenuo è «documenti × prezzo per chiamata». È sbagliato: i sistemi di estrazione entità/relazioni fanno più chiamate per chunk, e i chunk sono più dei documenti.
- Su 46.844 documenti realistici, si arriva facilmente a oltre 100.000 chiamate al modello.
- Con un modello di fascia alta a listino ($5 per milione di token in input, $25 in output), l'ordine di grandezza è qualche migliaio di dollari per un singolo ingest completo.
- Il free tier di un modello economico (20 richieste/giorno) porta lo stesso job a ~15 anni.
- Il free tier non è un piano di riserva: è un ambiente di prototipazione con una capacità che non scala.
- Il numero da stimare prima di lanciare il job è uno solo: chiamate totali. Tutto il resto è moltiplicazione.
Il momento in cui te ne accorgi
Il contesto reale: 46.844 discorsi parlamentari da ingerire in un motore di knowledge graph per OpenLegis. Il prototipo funzionava. Funzionava su duecento documenti, con un modello economico, sul piano gratuito.
Passare alla scala vera ha prodotto due muri consecutivi, in ordine:
- Modello di fascia alta: credito esaurito. Non a metà job — molto prima.
- Ripiego su un modello economico: limite del piano gratuito a 20 richieste al giorno.
Il secondo muro è quello istruttivo, perché non è un muro di soldi: è un muro di tempo. E il tempo, in quel caso, si misurava in anni.
Il conto ingenuo e perché è sbagliato
Quasi tutti stimano così:
46.844 documenti × 1 chiamata × costo per chiamata = conto totale
Il risultato sembra gestibile, e quindi il job parte.
Il problema è che «1 chiamata per documento» è quasi sempre falso. In una pipeline di estrazione di conoscenza — quella che trasforma testo in entità e relazioni — la sequenza reale per ogni documento è:
- Chunking: il documento viene spezzato. Un discorso parlamentare medio produce più di un chunk.
- Estrazione: per ogni chunk, una chiamata che identifica entità e relazioni.
- Gleaning: molti motori fanno una seconda passata sullo stesso chunk per recuperare quello che la prima ha perso.
- Merge delle descrizioni: quando la stessa entità compare in decine di chunk, il sistema chiama di nuovo il modello per fondere le descrizioni in una sola coerente.
Il moltiplicatore reale non è 1. È tipicamente fra 2 e 5 — e il passo 4 è quello che quasi nessuno mette nella stima, perché non è proporzionale ai documenti ma alla ricorrenza delle entità, che non conosci finché non hai finito.
Il calcolo fatto bene, con numeri espliciti
Le assunzioni qui sotto sono dichiarate apposta: il punto non è il numero finale, è il metodo. Cambia le assunzioni con le tue e rifai il conto prima di lanciare.
| Passaggio | Assunzione | Risultato |
|---|---|---|
| Documenti | — | 46.844 |
| Token medi per documento | ~1.500 | ~70M token di testo sorgente |
| Chunk per documento | ~1,2 (chunk da ~1.200 token) | ~56.000 chunk |
| Chiamate per chunk | 2 (estrazione + gleaning) | ~112.000 chiamate |
| Token input per chiamata | ~2.000 (chunk + prompt di sistema) | ~224M token input |
| Token output per chiamata | ~600 | ~67M token output |
A listino per un modello di fascia alta — $5 per milione di token in input, $25 per milione in output (prezzi Anthropic per Claude Opus 5, settembre 2026) — il conto è:
- Input: 224M × $5 / 1M = ~$1.120
- Output: 67M × $25 / 1M = ~$1.675
- Sottototale: ~$2.800
A cui va aggiunto il merge delle entità, che su un corpus con forte ricorrenza (gli stessi parlamentari, gli stessi temi, per anni) aggiunge facilmente un 30–50%. Ordine di grandezza reale: $3.500–4.000 per un singolo ingest completo. Con una riesecuzione perché hai cambiato il prompt di estrazione, raddoppia.
Ora il free tier. Stesse 112.000 chiamate, a 20 richieste al giorno:
112.000 ÷ 20 = 5.600 giorni ≈ 15 anni e 4 mesi
Non è una battuta: è il motivo per cui il job non è mai partito.
La lezione che vale oltre questo caso
Il free tier ti fa credere di avere un sistema funzionante quando hai un prototipo funzionante. Sono due cose diverse, e la differenza non si vede finché non moltiplichi.
Tre regole che ho ricavato e che applico da allora:
- Stima le chiamate, non i documenti. È l'unico numero che conta. Se non sai quante chiamate fa la tua pipeline per documento, strumenta un campione da 100 documenti e contale davvero prima di lanciare.
- Fai girare un campione a pagamento, non a gratis. Cento documenti sul piano vero ti danno il costo per documento misurato, non stimato. Costa qualche dollaro e ti risparmia la sorpresa.
- Metti un tetto di spesa prima di premere invio. Un job da 112.000 chiamate che gira storto è un job che brucia il budget di un trimestre mentre tu dormi.
C'è anche una scelta architetturale sotto: non tutto il corpus merita lo stesso modello. In un ingest di massa, il lavoro meccanico (chunking, estrazione strutturata da testo regolare) regge benissimo un modello economico; il giudizio vero — disambiguare entità ambigue, decidere se due relazioni sono la stessa — è dove serve il modello buono. Trattare tutto il corpus allo stesso modo è il modo più veloce di spendere molto per un risultato medio. È lo stesso ragionamento che faccio quando decido se mettere un agente in mezzo a un flusso: se il passaggio è deterministico, un modello è solo costo e varianza.
FAQ
Perché un ingest costa più di una semplice chiamata per documento?
Perché le pipeline di estrazione di conoscenza spezzano ogni documento in chunk, fanno almeno una chiamata per chunk, spesso una seconda passata di recupero, e poi ulteriori chiamate per fondere le descrizioni delle entità ricorrenti. Il moltiplicatore reale è tipicamente fra 2 e 5 chiamate per chunk.
Come stimo il costo prima di lanciare il job?
Strumenta la pipeline su un campione di 100 documenti reali, conta le chiamate effettive e i token in ingresso e in uscita, poi moltiplica per il rapporto fra corpus totale e campione. È l'unico modo per avere un numero misurato invece che immaginato.
Il free tier può servire per un ingest di massa?
No. I limiti dei piani gratuiti sono pensati per lo sviluppo, non per il throughput: anche un limite apparentemente generoso diventa anni di elaborazione quando le chiamate sono centinaia di migliaia. Il free tier è un ambiente di prototipazione.
Conviene usare un modello più economico per tutto il corpus?
Conviene dividere. Il lavoro meccanico su testo regolare regge bene un modello economico; la disambiguazione e le decisioni di merge beneficiano di un modello più capace. Applicare lo stesso modello a tutto è il modo più rapido di spendere molto per una qualità media.
Se stai valutando un ingest di massa e vuoi sapere cosa ti costerà davvero prima di lanciarlo — o hai un job che è andato storto — parliamone. È il tipo di stima che faccio spesso come Fractional CTO.
Articoli correlati
- Appalti PNRR: cinque sistemi pubblici che non si parlanoPer sapere chi ha vinto un appalto PNRR servono almeno cinque banche dati pubbliche diverse, nessuna delle quali è pensata per essere interrogata insieme alle altre. Il registro tecnico, fonte per fonte, di chi ha provato a farlo davvero.
- Il bug peggiore non rompe la funzione: rompe la vista26 strumenti collegati e funzionanti in produzione, la dashboard ne mostrava zero. Il bug era lì da mesi anche per un altro prodotto, e nessuno l'aveva visto perché chi poteva notarlo aveva i permessi di amministratore.
- Sapeva 22.000 sentenze, ma non un numero di attoUn sistema con la giurisprudenza costituzionale dal 1956 non riusciva a trovare un disegno di legge cercato per numero. Nessuno l'aveva mai testato: sembrava troppo ovvio per essere rotto.