Cet article a été mis à jour en juillet 2025

TL;DR

Cet article explore les méthodes permettant de réduire le temps de latence dans les systèmes de génération augmentée de recherche (RAG), en particulier dans les interactions vocales en temps réel pour les Applications dans le domaine du service/support à la clientèle.

Introduction

Avec l'adoption de la génération augmentée par récupération (RAG), de nombreuses organisations trouvent qu'il est plus facile d'accéder aux capacités génératives des grands modèles de langage (LLM) sans avoir recours à des modes de formation coûteux ou complexes, tels que la préformation, le réglage fin, la RLHF ou les adaptateurs. Le RAG permet aux organisations de construire des bases de connaissances contenant de vastes quantités d'informations et de n'en extraire que les parties pertinentes, en fournissant aux LLM une réponse complète sans incorporer l'information directement dans le LLM.

Qu'est-ce que le RAG ?

Dans le système RAG, un modèle extrait des documents ou des informations pertinentes d'une grande base de données, puis génère une réponse à partir de ces informations. La RAG utilise généralement un système en deux parties : un récupérateur et un générateur. Le récupérateur recherche des documents ou des passages pertinents sur la base d'une requête, en utilisant souvent des méthodes telles que la recherche éparse, dense et hybride, la recherche sémantique (basée sur les vecteurs) étant couramment utilisée pour obtenir des résultats rapides et contextuellement précis. Le générateur (souvent un modèle comme GPT) synthétise les informations récupérées pour générer la réponse finale. Cela permet au modèle de fournir des réponses plus précises et factuellement correctes.

Deux des cas d'utilisation les plus populaires du RAG sont les suivants :

1. Service clientèle: Exposer les informations externes/internes d'une entreprise dans un format conversationnel en utilisant des agents virtuels/assistants/chatbots pour les utilisateurs finaux et en automatisant les modules de FAQ et de questions-réponses, ce qui permet d'obtenir un taux de confinement élevé.

2. Recherche d'entreprise: Rendre les informations organisationnelles privées consultables et fournir des réponses plus précises en se connectant à des sources de données telles que Google Drive, Confluence, JIRA, Zendesk, des sites web, des fichiers statiques, etc.

Voice et latence acceptable pour les conversations

Lors de l'utilisation de RAG pour le service client, la recherche d'informations ou les conversations avec les MFR se déroulent généralement sur des canaux vocaux ou numériques (tels que le web, WhatsApp, SMS, etc.). La latence est un facteur critique dans les communications en temps réel, car elle peut avoir un impact significatif sur la qualité et l'efficacité de la conversation. Dans la communication en temps réel, la latence fait référence au délai entre le moment où un son est produit par le locuteur et celui où il est entendu par l'auditeur.

Le canal vocal a une faible tolérance à la latence, et le canal de transmission de la voix a une faible tolérance à la latence, et le canal de transmission de la voix a une faible tolérance à la latence. UIT-T (secteur de la normalisation des télécommunications de l'Union internationale des télécommunications) recommande une latence unidirectionnelle de 100 ms pour les tâches interactives et de 150 ms pour les cas d'utilisation conversationnelle impliquant des humains aux deux extrémités. Les canaux numériques ont généralement des niveaux de tolérance plus élevés que les canaux vocaux. Cet article analyse spécifiquement la latence du canal vocal lors de l'utilisation de RAG pour les interactions entre humains et assistants virtuels/agents/chatbots.

Atteindre une latence unidirectionnelle de 150 ms est presque impossible avec une architecture de type RAG où plusieurs composants sont impliqués dans le traitement de la voix. Cependant, il est possible d'obtenir des expériences en temps quasi réel en optimisant correctement la logique de traitement de la voix et les modèles d'IA. Les utilisateurs finaux des assistants virtuels/agents/chatbots sont plus tolérants aux délais que les conversations entre humains, qui sont très sensibles à la latence.

Vue de bout en bout d'un appel Voice

End-to-end view of a voice call

Un pipeline d'appels vocaux avec RAG peut être divisé en plusieurs composants. Il commence généralement par une conversation initiée sur une application web ou un téléphone par l'utilisateur final, la latence du réseau s'accumulant jusqu'à ce que la Voice atteigne le service. Une fois que la voix atteint le service, la première étape consiste à la convertir en texte à l'aide d'un service de conversion de la parole en texte (STT). Le texte transcrit est ensuite utilisé pour la recherche d'informations, et le contexte récupéré est transmis à un LLM pour générer une réponse. Cette réponse est ensuite envoyée à un service de conversion du texte en parole (TTS), qui reconvertit le texte en voix. Enfin, la Voice est transmise à l'application web ou au téléphone via le réseau pour être diffusée à l'utilisateur final.

Dispositif/Application/Navigateur

Une conversation de l'utilisateur final commence généralement par un appareil/application/navigateur connecté à l'internet. L'appareil/l'application/le navigateur de l'utilisateur final joue un rôle crucial dans la latence car il capture l'audio et effectue le codage. Il gère également la réponse en recevant l'audio et en le décodant.

Vous disposez généralement de trois options pour les terminaux :

1. Téléphone RTCP Si les utilisateurs finaux composent des numéros physiques au lieu d'utiliser la fonction d'appel de l'application ou du navigateur web, l'audio doit être envoyé à une passerelle RTPC avant d'être envoyé au service de conversion de la parole en texte ou au service ASR pour la transcription.

2. Applications mobiles Applications mobiles : Les applications mobiles peuvent diffuser de l'audio en continu via WebSockets ou WebRTC. Toutefois, les WebSockets, qui reposent sur le protocole TCP, peuvent présenter des problèmes de performance dans les réseaux à forte latence.

3. Navigateur Web Les navigateurs Web sont désormais équipés de la technologie WebRTC pour la communication en temps réel, ce qui permet une diffusion multimédia en continu à faible latence basée sur le protocole UDP.

Recommandation : Il est préférable d'obtenir une faible latence si l'application est basée sur WebRTC.

Réseau de liaison montante et descendante

Les conditions de latence des réseaux en liaison montante et descendante sont variées et imprévisibles pour les utilisateurs finaux, ce qui rend difficile la formulation de recommandations spécifiques.

Service de conversion de la parole en texte

Cette étape est cruciale car le service convertit la parole en texte pour un traitement ultérieur. Il est important d'obtenir une grande précision avec une faible latence, car la précision de cette étape affecte l'efficacité globale du pipeline de réponse. Différents fournisseurs, tels que Speechmatics, Deepgram, Google ASR et AWS Transcribe, proposent des services de conversion de la parole en texte. Deux modes sont disponibles :

1. Traitement préenregistré (par lots) Traitement par lots : une mémoire tampon ou un fichier audio enregistré est envoyé au fournisseur de services de conversion de la parole en texte par lots. Cette approche implique généralement l'attente d'un silence avant le traitement, ce qui ajoute un temps de latence.

2. Flux en temps réel Streaming en temps réel : Les énoncés de l'utilisateur final sont envoyés au service STT au fur et à mesure qu'ils sont reçus, ce qui permet une transcription plus rapide mais risque d'introduire des problèmes de précision. Une détection efficace de l'activité vocale (VAD) est essentielle pour le streaming en temps réel.

Recommandation : Il est plus facile d'obtenir une faible latence avec un flux en temps réel qu'avec un traitement par lots dans les services de conversion de la parole en texte.

Depuis 2025, des options plus récentes comme AssemblyAI et OpenAI Whisper API (bêta) sont également disponibles, dont beaucoup prennent en charge les points de terminaison en temps réel dès le départ pour améliorer la réactivité.

Recherche d'informations

Les méthodes de recherche utilisées dans RAG sont cruciales pour récupérer des documents ou des passages pertinents et de haute qualité que le modèle génératif peut utiliser pour produire des réponses informatives. Le choix de la méthode de recherche, qu'elle soit peu dense, dense ou hybride, dépend de facteurs tels que la précision des réponses, le temps de latence et les contraintes informatiques. Les méthodes de recherche hybrides, qui combinent des techniques denses et éparses, gagnent en popularité en raison de leur capacité à combiner précision et rappel, ce qui les rend très efficaces dans les systèmes RAG.

La recherche vectorielle, également connue sous le nom de recherche sémantique, utilise généralement des représentations vectorielles (embeddings) du texte et effectue ensuite une recherche sur ces embeddings pour trouver les résultats les plus similaires. Le temps de latence de la recherche vectorielle peut être réduit en utilisant des vecteurs d'intégration plus courts (mais toujours précis sur le plan contextuel) et des algorithmes de recalage plus rapides pour filtrer le contexte non pertinent. La mise en œuvre de la mise en cache et de bases de données vectorielles locales peut également améliorer le temps de latence de la recherche.

Recommandation : Pour les conversations en temps réel, la recherche sémantique est généralement un meilleur choix en raison de sa rapidité et de son efficacité. Elle permet une récupération quasi instantanée, ce qui est essentiel pour maintenir le flux des interactions en direct.

Bien que MongoDB Atlas Search prenne désormais en charge la recherche vectorielle, pour les applications à faible latence et en temps réel, les bases de données vectorielles dédiées telles que Weaviate, Qdrant, Pinecone ou FAISS sont généralement plus performantes.

Traitement des dossiers LLM

La partie génération du système RAG utilise un LLM pour produire des réponses cohérentes et contextuellement pertinentes basées sur les informations récupérées et la requête de l'utilisateur. Le temps nécessaire pour obtenir le premier jeton (TTFT) est une mesure de performance importante. Il s'agit du temps nécessaire à un modèle pour générer le premier jeton de sortie après avoir reçu une invite. Cette métrique est cruciale dans les applications interactives telles que les chatbots, les assistants virtuels et la génération de contenu en temps réel.

Dans les modèles de traitement par lots tels que Google Chat Bison, le TTFT fait généralement référence au temps nécessaire pour générer l'intégralité de la réponse, ce qui peut entraîner des retards car le service de synthèse vocale (TTS) doit attendre que l'intégralité de la réponse soit générée avant de la traiter. En revanche, les modèles de streaming tels que Gemini 1.5 Pro permettent de mesurer le TTFT à partir du moment où le premier jeton est généré, ce qui permet une sortie immédiate. Cela signifie que le service TTS peut commencer à traiter et à fournir des parties de la réponse au fur et à mesure qu'elles sont disponibles, ce qui améliore considérablement l'expérience de l'utilisateur en réduisant la latence perçue.

L'avenir de RAG pourrait être marqué par des avancées où la composante de récupération est minimisée ou entièrement éliminée, grâce à des modèles plus sophistiqués avec des fenêtres de contexte plus grandes, comme la famille de modèles Google Vertex Gemini. Plusieurs autres facteurs affectent également la génération de réponses LLM, et des optimisations telles que la réduction de la taille de l'invite ou l'utilisation de la mise en cache du contexte peuvent réduire la latence. Dans certains cas, vous pouvez opter pour un petit modèle linguistique (SLM) au lieu d'un LLM, en échangeant une certaine précision contre des temps de réponse plus rapides. Des fournisseurs comme FireworksAI se concentrent sur l'optimisation des modèles spécifiquement pour la latence. Les petits modèles de langage comme Claude 3 Haiku ou Mistral 7B Instruct gagnent également en popularité pour les applications critiques en termes de latence où le raisonnement LLM à grande échelle n'est pas nécessaire.

Recommandation : La sortie LLM en mode streaming peut réduire considérablement la latence, ce qui permet à TTS de lire la réponse générée plus tôt. Envisagez également des modèles plus rapides tels que Google Gemini Flash 8B, qui offrent des temps de latence plus faibles.

Service de synthèse vocale

Cette étape est cruciale, car le service convertit le texte en parole pour qu'il soit lu ou diffusé. Des fournisseurs comme Amazon Polly, Google TTS et Eleven Labs proposent des services de synthèse vocale, généralement en deux modes :

1. Traitement préenregistré (par lots) : convertit de grandes quantités de texte en parole en une seule opération asynchrone. Cette méthode est utile pour les Applications où le traitement en temps réel n'est pas critique, comme la génération d'audio pour les livres électroniques, les podcasts ou les annonces préenregistrées.

2. Streaming en temps réel Le streaming en temps réel : Essentiel pour les applications nécessitant une sortie vocale immédiate, telles que les assistants virtuels, les systèmes de réponse vocale interactive (IVR) et les outils de communication en temps réel.

Recommandation : La diffusion en continu en temps réel est préférable au traitement par lots pour obtenir une faible latence.

Conclusion

La latence dans les applications vocales en temps réel utilisant RAG est influencée par de nombreux facteurs, et diverses techniques d'optimisation peuvent aider à la contrôler. Le tableau ci-dessous résume la latence bidirectionnelle maximale attendue dans différentes phases de la communication vocale. Grâce à des optimisations, vous pouvez vous attendre à des améliorations significatives de la latence. Le tableau ne tient pas compte des latences introduites par l'appareil et les réseaux de liaison montante/descendante.

1. Recherche sémantique - La base de données vectorielle est basée sur MongoDB

2. LLM - sans streaming

3. LLM - en continu

En mettant en œuvre ces stratégies d'optimisation, vous pouvez réduire considérablement la latence dans les applications Voice utilisant le pipeline RAG, garantissant ainsi des conversations en temps réel plus fluides et plus efficaces.

Prendre contact

Jetez un coup d'œil à notre AI Studio de Vonage pour construire des conversations vocales à faible latence ou contactez-nous via Communauté Vonage Slack ou envoyez-nous un message sur X.