Show HN : un bot vocal avec un temps de réponse de 500 ms

• Une IA vocale doit réagir immédiatement, comme dans une conversation normale, pour paraître naturelle ; cette démo vise donc une réponse voix-à-voix en 500 ms
• Le défi principal consiste à réduire la latence perçue par l’utilisateur, à laquelle contribuent à la fois le réseau et le temps de traitement du modèle
• La démo montre jusqu’où il est possible d’aller en matière d’interactions LLM à faible latence grâce à l’optimisation et au mode de déploiement
• L’implémentation s’appuie sur Pipecat, un framework open source pour l’IA conversationnelle vocale et multimodale
• Pour créer un bot vocal conversationnel de niveau produit réel, il est essentiel de gérer la latence de toute la chaîne d’appel, pas seulement les performances du modèle

---

Démo visant une réponse vocale en 500 ms

• The World's Fastest Voice Bot Demo est une démonstration qui montre à quelle vitesse un chatbot IA vocal peut réagir
• L’objectif est d’atteindre un temps de réponse voix-à-voix de 500 ms
• Comme les humains s’attendent à des réponses rapides dans une conversation ordinaire, la vitesse devient un critère de qualité essentiel pour les interfaces d’IA vocale

Orientation de l’implémentation pour réduire la latence

• La démo est centrée sur des interactions LLM à faible latence
• Elle montre le potentiel d’un chatbot IA vocal optimisé et déployé pour minimiser à la fois la latence réseau et celle du modèle
• Le bot est construit avec Pipecat
  • Pipecat est un framework open source pour l’IA conversationnelle vocale et multimodale

[GN⁺]

Avis sur Hacker News

• Vraiment rapide. Excellent et propre. On a l’impression que la vitesse l’emporte sur tout le reste. Ce n’est qu’après avoir lu les commentaires que j’ai remarqué la voix robotique.
  J’ai déjà créé une IA pour le support client, et le temps de réponse moyen est passé de 24–48 heures à quelques secondes.
  Un message du type « Hello Bitch, your package will be picked up by USPS today... » a été envoyé à une cliente, qui a répondu « thank you so much » et a donné la note CSAT maximale. Même avec une erreur aussi grave, la vitesse l’emporte sur tout.

  • Je ne pense pas que tout le monde réagirait comme ça. Pour certaines personnes, s’appeler bitch mutuellement fait partie du langage courant, donc c’est possible que ce soit entré dans les données d’entraînement, mais pour d’autres pas du tout.
  • Ce qui est drôle, c’est qu’ils ont corrigé le problème en ajoutant un tag #profanity et en transmettant le message au conseiller suivant.
    Mais l’ingénieur avant-vente le plus actif n’a alors plus pu faire de démos auprès de prospects. Il y avait beaucoup d’appels embarrassants où l’IA ne répondait tout simplement pas, parce que son nom de famille était Dick.
  • Une solution pourrait être de faire passer le message par un autre LLM pour supprimer les grossièretés et le rendre aussi poli que possible. Cela dit, le coût d’exécution ferait probablement plus que doubler.
  • Peut-être que c’était le prénom de la cliente. Ou au moins le nom qu’elle avait saisi.

• Vraiment, vraiment bon. Si j’ai bien compris, ça ressemble à une application teaser pour montrer Cerebrium, mais elle a un gros potentiel de killer app. Testée sur iPad, la latence indiquée variait entre 1400 ms et 400 ms, et dans le bas de la fourchette c’était très fluide.
  Avec ce niveau de vitesse, une approche en plusieurs étapes pourrait devenir nécessaire ou possible dans certains workflows de chat. D’abord répondre rapidement, pendant qu’une requête plus longue de données/informations/RAG tourne séparément, puis laisser un résultat enrichi prendre le relais.
  Les humains fonctionnent aussi comme ça. Ils commencent à répondre tout en organisant leur pensée, en utilisant plusieurs mots de remplissage.
  Aujourd’hui, la plupart des systèmes envoient un prompt d’un seul coup, ou font parsing → requête → génération en arrière-plan, mais avec des réponses à faible latence, un meilleur flux ressemblerait plutôt à « [Llama 8B dans l’oreille pendant 3 secondes] → requête → [55 secondes de Llama 70B/GPT-4, etc., intégrant les résultats de la requête] ».

  • Je suis de chez Cerebrium. Merci beaucoup pour le retour, et ravi que l’expérience ait été bonne.
    Cette application est facile à étendre ou à implémenter, donc vous pouvez la modifier comme vous le souhaitez. Vous pouvez changer de LLM, de reconnaissance vocale, de modèle de synthèse vocale, modifier le prompt, ou implémenter aussi du RAG.
    Avec Daily, nous nous sommes concentrés sur les ingénieurs. Nous voulions rendre l’application très flexible pour l’adapter aux cas d’usage et aux préférences, tout en supprimant la partie pénible de la configuration d’infrastructure.
    Vous pouvez en savoir plus sur les façons de l’étendre ici : https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
  • Je me posais aussi cette question. Serait-il possible d’avoir un petit LLM efficace capable d’estimer la complexité d’une tâche de manière générale, sans exécuter la charge de travail complète ?
    Si l’on peut attribuer un score continu à la complexité, on peut savoir s’il faut d’abord envoyer une réponse du type « Oui, un instant. Je vais vérifier », au lieu d’attendre un long aller-retour.

• Pour un module de détection d’activité vocale multiplateforme dans le navigateur, il y a https://github.com/ricky0123/vad. C’est un portage vers ONNX du réseau VAD de Silero. Par multiplateforme, j’entends que ça fonctionne aussi dans Firefox. C’est plus simple, car il suffit d’avoir accès au micro, sans session WebRTC. Je me demande aussi si les navigateurs proposeront ce genre de fonction comme option native.
  Il existe aussi des moteurs de synthèse vocale basés navigateur, de plus en plus rapides et de meilleure qualité. Ce serait bien que les navigateurs intègrent par défaut un excellent TTS.
  GPT-4o a intégré la reconnaissance vocale automatique, la compréhension et la génération de réponse vocale dans un modèle unique pour obtenir une faible latence, et cela semble être une assez bonne idée. Comme ce n’est toujours pas sorti, il doit y avoir des problèmes de scalabilité ou de qualité sous une forme ou une autre.
  Il doit aussi y avoir des gens qui créent des grands modèles de langage multimodaux ouverts et unifiés, avec entrée/sortie audio et même entrée visuelle.
  Je me demande à quel point un modèle unique couplé est nécessaire et optimal en matière d’optimisation de la latence et des coûts.
  Le tableau de décomposition fourni est intéressant. Si possible, il semblerait préférable de faire tourner davantage de modèles sur l’appareil, notamment la génération vocale, et peut-être même la transcription ou la compréhension vocale au début. Qui a envie d’attendre STUN ?

  • Je pense que les environnements desktop devraient fournir la conversion parole-texte sous forme de service avec une interface standard. Quelque chose comme stdin, mais séparé et dédié à la voix.
    Les apps n’écouteraient pas par défaut et l’ignoreraient donc, mais le transcripteur serait remplaçable et utilisable par toutes les applications.
  • D’après ces chiffres, même si la reconnaissance vocale et la synthèse vocale étaient traitées sur l’appareil, si le reste ne change pas, on ne gagnerait que 120 ms. Les 639 ms restantes viennent de la latence matérielle/réseau et du déplacement des données vers et depuis le LLM. Ça reste plus lent que ce qu’on voudrait.
    Logiquement, il faudrait penser en unités de phonèmes. La sortie du LLM doit rattraper le dernier phonème assez vite pour pouvoir répondre « immédiatement » dès que la fin est détectée, ce qui impose à toute la chaîne une latence de bout en bout d’environ 200 ms.
    Pour s’en rapprocher, il faudra probablement une autre architecture. Comme dans le traitement de la parole chez l’humain : prendre de l’avance sur le flux audio à partir de phonèmes prédits avant leur arrivée, et n’utiliser l’audio réellement reçu que comme un signal léger de vérification pour décider s’il faut vider le buffer de sortie actuel ou le retraiter.
    Le décodage spéculatif permettrait d’aller en partie dans cette direction, mais ce serait difficile avec un pipeline mêlant audio et texte. Il vaut bien mieux éviter dès le départ de convertir l’audio en texte puis de le reconvertir en audio.
  • Cette annonce a complètement éclipsé ce que j’étais en train de construire, mais j’ai une implémentation simple d’assistant qui utilise rick0123/VAD et WebSocket.
    https://github.com/charlesyu108/voiceai-js-starter

• Je l’ai essayé moi-même et c’était amusant. Plus tôt cette semaine, j’ai testé june-va, mais les longs temps de réponse nuisaient pas mal à l’utilité. Les réponses rapides sont une excellente fonctionnalité, et là ça ressemble beaucoup plus à une conversation
  Le plus drôle, c’est que je lui ai demandé de me raconter une histoire et il ne répondait qu’une phrase à la fois, donc pour entendre la ligne suivante je devais dire « yes », « aha », « please continue »
  Puis on a eu cet échange. « Ah, je crois que j’ai découvert ton secret ! » « Dites-moi » « Tu obtiens des temps de réponse courts en gardant un contexte court » « Exactement »

  • Honnêtement, cette approche me va. Au-delà du contexte court, les réponses courtes sont clairement une bonne chose. Ça contraste avec le mode vocal actuel de ChatGPT, qui, dès qu’on lui demande quelque chose, vous sert une tirade façon GPT d’une minute

• Très impressionnant. C’est extrêmement rapide, peut-être même trop rapide, mais c’est sans doute le but. Le plus impressionnant, c’est la manière dont la VAD et la gestion des interruptions sont coordonnées. C’est de loin la conversation avec un agent qui m’a semblé la plus naturelle jusqu’ici. J’ai vraiment envie de l’essayer quand ce sera public

• Le marketing annonce 500, mais le calcul donne 759

  • C’est ce qu’on appelle du marketing
  • Dans mon test, il y a eu une valeur aberrante à 1400 ms, et une dizaine de réponses entre 400 et 500 ms. Le chiffre marketing m’a semblé honnête
  • Les 500 correspondent aux étapes transcription/LLM/TTS, c’est-à-dire au temps entre l’arrivée des données sur le serveur et le renvoi de la réponse. Le reste ressemble à divers délais annexes non liés à l’IA, comme l’encodage et le trafic réseau
  • Les latences du tableau sont basées sur des heuristiques observées ou des moyennes. En pratique, certains des composants de latence les plus importants peuvent être beaucoup plus faibles selon la conversation

• Moi aussi, j’ai hâte de voir le raisonnement vocal. Avant la sortie de GPT-4o d’OpenAI, j’avais construit ma propre implémentation de Faster Whisper basée sur WebSocket. Mon concept de coach d’entretien https://intervu.trueforma.ai et mon coach de pitch commercial https://sales.trueforma.ai se sont fait dépasser par eux
  Je n’ai pas réussi à faire fonctionner la VAD de façon fiable, donc j’ai laissé le push-to-talk par défaut. Tout tourne sur un LattePanda. J’avais prévu de brancher le Whisper hébergé de Groq
  Lassé des conversations d’entreprise ennuyeuses, j’aime bien l’idée d’utiliser le Llama3 non censuré de Groq comme LLM. J’aimerais réduire la latence et apprendre à partir des exemples. Je voudrais aussi essayer la démo, mais elle semble trop sollicitée, je n’arrive pas à lancer une conversation avec le bot
  Rien qu’avec 3 personnes tentant de faire de l’inférence en même temps, mon LattePanda risquerait de fondre

• Personnellement, j’utilise https://github.com/foges/whisper-dictation avec le llama-70b de Groq
  Je commence à parler, je vais sur le site, j’attends la fin du chargement, et au moment de choisir llama-70b j’ai aussi fini de parler, donc le temps d’attente supplémentaire est nul. Comme lire est beaucoup plus rapide qu’écouter, ça me convient parfaitement

• J’utilise encore Firefox

  • J’ai créé cette UI cliente, et je voulais vraiment prendre en charge Firefox
    Il nous fallait un moyen de mesurer la latence voix-à-voix du point de vue de l’utilisateur final, et Silero Voice Activity Detection (https://github.com/snakers4/silero-vad) nous a semblé le plus fiable pour détecter le moment où l’utilisateur cesse de parler, démarrer un minuteur, puis l’arrêter quand l’audio arrive du bot
    Silero tourne avec onnx-runtime et wasm. Ça fonctionne dans une certaine mesure sur Firefox, mais la VAD se comporte mal plus souvent que prévu, ce qui rend les chiffres de latence assez étranges. Je veux quand même absolument que ça marche, et je continue d’essayer
    Le code de la VAD de l’UI est ici : https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
  • Il ne faut pas forcément croire le message d’avertissement. Ça fonctionne bien dans la dernière version de Firefox. La démo est aussi chouette
  • Je déteste que tout le monde développe uniquement pour Chromium
  • Je pense qu’il y a pas mal d’utilisateurs de Firefox sur HN
  • Fonctionne parfaitement avec Firefox 127

• Vraiment impressionnant
  La Siri d’Apple en est encore à permettre seulement des conversations où l’on se coupe la parole, où ça s’arrête, où ça échoue, et où l’on finit par espérer obtenir au moins une réponse minimale