Ingegneria dell'affidabilità
Come costruire sistemi affidabili da componenti inaffidabili – e perché non è così nuovo come sembra.
Il disagio
Ogni sviluppatore conosce questo contratto:
Stesso input → stessa logica → stesso output. Ogni volta.
L'IA rompe questo contratto. Lo stesso prompt, lo stesso modello, lo stesso input possono produrre output diversi in esecuzioni consecutive. Per gli ingegneri formati sui sistemi deterministici, questo sembra fondamentalmente rotto.
La resistenza non è puramente intellettuale. È emotiva. Gli ingegneri costruiscono la propria identità intorno alla qualità del loro output, intorno al controllo sul comportamento del sistema. Quando un componente produce risultati inconsistenti, non mette in discussione solo un'assunzione tecnica. Mette in discussione il senso di padronanza che rende il lavoro significativo. Riconoscere questo è il primo passo per superarlo.
Non è rotto. È un tipo diverso di sistema. E richiede un tipo diverso di ingegneria dell'affidabilità.
Lo fai già
Il disagio è reale, ma il problema non è nuovo. Gli sviluppatori già lavorano ogni giorno con componenti inaffidabili:
- Le reti falliscono. Riprovi. Aggiungi timeout. Progetti per il fallimento parziale.
- Le API di terze parti cambiano. Versionifici. Scrivi contract test. Aggiungi fallback.
- Esistono race condition. Usi lock, code e idempotenza.
- Gli utenti forniscono input errati. Validi, sanifichi e rifiuti.
Nessuno di questi sistemi è deterministico a livello di componente. Sono affidabili a livello di sistema – perché hai ingegnerizzato l'affidabilità intorno a parti inaffidabili.
L'IA è lo stesso schema. Il modello è un componente inaffidabile. Il tuo lavoro è costruire un sistema affidabile intorno ad esso.
Il riquadramento
Il software tradizionale chiede: Funziona?
I sistemi IA chiedono: Con quale frequenza funziona?
Non è uno standard più basso. È uno più onesto. Anche il software tradizionale fallisce – ma fallisce in modi che abbiamo imparato a nascondere (gestione degli errori, retry, degradazione controllata). L'IA rende l'inaffidabilità visibile invece di seppellirla.
L'affidabilità non è "dà sempre la stessa risposta". L'affidabilità è "il sistema opera in modo consistente entro limiti accettabili". I limiti li definisci tu.
Il kit di strumenti
Il passaggio dai sistemi deterministici a quelli probabilistici richiede pratiche ingegneristiche specifiche. Nessuna di queste è esotica – è la stessa disciplina che già applichi ai sistemi distribuiti, applicata a un nuovo tipo di componente.
La valutazione sostituisce i test unitari
Nel software tradizionale, i test verificano output esatti. Nei sistemi IA, valuti le distribuzioni.
Ogni sistema IA dovrebbe avere:
- Un dataset di valutazione che rappresenta il comportamento atteso
- Esecuzioni di valutazione automatizzate ad ogni cambiamento
- Controlli di regressione che rilevano il degrado
Questo svolge lo stesso ruolo di una suite di test. Senza di essa, i sistemi IA degredano silenziosamente – non perché il codice sia cambiato, ma perché il modello è cambiato.
I guardrail sostituiscono la fiducia
L'output degli LLM non dovrebbe quasi mai essere fidato direttamente. Il modello fornisce il ragionamento. Il sistema fornisce l'affidabilità.
I sistemi di produzione devono includere livelli di validazione:
- Output strutturati o schemi che impongono il formato
- Regole di business deterministiche che ignorano il giudizio del modello dove appropriato
- Validazione dell'output che rileva le allucinazioni e le violazioni dei vincoli
- Loop di retry e riparazione per i fallimenti recuperabili
- Agente revisore – un agente valutatore separato revisiona l'output dell'agente primario (vedi sotto)
- Revisione umana graduata per rischio dove il costo dell'errore è alto – vedi gate di validazione graduati per rischio per l'allocazione HITL / HOTL / HOOTL
I guardrail non sono un'ammissione che l'IA sia cattiva. Sono l'ingegneria che rende l'IA utile.
L'agente revisore è il default di produzione
Per il lavoro non banale, abbina il generatore a un agente valutatore separato – contesto diverso, a volte un modello diverso. Il pattern è ora il default di produzione per la revisione del codice (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) ed è in adozione nel servizio clienti (revisione di tono + policy), nell'elaborazione documenti e in altri domini di lavoro discreto.
Perché conta: gli umani che valutano l'output rapidamente sono valutatori inaffidabili di output presentato con sicurezza ma scorretto. Gli agenti revisori, eseguiti in contesti diversi, fanno emergere ciò che gli umani stanchi non vedono. La ricerca PoLL ("Panel of LLM judges") rileva che giurie di modelli più piccoli spesso superano un singolo grande giudice (Verga et al., 2024) – e a costo inferiore.
Struttura di costo: un agente revisore separato su ogni artefatto raddoppia approssimativamente la spesa di inferenza per task. Al Grado 5, questo è ora considerato valga la pena – la matematica del costo per unità unita funziona perché la revisione umana su scala non funziona.
I passaggi più piccoli sostituiscono i prompt grandi
I prompt grandi che cercano di risolvere tutto sono fragili. Combinano troppi modi di fallire in una singola chiamata.
I sistemi IA affidabili decompongono i compiti:
- Classifica l'input
- Recupera il contesto rilevante
- Genera l'output
- Valida struttura e qualità
- Ripara se necessario
Ogni passaggio può essere valutato, monitorato e migliorato indipendentemente. Le unità di ragionamento più piccole aumentano l'affidabilità per lo stesso motivo per cui le funzioni piccole sono più affidabili di quelle monolitiche.
L'osservabilità sostituisce le supposizioni
I sistemi IA di produzione devono esporre:
- Log dei prompt – cosa è entrato
- Risposte del modello – cosa è uscito
- Punteggi di valutazione – quanto era buono
- Casi di fallimento – cosa è andato storto
- Metriche di costo e latenza – quanto costa
Non puoi migliorare ciò che non puoi vedere. E i sistemi IA falliscono in modi invisibili senza strumentazione – l'output sembra plausibile ma è sbagliato.
Il versionamento sostituisce la stabilità
I modelli IA evolvono continuamente. Un aggiornamento del modello può cambiare il comportamento in modi che nessuna modifica al codice spiegherebbe.
Le pratiche ingegneristiche devono includere:
- Versionamento del modello – fissa la versione del modello in produzione. Aggiorna deliberatamente.
- Versionamento del prompt – tratta i prompt come codice. Traccia i cambiamenti. Revisiona le differenze.
- Valutazione all'aggiornamento – esegui la tua suite di valutazione prima e dopo ogni cambio di modello, nello stesso modo in cui esegui i test prima di distribuire una nuova dipendenza.
- Iterazione rapida – quando qualcosa si rompe, itera velocemente. La correzione è di solito nel prompt, nei guardrail o nella valutazione – non nel modello.
Tratta i cambiamenti del modello come aggiornamenti delle dipendenze. Sai già come gestirli.
Modi di fallimento e recupero ad alta maturità
Il kit di strumenti gestisce i modi di fallimento noti. Alla maturità Tier 3 / Grado 5, tre preoccupazioni aggiuntive diventano dominanti: due nuovi modi di fallimento (sycophancy, casi limite soggettivi) e un pattern di risposta (ricalibrazione vs debugging) che distingue la pratica ad alta maturità da quella a bassa maturità. Nessuno è colto da test o monitoraggio; gli ingegneri devono saperli riconoscere.
Sycophancy: una preoccupazione strutturale
Gli LLM difendono in modo affidabile posizioni sbagliate con sicurezza. Questo è misurato in più studi (Sharma et al., 2023; Wen et al., 2024; OpenAI sulle allucinazioni, 2025). Wen et al. hanno rilevato che l'RLHF rende i modelli migliori nel convincere gli umani che hanno ragione senza renderli migliori nell'avere effettivamente ragione (tasso di falsi positivi +24% nelle QA, +18% nella programmazione).
La letteratura è in genuino disaccordo sul fatto che la sycophancy sia un problema trattabile con il training o un artefatto strutturale dell'RLHF.
La posizione del framework: trattare la sycophancy come una preoccupazione strutturale ai fini ingegneristici, indipendentemente dalla traiettoria di training.
Inserisci salvaguardie di processo (segnale esterno, agente revisore, retrieval di ground-truth, test eseguibili) in ogni ciclo. Non fidarti della sicurezza del modello come segnale di correttezza.
Se il training la migliora più tardi, le salvaguardie rimangono utile infrastruttura. Se no, le salvaguardie sono essenziali.
Casi limite soggettivi
A bassa maturità, i casi limite sono tecnici: i test non li colgono, il monitoraggio li mostra come anomalie, la correzione è nel codice. A maturità più alta, il caso limite dominante cambia: è soggettivo. Un utente segnala che l'IA ha sbagliato qualcosa – ma i test passano, il monitoraggio è verde e il fallimento è qualitativo.
Esempi:
- Ingegneria – un PR è tecnicamente corretto ma l'agente ha preso un percorso di implementazione sbagliato; l'utente nota "non era questo che intendevo"
- Servizio clienti – un ticket risolto dall'IA ha i fatti corretti ma il tono è inappropriato per lo stato emotivo del cliente
- Finanza – una transazione è categorizzata correttamente dalla regola ma la regola stessa rappresenta male l'intento aziendale
- Contenuti / marketing – il testo è grammaticale e a spec ma perde la voce del brand
Il recupero è conversazione, non patching. Parla con l'utente. Capisci cosa stava cercando di realizzare. Aggiorna la specifica o il contesto – non il codice.
Questo modo di fallimento è ben documentato ma poco nominato. Le fonti dei professionisti vi si riferiscono con vocabolario diverso: il problema del 70% di Addy Osmani (l'ultimo 30% è lavoro umano), la ricerca UX di NN/g, il PAIR Guidebook. Il framework lo nomina esplicitamente perché la risposta operativa differisce strutturalmente da una correzione tecnica di bug.
Ricalibrazione vs debugging
Quando l'IA sbaglia, due risposte sono possibili:
Correggi l'artefatto (codice, risposta, documento) prodotto dall'agente. Tratta il fallimento come un problema di codice.
Ricostruisci la comprensione dell'agente tramite contesto fresco, specifica riarticolata, brainstorm multi-prospettiva. Tratta il fallimento come un problema di specifica o contesto.
Queste sono operativamente distinte.
La letteratura sull'auto-correzione intrinseca è unanime: un modello che si è impegnato in una direzione sbagliata non se ne accorgerà in modo affidabile da solo; la riflessione nella stessa finestra di contesto dopo una risposta sbagliata aggrava l'errore invece di correggerlo (Huang et al., 2023; Kamoi et al., 2024). Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) hanno rilevato che il 41,8% dei fallimenti multi-agente sono problemi di specificazione o design che necessitano di ri-specificazione, non di retry.
Euristica pratica: se la stessa specifica produce lo stesso output sbagliato in due esecuzioni fresche, debugga la specifica, non l'artefatto. La maggior parte dei fallimenti non banali a maturità alta sono problemi di ricalibrazione travestiti da problemi di debugging.
Vedi Lab IA § Protocollo di stato bloccato per il pattern operativo.
Il cambiamento di ruolo
In questo modello, gli ingegneri non scrivono principalmente logica. Progettano sistemi che supervisionano l'intelligenza. Questo è, strutturalmente, management: specificare l'intento a un esecutore imperfetto, valutare l'output piuttosto che controllare il processo, e iterare sulla propria comunicazione quando il risultato non corrisponde all'intento. I manager hanno sempre operato in un mondo probabilistico. Gli ingegneri si stanno unendo a loro.
- •Scrivere logica di business
- •Implementare algoritmi noti
- •Debug riga per riga
- •Ottimizzare i percorsi di esecuzione
- •Progettare prompt e interfacce degli strumenti
- •Costruire livelli di validazione e valutazione
- •Progettare loop di retry e correzione
- •Monitorare le prestazioni a livello di sistema
Non è una retrocessione. È un passaggio a un livello di astrazione più alto, lo stesso cambiamento che è avvenuto quando gli ingegneri sono passati dall'assembly ai linguaggi di alto livello, o dal bare metal all'infrastruttura cloud. Ogni transizione è sembrata una perdita di controllo. Ognuna era in realtà un guadagno di leva.
Il principio fondamentale
Non programmiamo l'intelligenza. Progettiamo ambienti in cui l'intelligenza opera in modo affidabile.
L'inaffidabilità non è il problema. È la natura del componente. L'ingegneria è ciò che trasforma un componente inaffidabile in un sistema affidabile.
Non è nuovo. È quello che gli ingegneri hanno sempre fatto.
Correlato: la maturità del codice affronta il problema inverso: non come costruire sistemi affidabili da output IA inaffidabili, ma come dare agli agenti IA un codebase abbastanza leggibile da produrre lavoro affidabile. Stessa incertezza, riflessa.
← Torna alla home · Il Lab IA · Standard di esecuzione IA · Il Quadro di Riferimento