iFlytek publica Spark-ASR-2.0, su modelo de voz para ruido y dialectos
La compañía china lanza la segunda versión de su motor de reconocimiento de voz, orientado a audio con ruido, habla dialectal y frases que mezclan chino e inglés, con una API abierta en camino.
iFlytek ha publicado Spark-ASR-2.0, la segunda generación de su motor de reconocimiento automático de voz. La empresa lo sitúa en los tres escenarios donde suelen atascarse los ASR comerciales: audio con ruido de fondo, habla con acento o dialecto, y conversaciones donde el hablante salta entre chino e inglés dentro de la misma frase.
El anuncio viene sin apenas carne. iFlytek habla de una ronda de despliegue en iFLYTEK Input, su herramienta de entrada de texto, y de una API abierta que llegará más adelante, pero no da fechas, ni precios, ni límites de uso, ni nombres de los dialectos cubiertos.
El único dato técnico concreto que suelta la compañía es el coste: calcula que la inferencia de esta versión sale un 10 por ciento más cara que la de Spark-ASR-1.0. Es una cifra suya, no de un tercero, y no viene acompañada de ninguna medida de precisión, latencia o consumo por hora de audio procesada. Tampoco hay demo pública ni comparativa contra otros motores.
Por qué el code-switching importa
El salto de idioma a mitad de frase es un problema clásico en producción. Un motor entrenado para una sola lengua tiende a transcribir mal o directamente a inventar cuando el hablante cambia de idioma, y en entornos reales —soporte técnico, reuniones, atención al cliente— eso obliga a trocear el audio o a tirar de dos modelos en paralelo. Lo mismo pasa con el ruido: la mayoría de los ASR funcionan razonablemente en un estudio y se caen en una oficina.
Si iFlytek resuelve ambos casos con un 10 por ciento más de coste de inferencia, es un intercambio que a quien despliega esto le interesa mirar. La duda es si ese 10 por ciento se mide sobre el mismo hardware, y con qué vocabulario y duración de audio.
De momento hay poco que evaluar. Quien quiera probarlo tendrá que esperar a que la API abierta esté disponible y a que la compañía publique la documentación y los límites reales del servicio.
