Quando oggi si parla di sviluppare un’applicazione basata sull’intelligenza artificiale, quasi inevitabilmente la discussione comincia dal modello da utilizzare, dalle funzionalità che dovrà avere l’applicazione, dall’interfaccia e, naturalmente, dal prompt.
È comprensibile. Sono le parti immediatamente visibili del prodotto e sono anche quelle che permettono di ottenere velocemente qualcosa da mostrare. Si collega un LLM, gli si forniscono delle istruzioni sufficientemente dettagliate e, dopo qualche tentativo, si ottengono risultati che possono essere anche sorprendenti.
Il problema è che quella è una demo. Non è ancora un sistema.
Quando ragiono sullo sviluppo di un’applicazione che utilizza l’AI, una delle prime domande che mi pongo è diversa: “Che cosa succederà a questa applicazione quando comincerà a essere utilizzata da persone reali, in situazioni che oggi non conosco e che non posso prevedere completamente?”
Perché il prompt che funziona perfettamente oggi è stato scritto sulla base di quello che sappiamo oggi. L’applicazione reale, invece, comincerà immediatamente a produrre nuove informazioni.
Ed è proprio lì che, secondo me, comincia la parte interessante del problema.
Un prompt non è un’applicazione intelligente
Immaginiamo di sviluppare un’applicazione per un’agenzia di viaggi.
Possiamo scrivere un ottimo prompt che tenga conto della destinazione, del budget, della durata del viaggio, dell’età dei viaggiatori e di una serie di preferenze. Con un buon modello possiamo probabilmente ottenere itinerari di qualità già dal primo giorno.
E poi, ecco che arrivano gli utenti.
Scopriamo che un cliente preferisce spendere di più per l’albergo e risparmiare sui ristoranti, mentre un altro fa esattamente il contrario. Una famiglia considera perfettamente normale cambiare città ogni due giorni, mentre un’altra trova stressante cambiare albergo più di una volta durante l’intero viaggio. Per qualcuno venti minuti a piedi non rappresentano un problema; per qualcun altro diventano un elemento determinante nella scelta di un hotel.
Potremmo naturalmente continuare ad aggiungere informazioni al prompt. Ma a quel punto staremmo semplicemente cercando di costruire un prompt sempre più grande che contenga tutto quello che sappiamo.
Il problema, però, non è soltanto “che cosa sappiamo”. Dobbiamo anche stabilire quanto possiamo fidarci di quello che crediamo di sapere, quando quell’informazione è rilevante e se continua a essere vera.
Se una persona sceglie una volta un hotel economico, posso concludere che preferisce gli hotel economici? Probabilmente no. Se lo fa sistematicamente in dieci viaggi diversi, quell’informazione comincia ad avere un peso differente.
Il modello, da solo, non gestisce questo processo.
Ed è qui che entra in gioco quello che in inglese viene chiamato “AI harness”.
Che cos’è, concretamente, un harness?
Non conosco una traduzione italiana di “harness” che riesca a rendere bene il concetto. “Sistema di controllo” ne descrive soltanto una parte, mentre “orchestratore” rischia di far pensare a qualcosa di diverso. Preferisco quindi mantenere il termine inglese e spiegare cosa intendo quando lo utilizzo.
Un LLM, semplificando molto, riceve un insieme di informazioni e istruzioni e produce un risultato.
L’harness è il sistema software costruito intorno al modello che decide come quel processo deve avvenire.
Decide quali informazioni fornire al modello in una determinata situazione, da dove provengono, quanto sono affidabili e quali non devono essere utilizzate. Osserva ciò che accade dopo che il modello ha prodotto un risultato, raccoglie nuove evidenze, verifica quando possibile la qualità di quel risultato e decide se ciò che è stato appreso debba influenzare le interazioni successive.
Il prompt è quindi soltanto una componente di questo sistema.
All’interno dell’harness possono esserci memoria, regole, dati provenienti dall’applicazione, strumenti di verifica, livelli di confidenza, sistemi di valutazione e meccanismi che stabiliscono quando il modello può procedere autonomamente e quando invece è necessario coinvolgere una persona.
Per questo considero l’harness una parte fondamentale dell’architettura e non qualcosa da aggiungere successivamente.
Se voglio che un’applicazione AI possa realmente migliorare con l’utilizzo, devo progettare fin dall’inizio come apprenderà, non soltanto come risponderà.
Il problema successivo: chi valuta quello che viene appreso?
A questo punto nasce immediatamente un altro problema.
Supponiamo che l’applicazione acquisisca una nuova informazione su un utente. Come decidiamo se quell’informazione debba diventare parte del contesto che verrà utilizzato in futuro?
La soluzione più semplice sarebbe chiedere continuamente conferma all’utente.
“Questa risposta è stata utile?”
“Questa preferenza è corretta?”
“Vuoi che ricordi questa informazione?”
In alcuni casi è inevitabile e in altri è persino desiderabile. Ma se il funzionamento dell’harness dipende continuamente dal feedback esplicito, abbiamo creato un altro problema: per far evolvere l’AI abbiamo aggiunto lavoro all’essere umano.
È esattamente ciò che cercherei di evitare.
Una quantità enorme di feedback viene già prodotta durante il normale utilizzo dell’applicazione.
Se propongo tre hotel e l’utente tende sistematicamente a scegliere quelli centrali, sto ricevendo un’informazione. Se gli itinerari generati dall’AI vengono continuamente modificati eliminando le attività programmate molto presto al mattino, anche quella è un’informazione. Se una determinata proposta viene accettata senza modifiche, modificata oppure ignorata, sono tutti comportamenti che possono diventare evidenze.
Il punto importante è che un’evidenza non deve automaticamente diventare una verità.
Un singolo comportamento può generare un’ipotesi. La ripetizione dello stesso comportamento può aumentare il livello di confidenza. Informazioni successive possono confermarla oppure contraddirla. Il contesto può spiegare perché un comportamento apparentemente significativo fosse invece soltanto occasionale.
È quindi l’harness che dovrebbe gestire questa evoluzione, conservando non soltanto l’informazione ma anche la sua provenienza, il contesto nel quale è stata osservata e il livello di affidabilità che possiamo attribuirle.
In questo modo l’applicazione può imparare progressivamente senza costringere l’utente a diventare il supervisore permanente del processo.
Il feedback umano rimane importante, ma dovrebbe essere utilizzato dove porta realmente valore: quando l’evidenza è ambigua, quando la decisione ha conseguenze importanti o quando il sistema non possiede sufficiente confidenza per procedere autonomamente.
Il rischio dell’auto-evoluzione
C’è inoltre una distinzione che considero essenziale: cambiare non significa necessariamente migliorare.
Un sistema che acquisisce continuamente informazioni e modifica il proprio comportamento sulla base di quelle informazioni non è automaticamente un sistema che sta imparando bene. Potrebbe semplicemente amplificare errori precedenti.
Una conclusione sbagliata potrebbe entrare nel contesto, influenzare una risposta successiva e produrre un nuovo comportamento che apparentemente conferma la conclusione iniziale. Se non abbiamo progettato un meccanismo capace di riconoscere questo fenomeno, abbiamo costruito un ciclo di feedback che può rafforzare i propri errori.
Per questo, quando parlo di un’applicazione capace di “auto-evolversi”, non intendo un sistema libero di riscrivere continuamente il proprio comportamento.
Intendo un sistema nel quale l’evoluzione stessa è controllata, misurata e reversibile.
Deve essere possibile sapere perché una determinata informazione viene utilizzata, quale evidenza l’ha prodotta e, quando necessario, rimuoverla senza distruggere tutto ciò che il sistema ha imparato nel frattempo.
È una differenza importante, perché sposta il problema dal semplice utilizzo dell’intelligenza artificiale alla progettazione di un vero sistema adattivo.
Forse possiamo dire che stiamo usando l’AI al contrario
Mentre ragionavo su questo tipo di architettura mi sono reso conto di un altro paradosso che riguarda molte delle applicazioni AI che utilizziamo oggi.
Stiamo progressivamente affidando all’intelligenza artificiale la parte creativa del lavoro e lasciando agli esseri umani quella ripetitiva, noiosa e meccanica.
Torniamo all’esempio del viaggio.
Posso chiedere a un’AI di organizzarmi dieci giorni in Giappone. In pochi secondi può produrre un itinerario dettagliato con Tokyo, Kyoto e Osaka, suggerire alberghi, ristoranti, musei, escursioni, treni e persino indicarmi dove andare a vedere il tramonto.
Il risultato può essere bellissimo.
Poi comincia il mio lavoro.
Devo verificare se gli alberghi suggeriti hanno effettivamente camere disponibili nelle mie date e se i prezzi corrispondono al budget. Devo controllare gli orari dei treni, verificare che i musei siano aperti nei giorni indicati, capire se sia necessaria una prenotazione, controllare la disponibilità dei biglietti e assicurarmi che i tempi di trasferimento proposti siano realistici.
In altre parole, la macchina ha fatto la parte creativa e ha lasciato a me il lavoro sporco.
Credo che dovremmo cercare di fare esattamente il contrario.
Io voglio decidere che tipo di viaggio desidero fare. Voglio scegliere se trascorrere tre giorni a Kyoto invece di due, se preferisco un piccolo ryokan oppure un grande hotel, se voglio vedere dieci cose in una giornata oppure perderne metà e passare un pomeriggio senza programma.
Quella è la parte nella quale la decisione umana ha valore.
La macchina dovrebbe invece lavorare dietro le quinte per verificare che quello che ho deciso sia realmente possibile. Dovrebbe controllare disponibilità, orari, distanze e incompatibilità, confrontare fonti diverse e segnalarmi che il museo che ho scelto è chiuso proprio quel martedì o che il treno previsto arriva dopo l’orario limite per il check-in.
E possibilmente dovrebbe rifare autonomamente questi controlli prima della partenza, perché nel frattempo qualcosa potrebbe essere cambiato.
A quel punto l’AI non starebbe sostituendo la mia creatività. Starebbe eliminando il lavoro che non aggiunge alcun valore alla mia creatività.
Anche questo è un problema di harness
Per ottenere un comportamento del genere non basta chiedere a un LLM di “verificare meglio”.
Il sistema deve sapere quali informazioni necessitano di verifica, quali fonti utilizzare, quando un dato è sufficientemente recente, cosa fare quando due fonti sono in contraddizione e quale livello di confidenza è necessario prima di presentare qualcosa come un fatto.
Deve inoltre capire quando può risolvere autonomamente un problema e quando invece la decisione deve tornare all’essere umano.
È nuovamente il ruolo dell’harness.
Il modello può ragionare e generare. L’harness gli fornisce il contesto nel quale farlo, ne osserva il risultato e gestisce ciò che accade prima e dopo la generazione.
Questa distinzione cambia anche il modo in cui considero l’LLM all’interno dell’architettura. Per quanto sofisticato possa essere, rimane una componente del sistema.
Una componente straordinariamente potente, ma non il sistema stesso.
Perché partirei da qui
Quando si sviluppa software tradizionale nessuno penserebbe seriamente di progettare prima tutte le schermate e occuparsi soltanto alla fine dell’architettura, del database, della sicurezza e della business logic.
Eppure con l’AI vedo spesso qualcosa di molto simile.
Si costruisce la demo, si perfeziona il prompt, si ottiene una risposta impressionante e si comincia a costruire il prodotto intorno a quella risposta.
Io preferisco partire da altre domande.
Che cosa dovrà imparare questa applicazione durante il suo utilizzo? Da quali evidenze potrà impararlo? Come distinguerò un comportamento occasionale da una preferenza reale? Come verificherò quello che produce? Come impedirò che un errore diventi nuova conoscenza? Quali decisioni potrà prendere autonomamente e quali dovranno rimanere sotto controllo umano?
E soprattutto: come potrò dimostrare, tra sei mesi, che il sistema è effettivamente diventato migliore rispetto al giorno in cui è stato messo in funzione?
Se non riesco a rispondere a queste domande, probabilmente non ho ancora progettato la parte più importante dell’applicazione. Ho soltanto collegato un modello.
Il modello diventerà probabilmente la parte meno interessante
Credo che questa distinzione diventerà ancora più importante nei prossimi anni.
L’accesso a modelli estremamente potenti diventerà sempre più semplice e la differenza tra due applicazioni difficilmente sarà determinata soltanto dal fatto che una utilizzi un LLM migliore dell’altra.
La differenza sarà sempre più in ciò che viene costruito intorno al modello.
Sarà nel modo in cui raccogliamo evidenze, costruiamo il contesto, distinguiamo il segnale dal rumore, verifichiamo automaticamente i risultati e consentiamo al sistema di adattarsi senza perdere il controllo del motivo per cui sta cambiando.
Ed è questa la ragione per cui considero l’harness una delle prime cose a cui pensare quando progetto un’applicazione AI, non qualcosa da aggiungere quando il resto è già stato costruito.
Perché un sistema che accumula informazioni non sta necessariamente imparando e un sistema che cambia continuamente non sta necessariamente migliorando. Il vero problema è progettare il meccanismo capace di distinguere queste cose.
Collegare un LLM a un’applicazione è ormai relativamente semplice.
Costruire un’applicazione capace di diventare migliore mentre viene utilizzata, senza trasformare l’essere umano nel dipartimento di controllo qualità dell’AI, è un problema molto più interessante.
Il vero prodotto non è il modello
Alla fine, credo che il punto sia proprio questo: stiamo attraversando una fase nella quale l’attenzione è quasi completamente concentrata sui modelli. Quale ragiona meglio, quale costa meno, quale ha il context window più grande, quale produce il risultato migliore.
Sono questioni importanti, ma credo che diventeranno progressivamente meno determinanti. I modelli cambieranno, miglioreranno e, soprattutto, saranno disponibili più o meno a tutti.
Quello che non sarà uguale per tutti è ciò che avremo costruito intorno a quei modelli.
Un’applicazione AI non dovrebbe essere progettata pensando soltanto a quello che il modello è capace di fare oggi. Dovrebbe essere progettata pensando a ciò che il sistema sarà capace di imparare domani, a come valuterà quello che ha imparato e a come utilizzerà quella conoscenza senza perdere il controllo del processo.
Ed è qui che, per me, l’harness smette di essere una componente tecnica e diventa parte del prodotto stesso.
Perché il vero vantaggio non consiste nell’avere un’AI che produce una risposta migliore. Consiste nell’avere un sistema che osserva ciò che accade, raccoglie evidenze, verifica i propri risultati e diventa progressivamente più adatto al contesto nel quale viene utilizzato.
Ma c’è un’ultima condizione che considero fondamentale.
Se per ottenere tutto questo dobbiamo trasformare l’essere umano nel supervisore permanente dell’AI, abbiamo semplicemente automatizzato la parte sbagliata del lavoro.
L’obiettivo dovrebbe essere esattamente l’opposto: lasciare alle persone l’intenzione, la creatività, il giudizio e la decisione, e costruire macchine capaci di occuparsi sempre meglio di tutto il lavoro necessario per supportarle.
Forse è proprio questo il cambiamento di prospettiva che ci manca.
Non chiederci soltanto “cosa può fare l’AI al posto nostro?”, ma “quale parte del lavoro vogliamo davvero smettere di fare noi?”.
Per me, è da questa domanda che dovrebbe cominciare la progettazione di un’applicazione AI.