Le regole che avevo scritto non arrivavano al testo

Il sintomo, ventuno volte su trenta

Ho un'applicazione che ogni mattina genera un post e un editoriale a partire da una notizia verificata. Funziona da luglio. Il primo dubbio non è arrivato da un errore ma da una sensazione, quella di leggere sempre lo stesso pezzo. Le sensazioni sui testi generati sono notoriamente inaffidabili. Così ho contato.

Su trenta pezzi archiviati, ventuno aprivano il paragrafo di esperienza personale con la stessa costruzione, «Nei progetti con le PMI vedo spesso». Quattordici usavano la stessa mossa retorica subito dopo, «l'errore opposto» oppure «lo stesso schema in scala ridotta». Nove chiudevano con una lista di domande da fare al fornitore. Sette editoriali su trenta contenevano un'analogia storica con un'altra industria.

Il dato che ha cambiato la direzione dell'indagine è un altro. Il 2 agosto avevo riscritto le regole di stile, riducendo gli hashtag da un intervallo di quattro-sei a un massimo di tre. I post di agosto continuavano a uscire con cinque hashtag. Non era una questione di gusto del modello, era una regola che non arrivava a destinazione.

Dove finiva la regola

Le regole di scrittura vivono in un file del codice, lib/rules.js. L'applicazione le copia nelle impostazioni utente al primo avvio, così l'autore può modificarle dall'interfaccia senza toccare il codice. Fin qui è una scelta ragionevole.

Il difetto sta nel modo in cui le impostazioni vengono lette. La funzione che le restituisce fonde i valori di default con quelli salvati su disco. I salvati vincono. Detto in una riga, la copia scritta su disco a luglio schermava per sempre il file del codice. Ogni modifica alle regole che facevo nel repository era, dal punto di vista del programma in esecuzione, invisibile.

Nessun errore, nessun avviso, nessun comportamento anomalo. Il sistema funzionava esattamente come era scritto. È la categoria di guasto peggiore da trovare. Non c'è niente da cercare nei log e l'unico sintomo è un testo leggermente diverso da quello che ti aspettavi.

La prova che mi ha convinto è stata banale. Ho confrontato la stringa salvata su disco con quella del codice, riga per riga. Tre righe divergevano, ed erano esattamente le tre che avevo riscritto il 2 agosto.

Il costo non è stato il tempo di riparare, che è stato mezz'ora. Il costo sono le tre settimane in cui ho creduto di stare migliorando la qualità dei testi mentre modificavo un file che il programma non leggeva. In quelle settimane ho anche aggiunto due divieti nuovi, convinto che i precedenti non bastassero, quindi la diagnosi sbagliata ha prodotto lavoro sbagliato. È il danno tipico di un guasto silenzioso. Non l'interruzione del servizio ma le decisioni prese sulla base di un sistema che credi di conoscere.

L'autoverifica che non vede sé stessa

Il secondo guasto è più interessante e riguarda chi costruisce pipeline con i modelli.

Il prompt conteneva già una sezione di autoverifica finale, con l'istruzione di rileggere il testo e confrontare l'attacco con quelli dei pezzi precedenti, elencati poco sopra nello stesso prompt. Quella verifica è passata ventuno volte su trenta senza segnalare niente, mentre la ripetizione era sotto i suoi occhi.

La spiegazione che mi sono dato e che ho poi usato per costruire il rimedio sta in una frase. Una verifica dentro la stessa generazione non è una verifica. Il modello che ha appena scelto quella costruzione non ha nessun motivo per giudicarla ripetitiva, perché è la stessa distribuzione di probabilità che l'ha prodotta a doverla valutare. Chiedergli di controllarsi è come chiedere a qualcuno di rileggere una propria frase e dire se somiglia a come scrive di solito.

La conseguenza va oltre il mio caso. Chiunque metta un modello dentro una pipeline è tentato di chiudere il ciclo in un solo passaggio, perché costa la metà e sembra più elegante. Su qualunque proprietà che riguardi la forma del testo, la ripetizione, la lunghezza, il tono, quel ciclo chiuso non misura niente.

Il rimedio è stato spostare il controllo fuori. Una seconda chiamata separata, senza accesso al web, con davanti solo la bozza e lo scheletro dei pezzi precedenti. Un unico compito, trovare ciò che si ripete e riscriverlo. Alla prima esecuzione reale ha prodotto cinque interventi. Uno diceva che l'attacco ripeteva il movimento di due pezzi di due settimane prima. Nessuna autoverifica interna lo aveva mai notato.

Cosa ho cambiato e l'errore che ho fatto nel cambiarlo

La correzione delle regole fantasma è una versione. Il file del codice espone il testo e un numero, le impostazioni salvano quel numero, alla lettura la copia su disco viene riallineata se il numero è vecchio. Con un'eccezione necessaria, se l'autore ha modificato le regole a mano la sua versione resta, perché sovrascrivere il lavoro di chi usa il programma è un guasto peggiore di quello che sto risolvendo.

Poi ho sbagliato. Vale la pena raccontarlo perché è lo stesso tipo di errore del guasto originale. Nel definire i valori di default ho messo come numero di versione quello corrente. Risultato, la fusione fra default e valori salvati assegnava il numero nuovo anche alle impostazioni vecchie, che quindi risultavano già aggiornate. La correzione conteneva una copia esatta del difetto che doveva correggere.

L'ho scoperto perché ho provato la migrazione su una copia del file di impostazioni reale, invece di leggere il codice e convincermi che fosse giusto. Il valore di default corretto è zero, cioè un numero che nessuna impostazione salvata può avere.

Da qui è uscita la regola che mi porto dietro. Qualunque impostazione salvata da un programma è una copia. Una copia invecchia. Nel momento in cui la scrivi su disco hai creato due verità sullo stesso oggetto. Da quel momento la domanda «quale delle due sta vincendo» va resa verificabile, con un numero di versione, un confronto in avvio o un test che fallisce quando divergono. Se la domanda non ha una risposta automatica, prima o poi qualcuno passerà tre settimane a scrivere regole che nessuno legge.

Il controllo che avrebbe intercettato tutto costa una riga. Confrontare all'avvio il valore effettivamente in uso con quello dichiarato nel codice e lamentarsi se differiscono, senza che nessuno lo abbia chiesto. Non l'avevo scritto perché sembrava un controllo su una cosa che non può andare storta.