Scrivere una buona istruzione a un modello è utile a una persona. Progettare le istruzioni di un sistema è ciò che rende il risultato ripetibile.
La differenza è la stessa che passa tra saper scrivere una query e progettare uno schema di database. La prima è un’abilità personale che migliora il lavoro di chi la possiede. La seconda è un componente dell’architettura, con requisiti di versionamento, test e manutenzione.
Molte organizzazioni hanno investito nella prima e trascurato la seconda. Il risultato è che le persone lavorano meglio individualmente, mentre i sistemi in produzione restano fragili.
La differenza tra uso individuale e sistema
Nell’uso individuale l’istruzione è effimera. Se la risposta non soddisfa, si riformula. Il ciclo di correzione è immediato, il costo di un errore è nullo, l’unico giudice è chi ha posto la domanda.
In un sistema le condizioni si invertono.
L’istruzione è fissa e viene applicata a migliaia di richieste diverse, molte delle quali chi l’ha scritta non ha previsto.
Chi riceve la risposta non ha visto l’istruzione e non può correggerla.
Un errore non è un caso isolato: è un comportamento sistematico che si ripete finché non viene rilevato.
E il comportamento va documentato, perché in un contesto regolato le istruzioni che governano un sistema fanno parte della sua descrizione tecnica.
Da qui discendono tre requisiti che nell’uso individuale non esistono: versionamento, test, gestione delle regressioni.
Perché una modifica senza test può peggiorare mille risposte
È il rischio specifico di questo componente e non è intuitivo.
Le istruzioni di un sistema sono interdipendenti. Aggiungere una regola per gestire un caso problematico modifica il comportamento anche su casi che funzionavano.
Un esempio ricorrente. Il sistema risponde in modo troppo sintetico su alcune domande complesse. Si aggiunge un’istruzione che richiede risposte più articolate. L’effetto collaterale è che il sistema diventa verboso sulle domande semplici e, soprattutto, tende a estendere l’inferenza oltre ciò che i documenti affermano, perché deve riempire uno spazio più ampio.
La correzione ha risolto un caso su cento e peggiorato la qualità sugli altri novantanove. Senza un insieme di prova, l’effetto viene rilevato settimane dopo, attraverso segnalazioni sparse difficili da ricondurre alla modifica.
Questo comportamento è la ragione per cui la modifica delle istruzioni di un sistema in produzione va trattata come una modifica al software: proposta, testata, approvata, versionata, rilasciata. Non come una regolazione da applicare direttamente.
Come si struttura una libreria di istruzioni governata
Cinque elementi.
Separazione per livelli. Le istruzioni di un sistema non sono un blocco unico. Ci sono le regole di comportamento generale, valide per tutto il sistema: come citare le fonti, quando astenersi, quale registro adottare. Ci sono le istruzioni specifiche per compito: classificare un documento, redigere una sintesi, estrarre campi. E ci sono le istruzioni dipendenti dal contesto d’uso.
Separarle consente di modificarne una senza toccare le altre, e di riutilizzare le regole generali su più sistemi.
Versionamento. Ogni istruzione ha una versione, una data, un autore e una motivazione della modifica. È indispensabile per stabilire se un errore rilevato oggi riguardi anche output prodotti in passato.
Insieme di prova associato. A ogni istruzione corrisponde un insieme di casi con l’esito atteso. La modifica si valida eseguendo l’insieme completo, non i casi che hanno motivato la modifica.
Percorso di approvazione. Chi può proporre una modifica, chi la verifica, chi la autorizza. Nei sistemi che incidono su processi con responsabilità formali, l’approvazione coinvolge il proprietario del processo, non solo il referente tecnico.
Documentazione leggibile. Le istruzioni contengono decisioni di governo espresse in linguaggio operativo: quando il sistema si astiene, quali informazioni non deve fornire, quando chiede conferma. Devono essere comprensibili a chi risponde del processo e a chi verifica la conformità.
Il legame con la valutazione continua
I due elementi sono lo stesso meccanismo osservato da due lati.
Un insieme di prova senza governo delle istruzioni misura un sistema che cambia senza controllo. Istruzioni versionate senza insieme di prova producono una tracciabilità delle modifiche senza sapere se abbiano migliorato o peggiorato il comportamento.
Il ciclo operativo è in cinque passi. Si rileva un problema, da una segnalazione o dal monitoraggio degli scarti. Si formula una modifica. Si esegue l’insieme di prova completo, confrontando i risultati con la versione precedente per metrica e per categoria di caso. Si valuta se il guadagno sui casi problematici supera l’eventuale perdita altrove. Si rilascia con versione e motivazione registrate.
Il terzo passo è quello che viene saltato con maggiore frequenza, ed è quello che rende il sistema affidabile nel tempo.
Vale infine un’osservazione sul cambio di modello: le istruzioni calibrate su una versione possono comportarsi diversamente su un’altra. Ogni aggiornamento del modello richiede una nuova esecuzione dell’insieme di prova, non solo una verifica di funzionamento.
Che cosa questo approccio non risolve
Non compensa un recupero documentale inadeguato. Nessuna istruzione fa produrre a un modello una risposta corretta su materiale sbagliato.
Non elimina la variabilità. I modelli linguistici sono per costruzione non deterministici: la stessa richiesta può produrre formulazioni diverse. Le istruzioni riducono la dispersione, non la azzerano, e i sistemi con requisiti di output rigidi vanno progettati tenendone conto.
Non sostituisce le regole deterministiche. Un vincolo esprimibile come condizione verificabile va implementato come tale.
E non è un’attività una tantum. La libreria va mantenuta come qualsiasi altro componente.
In chiusura
La qualità di un sistema in produzione dipende dalle istruzioni quanto dall’architettura di recupero, e le istruzioni sono l’unico componente che si tende a modificare senza processo.
Trattarle come codice — versionate, testate, approvate — non è un formalismo. È ciò che consente di modificarle senza degradare il comportamento.
Se avete un sistema in esercizio le cui istruzioni vengono modificate senza un ciclo di verifica, siamo disponibili a un confronto su come impostare libreria e insieme di prova.
