La latenza percepita è il tempo che una persona sente di aspettare davanti a un assistente AI, e non coincide quasi mai con il numero che leggi nei log. La stessa risposta in otto secondi può sembrare istantanea o sembrare un guasto: dipende solo da cosa succede durante quegli otto secondi. È una distinzione che pesa, perché il primo reclamo che arriva su un agente AI quasi mai è «ha sbagliato». È «è lento».
Chi costruisce automazioni lo vede subito. Il modello fa il suo lavoro, la risposta è corretta, ma l'utente ha già cambiato scheda. Il problema non è la potenza di calcolo: è il progetto dell'attesa. E l'attesa si progetta con gli stessi strumenti con cui si progetta tutto il resto.
Latenza percepita e latenza reale sono due numeri diversi
La documentazione di Anthropic separa due misure. La baseline latency è il tempo che il modello impiega a elaborare il prompt e produrre la risposta completa: dà «un'idea generale della velocità del modello». Il time to first token (TTFT) misura invece quanto passa dall'invio della domanda alla comparsa della prima parola, ed è «particolarmente rilevante quando si usa lo streaming e si vuole offrire un'esperienza reattiva».
Questi due numeri si muovono in modo indipendente. Una risposta lunga ha per forza una baseline alta, ma se la prima parola arriva in mezzo secondo l'utente percepisce un sistema vivo. Al contrario, una risposta brevissima consegnata tutta in blocco dopo sei secondi di schermo fermo percepisce un sistema inchiodato. La latenza percepita si gioca quasi tutta sul TTFT e su cosa mostri nel frattempo.
I tre limiti che decidono se l'attesa è accettabile
Sulla percezione del tempo la ricerca di interazione uomo-macchina non è cambiata in trent'anni. Il Nielsen Norman Group fissa tre soglie: 0,1 secondi per avere la sensazione di reazione istantanea, 1 secondo per non interrompere il flusso di pensiero («l'utente nota il ritardo ma mantiene il senso di controllo»), 10 secondi come limite dell'attenzione sostenuta — oltre, «l'utente vorrà fare altro mentre aspetta».
Nessun assistente AI che ragiona sta sotto il secondo. Quindi la partita non è arrivare alla soglia: è gestire la fascia tra 1 e 10 secondi, e dichiarare onestamente quando la si sfonda. Qui il dato più utile riguarda il feedback visivo: nelle ricerche citate da NN/g, chi vedeva una barra di avanzamento in movimento si dichiarava più soddisfatto ed era disposto ad aspettare in media tre volte più a lungo di chi non vedeva nulla. Non è un trucco estetico. È la differenza tra un'automazione che viene usata e una che viene aggirata.
Le tre soglie della percezione: sotto il secondo il flusso di pensiero resta integro, oltre i dieci secondi l'utente si dedica ad altro.
Da dove arriva l'attesa in un assistente AI
Tre cause coprono la quasi totalità dei casi, e sono tutte governabili.
Il ragionamento. I modelli recenti pensano prima di rispondere, e quel pensiero sono token generati che costano tempo. Anthropic è esplicita: budget di ragionamento più alti consentono analisi più approfondite «con ritorni decrescenti che dipendono dal compito, e al costo di una latenza maggiore». Oltre i 32.000 token di ragionamento la raccomandazione è di passare all'elaborazione asincrona, perché le richieste diventano così lunghe da rischiare i timeout di rete e i limiti sulle connessioni aperte.
La lunghezza di prompt e risposta. Meno token entrano e meno token escono, più veloce è la risposta. Un prompt di sistema gonfiato da mesi di aggiunte non costa solo in bolletta: costa in secondi, su ogni singola chiamata. Lo stesso vale per il formato della risposta: chiedere «due paragrafi» funziona meglio che chiedere «massimo 150 parole», perché i modelli contano token, non parole.
Il contesto da rileggere. Più materiale metti nella finestra, più tempo serve a elaborarlo prima di cominciare a scrivere. È il rovescio della medaglia di cui abbiamo parlato a proposito della finestra di contesto da un milione di token: capienza e reattività tirano in direzioni opposte.
Quattro leve per ridurre la latenza percepita
1. Scegli il modello e il livello di sforzo per il compito, non per prestigio. Il parametro effort di Claude ha cinque livelli e decide quanti token il modello spende per rispondere. La documentazione è diretta: usare il livello basso «per compiti sensibili alla latenza o semplici» può «ridurre significativamente tempi di risposta e costi». Un classificatore di email non ha bisogno dello stesso sforzo di un'analisi contrattuale, e farglielo fare è uno spreco che l'utente paga in attesa.
2. Attiva lo streaming, sempre. Lo streaming consente al modello di iniziare a inviare la risposta prima che sia completa e, scrive Anthropic, «può migliorare significativamente la reattività percepita della tua applicazione». Su richieste con un max_tokens elevato non è nemmeno un'opzione: serve a evitare i timeout HTTP. Se il tuo assistente mostra una rotella fino alla fine, lo streaming non è stato implementato — ed è il difetto più comune e più economico da correggere.
3. Pre-scalda la cache. Il prompt caching non serve solo a tagliare la spesa. Il pre-caricamento permette di mettere in cache il prompt di sistema e le definizioni degli strumenti prima che arrivi la richiesta di un utente: «elimina la penalità di latenza del primo accesso, riducendo il TTFT per le applicazioni sensibili alla latenza». Tradotto: la prima persona del mattino non paga più per tutte le altre.
4. Dichiara l'attesa. Se un passaggio richiede dodici secondi, dillo. Una riga che cambia — «sto leggendo i tre documenti», «sto compilando il preventivo» — vale più di qualunque animazione generica, perché trasforma un silenzio in un avanzamento. È esattamente l'effetto misurato da NN/g: con un indicatore credibile l'attesa tollerata si allunga, senza che il sistema sia diventato più veloce di un millisecondo.
Quando l'attesa va spostata, non ridotta
C'è una categoria di lavori per cui ottimizzare la latenza è la domanda sbagliata. Riclassificare duemila schede prodotto, rileggere l'archivio dei ticket, generare i riepiloghi del mese: nessuno sta davanti allo schermo ad aspettare. Per questi casi esistono le API asincrone a lotti, che Anthropic offre con un taglio del 50% sul prezzo e con «la maggior parte dei lotti completati in meno di un'ora» (il limite dichiarato è 24 ore, oltre le quali la richiesta scade).
Il ragionamento operativo è semplice. Un processo che non ha un essere umano in attesa non deve stare su un percorso sincrono: va messo in coda, pagato la metà e consegnato con una notifica. Metà dei problemi di «lentezza» che ci vengono descritti sono lavori batch eseguiti in tempo reale per abitudine, non per necessità.
Cosa chiedere a chi ti costruisce l'automazione
Tre domande bastano a capire se l'attesa è stata progettata o subita. Primo: qual è il TTFT tipico e qual è il peggiore misurato, non stimato. Secondo: la risposta arriva in streaming o tutta in blocco. Terzo: quali operazioni sono sincrone perché devono esserlo, e quali lo sono soltanto perché nessuno le ha spostate in coda.
Se le risposte sono vaghe, il problema non è il modello. Infatti la latenza percepita è una scelta di progetto quanto la grafica o il testo dei messaggi: si misura, si governa con i parametri che il fornitore del modello mette a disposizione e si comunica all'utente. Un assistente che dice cosa sta facendo mentre lo fa viene percepito come competente; uno che tace per otto secondi viene percepito come guasto, anche quando la risposta che consegna è migliore.
Studiollice progetta agenti e automazioni su misura, e la latenza è una delle voci che mettiamo per iscritto insieme alle altre: cosa risponde in tempo reale, cosa arriva per notifica, con quale tempo tipico. Se un'automazione già in uso nella tua azienda viene percepita come lenta, quasi sempre si recupera senza cambiare modello.