Benchmark: ASR en código mezclado para agentes de voz | Keryc
Más de la mitad del mundo habla más de un idioma. ¿Y si tus clientes mezclan idiomas en la misma frase? Eso pasa todo el tiempo en centros de contacto y mesas de ayuda, y las transcripciones erróneas en la primera etapa —la de reconocimiento de voz— contaminan todo el flujo posterior. ServiceNow y su equipo construyeron un benchmark para responder a una pregunta directa: ¿cómo se comportan los ASR frontier frente al code-switching en escenarios de empresa?
Qué hicieron
Se enfocaron en la etapa crítica: el reconocimiento automático de voz (ASR). Partieron de interacciones reales de HR y soporte IT y generaron un corpus sintético de enunciados que mezclan un idioma matriz con fragmentos en inglés. ¿Por qué sintético? Porque eligieron controlar la mezcla lingüística y la calidad del audio usando TTS para asegurar cobertura y reproducibilidad.
El flujo fue así:
Tomaron pares paralelos (inglés + otro idioma) y filtraron candidatos con buena oportunidad de cambio de código.
Mantuvieron frases entre 12 y 40 palabras, y exigieron al menos tres palabras «switchables» (sustantivos, verbos, adjetivos) para que el resultado fuera natural.
Usaron un prompt de persona en un LLM (OpenAI/GPT-5) para generar el texto code-switched, luego un pase de verbalización para llevarlo a forma hablada y sintetizaron audio con ElevenLabs Multilingual V2.
Revisó un lingüista nativo del idioma matriz cada grabación; las fallas se excluyeron o regeneraron.
El dataset final contiene:
259 registros Spanish-English
298 French-English
188 Canadian French-English
173 German-English
Además liberaron su benchmark y datos a través de su AU-Harness para evaluar modelos de voz.
Dataset, métricas y modelos evaluados
Se midieron tres dimensiones clave:
WER (Word Error Rate): precisión a nivel de palabra.
SWER (Semantic WER): tasa de errores que afectan el sentido, basada en un juez LLM (Gemma-4-31B) siguiendo la implementación de Pipecat.
AER (Answer Error Rate): métrica funcional que genera tres preguntas por enunciado y comprueba si un LLM puede responderlas desde la transcripción (metodología inspirada en Bhushan et al.).
Modelos evaluados (7):
AssemblyAI / Universal 3-Pro
Deepgram / Nova 3 Multilang
ElevenLabs / Scribe V2
Google / Gemini 3 Flash
Mistral AI / Voxtral Small 24B-2507
Nvidia / Parakeet TDT 0.6b V3
OpenAI / Whisper Large V3 Turbo
Resultados principales
Los mejores en precisión de transcripción fueron ElevenLabs Scribe V2 y AssemblyAI Universal 3-Pro, muy parejos; Scribe toma una ligera ventaja general.
Gemini 3 Flash aparece como clave cuando la métrica es semántica (AER, SWER), likely por la optimización de los LALM en comprensión y razonamiento.
En mitad de la tabla están Deepgram, Mistral y Nvidia, cada uno mejorando en al menos un par de idiomas. Parakeet cierra el grupo medio, con mejor desempeño en German-English.
Whisper Large V3 Turbo queda al final por un problema claro: sin parámetro explícito de idioma, tiende a traducir a inglés en vez de transcribir, lo que penaliza sus WER.
Conclusión breve: Scribe V2, Gemini 3 Flash y AssemblyAI son los que mejor manejan code-switching en este benchmark, tanto en exactitud como en preservación de significado.
¿Cuál es el “coste” del code-switching?
Para medirlo aislaron cada enunciado en tres audios: code-switched, monolingual matriz (L2) y monolingual inglés. La diferencia de WER entre code-switched y monolingual da el coste del cambio.
Los top models (Scribe, Gemini, AssemblyAI) muestran deltas pequeños; Scribe incluso supera su propia línea base L2 en algunos casos.
Los modelos menos robustos se degradan más, lo que sugiere que el code-switching amplifica diferencias de robustez entre modelos en lugar de crear una dificultad uniforme.
Whisper muestra la mayor degradación relativa a inglés (hasta +0.85 en German-English), y es el único que a veces va mejor en code-switched que en monolingual L2 por su hábito de traducir.
Análisis técnico: factores que predicen errores
Aplicaron un modelo en dos partes: primero una regresión logística para identificar qué variables aumentan la probabilidad de tener al menos un error; luego un OLS condicional para ver qué factores afectan la magnitud del error si ya hubo uno.
Predictores usados:
Número de cambios de idioma en el enunciado
CMI (Code-Mixing Index): proporción de palabras en la lengua secundaria
Longitud del enunciado (control)
Hallazgos:
El conteo de switches es el predictor más consistente de si ocurre un error. Cada cambio introduce una nueva oportunidad de fallo, especialmente claro en French-English.
Una vez que ocurre un error, la magnitud del error se relaciona más con CMI: cuanto más densamente mezclado está el enunciado, mayores son los WER observados (ejemplo notable en German-English).
Además analizaron dónde ocurren los errores al nivel de palabra usando GPT-5 para etiquetar idioma por token. Resultado sorprendente:
Los errores se concentran en las porciones en inglés del enunciado, no en la lengua matriz. Esto es contraintuitivo porque el inglés suele ser el idioma mejor manejado por los modelos en monolingüe.
Posibles explicaciones:
Las porciones en inglés contienen más vocabulario técnico y nombres propios difíciles.
O el acto de insertar un tramo en otro idioma crea un contexto acústico/lingüístico que dificulta la adaptación del modelo mid-utterance.
Limitaciones y recomendaciones prácticas
Limitaciones importantes:
El benchmark es sintético: audio generado por TTS. No captura necesariamente prosodia, acentos y variaciones fonéticas de hablantes reales.
Todas las pruebas se hicieron en modo de detección automática de idioma. Muchos sistemas permiten forzar idioma o usar hints que podrían mejorar resultados en producción.
La per-language WER excluye insertions por dificultad de atribución de idioma.
Recomendaciones si gestionas agentes de voz bilingües:
No confíes en rankings generales; haz un benchmark con los idiomas de tus clientes. El mejor modelo para Spanish-English no tiene por qué ser el mejor para German-English.
Prueba tanto con audio sintético como con muestras reales de tus usuarios para capturar acentos y prosodia.
Considera usar LALMs o modelos con fuerte capacidad semántica si tu flujo depende de comprensión (formularios, enrutamiento, extracción de entidades).
Experimenta con opciones de configuración: tokens de idioma forzados, hints multilenguaje y pipelines que detecten switches y adapten el modelo.
Reflexión final
El code-switching deja de ser un fallo exótico y se está volviendo una condición normal que los mejores ASR pueden manejar con pequeñas penalizaciones. ¿Significa esto que ya puedes desplegar un asistente bilingüe sin más? Casi, pero no sin antes validar con tus idiomas y escenarios específicos. La parte técnica está clara: mide tanto la exactitud como la preservación del significado, porque un WER razonable no garantiza que la información crítica (números de caso, solicitudes, nombres) llegue intacta a tus sistemas.
