RAG vs LLM diretto: ho risparmiato il 79%. La risposta era sbagliata.
Il RAG non è la soluzione. È un compromesso.
Cosa trovi in questo articolo
Ho testato RAG e LLM diretto sullo stesso documento, stessa domanda, in .NET. Dentro trovi: due tabelle con costi e qualità a confronto, il motivo per cui il RAG può costare meno e rispondere peggio, l’errore di chunking che ha rovinato tutto, e le tre regole che uso adesso per decidere quando il RAG conviene e quando no.
Tutti parlano di RAG come se fosse la soluzione definitiva. Ai costi alti. Alle risposte imprecise. Al contesto che non basta mai.
Non è così.
Il RAG è un compromesso consapevole. Ha sensi e non sensi. Saperli vale più di qualsiasi ottimizzazione.
Ho costruito una demo in .NET per testarlo sul serio. Stesso documento, stessa domanda, due approcci a confronto. Quello che ho trovato ha cambiato come penso al problema.
Prima, il problema di base
Un LLM può sbagliare per tre motivi collegati: qualità del prompt, dimensione del contesto, e come viene usato quel contesto.
Il punto critico è il secondo. Più contesto mandi, più costi. Fin qui ovvio. Ma c’è un effetto meno noto: “lost in the middle”. Il modello si perde. Le informazioni nel mezzo di un testo lungo vengono elaborate peggio di quelle all’inizio e alla fine.
Più token: costi più alti. Qualità peggiore. Due problemi insieme.
Il RAG come risposta parziale
Il RAG risolve il problema selezionando solo i chunk rilevanti dal documento. Invece di mandare tutto, mandi solo quello che serve.
Ma introduce nuova complessità. Come spezzare il testo? Quanti chunk mandare? Se troppo piccoli, perdi il contesto. Se troppo grandi, riprendi gli svantaggi del diretto.
I test mi hanno mostrato esattamente dove funziona e dove no.
Stesso documento, due approcci
Stack usato: .NET 10, Blazor Server, Claude Haiku 4.5, Voyage AI voyage-3-lite, pgvector su PostgreSQL.
Documento piccolo, primo test
Documento: un diario di viaggio nelle Marche. Circa 3KB, 7 chunk. Domanda: “Quanto costa andare in bici con il signor Aldo?”
| RAG | LLM diretto | |
|---|---|---|
| Token input | 702 | 1.348 |
| Costo | 0,0922¢ | 0,1434¢ |
| Qualità | corretto | corretto |
Entrambi rispondono bene. Il RAG costa meno, ma il vantaggio è marginale: su un documento da 3KB parliamo di frazioni di centesimo. Mandare tutto direttamente funziona. Il RAG è overkill.
Documento medio, secondo test
Documento: manuale tecnico NexCore. Circa 17KB, 36 chunk. Domanda: “Quanto paga un’azienda che firma un contratto quinquennale Enterprise Plus?”
Una domanda che richiede incrociare due sezioni diverse del manuale.
| RAG | LLM diretto | |
|---|---|---|
| Token input | 773 | 6.177 |
| Costo | 0,1270¢ | 0,6018¢ |
| Tempo | 2,9s | 3,9s |
| Qualità | ”non ho questa info” | risposta lunga ma incompleta |
Il RAG costa il 79% in meno. Ma risponde male. Il diretto costa di più e risponde comunque male.
Nessuno dei due vince.
Cosa è andato storto
Il chunking.
Ho usato un approccio a caratteri fissi. Il risultato: chunk come questo:
"gliore — ha l'ombra di un pino enorme e si vede il mare"
La parola “migliore” tagliata a metà. Le informazioni correlate spalmate su chunk diversi. Il RAG non ha trovato quello giusto perché quello giusto non esisteva come unità coerente.
La soluzione non è ottimizzare la chiamata API. È ottimizzare come entra il contesto. Chunking semantico: spezza per paragrafo o sezione, non per numero di caratteri.
Le tre regole che uso adesso
Documento piccolo, domanda semplice: LLM diretto va bene. Il RAG aggiunge complessità senza vantaggio reale.
Documento grande, domanda semplice: RAG obbligatorio. I costi scendono fino all’87%. La risposta non peggiora.
Domanda che incrocia più sezioni: né RAG né diretto bastano da soli. Serve chunking semantico o aumentare il numero di chunk recuperati. Prima di ottimizzare il prompt, ottimizza come spezzi il testo.
Quello che ho capito davvero
Il RAG non è uno switch on/off. È un sistema da calibrare.
Il chunking è il vero lavoro, non la chiamata API. Puoi avere il retrieval perfetto e la risposta sbagliata se i chunk non hanno senso come unità.
Prima di ottimizzare i prompt, ottimizza come entra il contesto. Vale per il RAG. Vale in generale.
Parti dal documento. Capisci come è strutturato. Poi decidi come spezzarlo.
Nel prossimo esperimento
Misuro la qualità del RAG con RAGAS, un framework che valuta automaticamente faithfulness e relevancy. E provo il chunking semantico per sezione invece che per caratteri. I dati li pubblico qui.