LLM e RAG: la coppia che scoppia (se non sai come prenderla)

Parliamoci chiaro. Da quando l'Intelligenza Artificiale Generativa è diventata il prezzemolo di ogni conversazione, sembra che basti nominare due acronimi – LLM e RAG – per sentirsi subito dei guru dell'innovazione. C'è un entusiasmo quasi religioso, un'aura da soluzione definitiva che, onestamente, a noi di ThinkPink fa venire l'orticaria. Perché la realtà, quella che vedi quando sei alle tre di notte a Rosignano a far ripartire un server o a Kampala a spiegare a un cliente perché il suo chatbot "rivoluzionario" risponde con ricette di torte salate, è molto diversa.

La bozza che ci era arrivata da uno dei nostri junior (o forse da un'AI, chi può dirlo ormai?) era il solito peana: "potenziare", "rivoluzionare", "sinergia perfetta". L'abbiamo cestinata. È ora di dire le cose come stanno: mettere insieme un Large Language Model con un sistema di Retrieval-Augmented Generation non è una passeggiata. È più come tentare di far collaborare un artista visionario e un archivista pignolo. Uno crea, l'altro ancora alla realtà. Uno vola, l'altro ha i piedi piantati per terra. E se non fai da mediatore, si scannano.

H2: Il Problema non è l'LLM, ma la sua beata ignoranza

Un LLM, per quanto potente sia, è un improvvisatore di talento chiuso in una stanza senza finestre. Conosce una quantità spropositata di informazioni, ma tutte datate al momento del suo ultimo addestramento. Non sa nulla di ciò che è successo cinque minuti fa. Non conosce i tuoi dati, i tuoi processi, i casini specifici del tuo business. Chiedergli di risolvere un problema attuale e contestualizzato è come chiedere a Manzoni di scrivere un pezzo sulla trap. Il risultato sarà stilisticamente impeccabile, ma completamente fuori luogo.

Questa è la cruda verità che molti consulenti in gessato evitano di menzionare. Loro ti vendono il sogno dell'"intelligenza onnisciente", ma si dimenticano di dirti che quell'intelligenza ha bisogno di un aiutino. E quell'aiutino, spesso, è un accrocchio complesso che devi costruire, manutenere e, soprattutto, capire.

Qui entra in gioco il RAG. Che non è una magia.

H2: RAG, ovvero: come dare un'ancora di realtà al sognatore

Il Retrieval-Augmented Generation è, in parole povere, il bibliotecario che passa gli appunti giusti all'artista prima che vada in scena. Il suo compito è semplice da descrivere ma diabolicamente complesso da implementare: quando arriva una domanda, il RAG va a frugare in un database di informazioni fresche e verificate – la tua documentazione interna, le tue FAQ, il tuo gestionale – e recupera i pezzi più pertinenti. Solo a quel punto passa il tutto all'LLM e gli dice: "Ok, adesso improvvisa, ma usando questa roba qui".

Sembra facile, vero? Peccato che la qualità di quello che il RAG "pesca" determini il 90% del successo. Se il tuo database è un caos di documenti duplicati, informazioni obsolete e dati non strutturati, il RAG pescherà spazzatura. E l'LLM, da bravo artista che è, userà quella spazzatura per comporre una sinfonia di assurdità. Come si dice in gergo tecnico: Garbage In, Garbage Out.

L'altro giorno, in agenzia, abbiamo passato una settimana a fare il debug di un sistema RAG che forniva risposte incoerenti. Il cliente era furioso. Alla fine, il problema non era l'algoritmo di retrieval né il prompt dell'LLM. Era un file Excel del 2018, dimenticato in una cartella remota, che conteneva listini prezzi completamente sballati. Il RAG lo trovava, lo considerava pertinente e l'LLM lo usava per generare preventivi da fantascienza. Una pezza messa male tre anni prima ci è costata ore di lavoro e una figuraccia.

H2: Non è tecnologia, è artigianato (e un sacco di sudore)

La vera sfida, quindi, non è tecnologica. La tecnologia c'è. Il punto è il lavoro sporco che nessuno vuole raccontare. Quello che facciamo a Rosignano non è implementare soluzioni cloud scintillanti, ma passare giornate a pulire database, a standardizzare formati, a creare tassonomie sensate. A parlare con chi quei dati li usa davvero per capire cosa serve e cosa no.

I nostri ragazzi a Kampala hanno tirato su un sistema di supporto per una ONG locale. Il primo prototipo di RAG era un disastro. Perché? Perché le informazioni non erano nei documenti ufficiali, ma nelle chat WhatsApp e negli appunti vocali degli operatori sul campo. Abbiamo dovuto costruire un piccolo mostro che trascrivesse l'audio, interpretasse lo slang locale e solo dopo indicizzasse le informazioni. Non era un problema di Python o di API. Era un problema di comprensione della realtà.

Quindi, prima di lanciarti a capofitto nel mondo meraviglioso degli LLM con RAG, fermati un attimo. Fai un respiro.

E poniti le domande giuste:

1. I miei dati sono una palude o un giardino ordinato? Sii onesto. Se non riesci a trovare un'informazione tu, che sei umano, come pensi possa fare un algoritmo?
2. Chi si occuperà di mantenere questo giardino? Le informazioni invecchiano. Serve un processo, servono persone responsabili. Altrimenti, nel giro di sei mesi, il tuo RAG tornerà a pescare spazzatura.
3. Ho davvero bisogno di un cannone per uccidere una zanzara? A volte, una semplice barra di ricerca fatta bene o un albero di FAQ ben strutturato risolvono il problema con un decimo del costo e della complessità. L'obiettivo è risolvere un problema di business, non avere il giocattolo più nuovo.

L'accoppiata LLM e RAG può davvero spaccare tutto. Può creare assistenti virtuali che non sono stupidi, motori di ricerca interni che capiscono le domande invece di cercare solo parole chiave, sistemi di analisi che ti estraggono il succo da migliaia di pagine. Ma non è una soluzione pronta all'uso. È un cantiere. E per costruire qualcosa di solido, serve un progetto, materiali di qualità e qualcuno che non abbia paura di sporcarsi le mani. Il resto è solo fumo venduto a caro prezzo.