Ogni progetto di application maintenance assistita dall’AI parte da un presupposto implicito: che esista già una base di conoscenza da cui l’agente possa attingere. Quando un grande gruppo enterprise, in un settore fortemente regolamentato, ci ha chiesto un agente di triage per il supporto applicativo di secondo livello, quel presupposto si è rivelato il problema principale.
La Sfida: la conoscenza c’era, ma non era scritta da nessuna parte
Il team gestiva un flusso costante di segnalazioni, molte fuori perimetro o incomplete. Un agente avrebbe potuto classificarle e proporre una risposta, ma serviva materiale su cui ragionare. Gli ostacoli erano tre.
La conoscenza era tacita. Le procedure diagnostiche e il modo di riconoscere un falso allarme a colpo d’occhio vivevano nella testa dei tecnici e, frammentate, dentro migliaia di thread di ticket. Nessuno aveva mai avuto un motivo per scriverle.
I dati grezzi non erano utilizzabili così com’erano. Le estrazioni storiche arrivavano mensili e incrementali: lo stesso ticket ricompariva ogni mese con la conversazione un po’ più lunga, e andava riconciliato alla versione consolidata prima di poterlo usare. L’anonimizzazione dei dati personali, inoltre, doveva avvenire a monte, prima che qualunque testo raggiungesse un modello.
Una knowledge base opaca non è governabile. L’approccio istintivo è indicizzare tutto in un vector store e affidarsi al retrieval. Ma un indice vettoriale non si legge: se la base di conoscenza si sporca con informazioni sbagliate o contraddittorie, l’agente degrada lentamente e nessuno se ne accorge finché non è tardi.
L’Approccio Tecnico: la knowledge base è codice
Per afforntare con successo questo problema abbiamo adottato una soluzione basata su LLM-Wiki (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f): una wiki in Markdown, con pagine collegate da link, generata e manutenuta da un agente e versionata in un repository Git come se fosse software.
L’architettura ha due livelli. Il primo contiene i dati grezzi immutabili: ticket anonimizzati e documentazione dei sistemi, comprese le classificazioni già in uso. Il secondo contiene le informazioni e i documenti che l’agente deriva dal primo, cioè pagine di problemi noti che sintetizzano pattern ricorrenti su più ticket, playbook diagnostici, tassonomie. È il tipo di sintesi che i tecnici fanno a mente da anni senza mai avere il tempo di scriverla.
Il punto decisivo sta nel secondo livello: ogni modifica alla wiki è una pull request. L’agente non scrive nella knowledge base, propone una modifica; un esperto di dominio legge il diff e approva o rifiuta. Un problema di fiducia diventa così un problema di code review, con la storia delle revisioni, la tracciabilità delle approvazioni e la possibilità di tornare indietro quando una modifica si rivela sbagliata.
L’anonimizzazione, di conseguenza, diventa un confine architetturale e non un filtro applicato a valle: nel perimetro dell’agente entrano solo dati già ripuliti, e la wiki nasce anonima per costruzione. Dentro ci finiscono le lezioni apprese, non i casi singoli.
Il Risultato: una conoscenza che cresce invece di invecchiare
Alla chiusura di ogni ticket l’agente propone un aggiornamento: un problema noto in più, la correzione di un playbook esistente. La conoscenza si accumula come effetto collaterale del lavoro quotidiano, senza dipendere da un’iniziativa di documentazione che nessuno ha mai il tempo di completare.
Il guadagno si vede su tre piani. Ogni risposta dell’agente è riconducibile a una pagina che un essere umano può leggere e contestare, non a un frammento vettoriale privo di contesto. Quando la qualità peggiora si va a guardare la storia delle modifiche, e si scopre quale aggiornamento ha rotto cosa. E la wiki resta un documento utile alle persone: sopravvive a un cambio di modello o di framework, che di questi tempi non è un’ipotesi remota.
Conclusione
L’errore più comune nei progetti di AI applicata al supporto non riguarda la scelta del modello. Riguarda l’aver dato per scontato che la conoscenza esista già in forma utilizzabile: quasi mai è così. Trattarla come si tratta il codice, con versioni e revisioni approvate, è quello che separa un agente che funziona in demo da un sistema che l’IT può governare nel tempo.