以前のツイートで、Jevは私が最初に思っていたよりも重要だと書きました。 その理由の一部は、そのインターフェースが意思決定を生成から分離することを促す点にあります。 このアプローチを評価した結果、新しいモデルを導入しなくても、分離そのものが一部のケースで役立つことが分かりました。 たとえばNowledge Memのメモリレビューステップでは、タスクをこのように再構成するだけで、より良い結果が見られました。
私はまた、Jevのようなモデルを一種のインテリジェントなコプロセッサとしても期待しています。 つまり、汎化とインコンテキスト学習が可能な「システム1」モデルです。 多くのタスクは、生成テキストを必要とせずに知能を必要とします。 モデルは会話全体を理解し、ほんの一握りの意思決定だけを行う必要があるかもしれません。 異なるサブシステムがそれらの意思決定を処理できれば、学習された能力が反射神経や小脳、自律神経系の役割になるのと同じように、「脳」から作業をオフロードする方法が得られます。
さらに、低レイテンシでプロンプトベースの分類器としてのJevのより直接的な価値もあります。 現在ヒューリスティクスで処理されている判断を改善したり、レイテンシとコストのために実用的でなかったシステムの部分に意味理解をもたらしたりできる可能性があります。
これらのアイデアは1週間強の実験を通じて検討されました。 私たちは現在、Jevサポートを含むバージョンのNowledge Memをリリースしたので、実際に導入したものとともに、観察したことを議論できます。
記憶システム内の意味的意思決定
Nowledge Memは私たちが構築しているコンテキストレイヤー基盤であり、ソフトウェアとサービスの両方を含みます。Memは、人々やチームがAIとの仕事から得たコンテキストを保存、整理し、さまざまなエージェントが蓄積した知識を利用できるようにするのを支援します。 会話からメモリを抽出し、保存された知識を整理し、検索時に適切なコンテキストを選択することは、いずれも意味の理解に依存する意思決定を伴います。
「このコマンドは成功した」と「毎回のデプロイ前にこのチェックを実行する」はどちらも新しい情報です。 一方は操作の結果を記録し、もう一方は将来も適用されるべき作業合意かもしれません。 長さ、キーワード、タイムスタンプは、その区別や情報が将来も有用であり続けるかについてほとんど何も教えてくれません。
メモリを保存する前に、そのソースがそれを裏付けているか、実際に言われたことを超えていないか、すでに保存していないか、以前の決定を更新するものかを確認する必要もあります。 これらの判断は、エージェントが後で遭遇するコンテキストを形作ります。 誤ったメモリは繰り返し検索され引用され、さらなる結論の基礎にさえなる可能性があります。 これらのチェックは多くの場所で必要ですが、それぞれにLLMを呼び出すと、システム全体にコストと待ち時間が加わります。
JevはTypeSafeチームによる意思決定モデルです。
リクエストはstateとして何らかの素材と一連のquestionsを提供し、モデルは指定された範囲内で答えを確率とともに返します。
質問は、何かが真実かどうかを尋ねたり、固定された選択肢の中から選ぶようモデルに求めたり、定義された基準に対するスコアを要求したりできます。
このインターフェースにより、記憶システム内の意思決定を独立して定義し、同じ素材について複数の質問を1回の呼び出しで行い、異なるモデルに答えさせることができます。 基準を個別に整理してテストできます。 生成テキストを必要とする作業（メモリの内容、要約、エンティティ名）はLLMに任せます。
同じモデルで意思決定を生成から分離する
Jevに触発され、私たちは候補メモリのレビューに関する一連の実験から始めました。 LLMが会話から情報を抽出した後、それが長期保存に値するか、ソースがそれを裏付けているか、モデルが何かを過剰解釈していないかを確認します。 既存の実装ではすでにこれらのチェックが必要でしたが、モデルは1回の呼び出しで複数の仕事をしていました。 候補を保持するかどうかを決め、必要ならタイトルと内容を修正し、結果のメモリをJSONとして返すというものです。 Jevに備えて、私たちは判断を個別の質問に変え、それぞれに明示的な基準と許容される答えを設け、モデルにはそれらの質問にだけ答えるよう求めました。
このインターフェースをDecisionClientに入れたので、Jevとチャットモデルが同じ質問セットに答えられるようになりました。
これにより、最初はモデルを変えずに、タスクの構成方法を比較し、利得がどこから来るのかを理解することもできました。
同じKimi k3モデルに40件の候補メモリを2つの方法でレビューさせました。 元のレビュープロセスと、質問リストへの答えだけを返すバージョンです。 どちらも候補ごとに1回の呼び出しを行いました。
モデルは長期的価値の判断と過剰解釈の特定が改善しました。 メモリタイプ精度は同じままでした。 以前の比較ではタイプ分類にも大きな改善が見られましたが、この実行では再現しなかったため、信頼できる利得とは見なせません。 タイプ精度は、長期保持に値するとラベル付けされた19件の候補でのみ測定されました。
これらの完璧なスコアは、これら40例にのみ当てはまります。 また、レビューを個別の質問に変える際にいくつかの基準を明確にしたので、この比較だけでは改善がタスク形式から来たのか、より明確な指示から来たのかは分かりません。 それを調べるために、同じアブレーション実行で5つのバリアントを比較しました。 各答えに理由を求めるものも含まれます。
| バリアント | 過剰解釈F1 | 長期保持F1 | 相対コスト |
|---|---|---|---|
| 元のレビュー | 0.27 | 0.83 | 1.10 |
| 元の形式、よく混同されるケースを明示 | 0.42 | 0.86 | 1.19 |
| 質問リスト、各答えに1文の理由 | 1.00 | 1.00 | 1.41 |
| 質問リスト、答えのみ | 1.00 | 1.00 | 1.00 |
| 質問リスト、質問ごとに1回の呼び出し | 0.82 | 1.00 | 2.83 |
最後の列は、1件の候補の完全なレビューのコストを、当時のKimiのAPI価格を用いて計算して比較したものです。 答えのみの質問リストが基準で、コストは1です。
元のプロンプトで紛らわしいケースを明示するだけでもすでに役立ちました。 しかし、各判断、その基準、答えの選択肢を個別に指定したバージョンには及びませんでした。 その質問リストができると、各答えの説明をモデルに求めることは、レビュースコアを改善せずにコストを増やしました。
同じ比較を書き込み品質チェックと単独メモリタイプ分類についても行いました。 結果は同様でした。 理由を求めることは品質チェックのスコアやタイプ分類を改善しませんでした。 3つのタスク全体で、総コストが約35%増加し、呼び出しあたりの中央値レイテンシはほぼ2倍になりました。
システムのこれらの部分では、プログラムはモデルの意思決定を使用します。 理由を書くことはコストとレイテンシを増やし、これらの比較では対応する品質向上は見られませんでした。 これは、モデルに実際に生成させる必要があるテキストを再考する理由になります。 実験は理由を書くことが役立つかどうかについてでした。 理由を出力しないモデルでも、内部的には推論している可能性があります。
各意思決定が質問として定義されると、呼び出しのグループ化の仕方も重要になります。 1件の候補をレビューするには、同じ素材について6つの質問が必要です。 それらを6回の連続呼び出しで尋ねると、完全なレビューのp50で約50秒かかりました。 6つすべてを一緒に答えると11.6秒でした。 質問あたりに償却すると、8.4秒から1.9秒への削減で、コストは約65%低くなります。
これらの実験のいずれでもチャットモデルは変えていません。 比較していたのはタスクの定式化、説明を生成するかどうか、呼び出しをどうグループ化するかです。 Jevのための抽象化を構築することで、それらの選択を独立して評価し、そこからいくつかの利得を見つける方法が得られました。 それがツイートで共有したかった最初の観察です。
どの生成作業を避けられるか？
意思決定自体の評価と並行して、私たちはバックグラウンドプロセス全体のモデル呼び出しを棚卸ししました。 ヘビーユーザーの月間コストを1日あたり20の会話スレッドと60のメモリと見積もり、意思決定モデルが全体の支出のどれだけに影響できるかを理解しようとしました。
そのシナリオでは、意思決定タスクは呼び出しの半分以上を占めましたが、コストは約4分の1にすぎませんでした。 支出のほとんどは生成に使われました。 会話からのメモリ抽出、グラフ情報の抽出、データのバックフィルです。 その作業の一部は、それが本当に必要かどうかを確立する前に始まっていました。
したがって、意思決定を行うモデルを置き換えても直接的な節約は限定的です。 しかし、Jevのように比較的低いコストとレイテンシでコンテキストを理解できるモデルは、高価な生成を始める前にそれが本当に必要かを確認することをより実用的にします。 たとえば会話が変わったとき、まず新しい内容に、まだ保存していない保存価値のある知識が含まれているかを尋ねることができます。 その後、LLMにそれを抽出させるかどうかを決めます。
同じワークロードの仮定を用いて、元のプロセスをコスト100とします。 既存のモデルを維持し、意思決定を生成の前に移し、一緒にできる作業をバッチ化すると、推定コストは約37に下がります。 それらの意思決定をJevに割り当てると、当時のJevチームの価格を用いて約26になります。
これらの仮定の下では、節約の約85%はワークフローの変更から来ており、Jevとは無関係のバッチ化も含まれます。 残りの15%はモデル価格の差から来ます。 この見積もりは使用状況に大きく依存します。 実際にどれだけのコンテンツをスキップできるか、どれだけの作業をまとめられるかは、実際のトラフィックで測定する必要があります。
実際のサービスに対する小規模な統合テストでは、会話スレッドあたりのコストが約10%〜19%低下するのを観察しましたが、モデル化した削減量をはるかに下回りました。 それらのテストでは、元のモデルが依然として候補レビューを処理し、その段階では意思決定モデルの答えを記録しただけでした。 他のいくつかの段階では、その答えを使って後続の作業を決定しました。 本番ユーザーの月間請求全体のA/B比較を行う十分な時間はまだありません。
意思決定の後に何が起こるかがここでは重要です。 ほとんどのコンテンツが依然として抽出を必要とする場合、またはチャットモデルが意思決定を再確認しなければならない場合、新しい呼び出しは単にオーバーヘッドを追加するだけかもしれません。 スキップしたコンテンツを再訪し、保存すべき知識が含まれていなかったかを確認する必要もあります。
意思決定がメモリの保存をどう変えるか
抽出前にコンテンツをスクリーニングするには2つの判断が必要です。 新しい情報が長期保存に値すること、そしてまだ保存されていないことです。 新しいコンテンツが一時的な操作結果や一時的なステータスを報告するだけの場合、またはすでに保存した知識を繰り返す場合は、LLM抽出を通す必要はありません。
既存の知識を確認するために使う素材は重要です。 要約に決定が現れることは、それがメモリストアに書き込まれたことを意味しません。 以前の書き込みが失敗し、その要約と再び比較すると、モデルは内容を正しく理解しても、決して保存していない知識をスキップするかもしれません。 比較には正常に書き込まれたメモリを使う必要があります。
また、「意思決定できなかった」と「新しい知識がない」を区別する必要があります。 意思決定呼び出しがタイムアウトまたは失敗した場合、元の抽出プロセスを続行します。 答えがないことはコンテンツをスキップする理由にはできません。
抽出後の候補レビューでは、誤って受け入れられた候補は重複排除や書き込み品質チェックでまだ捕捉できます。 誤って拒否された候補は保存プロセスに到達しません。 それらの結果に応じて、モデルの答えを受け入れる条件を変える必要があります。 すべての判断に1つの信頼度しきい値では不十分です。
私たちは保守的なアプローチを試しました。 候補が通過すべきだと十分に確信している場合にのみモデルの答えを使い、拒否や不確実な答えは元のレビューに戻すというものです。 3回の小規模な比較実行では、誤った受け入れは見られませんでしたが、最終的に保存された正しい知識の量は元のプロセスより多いことも少ないこともありました。 コストも下がりませんでした。 したがって候補レビューは依然としてシャドウモードで実行されています。 意思決定モデルの答えを記録しつつ、実際のレビュー判断は元のプロセスが行います。
意思決定を使って生成をスキップする場合、最終チェックは保存されるべきだった知識がまだそこにあるかどうかです。 モデルが見たもの、プログラムがどの答えに基づいて行動したか、最終的に何が書き込まれたかを結びつける必要があります。 そうして初めて、呼び出しを1回減らしたことが不要な作業を削除したのか、メモリを失ったのかが分かります。
メモリ検索
メモリ検索は、Jevが役立つかもしれないと最初に考えた場所の1つでした。 私たちはMemの検索パイプラインについて書いたことがあります。 この設計は、クエリを理解することで恩恵を受けるいくつかの問いを提起します。 異なる検索パスの重み付け、HyDEが有用かどうか、クエリに時間制約が含まれているかどうかです。 レイテンシのため、デフォルトの高速検索パスでそれらすべての意思決定をチャットモデルに任せるのは困難です。
私たちは入力キャッシュがその待ち時間を減らせるかどうかもテストしました。 同一のプレフィックスを持つ6つの連続した意思決定リクエストを同じ推論チャットモデルに送りました。 最後の5回の呼び出しでは入力の約88%がキャッシュされましたが、各モデル呼び出しは依然として6〜33秒かかりました。 これらは実験における孤立したモデル呼び出しであり、Memの検索レイテンシではありません。 デフォルトの高速検索にはこのステップは含まれません。
私たちのJev統合は、クエリ内の時間情報の理解から始まりました。 記憶における時間に関する記事で論じたように、何かが起こった時とそれが記録された時は別のものです。 「昨年」や「最後の移行後」といったフレーズも文脈の中で解釈する必要があります。
既存のチャットモデルは依然として一般的な意図分析を処理し、意思決定モデルが時間的解釈を追加します。 Memory Deep Searchでは、意思決定サービスが設定されている場合、時間的意図を識別し、時間予算内で使用可能な結果を返すときに、再ランキングにもそれを使おうとします。 そうでなければ、既存の再ランカーを使います。
高速検索では、検索と時間的意図分析を同時に開始し、ランキング前に分析に限られた待ち時間を許し、分析がその予算を超えた場合は元の検索結果で進めることを試しました。 私たちのテストでは、検索はより早く終了し、意思決定モデルの答えは結果のランキングに間に合いませんでした。 したがって意思決定モデルは高速検索ではデフォルトでオフです。 今のところ、この統合はディープ検索にあります。
時間的解釈があっても、モデルが推論した範囲はランキングに影響するだけで、提案されたフィルターとして返されます。 ユーザーが明示的に提供したフィルターだけが適用されます。 誤って推論された時間範囲は、そうでなければ結果から証拠を除去し、下流のエージェントが何が悪かったのかに気づく機会を残さないかもしれません。
ローカルモデルはこれらの意思決定を行えるか？
Layaのような仕事は私にとって特に刺激的です。 ユーザーのコンピュータでバックグラウンドで動作するモデルが、抽出前にコンテンツをスクリーニングしたり、検索意図を解釈したりできれば、それらのタスクは毎回リモート呼び出しを待たずにローカルで実行できます。 私たちは、いくつかのコミュニティのオープンウェイトモデルを評価し、その能力、レイテンシ、リソース使用がMemのこれらの仕事に適合するかどうかを確認しました。
まず3つのエンコーダモデル（Laya、Von、Verdict）を、固定された質問セットと同じ中国語と英語の例でテストしました。 各モデルはGPUなしの8コアCPUマシンで290回の呼び出しを完了しました。
私たちは事前に要件を設定しました。 各タスクで、中国語と英語の両方のスコアが、適切に測定された精度またはF1で、チャットベースラインより0.05を超えて下回ってはならないというものです。 3つのモデルはいずれも、7つのタスクのいずれでもこの要件を満たしませんでした。 p50呼び出しレイテンシは0.2〜3.3秒、ピークプロセスメモリは1.7〜4.1 GBでした。 また、ユーザーのコンピュータで動き続けるモデルに求める水準からもいくらか離れていました。
私たちの友人PsiACEは、Bubの作者の一人で、別の興味深いアプローチであるDohnutsに取り組んでいます。 これはQwen3.5-0.8BをLoRAと専用のスコアリングヘッドで使い、意思決定タスクを学習し、トレーニング中はベースモデルの重みを変更しません。
同じ質問で、Dohnutsは7つのタスクのうち5つで3つのエンコーダの最良を上回りました。 書き込み品質判断では、最良のエンコーダが0.17 F1、Dohnutsは0.74に達しました。 メモリタイプ分類では、最良のエンコーダが0.48の精度、Dohnutsは0.70に達しました。
どちらのタスクもMemに固有の概念を含み、Dohnutsはそれらで大幅に優れていました。 完全な文章を読み、他のコンテンツと比較する必要があるタスクでは同様の利得は見られず、統合のための全体的な要件も依然として満たしていませんでした。 改善のどれだけがQwenベースモデル、トレーニングデータ、トレーニング方法から来るかを知るには、別の実験が必要です。
次に、タグを再利用できるか、ウェブ結果が関連しているか、ページに実質的な内容が欠けているかなど、明らかにより単純な6つのタスクに範囲を絞りました。 各タスクには合計40例があり、中国語、英語、日本語をカバーしました。 ここでも、どのローカルモデルも、どのタスクでも中国語と英語の両方で先の要件を満たしませんでした。 最も近かったのはウェブ関連性のDohnutsで、中国語F1は0.94、チャットベースラインは1.00でした。
これらのタスクのいくつかははい、いいえの答えで終わりますが、その答えに到達するには依然としてコンテンツとその文脈を理解する必要があります。 それが、より大きなベースモデルと異なるトレーニングデータがこれらのモデルをより広範な意思決定に有用にできるかどうかを見たい理由の一部です。
2026年10月1日更新：Discordでの議論の後、CLMを試す
この記事が公開された後、私たちの友人abnがDiscordで議論を続け、ポストトレーニングのローカルモデルという問いを取り上げました。 彼はNPU上でCLM-8Bを実行してローカルなSystem 1 APIを公開したいと考え、評価できるかと尋ねたので、私たちは別の実験を行いました。
私たちは上記13タスクにわたる同じ530例を使って、CPU上でCLM-v0.1-8Bをテストしました。 Qwen3-8B Q8量子化重みとCLMの元のスコアリングヘッドを使用しました。 ヘッドなしの比較も行いました。 この構成はMemで使える状態ではありませんでした。 長期メモリ価値テストでは40件の候補すべてを拒否しましたが、保存価値のある新しい知識があるかと尋ねると40例すべてを受け入れました。 後者は、ポジティブ例とネガティブ例を区別していなかったにもかかわらず、依然として0.67 F1を記録しました。 スコアリングヘッドは一部のタスクで役立ち、他のタスクでは悪化させました。
これは、どの意思決定がスコアを生み出したか、そしてシステムがそれに基づいて行動したら何が起こるかを見ることの有用なリマインダーです。 これらの答えは、レビュー中に有用な候補を破棄しつつ、不要な抽出作業を1つもスキップしないでしょう。 これはQ8量子化モデルの1回のCPU評価でした。 元の精度での公式セットアップと比較したり、abnのNPUのアイデアをテストしたりはまだしていません。 議論を続け、別の有用な比較を促してくれたabnに感謝します。
モデルを使ってヒューリスティクスを改善する
私たちはまた、一般的なルール（単語リスト、最小テキスト長、書記体系検出）を同じ6つのテストに通しました。 ルールは6つのタスクすべてでチャットモデルに劣り、4つで最小のローカルモデルにも劣りました。 たとえば、ページに実質的な内容があるかを長さで判断すると、短いが有用なページも除外されます。
権限、予算、日付演算、境界チェックはもちろんコードに残すべきです。 しかし、ページに有用なものが含まれているかを決めるにはそれを理解する必要があり、ページ長は単なる代理指標です。 ルールとモデルを同じ例でテストすると、それぞれがどこで間違えるかを比較できます。
したがってベースラインは、モデルが何を置き換えるかによって決まります。 既存のチャット呼び出しを置き換えることは、その品質要件を満たすことを意味します。 ヒューリスティクスを改善することは、許容できるコストでルールの誤りを減らすことを意味します。 私たちがテストしたローカルモデルは統合要件を満たしていませんが、ルールとの比較は探求を続ける理由を与えてくれます。
現在実行されているもの
設定の「Fast decisions」で意思決定サービスを構成できるようになりました。 独自のAPIキーを持ち込む場合は、TypeSafe AIを追加できます。 マネージドAIアカウントの場合、サービスが構成を提供します。 有効にすると、意思決定モデルは以下の段階で使用され、デスクトップとCloudでいくつかの違いがあります。
| 段階 | 現在の使用 |
|---|---|
| 会話からメモリを抽出する価値があるかを決める | 意思決定モデルはデスクトップとCloudで使用中 |
| 新しい会話内容に、長期保持に値する未保存の知識が含まれているかを確認する | デスクトップは意思決定を使って抽出を進めるかどうかを決める |
| 重複排除、書き込み品質チェック、タイプ分類 | デスクトップはこれらの判断に意思決定モデルを使用 |
| 候補メモリの長期的価値とソースサポートをレビューする | デスクトップは意思決定モデルの結果を記録し、元のレビュープロセスが依然として判断する |
| 時間的解釈と再ランキング | デスクトップのディープ検索は時間的解釈を使い、時間的意図が識別され結果が使用可能な場合に意思決定モデルの再ランキングを試みる。高速検索ではデフォルトでオフ |
| グラフ抽出前のスクリーニング | Cloudはスクリーニングに意思決定モデルを使用し、LLMは依然としてエンティティと関係を抽出する |
既存のモデル呼び出しを置き換えるだけでなく、ホストツールによって注入されたコンテンツの認識、タグを再利用できるか、ページに実質的な内容が欠けているかの判断、説明の言語の識別にも意思決定モデルをテストしています。 これらの判断は現在記録されるだけで、後続の処理には影響しません。 既存のアプローチと比較し続けます。 意思決定サービスが構成されていない場合、これらの追加呼び出しは行われません。
最終的に保存するメモリがより正確か、ユーザーの月間請求全体が低いか、検索が速いかは、完全なワークフローをカバーする本番A/Bテストが依然として必要です。 その結果はまだありません。
同様の仕事をしているなら、元の実装をベースラインとして保持することを強くお勧めします。 まず同じモデルで分離した意思決定をテストし、次に質問を固定したままモデルを変え、最後に統合後に完全なワークフロー全体で何が起こるかを評価します。 そうすれば、タスクの再構成による利得とモデルによる利得を区別し、どちらかが最終結果を改善するかを確認できます。 ヒューリスティクスを改善しようとしているなら、その比較に現在のルールも含めてください。
次に進みたい方向
私たちは最近、UT DallasのJev-Mem論文に出会いました。 彼らもメモリ構築と検索に意思決定モデルを使い、複雑な推論と答えの生成はLLMに任せており、私たちが取り組んできたことに近いものです。 彼らはLoCoMoで最終的な質問応答結果を評価しています。 私たちのここでの仕事は、各意思決定をどう定式化するか、システムが答えに直接基づいて行動できるかにより焦点を当ててきました。 2つのアプローチはよく補完し合うと思います。
この仕事は「ニューラルサブシステム」への私の関心をより具体的にしました。 意思決定を生成から分離すると、各意思決定が本当に必要とするモデル能力のレベル、ローカルで実行できるか、クラウドがより適しているのはいつか、システムの残りがその答えをどれだけ早く必要とするかを問うことができます。 これらのSystem 1モデルが、十分に低いコストで入ってくるコンテキストを継続的に解釈、評価できるなら、頻繁に行うのが難しかった作業ができるようになります。
私たちはローカルのJevのようなモデルのテストを続け、リアルタイムチャネル、Feedカード、クロスランゲージタグに意思決定モデルを試します。 また、特定の人物にとって何が保存に値するかを学習するなど、より個人的な能力にも興味があります。 専用のトレーニングがそれをどこまで進められるかを知りたいです。 これまでのところ、私たちの仕事は質問設計としきい値調整にあり、そのようなモデルをトレーニングしてはいません。
また、すべてのコプロセッサモデルが可能な限り小さく速いべきだとは思いません。 ツイートで述べたように、より大規模な事前学習とより強い汎化を持つJevのようなモデルは、より高いレイテンシでも、単純な反射を超えて多くの用途があるかもしれません。 Memの中でコンテキスト全体を理解する必要がある意思決定は、その方向に特に興味を抱かせます。 オープンウェイトLLMの意思決定指向のポストトレーニングがそれらの能力を生み出せるか、あるいは他のトレーニング方法が必要かを探求したいとも思います。
ロボティクスと身体性知能も私が興味を持つ別の方向です。 複数の異なるJevのようなモデルとフロンティアLLMを組み合わせた専用ハーネス、少なくとも視覚入力を理解するモデルを1つ含むものが、これらのモデルをロボットのフィードバックと意思決定ループに参加させられるかもしれません。 ロボティクスのサブシステム間のインターフェースはよく知りません。 しかし、そのような組み合わせが、以前は高価なトレーニングを必要とした能力の開発を容易にするかもしれないと推測しています。
これは別の研究上の問いを提起します。 LLMとそのハーネスは、複数の補助モデルを低レイテンシでどう調整できるか？それらのモデルをシステムとして一緒に設計した場合と、ハーネスを通じてプログラム的に接続した場合とで、能力とレイテンシにどのような違いが見られるか？不完全な類推は、エンドツーエンドの音声モデルと、別々のコンポーネントから組み立てられた音声エージェントフレームワークです。
神経系の類推に戻ると、AIは汎用のニューラルサブシステムを探求する前に「脳レベル」のモデルに到達したようです。 その順序が興味深いです。 記憶、エージェント、モデルに取り組む他の人たちとこれらのアイデアを議論し、それらを探求するより多くの仕事を見たいと思います。
実験ノート
チャットのアブレーションはKimi k3を使用し、タスクあたり40例でした。 チャートは同じ評価実行の結果を示しており、小さな差は結論を引き出す前に繰り返し実験が必要です。
チャットモデルのコストは当時のKimiのAPI価格を用いて計算し、共通の価格基準でアプローチを比較できるようにしました。 実際にはサブスクリプションを通じて実験を行ったので、これらの数値は私たちが支払った請求額ではありません。
Jevチームの要請により、Jev自身の性能数値を開示することはできません。 したがってこの記事のモデル評価数値は、チャットモデルとオープンウェイトモデルから来ています。