MOSS-Live acepta audio a 16 kHz y no pone la conversación en pausa para buscar

La mayoría de las IA de voz todavía conversan como walkie-talkies. Primero habla la persona; después, el sistema reconoce la frase, piensa y responde. Si se lo interrumpe a mitad de camino, la respuesta suele cortarse definitivamente o empezar de nuevo. En una conversación en vivo, esto resulta irritante muy pronto: no se puede intercalar un “sí”, aclarar un detalle ni hacer una pausa natural para elegir una palabra.

MOSI Intelligence propone otro enfoque. Según sus desarrolladores, MOSS-Live sigue escuchando mientras habla, distingue una reacción breve de una orden para detenerse y puede volver a una frase inconclusa después de una interrupción. La API recibe audio a 16 kHz y entrega una salida a 48 kHz. La conexión se realiza mediante WebSocket y las imágenes se transmiten como fotogramas JPEG independientes.

No una cola de turnos, sino un flujo compartido

Imaginemos un asistente de voz para una tienda en línea. Está explicando las normas de devolución y, a mitad de la explicación, el cliente pregunta: “¿Y si ya tiré la caja?”. Un agente convencional seguirá hablando por encima de la persona o perderá la respuesta original. MOSS-Live debería escuchar la aclaración, responderla y después volver al punto en el que se detuvo.

Lo importante no es el efecto de la interrupción en sí, sino la gestión del estado de la conversación. El sistema debe entender que “ajá” no significa que deba detenerse, que una pausa dentro de una frase no pone fin al turno y que una conversación ruidosa cercana puede no estar dirigida al agente. Es justo aquí donde suelen fallar los productos de voz, aunque la síntesis y el reconocimiento del habla ya funcionen bastante bien por separado.

Los desarrolladores también afirman que el sistema puede trabajar con la cámara, la pantalla compartida y los sonidos del entorno. Esto permite crear un asistente que no solo oiga la pregunta, sino que también vea la interfaz o el objeto que tiene delante el usuario. Por ejemplo, un agente de soporte técnico podría observar la pantalla e indicar por voz el siguiente paso.

Dos modelos en lugar de una pausa

La arquitectura separa la parte conversacional rápida del trabajo más lento que se ejecuta en segundo plano. La primera recibe continuamente audio e imágenes y mantiene el diálogo. La segunda busca datos, invoca herramientas o elabora un plan. Un estado compartido las conecta, por lo que la conversación no tiene que detenerse mientras se realiza una búsqueda.

Un caso práctico sería el siguiente: el usuario pide buscar billetes y después habla sobre las restricciones de equipaje mientras el modelo en segundo plano comprueba las opciones. Cuando termina la búsqueda, el resultado se incorpora a la conversación en el momento adecuado. Para un producto, esto resulta más útil que un indicador de carga convencional: el agente sigue disponible, puede recibir una nueva condición y corregir una tarea que todavía no ha terminado.

Sin embargo, aquí aparece también un difícil problema de ingeniería. Si el usuario cambia la fecha del viaje mientras ya se está ejecutando una búsqueda en segundo plano, el sistema debe cancelar la tarea obsoleta o marcar su resultado como desactualizado. Sin control de versiones del estado, un diálogo continuo y elegante empezará a ofrecer con seguridad respuestas a solicitudes antiguas.

Qué comprobar antes de la integración

Por ahora, MOSS-Live está disponible como beta gratuita. No se ha publicado la tarifa de la futura facturación por tiempo de conexión. No hay pesos del modelo y el despliegue solo es posible a través de la API. La documentación no enumera todos los idiomas compatibles; las demostraciones utilizan inglés y chino, y no se ha declarado la calidad en ruso.

Tampoco existen mediciones públicas e independientes de la latencia, la precisión al detectar interrupciones o la resistencia al ruido. Por eso, todavía es pronto para comparar el sistema con Gemini Live y GPT Realtime basándose únicamente en vídeos de demostración. Es especialmente importante comprobar las detenciones falsas, la recuperación tras una caída de la conexión, el coste de una sesión larga y el comportamiento de las tareas en segundo plano cuando cambia la solicitud.

Lo razonable para un desarrollador es empezar con un prototipo limitado: un escenario, varios tipos de interrupción y un registro de todas las transiciones de estado. El producto debería medir no solo la latencia hasta el primer audio, sino también la proporción de interrupciones procesadas correctamente, el número de reanudaciones perdidas y el tiempo que tarda en volver un resultado en segundo plano. Si MOSS-Live supera esta prueba, podría convertirse en la base de interfaces de voz que no se perciban como un chat leído en voz alta, sino como un interlocutor real.