L'Illusione del "Chat with your PDF"

Negli ultimi 12 mesi, migliaia di aziende hanno lanciato proof-of-concept (PoC) basati su RAG (Retrieval-Augmented Generation). La promessa è allettante: dare in pasto la documentazione aziendale a un LLM e ottenere un oracolo onnisciente.

La realtà dei sistemi in produzione è ben diversa. Una volta superata la fase di demo con 10 documenti, emergono i veri problemi:

1. Retrieval Accuracy: Il sistema recupera chunk irrilevanti che confondono l'LLM.
2. Context Window Limits: Non possiamo inserire interi manuali nel prompt.
3. Lost in the Middle: L'LLM tende a ignorare le informazioni nel mezzo di contesti lunghi.
4. Latency: Query complesse possono richiedere secondi, rendendo l'esperienza utente inaccettabile.
5. Cost Explosion: Ogni query che passa 10k token al modello costa denaro reale.

In Rayo Consulting, abbiamo standardizzato un'architettura Advanced RAG che mitiga questi rischi. Ecco i componenti chiave.

---

1. Chunking Strategico: Oltre i 500 Caratteri

Il chunking "naive" (dividere il testo ogni 500 caratteri) è il peccato originale di molti sistemi RAG. Questo approccio:

• Spezza frasi a metà
• Separa titoli dal loro contenuto
• Distrugge il contesto semantico necessario per la comprensione

Semantic Chunking

Utilizziamo Semantic Chunking: un algoritmo che analizza la densità semantica del testo usando embedding. Il processo:

1. Embedding Sentence-by-Sentence: Ogni frase viene convertita in un vettore.
2. Similarity Analysis: Calcoliamo la similarità coseno tra frasi consecutive.
3. Breakpoint Detection: Quando la similarità scende sotto una soglia (es. 0.7), identifichiamo un cambio di argomento.
4. Chunk Creation: Creiamo chunk che preservano l'integrità tematica.

Questo approccio garantisce che ogni chunk sia semanticamente coeso, migliorando drasticamente la qualità del retrieval.

Hierarchy-Aware Chunking per Documenti Strutturati

Per documenti legali, contratti, o manuali tecnici con struttura gerarchica, utilizziamo un approccio diverso:

• Parsing Strutturale: Identifichiamo la gerarchia (Capitolo → Sezione → Paragrafo).
• Metadata Enrichment: Ogni chunk include metadati sulla sua posizione nella gerarchia.
• Parent-Child Linking: Manteniamo riferimenti bidirezionali tra chunk padre e figli.

Esempio pratico: Un chunk contenente "Articolo 5, Comma 3" include nei metadati il riferimento all'Articolo 5 completo, permettendo al sistema di recuperare contesto aggiuntivo quando necessario.

Sliding Window con Overlap

Per testi narrativi o tecnici senza struttura chiara, utilizziamo una tecnica di sliding window:

• Window Size: 512 token
• Overlap: 128 token (25%)
• Rationale: L'overlap garantisce che informazioni importanti ai confini dei chunk non vengano perse.

---

2. Hybrid Search: Il Meglio di Due Mondi

Affidarsi solo ai Vector Database (ricerca semantica) è un errore comune. I vettori sono ottimi per concetti astratti ("trova documenti su machine learning"), ma pessimi per:

• Keyword Esatte: Codici prodotto (es. "SKU-12345")
• Acronimi Specifici: "GDPR", "API-REST"
• Date e Numeri: "Q4 2023", "€50.000"
• Nomi Propri: "Contratto Rossi-Bianchi"

Architettura Hybrid Search

La nostra soluzione implementa una ricerca ibrida che combina:

Sparse Retrieval (BM25)

• Algoritmo: BM25 (Best Match 25), evoluzione del TF-IDF.
• Vantaggi: Eccellente per match esatti di keyword.
• Implementazione: Elasticsearch o Apache Solr.

Dense Retrieval (Vector Search)

• Modello: Embeddings da modelli come text-embedding-3-large (OpenAI) o bge-large-en-v1.5.
• Database: Qdrant, Pinecone, o Weaviate.
• Vantaggi: Cattura similarità semantica ("auto" ≈ "veicolo").

Fusion Strategy: Reciprocal Rank Fusion (RRF)

I risultati dei due sistemi vengono combinati usando RRF:

RRF_score(d) = Σ 1 / (k + rank_i(d))

Dove:

• d è il documento
• rank_i(d) è il ranking del documento nel sistema i
• k è una costante (tipicamente 60)

Questo approccio è superiore al semplice averaging perché:

• Non richiede normalizzazione degli score
• Penalizza meno i documenti che appaiono solo in un sistema
• È robusto a differenze di scala tra i sistemi

Risultati Pratici

Nei nostri benchmark su dataset aziendali:

• BM25 solo: 67% accuracy
• Vector Search solo: 72% accuracy
• Hybrid (RRF): 89% accuracy

---

3. Re-Ranking: La Fase Critica

Il retrieval iniziale (BM25 + Vector) restituisce tipicamente 20-50 documenti candidati. Passarli tutti all'LLM:

• Aumenta i costi (più token)
• Aumenta la latenza (più tempo di processing)
• Introduce rumore (informazioni irrilevanti confondono il modello)

Cross-Encoder Re-Ranker

Introduciamo un modello Cross-Encoder che analizza la coppia (Query, Documento) e assegna uno score di rilevanza preciso.

Differenza tra Bi-Encoder e Cross-Encoder

• Bi-Encoder (usato nel retrieval): Codifica query e documento separatamente, poi calcola similarità. Veloce ma meno preciso.
• Cross-Encoder: Codifica query e documento insieme, permettendo interazione tra i token. Lento ma molto più preciso.

Implementazione

from sentence_transformers import CrossEncoder

model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')

# Dopo il retrieval iniziale
candidates = hybrid_search(query, top_k=50)

# Re-ranking
pairs = [(query, doc.text) for doc in candidates]
scores = model.predict(pairs)

# Selezioniamo solo i top-5
top_docs = sorted(zip(candidates, scores), 
                  key=lambda x: x[1], 
                  reverse=True)[:5]

Impatto sul Performance

• Precision@5: +23% rispetto al retrieval senza re-ranking
• Latency: +150ms (accettabile per la maggior parte dei casi d'uso)
• Cost: Minimo (modelli small, inference veloce)

---

4. Query Transformation: Aiutare l'Utente a Cercare Meglio

L'utente raramente formula domande perfette per un motore di ricerca. Le query reali sono:

• Ambigue: "Come funziona il processo?"
• Incomplete: "Prezzi"
• Mal formulate: "Cosa dice il contratto su quella cosa?"

Query Expansion

Generiamo automaticamente varianti della query originale:

1. Synonym Expansion: "auto" → ["automobile", "veicolo", "macchina"]
2. Acronym Expansion: "AI" → ["Artificial Intelligence", "Intelligenza Artificiale"]
3. Multi-Query Generation: L'LLM genera 3-5 riformulazioni della query originale.

Esempio:

Query originale: "Come posso cancellare il mio account?"

Varianti generate:
- "Procedura di eliminazione account utente"
- "Cancellazione dati personali e account"
- "Come rimuovere definitivamente il profilo"

Eseguiamo il retrieval su tutte le varianti e combiniamo i risultati.

HyDE (Hypothetical Document Embeddings)

Tecnica avanzata che inverte il problema:

1. Generazione Ipotetica: L'LLM genera una risposta ipotetica (anche se potenzialmente falsa) alla domanda dell'utente.
2. Embedding della Risposta: Convertiamo la risposta ipotetica in un vettore.
3. Search: Cerchiamo documenti simili alla risposta ipotetica, non alla domanda.

Rationale: I documenti reali assomigliano più alle risposte che alle domande.

Esempio:

Query: "Quali sono i vantaggi del nostro piano Premium?"

Risposta Ipotetica (generata dall'LLM):
"Il piano Premium offre storage illimitato, supporto prioritario 24/7, 
e accesso anticipato alle nuove funzionalità..."

→ Cerchiamo documenti che assomigliano a questa descrizione

Step-Back Prompting

Per query complesse, generiamo prima una "step-back question" più generale:

Query specifica: "Come configuro l'autenticazione OAuth2 con Google?"

Step-back question: "Quali sono i metodi di autenticazione supportati?"

Recuperiamo documenti per entrambe le query, garantendo sia contesto generale che dettagli specifici.

---

5. Metadata Filtering: Sicurezza e Rilevanza

Ogni chunk nel nostro sistema include metadati ricchi:

{
  "text": "...",
  "metadata": {
    "source": "contratto_2024.pdf",
    "page": 5,
    "section": "Termini di Pagamento",
    "access_level": "internal",
    "department": "finance",
    "last_updated": "2024-05-15",
    "language": "it"
  }
}

Pre-Filtering

Prima del retrieval, applichiamo filtri basati su:

• Permessi utente: Solo documenti accessibili all'utente corrente
• Freshness: Solo documenti aggiornati negli ultimi N mesi
• Dipartimento: Solo documenti rilevanti per il dipartimento dell'utente

Questo riduce drasticamente lo spazio di ricerca e migliora la rilevanza.

---

6. Context Compression: Massimizzare l'Informazione

Anche dopo il re-ranking, i top-5 documenti possono essere lunghi. Utilizziamo tecniche di compressione:

Extractive Summarization

Per ogni documento recuperato, estraiamo solo le frasi più rilevanti rispetto alla query:

from transformers import pipeline

summarizer = pipeline("summarization", 
                     model="facebook/bart-large-cnn")

compressed_docs = []
for doc in top_docs:
    # Estraiamo solo le parti rilevanti
    summary = summarizer(doc.text, 
                        max_length=200, 
                        min_length=50)
    compressed_docs.append(summary)

LLM-based Compression

Utilizziamo un LLM veloce (es. GPT-3.5-turbo) per comprimere i documenti:

Prompt: "Estrai solo le informazioni rilevanti per rispondere a: {query}
Documento: {doc_text}"

Questo riduce il context window del 40-60% mantenendo le informazioni critiche.

---

7. Evaluation: Misurare per Migliorare

Non puoi migliorare ciò che non misuri. Utilizziamo il framework RAGAS (Retrieval-Augmented Generation Assessment) per valutare:

Metriche Chiave

1. Context Precision: Quanti dei documenti recuperati sono effettivamente rilevanti?
2. Context Recall: Tutti i documenti rilevanti sono stati recuperati?
3. Faithfulness: La risposta generata è fedele ai documenti recuperati (no allucinazioni)?
4. Answer Relevancy: La risposta è pertinente alla domanda?

Test Set Creation

Creiamo un golden dataset di 500+ coppie (query, risposta attesa) rappresentative dei casi d'uso reali.

Continuous Monitoring

In produzione, monitoriamo:

• User Feedback: Thumbs up/down su ogni risposta
• Retrieval Latency: p50, p95, p99
• LLM Token Usage: Per ottimizzare i costi
• Cache Hit Rate: Quante query possono essere servite da cache

---

8. Production Deployment: Scalare a Milioni di Documenti

Architettura Distribuita

User Query
    ↓
Load Balancer
    ↓
API Gateway (Rate Limiting, Auth)
    ↓
Query Processing Service
    ↓
┌─────────────┬──────────────┬─────────────┐
│   BM25      │   Vector DB  │  Re-Ranker  │
│ (Elastic)   │  (Qdrant)    │  (Triton)   │
└─────────────┴──────────────┴─────────────┘
    ↓
Context Assembly
    ↓
LLM Inference (OpenAI / Self-hosted)
    ↓
Response

Caching Strategy

Implementiamo caching a più livelli:

1. Query Cache: Risposte complete per query identiche (TTL: 1 ora)
2. Retrieval Cache: Risultati del retrieval per query simili (TTL: 24 ore)
3. Embedding Cache: Embedding di documenti statici (TTL: infinito)

Incremental Indexing

Per gestire aggiornamenti continui:

• Batch Indexing: Ogni notte, re-indicizziamo documenti modificati
• Real-time Updates: Documenti critici (es. listini prezzi) vengono indicizzati in tempo reale
• Soft Deletes: Documenti rimossi vengono marcati come "deleted" ma non eliminati fisicamente (per audit trail)

---

9. Casi d'Uso Avanzati

Multi-Modal RAG

Estendiamo il RAG a immagini e tabelle:

• Vision Models: Usiamo CLIP per indicizzare immagini
• Table Parsing: OCR + structure detection per estrarre dati da tabelle
• Cross-Modal Search: "Trova grafici che mostrano trend di vendita Q4"

Conversational RAG

Manteniamo il contesto conversazionale:

conversation_history = [
    {"role": "user", "content": "Quali sono i nostri piani?"},
    {"role": "assistant", "content": "Abbiamo Basic, Pro, Enterprise"},
    {"role": "user", "content": "Quanto costa il secondo?"}  # "secondo" = Pro
]

# Risolviamo le co-referenze prima del retrieval
resolved_query = resolve_coreferences(
    current_query="Quanto costa il secondo?",
    history=conversation_history
)
# → "Quanto costa il piano Pro?"

---

Conclusioni

Costruire un sistema RAG che "funziona" su un notebook Jupyter richiede un pomeriggio. Costruirne uno che scala su 100.000+ documenti con un'accuratezza >95% e latenza <500ms richiede ingegneria robusta.

Checklist per il Successo

• [ ] Chunking strategico (semantic o hierarchy-aware)
• [ ] Hybrid search (BM25 + Vector)
• [ ] Re-ranking con cross-encoder
• [ ] Query transformation (expansion, HyDE)
• [ ] Metadata filtering per sicurezza
• [ ] Context compression
• [ ] Evaluation continua (RAGAS)
• [ ] Caching multi-livello
• [ ] Monitoring in produzione

Non fermatevi alla demo. Esigete metriche di valutazione prima di andare in produzione. E ricordate: un sistema RAG è buono quanto la qualità dei suoi dati. Investite tempo nella pulizia, strutturazione e arricchimento dei vostri documenti.

---

Vuoi implementare un sistema RAG enterprise-grade? Contattaci per una consulenza tecnica.