MOSS-Live accepte l'audio 16 kHz et ne met pas la conversation en pause pendant une recherche

La plupart des IA vocales parlent encore comme un talkie-walkie. L'humain parle d'abord, puis le système reconnaît la phrase, réfléchit et répond. Si on l'interrompt en plein milieu, la réponse s'arrête souvent définitivement ou repart de zéro. Dans une conversation réelle, c'est vite agaçant : impossible d'glisser un « oui », de préciser un détail ou de chercher tranquillement ses mots.

MOSI Intelligence propose une autre approche. D'après ses développeurs, MOSS-Live continue d'écouter pendant qu'elle parle, distingue une courte réaction d'une commande d'arrêt et, après une interruption, sait revenir à la phrase inachevée. L'API accepte en entrée un audio à 16 kHz et renvoie en sortie du 48 kHz. La connexion passe par WebSocket, et l'image est transmise sous forme de trames JPEG distinctes.

Non pas une file de répliques, mais un flux partagé

Imaginons un assistant vocal pour une boutique en ligne. Il explique les règles de retour, et le client demande au milieu : « Et si j'ai déjà jeté le carton ? » Un agent classique soit continue de parler par-dessus l'humain, soit oublie sa réponse initiale. MOSS-Live doit entendre la précision, y répondre, puis revenir à l'endroit où elle s'était arrêtée.

Ce qui compte, ce n'est pas l'effet d'interruption en soi, mais la gestion de l'état de la conversation. Le système doit comprendre qu'un « mm-hm » ne signifie pas un arrêt, qu'une pause au sein d'une phrase ne termine pas la réplique, et qu'une conversation bruyante à proximité ne concerne pas du tout l'agent. C'est précisément là que les produits vocaux échouent d'ordinaire, alors que la synthèse et la reconnaissance vocales fonctionnent déjà correctement prises séparément.

Les développeurs annoncent également la prise en charge de la caméra, du partage d'écran et des sons environnants. Cela permet de construire un assistant qui non seulement entend la question, mais voit aussi l'interface ou l'objet placé devant l'utilisateur. Par exemple, un agent de support technique pourrait suivre l'écran et indiquer vocalement l'étape suivante.

Deux modèles au lieu d'une pause

L'architecture sépare la partie conversationnelle rapide du travail de fond, plus lent. La première reçoit en continu le son et l'image et entretient le dialogue. La seconde cherche des données, appelle des outils ou élabore un plan. Un état partagé les relie, de sorte que la conversation n'a pas à s'arrêter pendant la recherche.

Un scénario pratique : l'utilisateur demande de trouver des billets, puis discute des limites de bagages pendant que le modèle d'arrière-plan vérifie les options. Quand la recherche se termine, le résultat est réintégré dans la conversation au bon moment. Pour un produit, c'est plus utile qu'un simple indicateur de chargement : l'agent reste disponible, peut accepter une nouvelle condition et corriger une tâche pas encore terminée.

Mais un problème d'ingénierie délicat apparaît ici aussi. Si l'utilisateur change la date du voyage alors que la recherche en arrière-plan est déjà en cours, le système doit annuler la tâche obsolète ou marquer son résultat comme périmé. Sans gestion des versions de l'état, ce beau dialogue continu se mettra à apporter avec assurance des réponses à d'anciennes requêtes.

Que vérifier avant l'intégration

Pour l'instant, MOSS-Live est disponible en bêta gratuite. Le tarif futur, facturé à la durée de connexion, n'est pas publié. Il n'y a pas de poids du modèle ; le déploiement n'est possible que via l'API. La documentation ne liste pas toutes les langues prises en charge ; les démonstrations utilisent l'anglais et le chinois, et la qualité du russe n'est pas annoncée.

Il n'existe pas non plus de mesures indépendantes publiques de la latence, de la précision de détection des interruptions ou de la robustesse au bruit. Comparer le système à Gemini Live et GPT Realtime uniquement sur des vidéos de démonstration est donc prématuré. Il est particulièrement important de tester les arrêts intempestifs, la reprise après une coupure de connexion, le coût d'une longue session et le comportement des tâches de fond lorsque la requête change.

Il est raisonnable pour un développeur de commencer par un prototype étroit : un seul scénario, plusieurs types d'interruptions et un journal de toutes les transitions d'état. Un produit gagnera à mesurer non seulement la latence du premier son, mais aussi la part d'interruptions correctement traitées, le nombre de reprises perdues et le temps de retour du résultat d'arrière-plan. Si MOSS-Live passe ce test, elle pourrait devenir la base d'interfaces vocales qui ne ressemblent pas à un chat mis en voix, mais à un véritable interlocuteur.