Un RAG su misura

I sistemi RAG (Retrieval Augmented Generation) sono ormai uno standard: un modello linguistico non risponde più “a memoria”, ma recupera i frammenti di testo più pertinenti da una base documentale e li usa come contesto per generare la risposta. 

Sulla carta il meccanismo è lineare: si dividono i documenti in chunk, si calcola la similarità vettoriale e si passa tutto al modello. 

Nella pratica, costruirne uno da zero — anziché affidarsi a una libreria preconfezionata — è un esercizio che smonta parecchie certezze.
La prima smentita riguarda il retrieval: si tende a pensare che sia solo una questione di vettori, distanze e similitudine del coseno. In realtà, il vero collo di bottiglia è quasi sempre a monte, nella segmentazione del testo. 

Un chunk troppo corto perde il filo del discorso; uno troppo lungo diluisce la rilevanza metrica e introduce rumore. In un sistema fatto in casa l'impatto di queste scelte è immediato: se il recupero fallisce, quasi mai la colpa è dell'algoritmo di similarità, ma di come i documenti sono stati originariamente frammentati.
Un altro aspetto istruttivo emerge quando si vincola il modello a rispondere esclusivamente basandosi sul contesto recuperato, ignorando la sua conoscenza pregressa. Se i documenti trattano un argomento in modo superficiale, la risposta sarà altrettanto superficiale. A prima vista potrebbe sembrare un fallimento del sistema, ma non lo è. È l'essenza stessa dell'architettura RAG, che scambia consapevolmente la ricchezza enciclopedica del modello con l'ancoraggio a una fonte verificabile e citabile. Comprendere a fondo questo trade-off cambia radicalmente il modo in cui si progettano i prompt e si valutano gli output.
Quando si sposta l'intera pipeline su un modello linguistico locale, emergono complessità che i servizi cloud tendono a nascondere: endpoint configurati male, policy CORS (Cross-Origin Resource Sharing), discrepanze tra il caricamento di un file locale e il serving via HTTP. 

Sono ostacoli infrastrutturali, non concettuali, eppure sono quelli che richiedono più tempo per essere risolti. La lezione che se ne ricava è una sorta di rasoio di Occam dello sviluppo: un errore sistematico e ripetitivo quasi mai nasconde una causa esotica; molto più spesso si tratta di una svista banale mascherata da sintomi allarmanti.
Con i framework pronti all'uso si ottiene un RAG funzionante in dieci minuti, ma si rinuncia a capire perché funzioni e, soprattutto, dove rischia di rompersi. 

Sviluppando la pipeline pezzo per pezzo — dal chunking al calcolo dei vettori, fino alla generazione condizionata — ogni passaggio diventa trasparente e ogni bug si trasforma in un laboratorio concettuale.
È un investimento che si ripaga quando si passa alla produzione: di fronte a una risposta imprecisa, chi ha costruito il sistema da zero sa individuare immediatamente se il problema risieda nella formattazione dei dati, nel retrieval o nei limiti intrinseca dell'architettura, anziché procedere per tentativi.
In definitiva, il valore di un RAG fatto in casa non sta nel risparmio economico rispetto a una soluzione commerciale. Sta nella competenza profonda che si acquisisce: un tipo di consapevolezza che nessun tutorial può trasmettere finché non ci si sporca davvero le mani.