Perché la Latenza Media È la Metrica Sbagliata per gli AI Agent

Il tempo di risposta medio è la metrica sbagliata su cui ottimizzare gli AI agent, perché nasconde esattamente le richieste che compromettono la fiducia: la tool call lenta, lo step LLM andato in retry, la richiesta andata in timeout che è silenziosamente tornata a un fallback. Monitori invece la latenza p95 e p99 per ogni step, e chieda la stessa cosa a qualsiasi vendor prima di firmare un contratto.

Il problema della media

Supponiamo che il suo agent risponda in media in 800ms. Sembra accettabile. Ma se il 90% delle richieste si conclude in 400ms e il restante 10% richiede 6 secondi — perché incappa in un retry, un rate limit o un'API downstream lenta — la media seppellisce la parte della distribuzione che gli utenti percepiscono davvero. Nessuno sperimenta la media. Ognuno sperimenta la propria richiesta, e per un utente su dieci quella richiesta è 15 volte più lenta di quanto la sua dashboard lasci intendere.

Non è un'idea nuova nei sistemi distribuiti in generale — è per questo che il Google SRE book tratta la latenza percentile (p50, p95, p99) come standard per il monitoraggio, non la media. Gli AI agent peggiorano la situazione rispetto ai normali servizi web perché la coda è più pesante: il tempo di inferenza degli LLM è di per sé variabile, le tool call possono bloccarsi, e gli agent spesso concatenano più chiamate dove un singolo link lento blocca l'intera richiesta.

L'origine della coda nei sistemi agent

Una singola chiamata LLM ben circoscritta ha un'unica fonte di varianza nella latenza: il tempo di inferenza del modello, più la rete. Un agent che concatena step — recuperare contesto, chiamare uno strumento, richiamare il modello, validare l'output, richiamare il modello una terza volta — moltiplica quella varianza a ogni passaggio. Ogni step porta anche la propria probabilità di errore e retry, e i retry non aggiungono latenza in modo uniforme: la aggiungono in modo irregolare. Una richiesta che necessita di un retry allo step 3 può richiedere il doppio del tempo rispetto a una che procede senza intoppi, e questa irregolarità è esattamente ciò che le medie cancellano.

Lo abbiamo visto direttamente costruendo il nostro tool di outreach, che analizza il sito di un prospect e redige un'email personalizzata. Le prime versioni usavano una catena a tre step: estrarre i dati dalla pagina, redigere l'email, poi perfezionarla. Lo step di estrazione era quello alla mercé del server altrui — alcuni siti dei prospect si caricavano rapidamente, altri erano lenti o appesantiti da script di tracciamento — e il tempo necessario per recuperare e analizzare quella pagina diventava un limite inferiore per tutto ciò che seguiva, poiché la redazione non poteva iniziare prima che l'estrazione fosse terminata. La media sembrava buona perché la maggior parte dei siti dei prospect è veloce. La coda era problematica perché i siti lenti non erano rari — erano semplicemente distribuiti in modo disomogeneo — e ognuno produceva uno stallo prolungato che una media veloce non mostrava mai. Unire estrazione e redazione in un'unica chiamata ben progettata non ha reso i singoli siti più veloci, ma ha eliminato la dipendenza sequenziale: c'era un passaggio in meno in cui un recupero lento potesse bloccare tutto. Se sta decidendo tra una catena agent e una singola chiamata per il suo prodotto, vale la pena valutare quel compromesso prima di costruire — consulti la nostra analisi di single-call vs agent chains.

Cosa misurare invece

Per qualsiasi AI agent — che lo stia costruendo lei o valutando quello di un vendor — chieda questi dati suddivisi per step, non solo per la richiesta nel suo complesso:

• p50 (mediana): come si sente una richiesta tipica.
• p95: cosa sperimenta un utente su venti. Di solito è qui che iniziano i veri reclami sul prodotto.
• p99: la coda nel caso peggiore. Per un bot di supporto che gestisce migliaia di conversazioni al giorno, il p99 non è un caso limite — sono decine di conversazioni reali ogni giorno.
• Tempo al primo token vs. tempo di completamento totale: se l'agent trasmette l'output in streaming, gli utenti tollerano molto meglio un tempo totale più lento rispetto a un avvio lento. Li misuri entrambi separatamente.
• Tasso di retry e dove avvengono: un tasso di retry del 2% su uno step sembra trascurabile, finché non si scopre che è lo step da cui dipende ogni richiesta.

Strumenti come OpenTelemetry esistono proprio per tracciare la latenza attraverso ogni step di una chiamata distribuita — incluse le catene agent — invece di vedere solo il totale. Se il suo stack attuale (o quello di un vendor) non riesce a mostrarle trace per step, anche questo è un dato informativo.

Come si manifesta nelle conversazioni con i vendor

Se sta valutando un team esterno per costruire o gestire un AI agent, le dichiarazioni sulla latenza sono uno dei punti in cui un pitch tende più facilmente a sovrastimare la realtà. "Risposte sub-secondo" è quasi sempre un'affermazione sulla media, ed è esattamente il tipo di dato che ha nascosto lo stall nel nostro tool di outreach finché non l'abbiamo scomposto per step. Le domande di approfondimento giuste sono:

• Qual è il p95 e il p99 sotto carico concorrente realistico, non con una singola richiesta a cache calda in una demo?
• Quale step nella pipeline è il più lento, e come cambia sotto carico?
• Cosa succede quando una chiamata downstream (un database, un indice di ricerca, un'altra API o, nel nostro caso, il sito web del prospect) è lenta? L'agent degrada in modo controllato o si blocca?

Queste domande appartengono alla stessa conversazione di prezzi e condizioni di supporto. Il resto di quella valutazione — incluse domande che non hanno nulla a che fare con la velocità — è disponibile nella nostra checklist per la valutazione di vendor di AI agent.

Latenza e costi sono la stessa conversazione

Vale la pena notarlo: la stessa catena che produce un p99 problematico di solito produce anche un conto problematico. Step aggiuntivi significano token aggiuntivi, retry aggiuntivi significano pagare due volte per lo stesso lavoro, e chiamate al modello aggiuntive significano pagare un overhead di coordinamento che non aggiunge valore all'output. Se sta già verificando la latenza, verifichi anche la spesa allo stesso tempo. La nostra guida sull'ottimizzazione dei costi LLM percorre lo stesso esercizio di ottimizzazione dal lato dei costi, e in pratica le soluzioni si sovrappongono: meno chiamate, meglio circoscritte, battono più chiamate e più piccole su entrambe le dimensioni.

Il punto pratico

Non lasci che "sembra veloce nella demo" o "tempo di risposta medio: 800ms" sostituiscano una misurazione reale. Prima di rilasciare un agent — o prima di approvare quello costruito da altri — ottenga i numeri p95 e p99 sotto carico, suddivisi per step. Se nessuno riesce a produrre quei numeri, ha già la sua risposta su quanto testing sia stato realmente effettuato.

Se sta costruendo un AI agent e desidera un secondo parere sull'architettura prima che la latenza diventi un problema in produzione, parliamone.