王雲和のスタートアップが、エージェントネイティブな最初のモデル「NeoHorse」をリリース

王雲鶴は起業後、初めて大規模モデルの成果を提出した。

量子位が報じたところによると、華為ノア方舟研究所の元所長、 Pangu大モデル代表王雲鶴が設立した基元律動が、初のAgent-Nativeモデル「NeoHorse」を発表。

このモデルは、無問芯穹が基盤インフラとInfra最適化技術を提供し、清华大学および北京大学のチームがアルゴリズムとトレーニング手法の研究に参加し、Agentの後トレーニングにおけるデータ利用効率とトレーニング効果の向上を共同で探求しています。

NeoHorse-1は4Bおよび9Bの2つのバージョンを含み、ツールの呼び出し、環境フィードバックの読み取り、エラーの検出、経路の調整、そして最終的なタスク完了に必要な一連の能力に焦点を当てています。

Harness Agent、ツール使用、コード、指示の順守など10の評価項目において、Agentic Post-Training後、4Bモデルの総合パフォーマンスは9B基礎モデルに達し、やや上回りました。

常に複数のモデル協力を強調してきた企業が、なぜ自社でモデルのトレーニングを始め始めたのか？プリミティブ・リズムは基礎モデルのテーブルに参加する準備をしているのか？

NeoHorseの回答から見ると、方向にはそのような変化は見られません。

このモデルは、プリミティブ・リズムが過去に蓄積してきたマルチモデル実行の経験を初めてモデルパラメータに取り入れたものです。

エージェントのモデルを選定する会社も、モデルのトレーニングを開始した

これまで、スコアはモデルを比較する主な基準となってきた。

しかし、モデルがエージェントシステムに導入され、完全なタスクを担い始めるにつれて、単一のスコアの説明力は低下する。

タスクでは、モデルは単に合理的な答えを提示するだけでなく、実行中に環境のフィードバックを継続的に読み取り、エラーを処理し、実際の進捗に応じてその後の経路を調整する必要があります。各段階では、モデルに求められる能力も異なります。

これにより、エレメントリズムチームは一つの判断を形成了しました。

モデルの非正規化は、AI産業に長期間存在し続ける構造である。

モデルが増えるほど、分業が細分化されるほど、価格と能力の差が明確になり、以下の質問に体系的に答える必要が高まる。

このステップではどのモデルを使用すべきですか？どの工程をコストが低いモデルに任せられますか？いつ、推論および実行能力がより高いモデルにアップグレードする必要がありますか？実行パスがブロックされた場合、誰に引き継がせますか？複数のモデルを並列でソリューションを提示させ、その結果を統合することは可能ですか？

王雲鶴チームはこのレイヤーシステムをRouting Harnessと呼んでいます（同チームの関連オープンソースプロジェクトOpenSquillaは複数のモデルを統一インターフェースで接続し、Agentの実行中に細粒度のルーティング、モデル切り替え、複数モデルの協働を実現しています）。

同様に、この考えに基づけば、プリミティブ・リズムには自らモデルを訓練する強い理由はなさそうです。市場にはすでに十分に豊富なモデルが存在しており、必要に応じて呼び出す方がより柔軟です。

スケジューリングシステムが継続して動作するにつれ、他の種類の資産も蓄積され始めています。たとえば、「どのようなタスクにどのような能力が必要か」「モデルはどの段階で失敗しやすいか」「どのような修復パスが有効か」「どのような結果が環境検証を通過できるか」などです。

これらの情報は、ルーティング判断を向上させる一方で、トレーニング価値も持ち始めています。

これは多くのブランドと消費者を結びつけるプラットフォームに似ています。取引中に蓄積された需要、評価、使用フィードバックは、商品がより適切なユーザーに届くのを助け、さらに製品開発にフィードバックとして活用できます。

プラットフォームサービスマーケットのプロセスは、次回の製品改善のためのデータソースとなります。

NeoHorseは、基元律動がHarness内で蓄積してきた一部の実行経験をモデルの能力に変換することを担っています。

マルチモデルが歩んできた道を、Agent-Nativeモデルに習熟させる

NeoHorseのデータソースは注目に値します。

その核心的なコーパスは、Routing Harnessが生成するAgent実行シグナルと公開データを統合し、Agentの後学習向けのデータ体系を構築することである。

エージェントがHarnessでタスクを完了すると、完全な実行ログが残されます。

タスクを入力→ ルーターが必要な能力を判断
→ あるモデルを選択
モデルが推論とツール呼び出しを実行
→ 環境の返信結果
モデルが継続して実行されるか、エラーが発生します
→ システムがモデルを切り替えたり、パスを調整したりします
→ タスクが最終的に完了または失敗する

よくある質問のデータは通常、「質問」と「回答」の両端に集中しています。

Routing Harnessのデータには、タスクに必要な能力、システムが下した実行決定、および環境が最終的に提供したフィードバックという追加の複数の情報層が含まれています。

例えば、ルーターは当初、あるタスクには通常のモデルで十分だと判断しましたが、実行中に連続して失敗したため、より強力なモデルに昇格させ、ようやくタスクを完了しました。

この軌跡には、単なる失敗以上の情報が含まれています。

システムは、初期の能力判断が過小評価されていたこと、モデルがどの段階で問題が発生したか、より強力なモデルがどのような戦略を採用したか、どの実行パスが環境検証を通過したか、およびタスク完了に追加で消費されたトークン数と時間を把握できます。

より重要な点は、基元律動が観測しているのは、あるモデルが自身の能力を判断することではなく、複数のモデルが類似タスクに取り組んだ際の横断的なパフォーマンスであることです。

その中には成功したパスもあれば、途中で失敗し、他のモデルに引き継がれた実行記録もあります。

トレーニングの観点から見ると、失敗した経路の方がむしろより多くの情報を提供する可能性があります。

最終的な答えはモデルに実行可能なパスを示し、失敗と修正のプロセスは、どこでエラーが発生しやすく、エラー発生後にどのように調整すべきかという他の2つの知識を補完する。

複数のモデルが与えた結果だけでなく、タスク環境内で複数のモデルが実際にたどった経路も学習する点が、NeoHorseの特徴の一つです。

エージェントの作業ログをモデルの能力にどう変換するか

すべてのログを訓練に投入しても、自然により強力なエージェントモデルが得られるわけではない。

エージェントのトレースは通常非常に長く、システムプロンプト、ユーザー要求、ツールパラメータ、実行結果、繰り返し試行、エラーメッセージ、および多数の中間出力が混在しています。

一部のステップは訓練価値がありますが、一部はノイズに近いです。また、トラジェクトリのプロセスは完全でも、結果自体が正しくない場合があります。

基元律動はまず、「どのデータがモデルの学習に値するか」という問題を解決する必要がある。

技術レポートによると、各トラジェクトリは構造チェックを経て、リクエスト、モデルの返答、ツールの呼び出し、および環境の結果が対応していることが確認されます。

その後、システムはユーザーの目標が達成されたか、指示に従ったか、ツールの使用が適切か、結論が証拠に基づいているか、エラー発生時に回復できたか、およびモデルが適切なタイミングでタスクを終了したかの6つの観点から実行品質を評価します。

ここには、エージェントのトレーニングで混同されがちな問題も含まれています。

タスクの終了は、ユーザーの目標が満たされたことを意味しない——モデルが「タスクが完了しました」と出力することは、実行フローが停止したことを示すだけで、提供物がユーザーの要件を満たしていることを証明しない。

したがって、完了状態、目標達成度、環境証拠、およびユーザーのフィードバックは、それぞれ異なるシグナルとして記録する必要があります。

データのフィルタリングが完了した後、ルーティングシグナルは別の役割を果たし始めます。

ルーターはタスクに必要な能力を推定し、異なる能力レベルのシグナルを生成します。NeoHorseは訓練中にこのシグナルに基づいてサンプルの順序を調整し、まず能力要件が低いタスクを学習した後、徐々により複雑な実行トラジェクトリーへと移行しながら、基本タスクのカバーを維持します。

この方法は、ルーティングガイドドカリキュラムと呼ばれます。

簡単に言うと、ルーティングシグナルはオンラインでタスクを誰に割り当てるかを決定し、トレーニング段階では、どのタスクを先に学習するのが適しているか、どのタスクを後に学習するのが適しているかをモデルに教えることができます。

通常の監督微調に加えて、NeoHorseはオンポリシーディスティレーションも使用しています。

生徒が自分なりの方法で問題を解くようにし、その後、教師が生徒が実際に到達したステップに応じて指導を与えることができる。

これにより、教師モデルは事前に用意された一連の標準的なエラーではなく、学生モデルの現在の分布で直面する問題を処理します。

これらのプロセスを経て、複数のモデルによる長期的な実行タスクから蓄積された経験が、NeoHorseの後学習に活用され始めています。

トレーニング後の改善点は何か？

現在の技術レポートの結果によると、Agentic Post-Trainingは4Bおよび9Bの両スケールで安定した向上をもたらしています。

その中で、NeoHorse-1-4Bの総合的なパフォーマンス（マクロ平均スコアが58.94から64.87へ向上）は、同規模のSOTAに達しており、すべての比較可能なベンチマークで基礎モデルであるQwen3.5-4Bを上回り、4B規模の比較モデルの中で総合的にリードしています。

しかし、SOTAは能力が均等に広がっていることを意味するわけではありません。

さらに結果を分解して見ると、4Bモデルの改善は主に一つのタスクに集中しています。

このようなタスクは通常、比較的明確な作業フローを持ち、環境からのフィードバックを観察でき、成功と失敗を検証でき、最終的な納品基準も明確です。

例えば、プロジェクトのスケジュールタスクにおいて、ベースモデルは作業ディレクトリ内のファイルを検出しましたが、最新の依存関係制約を含むメールの読み取りを継続しませんでした。

結果、既に期限切れの情報に基づいて計画を生成し、ファイルを誤った場所に保存しました。

後学習されたモデルは、追加の証拠を継続的に読み取り、制約が変化したことを検出し、スケジュールを再計算して結果を検証した後、成果物を正しい場所に保存します。

その差異はエージェントの実行チェーンに現れます。

一つのモデルはタスクの実行方法を大まかに理解しており、もう一つのモデルは証拠の収集、制約の更新、実行、検証、および納品を比較的完成度の高いワークフローとしてつなげられる。

同じ規模のSOTAに到達することとは、NeoHorse-1-4Bにすべてのタスクを担わせることを意味しない。基元律動は、異なるモデルの能力範囲をどのように精緻に分割するかに注目している。

4Bで安定して実行できるタスクは、より大規模なモデルの呼び出しを減らすことができる。より強力なモデルで実行できるタスクは、常に最高価格のフラグシップモデルにアップグレードする必要はない。難易度がさらに上昇した場合、モデルプール内でより強力なモデルに引き継ぐ。

ここで、Routing Harnessと自社開発モデルとの関係が正好に繋がります。

モデルは、対応可能なタスクのコスト範囲を継続的に拡張し、ルーティングシステムはタスクの難易度と実行状況に応じて、異なる能力を適切な位置に配置します。

API呼び出し料以外に、このモデルにはどのような価値がありますか？

ここで、エレメントリズムの複数の製品ライン間の関係も徐々に明確になってきました。

第一層はOpenSquillaのオープンソース版です。

プリミティブ・リズムは、無料でオープンソース、ローカルデプロイ、デスクトップ製品を通じて、開発者がマルチモデルエージェントを使用するハードルを下げ、開発者とタスクの入口を接続します。

第二層はTokenRhythm APIです。

中国版OpenRouterに近い位置づけで、統一されたインターフェースを通じてさまざまなモデルの呼び出し機能を提供し、開発者や企業のモデル利用ニーズに対応するとともに、モデルベンダーがより多くのアプリケーションシーンと接続できるように支援します。

企業は複数のモデルインターフェースを個別に調整することなく、モデルの評価、選択、切り替えをより簡単に実行できます。

第3層は、企業向けのサービスとデプロイ機能です。

金融、製造などの業界では、権限、安定性、プライベートデプロイメント、およびサービス保証に対する要件が異なり、その結果としてさらに商業的な機会が生まれています。

第四層はNeoHorseです。

NeoHorseはまず、ハーネス実行中に生成された有効な経験が、選別と訓練を経てモデルの能力に変換される可能性があることを確認しました。

これにより、元律動が以前提唱したビジネスフライホイールが、モデルレベルでの結果を初めて生み出しました。

これにより、推論経済の最適化も可能になります。

NeoHorseが今後、頻度が高く、基準が明確な一連のAgentタスクを安定して受託できるようになれば、プラットフォームは自らスケジューリング可能なリソース供給を一つ増やすことになります。

これらのタスクは、推論コスト、応答速度、安定性をさらに最適化でき、モデルの供給構成をより柔軟にします。モデルが継続的に更新されるにつれ、カバー可能なタスクの範囲もさらに拡大する余地があります。

この観点から見ると、エレメント・リズムが目指していることは、製造システムにおける技術の蓄積に似ています。

外部モデルエコシステムは異なる機能を提供し、Harnessが組織と実行を担当する。実行中に得られた経験は、次のモデル改善に反映される。

モデルの接続とサービス提供に加え、サービスから得られた経験をモデルの能力に変換し、効率と品質をさらに向上させるという点で、プリミティブ・リズムはAPI集約プラットフォームを超えて一歩踏み出しています。

モデルの外で、エレメントのリズムは何かを構築しているのか？

基元律動の構想におけるサイクルは、いくつかのビジネスラインでつなげることができます：

Routing Harnessは開発者とAgentタスクを接続します
→ TokenRhythm APIの接続モデルによる供給と呼び出し要件
→ ハーネス組織が実行し、ルーティングとタスクのトラジェクトリーを蓄積
→ モデルのトレーニングに使用するために選別された有効なトレース
→ 更新されたモデルがHarnessを返し、アダプテーションタスクに参加します
→ タスク体験を改善し、より良い応答速度とコスト効率を追求
→ 継続的な利用、課金、および運営効率の向上
次回のサービス改善と研究開発投資を支援

重要な変化の一つは、モデルが生成するトラジェクトリーが、消費や呼び出しの段階にとどまらず、次回のモデル訓練のソースとなる可能性があることです。

エージェントがタスクを1回完了するたびに、ハーネスは能力の境界について1回の観察を追加します。

あるモデルが失敗した場合、システムは能力のギャップがどこに生じるかを把握する。別のモデルが成功裏に引き継ぎ、システムは新たな修正パスを取得する。ユーザーが最終的に結果を受け入れるか拒否するかにより、外部フィードバックが追加される。

タスクが増えるほど、ルーティング判断はより正確になる。ルーティング判断が正確になると、選別されるトレーニングトラジェクトリは実際のタスクにより近づく。モデルがタスクに適応すると、APIサービスはコストと体験の両面でさらに改善の機会を得る。

このサイクルが長期的に成り立つ場合、エレメントリズムと通常のAPI集約プラットフォームとの差異は、ルーティングルールやモデルリストから、トレーニングタスクの設計、トレーニング方法、およびモデルパラメータへと徐々に拡大するでしょう。

最終的に、製品のパフォーマンスを通じて示されます。

RSIまであとどれくらい？

以上は、エレメンタル・リズムがRSI（Recursive Self-Improvement、再帰的自己改善）について話し始めた背景です。

現在、基元律動はRSIの範囲をより一貫したエンジニアリングのフィードバックループに近づけており、これを二つの部分に分割できます。

最初はData-RSIです。

モデルはHarness内でタスクを継続的に実行し、ルーティング、ツール呼び出し、失敗時の復旧、および最終結果のそれぞれに対して新しい構造化レコードが生成されます。

これらの記録は選別・処理された後、後続のトレーニング用データプールに取り込まれます。そのため、トレーニングデータはすべて人手で事前準備する必要がなく、システムの継続的な使用とともに増加させることができます。

二つ目はModel-RSIです。

システムは評価結果に基づいて、現在のモデルの能力の課題を特定し、次のトレーニングデータの分布を調整してモデルを更新し、新しいモデルをHarnessに戻して実行に参加させます。

つまり、モデルは実行経験から学習し、更新されたモデルが新しいタスクを実行することで、次のトレーニングラウンドに新たなフィードバックを提供します。

しかし、NeoHorseが現在公開している情報に基づくと、このシステムを完全なRSIと見なすことはできません。

現在の技術レポートでは、1つの「実行—評価—選択—更新」のフィードバックループが検証されています。シグナル設計、報酬設計、トレーニングプロセスは依然として人間によって設定されており、複数世代のモデルが繰り返し更新された後も継続的に利益を獲得できるかどうかは、さらなる実験によって確認する必要があります。

したがって、NeoHorseの今回のリリースは二重の検証を完了しました。

1階層はビジネス上のもので、システムが蓄積したデータはモデルのトレーニングに使用され、測定可能な能力の向上に変換されます。

もう一つの層は技術的なもので、王雲鶴が起業チームを率いて、RSI方向への単一のエンジニアリング検証を完了しました。