¿Pueden los agentes de voz entender a clientes bilingües? Un benchmark sobre ASR y code-switching

Las interacciones bilingües y el code-switching son habituales en muchos clientes empresariales. Este artículo resume un benchmark que mide cómo diferentes sistemas de reconocimiento de voz manejan conversaciones donde se mezclan idiomas, con foco en escenarios de soporte y RRHH.

Por Redaccion TD
¿Pueden los agentes de voz entender a clientes bilingües? Un benchmark sobre ASR y code-switching

Por qué importa el code-switching para empresas

Más de la mitad de la población mundial habla más de un idioma y, para millones de personas, alternar idiomas dentro de la misma frase es una práctica natural. En América Latina —especialmente en servicios de atención al cliente y contact centers que atienden mercados transfronterizos— el uso mixto de español e inglés ocurre con frecuencia. Para agentes de voz y pipelines conversacionales, la primera etapa crítica es el reconocimiento automático de voz (ASR): si la transcripción falla, los errores se propagan a todos los componentes posteriores, generando tickets mal clasificados, respuestas incorrectas o escalaciones innecesarias.

Ante la consulta de un cliente que atiende una base bilingüe proclive al code-switching, se construyó un benchmark y un conjunto de datos orientado a evaluar cómo rinden los sistemas ASR en ese contexto. El objetivo central fue medir no solo la exactitud literal de la transcripción, sino también si el significado relevante para tareas de soporte se preserva.

Alcance del benchmark y dataset

El estudio se enfocó en cuatro pares de idiomas relevantes para clientes empresariales: español-inglés, francés-inglés, francés canadiense-inglés y alemán-inglés. En el diseño se utilizó la lengua no inglesa como “matrix” (es decir, el idioma base) con inserciones de inglés de distintas longitudes. El corpus simula situaciones comunes en Recursos Humanos (RRHH) y en gestión de servicios IT (ITSM): consultas sobre beneficios y nómina, pedidos de restablecimiento de contraseña, acceso VPN y resolución de problemas de dispositivos.

Para generar cada enunciado code-switching se partió de pares de frases paralelas en inglés y en la lengua matrix. Se aplicaron filtros para mantener mensajes de entre 12 y 40 palabras —lo suficiente para que el cambio de idioma sea natural— y se descartaron casos dominados por entidades (correos, números, URLs) que forzarían la presencia de inglés. Además, se exigió al menos tres palabras de contenido intercambiables (sustantivos, verbos o adjetivos no entitativos) para asegurar material significativo que el generador pudiera alternar.

La mezcla lingüística final se produjo mediante un prompt de persona a un LLM (OpenAI/GPT-5), seguido de una pasada de verbalización para convertir el texto a su forma hablada. El audio se sintetizó con ElevenLabs Multilingual V2 y cada utterance fue revisado por un lingüista AI/NLP nativo del idioma matrix; los enunciados marcados se excluyeron o regeneraron. El dataset final contiene 259 registros español-inglés, 298 francés-inglés, 188 francés canadiense-inglés y 173 alemán-inglés. El benchmark se publica junto con el harness de evaluación AU-Harness.

Cómo se midió el rendimiento

Se emplearon tres métricas complementarias para captar precisión literal y capacidad de preservar significado:

  • Word Error Rate (WER): la medida estándar que compara la transcripción con la referencia palabra por palabra. Aporta una visión de errores a nivel léxico pero no distingue si la equivocación altera el sentido.

  • Semantic Word Error Rate (SWER): cuantifica errores juzgados como semánticamente relevantes. La implementación se basa en el benchmark STT de Pipecat y usa a Gemma-4-31B como modelo juez para valorar si sustituciones o pérdidas afectan el significado.

  • Answer Error Rate (AER): mide el impacto de la transcripción sobre tareas downstream. Para cada enunciado se generan tres preguntas de comprensión y se verifica si un LLM que lee la transcripción puede contestarlas correctamente, siguiendo la metodología propuesta por Bhushan et al.

Estas tres métricas permiten ver no solo cuántas palabras se reemplazaron, sino si esos fallos impiden acciones concretas como resolver un ticket o responder una consulta salarial.

Modelos evaluados

El benchmark incluye resultados de siete sistemas ASR y varios modelos de audio de frontera y de código abierto: AssemblyAI Universal 3-Pro, Deepgram Nova 3 Multilang, ElevenLabs Scribe V2, Google Gemini 3 Flash, Mistral Voxtral Small 24B-2507, Nvidia Parakeet TDT 0.6b V3 y OpenAI Whisper Large V3 Turbo.

Hallazgos principales

El hallazgo central es que el costo del code-switching varía según la pareja de idiomas y el modelo evaluado. No existe una penalización uniforme: algunos sistemas mantienen rendimiento competitivo, mientras que otros ven incrementos significativos en errores.

Entre los modelos probados, ElevenLabs Scribe V2, Gemini 3 Flash y AssemblyAI Universal 3-Pro aparecen como los mejor posicionados en las métricas combinadas (WER, SWER, AER) para estas tareas. Esto sugiere que ciertas arquitecturas y estrategias de entrenamiento son más robustas ante la alternancia de idiomas, aunque el desempeño exacto sigue dependiente del par lingüístico y del dominio.

Los resultados también confirman la importancia de medir impacto semántico: en algunos casos, una transcripción con WER relativamente alto aún preserva la información esencial (baja SWER/AER), mientras que pequeños errores léxicos en palabras críticas pueden provocar fallos en tareas automatizadas.

Implicaciones prácticas para equipos en Latinoamérica

Para líderes de producto, operaciones y TI que implementan agentes de voz en mercados bilingües, las conclusiones prácticas son claras:

  • No asuman que un buen WER en monolingüe se traduce a código mixto. Prueben modelos directamente con muestras representativas de su base de clientes.
  • Miden más allá del WER: incluyan métricas que capturen la preservación del significado y el impacto en procesos (como AER) para evaluar riesgo operacional.
  • Consideren modelos LALM o soluciones de frontera que muestran mayor resiliencia ante alternancia lingüística, pero siempre contrasten costos y latencias según necesidades del negocio.
  • Mantengan pipelines de evaluación continua y dataset propio: el comportamiento real de los clientes suele diferir de audio sintético o datos generados.

Limitaciones y siguientes pasos

El benchmark está centrado en interacciones empresariales de RRHH e ITSM y usa audio sintetizado a partir de texto generado por un LLM, revisado por lingüistas. Esto hace que los ejemplos sean realistas para el dominio objetivo, pero no equivalen completamente a la variabilidad de conversaciones espontáneas en entornos reales (ruido, acentos locales, interrupciones). Además, la cobertura quedó limitada a cuatro pares de idiomas y a la longitud de utterances definida en el protocolo.

Por ello, las organizaciones deberían complementar este benchmark con pruebas en datos reales de sus clientes y análisis por variedad de acentos y condiciones de audio.

Conclusión

El estudio confirma que el code-switching puede aumentar el costo de reconocer correctamente el habla, pero el impacto depende tanto del par de idiomas como del sistema ASR elegido. Para empresas en América Latina que atienden audiencias bilingües, la recomendación es evaluar modelos con métricas que reflejen significado y riesgo operativo, y priorizar pruebas en su propio dominio antes de desplegar agentes de voz a escala. La publicación del benchmark y del AU-Harness facilita esa evaluación comparativa y aporta una base para decisiones informadas sobre qué tecnología adoptar.

Fuente original: Hugging Face Blog