Perché la parte più importante di un’architettura Legal-AI è quella che quasi nessuno guarda
Se chiedi a un sistema costruito con RAG:
“E in quel caso cosa succede?”
Per te è chiarissimo. Per un sistema di retrieval, è caos. Ed è proprio qui che nasce l’errore più diffuso nella costruzione dei sistemi RAG: credere che il problema sia “quale modello usare”.
Non lo è, perchè il vero problema è molto più a monte.
Il punto che quasi tutti ignorano
Quando costruiamo un sistema Retrieval-Augmented Generation, tendiamo a pensare che il flusso sia questo:
1. L’utente fa una domanda
2. La trasformiamo in embedding
3. Interroghiamo il database vettoriale
4. Generiamo la risposta
Sembra corretto, elegante e lineare, ma nel mondo reale è insufficiente. Perché la domanda dell’utente non è pronta per essere cercata !.
Il problema nascosto delle domande umane
Partiamo da un punto molto importante, le domande reali sono:
- incomplete
- contestuali
- ambigue
- dipendenti dalla conversazione precedente
- cariche di impliciti
Esempio reale:
> “Quali sono i suoi requisiti?”
Requisiti di cosa !?
Di quale procedura?
In quale contesto?
Secondo quale norma?
Un embedding, anche di 3072 dimensioni, non può risolvere un’ambiguità strutturale, se l’input è semanticamente incompleto, anche il vettore sarà incompleto, ed è qui che entra in gioco il vero cuore dell’architettura.
Il passaggio che cambia tutto
L’architettura sviluppata introduce uno strato critico tra l’utente e Qdrant:
`Input ↓ Memoria Conversazionale ↓ Riscrittura ↓ Query Retrieval-Friendly ↓ Embedding + BM25 ↓ Hybrid Retrieval ↓ Risposta`
Quel passaggio intermedio è la differenza tra un RAG dimostrativo e un RAG enterprise.
1. Presa in input
La domanda entra nel sistema in forma grezza. Non viene immediatamente trasformata in embedding. Ma prima viene analizzata nel contesto della conversazione.
2. Riscrittura (Query Rewriting)
Il sistema recupera la memoria recente della chat e chiede al modello:
- Questa domanda è autonoma?
- Contiene pronomi?
- Fa riferimento a elementi precedenti?
- È generica o richiede retrieval?
Esempio:
Domanda utente:
> “E se non viene approvato?”
Domanda riscritta:
> “Cosa accade nella procedura se il piano non viene approvato dalla scuola?”
Ora sì che possiamo cercare.
3. Trasformazione in qualcosa di “retrieval-friendly”
Una query retrieval-friendly è:
- autonoma
- esplicita
- non ambigua
- coerente con il linguaggio documentale
- priva di pronomi
- semanticamente stabile
Questo passaggio è il vero cuore dell’architettura , perché solo ora la domanda è interrogabile in modo strutturato.
Perché questo è più importante del modello
Molti pensano che la qualità del sistema dipenda da:
- 1536 dimensioni vs 3072
In realtà, se la query è malformata, il problema è già avvenuto, perchè un grande modello non compensa una cattiva architettura.
Dense vs Sparse: due cervelli, non uno
Una volta che la query è corretta, entra in gioco il retrieval ibrido. Dense Retrieval (Embedding 3072)
Serve a:
- comprendere sinonimi
- collegare concetti giuridicamente vicini
- distinguere sfumature (annullabilità vs nullità)
- catturare intenzione semantica profonda
Ma non è sufficiente !!!!
Sparse Retrieval (BM25)
BM25 intercetta:
- numeri di articoli
- riferimenti normativi precisi
- nomi di procedure
- termini tecnici esatti
Nel diritto, perdere un numero di articolo significa perdere precisione, solo semantica non basta.
La fusione: 70% semantico, 30% lessicale
L’architettura esegue due ricerche in parallelo:
Poi normalizza i punteggi e applica una fusione pesata:
`score = 0.7 * semantic + 0.3 * lexical`
Questo evita:
- eccesso di sinonimia
- perdita di precisione normativa
- ranking instabile
Il risultato è un contesto pulito, coerente, giuridicamente ancorato.
# Riduzione delle allucinazioni
Le allucinazioni non nascono dal nullama nascono quando:
- il contesto è rumoroso
- il ranking è impreciso
- la query è ambigua
- il retrieval è fragile
Pulendo la query prima della ricerca, si pulisce l’intero sistema. La qualità della risposta è una conseguenza architetturale, non un effetto magico del modello.
Errori comuni nei sistemi RAG
Dopo molti test comparativi, questi sono gli errori più frequenti:
1. Nessuna riscrittura contestuale
2. Embedding diretto della domanda grezza
3. Nessuna gestione della memoria
4. Solo retrieval semantico
5. Nessuna normalizzazione punteggi
6. Fusione arbitraria non calibrata
7. Confondere prompt engineering con architettura
Il vero errore è pensare che il retrieval sia una funzione tecnica, non una fase cognitiva.
Benchmark comparativo sintetico
La differenza non è solo tecnica. È strutturale.
Perché questo è “enterprise-ready”
In alcuni ambiti, non basta rispondere, ma serve:
- coerenza normativa
- auditabilità
- riduzione del rischio interpretativo
- stabilità nel tempo
- replicabilità
Un’architettura senza rewriting non è scalabile in ambienti professionali complessi.
La vera lezione
Il modello generativo non è il centro del sistema.
Il centro è il passaggio tra umano e retrieval.
> Presa in input
> Riscrittura
> Trasformazione retrieval-friendly
> Interrogazione Qdrant
Se questo passaggio è solido, il sistema è stabile, se questo passaggio è debole, nessun LLM potrà salvarlo.
Conclusione
La vera innovazione nei sistemi Legal-RAG non è l’LLM. È l’architettura.
È la disciplina nel trattare la domanda umana non come testo, ma come struttura da ricostruire prima di cercare, ed è lì che si decide la qualità del sistema.
