Progettare un sito o un'applicazione digitale tradizionale segue da sempre una sequenza riconoscibile: una fase di ricerca e discovery, la definizione dell'architettura, infine la progettazione dell'interazione e dell'interfaccia. Il grosso dello sforzo sta a monte. È una fase di pensiero strutturata che raccoglie il massimo delle informazioni utili e le porta a chi poi deve disegnare e sviluppare. Un rapporto che si può riassumere come 80 prima e 20 dopo: tanto lavoro preliminare, poca rifinitura finale per sistemare i dettagli. Quando si arriva al traguardo di quella che la piramide data, information, knowledge, wisdom chiama saggezza, ciò che esce diventa naturale.
Tutto questo cambia radicalmente quando il cuore dell'applicazione è l'intelligenza artificiale. I pesi si invertono: si passa a 20 prima e 80 dopo. Poco lavoro preliminare e molta progettazione successiva. Non è una scelta stilistica, ma una conseguenza architetturale.
Dalla pagina bianca all'universo già disponibile
In un progetto classico si parte da una pagina bianca, con tutta la sindrome che comporta: una superficie vuota che deve accogliere puntini da unire per costruire un disegno. In un'applicazione costruita intorno a un modello linguistico, invece, la conoscenza del mondo è già pronta. Non si parte da una materia da trovare e poi plasmare, ma da un ambito di conoscenza totale che va più domesticato che scoperto. Non si sottrae dalla creta per fare la statua: la materia c'è già.
Un esempio concreto rende l'idea. Per creare un assistente che risponda alle domande sulle procedure interne di un'azienda, su come chiedere le ferie o su chi deve svolgere un certo compito, bastano i materiali già esistenti: manuali, mansionari, contratti, linee guida operative, una serie di PDF. Li si mette nel modello con un prompt di cinque righe che gli dice di comportarsi come il responsabile dell'organizzazione e di usare quei documenti per aiutare i dipendenti. Ci si mette lo stesso tempo che serve a dirlo, dieci minuti. E la macchina già risponde. Funziona, ma tra funzionicchia e rilasciabile c'è in mezzo il design.
La prima leva: il Mental Model
Dopo la meraviglia dei primi minuti arriva la frustrazione di non riuscire a far fare alla macchina esattamente quello che si vuole: la coerenza, la continuità, la risposta giusta. A quel punto comincia un processo invertito. Avendo già chiari obiettivi, task, gain e pain, si comincia a dare informazioni alla macchina perché le faccia proprie, perché capisca quali obiettivi perseguire e quali no, quali sono i suoi limiti e i suoi perimetri.
La prima leva è il Mental Model, una versione sofisticata del prompt che identifica con precisione il ruolo della macchina in quell'applicazione. Si può scrivere a tavolino, ma va testato, perché senza test non si sa se viene recepito correttamente, e va affinato progressivamente. È un processo agile: un Mental Model chiaro e semplice, messo in pratica e migliorato con i feedback dell'uso reale. A volte si scrivono parti in grassetto perché la macchina capisca che sono importanti, come in un'email. Da un Mental Model MVP si arriva a uno efficace solo attraverso uso, testing, correzione e riscrittura. È fondamentale che chi fa questo lavoro comprenda a fondo il contesto, perché sono le sfumature a fare la differenza, e a domanda imprecisa corrisponde risposta imprecisa.
Il fine tuning: dal modello di tutti al modello nostro
La seconda leva è il fine tuning, legato al reinforcement learning con feedback umano. Consiste nel creare set di conversazioni valide, editate a mano, scegliendo con cura le parole da usare in quel contesto, e utilizzarle per rimodellare il modello. In questo modo non resta più un modello generico, l'LLM di tutti, ma diventa il modello nostro, con una componente piccola ma molto focalizzata e specifica. Quelle conversazioni si individuano conversando, riconoscendo i prototipi che meritano di essere presi in considerazione, raffinandoli a mano. Raggiunto un numero ragionevole, dell'ordine del centinaio o meglio del migliaio, si possono usare per creare un modello specializzato.
La Knowledge base: le fondamenta semantiche
La terza leva è la Knowledge base, la base di informazioni specifica dell'azienda o del progetto da cui il modello attinge per formulare le risposte. Può essere composta da tipi diversi di asset: documenti non strutturati come PDF e Word, immagini, dati strutturati come database e fogli Excel, fino a siti web di cui si può fare lo scraping. Il valore è la centralizzazione: mettere insieme fonti generate in modi e momenti diversi e restituirle con una voce sola. La scelta di cosa includere e cosa escludere è design puro, perché definisce l'ambito semantico su cui poggia tutta l'applicazione.
Nella pratica le Knowledge base sono spesso incoerenti o lacunose. Trenta documenti su procedure aziendali, scritti da persone diverse in momenti e stili diversi, chiamano la stessa cosa in modi differenti e contengono impliciti. Ai modelli gli impliciti non piacciono: se un'informazione non è scritta, per una ricerca nella base di conoscenza semplicemente non esiste. E poiché le Knowledge base sono ciò che già si possiede, raramente vengono create ad hoc.
Il database delle regole
Per risolvere incoerenze e lacune senza riscrivere tutto entra in gioco il database delle regole: regole testuali gestibili in autonomia dall'azienda, masticate prima dell'accesso alla Knowledge base per disambiguare e aiutare la macchina a trovare e comprendere meglio le informazioni. Si può dire al modello che due termini rappresentano la stessa cosa o che dietro un certo argomento c'è un implicito da esplicitare. Sono regole locali, legate a pezzetti specifici della base di conoscenza: se qualcosa vale sempre, sta nel Mental Model; se vale solo parlando di un certo oggetto, sta in una regola che si attiva quando compare quella parola. L'esempio è quello di borraccia, bottiglia e termos: termini che nell'azienda indicano la stessa cosa anche se la documentazione li usa in modo intercambiabile.
Queste regole non si possono definire prima, per design. Si scoprono conversando: quando la macchina non risponde bene, si va a capire perché, si trova l'implicito non compreso, si crea la regola che lo supera, si riprova. È un processo successivo per definizione, perché si lavora su tutto ciò che si incontra strada facendo.
Un processo che non finisce mai
Il rilascio dell'applicazione arriva quando si raggiunge un ottimo locale ragionevole, ma da lì comincia un altro processo: il mantenimento e il continuous learning. Si analizzano le conversazioni reali in produzione, si comprende su cosa vertono e qual è il sentiment, se c'è efficacia o un warning che segnala una risposta mancata. Grazie alla parte di analytics si interviene con nuove regole, nuovo fine tuning o, quando serve, sostituendo o integrando pezzi di Knowledge base. Capita di accanirsi contro un modello che non funziona per scoprire poi che l'informazione non c'era proprio: un ottimo reality check per verificare se i dati siano davvero disponibili.
Il concetto di fondo resta uno: il processo di design dell'AI si inverte. Boots on the field, le mani subito nella materia, e poi tanto design di cesello e affinamento a strumento già funzionante, in un percorso di perfezionamento continuo che, di fatto, non finisce mai.