Lo strumento che rimuove gli errori di un LLM nasce da una scoperta inaspettata. Costruendo TeoCentro ho fatto la cosa ovvia: ripulire le fonti dal rumore (ho tenuto i testi primari nelle lingue originali e scartato le parafrasi delle parafrasi). Eppure alle domande difficili il modello restituiva ancora un passo del tutto inventato: struttura plausibile, tono autorevole, sbagliato in ogni dettaglio verificabile. Non per colpa del corpus — quello era pulito — ma per i suoi schemi impliciti. La compiacenza che il primo articolo ha chiamato per nome non si cura ripulendo i dati: abita il modello, non le fonti.
L'articolo precedente indicava la via d'uscita: non potendo toccare lo stendardo del ROI — l'incentivo a compiacere, sepolto nella blackbox — si devono quindi passargli a monte i dati che gli mancano, prima che generi, così che il suo calcolo di convenienza si ribalti a favore della verità. Ecco come funziona precorrect.
Cosa significa «distorcere»: il giogo
Un esempio rende tangibile la deriva — e perché un corpus pulito non basta. «Prendete il mio giogo su di voi» (Matteo 11,29). Nella tradizione cristiana occidentale, da Agostino a Calvino, «giogo» è letto in chiave metaforico-spirituale: il giogo lieve e soave della grazia, contrapposto a quello gravoso della legge. È la lettura più diffusa — e quindi quella che un modello generalista serve di default, anche con la fonte giusta davanti. Ma nel giudaismo del Secondo Tempio, il contesto storico reale del testo, «giogo» (עֹל, ol) era un termine tecnico-giuridico: l'autorità con cui un maestro interpreta la Torah («il giogo della Torah», «il giogo del Regno dei cieli»). La Mishnah lo dice apertamente: recitare lo Shema è «ricevere il giogo del Regno dei cieli» (Berakhot 2,2). «Prendete il mio giogo» era allora ed è ancora oggi una dichiarazione precisa di autorità legale (halakhica), non un'immagine liberale — e questo cambia la lettura dell'intero Discorso della Montagna e la sua applicabilità pragmatica. È esattamente questa la deriva — la versione comoda al posto di quella esatta — che precorrect è fatto per intercettare.
Il meccanismo: a monte, solo dove serve
Quasi tutti i sistemi tolgono il bias dopo: generano, poi correggono. precorrect lo fa prima, in tre mosse.
Sonda prima di generare. Sui testi recuperati per un certo tema, il sistema interroga il modello con domande mirate per scoprire verso quale distorsione scivolerebbe — quale lettura accettabile-ma-falsa sceglierebbe su quello specifico tema — prima che la scriva.
Interviene solo dove sbaglia con sicurezza. Il primo articolo mostrava come leggere la convinzione del modello dalla varianza delle risposte ripetute: bassa varianza e sbagliato = bias radicato, il modello è sicuro di compiacere e sbaglia. È lì che precorrect agisce, e salta dove il modello è già giusto. Correggere solo il quadrante pericoloso riduce gli interventi di circa tre quarti rispetto a una correzione a tappeto, a parità di qualità.
Inietta la correzione nel prompt. Il fatto giusto, preso dalle fonti, entra prima del primo token, restringendo la finestra in cui la distorsione verrebbe inserita, invece di doverla rimuovere dopo.
Concretamente, sul giogo: la sonda chiede al modello cosa intenda Matteo con «giogo» e lo coglie scivolare verso «grazia leggera» — il quadrante sicuro-ma-sbagliato. Allora, prima della generazione, gli inietta nel prompt la correzione presa dalla fonte — «giogo» = autorità halakhica sulla Torah, Berakhot 2,2 — e l'output esce con la lettura esatta invece di quella comoda. Dove invece il modello è già corretto, la sonda non trova nulla e non si tocca niente.
Perché a monte, e non dopo
Verificare la citazione dopo non basta: puoi avere la fonte giusta e l'inquadramento distorto — la citazione è corretta, il senso no. E, come si è visto, anche con un corpus ripulito il modello reintroduce la distorsione dai suoi schemi. Per questo la correzione è uno strato applicato al momento della generazione, non qualcosa inciso nei pesi del modello. Il sapere di dominio vive nei dati — le fonti selezionate e gli schemi di distorsione — non congelato in un modello dedicato: niente ri-addestramento mirato (fine-tuning), niente schede grafiche da mantenere. E quando esce un modello migliore, lo sostituisci e lo strato continua a valere. Un modello più potente, del resto, non basterebbe: sui fatti verificabili anche quelli di frontiera sbagliano con la stessa sicurezza — la capacità muove il tasso d'errore, non il radicamento.
La chiave-di-risposta: il metro che ti costruisci
Ma correggere presuppone un metro: come fa il sistema a sapere qual è la lettura giusta? Da un'unica risorsa, distillata dalle tue fonti: la chiave-di-risposta, lo standard di ciò che è vero, con fonti solide a sostegno (per la teologia, la lettura verificabile sull'ebraico e sul greco riga per riga). Non la scrivi a mano: la costruisce un motore di scoperta, che sonda le fonti una volta su tutto il corpus e poi la affina di continuo. È la stessa chiave a fare due lavori distinti.
Il correttore — il meccanismo qui sopra — vi attinge per prevenire: prende il fatto giusto e lo inietta a monte, dove ha calcolato che il modello sta per derivare, così l'errore non viene proprio scritto. E inietta il fatto preciso, non un cumulo di fonti: aggiungerne non aiuta — anzi diluisce il segnale. Conta colpire mirato, non di più.
Il verificatore vi attinge per giudicare: data una risposta, controlla coi suoi metodi se corrisponde alla chiave distillata dal corpus. Serve perché non puoi lasciare che sia il modello a giudicarsi: condivide i propri punti ciechi e, messo a valutare se stesso, ratifica gli errori sicuri invece di scovarli. Per questo il verificatore va ancorato alla fonte reale — non alla memoria del modello — e affidato a più giudici indipendenti: un solo modello-giudice porta con sé gli stessi angoli ciechi. È la soluzione alla crisi della valutazione di cui parla Karpathy: il suo «LLM Council» (più modelli di frontiera che si giudicano a vicenda) c'è caduto in pieno. La sua tesi della Verificabilità lo riassume: fidati di una valutazione automatica solo dove esiste un verificatore di verità di base.
E c'è una seconda mossa, quando la prevenzione non basta. Spesso il modello la verità la conosce già — la riconosce se gliela metti davanti — ma il suo schema gli impedisce di ammetterla: chiedergli «è corretto?» lo riporta alla risposta gradita. Allora non glielo chiedi: gli fai riscrivere il passo includendo il fatto verificato, e il verificatore controlla l'output contro la fonte. Ammettere-di-aver-sbagliato è bloccato; produrre-il-testo-giusto no — curi l'output, non la convinzione. E il verificatore, così ancorato, vale come strumento a sé: la stessa guardia serve ovunque un modello asserisca un fatto, prima e dopo.
La chiave la costruisci tu: precorrect parte da una generale e ti lascia farne una sulle tue fonti. È lei a ribaltare il calcolo del modello — non più «qual è la risposta gradita» ma «qual è quella che corrisponde alla chiave». E non lo fanno i trucchi di prompt: «rifletti», «verifica» spostano poco — è il dato ancorato a ribaltare la risposta. Un puntatore non è un grounding. Il meccanismo è generico e chiunque può copiarlo; la chiave è la tua, ed è quella — non il codice — a fare la differenza.
Lo strumento, e la prova
Ho estratto tutto questo — correttore e verificatore — in un piccolo strumento open source: precorrect su GitHub, pip install e un esempio da 30 secondi. Quasi tutti tolgono il bias dopo; questo lo fa prima.
Tenendo tutto fermo e scambiando solo lo standard di verità a cui il modello risponde, la stessa domanda che prima sbagliava ora la azzecca — lo stesso motore generico ha ritrovato ciò che il motore interno verticale, costruito a mano per la teologia, aveva già trovato (a riprova della conoscenza celata del LLM). Quanto netto sia quel ribaltamento — l'esperimento, i numeri — è l'ultimo articolo della serie.
La serie sulla verità nell'AI: 1. Il problema · 2. Il tool (questo) · 3. La prova (in arrivo).