本研究は、次世代AIモデルのための自己学習型ハイブリッド推論マニフォールド「HyEvo」を提案するものである。従来の手動設計によるエージェント構造を廃し、LLMノード(セマンティック推論用)とコードノード(決定論的実行用)を統合した異種混合型ワークフローを自律的に構築する。メタエージェントが実行ログを分析し、数学的に最適化された計算グラフトポロジーを発見する進化的探索フレームワークであり、マルチアイランド戦略とエリートアーカイブによって構造的多様性を維持しながら高性能ソリューションを保持する。ベンチマークでは既存手法を大幅に上回る性能を示したが、特定データセットへの過適合リスクや膨大な事前学習コストといった実用上の課題も存在する。
ハイブリッド進化による自己構築型AI
こんにちは、コミュニティの皆さん。お帰りなさい。今日はハイブリッド進化についてお話しします。次世代AIモデルのための自己学習型ハイブリッド推論マニフォールドです。
前回の動画ではハイパーエージェントについてお話ししました。チューリングマシンをベースにしていて、MTOがハイパー構造を最適化しようとするものでしたね。
ご覧の通り、自己進化、自己構築するAIというトピックが今週の大きなテーマになっています。新しい研究があります。これは2026年3月20日のものです。効率的な推論のための自己進化型ハイブリッドワークフローというタイトルです。華東師範大学、北京航空航天大学、上海大学、復旦大学による研究です。
自律的なアーキテクチャ構築
彼らが言うには、AIエージェントシステムに新しいアーキテクチャを自律的に構築できるシステムを作りましょうということです。セマンティック推論のためのLLMノードと、決定論的実行のためのコードノードを統合するんです。
アイデアはシンプルです。大規模言語モデル、LLMにはできないことがたくさんあります。例えば数学ですね。だからコードノードを使うんです。Python環境やC++に移行して、そこで数学的計算を行い、それを大規模言語モデルの推論にフィードバックするわけです。やってみましょう。
でも私たちが望んでいるのは、これが線形構造やスター構造であることではありません。これを最適化問題として、AIに解決させたいんです。
つまり、この特定のエージェント構造の手動トポロジー設計を排除したいということです。もう手動でLangChainやAutoGenを作る必要はないんです。若い頃に使っていたツールで、批評LLMをどこに配置するか、生成LLMをどこに置くか、オーケストレーションLLMをどこに置くかを決めなければならなかったようなツールですね。
今はAIがあります。だから、この特定のジョブ、ターゲットデータセットのために数学的に計算された最適な計算グラフをAIシステムに発見させればいいんです。注意してください、これは非常に特定のターゲットデータセット構成です。
決定論的操作と確率的生成の分離
最初のアイデアはシンプルでした。一般的にタスクの複雑さをここで分離するということです。
数学的実行やデータ書き込みのような決定論的操作を、確率的なLLM生成からコードノードにオフロードするんです。ここに小さなホロー効果が見えますね。特定のノード特性を持つトポロジー、マニフォールドを構築します。これが完全なハイブリッド進化フレームワークです。見てみましょう。
これが研究からのスクリーンショットです。著者たちは、ワークフローを初期化しましょうと言っています。特定の集団を初期化する必要があります。ゼロから始める場合は何もありません。シンプルですね。
それから自己進化ループの開始があります。今、何らかのスタート構成があることを願いながら選択するんです。基本的なワークフローがあります。約5分後に例をお見せします。これを親ワークフローと呼びましょう。この特定のループ、この実行のために選択したものです。
それから実行ログがあります。トップワークフローがあり、それほど美しく正確ではない他の多様なワークフローもあります。
反省と行動のループ構造
今から構築するのは、ここにループ構造です。自己進化フレームワークであり、言語的推論タスクをここから決定論的タスクから分離することで、異種混合型エージェントワークフローを自律的に構築します。確率を計算するというようなタスクです。
この最初のリフラクションフェーズは、もちろん複数のエージェントがあって、メタエージェントが実行するというものです。前回の動画でもお見せしましたが、メタエージェントと作業エージェントがあります。比較分析を行って、例えば主要な親の欠点を診断するんです。その失敗ログ、実行失敗ログを調べることによってです。Pythonがあれば、Pythonコードを実行して「動いてる?」と聞くだけです。「はい、素晴らしい」となればいいわけです。
2番目のステップは、同時にこの集団から洞察を引き出すということです。
したがって、何らかのスタート集団が必要になります。ここでハイパフォーマンスな例を見ます。これをグラフトップ、トップパフォーマンスのグラフ構造と呼びます。そして他のグラフもあります。それらは多様なものです。悪くはありません。なぜなら、システムはグラフトポロジー自体の効果的なパターンと非効果的なパターンを区別しなければならないからです。
メタエージェントまたはスーパーエージェントは、特定の構造的ボトルネックを特定します。うまくいけば、これを行えるLLMがあるはずです。それから自然言語、英語で診断を定式化します。こう言うんです。「聞いてください、これが起こりました、これが起こりました。これはミスだと理解しています。なぜならフォーマットが正しくなかったから、または数学的方法が正しくなかったから」というように。
それから、この診断的勾配によってガイドされて、次世代フェーズが新しいワークフロー、新しいグラフ、新しい異種混合型ワークフローを合成します。このワークフローには、2つのLLMノードがあるかもしれません。そして3つのコーディングノードがあるかもしれません。各コードノードは特定のタスク、サブタスクを持っています。
ご覧のように、メタエージェントがここで両方のことを定義します。グラフのトポロジーとノードパラメータ自体の両方を定義して、エラーログから特定された問題を解決するんです。
サンドボックス評価とマルチアイランド戦略
お分かりのように、この反省と行動のフェーズがあります。これは古典的な方法ですが、もちろんすべてはメタエージェントの推論力に依存します。それから簡単に、評価を実行するサンドボックスがあります。パフォーマンス、実行時間、コストメトリック、何でもいいです。サンドボックスプロトコル、素晴らしいですね。
でも、それから興味深いポイントが来ます。マルチアイランド戦略を使ってワークフローを管理するんです。マルチアイランド戦略とは何かと少し驚きました。
これはいいアイデアです。解決策の各島が、ローカル集団を維持すると言うんです。最初にお話しした、2つのコンポーネントの集団を扱うという話に戻ります。履歴セットがあります。これはすべての有効なワークフローを保存します。すべてです。そして、これらの有効なワークフローのうち、時間的に最良だったもの、コスト的に最良だったもの、推論能力的に最良だったものを知りたいんです。
分かりますか?では何を構築するのか?構造化された、彼らがエリートアーカイブと呼ぶものを構築します。A4アーカイブで、表現型空間をグリッドセルに離散化します。例えば、ここにノート数や比率が見えます。
エリートアーカイブの内部構造をどのように構築したいかによりますが、特定のメトリックに対して最適化したい場合、これが最適化する次元、軸になることがすぐに分かります。
ワークフローの複雑性を使って、研究では総ノード数を選びました。総ノード数は本当にワークフロー複雑性の完璧なメトリックでしょうか?多分そうかもしれないし、そうでないかもしれません。
それから推論密度を選びました。これは著者によってLLMノードの割合として定義されています。
多くの最適化空間があることが分かりますね。より良いアイランド構造を構築する方法です。なぜこれを行うのか?このメカニズムは、アーカイブが各特定の構造的構成に対して最高性能のソリューションのみを保持することを保証します。お話ししたように、推論時間、コスト、複雑性、推論構造、分かりますね。
グラフ構造からハイパーグラフへ
前回の動画で何人かの方が聞いてきました。「ねえ、なぜ通常のグラフ構造にとどまるんですか?ハイパーグラフに行かないんですか?」と。
ハイパーグラフ変換アーキテクチャがあります。10分前、いや2分前にお見せして、コーディング方法と構築方法を示しました。でも、著者は古典的なグラフ構造を選びました。
さて、私のチャンネルの購読者なら、これを構築する方法をお見せしたことを知っているはずです。トポロジカル歪みがあり、対処しなければならないクリック拡張があります。ハイパーエッジとハイパーグラフは任意の数のノードに接続できます。すみません、タイプミスです。もちろん、これははるかに高度な方法論ですが、やりたければできます。
元の論文に戻りましょう。このプレプリントは、自律的エージェントワークフロー生成を、コンテキストとコンテンツからのプロンプトエンジニアリングタスクとしてではなく、多目的ニューラルアーキテクチャ探索として定式化しています。理論的に可能なすべての組み合わせアーキテクチャニューラルアーキテクチャ構成の空間があると考えます。これは巨大な空間です。そして私たちは、特定のタスク、特定のクエリ、特定の検証データセットに対する最適な構成を単純に検索すればいいんです。
著者はこの空間をハイブリッド探索空間オメガと呼んでいます。素晴らしいですね。
メタエージェントと作業ノードの役割分担
では何があるのか?お話ししたように、メタエージェント、包括的なスーパーLLM、ボス、何と呼んでもいいです。実際のユーザークエリを解決するのが仕事ではありません。
その唯一の仕事は、ログを分析し、その特定の事前学習と学習データを考慮して最適なワークフローを設計し、それから特定のノード構成、グラフのトポロジーに入るプロンプトとPythonスクリプトを書くことです。
誰が実際の仕事をするのか?ノードLLM、作業者です。アーキテクトが構築したワークフロー内に存在するLLMインスタンスです。3つのLLMノードがあります。例えば古典的な、プランナー、サマライザー、レビュアーです。
これらは実行中の3つの別々のLLM呼び出しです。興味深いのは、ノード空間がある場合、これを2つの異なる生成的サブ空間の結合として見るということです。LLMノード、つまりLLMノードがあります。そこにはモデル、命令、温度、そして何でもハイパーパラメータがあります。それからコードサブ空間があります。これらはコードノードで、合成されたソースコードとIO署名があります。出力は厳密に入力の関数です。分かりますか?
有向非巡回グラフ、DAGを構築しました。古典的なグラフG t θです。まずすべての複雑性を見て、それから完璧なパスを見つけます。
数学的最適化目的関数に直面しているわけです。AI数学に関する特定の動画があります、もしよければ。
でもここでは最も単純な方法で集約報酬関数を最大化するだけです。見てください、SQ、パフォーマンス精度があります。それからトークンコストがあります。それからレイテンシがあります。このシンプルなアイデアで、これがシステムを最適化する対象だと分かります。
お話ししたように、このマルチアイランドエリート進化戦略は、本当に興味深いものです。なぜなら、制約のないグラフ空間における標準的な進化研究アルゴリズムは巨大で、壊滅的なモード崩壊につながるからです。何らかの方法で制限しなければなりませんね。
集団は単なる最良グラフのリストではありません。お見せしたように、構造的複雑性、ノートフットカウントや推論密度によって明示的に曲げられています。空間を制限するんです。これにより、構造的に多様なアーキテクチャが生き残ることが保証されます。彼らがマップエリート構造と呼ぶものです。
それからこれは興味深いです。島間で要素が移動できます。システムはk個、20個、50個、100個の孤立した集団を維持します。そしてデルタマイグレーション反復ごとに、島は最良のソリューションを交換できます。さらなる最適化ができるわけです。10個の島を持ち、トップ10の構造を見て、「これを組み合わせられるか?さらに最適化できるか?」と言えるんです。
何について話しているのか、すぐに理解できますね。
コンテキストサンプリングと診断プロセス
それからコンテキストサンプリングの瞬間が来ます。これに慣れているはずです。エージェントには、お話ししたように、親グラフの失敗ログ親を取得するために供給されます。トップパフォーマンスの例と、動画の冒頭でお見せした多様な構造的努力、グラフダイバースがあります。
それから診断文字列があります。ここで反省です。piデータによって、なぜ親グラフが特定のエッジで失敗したかを説明します。何らかの説明を与えます。
もちろん、システムがエラーログを理解し、美しいソリューションを思いつくことを望んでいます。子孫グラフ新のコードを合成します。必要なコードノードの量、必要なLLMノードの量はこれだけだと言い、タスクの複雑性に対して完璧なトポロジーを構築します。
サンドボックス評価について話しました。美しいですね。もちろん、高速であるために、サンドボックス内の小さなパーティションから始めて、構文エラーや大規模な論理的失敗をキャッチします。そして最初のベースラインしきい値をクリアした場合にのみ、完全なデータセット評価に公開します。
具体例:数式抽出と計算
例をお見せしましょう。これは非常にシンプルな私の例です。基本的な洞察を提供するためのものです。
クエリがあるとしましょう。乱雑なテキストから数式を抽出します。PDF形式だとしましょう。そしてその数式を解きます。
メタエージェントはまだ賢くしようとはしません。正確に1つのLLMノードからなるシードワークフローを作成します。タスクはテキストを読んでここに答えを出力することです。
システムは今、このノードワークフローを取り、検証セット、例えば100個の数学問題で実行します。テキスト内の数式と同じ複雑性と同じ数学的深さを持つものです。注意してください。そしてデータを収集します。この検証セットで与えた100問のうち、60問正解しました。コストはトークンで2ドル、45秒ですが、複雑な数学演算では完全に失敗しました。
もちろんです。LLMノードがあって、コードLLMではないからです。
ステップ3は、メタエージェントが実行ログ、トークンコスト、レイテンシ、そしてRSを見ているということです。そしてこう言います。「LLMノードがここで数式を幻覚し続けている。だから大規模言語だけで行くのは時間の無駄です。新しいワークフローグラフを構築しなければなりません」
このワークフローグラフでは、何だと思いますか?Python実行用のコードノードができました。おめでとうございます。
メタエージェントによって作成された新しい構造です。LLMノード1が方程式を純粋なテキストに抽出します。コードノードが次にpython evalで数式を計算します。そしてLLMノード2が最終的な応答をフォーマットします。
このシンプルな例で、これが進むべき道だと分かりますね。
注意深く、この方法論の何が特別なのかと尋ねるかもしれません。まあ、単にその1つのコードで無限にループするだけではありません。いいえ、私たちが持っている標準的なコーディングアシスタントのようにではありません。
なぜなら、これはLLMノードとコード固有のノードのトポロジーを最適化して、最良のグラフ構造を構築することに焦点を当てているからです。メタエージェントが失敗を見て、「このpy評価ノードはここで脆弱すぎる可能性がある。だからアーキテクチャ全体を再び変更しよう」と言うポイントがあります。
新しいトポロジーを発明します。新しいメンバー間、新しいノード構造間の新しいループを発明します。これは単なる純粋なコード最適化やコンテキストプロンプト最適化ではないことが分かりますね。これは本当に、マルチエージェントシステムを構築する建築的な方法なんです。
待ってください。これが研究からのスクリーンショットで、島とのこの視覚化で私たちが見てきたことが正確に分かります。
初期化されたワークフローから始めます。それから島1があり、すべての最適化トピックを実行します。
ベンチマーク結果と性能評価
ここでの結果は何でしょうか?私たちが持っているさまざまなベンチマークの平均です。最後の列を見てみましょう。Chain of Thoughtの複雑版から始まり、フローがあり、最後の行がここでの新しいハイブリッド進化です。
ご覧のように、この新しいモデルは美しく他を上回っています。でも注意してください、なぜ上回るのか考えてみてください。いくつかの制限があります。おそらく著者はこれを本当に指摘していません。だから私の考えを述べさせてください。
単純にLLMにプロンプトを出して最適なマルチエージェントグラフを設計させると、学習中に見たトポロジー、事前学習データセットで見たトポロジーをそのまま吐き出します。
知っていること、学習してきたことで行くんです。Chain of Thought、基本的なアクター批評ループ、リアクトパターン。LLMの生の生成能力は、事前学習の潜在空間によって絶対的に制限されています。そして繰り返しますが、皆が突然AIが目覚めて超知能になることを期待していたことは知っていますが、今日までそれは起こっていません。
ゼロショットでここに根本的に新しいトポロジー、新しいパラダイムを発明することはできません。著者は再び、この制限に対処しようとします。「これは突然変異エンジンではない」と言うことによってです。申し訳ありませんが、これは単に組み合わせの多様性です。異なるノードをどのように組み合わせるか、異なるレベルでどのような複雑性を達成できるかということです。そして進化的探索ルーチンがあります。エリートと共に。
生物学と比較すれば、これが突然変異構造とは何の関係もないことがすぐに理解できます。より良い理解を得たい場合は、Pyコードを見ることを強くお勧めします。Pyコードを本当に愛し始めているからです。なぜなら、ロジックを本当にここで提供してくれるからです。テキストではない場合があります。時々、テキストの順序は1つの部分に焦点を当てていて、2番目の部分のすべての複雑性には本当に言及していません。
でもここにあります。絶対に。だからこれはシステムのフロー、フローチャートを理解するのに少し役立つかもしれません。でも制限が何かをお伝えしたいです。
重要な制限事項:過学習リスク
明らかにターゲット分布への過学習があります。特定のデータセットに対してこのグラフトポロジーを最適化するからです。
お見せしたように、数学ベンチマーク構造です。そして最初に持っている進化的探索プロセスが時間がかかります。与えられたデータセットに対して特別に最適化された、非常に特定のPython文字列解析ルールを発見します。非常に特定のトピックの正しい数学的答えを抽出するためのものです。そのコードノードは、言ってみればワークフローに焼き付けられています。
でもこのワークフローを実際の世界に展開する場合、「評価手順を忘れよう、3年間知っている手順を忘れて、実際の世界に出よう」と言い、ユーザーがわずかに異なるフォーマットの数学的質問をすると、このコードノードは即座にクラッシュします。
著者が言うように、生成されたワークフローは検証セットのプロンプト分布に高度に適合しています。特定の与えられたデータセット、単一の数学ベンチマークで、引用符付きで学習させ、事前定義されたものであれば、それに対しては機能します。
汎化はそこにありません。考えてみてください。トポロジー最適化について話しているんです。トポロジー汎化ではありません。これは別の動画のトピックかもしれません。
大規模な単一障害点があります。もちろん、これはメタエージェントのコーディング能力です。コードを書き直し、トポロジーを書き直すなら。
コーディング能力にはOpus 4.6か何かお気に入りのものを使用することを願っています。ログに基づいてコードノートを書いて、デバッグして、接続するためにです。強力なコード構造が必要です。
推論コストと学習コストのトレードオフ
論文を読むと、著者が推論コストがどれほど安いかを自慢しているような感じを受けます。最終的に生成されたワークフロー。推論時にこのワークフローを実行すると、とても安いんです。とても美しい。とてもずっと速い。彼らは全く正しいです。速いです。
でも、ここで尋ね忘れた質問が1つあるかもしれません。このトポロジーの学習コストは何でしょうか?
この特定のベンチマーク、この数学ベンチマーク、この検証可能なベンチマークに対して最適なグラフを見つけるために、フレームワークは複数の島にわたって40回の反復を実行し、大規模なLLMを使用して検証セットを使って生成されたワークフローを常に評価し、Pythonコードを生成し、実行し、構文エラーを見つけ、何千ものプロンプトを反映します。アイデアが分かったでしょう。
私の間違いかもしれません。論文は、推論を開始する前に、本当に良いトポロジカルグラフ構造を達成するために、この自己進化ループを実行するために必要なドルコストとコンピュータ時間をここで完全に省略していると思います。なぜなら、特定のシステムを学習させなければならないからです。
だから、学習のコストや時間を見つけることができませんでした。したがって、今推論実行を行うことが他のシステムより19倍安いというのは驚くことではありません。
でも他のシステムは、大規模なLLMを使って「この文字列が有効なJSON形式かチェックして」というようなことをしていたことを思い出してください。LLMでJSONをチェックするのは本当のお金がかかります。複雑性によっては3秒から5秒かかるかもしれません。
今、3行のPythonスクリプトで式を単純にチェックする場合、ゼロドルかかります。1ミリ秒以下かかります。つまり、本当にリンゴとリンゴの比較ではないことが分かりますね。新しい方法論です。でも注意してください。
この新しいハイブリッド進化が推論レイテンシをトレードしている可能性があります。非常に特定のタスク構造に対する大規模な事前探索計算のために高速です。そして本当に硬直した過学習パイプラインを作成するリスクがあります。
利点があり、彼らは利点を示しています。でも注意してください。コードLLMと純粋なLLMノードを分離する、このトポロジー最適化されたグラフ構造を考え出すためには、特定のベンチマーク最適化に多くの学習が入っているんです。
まとめ:自己進化システムの新たな理解
とにかく、少し楽しんでいただけたことを願っています。ある種の自己進化システムです。絶対にそうです。純粋なワークフロー構造の最適化を見る場合、自己進化がどのように展開されるかの別の理解です。
少し楽しんでいただけたことを願っています。新しい情報、新しい洞察が得られたことを願っています。次の動画でお会いできたら素晴らしいです。
コメント