Leader di pensiero

Perché il costo dei token non dice se l’IA aziendale sta funzionando

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

L’IA aziendale sta attraversando un ciclo già noto. All’inizio, le organizzazioni hanno puntato tutto sui modelli più grandi e capaci, entusiaste della tecnologia e prima ancora di ricevere il conto. Quando è arrivato, la reazione è stata altrettanto prevedibile: i team hanno iniziato a razionare l’accesso, ridurre la sperimentazione e cercare modelli meno costosi.

Ali Ghodsi, cofondatore e CEO di Databricks, ha descritto la fase iniziale di questo ciclo come «massimizzazione dei token», in cui consumare più token viene considerato un segnale di progresso. La fase più importante è quella della «massimizzazione del valore», che consiste nel capire che cosa produce quella spesa e indirizzarla verso le attività che contano.

Non si tratta semplicemente di un nuovo nome per l’ottimizzazione dei costi. L’ottimizzazione dei costi si chiede come un’organizzazione possa spendere meno, mentre la massimizzazione del valore si chiede come ottenere di più da quanto spende. Questa distinzione diventerà sempre più importante man mano che l’IA passerà dagli esperimenti isolati alle attività quotidiane delle aziende.

Il modello più grande non è sempre quello giusto

Molte organizzazioni hanno avviato i propri programmi di IA utilizzando il modello più potente disponibile per quasi tutte le attività. Questo approccio aveva senso nella fase iniziale di sperimentazione, quando i team cercavano di capire che cosa potesse fare la tecnologia e le capacità del modello contavano più della prevedibilità.

Con la crescita delle implementazioni, però, è diventato difficile giustificare il costo di un modello all’avanguardia per ogni richiesta. Alcune organizzazioni hanno reagito limitando l’accesso o chiedendo ai team di fare meno, ma restrizioni generalizzate possono soffocare la sperimentazione utile insieme agli sprechi effettivi.

Sta emergendo un approccio più maturo. I team iniziano ad abbinare modelli più piccoli e specializzati alle attività di routine, riservando quelli più capaci ai compiti che richiedono ragionamenti complessi o comportano un costo elevato in caso di errore. Nel tempo, alcune organizzazioni potrebbero anche implementare modelli sulla propria infrastruttura, per avere un maggiore controllo sui costi, sulle prestazioni e sui dati sensibili.

La domanda importante non è se sia meglio un modello grande o piccolo, ma se il modello sia adatto al lavoro da svolgere e se il risultato giustifichi il costo totale necessario per ottenerlo.

I token indicano l’attività, non il valore

La maggior parte dei pannelli di controllo per l’IA aziendale si basa sui consumi. Indicano quanti token sono stati usati, quali modelli li hanno elaborati e quanto ha speso l’organizzazione. Questi dati sono necessari, ma non rivelano se il lavoro abbia prodotto un risultato utile.

Un team che consuma il doppio dei token non crea necessariamente il doppio del valore. Potrebbe occuparsi di attività più difficili, usare un modello più potente del necessario o affidarsi a un agente che riprova ripetutamente a eseguire attività non riuscite. Un carico di lavoro con costi elevati per i modelli può comunque rappresentare un ottimo investimento se previene le interruzioni del servizio, risolve i problemi dei clienti o restituisce ai dipendenti ore preziose.

Lo stesso problema si presenta da anni nell’osservabilità, solo che al posto dei token si parla di gigabyte. Inizialmente, i team raccoglievano tutto, perché la massima visibilità sembrava la strategia più sicura. Quando sono aumentate le spese di archiviazione ed elaborazione, hanno iniziato a campionare i dati, ridurre il periodo di conservazione ed eliminare informazioni contestuali per contenere i costi.

In entrambi i casi, spesso la reazione all’aumento dei costi è stata fare meno. Le organizzazioni hanno invece bisogno di poter individuare quali attività siano utili, quali siano uno spreco e quali possano diventare più efficienti senza compromettere il risultato.

Il costo reale va oltre l’inferenza

Una chiamata a un modello raramente rappresenta l’intero carico di lavoro dell’IA. Prima di produrre una risposta, un agente può recuperare documenti, interrogare un database, cercare dati di telemetria, chiamare servizi esterni e generare nuove attività nell’applicazione o nell’infrastruttura.

Si consideri un agente che indaga sul motivo per cui la latenza del checkout è aumentata dopo un’implementazione. Potrebbe esaminare i log, confrontare le metriche, analizzare le tracce, recuperare i record dell’implementazione e analizzare i servizi a valle. Se la sua prima ipotesi non trova conferma, potrebbe modificare l’intervallo temporale, cercare usando nomi di servizio diversi e seguire diverse cause alternative.

Una singola istruzione impartita da una persona può quindi generare centinaia di operazioni automatiche. Queste operazioni consumano capacità di calcolo, risorse di archiviazione per la lettura e la scrittura, capacità di rete e quote delle API di terze parti; nessuno di questi consumi potrebbe comparire nel pannello di controllo delle spese per i modelli dell’organizzazione.

Ciò significa che un modello apparentemente economico può essere alla base di un flusso di lavoro costoso. Un modello più capace potrebbe costare di più per chiamata, ma raggiungere la conclusione corretta in meno passaggi, richiedendo meno tentativi e meno infrastruttura di supporto. L’unico modo per fare questo confronto è osservare l’intera attività.

Collegare attività, costi e risultati

La massimizzazione del valore richiede che le organizzazioni colleghino tre tipi di informazioni che spesso vengono misurati separatamente.

Il primo elemento è l’attività dell’IA, che comprende la selezione dei modelli, il consumo di token, la latenza, le chiamate agli strumenti, i nuovi tentativi e i rami paralleli. Il secondo è il costo infrastrutturale e finanziario generato da tale attività, che include elaborazione, archiviazione, uso della rete, carico del database e costi delle API esterne. Il terzo è il risultato, che dovrebbe indicare se il lavoro è stato completato con successo e se qualcuno lo ha ritenuto utile.

Non è necessario tradurre ogni risultato in un importo esatto in dollari. Può bastare una misura pratica, per esempio verificare se una risposta è stata accettata, se qualcuno ha dovuto rifare il lavoro, se un incidente è stato risolto più rapidamente o se un flusso di lavoro automatizzato è stato completato senza interventi.

Per esempio, un’indagine su un incidente che genera centinaia di query può valerne la pena se aiuta gli ingegneri a ripristinare un servizio critico con 30 minuti di anticipo. Un flusso di lavoro molto più ridotto può comunque rivelarsi uno spreco se produce un rapporto che nessuno legge. Il solo consumo di token non permette di distinguere i due casi.

Una volta che le organizzazioni riescono a collegare l’attività ai risultati, possono decidere consapevolmente dove usare i modelli più avanzati, dove sono sufficienti modelli più piccoli e dove occorre riprogettare un flusso di lavoro.

La visibilità non dovrebbe richiedere di cedere il controllo

Per comprendere il valore dell’IA è necessario accedere a informazioni contestuali sensibili. Prompt, risposte generate, codice sorgente, informazioni sui clienti e telemetria degli ambienti di produzione possono far parte dello stesso flusso di lavoro.

Le organizzazioni non dovrebbero essere costrette a esportare queste informazioni verso un servizio esterno soltanto per capire come stanno funzionando i loro sistemi di IA. I prompt e il contesto degli ambienti di produzione che rendono utile la misurazione possono coincidere con le informazioni che i team di sicurezza, privacy e conformità non possono consentire di far uscire dall’ambiente dell’organizzazione.

I responsabili aziendali dovrebbero quindi chiedersi dove vengono elaborati i dati relativi all’IA e all’osservabilità, chi può accedervi, per quanto tempo vengono conservati e se l’analisi può essere svolta entro il perimetro di sicurezza già esistente. Una buona governance dipende dalla visibilità, ma questa non deve creare un nuovo problema di controllo dei dati.

Mantenere l’analisi vicino ai dati sottostanti facilita anche il collegamento tra l’attività dell’IA e le applicazioni, le infrastrutture e i processi aziendali su cui incide. Una visione completa di questo tipo consente ai team di capire non solo quanto hanno speso, ma anche quale ritorno ha generato la spesa.

Puntare sul valore, non sui volumi

Nella prossima fase dell’IA aziendale, le organizzazioni che avranno successo non saranno necessariamente quelle che usano più token o spendono meno. Saranno quelle capaci di individuare quali modelli e carichi di lavoro producono risultati significativi e di usare poi queste informazioni per orientare le implementazioni.

Per riuscirci, occorre superare i cruscotti che mostrano soltanto i costi dei singoli modelli. I team devono osservare l’intero percorso, dalla richiesta dell’utente alle chiamate ai modelli, agli strumenti, alle infrastrutture e al risultato finale, mantenendo al contempo le informazioni sensibili sotto un adeguato controllo organizzativo.

Tokenmaxxing è stata una fase utile, perché ha incoraggiato la sperimentazione e ha mostrato le potenzialità dell’IA. Valuemaxxing è la disciplina che deve seguirla: combina visibilità, costi e risultati, così che le organizzazioni possano continuare a sperimentare senza perdere il controllo della spesa o dei dati.

L’IA aziendale non deve diventare più limitata solo perché sono arrivate le prime fatture. Deve essere impiegata con maggiore criterio: lo sforzo va commisurato alla difficoltà, i modelli alle attività e la spesa al valore misurabile.

Prima responsabile principale di prodotto e poi direttore della gestione del prodotto presso Datadog, Nils ha avuto un ruolo importante nella supervisione di team fondamentali per la piattaforma, tra cui quelli dedicati alle query e all’archiviazione basate sugli eventi, agli avvisi e all’inventario referenziale delle risorse, nonché alle funzionalità di IA con Watchdog. In precedenza ha lanciato e guidato il prodotto di gestione dei log con la crescita più rapida di sempre. È inoltre autore di diversi articoli con le migliori pratiche sulla gestione dei log, dedicati a più linguaggi e tecnologie. Si è laureato al Telecom Paris e all’Imperial College di Londra.