そうそう、だから「リーチ」って言葉を使ったんだよね。エンゲージメントに関係なく、その機能に触れる可能性のあるユーザーの総数を指してるんだ。

これ見てたんだ！いいプロジェクトだね。

Pipecatについてもっと早く知っていればよかったな。数週間前に知ったんだけど、Gemma 4が出てから、Gemma 4 + Kokoro TTS + Whisperを使って、自分だけの完全にローカルな音声アシスタントをゼロから作ってるんだ。 https://github.com/pncnmnp/strawberry。PipecatのスマートターンモデルはVADにすごくいいよ。 https://huggingface.co/pipecat-ai/smart-turn-v3

今はできないけど、こんな感じのことならできるよ。すべてのWebRTCの状態を保存したり、一時停止したりして、次のプロセスで戻すことができるんだ。

これは2つの異なる「レイテンシー」のレイヤーだと思う。記事で言ってるレイテンシーは音声ストリーム自体の輸送に関するもので、君のシナリオのレイテンシーは音声ストリーム内でどれくらい早く反応を始めるかに関するものだよ。

難しい問題だね。無駄話を止めるためにフィラーを入れちゃうことが多いよ。問題を考えるより、いい感じに聞こえることにIQの大半を使ってる気がする。「うん、絶対そう思うよ…」みたいな感じで。これって、タイマーがあるからか、音声処理がテキストよりもコストがかかるからかもしれないね。テキストの応答はタスクにもっと時間をかけるから。

APIを使ってるなら、待つ時間を変更することもできるよ。

音声会話では、全く返事をしないか、「了解」とだけ言うように指示してる。完璧ではないけど、あまり干渉しないからいい感じ。

レイテンシが高いと、もっと問題になるね。話を一時停止して再開すると、モデルはそれに気づく前にもう話を遮ってしまう。実際の実装に問題があると思う。モデルに「考えを終えたら質問するまで『うん』だけ返事して」って指示したら、だいぶマシになった。でも、声モードは別の理由で完全に使えないと思った。モデルとやり取りするとすごく頭が悪く感じるし、言ったことを繰り返したり言い換えたりするし、毎回の回答が「フック」で終わって、全体のやり取りが馬鹿みたいにロボット的になる。指示を無視して止めてって言っても全然聞かないし、最も重要なのは、ブレインストーミングには全く役立たないってこと。実際に使ってみて、こんなにひどいとは思わなかった。これが彼らのキラーアプリになるはずなのに、モデルがすごく調整不足に感じる。

これも経験したことがあって、本当にイライラする。考えが終わってないのに話し続けなきゃいけないプレッシャーがあって、少なくとも自分には不自然に感じる。正しい言葉を探しているときは、それを見つける機会が欲しい。解決策は、レイテンシの高いプロトコルを使うのではなく、もっと賢く一時停止を扱うことだと思う。低レイテンシなら、話を遮ってもボットがすぐにおしゃべりをやめられる。

これは、記事で説明されているレイテンシよりも、音声活動検出（VAD）に関係している。

そうそう、ユーザーが話し終わったって強い信号を得るには、ある程度の「500msの静寂を待つ」が必要なんだよね。処理を始めて、話し続けたら放棄することもできるけど、それは過剰最適化な気がする。1〜2秒の返信は自然だし、君が指摘したように、文の途中で2〜3秒の間を取るのはすごく普通だよ。

強く同意するよ、LLMとやり取りする時は言葉を慎重に選びたい人もいるからね。OpenAIにいろんなチャンネル（開発フォーラムやアプリのフィードバックなど）を通じてこのことを伝えようとしてるんだけど。Grokはプッシュ・トゥ・トークモードをオプションで用意してるけど、ハンズフリーじゃないから、ユーザーが設定できる変数（例えば、音声入力を送る前の秒数の遅延）を持つ方が楽だと思う。

ちょっと関係ないけど、なんでコードベース全体をルートディレクトリに置いて、ネストされたsrcフォルダにしないの？READMEにアクセスするのがすごく難しくなるよね。

「WebRTC for the Curious」とPionに感謝！後者は直接使ってないけど、両方を使ってWebRTCをよりよく理解するのに役立ったよ。

本を全部オンラインにしてくれてありがとう！前に、webRTCデータチャネルを使ってデータベースからブラウザクライアントにCLI経由でデータを渡すアイデアを考えていたときに、少し読んだことがある。君の本のおかげで、自分のユースケースにはあまり合わないってことが分かった。結局、集中管理のコントロールプレーンとウェブソケットを使ったよ。webRTCデータチャネルとゼロコピーのApache Arrow arraybuffers、duckdbのWASMを組み合わせて面白いことができる気がするけど、まだうまくいってない。

ソフトウェア開発者だけが、参照を0から始めるんだよね、笑

pion使ってるよ、作ってくれてありがとう！彼らのアプローチが必要だと思ったか気になるな。音声AIのセットアップの速い部分を減らすために、すごく複雑になってる気がした。速いモデルと正確なVADが、WebRTCの遅延時間を微調整するよりずっと重要だと思うんだけど。

確かにそう見えるね。LiveKitサーバーは、このアーキテクチャにはあまり適していない（SFUの議論で基本的に言ってる通り）。ただ、クライアントSDKにはたくさんの便利なものがあるけど。

そうそう、OpenAIのリアルタイム/音声モードはいいけど、新しいモデルと比べるとちょっとバカだよね。よく自分を繰り返しちゃうし。GoogleのGemini flash live 3.1の方がいいよ、特にAPI経由で使うと。ツール呼び出しもできるし（自分で設定すれば、もっと賢いLLMにも呼び出せる）、推論レベルも設定できるし（高めにしてもリアルタイムに近いし）、Google検索で答えを裏付けることもできる。双方向音声が好きで、今のところこれが一番の選択肢だと思う。AIスタジオで試してみてね。

うん、タイトルの質問には答えられるよ：「最前線から2年遅れのモデルgpt-4oを使って音声応答を提供することによって」

これが彼らの音声モードを使えなくしてる理由なんだよね。4oの返答の仕方が耐えられないし、テキストモードからの質の差がすごいんだ。

Grokの音声は意外と良いよ。フロンティアモデルの思考モードには劣るけど、他のプロバイダーの音声モードよりはマシだね。