Show HN: 応答時間500msの音声ボット

 (fastvoiceagent.cerebrium.ai)
1 ポイント 投稿者 GN⁺ 2024-06-28 | 1件のコメント | WhatsAppで共有
  • 音声AIは通常の会話のように即座に反応してこそ自然に感じられるため、このデモは 500msの音声対音声応答 を目標としている
  • 中核となる課題は、ユーザーが体感する 遅延時間 を減らすことであり、ネットワークとモデルの処理時間の両方が影響する
  • このデモは、最適化とデプロイ方法を通じて 低遅延LLMインタラクション がどこまで可能かを示している
  • 実装には、音声およびマルチモーダル対話型AI向けのオープンソースフレームワーク Pipecat が使われている
  • 実際の製品レベルの対話型音声ボットを作るには、モデル性能だけでなく、呼び出し経路全体の遅延管理が重要である

500msの音声応答を目指したデモ

  • The World's Fastest Voice Bot Demo は、音声ベースのAIチャットボットがどれほど速く反応できるかを示すデモである
  • 目標は voice-to-voice 500msの応答時間 の達成である
  • 人は通常の会話で素早い応答を期待するため、音声AIインターフェースでは速度が中核的な品質要素となる

遅延を減らす実装方針

  • このデモは 低遅延LLMインタラクション を中心に構成されている
  • ネットワーク遅延とモデル遅延を最小化するよう最適化・デプロイされた音声AIチャットボットの可能性を示している
  • ボットは Pipecat で作られている
    • Pipecat は、音声およびマルチモーダル対話型AIのための オープンソースフレームワーク である

関連記事

1件のコメント

 
GN⁺ 2024-06-28
Hacker Newsのコメント

  • 本当に速い。素晴らしくてクリーン。速度が他のすべてを打ち負かすという感じ。コメントを読んでからやっとロボットっぽい声だと意識した
    カスタマーサポート向けAIを作ったことがあるが、平均応答時間が24〜48時間から数秒に短縮された
    ある顧客に「Hello Bitch, your package will be picked up by USPS today...」のようなメッセージが送られてしまったが、その顧客は「thank you so much」と返信し、CSAT満点を付けた。これほど深刻なミスをしても、速度がすべてに勝つ

    • 誰もがそう反応するわけではないと思う。人によっては互いを bitch と呼ぶのが日常的な話し方で、学習データに入っていた可能性もあるが、別の人たちにとってはまったくそうではないかもしれない
    • 面白いのは、この問題を #profanityタグ を追加してメッセージを次の担当者に渡す方式で直したことだ
      ただし、最も活発なセールスエンジニアが見込み客向けデモをもう実施できなくなった。AIがただ応答しない気まずい通話が多発したのだが、彼の姓はDickだった
    • 解決策は、メッセージを別の LLM に通して罵倒語を除去し、できるだけ丁寧にすることかもしれない。ただし実行コストは2倍以上になりそうだ
    • もしかすると、それが顧客の名前だったのかもしれない。少なくとも顧客がそう入力した名前だった可能性はある

  • 本当に本当に良い。正しく理解しているなら、Cerebrium を見せるためのティザーアプリのようだが、キラーアプリになる可能性が大きい。iPadでテストしたときの報告レイテンシは1400msから400msの間で、低いほうでは非常に滑らかに感じられた
    このくらいの速度なら、一部のチャットワークフローでは多段階アプローチが必要になったり、可能になったりしそうだ。まず素早く応答している間に、より長いデータ/情報/RAGクエリを別で回し、その後に情報を含んだ結果が引き継ぐ形だ
    人間もこう動く。答え始めながら考えをまとめるために、いくつもの フィラー を使う
    今はたいてい一度にプロンプトを投げるか、バックグラウンドでパース→クエリ→生成を行う方式だが、低レイテンシ応答が可能になれば、より良い流れはおおむね「[耳元で3秒間のLlama 8B] → クエリ → [クエリ結果を反映した55秒のLlama 70B/GPT-4など]」に近くなると思う

    • Cerebrium側です。フィードバック本当にありがとう、良い体験だったと聞けてうれしい
      このアプリケーションは簡単に拡張・実装できるので、望む形に修正できる。別のLLM、音声認識、音声合成モデルに置き換えたり、プロンプトを変更したり、RAGのようなものも実装できる
      Dailyとともに、エンジニアに焦点を当てた。ユースケースや好みに合わせてアプリケーションを非常に柔軟に変更できるようにしつつ、退屈なインフラ設定は減らしたかった
      拡張方法はここでさらに見られる: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
    • 私もこれが気になっていた。実際の全ワークロードを回さなくても、一般的な タスク複雑度 を見積もれる小さく効率的なLLMは可能だろうか？
      複雑度を連続値としてスコア化できれば、長い往復を待つ代わりに「はい、少々お待ちください。確認します」のような応答を先に送るべきかどうか分かる

  • クロスプラットフォームブラウザ向けの 音声活動検出 モジュールとして https://github.com/ricky0123/vad がある。SileroのVADネットワークをONNXに移植したものだ。クロスプラットフォームというのはFirefoxでも動くという意味だ。WebRTCセッションなしでマイクアクセスだけあればよいので、よりシンプルだ。ブラウザがこうした機能をネイティブオプションとして提供しているのかも気になる
    ブラウザベースのテキスト読み上げエンジンもあり、ますます高速化し、品質も良くなっている。ブラウザに優れたTTSが標準搭載されるといいのだが
    GPT-4oは低レイテンシのために自動音声認識、理解、音声応答生成を単一モデルに入れていて、かなり良いアイデアに見える。まだリリースされていないのを見ると、何らかのスケーラビリティや品質の問題があるのだろう
    同様に、音声入出力と視覚入力まで備えた公開の統合マルチモーダル大規模言語モデルを作る人たちもいそうだ
    レイテンシとコスト最適化の観点で、単一結合モデル がどれほど必要で最適なのか気になる
    提示された内訳表は興味深い。可能なら、音声生成、ひょっとすると冒頭部分の音声転写や音声理解まで、より多くのモデルをデバイス内で動かすのが良さそうだ。誰がSTUN待ちなんてしたいだろう？

    • デスクトップ環境は、標準インターフェースを持つサービスとして 音声-テキスト変換 を提供すべきだと思う。stdinに似ているが音声用に別立てされたインターフェースのようなものだ
      アプリは基本的に常時聞いているわけではないので無視するだろうが、文字起こし器は交換可能になり、すべてのアプリで使えるようになる
    • この数値どおりなら、音声認識と音声合成をデバイス上で処理しても、残りがそのままなら削減できるのは120msだけだ。残る639msはハードウェア・ネットワーク遅延と、データをLLMの内外に移すのに使われる。それでも望むより遅い
      論理的には 音素 単位で考えるべきだ。LLM出力が最後の音素に十分速く追いついて、終端が検出された瞬間に「即座に」応答できる必要があり、そのためにはチェーン全体でおよそ200ms程度のエンドツーエンド遅延が必要になる
      そこに近づくには別のアーキテクチャが必要そうだ。人間の音声処理のように、到着前に予測した音素をもとにオーディオストリームを先行させ、実際に受信した音声は現在の出力バッファを空にするか再処理するかを決める軽い確認信号としてだけ使う方式だ
      推測デコーディングである程度は行けるが、オーディオ/テキスト混在のパイプラインでは難しそうだ。そもそも音声をテキストに変えてから再び音声に戻さないほうがずっと良い
    • この発表には自分が作っていたものを完全に圧倒されたが、rick0123/VADとWebSocketを使うシンプルなアシスタント実装がある
      https://github.com/charlesyu108/voiceai-js-starter

  • 実際に使ってみたら面白かった。今週初めに june-va を試したが、応答時間が長くて有用性がかなり下がっていた。高速な応答は素晴らしい機能で、これはずっと会話らしく感じられる。
    面白かったのは、話をしてくれと頼んだら一度に一文ずつしか返さず、次の一行を聞くには "yes"、"aha"、"please continue" と言わなければならなかったこと。
    そのうちこんなやり取りになった。"ああ、君の秘密が分かった気がする！" "教えてください" "短いコンテキストを保って短い応答時間を実現しているんだろう" "その通りです"

    • 正直、そのやり方は悪くない。短いコンテキストより短い返答のほうが確実に良い。今の ChatGPT 音声モードは、何か尋ねると 1 分もの GPT 流長広舌を聞かされるのと対照的だ。

  • とても впечатляющий。ものすごく速く、もしかすると速すぎるくらいだが、そこがポイントなのだと思う。最も印象的なのは、VAD と割り込み処理の調整のされ方だ。これまでエージェントと交わした会話の中で、断然いちばん自然に聞こえた。公開されたらぜひ使ってみたい。

  • マーケティングでは 500 と書かれているが、計算では 759 になる

    • それをマーケティングと呼ぶ
    • 自分のテストでは 1400ms の外れ値が 1 つあり、10 回ほどは 400〜500ms の間だった。マーケティングの数値は妥当に見えた
    • 500 は文字起こし/LLM/TTS の段階、つまりサーバーにデータが到着してから応答を送り返すまでの時間だ。残りはエンコードやネットワークトラフィックなど、さまざまな非 AI の付随遅延に見える
    • 表のレイテンシは観測されたヒューリスティックや平均に基づいている。実際には会話次第で、より大きい遅延要素の一部がずっと低くなることもあり得る

  • 自分も音声推論に期待している。OpenAI の GPT-4o リリース前に、WebSocket ベースの Faster Whisper 実装を自作した。自分の面接コーチのコンセプト https://intervu.trueforma.ai と営業ピッチコーチ https://sales.trueforma.ai の実装は、彼らに押し流されてしまった。
    VAD を安定動作させられなかったので、デフォルトはプッシュツートークにしてある。全部 LattePanda で動かしている。Groq のホスト型 Whisper をつなごうとしていた。
    退屈な企業風の会話にうんざりしているので、LLM に Groq の検閲なし Llama3 を使うアイデアが気に入っている。レイテンシを減らして、例から学びたい。デモも試したいが、かなり混み合っているようで、ボットとの会話に入れない。
    同時に 3 人が推論を試しただけでも、自分の LattePanda は溶けそうだ

  • 個人的には https://github.com/foges/whisper-dictation を Groq の llama-70b と一緒に使っている。
    話し始めてサイトへ移動し、読み込みが終わって llama-70b を選ぶ頃には話し終わっているので、追加待ち時間が 0 だ。聞くより読むほうがずっと速いので、自分には完璧に合っている

  • いまだに Firefox を使っている

    • このクライアント UI を作ったが、本当にFirefoxをサポートしたかった。
      エンドユーザー視点で音声から音声までのレイテンシを測る方法が必要で、ユーザーが話すのをやめた時点を検知してタイマーを開始し、ボットから音声が来たら止めるために、Silero 音声活動検出(https://github.com/snakers4/silero-vad) が最も信頼できると判断した。
      Silero は onnx-runtime と wasm で動く。Firefox でもある程度は動くが、VAD が予想以上に頻繁に誤作動するため、レイテンシの数値がかなりおかしくなる。それでも何とか動かしたくて、まだ試している。
      UI の VAD コードはここにある: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
    • 警告メッセージだけで判断しなくていい。最新の Firefox ではちゃんと動く。デモも素晴らしい
    • みんなが Chromium だけを対象に開発するのが嫌だ
    • HN には Firefox を使う人がかなり多い気がする
    • Firefox 127 で完璧に動作する

  • 本当に印象的だ。
    Apple のSiriはまだ、互いに話がかぶり、止まり、失敗して、結局は最低限の答えだけでも得られればと思うような会話しかできない