Come funziona Legger

Un modello linguistico di grandi dimensioni (in inglese large language model, LLM) è un programma statistico addestrato su enormi quantità di testo, che impara a continuare un testo nel modo più plausibile. Produce prosa fluente e spesso corretta, ma mentre risponde non consulta alcuna fonte: attinge a regolarità apprese durante l’addestramento. Quando quelle regolarità non bastano, il modello può produrre una allucinazione: un’affermazione perfettamente plausibile nella forma e falsa nella sostanza.

Nel diritto questo difetto è particolarmente grave, per tre ragioni. Primo, le citazioni inventate: un modello generico può citare con sicurezza un numero di articolo sbagliato o un atto che non esiste, e una citazione errata rende inutile — o dannosa — l’intera risposta. Secondo, la vigenza: le norme cambiano di continuo, e ciò che il modello ha visto in addestramento può essere stato nel frattempo abrogato o riscritto (una norma è vigente quando è attualmente in vigore, abrogata quando è stata eliminata dall’ordinamento). Terzo, l’autorevolezza apparente: il tono sicuro del modello non distingue ciò che sa da ciò che inventa.

Legger inverte il ruolo del modello: non gli chiede di sapere la legge, gli chiede di leggerla. L’architettura si chiama retrieval-augmented generation(«generazione aumentata dal recupero»): prima si recuperano dall’archivio i testi normativi pertinenti, poi si genera la risposta vincolandola a quei soli testi. Le sezioni che seguono percorrono la catena, anello per anello.

La fonte primaria è Normattiva, la banca dati pubblica ufficiale della normativa statale italiana. Legger non la interroga direttamente: si appoggia a italia-corpus, un progetto pubblico che converte gli atti di Normattiva in semplici file di testo — un file per atto — organizzati in 23 raccolte per tipo (codici, decreti legislativi, testi unici, regi decreti…). Le raccolte degli atti abrogati e dei decreti-legge decaduti sono separate dalle altre: da questa struttura Legger deriva lo stato di vigenza di ciascun atto. Dopo l’eliminazione dei duplicati, l’archivio indicizzato conta 181.870 atti.

Il corpus è mantenuto con git, uno strumento nato per lo sviluppo software che funziona come un registro storico delle modifiche: ogni cambiamento è registrato come un «commit», una fotografia datata di che cosa è cambiato, in quali file e quando. Quando Normattiva consolida una modifica normativa, il corpus riceve un commit; Legger scarica quotidianamente le novità e ri-indicizza soltanto i file toccati, non l’intero archivio. Lo stesso registro renderà possibile, in roadmap, rispondere a domande come «com’era questo articolo al 15 marzo 2024?».

Un motore di ricerca semantico non lavora su interi codici (il solo codice civile conta migliaia di articoli): i testi vanno prima divisi in chunk, porzioni autosufficienti da indicizzare e recuperare singolarmente. La scelta dell’unità di taglio è la decisione più importante dell’intero sistema, e per Legger l’unità è l’articolo: mai tagli a lunghezza fissa che spezzano un comma (il capoverso numerato che compone un articolo) a metà. Gli articoli molto lunghi — come gli articoli unici delle leggi di bilancio, con centinaia di commi — vengono divisi per gruppi di commi, con una piccola sovrapposizione tra un gruppo e il successivo per non perdere il filo.

Un frammento isolato, però, non dice da dove viene: «Ciascuno è responsabile del danno cagionato dalle cose che ha in custodia…» non rivela né l’atto né l’articolo. Per questo ogni chunk è prefissato da un’intestazione contestuale che ne dichiara la provenienza, ad esempio:

Codice 262/1942 — Approvazione del testo del Codice civile
Art. 2051 — Danno cagionato da cosa in custodia
Ciascuno è responsabile del danno cagionato dalle cose che ha in custodia, salvo che provi il caso fortuito.

L’intestazione viaggia insieme al testo anche nella fase di indicizzazione, e migliora sensibilmente la ricerca: la domanda «danno da cosa in custodia» trova l’articolo anche quando il corpo del testo usa parole diverse. Applicato all’intero archivio, il processo produce 966.822 chunk, pari a circa 524 milioni di token(il token è l’unità con cui i modelli misurano il testo: all’incirca una parola breve o un pezzo di parola; in questo corpus, in media 2,26 caratteri per token).

Quando l’utente pone una domanda, il sistema la cerca nell’archivio per due strade complementari, perché le domande legali sono di due nature radicalmente diverse.

La prima strada è semantica. Un modello di embedding trasforma ogni testo in un vettore semantico: un punto in uno spazio matematico a migliaia di dimensioni, costruito in modo che testi con significato simile finiscano vicini. L’analogia più fedele è una mappa sterminata in cui ogni frammento di legge è uno spillo, e gli spilli sono raggruppati per argomento anziché in ordine alfabetico: la domanda dell’utente diventa a sua volta uno spillo sulla mappa, e il sistema raccoglie i frammenti più vicini. È così che «il cane del vicino mi ha morso, chi mi paga i danni?» trova l’art. 2052 del codice civile (danno cagionato da animali) pur non condividendo con esso quasi nessuna parola.

La seconda strada è lessicale: l’algoritmo BM25, un classico dei motori di ricerca, conta le parole esattamente in comune tra domanda e documento, dando più peso ai termini rari. È indispensabile per le query come «art. 613-bis c.p.», dove contano i caratteri esatti e non il significato. Le due classifiche vengono poi fuse con la Reciprocal Rank Fusion (RRF), una regola che premia i documenti ben posizionati in entrambe le liste: un chunk in alto sia per somiglianza di significato sia per parole in comune vince su uno forte in una sola delle due.

Sopra le due strade c’è una corsia preferenziale, il fast path: se la domanda contiene estremi normativi espliciti e riconoscibili («art. 2051 c.c.», «d.lgs. 81/2008»), un riconoscitore di pattern li estrae e recupera direttamente l’articolo dall’archivio, senza passare dal calcolo di somiglianza: una citazione esatta batte qualunque punteggio, e i risultati così ottenuti vanno in testa al contesto. Completano la pipeline la riscrittura della domanda alla luce della conversazione (così «e il comma successivo?» diventa una domanda autonoma) e l’inseguimento dei rinvii: se i passaggi recuperati richiamano espressamente altre norme («ai sensi dell’articolo…»), anche gli articoli richiamati vengono aggiunti al contesto, entro un budget massimo di testo.

I passaggi recuperati — di norma una decina — vengono consegnati al modello linguistico insieme a un prompt di sistema: le istruzioni permanenti che definiscono che cosa il modello può e non può fare. Le regole sono poche e senza eccezioni: rispondere solosulla base dei passaggi forniti («se un’informazione non è nei passaggi, non la conosci»); ogni affermazione normativa deve citare la fonte con un marker, un’etichetta leggibile dalla macchina nel formato [[codice-civile|art.2051]]; se il contesto non basta, dichiararlo e suggerire come riformulare la domanda — una risposta mancata è accettabile, una citazione inventata no; se un passaggio segnala che un articolo è stato abrogato, riferirlo fedelmente, senza mai ricostruire il testo previgente.

Le regole, da sole, sono promesse. Per questo a valle della generazione opera un guardrail, un controllo automatico: mentre la risposta viene trasmessa, ogni marker emesso è confrontato con l’insieme dei passaggi consegnati al modello. Se l’atto o l’articolo citato non era nel contesto, la citazione viene marcata «non verificata» e mostrata in ambra nell’interfaccia.

Un’avvertenza di onestà semantica: «verificata» ha qui un significato preciso e limitato. Vuol dire che la citazione punta a un testo che il sistema ha davvero recuperato e mostrato al modello — cioè che il modello non sta citando a memoria. Non vuol dire che la citazione sia giuridicamente corretta o pertinente al caso: quel giudizio resta al lettore, ed è per questo che la fonte è sempre a un click di distanza.

Tre scelte di interfaccia rendono il sistema ispezionabile. In calce a ogni risposta compare l’elenco delle fonti consultate: tutti i passaggi consegnati al modello, compresi quelli che la risposta non cita — ciò che il modello ha letto, non solo ciò che ha usato. Ogni citazione porta un badge di vigenza: verde per le norme vigenti, grigio per le abrogate, ambra per le citazioni non verificate dal guardrail. E ogni citazione apre la split-view: un pannello affiancato alla chat con il testo integrale dell’atto, fatto scorrere fino all’articolo citato e con i commi rilevanti evidenziati, più il collegamento alla pagina ufficiale su Normattiva. L’interfaccia è disegnata perché verificare sia più facile che fidarsi.

Un sistema onesto dichiara dove finisce. Questi sono i limiti attuali di Legger.

La vigenza ha la granularità dell’atto.Lo stato vigente/abrogato deriva dalla raccolta in cui l’atto è archiviato e vale per l’atto intero. Un singolo articolo abrogato dentro un codice vigente — per esempio l’art. 594 del codice penale (ingiuria), abrogato nel 2016 — è riconoscibile solo dalla nota di abrogazione presente nel testo consolidato, che il sistema riporta fedelmente; il badge dell’atto, però, resta «vigente».

Solo normativa statale. Niente giurisprudenza (le sentenze dei tribunali), normativa regionale, circolari o prassi amministrativa: sono in roadmap, fuori dal perimetro attuale.

La storia parte dal 2025. Il registro git del corpus inizia con la nascita del progetto italia-corpus: per le versioni anteriori di una norma fa fede Normattiva.

L’intelligenza artificiale può sbagliare. Il guardrail elimina le citazioni a memoria, ma non ogni possibile errore di lettura o di sintesi del modello. Il disclaimer in fondo a ogni pagina — strumento informativo, non costituisce consulenza legale; fa fede la Gazzetta Ufficiale — non è una formula di stile: descrive esattamente il perimetro entro cui il sistema è stato progettato e validato.