¿Por qué mi transcripción en el iPhone confunde palabras que suenan igual?

Es un tipo concreto de error de transcripción, y se nota distinto a los demás. La frase no suena rota, el ritmo es el correcto, cada otra palabra está bien — y de repente aparece "haber" donde tocaba "a ver", o una transcripción sobre cocina dice "hay" donde claramente dijiste "ahí". Nada en la grabación suena mal al reproducirla, que es justo lo que hace confuso este patrón de error la primera vez que se nota.

El sonido, de verdad, no los distingue

Una palabra dicha entre dientes o tapada por ruido de fondo es un problema de señal — el audio llevaba menos información de lo normal, y el reconocimiento tuvo que adivinar con una señal más pobre. Los homófonos son una situación completamente distinta: "haber" y "a ver" no suenan parecido, suenan igual. No existe una forma de pronunciar cualquiera de las dos con más claridad que cambie la onda sonora captada, porque la diferencia entre ellas nunca fue acústica — vive por completo en la ortografía y la gramática, cosas a las que un micrófono no tiene acceso.

Los casi-homófonos funcionan igual, con un poco más de margen: "haya", "halla" y "aya" difieren por un matiz tan pequeño que el habla cotidiana lo borra casi siempre. Un sistema que solo trabaja con el audio parte de la misma posición imposible en la que estaría una persona que pudiera oír la frase pero no verla escrita.

Lo que de verdad resuelve el empate

El reconocimiento de voz no se limita a emparejar sonidos con palabras — también puntúa qué secuencia de palabras es más probable según el uso normal del idioma, que es como suele acertar "vamos a ver la casa" en lugar de "vamos haber la casa" a pesar de sonar casi idéntico. Esa puntuación hace un trabajo real, y es la razón de que los errores de homófonos sean la excepción y no la norma en una transcripción que funciona bien.

Pero esa puntuación sigue siendo un hábito estadístico aprendido de enormes cantidades de texto corriente, no una comprensión de la frase concreta que dijiste. Recurre a la palabra que aparece más veces en ese hueco gramatical a lo largo del lenguaje cotidiano — y en un par de homófonos genuino, las dos palabras suelen ser lo bastante comunes, en huecos lo bastante parecidos, como para que las probabilidades queden muy ajustadas. Una persona que relee la frase la resuelve al instante porque sabe qué quiso decir. Un modelo estadístico no tiene ninguna versión de "lo que quisiste decir" a la que recurrir — solo lo típico.

Es la otra cara del problema de los nombres, no el mismo problema

Un nombre sale mal porque es raro — el modelo casi nunca lo ha visto, así que lo sustituye por algo corriente. Una confusión de homófonos es lo contrario: los dos candidatos suelen ser palabras corrientes, corrientísimas, y el modelo está genuinamente dividido entre dos cosas que conoce bien, en vez de recurrir a un sustituto. Por eso la solución también es distinta. Un nombre mal escrito tiende a repetirse igual cada vez que aparece, en cuanto se nota el patrón. Un desliz de homófonos se decide frase por frase, según qué lectura puntuó ligeramente más alto para ese contexto concreto — así que el mismo par de palabras puede salir bien en una frase y mal en la siguiente, dentro de la misma transcripción.

Por qué el ajuste de calidad y qué reconocedor se usó no cambian nada de esto

Merece la pena descartar a los sospechosos habituales, porque este error no viene de ninguno de los dos. Una frecuencia de muestreo más alta capta más detalle del sonido en sí, lo que ayuda con una voz baja o lejana — pero "haber" y "a ver" producen el mismo sonido a cualquier frecuencia de muestreo, así que más detalle no crea una diferencia que nunca estuvo ahí para captar. Y el reconocimiento en el dispositivo y el respaldo por servidor puntúan las secuencias de palabras exactamente de la misma forma estadística, sobre el mismo tipo de lenguaje de entrenamiento corriente, así que ninguno de los dos tiene una ventaja real aquí. Una transcripción grabada en condiciones perfectas, con el ajuste de calidad más alto, por cualquiera de los dos caminos de reconocimiento, puede seguir cayendo en la mitad equivocada de un par de homófonos — porque el problema nunca estuvo en el audio.

Arreglarlo es cuestión de leer, no de volver a escuchar

Reproducir el audio otra vez no ayuda como ayudaría con una palabra genuinamente poco clara, porque no hay nada que escuchar con más atención — el sonido es el mismo en los dos casos. Lo que sí funciona es leer la transcripción como se relee cualquier texto: a un ritmo normal, siguiendo el sentido de cada frase en vez de comprobarla palabra por palabra contra la grabación. Ya tienes el único dato que el reconocimiento nunca tuvo — lo que de verdad quisiste decir — y eso basta para pillar un "haber" cambiado o un "hay" fuera de sitio casi tan rápido como se lee la frase.

Ayuda esperar estos errores en sitios concretos en vez de tratar cada frase como igual de sospechosa: las palabras cortas y extremadamente comunes — haber/a ver, hay/ahí/ay, si/sí, tuvo/tubo — son donde más aparece, sencillamente porque son los pares con más usos cotidianos e igual de probables en ambos lados. Un par de homófonos más raro y distintivo falla mucho menos que el puñado de palabras cortas de las que depende casi cualquier frase.

Cómo encaja Voice Studio en esto

Voice Studio transcribe a través del framework de voz de Apple de la misma manera para cada grabación: primero reconocimiento en el dispositivo, y solo un reintento con el reconocimiento en el dispositivo desactivado — enviando el audio al servidor de Apple — si ese primer intento vuelve vacío o falla. Los dos intentos son modelos de lenguaje genéricos que puntúan secuencias de palabras según cómo se usa normalmente el idioma, no un sistema con acceso a de qué trataba realmente una frase concreta, así que un desliz de homófonos puede aparecer por cualquiera de los dos caminos y no es señal de que ninguno haya fallado. La transcripción de cualquier grabación sigue siendo texto editable, así que corregir una palabra cambiada es la misma edición sencilla que corregir cualquier otra cosa en ella, y exportarla después como TXT o JSON lleva el texto tal como se lee en ese momento.

Preguntas frecuentes

¿Confundir "haber" y "a ver" significa que la app me oyó mal?

No. Las dos suenan idénticas, así que no había nada en el propio audio que permitiera distinguirlas. El reconocimiento puntúa qué palabra es estadísticamente más probable en esa frase, y a veces elige la mitad equivocada de un par que suena exactamente igual.

¿Volver a transcribir la misma grabación lo arregla?

Normalmente no. El audio no ha cambiado, y los dos intentos de reconocimiento puntúan las secuencias de palabras de la misma forma estadística, así que la misma duda ajustada suele resolverse igual otra vez, salvo que cambie algo más.

¿Ayuda un ajuste de calidad más alto con este tipo de error?

No. Una frecuencia de muestreo más alta capta más detalle del sonido, lo que ayuda con una voz baja o poco clara. No ayuda aquí, porque los homófonos producen el mismo sonido sin importar cuánto detalle se capte.

¿Es más frecuente con el reconocimiento en el dispositivo o con el respaldo por servidor?

Ninguno tiene una ventaja real. Ambos son modelos de lenguaje genéricos que puntúan las secuencias de palabras de la misma forma estadística, así que una confusión de homófonos es más o menos igual de probable por cualquiera de los dos caminos.