Serie AI Domande di intervista 11: Come ottimizzare il RAG?

L'ottimizzazione del RAG non è un aggiustamento singolo, ma un processo di ottimizzazione dell'intera catena. Di seguito, fornisco strategie di ottimizzazione sistematiche da quattro dimensioni: lato indicizzazione dei dati, lato recupero, lato generazione, lato valutazione, insieme a esperienze pratiche da menzionare durante il colloquio.

1. Ottimizzazione lato indicizzazione dei dati (migliorare la qualità della "knowledge base")

Questa è l'area più trascurata ma con il maggior impatto immediato.

Punto di ottimizzazione	Fenomeno problematico	Azione specifica	Indicatore di risultato
Parsing dei documenti	Tabelle e diagrammi di flusso nei PDF vengono ignorati, o il testo è illeggibile/ordinato male.	Usare librerie di parsing migliori (es. `unstructured`, modalità di conservazione layout di `pypdf`); per le tabelle, estrarre con `pandas` e convertire in Markdown.	Recall +5~15%
Dimensione del chunk	Chunk troppo piccolo perde contesto (es. pronome "lui" in "l'fatturato di lui è cresciuto quest'anno"); chunk troppo grande introduce rumore nel recupero.	Sperimentare diverse dimensioni (256/512/768 token), overlap 10~20%; per documenti lunghi, segmentare per confini semantici (paragrafo/intestazione) anziché lunghezza fissa.	Hit rate / Fedeltà
Metadati aggiuntivi	Viene recuperato un paragrafo rilevante ma non si può risalire alla fonte o al tempo, o è necessario filtrare per dominio.	Aggiungere metadati a ogni chunk: `source` (nome file/URL), `timestamp`, `page_num`, `doc_type`. Usare filtri durante il recupero (es. `doc_type == 'legale'`).	Precisione del filtro
Scelta del modello di embedding	Embedding generici hanno prestazioni scadenti in domini verticali (medicina, codice, legale).	Usare modelli fine-tuning sul dominio (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); o fare fine-tuning del proprio modello embedding (con triplet loss).	MRR@10 +10~20%

2. Ottimizzazione lato recupero (rendere la "consultazione" più precisa)

Il recupero determina la qualità dei "riferimenti" forniti al LLM.

Punto di ottimizzazione	Fenomeno problematico	Azione specifica	Effetto
Recupero ibrido	Il recupero vettoriale non corrisponde a termini precisi (es. modello prodotto `ABC-123`), il recupero per parole chiave non capisce sinonimi.	Usare sia recupero vettoriale (semantico) che BM25 (keyword), combinati con pesi (es. 0.7vettore + 0.3BM25) o fusion tramite rerank.	Recall +10~25%
Reranking	I primi risultati dal recupero vettoriale non sono sempre i più rilevanti; il 10° potrebbe essere il migliore.	Usare un modello cross‑encoder (es. `BGE‑reranker-v2`, Cohere Rerank) per riordinare il candidato set (es. top 20) e prendere top‑K.	Hit rate migliorato significativamente (specialmente top‑1)
Riscrittura della query	La domanda dell'utente è vaga o con riferimenti ambigui (es. "Qual è il suo prezzo?").	Usare un LLM per riscrivere la domanda originale in una forma più adatta al recupero (es. "Quanto costa l'iPhone 15?"); o completare utilizzando la cronologia della conversazione.	Recall +5~15%
HyDE	Domanda troppo breve o astratta (es. "Parla della fotosintesi"), il recupero diretto è scarso.	Prima far generare al LLM una risposta ipotetica, poi usare questa risposta per recuperare i documenti.	Adatto per domini aperti, non per domande fattuali precise.
Regolazione del numero Top‑K	K troppo piccolo può perdere informazioni chiave; K troppo grande aumenta consumo di token e rumore.	Sperimentare K=3/5/10, osservare il trade‑off tra recall e fedeltà della risposta.	Trade‑off efficienza vs qualità

3. Ottimizzazione lato generazione (far usare bene i riferimenti al LLM)

Anche se il recupero è preciso, un prompt scadente o un modello debole non servono.

Punto di ottimizzazione	Fenomeno problematico	Azione specifica	Effetto
Ingegneria del prompt	Il LLM ignora il contenuto recuperato o inventa.	Istruzioni chiare: "Rispondi solo in base ai seguenti materiali di riferimento. Se i materiali sono insufficienti o non pertinenti, rispondi 'Non ci sono informazioni sufficienti'." Aggiungere esempi few‑shot che mostrano come citare le fonti.	Fedeltà +20~40%
Compressione del contesto	Il contenuto recuperato è troppo lungo (oltre la finestra di contesto del modello) o contiene molto rumore.	Usare `LLMLingua` o `contesto selettivo` per comprimere, mantenendo solo le frasi più rilevanti prima di inviare al LLM.	Riduce il rischio di perdita di informazioni
Aggiornamento del modello LLM	Modelli piccoli (7B) non riescono a eseguire ragionamenti complessi o a ricordare contesti lunghi.	Passare a modelli più potenti (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Accuratezza del ragionamento notevolmente migliorata
Streaming e citazioni	L'utente non può verificare l'affidabilità della risposta.	Durante la generazione, far sì che il LLM produca `[citation:1]` corrispondente al numero del documento recuperato. Il backend allega il link originale.	Fiducia dell'utente + debug
Calibrazione del rifiuto di rispondere	Il modello inventa quando non dovrebbe, o dice di non sapere quando dovrebbe rispondere.	Impostare una soglia di similarità: se la similarità coseno del chunk top‑1 recuperato con la domanda è inferiore a 0.7, istruire il LLM "materiale non pertinente".	Riduce il tasso di allucinazioni

4. Valutazione e iterazione (sapere dove regolare)

Senza metriche non si può ottimizzare.

Punto di ottimizzazione	Azione	Indicatore
Costruzione del set di valutazione	Preparare 100~300 domande reali degli utenti + risposte standard + ID corretti dei documenti recuperati.	Coprire diversi livelli di difficoltà e intenzioni.
Valutazione automatica	Usare RAGAS (Faithfulness, Answer Relevance, Context Recall) o TruLens.	Tre metriche chiave: fedeltà, pertinenza della risposta, recall del contesto.
Valutazione manuale	Ogni settimana campionare 20 casi negativi, analizzare il tipo di errore (fallimento recupero / errore di generazione / knowledge base carente).	Priorità di miglioramento.
Test A/B	In ambiente di produzione, testare diverse strategie di recupero (es. BM25 vs recupero ibrido) su gruppi separati.	Metriche online: soddisfazione utente, tasso di risposte non trovate.

5. "Esperienza pratica" da menzionare durante il colloquio (punti extra)

"Nel progetto RAG di cui ero responsabile, il tasso di hit rate iniziale era solo del 67%. Ho fatto tre cose:
1. Passare da chunk fissi a 1024 a segmentazione semantica dinamica (basata su intestazioni e paragrafi), hit rate salito al 74%;
2. Aggiunto recupero ibrido (vettore + BM25) e un piccolo modello di rerank, hit rate salito all'83%;
3. Ottimizzato il prompt e imposto l'obbligo di [Informazioni non trovate], il tasso di allucinazioni è sceso dal 22% a meno del 5%.

Inoltre, abbiamo creato una pipeline di valutazione continua, eseguendo il punteggio RAGAS su 200 domande prima di ogni modifica per garantire che non ci fossero regressioni."

Riepilogo finale: una mappa completa dell'ottimizzazione RAG

Livello dati ─→ Pulizia documenti, ottimizzazione chunk, arricchimento metadati, embedding di dominio
Livello recupero ─→ Recupero ibrido, rerank, riscrittura query, HyDE, ottimizzazione Top-K
Livello generazione ─→ Rafforzamento prompt, istruzioni, compressione, citazioni, soglia di rifiuto
Livello valutazione ─→ Set di valutazione, RAGAS, analisi manuale, esperimenti A/B