RAG: Fuffa per Investitori o Svolta Reale? La Verità dal Campo.

Quel giorno che abbiamo buttato 200 ore su un RAG che non funzionava.

L'altro giorno in agenzia è successa una cosa che capita spesso, ma di cui nessuno parla. Un cliente, esaltato da un articolo letto chissà dove, ci chiede: "Vogliamo un sistema RAG. Un'intelligenza artificiale che risponda alle domande dei nostri clienti usando la nostra documentazione. Straordinario, no?". Sulla carta, sì. Nella pratica, è l'inizio di un percorso a ostacoli dove il traguardo non è per niente scontato. Abbiamo visto progetti RAG (Retrieval-Augmented Generation, per chi ama le sigle) presentati come la bacchetta magica per il customer service, la ricerca interna, l'analisi di documenti. La promessa è semplice: prendi i tuoi dati, li dai in pasto a un Large Language Model e lui, magicamente, diventa l'esperto supremo del tuo business. Peccato che la realtà, come al solito, sia molto più sporca. Il problema non è la tecnologia in sé, che ha del potenziale. Il problema è l'idea che sia una soluzione *plug-and-play*. Non lo è. E chi vi dice il contrario, probabilmente, vi sta vendendo fumo o non ha mai passato una notte a fare debugging su un indice vettoriale che restituisce risultati senza senso. Il nostro primo vero RAG "serio" è stato un bagno di sangue. Ore passate a ottimizzare lo *chunking* dei documenti, a capire perché l'embedding scelto interpretava "report finanziario" come "analisi di bilancio" (spoiler: non sono la stessa cosa per un algoritmo) e a scoprire che la nostra base dati, apparentemente perfetta, era un colabrodo di informazioni ridondanti e obsolete. Risultato? Un sistema che, alle domande più semplici, rispondeva con una sicumera da primo della classe, ma sbagliando completamente i fatti. Un disastro. Da quel progetto, però, è nata una consapevolezza che oggi è il nostro mantra: un RAG non è un prodotto, è un processo. Un processo di sartoria che, se fatto bene, può davvero cambiare le regole del gioco. Ma preparatevi a sudare.
### La Teoria è Facile, la Pratica è un Campo Minato Partiamo dalle basi, senza fronzoli. Un sistema RAG fa due cose: recupera informazioni (Retrieval) e poi le usa per generare una risposta (Generation). Immaginatelo come un ricercatore a cui date una domanda e una biblioteca. Prima cerca i libri giusti (la vostra documentazione), poi legge i paragrafi pertinenti e infine scrive una risposta di sintesi. Semplice. In teoria. Il primo punto dove di solito scoppia tutto è il **Retrieval**. Se il sistema non trova l'informazione giusta, l'LLM genererà una risposta basata sul nulla o, peggio, si inventerà qualcosa di plausibile ma falso (le famose "allucinazioni"). Per evitare di andare a gambe all'aria qui, bisogna ossessionarsi su tre elementi: 1. **La Qualità dei Dati:** Banale? Forse. Ma il 90% dei progetti RAG che falliscono, muoiono qui. Documenti duplicati, informazioni contraddittorie, PDF scansionati che sembrano geroglifici per l'OCR. Prima di scrivere una riga di codice, serve un lavoro da certosino: pulire, standardizzare, versionare. A Rosignano abbiamo passato più tempo a sistemare i file del cliente che a sviluppare il backend. È un lavoro oscuro, che nessuno vede, ma è l'unica fondamenta solida su cui costruire. 2. **Strategia di Chunking:** Come spezzetti i tuoi documenti in pezzi digeribili per la macchina? Puoi fare chunk di dimensione fissa, basarti sui paragrafi, usare tecniche semantiche. Ogni approccio ha pro e contro. Un chunk troppo piccolo perde il contesto; uno troppo grande introduce rumore. Non c'è una risposta giusta. C'è solo quella che funziona per i *tuoi* documenti. E per trovarla, si fa una sola cosa: si testa. Si prova, si misura, si fallisce e si riprova. 3. **L'Embedding Model e il Database Vettoriale:** Qui la cosa si fa tecnica. L'embedding model è il traduttore che trasforma i tuoi pezzi di testo in coordinate numeriche (vettori). Il database vettoriale (noi usiamo spesso Qdrant, ma ce ne sono altri) è l'archivio che organizza questi vettori in uno spazio multidimensionale per trovare quelli più "vicini" alla domanda dell'utente. La scelta di questi due componenti è critica. Un modello di embedding generalista potrebbe non cogliere le sfumature del vostro gergo tecnico. A Kampala, per un progetto su documenti agricoli, abbiamo dovuto usare un modello specializzato per capire la differenza tra "pesticida" e "fertilizzante", che per un modello standard erano quasi sinonimi. Il diavolo, qui, è davvero nei dettagli.
### Generazione: Quando l'Oracolo Inizia a Parlare (e si Spera Dica Cose Sensate) Una volta che il sistema ha recuperato i suoi bei pezzetti di informazione, li passa al Large Language Model (tipo GPT-4, per intenderci) insieme alla domanda originale. Il prompt che si costruisce è più o meno così: *"Dati i seguenti contesti [pezzo di documento 1, pezzo di documento 2, ...], rispondi a questa domanda: [domanda utente]. Sii conciso e basati solo sulle informazioni fornite."*. Anche qui, la faccenda non è un pranzo di gala. La sfida è istruire il modello a comportarsi come un assistente fedele e non come un creativo esuberante. Deve attenersi ai fatti. Se l'informazione non c'è nei documenti recuperati, deve avere l'onestà di dire: "Non lo so". Insegnargli questa umiltà è una delle parti più difficili del *prompt engineering*. Un'altra grana è la gestione delle fonti. Una buona risposta RAG non è solo corretta, è anche verificabile. Per questo, il sistema deve essere in grado di citare le sue fonti: "La risposta è X, e l'ho trovata nel documento Y, pagina Z". Questo passaggio trasforma una scatola nera in uno strumento di lavoro affidabile. Implementarlo richiede un'architettura di tracciamento meticolosa, ma è quello che separa un accrocchio da una soluzione professionale.
### Non è Tecnologia, è Artigianato. Abbiamo visto aziende spendere decine di migliaia di euro in piattaforme RAG "pronte all'uso" per poi scoprire che nessuno in azienda sapeva come gestirle, come alimentare la base di conoscenza, come interpretare i fallimenti. Il problema non era il codice, era la testa. Hanno comprato un'auto da corsa pensando che si guidasse da sola. Un progetto RAG di successo non nasce da una tecnologia, ma da un team multidisciplinare. Serve chi conosce i dati meglio delle sue tasche (spesso è qualcuno del business, non un tecnico). Serve chi sa come architettare il flusso (il backend developer). E serve chi ha la pazienza di testare, misurare e iterare (un data scientist o un AI engineer). È un lavoro di squadra. La prossima volta che sentite parlare di RAG come la soluzione a tutti i mali, fate un passo indietro. Chiedetevi: chi pulirà i dati? Chi definirà la strategia di recupero? Chi testerà i risultati? Chi manterrà il sistema vivo nel tempo? Se la risposta a queste domande è un silenzio imbarazzato, allora forse non siete pronti. E non c'è niente di male. Meglio un processo manuale che funziona, che un'automazione costosa che va a gambe all'aria al primo imprevisto. La vera innovazione non è comprare il martello più grosso, ma imparare a costruire il mobile. E per quello, ci vuole un buon artigiano, non solo un buon attrezzo.