Attraversare la crepa dell’IA come OpenAI ha trasformato gli LLM in un successo di massa

Come OpenAI ha rivoluzionato gli LLM Trasformando il Nostro Modo di Frantumare il Vetro dell'Intelligenza Artificiale

E perché LLMOps subirà la stessa sorte di MLOps

Sono sempre stato uno scettico vocale riguardo alla fattibilità degli strumenti per sviluppatori di intelligenza artificiale (generalmente catalogati come MLOps) come business autonomi e, ad eccezione di poche eccezioni, ho avuto ragione. La mancanza di un design dominante ha portato a “micro-mercati” frammentati con un valore molto basso, principalmente a causa delle alternative open source e dei fornitori di cloud che offrono gratuitamente i loro strumenti di intelligenza artificiale (per guadagnare sul livello di infrastruttura). Quindi, cosa ha portato i LLM ad ignorare questi problemi, ricevere grande attenzione mediatica e ottenere una vera adozione diffusa? E cosa succederà a tutte le startup che cercano di applicare le strategie di MLOps ai LLM, ricommercializzandosi come LLMOps?

In questo articolo userò la teoria della “diffusione dell’innovazione” e il concetto di “attraversare il baratro” (crossing the chasm) nel tentativo di spiegare le mie aspettative positive sui fornitori di LLM come OpenAI o Anthropic, e il mio punto di vista negativo riguardo al tentativo di riportare in vita i MLOps come LLMOps.

L’adozione delle innovazioni e il baratro

Secondo la “diffusione delle innovazioni” di Everett Rogers, i prodotti innovativi sono adottati progressivamente da diversi gruppi di adottanti con caratteristiche distinte. Gli Innovatori, che sono disposti a correre rischi e hanno una grande tolleranza al fallimento, sono i primi a provare un nuovo prodotto. Gli Indietro, che sono avversi al cambiamento, sono gli ultimi. Il famoso grafico a forma di campana mostra la percentuale di adottanti in ogni categoria, e il grafico cumulativo di adozione assomiglia allo schema a “S” familiare della quota di mercato di un’innovazione nel tempo.

Immagine dello scrittore (modificata dalla fonte)

L’idea di base è che ogni gruppo sia influenzato da segnali e comportamenti dei gruppi precedenti, basandosi sulla prova sociale per informare la loro decisione di adottare un nuovo prodotto. Questo è un fenomeno ben compreso e documentato empiricamente, osservato in tutto, dai condizionatori d’aria per finestra ai telefoni iPhone.

Il “baratro” è un concetto reso popolare dal libro “Attraversare il Baratro” di Geoffrey A. Moore che si basa sulla teoria di Rogers. Moore sostiene che le differenze tra i mercati iniziali e quelli di massa siano troppo grandi e che la maggior parte dei prodotti fallisca nel tentativo di superare quel “baratro”, che è una modalità di fallimento piuttosto comune nelle startup tecnologiche.

Immagine dello scrittore (modificata dalla fonte)

Anche se Rogers ha criticato il concetto di baratro dicendo che la diffusione dell’innovazione è un “processo sociale” senza “rotture o discontinuità nette tra categorie di adottanti adiacenti”, è evidente che molti prodotti non raggiungono il grande pubblico perché non riescono a superare il gruppo degli Innovatori.

Moore fornisce diversi suggerimenti su come superare il baratro, con cui concordo solo in parte. Una delle osservazioni è che, con le sue stesse parole, il suo libro tratta principalmente il baratro “come un problema di sviluppo del mercato” e si concentra “su strategie e tattiche di marketing per superarlo”. Copre l’idea della “gestione del prodotto completo”, ma basandosi sulla sua lettura di “The Marketing Imagination” di Theodore Levitt, tale concetto si limita a colmare il divario tra il messaggio di marketing e la verità del prodotto con “servizi e prodotti accessori”. Non affronta l’effettiva evoluzione del prodotto. In realtà, l’innovazione (o il prodotto principale) è considerata costante.

Pensando alle caratteristiche specifiche del software (in particolare degli strumenti per sviluppatori), propongo due strategie (“evoluzione” e “salto”) per evitare il baratro e ipotizzo come la loro applicazione abbia contribuito a alimentare la rapida crescita delle LLM.

Due modi centrati sul prodotto per evitare il baratro

Evolvi (semplifica) i tuoi strumenti per sviluppatori nel tempo

La limitazione del prodotto come costante, mentre tutti gli altri aspetti del “prodotto completo” (come messaggistica, distribuzione, prezzi) cambiano per attirare diversi gruppi di utenti, è principalmente motivata dai prodotti fisici. Se ti occupi di produrre e vendere widget, modificare la catena di fornitura o ristrutturare le fabbriche non è una cosa banale da fare. Tuttavia, è una storia completamente diversa per i prodotti che sono esclusivamente software. Non far evolvere il tuo prodotto software è quasi sempre una ricetta per il fallimento.

La necessità di evolvere dovrebbe essere ovvia sulla base di come la maggior parte delle startup di software inizia in questi giorni. Molto spesso, gli strumenti per sviluppatori (specialmente nell’ambito dell’IA) nascono e vengono coltivati all’interno di una base di utenti forte e devota di esperti in un campo specifico. Non sorprende che questi primi utenti siano solitamente Innovatori e, come tali, non siano rappresentativi del mercato più ampio. È troppo facile per i fondatori dedicare tutto il loro tempo ed energia a questo segmento e modificare i loro prodotti sulla base dei loro feedback. Purtroppo, il successo commerciale di solito non si trova in quei primi gruppi. Gli Innovatori sono molto sofisticati e spesso preferiscono costruire anziché acquistare. Anche se decidessero di acquistare, non rappresenterebbero un mercato abbastanza grande.

Una soluzione a questo problema è evolvere il prodotto nel tempo per diversi target di utenza. Con strumenti per sviluppatori ben progettati, ciò significa introdurre nuovi livelli di astrazione e/o supportare linguaggi più ampiamente utilizzati. Prendendo ad esempio il mio ex datore di lavoro, il successo continuo di Spark è (almeno secondo me) in parte dovuto al fatto che la superficie del prodotto è stata continuamente semplificata per attrarre una gamma più ampia di utenti (oserei dire la “Early Majority”?). Spark ha iniziato con RDD (Resilient Distributed Datasets) e Scala come suo principale linguaggio di programmazione. Poi ha ampliato il supporto ai linguaggi con Python e PySpark (aprendosi a un gruppo più ampio di ingegneri software) e ha introdotto API più semplici come DataFrame e SparkSQL (aprendosi agli analisti SQL). Più di recente, Spark ha aggiunto un’API compatibile con Pandas (aprendosi agli scienziati dei dati) e ha persino introdotto un “SDK in inglese” utilizzando LLMs (aprendosi, beh, a chiunque conosca l’inglese). Se Spark non si fosse evoluto in questo modo, sarebbe rimasto bloccato nel segmento degli Innovatori che sanno come scrivere programmi MapReduce complessi in Scala.

Immagine dell'autore

Questa strategia sembra ovvia, ma non molti prodotti tecnologici (specialmente nell’ambito degli strumenti per sviluppatori) la mettono in pratica correttamente. A volte “semplificano” il prodotto rimuovendo alcune opzioni, ma non introducono nuovi livelli di astrazione che non siano permeabili.

Salta completamente il baratro

Un altro approccio, meno comune negli strumenti per sviluppatori, è saltare completamente il baratro. L’idea è ingannevolmente semplice: se il successo nel mercato iniziale non si traduce automaticamente in successo nel mercato mainstream, perché non puntare direttamente alla Early Majority?

Come accennato in precedenza, ciò è più importante nell’hardware, dove le iterazioni su un prodotto sono più lente, più costose e di conseguenza il prodotto principale non può evolversi facilmente. L’iPhone è un ottimo esempio di un prodotto che viene spesso criticato dagli Innovatori (addirittura l’iPhone 15 e la sua “deludente” porta USB-C) ma ha ottenuto un rapido successo con l’Early Majority che non si preoccupava di questi dettagli tecnici. In effetti, Apple insegna ripetutamente all’industria una lezione magistrale su questa strategia con la loro messaggistica. Probabilmente l’esempio più famoso è la campagna “1,000 brani in tasca”, rivolta all’Early Majority e non agli Innovatori che si preoccupano delle specifiche tecniche.

Immagine dell'autore

Questo sembra innaturale per molte startup del settore tecnologico (specialmente quelle che si concentrano sugli strumenti per sviluppatori) perché è troppo facile ottenere successo iniziale con gli innovatori e gli early adopter. Gli strumenti per sviluppatori di intelligenza artificiale iniziano nel mercato iniziale quasi per definizione, poiché di solito vengono creati da e per ricercatori avanzati di intelligenza artificiale o ingegneri di machine learning. La pratica di “proving product<>market fit”, misurata dalle stelle di GitHub, attraverso la condivisione di un progetto open source, rafforza solo questa idea.

Strategie comuni che falliscono nella commercializzazione di progetti open source

Ho visto abbastanza “progetti open source trasformati in startup” da avere almeno un certo grado di “riconoscimento di schemi” per modalità di fallimento comuni. Queste startup trovano successo iniziale (e finanziamenti) quando sperimentano una crescente adozione, misurata dalle stelle di GitHub o dai download di PyPI. Poi, tragicamente, seguono percorsi simili, talvolta anche se c’è un fondatore esperto che “l’ha già fatto” (perché in realtà non capiscono perché le loro aziende precedenti hanno avuto successo).

Immagine dell'autore

Offrire Innovatori: Intuitivamente (o ingenuamente?), la maggior parte delle startup tenta per prima di offrire agli Innovatori una versione “gestita” del prodotto open source. Questa strategia di solito non ha successo perché gli Innovatori iniziali, per definizione, sono molto sofisticati e preferiscono costruire invece di acquistare. La generica strategia 3S (gestione OSS + stabilità, scalabilità, sicurezza) non è sufficiente per giustificare un pagamento da parte di questo pubblico, poiché già sanno come costruire e gestire i servizi da soli. Gli Innovatori temono anche la “vincolazione al fornitore” e la perdita della loro capacità di innovare in modo indipendente.

Sfasamento tra prodotto e mercato: Il secondo tentativo consiste nel vendere lo stesso prodotto “Managed OSS” alla Early Majority. Di solito, questo fallisce perché l’offerta principale è ancora lo stesso prodotto difficile da usare che è stato ottimizzato per gli Innovatori. Aggiungere solo 3S non è sufficiente per incentivare la Early Majority a sviluppare competenze (come in alcuni piani per formare milioni di ingegneri di machine learning per forzare l’esistenza del mercato MLOps). Se ciò non fosse sufficiente, il colpo di grazia è che nessuno batte AWS in questo settore (ed è anche il motivo per cui sempre più progetti open source di infrastrutture passano a licenze non commerciali).

“Prodotto completo”: Chiamo sarcasticamente questa strategia “prodotto completo”, perché questo termine è stato frainteso per colmare lacune fondamentali del prodotto con mezzi subottimali. Questo tentativo di solito segue la consapevolezza che il prodotto principale è troppo difficile da usare per un mercato più ampio e la soluzione prevede comunemente il “lancio di umani al problema”. Questo porta a un’elevata componente di servizio nella struttura di reddito di una startup (che nessun investitore ama vedere) e a organizzazioni di distribuzione ingrossate. Va detto che una certa quantità di questo è necessaria, specialmente nel segmento aziendale o federale. Ma, più spesso che no, la startup comincia a sembrare una società di consulenza tecnologica.

Un approccio ibrido per gli strumenti per sviluppatori

La strategia che propongo è un approccio ibrido che consente comunque una rapida iterazione con una base di utenti devoti di Innovatori, ma riconosce le differenze fondamentali nei mercati iniziali e di massa concentrandosi esplicitamente sulla Early Majority nella definizione del prodotto.

Dimostrare il successo iniziale con gli Innovatori attraverso l’open source non deve essere in contrasto con la ricerca di una sostenibilità commerciale con la Early Majority, se si riconosce che richiedono prodotti diversi. In particolare, suggerisco di:

  1. Utilizzare il tuo progetto open source per guadagnare popolarità tra gli Innovatori
  2. Utilizzare questa popolarità per ottenere finanziamenti
  3. Utilizzare il gruppo degli Innovatori per scoprire come stanno creando valore a valle e per chi
  4. Indirizzare il tuo prodotto di massa a quel pubblico

Qui è dove la Diffusione dell’Innovazione per il software differisce dall’hardware di consumo come gli iPhone: L’idea chiave è che nella catena del valore del software, gli Innovatori spesso fungono da intermediari verso la Early Majority. In altre parole, gli Innovatori stessi non sono la fine della catena del valore. Consumano tecnologia per aiutare team di prodotto/aziendali a creare valore. A volte questo avviene tramite un “Centro di Eccellenza” o un “Team di Innovazione” centralizzato. L’obiettivo di una startup tecnologica dovrebbe essere di capire chi si trova nella catena del valore dopo quegli Innovatori, perché è lì che troveranno la chiave per coinvolgere la Early Majority. In modo critico, non sto dicendo che dovresti cercare di disintermediare quegli Innovatori nelle organizzazioni in cui esistono, perché ciò di solito genera reazioni negative. In quei casi, devi farli diventare i tuoi “campioni”.

L’obiettivo di una startup tecnologica dovrebbe essere quello di capire chi si trova nella catena del valore dopo gli Innovatori, dove troveranno la chiave per l’Early Majority.

L’implicazione principale della strategia “salta” è prendere una decisione esplicita durante la definizione del prodotto per affrontare l’Early Majority. Da notare che questa è diversa dalla strategia “evolvi” nel senso che il “prodotto di massa” potrebbe non essere semplicemente una versione più facile del tuo prodotto originale, ma potrebbe avere una forma completamente diversa. I due estremi di questa forma diversa sono:

  1. Un livello di astrazione più elevato rispetto al progetto OSS originale, in un fattore di forma diverso. Anche se imperfetto, Databricks fornisce un altro esempio di questo. Il prodotto innovativo che ha suscitato interesse iniziale al di fuori del gruppo degli Innovatori non era solo “Spark gestito”, ma un prodotto Notebook gestito per Data Scientist e Ingegneri (che, in quel momento, era piuttosto innovativo). Databricks continua a seguire la stessa strategia oggi con prodotti come Databricks SQL.
  2. Un prodotto verticalizzato più focalizzato nella catena del valore. Stripe è un ottimo esempio, in quanto originariamente hanno iniziato con una libreria di elaborazione dei pagamenti open source e poi hanno trovato successo con prodotti come Checkout (un modulo di pagamento completo per i siti web) o Terminal (terminale di pagamento al punto vendita).

Come MLOps non è riuscito ad evolversi e LLMs ha saltato l’abisso

MLOps è rimasto bloccato nel mercato iniziale

Una storia simile a quella che ho condiviso sull’evoluzione di Spark non può essere raccontata sul ML. Lo stack di MLOps sembra praticamente lo stesso di qualche anno fa, e la speranza nel mercato è che sempre più ingegneri imparino ad usarlo.

Senza soffermarsi su come siamo arrivati qui, voglio solo riassumere brevemente la mia opinione sullo stato del mercato di MLOps:

  • Il mercato di MLOps non si è convergenza su un “design dominante” e, di conseguenza, ogni “piattaforma MLOps” che troverai è diversa in modi ovvi e sottili.
  • A livello di sistemi, il mercato di MLOps non ha prodotto una “forma” più semplice o livelli di astrazione, quindi è ancora proibitivamente complesso e richiede vari ruoli specializzati (Data Engineer, Data Scientist, ML Engineer, ecc.) che sono prevalenti solo nelle aziende tecnologiche più avanzate.
  • L’audience che può consumare questa tecnologia, ovvero Innovatori e Early Adopters, preferisce vivere sul filo del rasoio e utilizzare strumenti open source invece di pagare un fornitore.
  • L’audience che sarebbe disposta a pagare un fornitore di solito si affida a quello che i principali fornitori di servizi cloud offrono. I fornitori cloud forniscono gratuitamente il livello di piattaforma “ML” e si concentrano sul guadagnare ricavi tramite storage e calcolo.
  • Dato che i fornitori cloud non hanno monetizzato esplicitamente MLOps, la cattura del valore in questo mercato è stata minima.

In sintesi, MLOps è caduto nell’abisso e non c’è segno che stia riemergendo dall’altro lato.

L’appeal dell’Early Majority di LLMs

Entra in scena LLMs. OpenAI avrebbe raggiunto un fatturato annuo ricorrente di $1,3 miliardi e ci si aspetta che continui a crescere a un ritmo rapido, cosa che non si può dire delle startup di MLOps. In effetti, potresti sommare i ricavi delle prime 10 startup di MLOps e non arrivare nemmeno vicino. Ricorda che la maggior parte dei fornitori cloud non monetizza realmente questo livello al di fuori del costo di calcolo e archiviazione, quindi i loro ricavi “ML” non contano davvero (a meno che tu non voglia fare il business di fornire infrastrutture cloud a prezzi di commodity).

Sorge quindi la domanda, perché LLMs hanno raggiunto così rapidamente un grande successo? Sostengo che siano riusciti a saltare l’abisso in due segmenti molto diversi.

Saltare l’abisso nel segmento dei developer

I modelli ML tradizionali “discriminatori” sono addestrati per compiti molto specifici, come prevedere la qualità di un lead di vendita o classificare una lista di prodotti. Per ognuno di questi compiti, diversi esperti devono lavorare insieme per scrivere data pipeline, raccogliere etichette, raffinare “feature”, addestrare e ottimizzare modelli, valutarli, distribuirli, monitorarne le prestazioni e quindi riaddestrarli periodicamente. La necessità di ripetere tutto ciò per ogni compito, così come la quantità di competenze richieste per farlo, ha fatto sì che questo miracolo fosse raggiungibile solo da pochi eletti.”I modelli di linguaggio “generativi”, d’altra parte, “funzionano solo” per una vasta gamma di casi d’uso, permettendo a chiunque possa fare una chiamata API di applicare l’IA al proprio prodotto o problema. Quasi immediatamente, i LLM hanno risolto la carenza di talenti nel campo dell’IA applicata, dando a ogni ingegnere del software superpoteri di intelligenza artificiale. In modo critico, lo stesso LLM potrebbe generare poesie, scrivere codice, tradurre domande in linguaggio naturale in query SQL o superare una vasta gamma di test standardizzati. Questo funziona sia “immediatamente” (zero-shot), o semplicemente dando al modello alcuni esempi del problema che si desidera risolvere (few-shot) ed estende a una vasta gamma di modalità, non solo testo.

Immagine dell'autore

Questa è la definizione stessa di saltare il baratro e andare dritto verso la “Early Majority”.

È anche per questo motivo che LLMOps è destinato a ripetere la storia. Suppongo che se hai un martello, tutto sembra un chiodo. Inevitabilmente, una piccola industria è emersa intorno all’idea che tutti hanno bisogno di allenare e affinare i propri LLM, il che manca completamente il punto di partenza per cui i LLM sono stati così di successo. Ripristinare la complessità della scrittura delle pipeline dei dati, dell’allenamento e del miglioramento dei modelli propri, del loro dispiegamento, ecc., ti riporta al micro-mercato degli Innovatori che preferiscono costruire invece di comprare.

Da notare che non sto dicendo che nessuno debba affinare e dispiegare i propri LLM. In alcune circostanze molto specifiche (che sono poche) ha senso farlo. Ma nella maggior parte di queste circostanze ti troverai negli Innovatori e nei Precursori, e quei gruppi utilizzeranno semplicemente strumenti open source e non pagheranno un fornitore per il servizio.

Saltare il baratro nel segmento dei consumatori

OpenAI gioca in due segmenti molto diversi: il segmento degli sviluppatori, discusso sopra, è servito con API e capacità di calcolo dedicate. ChatGPT e le sue applicazioni mobili, d’altra parte, sono prodotti molto “consumer”. ChatGPT è famosamente uno dei prodotti che più velocemente ha raggiunto 1 milione di utenti (in 5 giorni) e, sebbene non ci sia una suddivisione ufficiale dei numeri di fatturato di OpenAI, una stima colloca il fatturato delle applicazioni mobili a 3 milioni di dollari al mese. Non sembra un prodotto che sia cresciuto lentamente attraverso il mercato iniziale, vero?

Nonostante il suo nome tecnico (GPT sta per Generative Pretrained Transformer), ChatGPT ha saltato direttamente verso la Early Majority, principalmente grazie al suo formato amichevole e facile da usare. Chiunque, dai giornalisti agli insegnanti o agli studenti, poteva accedervi gratuitamente ed esperire immediatamente il suo valore. Se OpenAI avesse semplicemente rilasciato un modello che gli ingegneri potevano chiamare tramite API REST, non avrebbe portato a una massiccia adozione da parte del grande pubblico.

La maggior parte degli dirigenti ti direbbe che dividere la tua attenzione tra due segmenti molto diversi è generalmente una cattiva idea. Tuttavia, potrei sostenere che il successo di ChatGPT presso i consumatori sia stato strumentale nel generare domanda nel segmento degli sviluppatori. Si scopre infatti che gli sviluppatori e gli acquirenti aziendali sono anche umani. Leggono le notizie, seguono le tendenze e provano i prodotti consumer. OpenAI, sia in modo intenzionale o meno, ha beneficiato di questo in diversi modi.

  • Il più ovvio è che la consapevolezza e il riconoscimento del marchio sono fondamentali per qualsiasi attività. Anche se OpenAI e i LLM erano già ben noti nella comunità di intelligenza artificiale, è stato necessario il successo di ChatGPT per farne un nome di marca per l’Early Majority nel segmento degli sviluppatori in generale.
  • Uno dei motivi per cui il “baratro” esiste in primo luogo è che l’Early Majority di solito è incline al rischio e non si fida dei segnali provenienti dagli Innovatori. Un modo per superare questo ostacolo è fornire loro un modo facile per sperimentare il prodotto. ChatGPT ha offerto l’esperienza di “prova gratuita” perfetta per i decisori non tecnici nella Early Majority.
  • Il modo più “tipico” per ottenere una crescita dei ricavi come OpenAI è assumere un team di vendita enterprise. Si scopre che l’approccio di crescita basato sulle vendite (Sales-Led-Growth, SLG) beneficia significativamente dai metodi consolidati del Product-Led-Growth (PLG), come l’accesso senza soluzione di continuità per sperimentare un prodotto. Gli acquirenti aziendali si aspettano sempre di “vedere e sperimentare il valore del prodotto prima di impegnarsi in un grande contratto”.

Conclusione

Ho iniziato questo post come un sequel naturale ai miei precedenti articoli sugli strumenti per lo sviluppo di intelligenze artificiali, perché sto assistendo a una ripetizione della storia di MLOps con LLMOps. Ma, scrivendo su come gli LLM abbiano saltato il baratro, mi sono reso conto che le lezioni potrebbero essere applicabili in modo più ampio.

Per i fornitori di LLM come OpenAI, Anthropic, ecc.: Non sono sicuro se queste aziende abbiano scoperto questa strategia per caso, ma se applicata intenzionalmente, ci sono sicuramente lezioni su come migliorare lo sviluppo del prodotto e GTM. Tuttavia, se sei in modalità di ipercrescita, c’è poco tempo o necessità di ottimizzazione.

Per chiunque faccia parte dell’ecosistema LLMOps: Ti invito a leggere i miei precedenti articoli sull’infrastruttura di intelligenze artificiali e vedrai perché penso che non ci sarà molto valore estratto da questo livello. Inoltre, credo che ci siano pochissimi casi in cui abbia senso affinare gli LLM, ma altri ne hanno già scritto abbondantemente.

Per le startup tech in generale: Ho visto enormi round di finanziamenti in startup basate su open source in cui l’ipotesi era “OSS gestito + scala, stabilità e sicurezza” o “open core e monetizzazione da definire in seguito”. Credo che l’idea di “saltare il baratro” sia preziosa qui e attendo con ansia i feedback sia dai fondatori che dagli investitori!

Le opinioni espresse in questo post sono personali e non rappresentano le opinioni del mio datore di lavoro.

Clemens è un leader imprenditoriale nel campo dei prodotti che ha trascorso gli ultimi 8+ anni portando l’AI agli sviluppatori e alle imprese.