Quattro guasti che non sollevano alcun errore.
I progetti di intelligenza artificiale falliscono raramente sulla capacità del modello. Falliscono su difetti che non producono alcun messaggio, restituiscono un risultato plausibile, e superano tutti i controlli che si fanno spontaneamente.
Ciò che blocca un progetto non è quasi mai il modello
I lavori pubblicati sul fallimento dei progetti di intelligenza artificiale convergono su un punto: le iniziative che non raggiungono mai la produzione si contano in larghe maggioranze, e le cause citate non sono la capacità dei modelli. Sono la valutazione assente, l'integrazione con il sistema esistente, e l'affidabilità in condizioni reali.
Questa formulazione resta astratta finché non si è visto a che cosa assomiglia uno di questi guasti. Ecco quattro casi che abbiamo vissuto. Non hanno nulla in comune sul piano tecnico, e condividono tuttavia lo stesso tratto: nessuno produce un errore. Ciascuno supera un controllo superficiale, e ciascuno sarebbe stato scoperto da un utente anziché da noi.
Un flag di anteprima, e l'integrazione non produce nulla
Un'integrazione con un servizio di terzi era collegata, chiamata in produzione, e rispondeva correttamente a ogni sollecitazione. Non produceva tuttavia nulla di utilizzabile: un parametro che valeva «anteprima» per impostazione predefinita faceva uscire ogni documento barrato dalla dicitura corrispondente.
Il controllo abituale non poteva vedere il problema. La chiamata partiva, il servizio rispondeva, il documento arrivava. Tutto ciò che si verifica normalmente era verde.
La cosa più istruttiva è altrove. Cambiare questo parametro non era un dettaglio tecnico: cambiava chi paga che cosa, e dunque il trattamento contabile e fiscale dell'operazione. Tre file senza rapporto apparente dovevano muoversi lo stesso giorno.
Un irrigidimento degli accessi, e la tabella non restituisce più nulla
Abbiamo attivato il partizionamento per riga su una tabella di base dati, documentando che nessun accesso applicativo era desiderato. Ciò che il motore ne capisce è diverso da ciò che la frase suggerisce: attivare il partizionamento senza definire una politica non significa «riservato al servizio», significa nessuno.
Risultato: una riga perfettamente presente in base dati veniva contata zero dall'applicazione, e il percorso utente rispondeva che un identificativo valido non era più valido. Nessun errore, nessun rifiuto, nessuna traccia. Il sintomo è rigorosamente identico a quello di un identificativo sconosciuto.
La causa profonda non è la base dati, è il metodo di verifica. Un irrigidimento degli accessi si controlla spontaneamente nel senso «non scrive più», mentre è la lettura a rompersi, e si rompe in silenzio. Zero righe è una risposta valida, indistinguibile da un'assenza legittima.
Una variabile modificata, un processo che non l'ha letta
Un'impostazione viene corretta nel file di configurazione. Il valore è giusto, il file è rilasciato, e il comportamento non cambia. Si modifica allora qualcos'altro, si cerca altrove, e si finisce col dubitare dell'impostazione stessa.
La maggior parte dei programmi legge la propria configurazione all'avvio e la tiene in memoria. Finché il processo non è stato riavviato, lavora con il vecchio valore, qualunque sia il contenuto del file sul disco.
Questo caso sembra banale messo nero su bianco. Costa tuttavia ore perché si traveste da qualcos'altro: il sintomo osservato è «la mia correzione non funziona», il che orienta verso la correzione e mai verso il ciclo di vita del processo. La verifica consiste nel dimostrare che il processo che risponde è davvero quello nuovo, non nel rileggere il valore nel file.
Un rilascio partito dalla copia di lavoro
Il quarto caso è il più banale e il più difficile da recuperare. Un rilascio costruito a partire dalla cartella di lavoro anziché dal repository di codice imbarca tutto ciò che si trascina sulla postazione: un file modificato e non validato, una prova dimenticata, una correzione fatta in locale e mai versionata.
Funziona, spesso a lungo. Poi la produzione comincia a contenere codice che nessuno ritrova nello storico, e la persona che riprende il tema cerca per ore una modifica che non è mai esistita altrove che su una macchina.
Il rimedio sta in una frase: ciò che si rilascia viene dal repository, e un rilascio comincia col verificare che l'albero di lavoro sia pulito. Una regola noiosa, il cui valore si vede solo il giorno in cui qualcun altro riprende il sistema.
Che cosa hanno in comune questi quattro casi
Nessuno solleva un errore. Tutti restituiscono un risultato plausibile. E tutti superano il controllo che si fa spontaneamente, perché quel controllo verifica che il meccanismo giri invece di verificare che produca l'effetto giusto.
È la stessa lezione sotto quattro forme. Un controllo che non può fallire non controlla nulla. Vedere passare una richiesta non prova che abbia prodotto un effetto. Vedere un container in funzione non prova che serva la versione giusta. Vedere zero righe non prova che non ci sia nulla da vedere.
Queste verifiche costano qualche minuto ciascuna. Sono esattamente ciò che separa un prototipo che impressiona da un sistema che tiene, e non compaiono in nessuna dimostrazione.