Cómo construir un benchmark abierto de TTS en alemán y sus dialectos

Metodología, no resultados. Esta guía especifica un benchmark de TTS en alemán. No publica puntuaciones ni designa a un ganador.

Ideas clave

• Mida por separado la inteligibilidad, la corrección de las entidades, la calidad percibida, la autenticidad dialectal, la latencia y la fiabilidad.
• Trate la tasa de error por caracteres basada en ASR como una métrica de canalización, no como una medida directa de lo que entiende una persona.
• Defina la pregunta de escucha, el reparto de muestras, las exclusiones y el análisis estadístico antes de recoger valoraciones.
• Identifique las muestras dialectales por variedad concreta y localidad. «Dialecto alemán» no es una categoría útil de evaluación.
• Archive las entradas, peticiones, salidas, versiones y código de análisis exactos. Etiquete como observación fechada cualquier API cuya revisión de backend no pueda fijarse.
• Mantenga los datos de despliegue y gobernanza de datos fuera de la puntuación de calidad de audio.

Última actualización: agosto de 2026.

¿Cómo debe funcionar un benchmark abierto de TTS en alemán?

Congele el protocolo antes de generar audio. Cada sistema admitido recibe el mismo texto dentro de una vía declarada. Guarde la respuesta sin modificar, cree copias de reproducción con una única canalización de conversión publicada, ejecute una configuración fija de ASR, realice un estudio de escucha ciega y mida la latencia desde un único cliente controlado. No ajuste los prompts después de ver los resultados del conjunto de prueba.

Cada fila de resultados necesita el identificador del caso, los identificadores de sistema y de voz, la petición completa, la región de la API o el hardware local, la versión del software, la marca de tiempo, el resultado de los reintentos, la suma de comprobación de la salida y la versión del protocolo. Una organización práctica de la publicación es:

benchmark/
  PROTOCOL.md
  CHANGELOG.md
  LICENSES.md
  dataset/cases.jsonl
  dataset/provenance.csv
  configs/systems/*.yaml
  environment/container-digest.txt
  outputs/raw/<system>/<case-id>.*
  outputs/playback/<system>/<case-id>.wav
  asr/raw-transcripts.jsonl
  listening-study/design.json
  listening-study/anonymized-ratings.csv
  results/metrics.csv
  results/latency-events.jsonl
  scripts/

Publique una versión inmutable con sumas de comprobación, no solo una rama que cambia. Los criterios de artefactos de la ACM son un buen estándar de evidencia: un artefacto debe estar documentado, completo, ser ejecutable y coherente con lo que afirma. La mera disponibilidad no demuestra que otro evaluador pueda reproducir un resultado.

¿Qué métricas debe reportar un benchmark de TTS?

No reduzca estas filas a una «puntuación de calidad» ponderada. Los pesos serían una decisión de producto disfrazada de medición. Para dimensionar un despliegue, use un protocolo aparte de planificación de capacidad de TTS.

¿Qué debe contener el conjunto de prueba en alemán?

Construya el conjunto a partir de la carga de trabajo prevista y después estratifíquelo. Un benchmark de atención al cliente podría repartir los casos entre diálogo sencillo, compuestos largos, nombres, fechas y horas, importes, números de teléfono, identificadores alfanuméricos, abreviaturas y alternancia entre alemán e inglés. Publique el recuento y la fuente de cada categoría. Un benchmark de narración necesita otro material y no debería heredar esta mezcla sin justificarlo.

Cada fila del conjunto de datos debería incluir al menos:

{
  "case_id": "de_money_001",
  "input_text": "Der Betrag ist 3.847,26 Euro.",
  "spoken_reference": "Der Betrag ist dreitausendachthundertsiebenundvierzig Euro und sechsundzwanzig Cent.",
  "category": "currency",
  "language_tag": "de-DE",
  "variety_label": "Standard German",
  "locality": null,
  "source": "benchmark-authored",
  "license": "CC-BY-4.0"
}

La referencia hablada debe redactarse antes de la síntesis. Así se evita que un ASR que devuelve dígitos decida a posteriori qué cuenta como lectura correcta. Para los campos con alternativas legítimas, enumérelas de antemano. Mantenga la exactitud de las entidades separada del CER, porque un solo dígito equivocado puede ser grave en la operación y apenas alterar una tasa de edición a nivel de frase. La guía de normalización de texto explica por qué las fechas, los importes y los identificadores necesitan lecturas esperadas explícitas.

Utilice casos reservados para la evaluación publicada. El subconjunto de desarrollo puede ser público desde el principio; publique cada versión reservada junto con sus resultados y rote los casos de prueba futuros. Esto no elimina la contaminación de los datos de entrenamiento, así que la publicación debe indicar cuándo se hicieron públicos cada modelo y cada conjunto de prueba.

¿Cómo deben muestrearse y etiquetarse las variedades dialectales?

No use nombres de archivo como de-BY para referirse al bávaro. En BCP 47, una subetiqueta de región de dos letras designa un código de país ISO, no un estado federado alemán. Use una etiqueta válida de RFC 5646 y registre después la variedad subnacional y la localidad en campos separados. Por ejemplo, language_tag: de-DE puede acompañarse de variety_label: Munich Bavarian y de una localidad documentada. Use gsw-CH o nds-DE solo cuando esas subetiquetas de idioma registradas describan con precisión la muestra.

«Bávaro», «alemánico» y «alemán suizo» abarcan variación interna. Los corpus existentes lo hacen visible: STT4SG-350 equilibra el material en alemán suizo entre regiones dialectales, mientras que el corpus Betthupferl publica subconjuntos separados de franconio, bávaro, alemánico y alemán estándar. Un benchmark debería, por tanto, informar por separado de cada localidad reclutada antes de mostrar cualquier resumen de grupo más amplio.

Haga que hablantes de la variedad concreta redacten o revisen el texto, la ortografía, la pronunciación prevista y la etiqueta de variedad. Registre los criterios de los revisores: dónde crecieron, dónde viven ahora y con qué frecuencia usan la variedad. Son descriptores de la muestra, no pruebas de si alguien es «auténtico».

Si es necesario, ejecute dos vías distintas:

1. Vía de entrada común: todos los sistemas reciben el mismo texto dialectal y no se aplica ninguna corrección no declarada.
2. Vía de capacidad documentada: un sistema puede usar su control de acento, prompt o voz de referencia documentados, pero la configuración exacta es pública.

No mezcle nunca ambas vías en una misma clasificación. Los oyentes dialectales deben responder por separado a la inteligibilidad y a la adecuación regional; una lectura clara en alemán estándar de un texto dialectal puede puntuar bien en una y mal en la otra.

¿Cómo se calcula la tasa de error por caracteres basada en ASR?

Sintetice la entrada, transcriba el audio con un único sistema de ASR congelado, normalice la hipótesis y la referencia hablada con la misma función publicada y calcule después inserciones, eliminaciones y sustituciones divididas por la longitud de la referencia. La documentación de NIST SCTK describe esta familia de puntuaciones de reconocimiento del habla basadas en distancia de edición.

Publique la salida original del ASR y todas las cadenas normalizadas. Prefiera una normalización Unicode NFC conservadora, un tratamiento explícito de mayúsculas y reglas de puntuación claras. La especificación de normalización Unicode advierte de que las formas de compatibilidad pueden borrar distinciones, de modo que «aplicar NFKC» no es una opción neutra por defecto. No convierta un número mal pronunciado en el número esperado.

La métrica debería llevar el nombre de la configuración de ASR, por ejemplo CER_ASR-X_v1, porque mide conjuntamente el TTS, el ASR y la normalización. Si los recursos lo permiten, repita la medición con un segundo ASR congelado como comprobación de sensibilidad y muestre ambos resultados en lugar de promediarlos. No compare una porción dialectal con el alemán estándar como si el error del ASR se distribuyera por igual entre ambas.

¿Cómo debe realizarse el estudio de escucha ciega?

Parta de la ITU-T P.85, que aborda la evaluación subjetiva de dispositivos de salida de voz. Use la ITU-T P.808 cuando la prueba se realice mediante crowdsourcing. Estas recomendaciones son puntos de partida, no la prueba de que cualquier formulario web de cinco puntos sea un estudio MOS válido.

Registre de antemano la pregunta de escucha y el análisis. «¿Cómo de natural suena esta voz?» no es intercambiable con la calidad global, la similitud del hablante, el esfuerzo de escucha o la autenticidad dialectal. Pregunte por un solo constructo a la vez o informe de cada respuesta por separado.

El diseño publicado debe indicar:

• el número de voces por sistema, de muestras, de oyentes y de valoraciones por muestra;
• el idioma de los oyentes, su familiaridad con el dialecto y la geografía del reclutamiento;
• el orden aleatorizado, el enmascaramiento de los sistemas y cómo se repartieron las muestras;
• el formato de reproducción, las instrucciones de escucha y las comprobaciones de dispositivo o entorno;
• las muestras de referencia y de control, los controles de atención y las exclusiones declaradas de antemano;
• la pregunta exacta, las etiquetas de respuesta, la distribución de valoraciones original y el código de análisis.

Use un piloto para elegir un tamaño de muestra que cumpla un objetivo declarado de precisión o de potencia; no existe un número universal de oyentes para todos los diseños. Las valoraciones se repiten entre oyentes y enunciados, así que la unidad de análisis importa. Declare si el intervalo de confianza es por archivo o por condición y calcúlelo en consecuencia; la ITU-T P.1401 trata ambas formas. Si se reivindica un ganador, publique el modelo de comparación declarado de antemano y el tratamiento de las comparaciones múltiples. Una media más un «IC del 95 %» sin explicar no basta.

Los empleados, los productores de las muestras y cualquiera capaz de reconocer las salidas de un sistema deben reportarse como panel de expertos aparte o excluirse del panel ciego. Si una sola voz representa a un sistema, la conclusión se aplica a esa voz y a esa configuración, no a todo el catálogo del proveedor.

¿Cómo deben medirse el tiempo hasta el primer audio y la fiabilidad?

Defina el tiempo hasta el primer audio como el tiempo transcurrido según un reloj monótono desde justo antes de que el cliente envíe la petición de síntesis hasta la primera muestra de audio que la aplicación puede decodificar y reproducir. Una cabecera de respuesta o de contenedor no es audio reproducible. Guarde las marcas de tiempo de los eventos para que otros puedan recalcular la métrica.

Ejecute y reporte escenarios separados:

• conexión en frío, incluidos DNS, TCP y TLS cuando corresponda;
• conexión caliente reutilizada con concurrencia uno;
• una tasa de llegadas o concurrencia declarada y representativa de producción;
• salida nativa sin pérdidas y, si procede, una conversión telefónica habitual a 8 kHz aplicada tras archivar el original.

Intercale las peticiones a los distintos sistemas para reducir el sesgo por hora del día. Fije la ubicación del cliente, la región del proveedor, el conjunto de textos, el formato, la frecuencia de muestreo, el tiempo de espera, la política de reintentos y la reutilización de conexiones. Desactive los reintentos automáticos o registre cada intento. Los tiempos de espera agotados, el audio no válido, los límites de velocidad y los errores de servidor forman parte del denominador y de categorías de fallo con nombre; descartarlos en silencio mejora sobre el papel tanto la latencia como la fiabilidad.

Publique el recuento, la distribución empírica, el p50 y el p90. Publique el p99 solo con su incertidumbre y con observaciones suficientes para la precisión pretendida. Las reglas de MLPerf Inference muestran por qué la confianza en la latencia de cola requiere muchas más observaciones que una mediana; un p99 calculado a partir de unas pocas decenas de llamadas no debería sustentar una afirmación de compra. La latencia de procesamiento declarada por el proveedor puede incluirse en una columna aparte, pero no debe mezclarse con las mediciones de extremo a extremo desde el cliente.

¿Qué sistemas pueden incluirse de forma justa?

Defina la lista de participantes en la publicación versionada del benchmark, no en un artículo de marketing. Aplique la misma regla de admisión a KugelAudio y a cualquier competidor.

Una API cerrada puede ser útil en un benchmark abierto aunque su implementación no sea de código abierto. El benchmark debe declarar la limitación resultante. Para alternativas locales, consulte la guía de modelos de TTS autoalojados y verifique después la ficha y la licencia del checkpoint exacto en el momento de la publicación.

¿Qué debe publicarse en materia de licencias y reproducción?

Lleve el control de los derechos por artefacto. El código del benchmark, el texto de prueba, las grabaciones de referencia, las muestras de voz, el audio generado, los pesos del modelo y las condiciones del proveedor pueden tener licencias o condiciones de redistribución distintas. Un archivo LICENSE de nivel superior para el arnés de pruebas no concede derechos sobre el conjunto de datos ni sobre el audio.

Registre la fuente, el autor o titular de los derechos, el identificador de licencia o la URL de las condiciones, la fecha de obtención, la atribución exigida y si se permite la redistribución. SPDX ofrece metadatos estandarizados para software, modelos de IA y conjuntos de datos, incluidas la procedencia, las licencias y las sumas de comprobación. Obtenga consentimiento documentado para cualquier voz de referencia e indique los usos permitidos dentro del benchmark.

Si las condiciones del proveedor impiden publicar el audio generado, revélelo antes de la ejecución y marque el sistema como solo parcialmente reproducible. No sustituya los archivos por ejemplos seleccionados a conveniencia. Archive cada publicación, su instantánea de condiciones cuando esté permitido y un registro de correcciones. Otro evaluador debería poder reconstruir todas las tablas publicadas a partir de los artefactos difundidos con un único comando documentado.

¿Cómo deben interpretarse los resultados?

Toda conclusión está acotada por las voces, el texto, las localidades dialectales, los oyentes, el ASR, la región, la carga, el códec y la fecha de la muestra. Publique los datos por caso y las distribuciones por porción antes que los resúmenes. No convierta varios resultados locales en una «puntuación universal de dialectos alemanes».

KugelAudio vende un sistema que puede figurar en la evaluación. Cualquier publicación realizada por KugelAudio debe declarar ese conflicto junto a cada tabla de resultados, aplicar el protocolo publicado sin excepciones a posteriori e invitar a repeticiones independientes. Use el benchmark para acotar una lista corta y repítalo después con su propia mezcla de tráfico, entidades críticas, ubicaciones, concurrencia y voces. Las pruebas de calidad tampoco acreditan privacidad ni cumplimiento normativo; evalúelos por separado con la guía de infraestructura de IA de voz on-premise.

Preguntas frecuentes

¿Cómo se mide la calidad del TTS en alemán?

Use pruebas separadas para la inteligibilidad en texto corriente, las entidades críticas, la calidad percibida por personas, la adecuación dialectal, la latencia y los fallos. Ninguna métrica única sostiene todas esas conclusiones.

¿Qué es el CER de ida y vuelta?

Es la tasa de error por caracteres entre una referencia hablada declarada y la salida de un sistema de ASR congelado aplicado al audio sintetizado. Es repetible cuando el ASR y el código de normalización están fijados, pero no es una puntuación pura de TTS ni de inteligibilidad humana.

¿Cuántos oyentes necesita un estudio MOS?

No hay un número universal. Elíjalo a partir de un piloto y de un objetivo declarado de precisión o potencia, y publique después los oyentes, las valoraciones por muestra, las exclusiones y la unidad de análisis. Más valoraciones no arreglan un panel de oyentes o un conjunto de prueba sesgados.

¿Puede un benchmark reportar el p99 a partir de 100 peticiones?

Puede calcular un percentil muestral, pero esa estimación contiene muy poca información de cola. Publique la distribución original, el número de muestras y la incertidumbre; no presente un p99 de una ejecución pequeña como una garantía estable en producción.

¿Qué sistema de TTS en alemán es más preciso?

Esta metodología no señala a ninguno. Una respuesta defendible debe especificar la porción de texto, las voces, las instantáneas de modelo, la configuración del ASR, el panel de escucha y la fecha, y debe poner a disposición la evidencia subyacente.

¿Tiene que ser de código abierto todo modelo incluido?

No. Una API comercial versionada puede evaluarse de forma transparente. Si su backend no puede fijarse o sus salidas no pueden redistribuirse, señale esa limitación y manténgala fuera de las afirmaciones sobre reproducibilidad exacta.

¿Una mejor calidad de audio implica mejor privacidad o cumplimiento normativo?

No. La región de alojamiento, la retención, los subencargados, los contratos y los controles on-premise son pruebas de compra distintas. Evalúelos con independencia de las puntuaciones de audio.