Cette IA change de langue en plein milieu de la phrase.

Posez une question à un haut-parleur intelligent en anglais, puis glissez-vous en espagnol au milieu de la phrase. La plupart des systèmes se figent, transcrivent mal ou réagissent de manière étrange dans la mauvaise langue. Les assistants vocaux grand public d'aujourd'hui fonctionnent effectivement en synchronisation monolingue : une langue par session, choisie dans un menu de paramètres ou codée en dur par un développeur.

Les humains font le contraire. Les locuteurs bilingues "changent de code" en permanence—"Peux-tu réserver la cita pour mañana ?"—sans réfléchir à quel modèle soutient quel lieu. Dans des villes comme Londres, New York ou Mexico, une seule conversation peut passer de l'anglais au polonais au français en moins de 10 secondes, et personne ne remplit d'abord un formulaire pour déclarer sa langue.

L'IA vocale réside principalement dans ce que Hugo Pod appelle le Niveau 1 : elle peut gérer plusieurs langues, mais uniquement si vous lui indiquez à l'avance laquelle attendre. Cela fonctionne pour des parcours d'appel rigides et des IVR, mais cela se dérègle dès qu'un appelant demande en anglais : « Parlez-vous espagnol ? » et passe ensuite réellement à l'espagnol. L'agent continue soit de répondre en anglais, soit, pire, altère la transcription et dérange le LLM.

Le niveau 2 est la mise à niveau : un agent multilingue qui détecte et change de langue en plein milieu d'une phrase, sans interrupteurs manuels, sans « appuyez sur 2 pour l'espagnol », sans redémarrage. Un utilisateur peut commencer en anglais, passer au polonais, puis ajouter une phrase en français, et le système suit tout cela en temps réel. Ce type de fluidité transforme un voicebot d'un panneau de configuration en une conversation.

Construire cet agent de niveau 2 nécessite trois éléments fonctionnant en parfaite synchronisation : - Un cadre intelligent comme LiveKit pour orchestrer l'audio en temps réel et la logique de l'agent - Un cerveau puissant (un LLM) capable de répondre naturellement dans de nombreuses langues - Une oreille hyper-consciente (STT) qui effectue un changement de code à faible latence et haute précision

La plupart des LLM et des moteurs de synthèse vocale gèrent déjà plusieurs langues de manière raisonnable. Le véritable point de blocage réside dans la transcription vocale, capable d'entendre « Parlez-vous espagnol ? » et de suivre sans difficulté lorsque le reste de la phrase arrive en espagnol—sans reconfiguration, sans redémarrage, juste une compréhension continue et multilingue.

Les agents multilingues de niveau 1 semblent flexibles sur le papier : un système, plusieurs langues. En pratique, ils ne fonctionnent que si vous déclarez la langue à l'avance, avant que quiconque prononce un mot. Vous configurez « espagnol », « polonais » ou « français » en tant que paramètre de session, puis toute la conversation reste bloquée sur ce choix.

Ce design apparaît partout, des arbres de téléphone IVR aux bots de support client. Vous choisissez dans un menu déroulant, appuyez sur "2 pour Español" ou touchez une icône de drapeau, et ce n'est qu'alors que le pipeline reconnaissance vocale charge les bons modèles acoustiques et linguistiques. Changez d'avis pendant l'appel ou ajoutez une autre langue, et le système vous entend mal ou ignore le changement.

Logiquement, le niveau 1 semble maladroit. Les formulaires doivent inclure un champ supplémentaire pour la « langue préférée », les flux d'appels nécessitent un menu, et les kiosques doivent avoir des fonctionnalités d'interface utilisateur juste pour commencer. Chaque étape supplémentaire augmente la friction et l'abandon ; de nombreuses applications pour consommateurs perdent des utilisateurs si l'intégration prend plus de 10 à 20 secondes.

Les agents multilingues de niveau 2 fonctionnent différemment. Ils écoutent d'abord et décident sur le vif quelle langue — ou quelles langues — vous utilisez, sans déclaration préalable. Une conversation peut commencer en anglais, passer à l'espagnol pour une question, puis glisser en polonais, et l'agent suit ces transitions en temps réel.

Ce changement fait de multilingue une compétence de conversation réelle plutôt qu'une simple fonctionnalité à cocher. Un système de niveau 2 prend en charge le « code-switching » naturel, où un utilisateur mélange les langues au sein d'une seule phrase, comme « Peux-tu envoyer la factura à mon adresse email professionnelle ? » ou « Czy mówisz hiszpański również ? » L'agent doit transcrire, raisonner et répondre de manière appropriée à chaque transition.

Pour les produits mondiaux, le niveau 2 est la norme d'excellence. Un agent peut servir des utilisateurs dans des dizaines de marchés sans avoir besoin de numéros de téléphone distincts, de robots séparés ou de règles strictes de routage linguistique. Les entreprises évitent de maintenir des flux parallèles pour l'anglais, le français et le polonais, et déploient plutôt une couche logique unique qui s'adapte à la langue parlée par l'utilisateur.

Le « Comment créer un agent vocal multilingue avec LiveKit et Gladia » de Hugo Pod cible explicitement ce modèle de niveau 2. En utilisant Gladia pour un changement de code à faible latence et LiveKit pour un audio en temps réel, sa pile vise ce standard élevé : un agent qui se comporte moins comme un formulaire et plus comme une personne.

Le code-switching décrit comment les personnes bilingues alternent entre les langues en plein milieu d'une phrase sans y penser : « Oye, did you send that report ? » ou « Ça marche, I’ll ping you later. » Les psycholinguistes le considèrent comme une caractéristique, et non un défaut — des recherches montrent que les bilingues alternent en fonction du sujet, de l'émotion ou de leur interlocuteur, souvent plusieurs fois par minute.

Pour les agents vocaux IA, ce comportement est le sainte graal. Un client hispanophone pourrait commencer en anglais pour le menu IVR, passer en espagnol pour expliquer un problème de facturation, puis revenir à l'anglais pour les numéros de carte. Tout système qui se fige sur la première langue perd la confiance, le temps et souvent l'utilisateur.

Les enjeux du monde réel sont élevés. Les centres de support globaux à Mexico, Manille ou Varsovie jonglent régulièrement avec l'anglais plus 2 à 4 langues locales sur la même ligne. Les appels de ventes internationales dans les domaines de la fintech, des voyages ou du SaaS passent entre l'anglais, l'hindi et des dialectes régionaux. Les services publics dans des villes comme New York ou Londres doivent gérer des conversations en langues mixtes dans les domaines de la santé, du logement et de l'éducation.

Techniquement, c'est brutal car l'audio brut est ambigu sans contexte linguistique. Un extrait de deux secondes peut correspondre à des mots plausibles en anglais, en polonais ou en portugais, chacun ayant des significations différentes. Le bruit de fond, les accents et le jargon de domaine multiplient la confusion, si bien que les modèles naïfs "se figent" dans la mauvaise langue et ne se rétablissent jamais.

Les trois piliers—STT (speech-to-text), LLM et TTS—doivent rester parfaitement synchronisés sur le choix de la langue. Les LLM gèrent déjà bien les invites multilingues, et les moteurs TTS modernes comme 11 Labs peuvent parler un polonais ou un espagnol convaincant une fois qu'ils ont un texte propre. La reconnaissance vocale est le véritable défi.

La reconnaissance vocale multilingue doit détecter les limites de langue en temps réel, parfois sur un seul mot, tout en maintenant une latence inférieure à ~300 ms pour un appel naturel. Elle doit décider "était-ce 'no' en anglais ou 'não' en portugais ?" en temps réel et changer de modèles ou de vocabulaire instantanément. Des outils comme les modèles de changement de code de Gladia et les cadres documentés dans Voice AI quickstart | LiveKit docs émergent, mais le changement de code parfait reste un problème de frontière.

La voix IA moderne de code-switching repose sur quatre piliers : le routage en temps réel, la reconnaissance vocale, le raisonnement linguistique et la parole synthétique. Échangez l'un d'eux pour un composant plus faible et toute l'illusion d'une conversation fluide et bilingue se brise instantanément.

Au centre se trouve LiveKit, le cadre de communication en temps réel qui agit comme le système nerveux de l'agent. Il gère les flux audio à faible latence, l'état de la session et la pression arrière, veillant à ce que les paquets audio, les transcriptions et les réponses arrivent en moins de quelques centaines de millisecondes plutôt qu'en secondes.

LiveKit relie trois services spécialisés qui possèdent chacun une partie différente de l'ensemble : - Gladia pour la reconnaissance vocale - OpenAI GPT-4.1 pour la compréhension du langage - 11Labs pour la synthèse vocale

Gladia agit comme les oreilles de l'agent, transcrivant en continu l'audio brut en texte pendant que l'utilisateur continue de parler. Son modèle multilingue, tel que la variante SEA SALARIA 1, prend en charge le code-switching dans des dizaines de langues, détectant lorsqu'une phrase passe de l'anglais à l'espagnol puis au polonais sans réinitialiser la session.

Cette capacité de passer d'une langue à l'autre est importante car la transcription vocale en texte est le maillon le plus fragile de cette chaîne. Si Gladia identifie mal l'espagnol comme de l'anglais avec accent, GPT-4.1 ne voit jamais les mots corrects, et l'ensemble de l'expérience "multilingue" s'effondre en non-sens ou en questions de clarification maladroites.

Une fois que Gladia émet du texte, OpenAI GPT-4.1 intervient en tant que cerveau. Le LLM suit l'historique des conversations, l'intention de l'utilisateur et les variations linguistiques, puis décide non seulement de ce qu'il faut dire, mais aussi dans quelle langue le dire. Une incitation peut amener GPT-4.1 à imiter automatiquement la langue de l'utilisateur ou à changer lorsqu'on le lui demande explicitement (« ¿Puedes hablar polaco ? »).

11Labs boucle la boucle en tant que voix. Alimentez-le avec des tokens en polonais, en français ou en anglais et il renvoie un audio au son naturel dans cette même langue, en utilisant la même voix synthétique, de sorte que l'agent semble être une personne cohérente, et non un patchwork de différents systèmes.

Ensemble, LiveKit, Gladia, GPT-4.1 et 11Labs forment un circuit en temps réel très efficace. L'audio entre, le texte sensible à la langue circule, et la parole correctement localisée sort—suffisamment rapidement pour que le changement de langue semble naturel, comme s'il s'agissait de changer d'application.

La conversion de la parole en texte décide discrètement si un agent vocal multilingue fonctionne ou s'effondre. Pour les systèmes de niveau 2 qui doivent suivre un appelant de l'anglais à l'espagnol puis au polonais en une seule phrase, la conversion de la parole en texte est de loin la partie la plus difficile de l'ensemble. Les modèles de langage de grande taille (LLMs) et la synthèse vocale (TTS) peuvent déjà jongler avec des dizaines de langues à partir de texte clair ; la conversion de la parole en texte doit le faire à partir d'audio bruyant, superposé et fortement accentué en temps réel.

Le modèle sea-salaria-v1 de Gladia se situe à ce point de congestion. Il prend en charge plus de 40 langues dès le départ, avec un changement de code natif, de sorte qu'une phrase comme « Peux-tu appeler mi mamá à Madrid ? » ne le trouble pas en une langue déformée. Au lieu de cela, il segmente et transcrit proprement l'anglais et l'espagnol tels qu'ils apparaissent réellement dans la forme d'onde.

Le routage régional est là où sea-salaria-v1 devient viable pour les produits en direct plutôt que pour de simples démonstrations. Gladia vous permet d'attribuer le traitement à des régions spécifiques, comme l'UE Ouest, afin que si vos utilisateurs se trouvent à Londres ou à Paris, vous évitiez la pénalité de 100 à 200 ms des sauts transatlantiques. Pour un agent vocal, réduire cette latence permet de garder les réponses aller-retour en dessous du seuil de ~300 ms où la « pause IA » devient évidente.

Sans un moteur STT capable de détecter les changements de langue directement à partir de l'audio, rien d'autre dans le processus n'a jamais la chance d'être intelligent. Le LLM ne voit que la transcription textuelle qu'il reçoit ; si le STT étiquette à tort le polonais comme anglais et génère des jetons incompréhensibles, même le meilleur modèle répondra avec confiance dans la mauvaise langue. TTS répète alors joyeusement cette erreur à l'utilisateur, rendant l'échec irréversible.

Le support de changement de code au niveau de la couche STT prévient également les solutions fragiles de pré-routage. Vous n'avez plus besoin de deviner la langue d'un appelant à partir de son numéro de téléphone, d'un choix de menu ou de la première phrase. Sea-salaria-v1 peut écouter dès la première seconde, reconnaître que l'utilisateur vient de passer d'instructions en anglais à un français rapide, et ajuster les jeux de caractères et les modèles linguistiques en temps réel.

Deepgram et d'autres fournisseurs de STT proposent effectivement des fonctionnalités multilingues et même de changement de code, qui fonctionnent pour de nombreux cas d'utilisation. Cependant, pour cet agent de niveau 2 spécifique, Gladia a remporté la mise en termes de précision de transcription brute sur des podcasts audio multilingues, en particulier avec des changements rapides et des combinaisons moins courantes comme l'anglais-polonais. Lorsque votre expérience entière dépend de la réussite de ces cas particuliers, cet écart de précision est décisif.

LiveKit n'agit plus seulement comme un routeur WebRTC ; il se comporte comme un agent d'exécution qui possède l'intégralité de la boucle d'appel. Au lieu de relier manuellement la STT, le LLM et la TTS, vous définissez un agent qui réagit aux événements—cadres audio, messages, délais—et LiveKit orchestre le reste en temps réel.

Au centre se trouve le LiveKit Agent Framework, qui exécute votre logique Python (ou Node) à proximité du pipeline multimédia. Cette proximité est importante : moins d'allers-retours entre les médias, l'inférence et la logique métier se traduisent par une latence de bout en bout réduite, ce qui est une question de vie ou de mort pour un agent vocal capable de changer de code.

LiveKit Inference s'intègre directement dans ce processus en tant que couche LLM et TTS gérée. Vous dirigez votre agent vers des modèles—OpenAI, locaux ou hébergés par des fournisseurs—et LiveKit s'occupe de la diffusion des tokens et du retour audio sans que vous ayez à jongler avec trois SDK différents.

L'utilisation de LiveKit Inference évite également un tas de maux de tête opérationnels. Vous évitez les limites de taux par fournisseur sur les appels LLM et TTS, consolidez l'utilisation en une seule facture et bénéficiez souvent d'une latence réduite car LiveKit communique avec les fournisseurs via des liens de niveau entreprise plutôt qu'à travers des passerelles API publiques.

La consolidation de la facturation n'est pas seulement une question de commodité ; elle modifie votre architecture. Au lieu de créer des logiques de limitation et de secours sur mesure pour chaque fournisseur, vous considérez l'inférence comme un seul pool de ressources avec des quotas prévisibles et une surveillance.

La structure de LiveKit rend l'échange de composants presque mécanique. Dans agent.py de Hugo Pod, Gladia se connecte en tant que fournisseur STT via un simple bloc de configuration : nom du modèle (sea salaria 1), région (EU Ouest) et une liste de langues prises en charge.

Ce design vous permet d'expérimenter de manière agressive. Vous souhaitez tester A/B deux voix TTS ou deux invites LLM ? Il vous suffit de modifier quelques lignes dans la définition de l'agent ; LiveKit gère toujours l'état de session, le routage multimédia et la logique de reconnexion.

Pour les équipes venant de WebRTC brut ou de services gRPC faits maison, c'est un niveau d'abstraction différent. Vous cessez de penser en sockets et en codecs et commencez à penser en « sessions d'agent » et en « tâches » qui peuvent être mises à l'échelle horizontalement.

La documentation de LiveKit s'appuie sur ce modèle ; Construire des agents vocaux | Documentation LiveKit explore des schémas tels que les tâches en arrière-plan, le routage multi-agents et des outils personnalisés que vous pouvez réutiliser dans des projets multilingues.

Les LLMs modernes n'ont presque aucun mal à jongler avec les langues. Les modèles de la classe GPT-4 s'entraînent sur des trillions de tokens extraits du web multilingue, de livres, de forums et de dépôts de code, couvrant tout, de l'anglais et de l'espagnol au polonais et à des dialectes spécifiques. Si vous demandez : « Répondez en français, puis résumez en anglais », ils le font simplement, token par token.

Ce comportement multilingue n'est pas une fonctionnalité ajoutée ; il découle de la façon dont ces modèles apprennent. Pendant l'entraînement, ils voient des concepts parallèles exprimés dans différentes langues et optimisent un immense espace d'intégration partagé. Ainsi, lorsqu'un utilisateur change de langue en plein milieu d'une phrase, passant de « Pouvez-vous réserver un vol ? » à « para mañana a Madrid », le modèle continue simplement à prédire le prochain token le plus probable, désormais en espagnol.

La dynamique de demande vous offre un contrôle précis. Vous pouvez indiquer au LLM : « Répondez toujours dans la langue de l'appelant » ou « Parlez anglais mais reflétez toutes les phrases étrangères citées. » Avec un seul message système, la même instance de GPT-4 peut gérer le support client en allemand, l'intégration technique en portugais et les questions de suivi en anglais, le tout dans une session continue.

Du côté de la sortie, les systèmes de TTS comme 11Labs sont encore plus simples. Ils n'ont pas besoin de déduire la langue que vous vouliez; ils synthétisent simplement la langue que le texte utilise déjà. Alimentez-les avec du texte polonais, vous obtenez de l'audio polonais ; remplacez-le par du français, vous obtenez du français, souvent avec un timbre vocal cohérent à travers les langues.

La synthèse vocale multilingue dépend principalement de deux choses : la couverture linguistique et la qualité des voix. Si un fournisseur prend en charge, par exemple, 28 langues et des voix cross-linguistiques, votre application peut conserver la même “personnalité d'agent” tout en passant de l'anglais à l'espagnol puis au polonais en temps réel. Pas de reconfiguration, pas de voix séparée par langue.

Toute cette élégance s'effondre si les mots envoyés au LLM sont erronés. La véritable magie—et le véritable risque—se situe en amont dans STT, où des modèles comme Gladia doivent détecter les changements de langue, les segmenter correctement et transmettre au LLM des transcriptions propres et adaptées au code-switching.

Agent.py agit comme le schéma de câblage pour cette configuration multilingue, et presque toute la magie provient de la configuration, pas d'algorithmes personnalisés. Hugo définit un seul `Agent` qui lie GladiaSpeechToText, les services d'inférence de LiveKit et quelques contrôles de conversation dans une boucle en temps réel.

La reconnaissance vocale bénéficie d'un réglage des plus détaillés. Le bloc `GladiaSpeechToText` spécifie trois paramètres critiques : `model="sea-salaria-1"`, `region="eu-west"` et un tableau `languages`. Le modèle `sea-salaria-1` est le cheval de bataille de Gladia pour le changement de code, conçu pour gérer les alternances en milieu de phrase entre l'anglais, l'espagnol, le polonais et d'autres langues.

La sélection de la région est importante pour la latence. En fixant `region="eu-west"` depuis Londres, Hugo maintient les temps de réponse bas au lieu de faire rebondir l'audio à travers l'Atlantique vers un point de terminaison par défaut aux États-Unis. De nombreux fournisseurs de STT cachent le routage régional ; Gladia l'expose directement, ce qui est rare et extrêmement utile pour la voix en temps réel.

Le paramètre `languages` est celui qui fait passer ce système de la catégorie 1 à la catégorie 2. Au lieu de dire au modèle "cet appel est en français", Hugo transmet une liste d'options autorisées, par exemple : - `"en"` - `"fr"` - `"es"` - `"pl"` Gladia détecte ensuite automatiquement la langue parlée à tout moment et adapte les règles de transcription en temps réel.

Le côté de LiveKit semble presque ennuyeux par rapport, ce qui est justement le but. Pour l'inférence LLM, Hugo connecte un client `LiveKitInference` avec un modèle tel que `"gpt-4o-realtime-preview"`, accompagné d'un court message système : "Vous êtes un assistant vocal utile." Pas de drapeaux multilingues supplémentaires, pas de logique de routage, juste un modèle qui comprend déjà des dizaines de langues.

La synthèse vocale utilise le même principe : un client TTS `LiveKitInference` pointant vers un modèle tel que `"eleven_multilingual_v2"` avec un identifiant de voix choisi. Tant que le moteur TTS prend en charge la langue cible, il suffit d'alimenter le texte en polonais ou en espagnol, ce qui fait que le code reste presque uniquement basé sur la configuration.

Le partage de la parole est un aspect où de petites modifications de configuration peuvent avoir un impact significatif sur l'expérience utilisateur. Hugo change le modèle `turn_detection` de LiveKit de `"english"` à `"multilingual"`, permettant à l'agent de détecter correctement les pauses et la fin des énoncés dans les langues non anglaises et les phrases en langues mélangées.

Enfin, `preemptive_generation=False` désactive l'habitude de l'agent de parler par-dessus les utilisateurs. De nombreux systèmes en temps réel commencent à parler dès qu'ils "pensent" que vous avez fini ; cela perturbe le passage d'une langue à l'autre lorsque les utilisateurs ajoutent une clause dans une autre langue. Forcer l'agent à attendre une frontière de tour claire maintient les conversations naturelles et empêche les interruptions en plein milieu d'une phrase.

Le moment de code-switching dans la démo commence de manière suffisamment innocente. L'utilisateur ouvre en anglais, discutant avec l'agent comme s'il s'agissait de n'importe quel autre système de niveau 1. Puis vient la phrase pivot qui pourrait briser la plupart des voix de production : "Je voulais juste savoir si vous pouvez parler polonais."

Au lieu de répondre en anglais ou de se figer, l'agent s'adapte instantanément. Il répond en polonais fluide et naturel, avec une phonétique et une prosodie correctes provenant de la pile TTS, signalant que le LLM, l'invite et les paramètres de voix ont tous accepté le changement de langue sans réinitialisation. Pas de bascule manuelle de la langue, pas de réinitialisation, pas de délai de "changement de langue, veuillez patienter".

Ce qui compte davantage, c'est ce qui se passe ensuite. L'utilisateur continue en polonais, s'engageant dans un échange complet qui reste entièrement dans cette langue. L'agent comprend les phrases de suivi en polonais, maintient le contexte et renvoie des réponses polonaises cohérentes et pertinentes - exactement le comportement de niveau 2 que les produits multilingues promettent mais livrent rarement.

Sous le capot, cette performance repose sur STT. Le modèle de Gladia reçoit un audio qui commence en anglais, puis, en plein milieu de la conversation, passe au polonais, tout en produisant des transcriptions précises avec une faible latence. Cette qualité de transcription permet au LLM de maintenir un état de conversation unique au lieu de créer des fils « mode anglais » et « mode polonais ».

Les journaux de l'exécution révèlent un aspect intrigant : « le détecteur de tournants ne prend pas en charge la langue polonaise ». La détection de tournants détermine quand un utilisateur a fini de parler, donc cet avertissement signifie qu'un composant secondaire ne sait segmenter que certaines langues. Malgré cela, le système ne présente jamais de bégaiement visible car le pipeline STT principal continue de reconnaître et de transcrire le polonais de manière fiable.

C'est un point architectural subtil mais important. Vous pouvez avoir des éléments non critiques — comme un détecteur de tour limité par la langue — qui lancent des avertissements pendant que le moteur de transcription principal **Gladia** continue de fonctionner parfaitement dans toutes les langues. Dans les déploiements réels, cette séparation des préoccupations signifie que vous pouvez itérer sur des modules accessoires sans risquer de compromettre le cerveau multilingue qui alimente réellement l'expérience.

Les agents polyglottes cessent d'être un simple outil de recherche une fois que vous intégrez un cadre de haut niveau comme LiveKit dans un moteur STT spécialement conçu comme Gladia. LiveKit gère les aspects techniques complexes en temps réel—WebRTC, sessions, cycle de vie des agents—tandis que le modèle à faible latence et de changement de langue de Gladia (comme sa variante sea-salaria-1) accomplit la tâche que les modèles génériques peinent encore à réaliser : détecter et transcrire plusieurs langues dans la même phrase. Cette association transforme un simple bot vocal en un agent de niveau 2 qui suit la conversation humaine au lieu de forcer les humains à gérer les paramètres du système.

Empilés ensemble, ces éléments débloquent des produits qui fonctionnent réellement à l'échelle mondiale. Une seule ligne de support peut diriger les clients de Mexico, Varsovie et Paris vers le même agent vocal multilingue, qui les suit lorsqu'ils passent de l'anglais pour les noms de produits à leur langue maternelle pour tout le reste. Pas d'arbres IVR, pas de « Appuyez sur 3 pour l'espagnol », juste un point d'accès qui s'adapte en temps réel.

Les réunions évoluent également. Imaginez un compagnon Zoom ou Meet qui écoute un appel de 10 personnes où les participants échangent entre l'anglais, l'allemand et le polonais, tout en produisant : - Des sous-titres en direct dans la langue préférée de chaque participant - Des transcriptions consultables étiquetées par intervenant et langue - Des résumés qui conservent quand et pourquoi le changement de code s'est produit.

Les assistants pour consommateurs en bénéficient tout autant. Une famille bilingue peut communiquer avec un appareil domestique en anglais, passer au français en pleine phrase pour s'adresser à un grand-parent, puis revenir sans avoir besoin de redémarrer le mot de réveil ou de changer les paramètres de l'application. L'accessibilité augmente lorsque les utilisateurs ayant une maîtrise limitée d'une langue « par défaut » n'ont plus besoin de s'y tenir simplement pour être compris.

Les barrières qui nécessitaient autrefois un laboratoire de recherche—reconnaissance vocale automatique rapide, code-switching robuste, streaming à faible latence—s'intègrent désormais dans un projet de weekend. LiveKit abstrait la pile en temps réel ; Gladia gère la reconnaissance vocale multilingue ; les LLM et TTS grand public parlent déjà des dizaines de langues dès leur sortie de boîte. La partie difficile n'est plus “Cela peut-il être construit ?” mais “Que doit réellement faire cet agent ?”

Vous pouvez répondre à cela vous-même. Consultez le dépôt GitHub de "Comment créer un agent vocal multilingue avec LiveKit et Gladia", insérez vos propres invites et voix, et commencez à expédier des agents qui parlent aux utilisateurs de la manière dont les utilisateurs se parlent déjà entre eux.

Qu'est-ce que le code-switching en intelligence artificielle ?

Le code-switching est la capacité d'un agent vocal AI à détecter et à changer entre plusieurs langues au sein de la même conversation, tout comme le ferait une personne bilingue. Cela nécessite une technologie avancée de conversion de la parole en texte.

Pourquoi Gladia est-il recommandé pour les agents vocaux multilingues ?

Le système de reconnaissance vocale de Gladia se distingue par sa grande précision dans de nombreuses langues, sa faible latence et son soutien spécifique au code-switching, qui est la caractéristique la plus essentielle pour ce type d'agent.

Quel est le rôle de LiveKit dans ce projet ?

LiveKit agit comme le cadre sous-jacent pour l'agent vocal, gérant la communication en temps réel (WebRTC) et fournissant un kit de développement pour les agents. Sa fonctionnalité d'inférence simplifie également l'utilisation de modèles tels que GPT-4 et 11Labs en intermédant les appels API.

Puis-je utiliser un autre LLM ou TTS avec cette configuration LiveKit ?

Oui. Le framework de LiveKit est flexible. Bien que le tutoriel utilise le GPT-4 d'OpenAI et 11Labs via LiveKit Inference, vous pouvez intégrer d'autres modèles de langue et services de synthèse vocale qui répondent à vos besoins.