インタラクションモデル - 人間とAIの協働のためのスケーラブルなアプローチ

 (thinkingmachines.ai)
4 ポイント 投稿者 GN⁺ 3 시간 전 | 2件のコメント | WhatsAppで共有
  • 外部ハーネスではなく、モデルがオーディオ、ビデオ、テキストをリアルタイムで同時に入出力し、人間と自然に協働
  • 従来のターンベースモデルには、ユーザーが話し終えるまで待機し、生成中は新たな入力を受け取れない協働のボトルネックがあった
  • 200ms単位のマイクロターン設計により、入力と出力を連続ストリームとして処理し、割り込み・同時発話・視覚的反応など多様なインタラクションモードをサポート
  • システムでは、リアルタイム会話を担うInteraction Modelと、長期推論・ツール利用を担うBackground Modelが文脈を共有
  • インタラクティビティがモデル自体に組み込まれているため、スケーリング時により賢くなるのと同時により優れた協働相手にもなる

協働のボトルネックとInteraction Modelの目標

  • Thinking Machines Labは、外部ハーネス（harness）ではなく、モデル自体が相互作用を処理するInteraction Modelの研究プレビューを発表した
  • 目標は、AIの知能だけでなくインタラクティブ性も同時に拡張できるようにすることであり、モデルがオーディオ・ビデオ・テキストを継続的に受け取り、リアルタイムに考え、応答し、行動する方式である
  • 現在の多くのAI研究やインターフェースは、AIが自律的に長時間作業する能力を重視しているが、人が継続的に介入するhands-on-keyboard作業では、モデルが遅すぎると感じられ、価値が見えにくくなることがある
    • 人間がループの中にとどまるよう最適化されていない
  • 実際の業務では、要件を最初から完全に指定して離れるやり方は難しく、人が途中で明確化やフィードバックを与える協働プロセスが良い結果につながる
  • 従来のターンベースモデルは、ユーザーが入力を終えるまで待ち、モデルが生成している間は新しい情報を受け取れないため、現実を単一スレッドのように経験している
    • この構造は、ユーザーの知識・意図・判断がモデルに伝わる幅と、人がモデルの作業を理解できる幅を狭める
  • Thinking Machines Labは、このボトルネックを解消するにはあらゆるモダリティにおけるリアルタイム相互作用が可能でなければならず、人がAIインターフェースに合わせるのではなく、AIが人のやり方に合わせるべきだと見ている
  • 既存のAIモデルの多くは、途切れのなさ、マルチモーダル性、同時性を模倣するために複数のコンポーネントをつなぎ合わせたハーネスを使っているが、The Bitter Lessonによれば、手作業のシステムは汎用能力の拡張に劣後する可能性がある
  • インタラクティブ性が知能とともに拡張されるには、モデル内部の機能である必要があり、モデルを大きくすれば、より賢くなるだけでなく、より優れた協働相手にもならなければならない

モデル内部の相互作用が開く機能

  • 自然な対話管理

    • モデルは、話者が考え中か、発話を譲ろうとしているか、自分で言い直しているか、応答を促しているかを暗黙的に追跡する
    • 別個の対話管理コンポーネントなしに、こうした判断を処理する

  • 音声・視覚ベースの介入（割り込み）

    • モデルは、ユーザーが話し終えたときにだけ反応するのではなく、文脈に応じて必要な瞬間に割り込むことができる
    • ユーザーが誤ったことを言ったときに遮ったり、コードにバグを書いたときに視覚的な手がかりを見て知らせたりすることが可能になる

  • 同時発話

    • ユーザーとモデルが同時に話すことができ、リアルタイム翻訳のような状況で有用である

  • 時間認識

    • モデルは経過時間を直接認識し、特定の時間間隔に合わせて話したり、ユーザーの行動時間を測定したりする課題を扱える

  • ツール呼び出し・検索・生成UIの同時実行

    • モデルは、ユーザーと話し聞きしながら同時に検索、Webブラウジング、UI生成を実行できる
    • 結果の準備ができれば、対話の流れに合わせて再び組み込む
    • 長い実際のセッションでは、こうした機能が継続的に同時進行し、プロンプトを送る感覚よりも協働している感覚に近くなる

アプローチ

  • 時間整列マイクロターン

    • Interaction Modelは連続する入出力ストリームをマイクロターンに分割し、時間を基準に相互作用を構成する
    • ターンベースモデルは交互に続くトークン列を見るが、時間認識型のInteraction Modelは連続するマイクロターンのストリームを見るため、沈黙、重なり、割り込みがモデルのコンテキストに残る
    • モデルはユーザーとの継続的な双方向のやり取り状態を維持し、知覚と応答を同時に行う
    • ロボティクスと自動運転は物理世界の要件からリアルタイム動作を前提としており、Moshi、PersonaPlex、nemotron-voicechat、Seeduplexのようなオーディオのフルデュプレックスモデルも双方向・連続相互作用の例である

  • システム構成

    • システムは、リアルタイムの存在感を維持する時間認識型 Interaction Modelと、継続的な推論・ツール利用・長期タスクを担う非同期 Background Modelで構成される
    • より深い推論を即座に生成できないとき、Interaction ModelはBackground Modelに委譲する
    • 委譲中もInteraction Modelは引き続きユーザーの前面に残り、後続の質問に答え、新しい入力を受け取り、対話コンテキストを維持する
    • Background Modelの結果は生成され次第ストリーミングされ、Interaction Modelがユーザーの現在の行動に合ったタイミングで対話に統合する
    • 2つのシステムはコンテキストを共有し、ユーザーは非推論モデル並みの応答遅延の中で、推論モデルの計画、ツール利用、エージェントワークフローをあわせて活用できる
    • Background ModelとInteraction Modelはどちらも知能を備えており、Interaction Model単体でも相互作用および知能ベンチマークで競争力のある性能を示す

  • Interaction Modelの構造

    • 設計の出発点は本質的にリアルタイムである連続オーディオとビデオであり、テキストは待ててもリアルタイム対話は待てない
    • モデルはテキスト、オーディオ、ビデオの任意の部分集合を入力として受け取り、テキストとオーディオを予測する
    • 200ms分の入力処理と200ms分の出力生成を継続的に交互に行うマイクロターンで動作する
    • 完成したユーザーターンを消費して完成した応答を生成するのではなく、入力トークンと出力トークンの両方をストリームとして処理する
    • この方式は複数の入出力モダリティのほぼリアルタイムな同時性を可能にし、モデルが守るべき人工的なターン境界をなくす
    • 既存のリアルタイムシステムの多くは、ターンベースモデルをリアルタイムらしく見せるために、音声活動検出（VAD）のようなハーネスでターン境界を予測する
    • こうしたハーネスコンポーネントはモデル自体より知能が低く、能動的な割り込みや視覚的手がかりへの反応といった相互作用モードを制限する
    • Interaction Modelでは、こうした相互作用モードは特別なハーネスではなく、モデルが実行できる特殊事例となり、モデルサイズと学習データの拡張に応じて品質を改善できる

  • エンコーダなしの早期融合

    • オーディオとビデオを大きな独立エンコーダで処理する代わりに、最小限の前処理を使う構造を選択した
    • 多くのオムニモーダルモデルではWhisper類似のエンコーダやTTS類似のデコーダを別々に学習させる必要があるが、このモデルはオーディオ信号をdMel形式で受け取り、軽量な埋め込み層に変換する
    • dMelはBai, et al. 2024に従う
    • 画像は40x40パッチに分割した後、hMLPでエンコードする
    • オーディオデコーダにはflow headを使用する
    • すべてのコンポーネントはトランスフォーマーとともに最初から共同学習される

  • 推論最適化

    • 推論時には200msチャンクごとに小さなprefillとdecodeが頻繁に必要になり、各段階が厳格な遅延条件を満たさなければならない
    • 既存のLLM推論ライブラリは、小さなprefillが頻発する状況に最適化されておらず、ターンごとのオーバーヘッドが大きい
    • そのためstreaming sessionを実装し、クライアントが各200msチャンクを別個のリクエストとして送ると、推論サーバーがGPUメモリ上の持続シーケンスにチャンクをつなぎ込むようにした
    • この方式は頻繁なメモリ再割り当てとメタデータ計算を回避し、その機能の一版をSGLangにupstreamした
    • 双方向サービングで現れるshapeと遅延を基準にカーネルも最適化した
    • MoEカーネルには標準のgrouped gemmの代わりに、PyTorchとCursorの先行研究のようにgather+gemv戦略を用いる

  • Trainer-Sampler整列

    • ビット単位のtrainer-sampler alignmentは、学習安定性とシステムコンポーネントのデバッグに有用だった
    • batch-invariant kernelsを実装しており、全体の性能オーバーヘッドは5%未満である
    • All-reduceとreduce-scatterにはNVLSを使用し、Blackwell上で決定論的な低遅延通信カーネルを実装した
    • このカーネルは、Sequence ParallelismやTensor Parallelismのような異なる並列化戦略の間でもビット単位の整列を達成する
    • Attentionの主な課題はSplit-KVで、一般にdecodeとprefillの間で累積順序の不一致を生む可能性がある
    • decodeとprefillの間で一貫してsplitを選べば累積順序を維持でき、例としてSMを4096トークン単位でleft-aligned処理することでprefillとdecodeの両方で効率を得られる

  • 2つのモデルの協調

    • Interaction Modelが委譲する際には、独立したクエリではなく、対話全体を含む豊富なコンテキストパッケージを送る
    • Background Modelの結果は生成されるたびに戻り、Interaction Modelが唐突なコンテキスト切り替えではなく、ユーザーの現在の行動に合ったタイミングでそれを対話に織り込む

  • 安全性

    • リアルタイム相互作用はターンベースのやり取りとは異なる形で安全性に負荷をかけるため、作業はモダリティに適した拒否と長期対話の堅牢性に集中している
    • 音声での拒否が口語として自然に聞こえるよう、TTSモデルで許可されないトピック範囲の拒否および過剰拒否の学習データを生成する
    • 拒否の境界は自然な表現を優先しつつ、断固さを弱めないよう補正されている
    • 長いspeech-to-speech対話で堅牢性を高めるため、自動レッドチームハーネスでマルチターンの拒否データを生成する
    • テキストベースの拒否との行動類似性も近く維持する

ベンチマークと評価

  • 知能とインタラクション性

    • モデル名は TML-Interaction-Small であり、強い知能・指示追従性とインタラクション性をあわせ持つ最初のモデルとして提示されている
    • インタラクション品質は FD-bench で測定する
    • FD-bench v1.5 では事前録音された音声が与えられたとき、モデルが特定の時点で応答する必要があり、ユーザーの割り込み、相づち、他者との会話、背景発話の状況でのモデルの挙動を測定する
    • 知能は、知能と指示追従を追跡する一般ベンチマークである Audio MultiChallenge で測定する
    • TML-Interaction-Small は FD-bench V1 のターンテイキング遅延で 0.40秒 を記録し、表にある比較モデルより低い遅延を示した
    • FD-bench V1.5 の平均スコアは 77.8 で、比較対象である GPT-realtime-2.0、GPT-realtime-1.5、Gemini-3.1-flash-live、Qwen 3.5 OMNI-plus-realtime より高い
    • FD-bench V3 Audio+Tools では Background Agent 有効時の 応答品質 82.8% / Pass@1 68.0% を記録した
    • QIVD Video+Audio の正確度は 54.0% で、一部の比較モデルより低いか同程度である
    • Audio MultiChallenge APR は 43.4% であり、GPT-realtime-2.0 xhigh の 48.5% よりは低いが、instant モデル群よりは高い
    • BigBench Audio は Background Agent 有効時の 75.7 / 96.5 と報告されている
    • IFEval は VoiceBench Audio で 82.1%、Text で 89.7% を記録した
    • Harmbench のテキスト拒否率は 99.0% である

  • 既存評価では捉えられないインタラクションの次元

    • 既存のインタラクションベンチマークは、モデルで観察される質的な飛躍を十分に捉えられないため、時間認識、同時発話、視覚的プロアクティビティを測る内部・改変評価が追加された

  • 時間認識と同時発話

    • ターンベースのモデルと対話管理システムは、正確な時間推定や同時発話をサポートしない
    • 例題は「1マイル走るのにどれくらいかかったか」「私の発音を聞いたらすぐに直してほしい」「この関数を使うのにどれくらい時間がかかったか」といった形式である
    • TimeSpeak は、モデルがユーザーの指定した時刻に合わせて話し始め、正しい内容を話せるかをテストする
    • 例として「呼吸の練習をしたいので、止めてと言うまで 4 秒ごとに息を吸って吐くよう知らせてほしい」がある
    • CueSpeak は、適切な瞬間に意味的に正しい応答を話せるかをテストする
    • データは、満点を得るためにモデルがユーザーと同時に話さなければならないよう構成されている
    • 例として「私がコードスイッチして別の言語を使うたびに、元の言語で正しい単語を言ってほしい」がある
    • 2 つのベンチマークは各例題ごとに期待される意味応答と時間ウィンドウを 1 つずつ持ち、LLM judge が意味とタイミングの両方を満たしたときのみ正答として採点する

  • 視覚的プロアクティビティ

    • 現在の商用リアルタイム API は主に音声ベースの対話管理ハーネスでターンを検出しており、視覚世界が変化したときに自ら話すタイミングを選ぶことはできない
    • StreamBridge、Streamo、StreamingVLM、MMDuet2 は、ストリーミング動画入力からいつテキストを出力するかを扱っている
    • こうしたテキスト出力研究は、発話には持続時間があり、ユーザーと重なる可能性があり、ターンテイキング・割り込み・相づちと調整されるべきという音声出力インタラクションの制約を扱っていない
    • AURA は、VideoLLM がテキストを出すか沈黙するかの時点を決める構造に ASR/TTS デモを付けた形であり、Thinking Machines Lab のモデルは speech-native かつ full-duplex である点が異なる

  • 視覚的プロアクティビティ評価

    • RepCount-A は、反復動作動画をオンラインカウント課題に改変したものである
    • モデルには「{action} の反復回数を数えてほしい」という音声指示と動画がストリーミングされ、正解の終わりから 2 回前の反復以降にモデルが話した最後の数字が、正解と 1 回以内の差かどうかで採点する
    • この課題は連続的な視覚追跡とタイムリーなカウントを測定する
    • ProactiveVideoQA は、特定の瞬間に答えが分かるようになる質問を含む動画で構成される
    • 質問を音声でストリーミングした後に動画を送り、字幕がある場合は動画に焼き込み、入力動画はミュートして視覚的プロアクティビティを強調する
    • 評価は論文の turn-weighted PAUC@ω=0.5 指標を 0〜100 にスケールし、ターンとカテゴリの平均を取り、沈黙し続けると 25.0 点になる
    • 高得点には、正しい答えを正しいタイミングで話すことが必要であり、誤答にはペナルティがある
    • Charades は標準的な時間的行動位置推定ベンチマークで、各動画にはラベル付けされた時間区間で発生する行動が含まれる
    • モデルは「人が {action} を始めたら『start』と言い、止めたら『Stop』と言え」という音声指示と動画ストリームを受け取り、予測区間と参照区間の temporal IoU で採点される

  • 現在のモデルの限界

    • 既存モデルは、このような時間認識、同時発話、視覚的プロアクティビティ課題を意味のある形では実行できない
    • 完全性のために GPT Realtime-2 minimal の結果が報告されているが、thinking high モデルを含むすべての評価モデルは同程度かそれ以上に悪く、沈黙するか誤った答えを出す
    • インタラクション性は今後の重要な研究分野と見なされており、Interaction Model や人間-AI 協働評価フレームワークなどのための研究助成計画が予告されている

限界と公開計画

  • 長時間セッション

    • 連続した音声と動画はコンテキストを急速に蓄積する
    • streaming-session 設計は短時間から中程度の長さのインタラクションをうまく処理するが、非常に長いセッションでは慎重なコンテキスト管理が必要である

  • 計算資源とデプロイ

    • 低遅延で音声と動画をストリーミングするには、安定した接続が必要である
    • 良好な接続がなければ体験は大きく悪化する
    • システムの信頼性を高め、遅延したフレームにより頑健になるようモデルを訓練すれば、改善の余地がある

  • アラインメントと安全性

    • リアルタイムインターフェースは、アラインメントと安全性の両方において新たな研究領域を開き、フィードバック収集と研究助成の検討が進行中である

  • モデルサイズの拡張

    • 現在の TML-Interaction-Small は 276B パラメータの MoE であり、アクティブパラメータは 12B である
    • モデルスケールが大きくなればインタラクション性も改善すると期待されるが、より大規模な事前学習モデルは現時点ではこの設定でサービングするには遅すぎる
    • より大きなモデルは今年後半に公開する計画である

  • Background Agent の改善

    • 主な焦点はリアルタイムのインタラクション性だが、エージェント知能も必須の能力である
    • エージェント知能をフロンティア水準まで引き上げることに加え、Background Agent が Interaction Model とどのように連携するかはまだ初期段階にある

  • 公開スケジュール

    • 今後数か月以内にフィードバック収集のための限定的な研究プレビューを開始し、今年後半により広く公開する予定である

関連記事

2件のコメント

 
xguru 2 시간 전

これは添付された動画を見るべきです。この程度の遅延でもかなり現実的ですね。 もう少し発展すれば、本当に映画で見たように会話を交わせるようになりそうです。
 
GN⁺ 3 시간 전
Hacker Newsのコメント

  • この動画群は一見の価値がある。印象的な場面が多いが、最初の場面で女性が「ひとつ話をしてみますね」と言ったあと、コーヒーを長く飲んでいる間、モデルが何もせずただ待っていたところで一気に納得した。有料で使いたくなった
    お金の話が出たついでに、こういう会社の経済モデルが何なのか気になる。アーキテクチャはかなり公開していて、フロンティア研究所なら実装できる程度には公開されているように見える。特許？営業秘密？ Anthropic/GOOG/oAI/Meta の学習計算量とノウハウに、法的保護なしでどう勝つのか理解しづらい
    こうしたモデルアーキテクチャがレイテンシを30〜40%下げてさらに賢くなったらどうなるのか楽しみだ。ちなみにこのモデルは Opus 4.7 / GPT 5.x 系のだいたい 1/10 の規模で、275B、active 12B 程度に見えるので、知能をさらに積み増す余地も大きく、より低いレイテンシも期待できる

    • 公開されているアーキテクチャは氷山の一角である可能性が高い。ハイパーパラメータ調整、データレシピ、データ収集、カスタムカーネル、強化学習/評価インフラはどれも非常に深いテーマで、こうした最先端の性能を出すには複数の博士の何十年分もの時間が圧縮されている必要がある
      単に待つこと自体は後段学習寄りなので、Gemini や oAI がそれを優先していなかった事実を過大解釈しないほうがいい。ここで示された**全二重(full duplex)**は、技術的にははるかに難しい達成だ
    • 中国では、有望な新興企業がAlibaba や Tencentのどちらかから買収提案を受けることはよく知られている。米国でも似たようなものだろう。公開したものは買収されるか、ただ複製される可能性がある。Thinking Machines もそれを期待しているのかもしれない
    • 経済モデルはもともと企業向け LLMではなかったかと思う。tinker は企業向けのカスタムモデル微調整用で、interaction models は、企業が AI エージェント中心にプロセス全体を再発明しなくても、デジタルな相棒社員のように働かせる方向だ
    • 先端研究者を採用するには、彼らが論文を出せるようにしなければならず、そうでなければ働かない

  • 目を引くのは、このアーキテクチャがテキスト、画像、音声入力を受け取り、テキストと音声を出力するトランスフォーマーであり、しかもすべて一緒に学習されている点だ。また、与えられたプロンプトから出力を純粋生成する代わりに、入力と出力を相互に差し込みながら、ほぼリアルタイムで動作する
    “Time-Aligned Micro-Turns. The interaction model works with micro-turns continuously interleaving the processing of 200ms worth of input and generation of 200ms worth of output. Rather than consuming a complete user-turn and generating a complete response, both input and output tokens are treated as streams. Working with 200ms chunks of these streams enables near real-time concurrency of multiple input and output modalities.”
    私には、これが他のフロンティア研究所のマルチモーダルモデルと一線を画す核心に見える

    • 最初からマルチモーダルアーキテクチャとして設計されていると、異なるモダリティが同じ対象の「面」のように扱われるアプリケーションが出てきうるという点が本当に面白い。たとえばコーディングエージェントが「コード」+「IDE」+「メモリマッピング」+ 複数のプラグインからのフィードバックを別々のモダリティとして見て、出力もテキストが必要な場所にはテキストで、アクションが必要な場所には今のような call_something(params) ではなくアクションとして出す、という形だ
      あるモダリティがトリガーされるまで「じっとしていられる」能力も興味深い。こうしたことは今でもできるが、後付けに近い形で、それでもかなりうまく動いている。最初から結合された形で学習したらどれほどうまくいくのか気になる
    • 「200ms 分の入力処理と 200ms 分の出力生成を差し込む」というのがどう動くのか気になる。LLM/トランスフォーマーは次のトークン群を出力するのに文脈全体が必要なのではないか？

  • デモを見ると、外部ハーネスにあった構成要素をモデル内部に移しているケースが多いように見えるが、これが本当に柔軟なやり方なのかは分からない
    多くの場合、ユーザー相互作用のハーネスは外部にあったほうが、より速く反復改善できる気がする。たとえばユーザーとモデルの間に UI があり、その UI を変える必要があるなら、ユーザー自身がカスタマイズすることもできる
    私は柔軟性は必須だと思う。リアルタイム翻訳や単純な音声ボットのような固定的なユースケースでは、こうしたモデルは役立つだろうが、それぞれのケースでは結局、より特化した代替手段に押される可能性が高い

  • モデル自体が印象的なのとは別に、ここのデモは本当によく作られている。Anthropic や OpenAI で見てきたものと違って、短くて個性がある

    • 興味深くて印象的で、デモも良いという点には同意する
      ただ、「猫背姿勢」のデモで女性が見せた予想外の身体ギャグは本当に笑えた。完璧なコメディで、直すところがない
      OpenAI/Anthropic 風のデモより、こういう人間味のある雰囲気のほうが好きだ。これをあえて「人間中心設計」の例と呼んでもいいのでは、と思う (https://en.wikipedia.org/wiki/Human-centered_design)

  • とてもクールだ。ただ、デモはかなり作為的にも感じられた。たとえば私が話している間に物を数える、といった具合だ。もっと有用だったり商業的だったりするアプリケーションがどんな姿になるのか気になる

    • 理論上は、現在のフロンティアモデルができることをすべてこなしつつ、より良い協調のためのリアルタイムな相互作用性が加わる形になると期待している。最大の利点はリアルタイムの映像入力かもしれない。動画全体や画像群をまとめて受け取って単一の出力を返すのではなく、入力を受け入れながら、その入力によって調整された出力を並列に作れるからだ
    • どの AI デモでも、こういう点を強く感じる。技術を見せるために考え出した最高のユースケースが、自分で簡単にできる休暇予約なのだとしたら、そのサービスは本当に大きな価値を足しているのだろうか？ それとも、実際の用途はもっと微妙で専門的で、短い大衆向けデモには向いていないだけなのだろうか？ よく分からない

  • より自然な人間-AI 相互作用パターンは、こういう方向に進むべきだと感じる。記事もデモも良い

  • 言いたくはないが、これは AI との相互作用の仕方としてかなり印象的で前進に見える一方で、提示されたユースケースと UX は非現実的だったり、あまり役に立たなかったりするように思える
    リアルタイム翻訳は例外で、それ自体で別個の製品になるべきだと思う。それ以外では、動物の数を数えたりクイズ時間を計ったりする機能には大した効用がない。姿勢検出のデモは面白くはあったが、かなりディストピア的で奇妙だ。高齢の親をマウンテンバイクに連れて行く話を最後まで待たずに AI が割り込んで叱るのも嫌だ
    UX も問題だ。モデルがユーザーを遮るのは、奇妙なユースケース上は必要に見える場合でさえ、流れを壊してしまう。公開されたデモ動画でも、社員/俳優たちが無愛想なロボット機械に遮られていないかのように話し続けるため、かなり集中しなければならない様子が見える。人がこうしたまれな「招かれた割り込み」に参加するときは、主話者の下で話せるし、普通はもっと微妙なタイミングを合わせる
    自動翻訳デモでも、人の声量は下げていたが AI が押し入ってきていたし、実際にあのデモをやるなら、発話をかなり制御するか、もっと可能性が高いのは出力をミュートする必要があっただろう。人間の通訳者には、「出力」を意図した聞き手に向けるやり方がある
    この技術のいちばん良い部分は、最初の動画で AI が不要にユーザーを遮らない場面だった。現在のモデルがいまだに抱えている重要なバグを直したように見える
    良いユースケースとしては、人前で話す練習のときに**「えー」などのフィラー**を数えるくらいかもしれない

    • オムニモデルはリアルタイムの人間-コンピュータ相互作用に非常に有用そうだ。すぐ思いつく例としては、音声アシスタント、カスタマーエクスペリエンス、ゲーム、会議アシスタント、ソフトウェア利用のためのリアルタイムコーチやユーザー補助、翻訳、音声で操作するコンピュータ作業がある
      たとえばフロントエンド/モバイル開発、CAD、3D モデリングのような作業だ。従来、こうした LLM エージェントのユースケースはレイテンシが大きい傾向がある。モデルが話者の発話終了を待ってからツールを呼ぶか応答するかを決め、ツールを呼んだなら、その結果を処理してから再びツールを呼ぶか応答するかを決めなければならないからだ

  • これは、人々がすでにローカルでGemma4 と TTSを使って作っているものに近く、少し派手になった程度に見える
    ローカルモデルもすぐ追いつくだろう

  • 意図は良いのかもしれないが、悪用されれば監視技術を強化する方向に見える。対処すべき時だ