Il RAG funziona. Ma non come sembra dai tutorial.

Negli ultimi tre anni abbiamo costruito sistemi di Retrieval-Augmented Generation in produzione su contratti complessi, manuali tecnici industriali, knowledge base normative. La cosa che mi sento di dire dopo qualche centinaio di ore di lavoro è: il 70% del problema non è il modello, è il chunking e il retrieval. Il restante 30% è prompt e guardrail.

Cosa vi dicono i tutorial

I tutorial di LangChain (e mille post Medium) suggeriscono questa pipeline standard:

PDF → Text → Chunking 500 tokens overlap 50 → Embedding ada-002 →
Pinecone → Top 5 cosine similarity → Prompt → LLM

Funziona? Sì, su demo. Funziona in produzione su documenti italiani complessi? No.

I problemi reali

1. PDF non è testo. Un contratto M&A italiano da 80 pagine ha tabelle, allegati, riferimenti incrociati ("come da art. 4.3"), formattazione su due colonne. Estrarre testo lineare butta via il 40% del significato. Servono parser che preservino struttura — Unstructured.io o pipeline custom.

2. Chunking fisso è il diavolo. Tagliare a 500 tokens spezza una clausola a metà. Nel chunk N hai "Le parti convengono che il pagamento avverrà". Nel chunk N+1 "entro 30 giorni dalla consegna". Il retrieval ne pesca uno, non l'altro. Il modello allucina la metà mancante.

Cosa funziona invece: chunking semantico per sezione del documento, con overlap strutturato e metadata che includono il titolo della clausola.

3. Embedding generici falliscono in italiano legale/fiscale. "Decadenza" e "prescrizione" hanno embedding simili in modelli generalisti, ma significano cose molto diverse. Il retrieval mischia.

Cosa funziona: embedding multilingual fine-tuned (Cohere multilingual, OpenAI text-embedding-3-large) + reranker (Cohere Rerank o Voyage rerank-2) sopra. Costa il 30% in più, migliora la precision del 60-80%.

4. Top-K cieco fallisce sempre. "Top 5 documenti più simili" funziona finché tutti i 5 contengono parte della risposta. Ma se la risposta è in 12 chunk diversi sparsi nel corpus, ne perdi 7.

Cosa funziona: query decomposition (il modello scompone la domanda in sub-query), retrieval su ogni sub-query, ranking aggregato.

Il mio stack 2026 per RAG italiano

Quando partiamo oggi su un progetto RAG serio, lo stack tipico è:

  • Parser: Unstructured.io con OCR (Tesseract o Azure Document Intelligence per PDF complessi)
  • Chunking: semantico, custom, conservativo (200-800 token con metadata strutturati)
  • Embedding: Cohere embed-multilingual-v3.0 o OpenAI text-embedding-3-large
  • Vector DB: Pinecone o pgvector se i volumi non superano i 10M
  • Reranker: Cohere Rerank multilingual
  • LLM: Claude 3.7 per casi che richiedono ragionamento, GPT-4o per ecosistema/cost
  • Eval: Ragas + dataset custom di 200-500 Q/A reali

La parte che nessuno fa (e che cambia tutto)

L'evaluation. Senza un set di domande di test reali con ground truth, non state facendo RAG. State sperando.

Per ogni progetto serio costruiamo un set di 100-300 domande con risposta corretta nota. Misuriamo: faithfulness (la risposta è supportata dai chunk?), answer relevancy (risponde alla domanda?), context precision (i chunk recuperati sono rilevanti?).

Senza questo, ogni modifica alla pipeline è una scommessa. Con questo, ogni modifica è un test.

In conclusione

RAG non è "facile" come sembra dai 5-minute video. È ingegneria del retrieval, fatta come si deve, con valutazione metrica e iterazione. Ma quando lo fai bene il valore è enorme — abbiamo clienti dove il RAG ha sostituito il 70% delle ore spese a leggere manualmente documentazione legale o tecnica.

Vale la pena farlo bene.