# 相互運用モデル ## 目的と範囲 本書は、システム内のユーザーとエージェント間の標準的な相互作用モデルを定義する。本書では、各種の条件下においてリクエストが发起され、処理され、応答される仕組みを明らかにし、すべてのエンドポイントで一貫した動作を確保することを目的とする。 ## 基本原則 - **明確性**: すべての相互作用は、適切に構成されたメッセージによって曖昧性を排除し、自身で文書化可能である必要がある。 - **単純性**: 正しさやセキュリティのためであれば必要でない限り、単純で直線的なフローを優先する。 - **一貫性**: すべてのモジュールを通じて標準化された形式（例：JSON、XML）と慣習を使用する。 - **効率性**: ペイロードサイズを最適化し、不要なラウンドトリップを削減することでレイテンシを最小限に抑える。 ## リクエストのライフサイクル 1. **发起**：クライアントは、有効なヘッダー、認証トークン、およびスキーマ定義に従ったペイロードを持つリクエストを構築する。 2. **検証**：サーバーは処理前に入力データの整合性、権限状態、レート制限を検証する。 3. **処理**：業務ロジックが操作の種類（例：CRUD、クエリ、変換）に基づいて実行される。 4. **応答生成**：ステータスコード、データペイロード、必要に応じてエラーメッセージを含む構造化された応答が生成される。 5. **配信**：定義された SLA の範囲内でクライアントへ応答が送信され、関連するキャッシュヘッダーが適切に設定される。 ## エラー処理 すべてのエラーは統一的な形式に従う必要がある: - プログラムによる処理のために `error_code` を含む。 - 問題の内容を説明する人間の読解可能な `message` を提供する。 - 適切な HTTP ステータスコードを返す（例：400 のリクエストエラー、401 の未認証、500 の内部サーバーエラー）。 エラー応答の例: ```json { "error_code": "INVALID_INPUT", "message": "提供されたメールアドレス形式が無効です。", "timestamp": "2023-10-07T14:32:18Z" } ``` ## セキュリティ上の考慮事項 - すべての相互作用は暗号化されたチャネル（HTTPS）上で行われる必要がある。 - 保護されたエンドポイントでは、認証および権限チェックが必須である。 - 機密データは適切な場合に渡信中および保存時に暗号化される必要がある。 - 入力検証により注入攻撃（SQLi、XSS など）を防止する。 ## 付録：相互作用の種類 - **同期型**: リクエストと応答のペアであり、即座にブロックする動作を示す。 - **非同期型**: ロングランニングな操作にはファイア・アンド・フォーゲットまたはコールバックベースの方式を採用する。 - **ストリーミング型**: WebSockets または Server-Sent Events を介したリアルタイムデータ配信を行う。 本書の終わり

本日は、外部のスキャフォールディングではなく、対話そのものをネイティブに処理する「対話モデル（interaction models）」の研究プレビューを公表します。当社は、インタラクティビティは知能と並行してスケールしていくべきだと考えています。AI との働き方は後付けのものとして扱われるべきではないのです。

対話モデルには、人間同士が自然に行うような協業を通じて AI と連携する能力があります。これらは音声、映像、テキストを絶えず取り込み、リアルタイムで思考・応答・行動を行います。

当社は対話モデルを一からゼロでトレーニングしています。リアルタイムでの反応速度を確保するため、マルチストリームおよびマイクロターン（micro-turn）を採用した設計にしています。今回の研究プレビューでは、質的に新しい対話能力の実現に加え、知能性と反応性において業界最上位レベルの総合パフォーマンスを実証しています。

コラボレーションのボトルネック

AI ラボでは、多くの場合、AI が自律的に動作できる能力をモデルにおける最重要機能とみなします（Kwa et al., METR, 2025）。その結果、現在のアプローチやインターフェースは、人間がループ内で継続して関与するよう最適化されていません。最近のフロンティアモデルに関する説明書カードには、「重要なのは、インタラクティブで同期された『キーボードを操作する（hands-on-keyboard）』ようなパターンで使用した場合、このモデルからの恩恵が不明瞭であるという点です。このような使い方をすると、一部のユーザーはモデルが「遅すぎると感じており」、得られる価値を実感ができなかったと述べています。一方、自律的な長時間実行のエージェントは、コーディング能力を引き出すのに適しています」と記載されています。

自律的なインターフェースには確かに価値がありますが、多くの現実的な仕事では、ユーザーは要件を事前に完全に指定した上で去ることができず、良い結果を得るためには、人間がループ内に留まりながら clarification やフィードバックを行う協業プロセスが必要です。しかしながら、人間が作業から排除されるのは、仕事が不要だからではなく、インターフェースに人間を収める余地がないからです。人は、他の人と同じように AI とメッセージ交換したり会話したり、聴き分けたり見たり、必要な時に介入したりできる場合に最も効果的です。AI もまた同様である必要があります。

コミュニケーションの質は以下の要素で向上します： (a) 共在（Copresence）: 他者が何と対話しつつあるか、それらと直接やり取りできること。 (b) 同時性（Contemporality）: 他者が情報を生産するにつれ、瞬時のフィードバックを受け取れること。 (c) 同時発現（Simultaneity）: 情報を受信し、同時に生成すること。 （Clark & Brennan, "Grounding in Communication," 1991）。言語の参与性の質（客観的な距離感との対比で）は儚いものであり、今日のコンピューティングや知識作業の媒体も同様のインタラクティブな特性を有しています（Ong, Orality and Literacy, 1982）。

これを解決するためには、現在のターンベースのインターフェースを超えて進む必要があります。現在のモデルは現実をシングルスレッドで捉えています。ここで言うのは商用の汎用フロンティアモデルであり、Moshi や PersonaPlex、Nemotron VoiceChat、GPT-Realtime-Translate といった小規模・専門化されたモデルとは異なります。ユーザーが入力（タイプや発話）を終えるまで、モデルは何をしているのか、あるいはどのように行っているのか、その認識を持たずに待機します。また、モデルが生成を完了するまで、その認識機能は凍結し、中断されるか完了するまでは新しい情報を受取れません。これにより、人間と AI のコラボレーションには狭窄されたチャネルができ、人の知識、意図、判断がモデルに到達できる量が制限され、逆にモデルの成果を理解できる量も制限されます。つまり、重要な意見対立をメールで解決しようとするような状態を想像してください（その代わりになるはずのアナログな人間同士のやり取り）。

Thinking Machines では、この帯域幅のボトルネックを解消するため、あらゆるモーダルで AI をリアルタイムにインタラクティブにできることを可能にすると考えています。これにより、AI インターフェースは人間に合わせて機能するようになり、人間が AI インターフェースに適応することを強制する必要なくなります。

既存の多くの AI モデルでは、インタラクティビティを追加的に実装（ボルトオン）しています：中断、マルチモーダル性、並行処理などを模倣するためにコンポーネントを組み合わせています。ほとんどのリアルタイム商用音声システムは、ターン境界を検出するために音声活動検出（VAD）コンポーネントを使用しています。しかし、Sutton の『苦い教訓』（The Bitter Lesson, 2019）は、このような手作りされたシステムが汎用的な能力の進歩に追いついてしまうことを示唆しています。インタラクティビティを知能と共にスケールさせるためには、それがモデルそのものの一部である必要があります。このアプローチにより、モデルをスケールすると、より賢く、より優れた協力者になります。

機能性（Capabilities）

インタラクティビティがモデルの一部となることで、以前はボルトオンで実装する必要があった多種多様な機能が解放されます：

• シームレスな対話管理: モデルは、話者が思考しているか、譲歩しているか、自己修正をしているか、それとも応答を促しているかを暗黙的に追跡します。専用の対話管理コンポーネントはありません。
• 言語的および視覚的な介入: ユーザーが話し終わるだけでなく、文脈に応じて必要なタイミングでモデルが介入します。
• 同時発話: ユーザーとモデルは同時并发言が可能です（例：ライブ通訳）。
• 時間意識: モデルは経過時間を直接的に感知できます。
• 同時ツール呼び出し、検索、および生成 UI: 話し耳を澄ますユーザーに対し、モデルは同時に検索したりウェブ閲覧したり、または UI を生成することもでき（必要な結果を会話に縫い合わせて統合）、これにより対話の文脈に戻ります。

より長いセッションでは、これらの機能すべてが連続的に発生し、「プロンプトを送る」という感覚よりも「協業している」という体験を提供します。

当社のアプローチ

当社のアプローチは**時間同期型のマイクロターンベース（time-aligned micro-turn based）**です。対話は時間に基盤を置き、入出力ストリームを微細なターンに分割して-grounding（根拠付け）を行います。

• ターンベースのモデル: 交互するトークンのシーケンスのみを見ます。
• 時間意識型対話モデル: マイクロターンからなる連続ストリームを見ており、沈黙やオーバーラップ、中断もモデルのコンテキストの一部として保ちます。

対話モデルはユーザーとの間で絶えず双方向の交流にあります—同時に認識と応答を行っています。いくつかのドメインでは、このようなインタラクティビティは当然のものとして扱われます—物理世界はロボットや自動車をリアルタイムで動作させることを要求しています。また、Audio full-duplex モデル（Moshi, PersonaPlex, nemotron-voicechat, Seeduplex）も、対話が一方向ではなく双方向かつ連続的である別の例です。

同様の原則を応用し、我々はこのレジームにネイティブな対話モデルの構築に取り組みました—それが音声・映像・テキストを跨いで、認識と応答を同一のループで行うものです。その結果、2 つのアイデアを軸としたアーキテクチャが生まれました：リアルタイムプレゼンスを維持する「時間意識型の対話モデル」と、持続的な推論、ツールの使用、より長期的な作業を扱う非同期バックグラウンドモデルです。

システム概要

対話モデルはユーザーとの間で絶えず交流しています。タスクに対して瞬時では生成できないような深い推論が必要な場合、対話モデルは非同期で実行するバックグラウンドモデルに権限を委譲します。このアプローチは、Qwen-omni や KAME、MoshiRAG などの既存の研究成果を発展させるものです。対話モデルは常に現存し続けます—フォローアップ質問への回答、新しい入力の受領、スレッドの保持を行い、バックグラウンドから得られた結果を会話へと統合していきます。

この分割により、ユーザーは反応性と完全な知能性の双方の恩恵を受けます：推論モデルが持つプランニング、ツール使用、エージェントワークフローなどの利点を受けつつ、非思考型モデルと同等の応答遅延で提供します。バックグラウンドモデルと対話モデルの両方が知能を持っていることに注意してください—特に、対話モデル単独でもインタラクティブなベンチマークや知能性ベンチマークにおいて競合的なパフォーマンスを示しています。

対話モデル（The Interaction Model）

我々の出発点は連続的な音源と映像です—これらは本質的にリアルタイムであるモーダルです。テキストは待てますが、生きた会話は待てません。最も難しいケースを最初に設計することで、ネイティブにマルチモーダルで時間意識を持ち、すべてのモーダルにおいて入出力ストリームを並行処理できるアーキテクチャに到達しました。これを実現するためにはいくつかの設計上の選択を行いました：

1. 時間同期型マイクロターン（Time-Aligned Micro-Turns）: 対話モデルは、200ms 分の入力処理と 200ms 分の出力生成を絶えずインターリーブさせて動作します。完全なユーザーターンの消費と完全な応答の生成ではなく、入出力トークンはすべてストリームとして扱います。これらのストリームの 200ms チャンクを用いることで、複数の入出力モーダルにおけるほぼリアルタイムの並行性を可能にします。

   • 人間の知覚は入出力ストリームを併存して保持しますが、モデルは単一のインターリーブされたトークンシーケンスを受信します。
   • この設計により、モデルに従う必要のある人工的なターンの境界はありません。対照的に、既存の多くのリアルタイムシステムは、ターンベースのモデルがリアルタイムかつ反応的と感じるために、ターンの境界を予測するボルトオン（ハネス）を要求します。Moshi、PersonaPlex、および Nemotron Voicechat は、ターンの検出にハネスを使用せずフルダプлексシステムを実現した例です。これらは知能性のベンチマークよりも遅延に焦点を当てた小規模なモデルです。VAD（音声活動検出）などのコンポーネントで作られたこのハネスは、モデル自身と比べて有意に知能が低いものです。これにより、「私が間違ったことを言ったとき打断する」「コードにバグを見つけたとき教えて」のような先行的介入や、視覚的キューへの反応などが不可能になります。さらに、聴きながら話したり（「スペイン語から英語へリアルタイム通訳」）、見ながら話したり（「このスポーツ試合のリアルタイム解説」）することもできません。
   • したがって、今日では特別なハネスを必要とするこれらの多様な対話モードは、モデルが持つ機能の特殊なケースとなり、モデルサイズの拡大とトレーニングデータの増加に伴い品質が向上します。

2. エンコーダーなし早期融合（Encoder-free early fusion）: 大規模で独立したエンコーダーを通じて音声や映像を処理する代わりに、最小限の前処理を行うシステムを選択しました。多くのオムニモーダルモデルでは、別個のエンコーダー（例：Whisper 様式）やデコーダー（例：TTS モデル様式）を訓練する必要があります。我々は音声信号を dMel（Bai et al., 2024）として取り込み、軽量な埋め込み層を通じ変換します。画像は 40x40 のパッチに分割され、hMLP（Touvron et al., 2022）で符号化されます。音声デコーダーにはフローヘッド（Lipman et al., 2022）を使用します。すべてのコンポーネントは変換器と共に一からゼロで共同訓練されています。

   • シングル 200ms のマイクロターンの対話モデルアーキテクチャの図示では、モデルがテキスト、音声、または映像のいずれかのサブセットを取り込み、テキストと音声を予測する様子を示しています。

3. 推論時の最適化（Inference Optimization）: 推論時、200ms のチャンクは小規模な頻繁なプリフィルとデコードを必要とし、厳密な遅延制約を満たす必要があります。残念ながら、既存の LLM 推論ライブラリは頻繁な小さなプリフィルに対して最適化されておらず、ターンごとにオーバーヘッドが大きくなりがちです。これを解決するため、ストリーミングセッションを実装しました。クライアントは各 200ms のチャンクを別個のリクエストとして送り、インferences サーバーは GPU メモリ内の永続シーケンスにこれらのチャンクを追加します。これは頻繁なメモリアロケーションやメタデータ計算を回避し、この機能を SGLang にアップストリーミングしました。さらに、我々は双方向サービスの実際の形状と遅延性の両面でカーネルも最適化しました。例えば、PyTorch や Cursor などの先行研究で行われていた標準的なグループ化された gemm の代わりに、MoE カーネルには gather+gemv ストラテジーを使用します。

4. トレーナー・サンプラー整合性（Trainer-Sampler Alignment）: ビット単位のトレーナー・サンプラー整合性を訓練の安定性とシステム各コンポーネントのデバッグに役立つと感じています。バッチ不変カーネルを実装し、エンドツーエンドのパフォーマンスオーバーヘッドを最小限（<5%）に抑えています。

   • All-Reduce と Reduce-Scatter: 低遅延通信カーネルを実装するために NVLS を使用し、Blackwell では決定論的に動作させながら、ある程度の異なる並列化戦略（シーケンス並列とテンソル並列）の間でビット単位の整合性を達成します。
   • 注意力（Attention）: 注意力の主な課題は Split-KV で、デコードとプリフィルの間で一貫性のない累積順序を引き起こすことが一般的です。Colfax との協力による取り組みですが、デコードとプリフィル間で一貫して分割することで累積順序の一貫性を維持できます。例えば、一度に 4096 トークンを処理する SM を分割（左揃え）することで、プリフィルとデコード双方で良い効率化を実現します。

5. 対話モデルとバックグラウンドモデル間の調整: 対話モデルが権限を委譲する際、それは単なるクエリではなく、会話全体の豊富なコンテキストパッケージを送信します。結果はバックグラウンドモデルが生成するにつれストリーミングされ、ユーザーが行っていることに適したタイミングで、対話モデルはこれらアップデートを会話にインターリーブしていきます—突然のコンテキスト切替としてではありません。

6. 安全性（Safety）: リアルタイムなインタラクションは、ターンベースのやり取りとは異なる方法で安全性にストレスをかけるため、我々の安全対策は「モーダルに適した拒否」と「長期的な堅牢性」の 2 つの軸に焦点を当てました。拒否を口語的スピーチとして機能させるために、拒否および過剰拒否のトレーニングデータ（禁止トピックの範囲）を生成するテキストから音声へのモデルを使用し、拒否の境界は自然に言い換えられたものだが、決して弱さのない拒否を優先するように校准しました。長期的な音声対音声会話を横断して堅牢性を向上させるために、自動化されたレッドチームハネスを使用して多ターンの拒否データを生成し、モデルのテキストベースの拒否との行動的等価性を維持しながら行いました。

ベンチマーク

知能とインタラクティビティのフロンティア

我々は、TML-Interaction-Smallという名の対話モデルが、強力な知能/指示従順性とインタラクティビティの両方を有する最初のモデルであることを示します。対話品質を測定するために、インタラクティビティを測定することを意図した既存の数少ないベンチマークである FD-bench を使用します。FD-bench v1.5 では、モデルには録音済みの音声を与えられ、特定の時刻に応答する必要があります。このベンチマークは、ユーザーの中断、ユーザーのバックチャネル（反応）、他の誰かとの会話、および背景の発話など、いくつかのシナリオにおけるモデルの振る舞いを測定します。我々のモデルはこれらのすべての分野で良いスコアを獲得しました。知能性を定量化するためには、一般的なベンチマークである Audio MultiChallenge を使用し、知能性と指示従順性を追跡します。

モデル	パフォーマンス指標*
TML-interaction-small	対話品質を支配的にしつつ、どの思考モデルよりも知能性が高い。
GPT-realtime-2.0 (minimal)	知能性とインタラクティビティが低い
GPT-realtime-2.0 (xhigh)	知能性とインタパクティビティが低い
GPT-realtime-1.5	知能性とインタラクティビティが低い
Gemini-3.1-flash-live-preview (minimal)	知能性とインタラクティビティが低い
Gemini-3.1-flash-live-preview (high)	知能性とインタラクティビティが低い

注：当モデルは、ユーザーとモデルターンの間の遅延として測定される反応性において最高成績を収めています。

さらに詳細な知能性、安全性、およびインタラクティビティ/レイテンシの結果については、以下の表をご参照ください。我々はストリーミングベンチマークとターンベースベンチマークの両方でパフォーマンスを報告しています。 (具体的な数値は、IQA、AMC、VideoQA、BigBench Audio などの詳細はオリジナルの研究論文をご覧ください)

インタラクティビティの新次元

上記のインタラクティビティ志向の既存のベンチマークは、我々が認める対話能力における質的な飛躍を十分に捉えていません。そのため、これらの能力を定量化する早期の研究成果を持っています。

時間意識と同時発話: ディアログ管理システムを備えたターンベースモデルは、正確な時間推定や同時発話をサポートしません。例：「1 マイル走るのにどれくらいかかりましたか？」「聞こえたまま発音の誤りを直してください」または「この関数を書くのにどれくらいかかりましたか？」

我々は、これらの先行的な音声機能を測定するための 2 つの内部ベンチマークを作成しました：

• TimeSpeak: モデルがユーザー指定された時刻に正しいコンテンツを生成しながら発話を開始できるかをテストします。例：「私は呼吸法を練習したい。4 秒ごとに吸って息を吐くことを、私が止めると言えば止めるまで提醒してください。」
• CueSpeak: モデルが適切な時点で期待される意味的に正しい応答で発話するかどうかをテストします。データセットのエントリーは、モデルが完全なスコアを得るためにはユーザーと同時に話す必要があることを保証するために作成されます。例：「毎回コードスイッチして別の言語を使うたびに、元の言語で正しい単語を教えてください。」

両方のベンチマークにおいて、各例には単一の期待された意味的な応答とタイミングウィンドウがあります。LLM ジュッジによる採点を行い、期待された意味を伝えかつ適切な時期に届けられた場合にのみ正しいとカウントし、どちらかの基準を満たさなければ評価されない仕組みです。例全体にわたるマクロ平均精度を報告します。

視覚的な先導性（Visual proactivity）: 現在の商用リアルタイム API は、音声単一の対話管理ハネスによるターン検出を実行します。それらはspoken turn に反応しますが、視覚的世界が変化した際に能動的に発話を選択することはできません。我々には、視覚的プロアクティビティの出力をサポートする商用 API については存じておりませんが、いくつかの学術論文では関連する研究プロトタイプを構築しました。StreamBridge、Streamo、および MMDuet2 は、ストリーミングビデオ入力設定でテキストを出力するタイミングを研究しています。テキストアウトであるため、それらは音声出力インタラクションの追加制約（発話には持続時間があり、ユーザーとオーバーラップでき、ターンテイキング、中断、バックチャネリングと調整する必要があり）については研究していません。最も近いのは AURA で、VideoLLM 周りに ASR/TTS デモを追加し、テキストを出力するか沈黙するかのタイミングを決定しますが、対照的に当社のモデルは音声ネイティブでフルダプлексです。例えば、「私が何回バウチャー（pushups）をしているか数えてください」と頼まれた場合、そのようなシステムは「承知しました！」と反応してその後沈黙し、決して来る事のない音声単一のキューを待ち続ける可能性があります。

我々はモデルの視覚プロアクティビティを評価するために 3 つのベンチマークを適応させました：

• RepCount-A: 反復動作のビデオを含み、オンラインカウントタスクに適応されました。我々は音声指示「{action} の反復数を数えてください。」に従って動画をストリーミングします。基準となる真値の前々回の反復後にモデルが言った最後の数字を抽出し、それが基準と1回以内にあるかどうかで採点します。このタスクは継続的な視覚追跡と適時なカウントを測定します。
• ProactiveVideoQA: 特定の時刻で回答が利用可能になる質問を含むビデオから成ります。我々は質問を音声としてストリーミングし、その後動画をストリーミングします。具体的には以下の TTS を実行します：「動画を視聴して、新しいモーメンツが質問に答えるまで沈黙してください。それが起こった時に簡潔な答えを言ってください。{question}」その後、モデルが指示を確認できるように2 秒間の沈黙をストリーミングします。ビデオに含まれるあれば字幕を焼き付け（burn）、入力動画をミュートして視覚プロアクティビティのテストを強調します。我々は論文のターン重み付き PAUC@ω=0.5 メトリック（0-100 でスケーリング）をターンとカテゴリーにわたって平均して報告します。沈黙を維持するとスコアは 25.0 となります。より高いスコアは正しい時刻に正しい答えを提供することを要求し、誤った答えにはペナルティが科せられます。
• Charades: 標準的な時間的行動局在化ベンチマークです。各ビデオにはラベルされた時間区間を超えて発生する動作が含まれます。我々はユーザー音声指示「人が {action} を始めるときは'start'と言って、やめるときは'stop'と言ってください。」をストリーミングし、その後動画をストリーミングします。モデルは予測区間と参照区間の時間的 IoU で評価されます。

ベンチマーク結果（当モデル vs ベースライン）:

機能	メトリック	TML-Interaction-Small	ベストベースライン*
時間意識	TimeSpeak (macro-acc)	64.7%	4.3%
言語的キュートリガー	CueSpeak (macro-acc)	81.7%	2.9%
視覚ベースカウント	RepCount-A (off-by-one)	35.4 reps	1.3 reps
視覚的キュートリガー	ProactiveVideoQA (PAUC@ω=0.5)	33.5	25.0*
視覚的キュートリガー	Charades (mIoU)	32.4	0

*ProactiveVideoQA のベースラインの無回答は 25.0 です。

既存のどのモデルも、これらのタスクのうちどれかを有意義に実行することはできません。完全性の観点から、GPT Realtime-2 (minimal) の結果を報告していますが、評価されたすべてのモデル（思考性を持つ高いモデルを含む）は、これらのタスクで同様の性能またはより低い性能を示します。それらは沈黙したり、誤った答えを与えたりします。

我々の内部音声およびビデオベンチマークからの例: [オリジナルドキュメントの視覚的例をご覧ください]。

将来の評価。我々はインタラクティビティが将来の研究にとって重要な分野であると考えており、コミュニティに新しい対話品質評価のためのフレームワークなどを含め、対話モデルと人間-AI 協業の分野へのさらなる研究を促すためにベンチマークへの貢献を歓迎します。詳細は近日公開予定です。

限界と将来の作業

• 長セッション: 連続的な音声と映像はコンテキストを急速に蓄積します。ストリーミングセッション設計は短く中程度のインタラクションで良好に機能しますが、非常に長いセッションは依然として慎重なコンテキスト管理を必要とします—現在活発に取り組んでいる分野です。
• 計算資源と展開: 低遅延での音声・映像ストリーミングには信頼性の高い接続が必要です。良い接続がない場合、体験は大幅に劣化します。システム信頼性の向上やモデルを遅延フレームに対してより堅牢にするトレーニングなど、将来はこの点が大幅に改善できる我们相信ています。
• 整合性と安全性: リアルタイムインターフェースは、両方の分野における新しい研究分野を開拓し、合意形成と安全性の研究領域を広げます。我々はフィードバックを収集し、研究助成金を見直しています。
• モデルサイズのスケール: 現在の TML-Interaction-Small は 12B がアクティブな 276B パラメータを持つ MoE です。インタラクティビティがモデル規模の拡大とともに改善すると予想されますが、現在我々のより大きな事前学習済みモデルはこの設定でサービスを提供するには遅すぎます。我々は今年後半に大きなモデルをリリース予定です。
• 改善されたバックグラウンドエージェント: この投稿では主にリアルタイムインタラクションに焦点を当てていますが、エージェント知能も不可欠な機能です。エージェント知能をフロンティアに押しやるだけでなく、バックグラウンドエージェントが対話モデルとどのように協力できるかについては、表面に触れたに過ぎないと考えます。

感想をお聞かせください、私たちにご参加ください

今後数ヶ月以内に、フィードバック収集のための限定された研究プレビューを開き、今年後半により広範なリリースを行う予定です。皆様のご参加を心から歓迎いたします。ご意見は [email@example.com] でお知らせください。

引用

この作品を次のように引用してください： Thinking Machines Lab, "Interaction Models: A Scalable Approach to Human-AI Collaboration", Thinking Machines Lab: Connectionism, May 2026.

または BibTeX 引用を使用してください：

@article{thinkingmachines2026interactionmodels,
  author = {Thinking Machines Lab},
  title = {Interaction Models: A Scalable Approach to Human-AI Collaboration},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2026},
  month = {May},
  note = {https://thinkingmachines.ai/blog/interaction-models/},
  doi = {10.64434/tml.20260511},
}