IA e Avvocati (11): come verificare l’accuratezza delle risposte
Intelligenza artificiale e Avvocati
11. Verificare la precisione dell’IA legale: strategie di testing e debug per sistemi RAG locali
Introduzione
Allucinazioni, bias, omissioni… Nel percorso di adozione dell’Intelligenza Artificiale generativa negli studi legali italiani, uno degli aspetti più delicati è garantire l’affidabilità delle risposte generate dai modelli linguistici.
Glossario di base:
- LLM (Large Language Model): modello linguistico di grandi dimensioni addestrato su enormi quantità di testo per generare o comprendere linguaggio naturale.
- RAG (Retrieval-Augmented Generation): tecnica che combina un motore di recupero documenti con un LLM per generare risposte basate su contenuti specifici.
- Prompt: testo di input fornito a un LLM per ottenere una risposta.
- Embedding: rappresentazione numerica di un testo che permette di confrontare la somiglianza semantica tra frasi o documenti.
- FAISS: libreria sviluppata da Facebook per creare e interrogare indici vettoriali ad alta velocità, utilizzata per il recupero di documenti.
- LangChain: framework Python per costruire applicazioni AI con modelli linguistici e catene di elaborazione.
- Allucinazioni (Hallucinations): errore tipico degli LLM che consiste nella generazione di informazioni non supportate dai dati di origine.
- Chunking: tecnica di suddivisione del testo in segmenti più piccoli per facilitarne l’indicizzazione e il recupero.
- Context window: limite di memoria del modello linguistico, ovvero quanta informazione può tenere a mente in una sola richiesta.
Questo post, undicesimo della serie, affronta il tema del testing e del debug di un sistema RAG (Retrieval-Augmented Generation) installato in locale su ambiente Windows.
L’obiettivo è aiutare gli studi legali a costruire un processo robusto di verifica, utilizzando strumenti open source e metodologie replicabili su casi reali.
Perché testare un sistema RAG
Un sistema RAG, anche se locale e alimentato da dati propri, può produrre errori di vario tipo: per esempio risposte incomplete, allucinazioni, omissioni o bias.
Per uno studio legale, questi errori possono tradursi in conseguenze rilevanti sul piano professionale e deontologico.
Testare e migliorare le prestazioni del sistema è quindi una fase essenziale prima di introdurlo nel flusso di lavoro quotidiano.
Costruzione di un dataset di test
Per testare l’accuratezza di un sistema RAG, è utile costruire un dataset composto da:
- Documenti PDF legali già processati (testo pulito);
- Domande generate manualmente o automaticamente a partire dai documenti;
- Risposte attese (ground truth), redatte da un professionista.
Il dataset può essere conservato in un file JSON o CSV, con tre colonne: domanda, risposta attesa, contesto documentale.
Strumenti consigliati
RAGAS
RAGAS (Retrieval-Augmented Generation Assessment Suite) è una libreria Python progettata per valutare le prestazioni di un sistema RAG.
Fornisce metriche come “faithfulness”, “answer relevancy”, “context recall” e “context precision”.
Installazione:
pip install ragas
⚠️ Nota sulla riservatezza – Ragas
Ragas elabora i dati localmente e non trasmette prompt, risposte o documenti online, salvo che tu non configuri servizi cloud esterni. Il software raccoglie solo statistiche d’uso anonime, disattivabili impostando RAGAS_DO_NOT_TRACK=true.
LangSmith
LangSmith è uno strumento avanzato di LangChain che consente il tracciamento e l’ispezione delle catene di prompt.
Utile per il debug delle chiamate tra retriever, LLM e formattatori di risposta.
Installazione:
pip install langsmith
⚠️ Nota sulla riservatezza – LangSmith
LangSmith è uno strumento potente per il tracciamento delle pipeline, ma la versione cloud prevede la trasmissione dei dati verso server esterni gestiti da LangChain, anche fuori dall’Italia. Questo comporta che prompt, risposte generate e, in alcuni casi, anche il contesto documentale vengano inviati online per essere visualizzati e analizzati nella dashboard. Per queste ragioni, LangSmith cloud è indicato solo in fase di sviluppo o test e non è adatto all’uso su dati legali reali, salvo specifiche garanzie contrattuali e valutazioni di impatto privacy.
Tipi di errori da monitorare: allucinazioni, omissioni, bias, errori di retrieval
Durante l’utilizzo di un sistema RAG, è fondamentale saper riconoscere e classificare gli errori più comuni.
Questi errori possono compromettere la qualità delle risposte fornite e, di conseguenza, la fiducia nell’intero sistema.
Ecco una panoramica dettagliata:
- Allucinazioni (Hallucinations) – Le allucinazioni si verificano quando il modello genera informazioni non supportate da alcun contenuto presente nei documenti di origine. Ad esempio, le allucinazioni possono attribuire una norma inesistente a una determinata legge, citare articoli di codice non coerenti con la giurisdizione italiana, oppure menzionare sentenze che non esistono. Gli errori dovuti alle allucinazioni sono tra i più pericolosi, in quanto possono indurre l’Avvocato a conclusioni erronee. Le cause delle allucinazioni possono risiedere in prompt poco precisi, nella mancanza di contesto sufficiente o in LLM non ottimizzati per l’ambito legale.
- Incompletezza – La risposta fornita è solo parziale rispetto alla domanda. Questo accade spesso quando il contesto fornito al modello non è sufficientemente ricco oppure quando la segmentazione (chunking) del documento originale è troppo aggressiva, escludendo parti rilevanti. In altri casi, può derivare da un limite del context window del modello o da un retrieval inefficace. È importante monitorare anche l’aderenza sintattica e semantica della risposta alla domanda originale.
- Bias – I modelli linguistici possono riflettere pregiudizi culturali, sociali o ideologici presenti nei dati di addestramento. Sebbene l’utilizzo di modelli open source permetta un certo grado di controllo, è comunque importante monitorare la neutralità delle risposte, specialmente in ambito giuridico dove l’imparzialità è cruciale. Bias possono emergere ad esempio in risposte relative a temi sensibili come immigrazione, genere, minoranze, reati sessuali o religione. Una buona prassi è effettuare audit periodici su dataset specifici.
- Errori di retrieval – Riguardano la fase in cui vengono selezionati i documenti da passare al modello per generare la risposta. Un retriever inefficace può scegliere fonti irrilevanti o marginali, influenzando negativamente la qualità dell’output finale. Questo può essere dovuto a una scelta subottimale della tecnica di embedding, a un’errata configurazione del motore FAISS o a una segmentazione poco funzionale. È utile valutare metriche di precisione/recall e verificare la qualità dei top-k documenti selezionati per ogni query.
Per ridurre al minimo tali errori è importante:
- Ottimizzare i prompt, specificando meglio il tipo di risposta desiderata (es. citazione normativa, sintesi, comparazione);
- Curare il pre-processing dei documenti (pulizia del testo, normalizzazione, segmentazione coerente);
- Aggiornare periodicamente gli indici FAISS e verificare l’efficacia degli embedding con set di validazione;
- Scegliere LLM adeguati al dominio legale e, se possibile, affinarli (fine-tuning) su dati giuridici specifici dello studio;
- Mantenere aggiornati i dataset normativi e giurisprudenziali utilizzati, per evitare che il sistema operi su testi superati o abrogati.
Inoltre, è raccomandabile:
- Effettuare un logging sistematico degli errori, associando ogni richiesta a un ID univoco e creando un archivio utile sia per il debug che per la formazione interna;
- Rafforzare la supervisione umana in tutte le fasi di test, validazione e utilizzo operativo: l’IA deve essere considerata uno strumento di supporto e non sostitutivo del giudizio dell’Avvocato, il quale mantiene sempre la responsabilità legale e deontologica finale.
Procedura consigliata per ambiente Windows
Si rimanda al post 6 per la configurazione dell’ambiente Windows.
Ricordiamo:
- Setup ambiente: Windows 10 o superiore, Python ≥ 3.10, Ollama installato con modello compatibile (es. Mistral), FAISS attivo;
- Test iniziali manuali: inserimento di domande via script Python e analisi delle risposte;
- Valutazione automatica con RAGAS;
- Debug delle pipeline con LangSmith;
- Verifica umana finale su un sottoinsieme di risposte generate.
Best practice per studi legali
- Archiviare ogni risposta generata con il relativo riferimento documentale;
- Documentare sistematicamente gli errori riscontrati e le soluzioni adottate;
- Applicare versionamento sia al codice che ai dataset di test;
- Prevedere sempre la revisione umana delle risposte in caso di utilizzo operativo.
Context-Aware Generation (CAG)
Un aspetto cruciale nella valutazione della qualità delle risposte generate da un sistema RAG è il grado di consapevolezza del contesto, noto come Context-Aware Generation (CAG).
Si tratta della capacità del modello linguistico di produrre risposte non solo grammaticalmente corrette, ma anche profondamente ancorate alle informazioni fornite nei documenti di riferimento.
Cos’è il CAG
Nel contesto dell’IA generativa applicata al diritto, il CAG implica che il modello linguistico utilizzato consideri:
- il significato specifico dei termini nel contesto giuridico (es. “revoca”, “termine decadenziale”);
- la coerenza tra la risposta e la giurisdizione o ambito normativo richiesto;
- i dettagli del caso o del documento fornito (es. se il documento è una sentenza o un parere).
Perché è importante
Una generazione sensibile al contesto è essenziale per:
- evitare generalizzazioni dannose in ambito giuridico;
- prevenire allucinazioni dovute a interpretazioni errate del contesto;
- migliorare la rilevanza e precisione delle risposte, specialmente nei casi in cui il sistema deve distinguere tra norme simili applicabili in ambiti differenti.
Come valutarla
Strumenti come RAGAS permettono di misurare il “context recall” e la “context precision”, che indicano in che misura il contesto recuperato è stato utilizzato in modo corretto.
È inoltre possibile confrontare la risposta con il testo di origine per verificare l’aderenza semantica.
Implicazioni operative
Per ottenere un buon livello di CAG è consigliabile:
- Segmentare correttamente i documenti (chunking semantico, non solo strutturale);
- Sviluppare prompt che guidino il modello a fare riferimento esplicito al contesto;
- Monitorare i casi in cui la risposta omette, distorce o esagera parti del contesto.
Il CAG rappresenta un criterio avanzato ma sempre più essenziale per garantire che le risposte generate da un sistema RAG siano utilizzabili in un ambiente legale professionale, dove ogni parola può avere valore vincolante.
Conclusione
Testing e debug sono fasi imprescindibili per chi desidera integrare l’intelligenza artificiale nel proprio studio legale.
L’implementazione locale garantisce sicurezza e riservatezza, ma è essenziale verificarne l’accuratezza, correggere gli errori sistemici e costruire fiducia nei risultati.
L’adozione di strumenti come RAGAS rende questo processo più accessibile anche per professionisti senza competenze tecniche avanzate.
Nel prossimo post vedremo come estendere il semplice sistema RAG sperimentale che abbiamo creato.
Per un aiuto e per approfondire
Per un aiuto e per approfondire i temi dell’intelligenza artificiale nello studio legale, del legal tech e del legal design è online il GPT Iusreporter.tech (link esterno, richiede ChatGPT)
Per gli altri articoli pubblicati su questo blog sul tema:
Intelligenza artificiale e Avvocati
Scritto con l’aiuto di Iusreporter, il tuo assistente per la ricerca giuridica online
Studio legale Avvocato Giuseppe Briganti
Pesaro – Urbino
Post aggiornato alla data di pubblicazione
📄 Disclaimer
Gli script Python e i contenuti di questo testo sono forniti esclusivamente a scopo informativo, didattico e sperimentale in ambienti di test controllati. Non costituiscono consulenza legale o tecnica e non sostituiscono il parere di un professionista qualificato.
L’autore declina ogni responsabilità per eventuali errori, omissioni, malfunzionamenti, danni diretti o indiretti, incidentali, consequenziali o di altro tipo derivanti dall’uso, dall’uso improprio o dall’impossibilità di utilizzo degli script o delle informazioni contenute nel presente testo. Gli script sono forniti “così come sono” (AS IS), senza garanzie esplicite o implicite, incluse, ma non limitate a, garanzie di commerciabilità, idoneità a uno scopo particolare o assenza di violazioni.
L’utilizzo degli strumenti è sotto la piena responsabilità dell’utente, che è tenuto a verificarne, in particolare:
- la correttezza tecnica e funzionale,
- la conformità alle normative vigenti, incluse, a titolo esemplificativo, l’AI Act, il GDPR, il Codice Deontologico Forense,
- il rispetto delle licenze delle librerie e dei componenti e software di terze parti eventualmente utilizzati, inclusi quelli distribuiti con licenze open source.
Gli script non sono progettati né validati per l’uso in ambienti produttivi o per l’elaborazione di dati personali. Qualsiasi utilizzo in tali contesti è esclusiva responsabilità dell’utente, che deve adottare le opportune misure di sicurezza e valutare l’impatto normativo.
Gli script sono stati testati su Python 3.10 in ambiente Windows. Non è garantita la compatibilità con versioni diverse del linguaggio o con altri sistemi operativi. L’autore non fornisce assistenza tecnica, aggiornamenti periodici o correzione dei malfunzionamenti.
Tutti i contenuti di questo ebook, inclusi i testi e il codice sorgente, sono protetti dal diritto d’autore ai sensi della Legge 22 aprile 1941, n. 633 e successive modificazioni. È vietata la riproduzione, distribuzione, pubblicazione, comunicazione o modifica, totale o parziale, in qualsiasi forma, dei contenuti senza autorizzazione scritta dell’autore, salvo espressa indicazione contraria.
L’uso di questo testo e degli script in esso contenuti implica l’accettazione integrale del presente disclaimer. Se non si accettano tali condizioni, si prega di non utilizzare il materiale fornito.
Eventuali errori, osservazioni o segnalazioni possono essere comunicati all’autore, che si riserva di valutarli senza alcun obbligo di risposta o correzione.