Normalización de texto y pronunciación en IA de voz: guía para producción

Nota sobre el alcance. Un mismo texto escrito puede tener varias formas habladas válidas. El responsable de la aplicación debe definir el significado previsto para su mercado, dominio y recorrido de usuario antes de evaluar un sistema de voz.

Ideas clave

• La normalización directa de texto convierte formas escritas en palabras para el TTS. La normalización inversa convierte una transcripción de ASR en texto para mostrar. Resuelven problemas distintos y no son inversas sin pérdida.
• Cuando la aplicación ya sabe que un valor es una fecha, un importe, un número de teléfono o un identificador, conserve ese tipo en lugar de pedir a un normalizador que lo deduzca.
• Los datos de configuración regional pueden dar formato a un valor, pero no pueden decidir si 1.250 es un entero agrupado en alemán, un decimal en inglés o un identificador.
• Use reglas estructurales para los valores cambiantes y controles de pronunciación para el vocabulario estable, como nombres, marcas y abreviaturas.
• Publique las reglas de la aplicación, los datos de configuración regional, el conjunto de diccionarios, el modelo y la voz como una única configuración probada, con un objetivo de reversión documentado.

Última actualización: agosto de 2026. Esta guía define un método de implementación y de pruebas, no una pronunciación universal para todos los idiomas, dialectos o entradas estructuradas.

¿Qué es la normalización de texto en la IA de voz?

En TTS, la normalización de texto suele referirse a la normalización directa: convertir una forma escrita en una forma pronunciable. La Recomendación SSML 1.1 del W3C emplea el mismo sentido y señala que cadenas como 1/2 son intrínsecamente ambiguas. La normalización inversa de texto (ITN) opera en la dirección contraria y convierte la salida hablada del ASR en formas escritas como fechas, importes y horas. El resumen de investigación sobre ITN de Apple usa esa definición.

La distinción importa en un agente de voz:

1. Una persona dice «cincuenta euros».
2. El ASR y la ITN pueden mostrar 50 €.
3. La lógica de negocio valida el importe y pide confirmación si procede.
4. Una respuesta posterior de TTS aplica la normalización directa para pronunciar el valor almacenado.

No pruebe esta cadena esperando una ida y vuelta exacta. Varias formas escritas pueden producir el mismo habla, y una misma forma hablada puede corresponder a varias formas escritas. La salida de la ITN sigue siendo entrada analizada, no un importe, una fecha o un número de cuenta fiables.

Idóneo para: la entrada tipada. No aplane un objeto de fecha o un importe decimal en una cadena de visualización ambigua para intentar después recuperar su significado con una sola expresión regular gigante.

¿Qué capa debe decidir cada aspecto del habla?

Utilice tres fronteras de responsabilidad:

1. Semántica de la aplicación: el sistema de origen es dueño del valor y de su significado. Decide, por ejemplo, si los céntimos son relevantes o si un código de cuenta debe confirmarse carácter a carácter.
2. Normalización: reglas conscientes de la configuración regional representan los valores tipados y tratan el texto escrito ordinario. Los generadores de valores críticos deben ser deterministas y comprobables de forma independiente.
3. Pronunciación: un diccionario de alcance reducido, una forma fonética o una etiqueta admitida controlan el vocabulario recurrente una vez conocidas las palabras previstas.

Esta separación evita que una sustitución específica de un cliente se convierta en una regla lingüística global. También hace los fallos diagnosticables: conserve el valor de origen, la entrada representada para el TTS y el manifiesto de publicación, con sujeción a la política de conservación de datos del producto.

En KugelAudio, establezca normalize: true e indique language cuando se conozca; la detección automática de idioma puede clasificar mal los textos cortos. La documentación canónica de procesamiento de texto documenta además <spell> para el deletreo de caracteres. Los diccionarios de pronunciación del proyecto pueden usar texto de sustitución o AFI, y se seleccionan mediante project_id y el opcional dictionary_ids; consulte la documentación de diccionarios de pronunciación.

No traslade directamente ejemplos genéricos de SSML a peticiones de producción. SSML define elementos como say-as, phoneme y léxicos externos, pero su compatibilidad depende del procesador. KugelAudio documenta <break>, <spell> y <prosody rate> como etiquetas interpretadas, además del AFI en línea y los diccionarios. Su referencia de prompting es la fuente autorizada sobre los controles admitidos actualmente.

¿Cómo deben tratarse las cifras, fechas e identificadores en alemán?

Parta de un valor tipado y represéntelo después para la tarea de escucha. Lo siguiente son casos de prueba, no pronunciaciones prescritas:

La especificación LDML de números y la especificación de fechas de Unicode definen estructuras de datos regionales para dar formato a números, monedas, fechas, horas y zonas horarias. Use una biblioteca regional mantenida y basada en esos datos en lugar de gestionar a mano los separadores de miles y los nombres de los meses. El formato regional sigue sin poder aportar significado de negocio, la agrupación de un identificador de empresa ni una política de confirmación.

Para un valor cambiante, defina un generador por cada tipo semántico, como render_money(amount, currency, locale) o render_reference(value, grouping_policy). Valide el valor completo antes de representarlo. Las expresiones regulares pueden ayudar a imponer una gramática de campo pequeña y anclada, pero no deberían ser el analizador de cada subcadena parecida a un número dentro de una prosa libre.

¿Cómo deben tratarse Unicode y el texto no confiable?

Elija y documente una forma de normalización Unicode antes de comparar con el diccionario. NFC es una opción habitual porque el texto canónicamente equivalente recibe una única representación; la especificación de normalización Unicode define las formas y sus garantías. No sustituya NFC por NFKC a la ligera: la normalización de compatibilidad puede eliminar distinciones que una política de identificadores quizá deba preservar.

La normalización canónica no es una comprobación de seguridad. Caracteres visualmente parecidos pueden proceder de sistemas de escritura distintos, y los controles invisibles pueden alterar la comparación o la visualización. En los identificadores sensibles a la seguridad, valide el sistema de escritura permitido, las clases de caracteres, la longitud y los separadores frente al contrato del campo. El UTS #39 de Unicode ofrece mecanismos de detección de caracteres confundibles, pero indica explícitamente que su esqueleto de confundibles no sirve como valor de sustitución ni de visualización.

Trate el texto controlado por el usuario como datos, no como marcado del habla. No concatene el texto libre de una persona dentro de la sintaxis de confianza <spell> o <break> sin un escapado adecuado al contexto o sin rechazar los delimitadores de etiqueta. Aplique límites de longitud y de estructura en el servidor antes de normalizar y acote el trabajo de las expresiones regulares; la guía de validación de entradas de OWASP explica por qué las listas de permitidos encajan con los campos estructurados y por qué bloquear unas pocas cadenas peligrosas no basta. Incluya en las pruebas negativas corchetes angulares literales, etiquetas malformadas, controles bidireccionales, marcas diacríticas combinantes, escrituras mezcladas y entradas excesivamente largas.

¿Cómo se controlan los nombres, las marcas y las abreviaturas?

Use un diccionario para los términos estables, no para valores que cambian en cada petición. Cada entrada necesita la forma escrita, la forma hablada prevista, la etiqueta de idioma, el alcance de coincidencia, el responsable, la evidencia y la versión de publicación. La especificación de etiquetas de idioma BCP 47 estandariza las etiquetas de idioma y de región, pero una etiqueta correcta no demuestra que una pronunciación suene bien.

En una abreviatura, registre si cada significado debe expandirse, pronunciarse como palabra o deletrearse. Pruebe la entrada dentro de frases, incluidas palabras corrientes que no deberían coincidir. Evite una sustitución amplia que arregle una marca en un contexto y altere un apellido o una subcadena en otro.

Use AFI solo cuando el sistema de destino documente el alfabeto aceptado y revisores nativos puedan aprobar el resultado. El elemento phoneme del SSML del W3C puede identificar AFI, pero los motores pueden diferir en su inventario de fonemas y en la representación. En KugelAudio, el AFI del diccionario tiene prioridad sobre el texto de sustitución, así que pruebe tanto el término previsto como los casos cercanos que no deberían coincidir con el modelo y la voz exactos.

¿Cómo pueden los equipos publicar y revertir la normalización con seguridad?

Trate los recursos de normalización como una unidad de publicación. Guarde un manifiesto inmutable que contenga:

• la versión del generador de la aplicación y la versión de los datos regionales;
• el ajuste del normalizador y el idioma explícito;
• los identificadores de diccionario o un resumen criptográfico de su contenido;
• el modelo, la voz y la configuración de síntesis pertinente;
• la versión del conjunto de regresión y el registro de aprobación.

Cree un diccionario candidato en lugar de editar la única copia en producción. La selección de dictionary_ids por petición de KugelAudio permite apuntar a un diccionario candidato para pruebas o para una versión canaria sin alterar el tráfico por defecto. Promueva el conjunto probado mediante configuración, vigile los errores por clase de entrada y mantenga preparado el manifiesto anterior. Revertir consiste entonces en restaurar identificadores y versiones conocidos, no en deshacer entradas a mano bajo presión.

¿Cómo pueden los equipos probar la normalización sin ocultar errores?

Cree una tabla sintética de regresión con el valor de origen, el tipo semántico, la configuración regional, la zona horaria, la entrada esperada para el TTS, las variantes habladas permitidas, la criticidad y la alternativa. Incluya ceros, negativos, límites de rango, días bisiestos, cambios de horario de verano, precisión inesperada, valores malformados y casos límite de Unicode.

Pruebe por capas:

1. Compruebe el texto normalizado exacto en los generadores deterministas de la aplicación.
2. Genere audio con la versión candidata y archive muestras de los casos críticos.
3. Use ASR o alineación forzada para señalar omisiones y sustituciones, no para certificar la acentuación, la agrupación o la pronunciación.
4. Pida a oyentes nativos que revisen nombres, expectativas regionales, agrupación e inteligibilidad sin mostrarles antes la respuesta esperada.
5. Ejercite el flujo completo de aclaración o confirmación para los datos que desencadenan acciones.

Informe de los resultados por clase y por gravedad. Una única puntuación media de exactitud puede ocultar una coma decimal o un dígito de control equivocados. Registre la tasa de recurso a la alternativa, los fallos de los generadores exactos, las omisiones de contenido y los fallos críticos detectados por los oyentes, junto con el manifiesto que los produjo. La guía de benchmark de alemán y dialectos explica por qué la inteligibilidad y la calidad juzgada por nativos necesitan evidencias separadas.

¿Qué debe ocurrir cuando la normalización es incierta?

No adivine en silencio ante un valor que desencadena una acción. Rechace un valor que incumpla su tipo declarado o pase a una vía de recuperación aprobada: formule una pregunta precisa, use una forma más larga e inequívoca, deletree o agrupe el valor, muéstrelo visualmente, envíelo por un canal autenticado o transfiera a una persona.

El error debe identificar el campo y el contrato incumplido sin volcar secretos en los logs. Una lectura plausible pero incorrecta es más difícil de detectar que un fallo explícito.

¿Qué limitaciones tiene esta guía?

Estos son patrones de ingeniería, no reglas lingüísticas universales. La pronunciación varía según el idioma, la región, el hablante y la política de cada organización. Este artículo no afirma que exista soporte completo de SSML, de todos los dialectos, de nombres arbitrarios ni de todos los formatos estructurados. Pruebe la configuración exacta de producción y las entradas que conllevan riesgo de negocio.

Preguntas frecuentes

¿Es lo mismo la normalización de texto que el control de la pronunciación?

No. La normalización convierte estructuras como fechas e importes en las palabras previstas. El control de la pronunciación especifica cómo deben sonar determinadas palabras o contenidos fonéticos. Un sistema en producción suele necesitar ambos.

¿Cuál es la diferencia entre normalización de texto y normalización inversa?

La normalización directa convierte formas escritas en texto pronunciable para el TTS. La normalización inversa convierte la salida hablada del ASR en formas escritas. No son inversas sin pérdida, porque ambas direcciones pueden resultar ambiguas.

¿Debe el modelo de TTS decidir cómo leer cada número?

No. Si la aplicación sabe que un valor es un precio, un número de teléfono o un identificador, debería conservar ese tipo y construir la entrada prevista para el TTS antes de la síntesis.

¿Puede un diccionario de pronunciación arreglar un IBAN o un identificador de cliente?

No como mecanismo principal. Los diccionarios encajan con el vocabulario recurrente; los identificadores cambiantes necesitan validación, reglas estructurales de agrupación y una política de confirmación.

¿Basta el ASR para validar la pronunciación?

No. El ASR puede señalar omisiones o sustituciones, pero una transcripción correcta no demuestra una acentuación, una agrupación, una aceptabilidad regional ni una inteligibilidad correctas.

¿Cómo deben publicarse los cambios de diccionario?

Pruebe una versión candidata con frases representativas y con casos que no deben coincidir, y publíquela después junto con el manifiesto de normalizador, modelo y voz. Conserve el conjunto de diccionarios anterior como objetivo de reversión.

¿Qué debe hacer un sistema con un texto crítico ambiguo?

Devolver un error de validación explícito o aplicar un flujo aprobado de aclaración y confirmación. No debe elegir en silencio una lectura plausible cuando esa elección puede cambiar el significado.