Come abbiamo eliminato in un'ora 1 milione di dollari all'anno di spesa inutile per gli agenti AI

Gli ingegneri di Databricks si affidano molto agli agenti IA per snellire e accelerare il proprio lavoro. A loro volta, questi agenti richiedono l'accesso non solo a diversi Foundation Models, ma anche a server MCP con strumenti che consentono di accedere ad artefatti rilevanti (ad es. log di sistema, tabelle di utilizzo, ticket di supporto, wiki). In un blog precedente, abbiamo spiegato che la gestione dei costi dell'IA su scala richiede di ottimizzare non solo la selezione dei modelli, ma anche il modo in cui gli agenti utilizzano gli strumenti. In questo post, descriviamo come abbiamo cercato di ridurre i costi nell'uso degli strumenti da parte dei nostri agenti, le sfide che abbiamo affrontato lungo il percorso e come il tracciamento OTel in Unity Gateway ha ridotto a una sola ora il percorso dall'analisi a un risparmio di 1,2 milioni di dollari all'anno.

Consentire ai nostri sviluppatori di creare i propri agenti ha dato un enorme impulso alla produttività, ma con l'aumento dell'utilizzo sono cresciuti anche i costi. Abbiamo iniziato a esaminare diverse ottimizzazioni e uno dei nostri sospetti riguardava il costo nascosto delle chiamate agli strumenti non andate a buon fine. In particolare, quando gli strumenti non funzionano correttamente, l'agente chiamante raramente segnala l'errore in modo evidente. Al contrario, riprova, va a tentativi e alla fine aggira il problema, consumando silenziosamente token e tempo degli sviluppatori lungo tutto il percorso. Questo tipo di spreco è pericoloso: dall'esterno, l'attività viene comunque completata e una dashboard dei costi aggregati potrebbe mostrare un aumento del 10% nella spesa dei token, che può essere facilmente interpretato come una crescita dell'utilizzo. 

Abbiamo analizzato questo sospetto nella nostra flotta di agenti utilizzando il tracciamento di Unity Gateway e Genie One. Abbiamo riscontrato sette piccoli bug nei nostri server degli strumenti che costavano circa 499.000 dollari all'anno in token sprecati e circa 12.000 ore di ingegneria all'anno in tempi di attesa degli agenti. In totale, si tratta di una perdita stimata di 1,2 milioni di dollari all'anno in termini di produttività. 

Individuare tutti e sette i bug, quantificarli e risolverli ha richiesto circa un'ora. Questo post descrive il processo che abbiamo seguito e cosa ci ha insegnato sulla creazione di strumenti per gli agenti.

Come monitorare l'attività degli agenti IA e di MCP

Quando abbiamo distribuito per la prima volta gli agenti IA su larga scala in Databricks per la scrittura di codice e i flussi di lavoro interni, era impossibile gestire o persino comprendere appieno i costi, perché non avevamo visibilità sulle chiamate agli strumenti degli agenti e sull'attività complessiva. Per risolvere questo problema, abbiamo sfruttato Unity Gateway, che emette automaticamente una traccia OpenTelemetry per tutte le chiamate agli strumenti MCP, inclusi il nome dello strumento, gli argomenti, l'eventuale errore, il conteggio dei token, la latenza e un ID sessione che collega le chiamate tra loro. Queste tracce finiscono in un'unica tabella che registra esattamente ciò che i nostri agenti hanno fatto in qualsiasi intervallo di tempo. Non è stata richiesta alcuna nuova strumentazione e, poiché il gateway si trova già sul percorso di ogni chiamata, i dati erano immediatamente disponibili.

Questo rende la gestione dei costi degli agenti IA più pratica: invece di vedere solo la spesa aggregata dei token, possiamo attribuire la spesa sprecata a strumenti, errori e sessioni di agenti specifici.

Ora che i dati sono disponibili, il passo successivo è l'esplorazione:

• Quali errori degli strumenti si ripetono più spesso?
• Quando un agente ne incontra uno, quanti passaggi sono necessari per risolverlo?
• Quanto costa ogni errore in termini di token e tempo di attesa effettivo?

Normalmente, la parte più onerosa di questo tipo di analisi è la scrittura di query SQL e l'esplorazione degli schemi. Ma con Genie One, ci è bastato puntarlo verso la tabella delle tracce, porre esattamente queste domande in un linguaggio naturale e ottenere risposte in pochi minuti. La maggior parte della nostra ora è stata dedicata alla lettura di quelle risposte piuttosto che alla scrittura di query.

Cosa hanno rivelato le tracce: in che modo i guasti degli strumenti MCP fanno lievitare i costi degli agenti IA

Genie One ha trasformato in pochi minuti un vago sospetto ("gli agenti sembrano bloccarsi sulle chiamate Jira") in un elenco di bug classificato e quantificato. Ecco un esempio relativo a una singola finestra di 24 ore, che mostra i bug nei nostri server degli strumenti Jira e Google Drive/Docs:

Prendiamo come esempio il bug con il volume più elevato, ovvero 535 errori al giorno. Lo strumento Jira issues.search accetta un parametro fields e il server ha eseguito questa operazione:

Si aspettava una stringa separata da virgole come "key,summary,status". Tuttavia, un array è il tipo JSON semanticamente naturale per "un elenco di campi", ed è ciò che il modello ha dedotto dalle sue conoscenze di base sulle convenzioni JSON e dalle chiamate agli strumenti adiacenti nella stessa sessione. Quindi ha passato il valore strutturato che un chiamante ragionevole passerebbe:

Una lista non ha .split(), quindi il server ha generato 'list' object has no attribute 'split', un traceback Python non elaborato che non dice nulla all'agente su cosa abbia sbagliato. Quindi l'agente ci ha riprovato, andando a tentativi. A volte ha riprovato con la stessa lista fallendo nello stesso modo; altre volte ha riletto lo schema o è ricorso a tentativi ed errori. In media, sono stati necessari 12 passaggi per risolvere il problema e il 30% delle sessioni ha riscontrato l'errore più di una volta. Una singola chiamata .split() costava circa 87.000 dollari all'anno in token e 4.850 ore di tempo di attesa dell'agente.

L'errore Google Drive Invalid field selection è stato ancora più sorprendente in termini di volume: il 49,6% di tutte le chiamate drive_file_get è fallito, perché il modello continuava a passare nomi di campi delle API di Drive apparentemente validi (id, name, mimeType) che l'endpoint dello strumento non accettava.

La vera lezione: come progettare strumenti MCP per agenti IA e LLM

La conclusione ovvia è "scrivere messaggi di errore migliori" e i dati lo confermano. Il costo di risoluzione segue quasi perfettamente la qualità dei messaggi di errore:

Ma che "i buoni messaggi di errore siano d'aiuto" è una vecchia notizia. La domanda più interessante è perché il modello abbia richiamato questi strumenti in modo "errato" fin dall'inizio. Nella maggior parte di questi casi, non lo ha fatto.

Le firme degli strumenti MCP sono spesso deliberatamente sotto-specificate. Le manteniamo flessibili di proposito: in parte per generalità e in parte per risparmiare token di contesto, poiché ogni descrizione di parametro comporta un costo in token che il modello paga a ogni chiamata. La conseguenza è che quando una firma è vaga riguardo ai campi, il modello colma la lacuna con una supposizione ragionevole, e un array JSON è una supposizione ragionevole per un elenco di campi. Il bug non consisteva nel fatto che il modello richiamasse lo strumento in modo errato. Era che il server accettava solo una delle diverse interpretazioni ragionevoli e andava in crash con le altre.

Quindi il principio di progettazione è l'opposto di quello riflessivo: gli strumenti per gli agenti dovrebbero adattarsi al modo in cui gli LLM li richiamano naturalmente, ad esempio, forzando l'elenco in una stringa, impostando come predefinito il parametro omesso, assorbendo l'argomento imprevisto e così via. Una firma sotto-specificata è una promessa di flessibilità, e lo strumento dovrebbe onorare tale promessa in ricezione, piuttosto che andare in crash al primo input che non corrisponde all'unica forma che il suo autore aveva in mente.

La parte facile: come abbiamo ridotto lo spreco di spesa per gli agenti AI in un'ora

Le correzioni stesse erano semplici e non sono la parte interessante di questa storia. Una volta che Genie One ci ha fornito un elenco classificato di quali errori correggere e di cosa il modello stesse effettivamente inviando, applicare le correzioni sui server degli strumenti è stato un passaggio rapido con un agente di codifica. L'intero ciclo (individuazione, quantificazione, correzione) ha richiesto circa un'ora.

La fase difficile e costosa non è mai stata scrivere la correzione. Era sapere cosa correggere. Il tracciamento combinato con Genie One ha trasformato quel passaggio da un progetto di ricerca a una domanda che si può porre ad alta voce.

Chiudere il cerchio: come monitorare continuamente e ridurre i costi degli agenti AI

Man mano che una parte maggiore del lavoro reale si sposta sugli agenti, i guasti silenziosi degli strumenti diventano un centro di costo di primo piano, di quelli che si nascondono all'interno della "crescita dell'utilizzo" e non allertano mai nessuno. Il ciclo per individuarli è economico e ripetibile: Unity Gateway rende osservabile il comportamento degli agenti e Genie One rende tale comportamento interrogabile senza SQL.

Insieme, questo offre ai team un modo ripetibile per monitorare gli agenti AI, diagnosticare i guasti degli strumenti MCP e ridurre lo spreco di spesa per l'AI. Se esegui agenti sui tuoi strumenti, fai lo stesso. Traccia le chiamate e chiedi a Genie One cosa continua ad andare storto.

Inizia con l'analisi delle tracce di Unity Gateway con Genie One

Unity Gateway è generalmente disponibile e ora puoi monitorare tutta l'attività AI utilizzando la tabella di tracciamento unificata, che è ora in Beta. Vedi la nostra documentazione su come iniziare. 

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale