Costruire un sistema RAG (Retrieval-Augmented Generation) in produzione sembra, sulla carta, un esercizio di assemblaggio: un retriever, un reranker, un LLM, un vector DB. Quando un grande gruppo industriale italiano ci ha chiesto di ottimizzare il proprio assistente documentale interno, abbiamo verificato quanto questa narrazione sia distante dalla realtà enterprise.
La Sfida: misurare prima di ottimizzare
Il sistema esistente combinava un retriever, un reranker open-source di uso comune (ms-marco-TinyBERT) e un LLM generativo. Sulla carta tutto in regola. Nei fatti gli ostacoli erano tre:
- Metriche oggettive assenti: su corpus tecnico in italiano le metriche generaliste non bastano a dire se una modifica migliora il sistema.
- Nessun dataset di valutazione: senza coppie domanda-risposta di qualità non esiste né fine-tuning né benchmarking.
- Componenti “default” non verificati: nessuno aveva mai misurato il contributo reale di ciascun blocco dell’architettura.
L’Approccio Tecnico: smontare la pipeline
Abbiamo affrontato il progetto come un’ottimizzazione end-to-end, intervenendo su ogni stadio.
1. Generazione sintetica del dataset. Partendo dal paper [RAFT: Adapting Language Model to Domain Specific RAG]([2403.10131] RAFT: Adapting Language Model to Domain Specific RAG), abbiamo costruito un pipeline personalizzata per LLM custom (Llama-3.0 8B, Mixtral 8x7B), basata sul Synthesizer di DeepEval ed eseguibile su HPC (High-Performance Computing, cioè i cluster di calcolo usati per addestrare i modelli). Nel ciclo di generazione abbiamo introdotto la groundedness (che rappresenta quanto una risposta è ancorata ai documenti e non inventata) al posto della più debole metrica di ‘chiarezza’. Ogni domanda viene poi valutata su tre assi: G-Eval ( che consiste in un giudizio di qualità espresso direttamente da un LLM), diversità semantica e diversità lessicale.
2. La sorpresa: il reranker peggiorava il retrieval. Misurando con metriche dedicate quanto in alto compare la risposta corretta nella lista dei risultati (Contextual Precision/Recall, MRR e MAP) abbiamo scoperto che il reranker in produzione ordinava i golden chunk (cioè i passaggi di documento da cui nasce la domanda) peggio del retriever da solo. Un caso reale di componente “scelto per default” da rimuovere. Dopo un confronto comparativo abbiamo fine-tunato BAAI/bge-reranker-v2-m3 su un nuovo dataset, realizzato a partire da dati già esistenti, contenente, per ogni query, una lista di chunk contenente il golden chunk (cioè il chunk da cui è stata generata la query) e una lista di 3 chunk distrattori (cioè chunk che non contengono informazioni utili per rispondere alla query fornita in input), ottenendo un incremento del MRR pari al 4% e del MAP pari al 7%.
3. Embedding e Vector DB. Il modello sentence-bert-italian è stato sostituito con gte-multilingual-base, vincitore del benchmark su Contextual Precision (0.65 vs 0.55). Migrato anche il vector DB da FAISS a Qdrant per scalabilità.
4. Fine-tuning dell’LLM con chunking consapevole. Abbiamo dimostrato sperimentalmente che la strategia di chunking (split casuale, split per punto, blocchi consecutivi) impatta drasticamente sulla qualità del dataset Q&A generato. Sul modello Llama-3.0 8B fine-tuned, filtrando le coppie per Standalone e Groundedness sopra soglia, abbiamo raggiunto:
- Answer Relevancy: 0.87 (baseline 0.47)
- Answer Correctness: 0.71 (baseline 0.35)
- Faithfulness: 0.77 (baseline 0.76, già elevata e mantenuta stabile dal fine-tuning)
Sul corpus tecnico in italiano utilizzato per l’esperimento e sulle metriche che abbiamo misurato, il modello fine-tuned si è quindi rivelato in grado di superare GPT-3.5 e, su rilevanza e correttezza, anche GPT-4o, pur essendo un modello molto più piccolo e ospitabile on-premise.
Il Risultato: un RAG misurabile e governabile
Il prodotto finale non è solo un sistema più accurato: è un’infrastruttura strumentata. Ogni componente, dall’embedding al reranker fino all’LLM, viene misurato con metriche dedicate; il dataset di valutazione è riproducibile; le scelte tecnologiche sono giustificate da numeri, non da bias di mercato.
Il caso del reranker rimosso è emblematico: senza misurazione avremmo continuato a usare un componente che peggiorava il sistema. Con la misurazione abbiamo identificato il problema, fine-tunato l’alternativa migliore e validato il guadagno.
Per chi implementa questo sistema nei propri flussi aziendali il vantaggio è concreto: un assistente che sbaglia meno risposte e di cui i dipendenti possono fidarsi a cui si aggiunge un metodo ripetibile per migliorarlo. Ogni modifica futura alla pipeline (un nuovo modello, un altro reranker, etc) si può validare con numeri prima di andare in produzione, invece che a intuito. Questa è la differenza tra un sistema che funziona ‘a sensazione’ e uno che l’IT può governare e difendere davanti al business.
Conclusione: la differenza la fa l’ingegneria della valutazione
In un’epoca in cui “fare un RAG” sembra ridursi a collegare LangChain a un vector DB, la vera differenza la fa l’ingegneria della valutazione: definire metriche, costruire dataset di test, verificare il contributo reale di ogni componente. È la distanza che separa un prototipo da una soluzione enterprise.