Leggere i tuoi documenti

Il limite che il contesto non puo risolvere

Immagina di voler costruire un assistente capace di rispondere a domande su tutta la documentazione interna della tua azienda: 50.000 pagine, aggiornate ogni settimana.

Anche con una finestra da 1 milione di token, non puoi metterci tutto. E se potessi, il costo sarebbe proibitivo e la qualita delle risposte peggiorerebbe: i modelli faticano a estrarre informazioni precise in contesti molto lunghi.

Serve un altro approccio. E il RAG — Retrieval-Augmented Generation.

L'idea fondamentale

Invece di dare tutto il documento al modello, gli dai solo i passaggi pertinenti per la domanda. Per farlo servono due cose:

1. Un indice: una rappresentazione vettoriale di tutti i documenti, salvata in anticipo.
2. Un motore di ricerca semantica: quando arriva una domanda, trova i passaggi semanticamente piu vicini.

I passaggi trovati vengono poi iniettati nel contesto dell'LLM insieme alla domanda. Il modello risponde appoggiandosi a questi estratti.

E esattamente cio che fa la ricerca semantica con gli embeddings che conosci gia dal capitolo 03 — ma applicata a documenti reali.

Il pipeline in tre passaggi

1. Indicizzazione (una sola volta)

Si taglia il documento in chunks — estratti di qualche centinaio di token (con una leggera sovrapposizione per non tagliare il senso al confine).

Ogni chunk viene poi convertito in vettore da un modello di embedding. Questi vettori vengono salvati in un database vettoriale (Pinecone, Chroma, pgvector…).

Questo passaggio si fa una sola volta, o a ogni aggiornamento del documento.

2. Ricerca (a ogni domanda)

Quando arriva una domanda, la convertiamo in vettore con lo stesso modello di embedding.

Calcoliamo la similarita coseno tra questo vettore-domanda e tutti i vettori-chunk della base. I k chunk piu vicini vengono recuperati — in genere 3-5.

Questa e la ricerca semantica: "vicino" non significa "contiene le stesse parole", ma "esprime un significato simile".

3. Generazione

I chunk recuperati vengono assemblati in un prompt:

Estratti dal documento:
[Estratto 1 — ...]
[Estratto 2 — ...]
[Estratto 3 — ...]

Domanda: {domanda dell'utente}

Questo prompt viene inviato all'LLM, che genera una risposta basandosi sugli estratti. Il modello non ha memorizzato il documento: lo legge nel momento in cui gli fai la domanda.

Visualizzazione del pipeline

Ecco il sistema in azione su un mini-corpus di planetologia. Scegli una domanda: osserva quali chunk vengono recuperati nello spazio vettoriale e come vengono assemblati in contesto.

Scegli una domanda: viene embedded, confrontata con i chunk del corpus, e i più pertinenti vengono iniettati nel prompt prima della generazione. È questa deviazione che permette a un LLM di rispondere su documenti che non ha mai visto durante il training.

Dimensione dei chunk: una vera scelta ingegneristica

Il taglio in chunk non e banale. E spesso la prima fonte di problemi in un sistema RAG.

Chunk troppo piccoli: ogni chunk e poco informativo. Recuperiamo frammenti che, fuori contesto, non permettono al modello di rispondere correttamente.

Chunk troppo grandi: superiamo la precisione dell'embedding. Un vettore che rappresenta 2.000 token e una media sfocata: verra recuperato per alcune domande, ma il contenuto pertinente sara annegato nel testo.

Regola pratica: chunk da 200 a 500 token, con overlap del 10-15%. Il parametro giusto dipende dalla struttura dei tuoi documenti.

Quale modello di embedding usare?

Non tutte le domande arrivano ai chunk giusti con lo stesso embedding. Un modello addestrato su italiano generalista recuperera male del codice Python; un modello addestrato sul codice recuperera male scambi medici.

Le scelte che ricorrono in pratica:

• text-embedding-3-small / -large (OpenAI) — qualita solida, generalista, multilingua. La scelta di default quando si comincia.
• bge-large / bge-m3 (BAAI) — open-source, eccellente in multilingua, in cima ai benchmark MTEB nel 2024.
• all-MiniLM-L6-v2 (Sentence-Transformers) — piccolo, veloce, distribuibile in locale. Buon rapporto qualita/costo per casi d'uso semplici.
• Modelli specializzati per dominio (codice, biomedico, giuridico) — sempre migliori sulla loro nicchia, piu deboli altrove.

Regola pratica: testare due o tre modelli sui tuoi dati e sulle tue domande. La classifica MTEB dice poco del tuo caso d'uso specifico.

Il reranker: una seconda passata

La ricerca vettoriale ha un difetto: e veloce ma grossolana. Un embedding di qualche centinaio di dimensioni e una media sfocata di un testo. Molti chunk "piu o meno pertinenti" galleggiano in superficie, e quelli davvero buoni a volte vengono annegati.

Da qui un passaggio diventato standard nei sistemi RAG seri: il reranker.

L'idea in due tempi:

1. Prima passata (ricerca vettoriale) — recupera i 50 o 100 chunk piu vicini. Veloce.
2. Seconda passata (reranking) — un piccolo modello (spesso un cross-encoder) valuta ogni coppia (domanda, chunk) insieme, da un punteggio preciso, e tiene i top 5-10. Lento per chunk, ma lo si fa solo sui 50 candidati della prima passata.

Il reranker vede la domanda e il chunk allo stesso tempo, cosa che l'embedding non fa. Coglie sottigliezze semantiche che la ricerca vettoriale manca. Cohere, Jina AI, BAAI offrono reranker pronti all'uso.

Senza reranker, il tuo RAG si appiattisce. Con uno, la qualita salta di un livello senza cambiare il resto della pipeline.

Perche non full-text search?

Domanda legittima: perche non fare semplicemente una ricerca per parole chiave, come un motore di ricerca classico?

La ricerca vettoriale e complementare, non un sostituto. Trova passaggi semanticamente vicini anche quando la formulazione e diversa. "Quale pianeta ruota piu lentamente?" puo recuperare un chunk che parla di "periodo orbitale" senza che quelle parole siano nella domanda.

In pratica, i sistemi migliori combinano i due approcci: hybrid search — un punteggio che combina similarita vettoriale e corrispondenza di parole chiave (BM25).

I limiti del RAG

Il RAG non e magia. Ecco i problemi piu frequenti:

Chunk tagliato male. Se una risposta si estende su due chunk e il confine cade nel punto sbagliato, nessuno dei due chunk e sufficiente da solo.

Il "lost in the middle" dentro il chunk. Se il chunk e troppo lungo, le informazioni importanti possono finire al centro ed essere ignorate dal modello.

Domanda ambigua. Se la domanda e vaga, l'embedding-domanda sara lontano dalla maggior parte dei chunk pertinenti. Soluzione: riformulare la domanda, o generarne piu varianti.

Allucinazioni sugli estratti. L'LLM puo estrapolare oltre cio che dicono i chunk. Il RAG riduce le allucinazioni, non le elimina.

Cosa cambia il RAG in pratica

Il RAG e oggi la tecnica di riferimento per collegare un LLM a dati privati o recenti. Quasi tutti i chatbot aziendali, gli assistenti di documentazione e gli strumenti di monitoraggio si appoggiano a questo.

Ma e ancora un'architettura "passiva": il modello riceve una domanda, cerca chunk, risponde. Per compiti piu complessi — cercare, poi agire in base al risultato, poi cercare ancora — bisogna salire di un livello.

Aggiornato il 10 maggio 2026