MAI-Transcribe-2-Streaming de Microsoft: la transcripción en directo y sus límites

Microsoft anunció MAI-Transcribe-2-Streaming el 1 de octubre. Recibe audio mientras una persona habla y devuelve texto cambiante antes de una transcripción definitiva. Para un desarrollador que añade subtítulos en directo o entrada de voz a una aplicación, la pregunta útil es cómo llegan esas actualizaciones a la aplicación y cuándo puede considerar que el texto está confirmado.

Esta guía de integración, basada en documentación, está dirigida a desarrolladores que evalúan la vista previa pública. El objetivo es decidir si conviene crear un prototipo del modelo e identificar el trabajo necesario en el cliente para mostrar texto en directo y conservar el texto final. Microsoft documenta la ruta y el código de ejemplo; BIG CHANGE no ha desplegado el modelo, ejecutado los ejemplos ni medido su precisión o latencia.

El cambio principal

• Microsoft ha presentado un modelo de streaming que devuelve texto provisional a medida que llega el audio y después confirma los segmentos de la transcripción. La ruta independiente MAI-Transcribe-2 para transcribir archivos procesa audio grabado y documenta un conjunto distinto de opciones.
• Una aplicación que usa la API Realtime debe enviar audio con el formato correcto, gestionar las revisiones del sufijo provisional y decidir cuándo solicitar una transcripción completa. Esas decisiones determinan qué ven los usuarios y cuándo la lógica posterior de la aplicación puede confiar en que el texto es definitivo.
• El modelo de streaming es una vista previa pública sin acuerdo de nivel de servicio. Microsoft no lo recomienda para cargas de trabajo de producción. Las cifras de velocidad y precisión citadas son afirmaciones de lanzamiento y de pruebas comparativas, no mediciones de esta guía.

Elegir una vía de conexión

El catálogo de Microsoft Foundry incluye MAI-Transcribe-2-Streaming versión 2026-08-06 como modelo en vista previa con entrada de audio y salida de texto. El resumen del 1 de octubre de Microsoft documenta dos formas de integración: una API Realtime que utiliza un protocolo WebSocket similar al de OpenAI Realtime, o Azure Speech SDK. Ambas devuelven resultados intermedios y definitivos del reconocimiento. El SDK gestiona la conexión y el envío de audio en streaming; la vía Realtime expone los eventos directamente.

Para la API Realtime, Microsoft requiere una suscripción de Azure, un recurso de Microsoft Foundry en una región compatible y una implementación del modelo de streaming. Conéctate a wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription mediante un token de portador de Microsoft Entra o una clave de API. La documentación recomienda la autenticación de Entra. Después de session.created, envía session.update con el nombre de tu implementación y el formato de entrada. Este ajuste no se puede cambiar después del primer envío de audio, ni siquiera tras confirmar el audio.

La entrada documentada es audio PCM16 sin procesar, firmado, mono y en orden little-endian, a 16 o 24 kHz, enviado en fragmentos codificados en base64 dentro de mensajes de input_audio_buffer.append. Se trata de datos PCM sin encabezado WAV. Microsoft recomienda fragmentos pequeños, por ejemplo de 10 a 20 milisegundos, para reducir la latencia, y señala que los más grandes reducen la sobrecarga de red. Su ejemplo en Python lee audio del micrófono en bloques de 100 ms; la recomendación de fragmentos pequeños y el tamaño de bloque del ejemplo son opciones distintas, no resultados medidos por BIG CHANGE.

La vía de Speech SDK requiere la versión 1.52.0 del SDK, una suscripción de Azure y un recurso de Foundry o Speech. El ejemplo de Microsoft para Python establece speech_config.model en MAI-Transcribe-2-Streaming, proporciona audio mono de 16 kHz y 16 bits mediante un flujo push y escucha los eventos recognizing y recognized. El ejemplo utiliza un archivo audio.pcm preexistente para ilustrar el flujo push; una aplicación proporcionaría su propia fuente de audio. Son interfaces documentadas y tipos de eventos esperados, no una prueba de compatibilidad con una cuenta realizada por esta publicación.

Mantén separado el texto provisional del texto confirmado

La semántica de los eventos Realtime es importante para una interfaz en directo. Un evento conversation.item.input_audio_transcription.delta contiene texto recién finalizado, que la aplicación cliente añade a su búfer confirmado sin cambiar los espacios. Un evento intermediate contiene todo el sufijo provisional actual. Cada sufijo nuevo sustituye al anterior. La pantalla puede mostrar el búfer confirmado junto con ese sufijo actual, pero guardar cada evento intermedio como una línea más duplicaría las palabras a medida que el modelo las revisa.

El cliente envía input_audio_buffer.commit durante una pausa que haya detectado o al terminar una grabación. Microsoft indica que esto solicita una transcripción final lo antes posible; input_audio_buffer.committed confirma la operación y conversation.item.input_audio_transcription.completed proporciona el texto final completo del audio desde la confirmación anterior. La guía Realtime dice que la detección de turnos en el servidor y la confirmación automática no están disponibles con la configuración de sesión de este modelo. Por tanto, una aplicación de voz necesita detectar por su cuenta las pausas o los límites entre turnos si quiere completar segmentos automáticamente. La documentación describe el funcionamiento de los eventos, pero no prescribe un detector de límites adecuado para todos los casos.

Microsoft limita cada sesión Realtime a una hora. También indica que cada envío de audio no tiene un acuse de recibo individual y puede producir cero o varios eventos de transcripción. Al evaluar un prototipo, los desarrolladores deberían distinguir entre la recepción de mensajes de audio y la recepción de texto definitivo, y decidir cómo gestionará la aplicación una sesión desconectada. El ejemplo de Python de la guía pública incluye una cola de micrófono y gestión de errores, pero BIG CHANGE no lo ha ejecutado para comprobar el comportamiento ante fallos.

Acceso, regiones y precio

Microsoft afirma que se puede acceder al modelo desde cualquier lugar y que Azure enruta las solicitudes a las regiones donde se presta el servicio. Las dos páginas de integración del 1 de octubre indican regiones disponibles distintas: la guía Realtime menciona Suecia Central, Centro de EE. UU. y Sur de India; la guía de Speech SDK menciona Suecia Central, Centro de EE. UU. y Sudeste Asiático. Ambas indican que Este de EE. UU. 2 estará disponible próximamente. Comprueba las opciones actuales de implementación y región para la vía que piensas utilizar; estas páginas no ofrecen una lista única y coherente. El acceso global no garantiza una ubicación de procesamiento concreta.

El anuncio indica un precio introductorio de 0,54 dólares por hora de audio hasta finales de 2026. Por aritmética, son 9 dólares por cada 1.000 minutos de audio, antes de cualquier servicio o infraestructura adicional que use la aplicación. Desde sus guías, Microsoft enlaza a las páginas de precios de Foundry Models y del servicio Speech para las respectivas vías. Las fuentes revisadas no indican la tarifa posterior al periodo introductorio ni el importe de una factura probada, por lo que para presupuestar un despliegue hay que comprobar los precios vigentes.

Microsoft afirma que el modelo de streaming admite 60 idiomas con detección automática continua. Dice que el primer resultado parcial aparece poco más de 100 ms después de recibir el audio y cita a Artificial Analysis para afirmar que ocupa un lugar destacado en precisión. La prueba comparativa de streaming de Artificial Analysis mide la tasa de error de palabras en unas ocho horas de conjuntos de datos ponderados y calcula los tiempos de los resultados parciales y definitivos respecto del final detectado del habla. Es una prueba comparativa con audio y reglas de medición específicos, no una garantía de que una aplicación concreta muestre palabras correctas en 100 ms. No verificamos de forma independiente la posición exacta que Microsoft le atribuye, porque el texto público de la prueba que recuperamos no mostraba una fila de resultados específica para el modelo.

La guía independiente sobre MAI-Transcribe-2 en Azure Speech documenta la entrada mediante archivos y opciones como la diarización de hablantes, las marcas de tiempo por palabra, el sesgo de palabras clave y los estilos limpios o literales. No des por hecho que esos controles funcionan con MAI-Transcribe-2-Streaming: las guías de integración en streaming no los documentan. Si un producto necesita esos resultados, evalúa el modelo para archivos o confirma la compatibilidad con streaming mediante documentación actualizada y una prueba antes de basar el diseño en ella.

Fuentes y lecturas adicionales

• Anuncio de Microsoft AI, del 1 de octubre de 2026: fecha de lanzamiento y afirmaciones sobre idiomas, velocidad y precio introductorio. Las afirmaciones de Microsoft sobre precisión y velocidad interna se atribuyen a la empresa en el artículo.
• Catálogo de modelos de Microsoft Foundry, consultado el 2 de octubre: versión del modelo, estado de vista previa y tipos de entrada y salida; el catálogo no es una prueba de rendimiento.
• Resumen de streaming, guía de la API Realtime y guía de Speech SDK, actualizadas el 1 de octubre: las dos vías de integración documentadas, las condiciones de vista previa, el comportamiento de los eventos, los ejemplos y las tablas de regiones. BIG CHANGE no ejecutó los ejemplos.
• MAI-Transcribe-2 en Azure Speech, consultado el 2 de octubre: la vía distinta de transcripción de archivos y sus controles documentados. Su lista de funciones no demuestra que estén disponibles en streaming.
• Prueba comparativa de streaming de Artificial Analysis y metodología, consultadas el 2 de octubre: diseño de la prueba comparativa independiente y definiciones de medición temporal. El texto público recuperado no mostraba la fila de resultados específica del modelo para confirmar de forma independiente su posición.