L‘intelligenza artificiale sta rapidamente divenendo una “primitiva” sempre più diffusa nella realizzazione di sistemi software e le sue capacità sono anche accessibili mediante API e strumenti software dedicati.
Indice degli argomenti
OpenAI Dev Day 2024
L’ultima importante evoluzione del fenomeno si è visto nell’OpenAI Dev Day 2024 di questa settimana, con annunci relativi agli sviluppatori che programmano sistemi basati sui modelli Gpt.
Vediamo in cosa consistono questi annunci di OpenAI a cui è rapidamente seguito un annuncio su una nuova modalità di interazione chiamata “Canvas” questa volta però integrata in ChatGPT.
L’importanza delle API
Ma prima di tutto, perché questo sviluppo è importante? Per due motivi.
- Recentemente ad un evento IT parlando con vari amministratori mi è apparso evidente come le API dell’IA siano già parte di sistemi e si stiano rapidamente diffondendo grazie al vantaggio competitivo che il loro impiego assicura rispetto a sistemi precedenti.
- Le API, inoltre, ci permettono di osservare questi sistemi nella forma più vicina alla realtà perché spogliati di strati di software sempre più corposi costruiti sopra di loro per fornire le interfacce a cui ci siamo rapidamente abituati.
Gli annunci del DevDay 2024
OpenAI ha annunciato quattro novità durante l’evento:
- la nuova Realtime API disegnata per realizzare sistemi interattivi multimodali come quelli mostrati a maggio durante il lancio di GPT-4o
- un nuovo modello di caching dei prompt
- il supporto alla distillazione di modelli partendo dai loro modelli
- l’abilità di raffinare (fine tune) il modello vision fornendo immagini di un dominio specifico
La real time API
Questa nuova API rappresenta l’annuncio forse più importante dell’intero evento: si tratta dell’API che OpenAI stessa usa nell’implementazione del nuovo modello di voce avanzata che, come abbiamo visto, offre un’interazione decisamente più naturale con l’intelligenza artificiale.
Lasciando i dettagli tecnici alla documentazione, cerchiamo invece di capire cosa introduce questa nuova API e perché si rende necessaria. L’API dominante che ormai tutti usano è la completion API: in sostanza si presenta all’API una struttura data che contiene una sequenza di messaggi etichettati come “system”, “assistant”, e “user” e il contenuto per fornire gli aspetti rilevanti di una conversazione chiedendo come risultato il prossimo messaggio all’AI. Poiché la risposta può richiedere più tempo di quanto un utente del Web oggi sia disposto ad aspettare OpenAI ha introdotto l’uso degli eventi Web per mandare i frammenti della risposta mentre viene ancora calcolare e che vengono visualizzati dal browser incrementalmente esibendo il comportamento “macchina da scrivere” a cui ci siamo rapidamente abituati.
In effetti quindi l’interazione attuale è:
- Viene preparata la richiesta
- Si riceve la risposta
- Si fa una nuova richiesta
- …
L’interruzione della risposta dell’AI, sebbene possibile, non informa l’AI dell’evento, rendendo l’interazione un po’ rigida come molti hanno scoperto cercando di parlare con GPT. Quello che colpisce della modalità voce avanzata invece è la naturale interruzione di un interlocutore con un altro che recepisce e si adatta naturalmente al flusso dell’interazione. Se questo è importante in un dialogo è sicuramente essenziale se insieme al dialogo si deve considerare un flusso video che riprende il mondo reale (a cui difficilmente si può chiedere di ripetere qualcosa).
Inoltre, nella modalità voce avanzata viene inviato l’audio al modello, non viene trascritto prima da un modello, si tratta quindi di un’interazione direttamente audio e non testuale (i nuovi modelli si dicono multimodali esattamente per questo motivo).
Ecco, quindi, che la natura stessa dell’interazione rende la completion API un po’ limitata da cui la necessità di disporre di una nuova API capace di catturare questo tipo di interazione “in tempo reale”.
La nuova API cambia la struttura di interazione con il servizio: si apre infatti un Web Socket, ovverosia un canale con il server che consente di scambiarsi messaggi simili al seguente:
Questo consente di inviare al modello sequenze di messaggi contenenti flussi non solo testuali ma anche audio e video continuamente. Il modello manderà indietro altrettanti eventi con il risultato dell’elaborazione. È quindi evidente come si perda la sequenzialità tipica dell’interazione in stile chat, e si passi ad un’interazione più tipica del mondo reale in cui molti canali di informazione inviano informazione simultaneamente all’AI che risponde in accordo agli stimoli che riceve.
Resta da capire se i sistemi open recepiranno anche questa nuova API per supportare i modelli multimodali open. Se così fosse OpenAI consoliderebbe la propria posizione di standard de facto nella definizione dell’accesso ai servizi di AI incoraggiando sempre più sviluppatori ad usare le sue API per evitare di essere lock-in assicurandosi la possibilità di cambiare il servizio usato nel tempo. Se così fosse anche big come Google e Anthropic dovrebbero considerare di fornire, magari in aggiunta alle proprie, il supporto a queste API.
Nuovo modello caching del prompt
Notevole anche il nuovo modello di caching del prompt. La diffusione dei sistemi RAG tende infatti a produrre prompt il cui prefisso è sempre lo stesso, e data la natura del processo sequenziale di generazione degli LLM è naturale per chi industrializza un servizio conservare la parte comune del calcolo in modo da ridurre i costi computazionali ed accelerare i tempi di esecuzione.
I benefici sono per tutti: OpenAI aumenta la propria capacità di servire richieste diminuendo il carico computazionale, e chi usa il servizio riduce i costi ed ottiene risposte più rapide. L’aspetto forse più importante è che la funzione è trasparente per chi usa le API, ma rappresenta anche una linea di indirizzo per chi scrive i prompt usati mediante l’API: la loro organizzazione che favorisce un prefisso comune assicura costi minori e più efficienza.
Io, ad esempio, sto rivedendo il codice di Oraculum per assicurarmi che i fatti inseriti nel prompt siano, se possibile, mantenuti nello stesso ordine anticipando nel prompt quelli che vivranno più a lungo per massimizzare questo effetto.
Il canvas
Per non farci annoiare OpenAI ha subito dopo annunciato Canvas, una nuova modalità di interazione con ChatGPT. Si tratta di una nuova modalità di interazione con l’AI meno orientata alla conversazione e più rivolta alla co-scrittura di testo o codice. Assomiglia molto ad una modalità già annunciata da Satya Nadella nella seconda ondata di Copilot e che ricorda strumenti simili a OneNote ma molto smart.
In attesa della possibilità di provarlo val la pena di notare fin da subito che il suo arrivo potrebbe mettere in discussioni sistemi di scrittura orientati al Web come Google Docs o Word online, mettendo al centro della scrittura l’interazione creativa con l’AI.
Sembra essere una buona idea, vediamo se l’implementazione sarà altrettanto convincente.
Le implicazioni per tutti noi
Solo un anno fa si parlava della professione del “prompt engineer”, oggi è abbastanza evidente che è la macchina stessa a svolgere quel ruolo, e in modo sempre più sofisticato come ci ha recentemente mostrato il modello o1 di OpenAI.
Non che il prompt inserito da un utente non abbia la sua rilevanza, ma è evidente, almeno a me, che non è così cruciale da caratterizzare addirittura una professione. Il prompt engineering sta invece divenendo un’abilità per programmatori: il modello di programmazione RAG è ormai pervasivo visto che abbiamo imparato che fornire informazioni al modello nel prompt è un ottimo modo per ridurre il rischio di allucinazioni e consente di usare le abilità dei modelli su dati freschi. Si stanno diffondendo quindi strumenti e teorie su come strutturare i prompt al fine di ottenere gli output desiderati minimizzando al tempo stesso le sue dimensioni per incrementare le prestazioni e ridurre i costi.
È quindi essenziale di quando in quando, anche se non si è esperti, dare un’occhiata alle API: rivelano molti aspetti interessanti sul funzionamento di questi sistemi. Una API deve essere il più possibile prevedibile anche se nell’AI generativa è intrinseco un aspetto stocastico che non garantisce lo stesso output a parità di input, ma in ogni caso ci si aspetta un certo grado di prevedibilità nel suo comportamento, è quindi naturale che sia più vicina al modello stesso con meno comportamenti “smart” rispetto a quelli mediati nell’interfaccia di un chatbot.
Api di Open AI diventano uno standard?
Le API di OpenAI, almeno per ora, sono ancora più interessanti da osservare, sono infatti state implementate da molti sistemi open source come, ad esempio, ollama e LM Studio, e consentono quindi l’accesso non solo ai modelli di OpenAI (con tutte le relative implicazioni sull’uso di un servizio) ma anche a molti modelli open sviluppati dalla comunità. Si potrebbe arrivare a dire che queste API stanno, almeno in parte, divenendo uno standard de facto che aiutano a sviluppare sistemi che non dipendano da una particolare classe di modelli.
Sembra ancora una volta che OpenAI prosegua nel seguire una propria vision che tende ad imporre agli altri che non possono che inseguire. Ad ogni annuncio sembra che molte considerazioni fatte non più di un anno fa siano già obsolete, non solo figure mai nate come il prompt engineer.
L’AI act stesso sembra decisamente meno efficace nel trattare con una visione multi-modale che la real time API lascia intravedere in cui il modello assomiglia sempre più al nostro cervello nella capacità di ricevere stimolazioni dall’ambiente esterno e risponda ad esse, siano essi flussi audio/video o testuali. E in questa visione lo spazio per una AI come un enorme indice di informazioni testuali sembra ridursi rapidamente, senza però eliminare, anzi forse acuendo, i problemi sostanziali come “informazione vera” o “rispetto della privacy”.
