Mi capita ogni mese di sentire la stessa frase in discovery: "vogliamo fare il RAG sui nostri documenti". La pronunciano CFO, CTO, ufficio operations. La pronunciano anche aziende che non hanno l’infrastruttura per gestire un foglio Excel condiviso.
RAG — Retrieval Augmented Generation — è una tecnica seria. Quando serve, serve davvero. Quando non serve, diventa il modo più costoso e fragile per fare ricerca full-text che esista oggi sul mercato.
Provo a dare regole pratiche.
Quando RAG ha senso
Tre condizioni, tutte e tre necessarie:
1. Hai un corpus largo e statico-ish. Largo significa: troppi documenti perché un umano li legga in tempo utile. Statico-ish significa: cambia di settimana in settimana, non di minuto in minuto. 2. La domanda del lettore è in linguaggio naturale, non puntuale. Se ti basta "trova la fattura 12345", non serve RAG, serve grep. RAG serve quando la query è "cosa abbiamo scritto in passato sui contratti che includono clausole di non concorrenza estese a 24 mesi" — testo, non chiave. 3. L’output che ti aspetti è una sintesi argomentata, non un singolo fatto. Se hai bisogno della risposta esatta a una domanda chiusa, una funzione SQL su un DB strutturato fa molto meglio. RAG brilla quando devi mettere insieme passaggi che vivono in posti diversi.
Tutte e tre. Manca anche solo una, e quasi sempre stai sovra-ingegnerizzando.
Quando NON ha senso
Dieci aziende su cento ce l’hanno davvero, il problema RAG. Le altre 90:
- ◆Hanno 200 documenti. Un GPT con tutta la roba nel contesto fa benissimo, costa meno del setup di un vector DB, e la qualità delle risposte è migliore. Soglia indicativa: sotto i 50.000 token totali stai in-context, sopra ti serve retrieval.
- ◆Hanno corpus che cambia ogni ora. Reindicizzazione continua è dolorosa. Per quegli use case quasi sempre la risposta giusta è un agente che chiama un tool API/SQL in tempo reale, non una vector store.
- ◆Hanno bisogno di citazioni esatte e auditabili. RAG non garantisce che il modello citi davvero quello che ha trovato; tende a parafrasare. Per compliance hai bisogno di tool che ti diano il documento sorgente, la pagina, la riga — meglio un motore di ricerca classico con highlighting.
Cosa costa davvero
Setup di un RAG decente per un cliente PMI medio (10-50 mila documenti, 3-5 utenti concorrenti, dominio italiano):
- ◆Estrazione + chunking + embedding: 2-3 settimane di lavoro la prima volta, poi 1-2 giornate ogni grande reindicizzazione.
- ◆Infrastruttura: vector DB managed (Pinecone, Supabase pgvector) parte da circa €30/mese, sale velocemente con volume e QPS.
- ◆Costo per query: dipende dal modello, ma orientativamente €0.005-€0.02 per ricerca con sintesi.
- ◆Manutenzione: 0.5-1 giorno/mese di monitoring + re-tuning. Non è zero.
Per molti scenari, una soluzione "no-RAG" — un agente che fa SQL su Postgres + un search server tipo Meilisearch davanti — costa la metà e funziona meglio.
Il caso reale che ci ha convinto
Studio legale milanese, 18 mila pratiche storiche, vincolo: "i clienti ci pagano per la nostra memoria istituzionale, ma quella memoria sta in testa ai due partner senior che vanno in pensione tra 18 mesi". Lì RAG ha senso vero. Abbiamo indicizzato gli archivi PDF anonimizzati, costruito un agente che risponde a domande tipo "abbiamo mai visto una clausola compromissoria su un settore X con risultato Y", e cita le pratiche. Un junior in 5 minuti recupera l’intuizione che prima richiedeva di citofonare in ufficio al partner.
Setup: 3 settimane di lavoro, costo mensile ~€90 di infra, ROI calcolato sul tempo del partner risparmiato: payback in 2 mesi.
La domanda da farsi
Quando un cliente ci chiede "vorremmo fare il RAG", la prima cosa che facciamo è chiedergli di descriverci tre query tipo che vorrebbe poter fare. Se le query sono fatti puntuali, gli proponiamo SQL+search. Se sono sintesi, e il corpus è grande, allora RAG. Se sono sintesi e il corpus è piccolo, GPT in-context.
Il 70% delle volte la risposta giusta non è RAG. La differenza tra noi e un’azienda che vende RAG come unico martello: noi non abbiamo un martello solo.