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

A continuación se presenta un resumen técnico detallado del artículo "Praxy Voice: Recuperación de Prompt de Voz + BUPS para TTS Indic de Clase Comercial desde una Base No Indic Congelada a Coste Cero de Datos Comerciales de Entrenamiento".

1. Declaración del Problema

Desarrollar sistemas de Texto a Voz (TTS) de alta calidad para lenguas indias (específicamente telugu, tamil y hindi) generalmente requiere:

1. Entrenamiento desde cero: Que exige cientos a miles de horas de GPU y conjuntos de datos masivos (por ejemplo, Indic Parler-TTS, IndicF5).
2. Uso de APIs comerciales cerradas: Que incurren en costos por llamada y carecen de control de datos.

Las bases multilingües de código abierto existentes, como ResembleAI Chatterbox, soportan 23 idiomas (incluido el hindi) pero no admiten nativamente el telugu y el tamil. Además, carecen de capacidades de tokenización para escrituras brahmicas (devanagari, telugu, tamil, etc.), lo que a menudo resulta en errores de tokenización o "basura byte-BPE" al procesar estos idiomas. Los autores preguntan: ¿Cuál es la intervención mínima requerida para llevar una base multilingüe congelada y no nativa india a un rendimiento de clase comercial en telugu, tamil y hindi sin entrenar un nuevo decodificador acústico ni utilizar datos de entrenamiento de TTS comerciales?

2. Metodología

Los autores proponen una tubería de inferencia de tres ramas que combina tres componentes de ingeniería en una sola receta. La innovación central es adaptar un modelo congelado mediante actualizaciones mínimas de parámetros y heurísticas en tiempo de inferencia.

A. BUPS (Espacio Fonémico Unificado Brahmico)

• Desafío: El tokenizador de Chatterbox no puede procesar scripts nativos de telugu o tamil.
• Solución: Una capa de enrutamiento determinista que convierte los scripts brahmicos (devanagari, telugu, tamil, kannada, bengalí, gujarati, malayalam) en cadenas latinas romanizadas ISO-15919 en el momento de la tokenización.
• Mecanismo: Segmenta el texto de entrada por script, translitera los tramos brahmicos a latín utilizando diacríticos (preservando la fonología) y pasa los tramos no brahmicos sin cambios. Esto permite que las rutas existentes del tokenizador latino del modelo procesen texto indio sin modificar los pesos del modelo.

B. Adaptación LoRA (Solo Cabeza de Texto)

• Objetivo: Solo el predictor de tokens de texto (transformador t3) de la base Chatterbox. El decodificador acústico (s3gen) y el codificador de voz (ve) permanecen congelados.
• Configuración: Un adaptador de Adaptación de Bajo Rango (LoRA) aplicado a las proyecciones de atención ($q, k, v, o$).
  • Parámetros Entrenables: 7.86M (0.97% del modelo base de 810M).
  • Datos de Entrenamiento: ~1,220 horas de audio indio con licencia (IndicTTS, Rasa, FLEURS, Shrutilipi). No se utilizaron datos de TTS comerciales.
  • Condicionamiento de Idioma: Los textos en telugu y tamil se condicionan con un ID de idioma proxy hindi (hi). Esto enruta la adaptación a través de la variedad acústica más cercana que la base ya posee.
• Resultado: La cabeza de texto aprende a emitir tokens de habla que se alinean con la fonología india, mientras que el decodificador congelado genera el audio.

C. Recuperación de Prompt de Voz y Configuración B

• Problema: Incluso con BUPS y LoRA, la inferencia predeterminada produce habla "plana" o con "acento extranjero" porque el decodificador congelado carece de priores acústicos indios nativos.
• Solución: Una receta en tiempo de inferencia que implica:
  1. Prompt de Voz: Proporcionar un clipe de audio de referencia de 8–11 segundos en el idioma objetivo (el mismo idioma que el texto de entrada). Esto condiciona al decodificador sobre la prosodia y el timbre nativos.
  2. Anulaciones de Muestreo de Configuración B: Tres ajustes específicos de parámetros para estabilizar la generación:
     • exaggeration: 0.7 (aumenta el contorno prosódico).
     • temperature: 0.6 (estrecha la distribución).
     • min_p: 0.1 (filtra tokens de baja probabilidad que causan deriva fonémica).

D. Arquitectura de Enrutamiento

El sistema despliega una arquitectura de dos ramas para entradas de script puro y una tercera rama para entradas de código mixto:

1. Telugu/Tamil (Script Puro): Se enruta a través de BUPS + LoRA (Proxy Hi).
2. Hindi (Script Puro): Se enruta a través de Chatterbox Vanilla (Sin LoRA, Sin BUPS). Críticamente, aplicar LoRA al hindi degrada la precisión semántica, por lo que se utiliza una rama de control negativo.
3. Código Mixto (ej. Hindi + Inglés): Se enruta a IndicF5 (un modelo de flujo nativo indio) precedido por un preprocesador de transliteración impulsado por Haiku que convierte las palabras en inglés en ortografías fonéticas de script nativo (ej. "WhatsApp" $\to$ "व्हाट्सऐप").

3. Contribuciones Clave

1. BUPS: La primera aplicación de la romanización ISO-15919 como mecanismo de enrutamiento para habilitar el soporte indio en bases TTS tokenizadas en latín.
2. LoRA de Intervención Mínima: Una estrategia que adapta solo la cabeza de texto de un modelo multilingüe congelado utilizando un ID de idioma proxy, logrando calidad comercial sin entrenamiento de decodificador acústico.
3. Receta de Recuperación de Prompt de Voz: Demuestra que anulaciones específicas de muestreo (Configuración B) combinadas con prompts de voz en el mismo idioma pueden recuperar acústicas de clase comercial desde un decodificador congelado.
4. Despliegue de Dos Ramas: Una arquitectura novedosa que cambia dinámicamente entre modelos adaptados con LoRA y modelos vanilla según el idioma, validada por un control negativo que muestra que LoRA perjudica el rendimiento en hindi.
5. Solución de Código Mixto: Una tubería de preprocesamiento que reduce el LLM-WER en entradas de código mixto de ~0.80 a ~0.14–0.27 mediante la transliteración de tramos en inglés a scripts nativos.
6. Lanzamiento Abierto: Los pesos LoRA R6 (Apache-2.0) y el código de inferencia (MIT) están disponibles públicamente.

4. Resultados

Evaluado en la métrica de referencia PSP (Perfil de Sustitución de Fonemas) y métricas de inteligibilidad:

• Telugu:
  • Colapso Retroflexo: 26.7% (Praxy) vs. 33.3% (Sarvam Bulbul) y 50% (Cartesia). Praxy ocupa el primer lugar.
  • FAD (Distancia Audio Fréchet): 291.3 (comparable a las líneas base comerciales).
• Tamil:
  • Colapso Zha: 71% (Praxy) vs. 86% (Trío Comercial). Esta es la ganancia por dimensión más clara observada.
  • PSD (Divergencia de Firma Prosódica): 71.2 (igual a Sarvam Bulbul).
• Hindi:
  • LLM-WER: 0.025 (Praxy Vanilla) empatado con Cartesia Sonic-3.
  • Nota: La rama LoRA degradó significativamente el rendimiento en hindi (LLM-WER 0.334), validando la necesidad del enrutamiento de dos ramas.
• Código Mixto:
  • El LLM-WER disminuyó de 0.80–0.85 (IndicF5 crudo) a 0.14–0.27 con el preprocesador de transliteración.

5. Significado

• Eficiencia de Costos: Logra TTS de grado comercial para las principales lenguas indias utilizando cero datos de entrenamiento comerciales y computación mínima (una sola A100, ~11 horas, ~$45).
• Accesibilidad: Democratiza el acceso a TTS indio de alta calidad para desarrolladores que no pueden costear la computación o los datos requeridos para entrenar modelos desde cero.
• Perspectiva Metodológica: Demuestra que para bases multilingües, la adaptación de la cabeza de texto combinada con el condicionamiento acústico en tiempo de inferencia (prompts de voz) es suficiente para cerrar la brecha para idiomas no soportados, siempre que la base tenga una variedad acústica "suficientemente cercana" (por ejemplo, hindi para telugu/tamil).
• Control Negativo: El artículo demuestra rigurosamente que "más adaptación" no siempre es mejor; el adaptador LoRA perjudica activamente el rendimiento en idiomas que la base ya soporta (hindi), lo que hace necesaria una estrategia de enrutamiento condicional.

Los autores concluyen que este enfoque de "intervención mínima" cierra efectivamente la brecha entre el TTS de código abierto y el comercial para entradas indias de script puro, con una solución separada y de bajo costo para escenarios de código mixto.