GPT-4o : la latence devient un critère de conception
GPT-4oLatenceAdoptionArchitecture2024-05-1310 min
Sous trois cents millisecondes, un échange devient une conversation. Au-delà de trois secondes, l'utilisateur abandonne. Entre les deux se joue l'adoption.
Ce que la vitesse rend possible
GPT-4o répond assez vite pour soutenir un échange vocal sans temps mort perceptible, ce qui fait basculer l'interaction du registre de la requête à celui de la conversation. C'est un changement d'usage, pas seulement de performance.
Une requête se pose, s'attend, se lit. Une conversation s'interrompt, se corrige, se reprend. La seconde suppose que la réponse arrive dans le délai qu'un humain tolère d'un autre humain, soit quelques centaines de millisecondes.
Ce seuil n'est pas arbitraire : il correspond à la latence d'un tour de parole ordinaire. En dessous, l'échange paraît naturel. Au-delà, l'utilisateur ajuste son comportement, il parle plus lentement, attend, reformule, et l'usage se dégrade.
Les seuils qui comptent, et lesquels viser
Trois cents millisecondes pour un échange vocal, une seconde pour une interface écrite, trois secondes avant l'abandon. Ces ordres de grandeur suffisent à cadrer la conception d'un système.
Pour une interface écrite, la contrainte est plus souple parce que l'affichage progressif du texte occupe l'attention. L'utilisateur qui voit les premiers mots arriver attend volontiers la suite. C'est pourquoi le temps jusqu'au premier jeton compte davantage que le temps total.
Pour un usage vocal, l'affichage progressif n'existe pas : le silence est un silence. La contrainte devient absolue et exclut d'emblée certaines architectures, une chaîne de récupération lente, un enchaînement de plusieurs appels, un modèle de très grande taille.
La conséquence de conception est nette : un système vocal ne peut pas se permettre l'architecture d'un système écrit. Ce qui est invisible dans l'un devient rédhibitoire dans l'autre.
Où se perd la latence dans un système documentaire
- La récupération, si l'index est mal dimensionné ou si le filtrage des droits se fait après la recherche au lieu d'avant.
- Le nombre d'appels enchaînés. Chaque appel supplémentaire ajoute son délai complet, et trois appels séquentiels triplent l'attente.
- La taille du contexte envoyé. Un contexte deux fois plus long met sensiblement plus de temps à être traité, ce qui s'ajoute au coût. Voir une grande fenêtre reste une facture.
- Les garde-fous mal placés. Un contrôle de sécurité qui attend la réponse complète avant de la valider annule tout le bénéfice de l'affichage progressif.
Pourquoi la latence décide de l'adoption
Un système lent est abandonné même quand ses réponses sont bonnes, et c'est la cause d'échec la plus sous-estimée que je rencontre. Elle n'apparaît dans aucun tableau de bord de qualité.
Le mécanisme est simple. Un utilisateur qui attend trop longtemps développe une stratégie de contournement : il fait autrement, il demande à un collègue, il retourne à sa recherche manuelle. Ce contournement ne produit aucun signal, pas d'erreur, pas de plainte, juste une baisse d'usage.
J'ai repris des systèmes dont les réponses étaient excellentes et l'usage nul, avec une latence moyenne de huit secondes. Diviser cette latence par trois a fait plus pour l'adoption que six mois d'amélioration de la qualité des réponses.
La mesure à mettre en place est donc la latence perçue, au quantile élevé et non en moyenne. Une moyenne de deux secondes qui cache un dixième des requêtes à douze secondes produit un abandon massif. C'est le sujet de l'observabilité des systèmes IA.
La métrique à afficher en priorité
Le temps jusqu'au premier jeton, au quantile 95. C'est la seule mesure qui corresponde à ce que l'utilisateur ressent réellement, et c'est celle qui prédit l'adoption bien mieux que la qualité des réponses.
Ce que ça change pour la conception des usages
La rapidité ouvre des usages qui étaient hors de portée : l'assistance en situation, la conversation vocale en mobilité, la correction en temps réel. Ce sont des usages différents, pas des versions accélérées des précédents.
L'assistance en situation, un technicien devant une machine, un agent au téléphone avec un client, suppose une réponse dans le rythme de l'action. Une réponse en huit secondes arrive après que la personne a déjà fait autre chose.
Ces usages ont une caractéristique commune : ils tolèrent mal l'erreur, parce que l'utilisateur n'a pas le temps de vérifier. La rapidité augmente donc l'exigence de fiabilité au lieu de la relâcher, et impose de concevoir explicitement ce que le système fait quand il n'est pas sûr.
La réponse tient en une règle : dans un usage rapide, le refus doit être aussi rapide que la réponse. Un système qui met huit secondes à dire qu'il ne sait pas est pire qu'un système qui le dit tout de suite.
Cette exigence rejoint directement la question du périmètre : plus l'interaction est rapide, moins l'utilisateur vérifie, et plus il importe d'avoir décidé à l'avance ce que le système n'a pas le droit de faire seul. Le cadre est posé dans le périmètre avant l'autonomie.
Questions fréquentes
- Quelle latence viser pour un assistant documentaire ?
Moins d'une seconde jusqu'au premier jeton pour une interface écrite, où l'affichage progressif occupe l'attention. Pour un usage vocal, le seuil descend à quelques centaines de millisecondes et devient contraignant.
- Faut-il mesurer la latence moyenne ?
Non, le quantile élevé. Une moyenne de deux secondes qui cache un dixième des requêtes à douze secondes produit un abandon massif que la moyenne ne révèle jamais.
- Où se perd la latence en pratique ?
Dans la récupération mal dimensionnée, les appels enchaînés, la taille du contexte envoyé et les garde-fous qui attendent la réponse complète avant de la valider.
- La rapidité réduit-elle l'exigence de fiabilité ?
Au contraire. Un usage rapide ne laisse pas le temps de vérifier, donc l'erreur passe. Il faut concevoir explicitement le comportement en cas de doute, et rendre le refus aussi rapide que la réponse.