Comment optimiser la latence pour le Conversational AI ?

Pour la plupart des applications, la latence est une préoccupation mineure. Cependant, pour le Conversational AI, la latence est ce qui distingue les bonnes applications des excellentes.

Pour commencer, l'objectif du Conversational AI est assez ambitieux : offrir la même sensation, le même toucher et la même voix qu'une conversation humaine, tout en surpassant l'intelligence humaine. Pour y parvenir, une application doit converser sans longs silences. Sinon, le réalisme est brisé.

Le défi de la latence du Conversational AI est accentué par sa nature fragmentée. Le Conversational AI est une série de processus intermédiaires, tous considérés comme à la pointe dans leurs domaines respectifs. Chacun de ces processus entraîne une latence additive.

En tant qu'entreprise de voix générative, nous avons passé beaucoup de temps à étudier comment minimiser la latence pour le Conversational AI. Aujourd'hui, nous voulons partager nos apprentissages, dans l'espoir qu'ils seront utiles à quiconque s'intéresse à la création d'applications de Conversational AI.

Les Quatre Composants Principaux

Chaque application de Conversational AI implique au moins quatre étapes : speech-to-text, prise de tour, traitement de texte (c'est-à-dire LLMs), et text-to-speech. Bien que ces étapes soient exécutées en parallèle, chaque étape contribue tout de même à la latence.

Notamment, l'équation de la latence du Conversational AI est unique. Beaucoup de problèmes de latence de processus peuvent être réduits à un seul goulot d'étranglement. Par exemple, lorsqu'un site web effectue une requête de base de données, la latence du réseau web détermine la latence totale, avec seulement des contributions triviales de la latence du VPC du backend. Cependant, les composants de latence du Conversational AI ne varient pas radicalement. Ils sont inégaux, mais la contribution de la latence de chaque composant est dans un degré des autres. En conséquence, la latence est déterminée par une somme de parties.

Reconnaissance Automatique de la Parole

L'« Oreille » du Système

La reconnaissance automatique de la parole (ASR)—parfois appelée speech-to-text (STT)—est le processus de conversion de l'audio parlé en texte écrit.

La latence de l'ASR n'est pas le temps qu'il faut pour générer du texte, car le processus de speech-to-text fonctionne en arrière-plan pendant que l'utilisateur parle. Au lieu de cela, la latence est le temps entre la fin du discours et la fin de la génération de texte.

En conséquence, les intervalles de parole courts et longs peuvent entraîner une latence ASR similaire. La latence peut varier selon les implémentations ASR (dans certains cas, il n'y a pas de latence réseau du tout car le modèle est intégré dans le navigateur, comme Chrome/Chromium). Le modèle open source standard, Whisper, ajoute 300ms + de latence. Notre implémentation personnalisée ajoute <100ms.

Prise de Tour / Interruption

L'« Instinct » du Système

La prise de tour / interruption (TTI) est un processus intermédiaire qui détermine quand un utilisateur a fini de parler. Le modèle sous-jacent est connu sous le nom de détecteur d'activité vocale (ou VAD).

La prise de tour implique un ensemble complexe de règles. Une courte rafale de parole (par exemple, « uh-huh ») ne devrait pas déclencher un tour ; sinon, les conversations sembleraient trop saccadées. Au lieu de cela, il doit évaluer quand un utilisateur essaie réellement d'attirer l'attention du modèle. Il doit également déterminer quand l'utilisateur a fini de transmettre ses pensées.

Un bon VAD ne doit pas signaler un nouveau tour chaque fois qu'il détecte un silence. Il y a du silence entre les mots (et les phrases), et le modèle doit être sûr que l'utilisateur a réellement fini de parler. Pour y parvenir de manière fiable, il doit rechercher un seuil de silence (ou plus précisément, une absence de parole). Ce processus introduit un délai, contribuant à la latence globale ressentie par l'utilisateur.

Techniquement parlant, si tous les autres composants du Conversational AI n'entraînaient aucune latence, la latence attribuée à la TTI serait une bonne chose. Les humains prennent un temps avant de répondre à la parole. Une machine prenant une pause similaire donne du réalisme à l'interaction. Cependant, puisque d'autres composants du Conversational AI entraînent déjà une latence, une latence TTI minimale est idéale.

Traitement de Texte

Le Cerveau du Système

Ensuite, le système doit générer une réponse. Aujourd'hui, cela se fait généralement avec un Large Language Model (LLM), tel que GPT-4 ou Gemini Flash 1.5.

Le choix du modèle de langage fait une différence significative. Des modèles comme Gemini Flash 1.5 sont incroyablement rapides—générant des sorties en moins de 350ms. Des modèles plus robustes capables de gérer des requêtes plus complexes—comme les variantes de GPT-4 et Claude—pourraient prendre entre 700ms et 1000ms.Choisir le bon modèle est généralement le moyen le plus simple de cibler la latence lors de l'optimisation d'un processus de Conversational AI.

Cependant, la latence du LLM est le temps qu'il faut pour commencer à générer des tokens. Ces tokens peuvent être immédiatement transmis au processus suivant de text-to-speech. Comme le text-to-speech est ralenti par le rythme naturel d'une voix humaine, le LLM le devance de manière fiable—ce qui compte le plus est la latence du premier token (c'est-à-dire, le temps jusqu'au premier octet).

Il y a d'autres contributeurs à la latence d'un LLM au-delà du choix du modèle. Ceux-ci incluent la longueur de l'invite et la taille de la base de connaissances. Plus l'un ou l'autre est grand, plus la latence est longue. Cela se résume à un principe simple : plus le LLM doit prendre en compte, plus cela prend de temps. En conséquence, les entreprises doivent trouver un équilibre entre une quantité saine de contexte sans surcharger le modèle.

Text to Speech

La Bouche du Système

Le dernier composant du Conversational AI est text-to-speech (TTS). La latence nette du text-to-speech est le temps qu'il faut pour commencer à parler après avoir reçu les tokens d'entrée du traitement de texte. C'est tout—car des tokens supplémentaires sont disponibles à un rythme plus rapide que la parole humaine, la latence du text-to-speech est strictement le temps jusqu'au premier octet.

Auparavant, text-to-speech était particulièrement lent, prenant jusqu'à 2-3s pour générer de la parole. Cependant, des modèles à la pointe comme notre moteur Turbo sont capables de générer de la parole avec seulement 300ms de latence et le nouveau moteur Flash TTS est encore plus rapide. Flash a un temps de modèle de 75ms et peut atteindre un temps de latence audio de 135ms jusqu'au premier octet, le meilleur score dans le domaine (nous devons nous vanter un peu !).

Contributeurs Supplémentaires

Au-delà des quatre composants, il y a quelques contributeurs supplémentaires à la latence nette du Conversational AI.

Latence Réseau

Il y aura toujours une latence associée à l'envoi de données d'un endroit à un autre. Pour certaines applications de Conversational AI, les processus ASR, TTI, LLM, et TTS devraient idéalement être co-localisés, de sorte que la seule source de latence réseau non triviale soit les chemins entre le locuteur et l'ensemble du système.Cela nous donne un avantage sur la latence car nous pouvons économiser deux appels serveur puisque nous avons notre propre TTS et une solution de transcription interne.

Appels de Fonction

Beaucoup d'applications de Conversational AI existent pour invoquer des fonctions (c'est-à-dire interagir avec des outils et des services). Par exemple, je pourrais demander verbalement à l'IA de vérifier la météo. Cela nécessite des appels API supplémentaires invoqués au niveau du traitement de texte, ce qui peut entraîner beaucoup plus de latence selon les besoins.

Par exemple, si je dois commander une pizza verbalement, il pourrait y avoir plusieurs appels API nécessaires, certains avec un retard excessif (par exemple, le traitement d'une carte de crédit).

Cependant, un système de Conversational AI peut combattre les retards associés aux appels de fonction en incitant le LLM à répondre à l'utilisateur avant que l'appel de fonction ne soit terminé (par exemple, « Laissez-moi vérifier la météo pour vous »). Cela modélise une conversation réelle et ne laisse pas l'utilisateur sans engagement.

Ces modèles asynchrones sont généralement réalisés en utilisant des webhooks pour éviter les requêtes de longue durée.

Téléphonie

Une autre fonctionnalité courante pour les plateformes de Conversational AI est de permettre à l'utilisateur de se connecter par téléphone (ou, dans certains cas, de passer un appel téléphonique au nom de l'utilisateur). La téléphonie entraînera une latence supplémentaire—et cette latence peut être fortement dépendante de la géographie.

En base, la téléphonie entraînera une latence supplémentaire de 200ms si elle est contenue dans la même région. Pour les appels mondiaux (par exemple, Asie → USA), le temps de trajet peut augmenter considérablement, avec une latence atteignant ~500ms. Ce schéma pourrait être courant si les utilisateurs ont des numéros de téléphone en dehors de la région où ils se trouvent—forçant un saut vers les réseaux téléphoniques de leur pays d'origine.

Une Pensée de Clôture

Nous espérons que cette exploration aller-retour du Conversational AI a été intéressante. En résumé, les applications devraient viser une latence inférieure à une seconde. Cela peut généralement être accompli en choisissant le bon LLM pour la tâche. Elles devraient également interagir avec l'utilisateur chaque fois que des processus plus complexes s'exécutent en arrière-plan pour éviter de longues pauses.

En fin de compte, l'objectif est de créer du réalisme. Un utilisateur doit ressentir la facilité de parler à un humain tout en bénéficiant des avantages d'un programme informatique. En resserrant les sous-processus, cela est désormais possible.

Chez ElevenLabs, nous optimisons chaque partie du système de Conversational AI avec nos modèles STT et TTS à la pointe. En travaillant sur chaque partie du processus, nous pouvons obtenir des flux de conversation fluides. Cette vue d'ensemble sur l'orchestration nous permet de réduire un peu la latence—même 1ms—à chaque étape.