OpenAI API: quando l'AI diventa un componente software

A giugno OpenAI ha annunciato una nuova API per accedere ai propri modelli di intelligenza artificiale. Detta così può sembrare una notizia per addetti ai lavori. Le API di servizi di intelligenza artificiale esistono già: possiamo mandare un'immagine a un servizio di riconoscimento, un testo a un traduttore automatico, un file audio a un sistema di trascrizione. Quello che mi sembra interessante nell'annuncio di OpenAI è un'altra cosa. L'azienda descrive la propria API come un'interfaccia general purpose “text in, text out”: inviamo del testo e riceviamo del testo, ma il compito non è fissato una volta per tutte dal servizio.

In questo momento l'API utilizza modelli della famiglia GPT-3 e l'accesso è ancora in private beta, quindi non stiamo parlando di un servizio maturo e disponibile liberamente a chiunque. Però l'idea merita attenzione.

La novità non è avere un'altra API di intelligenza artificiale. È poter provare a risolvere problemi diversi usando lo stesso modello e la stessa interfaccia software.

Dal servizio specializzato al modello general purpose

Molti servizi cloud di intelligenza artificiale che utilizziamo oggi espongono una funzione precisa. Invio una fotografia e provo a riconoscere gli oggetti. Invio una registrazione e ottengo una trascrizione. Invio una frase e ottengo una traduzione. L'interfaccia software può essere molto semplice, ma la funzione del modello è già stata decisa da chi offre il servizio.

Con l'API presentata da OpenAI il rapporto cambia.

La differenza concettuale: più servizi specializzati contro un modello general purpose richiamabile attraverso testo.

GPT-3 è stato presentato a maggio nel paper Language Models are Few-Shot Learners. È un modello linguistico con 175 miliardi di parametri e uno degli aspetti su cui OpenAI insiste è la capacità di affrontare compiti differenti senza dover addestrare ogni volta da zero un modello specializzato. Non significa che faccia tutto bene. Significa che il confine tra “funzione del software” e “comportamento del modello” diventa più interessante.

Un nuovo modo di dire al software cosa vogliamo

L'API riceve un testo, che OpenAI chiama prompt, e restituisce un completamento cercando di proseguire secondo il pattern che ha ricevuto. La parte curiosa, almeno per chi sviluppa software, è che il comportamento può essere indirizzato anche mostrando alcuni esempi direttamente nel testo inviato. Un esempio molto semplificato potrebbe essere:

ottimo servizio -> positivo
esperienza pessima -> negativo
tornerò sicuramente ->

e chiedere al modello di completare il pattern.

Invece di codificare tutte le regole, in alcuni casi possiamo descrivere il comportamento attraverso testo ed esempi.

Ovviamente un esempio del genere non dimostra che possiamo sostituire con tre righe qualsiasi sistema di classificazione. La cosa interessante è il meccanismo. Fino ad oggi, quando scriviamo un'applicazione, siamo abituati a descrivere il comportamento soprattutto attraverso codice, regole, dati strutturati e algoritmi. Qui una parte del comportamento viene invece specificata attraverso il linguaggio naturale e gli esempi forniti al modello.

Se questa impostazione funzionerà bene in produzione, il testo che inviamo al modello diventerà a tutti gli effetti una parte dell'architettura dell'applicazione.

Per uno sviluppatore cambia soprattutto il costo dell'esperimento

Per utilizzare tecniche avanzate di elaborazione del linguaggio normalmente servono competenze specifiche, dataset, modelli, infrastruttura e tempo. Un'API general purpose cambia soprattutto il costo iniziale per provare un'idea. Non devo necessariamente partire costruendo tutta la parte di machine learning. Posso prima capire se il comportamento del modello è abbastanza interessante per il problema che sto cercando di risolvere. Per esempio, in linea teorica, potrei sperimentare su:

• classificazione di testi;
• estrazione o trasformazione di informazioni;
• generazione di bozze;
• completamento di contenuti;
• risposte costruite a partire da esempi;
• interfacce nelle quali l'utente esprime una richiesta in linguaggio naturale.

Non tutte queste prove diventeranno un prodotto. Ma ridurre il costo dell'esperimento cambia il numero di esperimenti che possiamo permetterci di fare. Ed è spesso da lì che nascono nuove applicazioni.

Ma un'API non trasforma l'AI in una funzione deterministica

Qui arriva la parte che secondo me è più importante. Per uno sviluppatore una chiamata API assomiglia, esternamente, a qualsiasi altra chiamata API. Invio dei dati. Ricevo una risposta. Questo può creare una falsa sensazione di familiarità.

Se chiamo un servizio per sapere l'aliquota IVA associata a un codice, mi aspetto una risposta deterministica. Un modello linguistico non funziona nello stesso modo. Produce testo sulla base dei pattern appresi e dell'input ricevuto. Il fatto che una risposta sia scritta bene non significa automaticamente che sia corretta. Lo stesso prompt può inoltre richiedere prove, esempi e controlli prima di produrre risultati abbastanza affidabili per uno specifico caso d'uso. OpenAI stessa scrive che il successo varia in base alla complessità del compito.

Quindi l'applicazione che utilizza il modello non può limitarsi a dire:

risposta = AI(domanda)

e considerare chiuso il problema. Bisogna decidere dove il risultato può essere usato direttamente, dove va controllato e cosa deve succedere quando il modello sbaglia.

L'intelligenza artificiale entra nell'architettura del software

Questa è forse la parte che trovo più interessante. Finora abbiamo spesso parlato di intelligenza artificiale come di un prodotto separato. “Facciamo un progetto di AI.” “Usiamo il machine learning.” “Costruiamo un modello.”

Un'API come questa suggerisce invece uno scenario diverso: l'intelligenza artificiale può diventare uno dei componenti di un'applicazione, esattamente come lo sono un database, un servizio di pagamento o un motore di ricerca. Con una differenza sostanziale. Un database deve restituire il dato che gli abbiamo chiesto. Un pagamento deve avere uno stato preciso. Un modello linguistico restituisce qualcosa che dobbiamo interpretare.

Questo significa che dobbiamo progettare anche ciò che gli sta intorno. Validazione. Logging. Controllo degli errori. Eventuale revisione umana. Gestione dei dati inviati. Limiti all'utilizzo. Fallback quando il risultato non è accettabile.

Integrare un modello intelligente non elimina la necessità di progettare il software. Aggiunge un componente meno prevedibile, e quindi aumenta l'importanza di ciò che gli costruiamo attorno.

Ci sono anche limiti che non sono tecnici

OpenAI ha scelto di lanciare l'API come private beta anche per studiarne gli utilizzi e i possibili abusi. Nel proprio annuncio parla esplicitamente di bias, spam, molestie, radicalizzazione e altri usi dannosi, e prevede la possibilità di interrompere l'accesso per alcuni casi. Non è un dettaglio marginale. Quando una funzionalità viene incorporata tramite API dentro un nostro prodotto, la responsabilità del risultato non sparisce perché una parte dell'elaborazione avviene sui server di qualcun altro. Dobbiamo sapere:

• quali dati inviamo;
• quali risultati mostriamo agli utenti;
• quali controlli facciamo;
• cosa registriamo;
• come interveniamo quando il comportamento non è quello previsto.

È un problema tecnico, ma anche progettuale.

Non so ancora dove ci porterà

È troppo presto per sapere quanto questa strada diventerà importante. L'accesso è limitato. Il modello lavora soprattutto sul testo inglese. I risultati variano molto in base al compito. E molte delle applicazioni che oggi sembrano impressionanti potrebbero rivelarsi semplici dimostrazioni.

Ma c'è un cambiamento che vale la pena osservare già adesso. Per provare ad aggiungere a un software una capacità legata al linguaggio naturale, potrebbe non essere più necessario cominciare costruendo un modello dedicato. Potremmo cominciare da una chiamata API. E per chi sviluppa software questa non è una differenza piccola. Significa che una tecnologia che fino a ieri richiedeva un progetto specialistico può iniziare a presentarsi come un componente da sperimentare, misurare e integrare.

Non sappiamo ancora quali applicazioni diventeranno davvero utili. Ma vale la pena iniziare a fare una domanda: se il software riesce a lavorare con il linguaggio naturale attraverso una semplice API, quali problemi che oggi risolviamo con regole rigide potremmo affrontare in modo diverso?