⚡ electrical engineering

Praxy Voice: Voice-Prompt Recovery + BUPS for Commercial-Class Indic TTS from a Frozen Non-Indic Base at Zero Commercial-Training-Data Cost

Praxy Voice atteint des performances de synthèse vocale de niveau commercial pour le télougou, le tamoul et l'hindi en combinant un espace phonémique unifié brahmique (BUPS) pour la conversion de script, un adaptateur LoRA uniquement textuel entraîné sur des données licenciées et une recette d'échantillonnage de prompts vocaux spécifique, le tout sans nécessiter de données d'entraînement commerciales ni de réentraînement du décodeur acoustique.

Auteurs originaux : Venkata Pushpak Teja Menta

Publié 2026-04-29

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Venkata Pushpak Teja Menta

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un chef de classe mondiale (l'IA Chatterbox) capable de préparer des plats délicieux pour 23 langues différentes, comme l'anglais, l'espagnol et le français. Cependant, ce chef n'a jamais cuisiné pour trois régions spécifiques : le télougou, le tamoul et l'hindi. Si vous lui demandez de préparer un plat télougou, il refuse soit, soit vous sert un mélange étrange et immangeable d'ingrédients car il ne connaît pas les recettes locales.

L'article présente Praxy Voice, un « hack de cuisine » astucieux qui permet à ce même chef de préparer des plats parfaits en télougou, tamoul et hindi sans embaucher un nouveau chef, sans acheter de nouveaux ingrédients (données d'entraînement commerciales) et sans apprendre au chef à cuisiner à partir de zéro.

Voici comment ils ont procédé, décomposé en trois étapes simples :

1. Le Traducteur Universel (BUPS)

Le Problème : Le chef ne comprend que les lettres latines (A, B, C). Si vous écrivez une recette en script télougou (qui ressemble à des cercles et des lignes), le chef la voit comme du charabia.
La Solution : L'équipe a construit un outil appelé BUPS. Imaginez-le comme un traducteur magique qui convertit instantanément les scripts télougou, tamoul et hindi en lettres latines avant que le chef ne les voie.

Analogie : C'est comme prendre une lettre manuscrite dans un script étranger, la numériser, et faire en sorte qu'un ordinateur la tape instantanément en anglais pour que le chef puisse la lire. Le sens et les sons restent les mêmes, mais maintenant le chef peut réellement traiter les instructions.

2. Le Sous-Chef Spécialisé (Adaptateur LoRA)

Le Problème : Même si le chef peut maintenant lire la recette (grâce à BUPS), il ne sait toujours pas comment la cuisiner. Il pourrait lire le mot « curry » mais le préparer comme un ragoût car il n'a jamais fait de cuisine indienne auparavant.
La Solution : L'équipe a ajouté un tout petit assistant spécialisé (un adaptateur LoRA) à la partie du cerveau du chef qui lit les recettes.

La Magie : Ils ont entraîné cet assistant sur environ 1 220 heures d'audio indien sous licence (comme des podcasts et des actualités du domaine public).
L'Astuce : Puisque le chef ne connaît ni le télougou ni le tamoul, l'équipe a demandé à l'assistant de faire semblant que les recettes étaient en hindi (que le chef connaît). Comme le télougou et l'hindi se ressemblent quelque peu, le chef utilise son style de « cuisine hindi » existant comme base, et l'assistant l'ajuste juste assez pour que cela ressemble au télougou ou au tamoul.
Résultat : Cet assistant est minuscule (moins de 1 % de la puissance cérébrale totale du chef) mais fait une énorme différence.

3. La Recette du « Test de Goût » (Prompt Vocal et Config B)

Le Problème : Même avec le traducteur et l'assistant, la voix du chef sonne un peu « étrangère » ou robotique lorsqu'il parle ces nouvelles langues. C'est intelligible, mais il manque le rythme naturel et l'accent d'un locuteur natif.
La Solution : L'équipe a découvert une « recette » spécifique pour l'étape finale :

Le Prompt Vocal : Avant de cuisiner, vous faites écouter au chef un extrait de 8 à 11 secondes de la voix d'un locuteur natif. Cela agit comme un « test de goût », disant au chef : « C'est exactement ainsi que le plat doit sonner. »
Les Réglages « Config B » : Ils ont ajusté trois molettes sur le four du chef (température, exagération et filtrage).
- Analogie : Imaginez que le chef cuisinait à feu doux. L'équipe a légèrement augmenté le feu et ajusté l'assaisonnement pour faire ressortir les saveurs. Ces réglages spécifiques (exagération 0,7, température 0,6, min_p 0,1) se sont révélés être le « juste milieu » pour rendre la voix naturelle.

La Stratégie « Deux Branches »

L'équipe a remarqué quelque chose d'intéressant : s'ils utilisaient cet assistant spécial sur l'hindi (que le chef sait déjà cuisiner), le résultat devenait en fait pire. L'assistant perturbait le chef.

La Solution : Ils ont construit un commutateur intelligent.
- Si l'entrée est en télougou ou tamoul : Utilisez le Traducteur + l'Assistant + le Prompt Vocal.
- Si l'entrée est en hindi : Ignorez l'assistant et utilisez simplement le chef original + le Prompt Vocal.
- Cela garantit la meilleure qualité pour chaque langue.

Gestion du Problème des « Langues Mixtes »

En Inde, les gens mélangent souvent des mots anglais dans des phrases indiennes (par exemple : « J'ai envoyé un message WhatsApp »).

Le Problème : Le chef principal (Chatterbox) est perturbé par les mots anglais mélangés et les supprime silencieusement.
La Solution : Pour ces phrases mixtes, ils utilisent un autre chef pré-entraîné (IndicF5) qui gère mieux les langues mixtes. Cependant, ce chef a aussi du mal avec les mots anglais écrits en script latin.
Le Hack : Ils utilisent un petit outil IA pour réécrire les mots anglais en script indien de manière phonétique (par exemple, changer « WhatsApp » en « व्हाट्सऐप ») avant de les donner au chef. Cela empêche le chef de supprimer les mots.

Les Résultats

Lorsqu'ils ont testé ce système contre les meilleurs systèmes de voix commerciaux (comme ElevenLabs ou Cartesia) :

Télougou : Il a fait moins d'erreurs de prononciation que les leaders commerciaux.
Tamoul : Il a géré un son spécifique difficile (« zha ») beaucoup mieux que la concurrence.
Hindi : Il a égalé les meilleurs systèmes commerciaux en compréhension et en clarté.

Le Fond du Problème :
Les auteurs ont prouvé que vous n'avez pas besoin de millions de dollars ni de milliers d'heures d'entraînement pour obtenir une voix « de qualité commerciale » pour les langues indiennes. En utilisant un traducteur intelligent, un petit assistant spécialisé et une recette spécifique de « prompt vocal », ils ont transformé une IA à usage général en un acteur de voix indien sonnant comme un natif gratuitement (en utilisant uniquement des outils open-source et des données publiques).

Ils ont publié tout le code et les poids de l'« assistant » pour que tout le monde puisse les utiliser.

1. Énoncé du problème

La construction de systèmes de synthèse vocale (TTS) de haute qualité pour les langues indiques (spécifiquement le télougou, le tamoul et l'hindi) nécessite généralement l'une des deux approches suivantes :

Entraînement à partir de zéro : Nécessitant des centaines à des milliers d'heures GPU et des ensembles de données massifs (par exemple, Indic Parler-TTS, IndicF5).
Utilisation d'API commerciales fermées : Qui engendrent des coûts par appel et manquent de contrôle sur les données.

Les bases multilingues open-source existantes, telles que ResembleAI Chatterbox, prennent en charge 23 langues (y compris l'hindi) mais échouent à supporter nativement le télougou et le tamoul. De plus, elles manquent de capacités de tokenisation pour les scripts brahmaniques (dévanagari, télougou, tamoul, etc.), entraînant souvent des erreurs de tokenisation ou des « déchets byte-BPE » lors du traitement de ces langues. Les auteurs se demandent : Quelle est l'intervention minimale requise pour amener une base multilingue figée et non native aux langues indiques à une performance de classe commerciale sur le télougou, le tamoul et l'hindi, sans entraîner un nouveau décodeur acoustique ni utiliser de données d'entraînement TTS commerciales ?

2. Méthodologie

Les auteurs proposent un pipeline d'inférence à trois branches qui combine trois composants d'ingénierie en une seule recette. L'innovation centrale réside dans l'adaptation d'un modèle figé via des mises à jour minimales de paramètres et des heuristiques au moment de l'inférence.

A. BUPS (Espace Phonémique Unifié Brahmanique)

Défi : Le tokeniseur de Chatterbox ne peut pas traiter les scripts bruts télougou ou tamoul.
Solution : Une couche de routage déterministe qui convertit les scripts brahmaniques (dévanagari, télougou, tamoul, kannada, bengali, gujarati, malayalam) en chaînes latines romanisées ISO-15919 au moment de la tokenisation.
Mécanisme : Il segmente le texte d'entrée par script, translittère les segments brahmaniques en latin en utilisant des diacritiques (préservant la phonologie), et fait passer les segments non brahmaniques inchangés. Cela permet aux chemins de tokeniseur latin existants du modèle de traiter le texte indien sans modifier les poids du modèle.

B. Adaptation LoRA (Tête de texte uniquement)

Cible : Uniquement le prédicteur de tokens de texte (transformateur t3) de la base Chatterbox. Le décodeur acoustique (s3gen) et l'encodeur vocal (ve) restent figés.
Configuration : Un adaptateur d'adaptation à faible rang (LoRA) appliqué aux projections d'attention ( $q, k, v, o$ $q, k, v, o$ ).
- Paramètres entraînables : 7,86 M (0,97 % de la base de 810 M).
- Données d'entraînement : ~1 220 heures d'audio indien licencié (IndicTTS, Rasa, FLEURS, Shrutilipi). Zéro donnée TTS commerciale n'a été utilisée.
- Conditionnement linguistique : Les textes en télougou et en tamoul sont conditionnés avec un ID de langue proxy hindi (hi). Cela achemine l'adaptation à travers la variété acoustique la plus proche que la base possède déjà.
Résultat : La tête de texte apprend à émettre des tokens de parole alignés sur la phonologie indienne, tandis que le décodeur figé génère l'audio.

C. Récupération de prompt vocal & Configuration B

Problème : Même avec BUPS et LoRA, l'inférence par défaut produit une parole « plate » ou avec un « accent étranger » car le décodeur figé manque de priors acoustiques indiens natifs.
Solution : Une recette d'inférence impliquant :
1. Prompt vocal : Fournir un extrait audio de référence de 8 à 11 secondes dans la langue cible (même langue que le texte d'entrée). Cela conditionne le décodeur sur la prosodie et le timbre natifs.
2. Remplacements d'échantillonnage Config B : Trois ajustements spécifiques de paramètres pour stabiliser la génération :
  - exaggeration : 0,7 (augmente le contour prosodique).
  - temperature : 0,6 (resserre la distribution).
  - min_p : 0,1 (filtre les tokens à faible probabilité causant une dérive des phonèmes).

D. Architecture de routage

Le système déploie une architecture à deux branches pour les entrées en script pur et une troisième branche pour les entrées mixtes (code-mixed) :

Télougou/Tamoul (Script pur) : Routage via BUPS + LoRA (Proxy Hi).
Hindi (Script pur) : Routage via Chatterbox Vanilla (Sans LoRA, Sans BUPS). Crucialement, l'application de LoRA à l'hindi dégrade la précision sémantique, une branche de contrôle négatif est donc utilisée.
Mixte (par exemple, Hindi + Anglais) : Routage vers IndicF5 (un modèle de matching de flux indien natif) précédé par un préprocesseur de translittération piloté par Haiku qui convertit les mots anglais en orthographes phonétiques en script natif (par exemple, « WhatsApp » $\to$ « व्हाट्सऐप »).

3. Contributions clés

BUPS : La première application de la romanisation ISO-15919 comme mécanisme de routage pour permettre le support indien dans les bases TTS tokenisées en latin.
LoRA à intervention minimale : Une stratégie adaptant uniquement la tête de texte d'un modèle multilingue figé en utilisant un ID de langue proxy, atteignant une qualité commerciale sans entraînement de décodeur acoustique.
Recette de récupération de prompt vocal : Démontre que des remplacements d'échantillonnage spécifiques (Config B) combinés à des prompts vocaux dans la même langue peuvent récupérer des acoustiques de classe commerciale à partir d'un décodeur figé.
Déploiement à deux branches : Une architecture novatrice qui commute dynamiquement entre les modèles adaptés par LoRA et les modèles vanille en fonction de la langue, validée par un contrôle négatif montrant que LoRA nuit aux performances en hindi.
Solution pour le mixage de codes : Un pipeline de prétraitement qui réduit le LLM-WER sur les entrées mixtes de ~0,80 à ~0,14–0,27 en translittérant les segments anglais vers les scripts natifs.
Publication ouverte : Les poids LoRA R6 (Apache-2.0) et le code d'inférence (MIT) sont disponibles publiquement.

4. Résultats

Évalués sur le benchmark PSP (Profil de Substitution de Phonèmes) et les métriques d'intelligibilité :

Télougou :
- Effondrement rétroflexe : 26,7 % (Praxy) contre 33,3 % (Sarvam Bulbul) et 50 % (Cartesia). Praxy se classe premier.
- FAD (Distance Audio Fréchet) : 291,3 (comparable aux bases commerciales).
Tamoul :
- Effondrement Zha : 71 % (Praxy) contre 86 % (Trio Commercial). C'est le gain par dimension le plus clair observé.
- PSD (Divergence de Signature Prosodique) : 71,2 (correspond à Sarvam Bulbul).
Hindi :
- LLM-WER : 0,025 (Praxy Vanilla) égalise Cartesia Sonic-3.
- Note : La branche LoRA a considérablement dégradé les performances en hindi (LLM-WER 0,334), validant la nécessité d'un routage à deux branches.
Mixte :
- Le LLM-WER est passé de 0,80–0,85 (IndicF5 brut) à 0,14–0,27 avec le préprocesseur de translittération.

5. Signification

Efficacité des coûts : Atteint un TTS de qualité commerciale pour les principales langues indiennes en utilisant zéro donnée d'entraînement commerciale et un calcul minimal (un seul A100, ~11 heures, ~45 $).
Accessibilité : Démocratise l'accès à un TTS indien de haute qualité pour les développeurs qui ne peuvent pas se permettre le calcul ou les données nécessaires pour entraîner des modèles à partir de zéro.
Insight méthodologique : Prouve que pour les bases multilingues, l'adaptation de la tête de texte combinée à un conditionnement acoustique au moment de l'inférence (prompts vocaux) suffit à combler le fossé pour les langues non supportées, à condition que la base possède une variété acoustique « suffisamment proche » (par exemple, l'hindi pour le télougou/le tamoul).
Contrôle négatif : Le papier démontre rigoureusement que « plus d'adaptation » n'est pas toujours mieux ; l'adaptateur LoRA nuit activement aux performances sur les langues que la base supporte déjà (hindi), nécessitant une stratégie de routage conditionnel.

Les auteurs concluent que cette approche « à intervention minimale » comble efficacement le fossé entre le TTS open-source et commercial pour les entrées indiennes en script pur, avec une solution distincte et peu coûteuse pour les scénarios mixtes.