Quanto costa davvero il RAG: ingestione, storage, retrieval e generazione

Il costo di un sistema RAG (Retrieval-Augmented Generation) si costruisce su quattro voci: ingestione dei documenti, storage e indicizzazione, retrieval ad ogni domanda e generazione della risposta. Per una PMI italiana con qualche centinaio di documenti, il costo per singola domanda oscilla tipicamente tra pochi centesimi e qualche decina di centesimi di euro, a seconda della lunghezza del contesto recuperato e del modello usato in generazione. Capire come si compongono questi costi aiuta a scegliere tra pagare a consumo, abbonarsi a un servizio gestito o costruire l'infrastruttura in casa.

Da cosa è composto davvero il costo di un sistema RAG

Quando si parla di «costo del RAG» si tende a pensare solo al prezzo per token del modello linguistico, ma è solo una parte della storia. Un sistema RAG completo ha quattro centri di costo con dinamiche molto diverse: l'ingestione (una tantum o periodica, quando si caricano o aggiornano documenti), lo storage (un costo fisso mensile indipendente dal traffico), il retrieval (un costo marginale per ogni domanda, generalmente piccolo) e la generazione (il costo più visibile e più variabile, legato ai token scambiati con il modello). Separare queste voci è il primo passo per capire dove conviene davvero intervenire quando il conto a fine mese sembra troppo alto.

Il costo dell'ingestione: preparare i documenti prima di poterli interrogare

L'ingestione comprende l'estrazione del testo da PDF, Word o file scansionati (con eventuale OCR), la suddivisione in chunk e la generazione degli embedding per ogni frammento. Il modo in cui si dividono i documenti incide sia sulla qualità delle risposte sia sul numero di chunk da embeddare: una strategia di chunking per RAG troppo fine moltiplica il numero di vettori da creare e indicizzare, mentre una troppo grossolana rischia di diluire il segnale utile. Il costo di embedding per token è generalmente molto basso rispetto alla generazione, ma su archivi di decine di migliaia di pagine può comunque pesare se si rifà l'indicizzazione spesso. Il punto chiave è che questa è una spesa legata al volume di documenti caricati o aggiornati, non al numero di domande poste: un archivio stabile che riceve mille domande al mese costa in ingestione quanto uno che ne riceve dieci.

Il costo dello storage e dell'indicizzazione vettoriale

Una volta creati, gli embedding devono essere conservati in un indice interrogabile, tipicamente un database vettoriale o un motore di ricerca ibrida. Questo è un costo ricorrente e in gran parte fisso: si paga per mantenere l'indice disponibile, non per ogni query che lo interroga. Le opzioni vanno da soluzioni open source autogestite a servizi completamente gestiti, con differenze di prezzo molto ampie a seconda del numero di vettori, della dimensione degli embedding e del livello di disponibilità richiesto. Abbiamo approfondito questo aspetto in dettaglio nell'articolo sul costo di un database vettoriale: per una base di conoscenza di medie dimensioni il conto mensile puro di storage resta spesso una frazione minore della spesa totale, ma diventa rilevante quando si gestiscono più basi separate o si vuole alta ridondanza.

Il costo del retrieval: cosa succede ad ogni domanda prima di generare la risposta

Il retrieval è la fase in cui il sistema cerca nei documenti i passaggi più pertinenti alla domanda posta. Con una ricerca ibrida che combina parole chiave (BM25) e similarità semantica dei vettori, come spiegato in ricerca ibrida: BM25 e vettori, il costo computazionale per singola query resta generalmente contenuto: si tratta di operazioni di confronto su un indice già costruito, non di generazione di nuovo testo. Il costo sale leggermente quando si usa query expansion (riformulare o arricchire la domanda con sinonimi e varianti prima della ricerca), perché questo passaggio può richiedere una piccola chiamata aggiuntiva a un modello. In pratica, il retrieval resta quasi sempre la voce meno impattante sul costo per domanda, ma è quella che determina la qualità dei passaggi che finiranno nel prompt di generazione, e quindi indirettamente anche la lunghezza (e il costo) di quel prompt.

Il costo della generazione: la voce più visibile in bolletta

La generazione è dove il costo diventa tangibile, perché si paga per i token scambiati con il modello linguistico: quelli in ingresso (la domanda, le istruzioni di sistema e i passaggi recuperati) e quelli in uscita (la risposta prodotta). Se il sistema recupera cinque passaggi da 250-300 parole ciascuno, il prompt può facilmente arrivare a 2.000-3.000 token prima ancora di aggiungere la domanda, mentre la risposta generata è spesso più corta, qualche centinaio di token. Il prezzo per milione di token varia moltissimo da modello a modello: i modelli più piccoli ed economici costano pochi centesimi di euro per milione di token, i modelli di punta possono costare diversi euro, soprattutto in uscita. Questo spiega perché la lunghezza del contesto iniettato è la leva più diretta sul costo: più passaggi si recuperano «per sicurezza», più il prompt cresce e più la domanda costa. Il confronto con gli approcci a contesto lungo, che evitano il retrieval ma pagano prompt enormi ad ogni interazione, è approfondito in RAG vs modelli a contesto lungo.

Pagare a consumo o in abbonamento: due modelli di pricing a confronto

Sul mercato convivono due logiche di prezzo per l'accesso a un sistema RAG: il pagamento a consumo, con crediti prepagati scalati per ogni domanda posta, e l'abbonamento a soglia fissa, che include un certo volume di utilizzo mensile. Su Kopik, ad esempio, convivono entrambi: crediti prepagati per chi fa un uso occasionale o irregolare, oppure un abbonamento in modalità chat a 12 euro al mese con un indicatore di consumo che mostra quanto resta disponibile. La scelta tra i due modelli dipende soprattutto dalla prevedibilità del traffico: con volumi costanti e noti l'abbonamento tende a essere più conveniente e più facile da budgettare, mentre con picchi irregolari (un progetto stagionale, un lancio, un uso sporadico interno) i crediti a consumo evitano di pagare per capacità inutilizzata. Un confronto più ampio tra pipeline autogestite, database vettoriali e marketplace di basi già pronte è disponibile in piattaforme RAG as a service a confronto.

• Abbonamento a soglia fissa: conviene con traffico regolare e prevedibile, perché il costo marginale per domanda tende a zero una volta dentro la soglia.
• Crediti prepagati: convengono con traffico irregolare o stagionale, perché non si paga nulla nei mesi di scarso utilizzo.
• Infrastruttura autogestita: ha senso solo oltre volumi molto alti, perché richiede comunque storage, manutenzione e monitoraggio continui.
• Servizio gestito tipo marketplace: elimina i costi di ingestione e indicizzazione dal lato utente, lasciando solo il costo per domanda o l'abbonamento.

Come abbassare il costo di un sistema RAG senza perdere qualità

La leva più efficace resta la gestione del contesto iniettato nel prompt: recuperare meno passaggi, ma più pertinenti, riduce i token in ingresso senza peggiorare la risposta, a patto che il retrieval sia abbastanza preciso da non perdere l'informazione giusta. Altre leve pratiche includono:

1. Limitare il numero di passaggi recuperati per domanda (3-5 invece di 10-15) e verificare che la qualità delle risposte non cali con un test set, come descritto in come valutare un sistema RAG.
2. Usare la modalità «solo passaggi» quando basta mostrare l'estratto originale senza generare una risposta sintetica: si paga solo il retrieval, non la generazione.
3. Scegliere un modello più economico per le domande semplici e riservare un modello più costoso solo a query complesse o ambigue.
4. Rivedere la dimensione dei chunk: frammenti troppo piccoli moltiplicano il numero di passaggi necessari per coprire una risposta completa, aumentando sia l'ingestione sia il prompt.
5. Evitare di re-indicizzare interi archivi quando cambia un solo documento: aggiornare solo i chunk toccati riduce il costo di ingestione ricorrente.
6. Mettere in cache le risposte alle domande più frequenti, quando il contenuto sorgente non cambia spesso.

Un esempio di calcolo mensile per una PMI

Immagini uno studio professionale che carica un centinaio di documenti interni (regolamenti, procedure, contratti tipo) e riceve circa 500 domande al mese da collaboratori interni. L'ingestione iniziale è un costo una tantum di pochi euro. Lo storage dell'indice resta un costo fisso mensile contenuto, indipendente dal numero di domande. Il retrieval su 500 domande è trascurabile. La generazione, assumendo un prompt medio di circa 2.000 token e una risposta di 300 token, con un modello di fascia economica, porta il totale mensile a una cifra ragionevole, spesso inferiore a un singolo abbonamento SaaS aziendale. È proprio per rendere questo conto prevedibile che un abbonamento a soglia fissa, come quello a 12 euro al mese con indicatore di consumo, risulta comodo per chi vuole evitare sorprese in fattura: si sa in anticipo quanto si spenderà, e il gauge segnala quando si sta per esaurire la soglia inclusa.

In sintesi: dove guardare prima di firmare un contratto

Quando valuta un fornitore o un'architettura RAG, chieda sempre di scomporre il preventivo nelle quattro voci viste: quanto costa caricare e aggiornare i documenti, quanto costa mantenere l'indice attivo ogni mese, quanto incide il retrieval per domanda e quanto costano i token di generazione al volume di traffico previsto. Un fornitore che quota solo «un prezzo per domanda» senza distinguere queste componenti rende difficile capire cosa succede se il volume di documenti cresce, o se cambia il modello di generazione usato. Chi offre API e documentazione tecnica aperta, come descritto nella sezione sviluppatori, permette anche di misurare direttamente token consumati e tempi di risposta, invece di fidarsi solo di una stima a priori.