Chi costruisce agenti AI per l’automazione IT conosce bene un problema frustrante: l’agente sbaglia un task, magari un’esecuzione di comando maldestra o un’interpretazione errata di un output di sistema, e la settimana dopo commette esattamente lo stesso errore. La memoria “di lavoro” di un large language model non sopravvive tra una sessione e l’altra, e l’unico modo tradizionale per farla persistere — il fine-tuning — è costoso, lento e rischia di degradare capacità già acquisite (il classico catastrophic forgetting).

Google Research ha proposto un’alternativa che vale la pena analizzare da vicino: WikiSkill, un framework che permette agli agenti di accumulare esperienza operativa sotto forma di conoscenza testuale strutturata, senza toccare i pesi del modello. È un tema che si lega direttamente a quanto discusso in precedenti approfondimenti su questo blog riguardo l’architettura degli agenti AI come sistemi distribuiti e i controlli infrastrutturali necessari per metterli in sicurezza: WikiSkill aggiunge un tassello importante, quello dell’apprendimento continuo controllato.

Il problema: agenti che non imparano dai propri errori

Un agente basato su LLM esegue un task, magari fallisce per un dettaglio (un parametro sbagliato in una chiamata API, un’assunzione errata sul formato di un file), e nella sessione successiva il contesto è azzerato. Le opzioni classiche per fissare la lezione sono due:

• Fine-tuning: richiede dataset curati, potenza di calcolo, tempi di rilascio lunghi, e comunque non garantisce che il modello generalizzi la lezione senza perdere altre capacità.
• RAG (Retrieval-Augmented Generation): recupera documenti o frammenti di conoscenza pertinenti, ma non consolida “come si fa” un’operazione in un’istruzione procedurale riutilizzabile: resta un recupero di informazione, non una skill.

WikiSkill propone una terza via: trattare l’esperienza dell’agente come conoscenza da redigere e mantenere, un po’ come farebbe un team che aggiorna una wiki interna di runbook operativi dopo ogni incident.

Architettura a tre livelli

Il cuore del sistema è la separazione della memoria dell’agente in tre strati distinti, ciascuno con uno scopo preciso:

Raw Layer

Conserva le tracce di esecuzione grezze e immutabili: chiamate agli strumenti, argomenti passati, output ricevuti, esito (successo o fallimento). È il log di sistema, la fonte di verità da cui tutto il resto viene derivato.

Wiki Layer

Distilla le tracce grezze in conoscenza strutturata e durevole: pattern di fallimento documentati (“quando il file supera i 10.000 record, la funzione X va in timeout”) e strategie di successo verificate. È l’equivalente di una knowledge base di post-mortem, ma scritta e mantenuta automaticamente da un componente dedicato.

Skill Layer

Contiene le istruzioni procedurali attive che l’agente usa durante l’esecuzione — il “come fare” operativo. A differenza del Wiki Layer, che è un registro cumulativo, le skill possono essere aggiornate e ripristinate se una revisione peggiora le prestazioni. Questo è un dettaglio architetturale importante: separare “quello che sappiamo” (wiki, sempre append-only) da “quello che facciamo adesso” (skill, versionabile e reversibile).

Il ciclo di miglioramento continuo

Il processo di apprendimento è organizzato in quattro componenti che lavorano in loop:

1. Inference Agent   → esegue il task e produce una traccia di esecuzione
2. Wiki Maintainer   → analizza la traccia e aggiorna il Wiki Layer
                        con nuove osservazioni (successi e fallimenti)
3. Skill Proposer    → sulla base del wiki aggiornato, propone una
                        revisione delle istruzioni nello Skill Layer
4. Gating Mechanism  → valida la skill proposta su un dataset separato
                        di validazione: se migliora i risultati viene
                        promossa, altrimenti si effettua il rollback
                        alla versione precedente

Il punto cruciale è il gating mechanism: nessuna modifica alle istruzioni operative viene applicata senza una verifica empirica su un set di validazione separato da quello di training del ciclo. Le skill che peggiorano le prestazioni vengono scartate, ma il wiki mantiene comunque traccia del tentativo fallito — anche gli esperimenti negativi diventano conoscenza utile per le proposte future.

I numeri: quanto migliora davvero

Google ha testato WikiSkill su cinque benchmark (LiveMath, SealQA, SpreadSheet, OfficeQA, ALFWorld) usando modelli di diverse dimensioni, da Qwen 4B a 27B, Gemma-4-31B e Gemini-3.5-Flash. I risultati aggregati sono significativi:

• Gemini-3.5-Flash: dal 49,5% al 68,1% di accuratezza media sui benchmark testati.
• Qwen-27B: dal 39,4% al 63,3%.
• Sul singolo benchmark LiveMath, Gemini è passato dal 33,0% al 72,6%.
• Su SpreadSheet, dal 50,5% al 76,6%.

Un’osservazione interessante per chi progetta pipeline di agenti in produzione: modelli più piccoli equipaggiati con WikiSkill possono avvicinarsi alle prestazioni di modelli più grandi senza il framework, il che ha implicazioni dirette sui costi di inferenza. Le skill sviluppate, inoltre, si sono dimostrate parzialmente trasferibili tra modelli diversi, anche se non sempre performano meglio delle skill “auto-sviluppate” dallo stesso modello che le userà.

Implicazioni pratiche per chi costruisce agenti aziendali

Per un team che sviluppa agenti operativi (automazione di ticket, agenti DevOps, assistenti di troubleshooting) il pattern è replicabile anche senza il framework completo di Google, seguendo la stessa logica architetturale:

• Salvare sistematicamente le tracce di esecuzione (input, tool call, output, esito) in uno store persistente — anche una semplice tabella in un database relazionale è sufficiente per iniziare.
• Introdurre un processo, anche semi-automatico, che analizzi periodicamente i fallimenti e aggiorni un documento di “lezioni apprese” separato dal prompt di sistema operativo.
• Versionare le istruzioni operative (il “system prompt” o le skill dell’agente) come si versiona il codice, con la possibilità di rollback immediato.
• Non promuovere mai una nuova versione delle istruzioni senza un test A/B su un set di casi di validazione rappresentativo, esattamente come si farebbe con un modello di machine learning classico.

C’è però un rischio che vale la pena evidenziare, ed è coerente con quanto già discusso su questo blog a proposito di data poisoning e avvelenamento dei sistemi di raccomandazione AI: se il Wiki Layer viene alimentato anche da segnali esterni non fidati (ad esempio output di strumenti di terze parti, o contenuti recuperati dal web), un attaccante potrebbe in teoria tentare di iniettare “lezioni” false per orientare il comportamento futuro dell’agente. Qualsiasi implementazione di questo pattern in produzione dovrebbe quindi trattare il Wiki Layer come una superficie di attacco a tutti gli effetti, con validazione e, se possibile, revisione umana periodica delle voci più impattanti prima che vengano promosse a skill attiva.

Conclusione

WikiSkill non è un prodotto pronto all’uso ma un framework di ricerca, e i benchmark testati sono compiti relativamente circoscritti (matematica, fogli di calcolo, ricerca, ambienti simulati). Tuttavia il principio architetturale — separare log grezzi, conoscenza distillata e istruzioni operative, con un gate di validazione tra la conoscenza e l’azione — è un pattern solido e riutilizzabile per chiunque stia progettando agenti AI destinati a girare in produzione per mesi, non per una singola sessione. In un momento in cui la spesa per l’infrastruttura AI aziendale cresce rapidamente, poter migliorare le prestazioni di un agente aggiornando testo invece di ripetere costosi cicli di fine-tuning è un vantaggio operativo ed economico che vale la pena tenere d’occhio.

Fonte: 4sysops.com. Approfondimento tecnico: The Decoder. Paper originale su arXiv (2608.27454).