本動画は、AIの最新動向としてAnthropicと清華大学の論文に基づき、AIエージェントの新たなアーキテクチャ「ハーネスエンジニアリング」について解説するものである。従来のプロンプトエンジニアリングやコンテキストエンジニアリングの限界を指摘し、AIの思考プロセスや状態をLLMの内部メモリではなく外部のファイルシステムに記録・管理する手法を紹介している。これにより、ハルシネーションやコンテキストの劣化を防ぐ試みがなされているが、一方でメインのLLM自体が学習しないという根本的な課題も提示している。
AIの進化：プロンプトからハーネスエンジニアリングへ
皆さんこんにちは、戻ってきてくれて本当に嬉しいです。はい、今日は人工知能の最新の発展に関する全く新しい論文をご紹介します。今日も少し楽しみながら学んでいきましょう。それでは始めます。
AIの石器時代にはプロンプトエンジニアリングというものがありましたね。ステップ・バイ・ステップで考えよう、といった魔法の言葉を見つけることで、直接的にトークンの確率を形成していました。思考の連鎖を用いたり、あなたは熟練のプログラマーですといったペルソナをAIシステムに与えたりして、人間とAIのステートレスな単発のやり取りを前提としていました。
その後、コンテキストエンジニアリングが登場しました。研究者たちは、長期的なタスクが完全に失敗するのは、LLMにその能力がないからではなく、彼らがコンテキストの腐敗と呼ぶ現象、つまり膨大なトークンシーケンスに対するアテンションの希薄化が原因であることに気づいたのです。つまりコンテキストエンジニアリングとは、あるステップtにおいて、私たちのコンテキストベクトルの高次元数学空間の中にあるものを動的にキュレーションすることです。これには、RAGやコンテキストの折りたたみ、過去の対話の要約、特定のログの注入、仮説の提供など、皆さんがご存知のあらゆる手法が含まれます。素晴らしいですね。コンテキストエンジニアリングの変数となるのは、もちろん情報密度そのものと、その複雑さのレベルを考慮した特定のタスクに対する情報の関連性です。
そして今、新しいものが登場しました。それがハーネスシステムエンジニアリングです。あるいは、これをファクトリーアーキテクトと呼ぶ人もいますし、好きなように呼んで構いません。これはコンテキストエンジニアリングを包含するエンジニアリングですが、時間のトポロジー、いくつかの物理法則、そして少しの論理といった複雑さを追加しています。少し見てみましょう。
ハーネスが定義するのは、驚くことではありませんが、実行そのもののグラフです。つまり、誰がコンテキストを受け取るのかというルーティング、誰がこのエラーログをプランナーエージェントやデバッガーエージェントに送るのか、スケジューリングの観点からいつこのコンテキストが提供されるべきか、そして停止条件や契約、検証ゲートなど、あらゆることをシンプルに問いかけます。このように、コアエージェントであるLLMの周りにシンプルなハーネスを定義するわけです。中央にオーケストレーションエージェントが配置され、その周りに子エージェントが配置される形になります。
新たなアプローチ：外部ファイルシステムを活用した状態管理
チャンネルメンバーの皆さん、いつもサポートありがとうございます。この動画を見る数日前、具体的には3日前に、Anthropicのエンジニアリングチームが2026年3月24日に発表した、特定のAnthropicの機能とファイルシステムを前提とした長期稼働アプリケーション開発のためのハーネス設計に関する新しい論文についてすでにお話ししました。また、静的テンプレートから動的ランタイムグラフへという別のPDFも紹介しましたね。これは3月23日に発表されたLLMエージェントのフロー最適化に関する完全な調査報告で、すべての方法論の非常に美しい概要がまとめられていました。
しかし今日は、清華大学による全く新しいアイデアである、もう一つの方法論を追加でご紹介します。メンバーでない方も心配しないでください。簡単に説明しましょう。プロンプトエンジニアリングとは、AIのための明確な取扱説明書を書くことです。そしてコンテキストエンジニアリングとは、作業員が必要とする直前に、作業台の上に適切なツールと青写真を配置することです。そしてハーネスエンジニアリングとは、言ってみれば工場の壁を建設し、ワークステーション間のベルトコンベアを定義し、品質検査員を雇い、シンプルなルールを強制することです。そのルールとは、監査員がスタンプを押し、認証があり、証明され、すべてが正しいと確認されない限り、製品は工場から出荷されないというものです。
とてもシンプルですね。これが深センにある清華大学の研究で、彼らは2026年3月26日にハーネス設計に関する論文を発表しました。彼らによると、ハーネスの設計は通常、コントローラーのコードやランタイム固有の規則の中に埋もれてしまっており、移行したり、比較したり、正確に何が起こっているのかを研究したりするのが非常に困難になっているそうです。そこで彼らは、このハーネス設計に光を当てたいと考えており、私はそれが素晴らしいアイデアだと思います。それでは見ていきましょう。
オーケストレーションエージェントと実行グラフの抽象化
彼らはまず、例えばGPT-4oのようなメインとなる知能、つまりメインエージェントが存在すると仮定します。そしてこのオーケストレーションエージェントの唯一の仕事は、サブエージェントを立ち上げることです。私たちにはやるべき仕事がたくさんあります。シンプルなReActフレームワーク、自己進化型エージェント、RAG、リフレクション、メモリなど、想像できるあらゆるものがあります。つまり、現代のエージェントで使用されているハーネスの設計パターンには、ReActによる検索、リフレクション、検証、メモリ、探索からオーケストレーションに至るまで、あらゆるものが含まれています。
これを少しだけ数学的に説明すると、著者たちはLLMの生成という概念を、エージェントコールという概念に格上げしています。ご存知の通り、マルチモーダルLLMは、コンテキストCを出力結果Yにマッピングするものとみなすことができます。ここで、コンテキストにはテキスト、画像、動画、音声などあらゆるものが含まれます。しかし、コンテキストから単にY＝LLM(C)とするのではなく、ベースモデルの呼び出しをエージェントコールに引き上げるのです。
そのため著者たちはここでタスクTを定義しており、プロンプトや入力ファイルのためのパラメータが存在します。後ほどすぐにお見せしますが、ここには決定論的なファイルシステムが存在します。そしてK、あるいはカッパと呼ばれるものが、私たちが持つ実行契約になります。これは、金銭的または時間的な予算内に収めること、権限を持つこと、必要な出力パスやフォーマットを持つことなどを示します。これがタスクの定義であり、エージェントコールはある時点tでシンプルに実行されます。
エージェントコールが定義されており、そのパラメータはシンプルです。Aから始めましょう。これは生成された成果物です。次にデルタオメガがあります。これは環境への変更を意味します。そしてYDがあります。これは、成功または失敗を示す最終的な応答のポイントです。そしてここで最も重要な一文は、私たちの自然言語エージェントハーネスは、これらのエージェントコールを動的にオーケストレーションするために存在しているということです。まさにこれです。ハーネス定義の背後には何があるのでしょうか。素晴らしいですね。
自然言語エージェントハーネスと外部ファイルシステム
論文からのスクリーンショットが提示されていますが、それによると、昔は従来のコードと結合されたハーネスがありました。実行タスクを定義し、ステージ1で計画、ステージ2で実行、ステージ3で検証を行い、おそらくステージ4が修復ループ、つまりどう修正するかという流れでした。そしてコードを返していました。しかし今、彼らはこれを自然言語でやろうと提案しています。簡単ですね。関数を実装し、テスト段階や計画、実行などすべてをクリアすることを確認するだけです。そして今、私たちには少しばかりのサポート構造が必要です。
自然言語エージェントハーネスとランタイムそのものが必要であり、彼らはこれをインテリジェント・ハーネス・ランタイム、略してIHRと呼んでいます。ここからが私たちが注目するポイントですが、皆さんはすでに最も重要な事実に気づいているはずです。Anthropicで現在何が起きているのか、Anthropicがどのように開発を進め、ファイルに裏付けられた状態モジュールをどのように提供・公開しているのかを理解すればわかることです。つまり、私たちにはワークスペースがあり、成果物があり、台帳があり、そしてタスクの状態といった応答からのすべてが存在します。
このように、このワークスペースこそが私たちが今まさに焦点を当てるべきものです。コアとなる部分には、インループLLM、つまりインタプリタLLMでありメインのオーケストレーターが存在します。次に、ランタイム憲章、あるいはポリシー、セマンティクス、すべての子エージェントにまたがるオーケストレーションがあります。そしてツールインターフェースとエージェントコールがあります。これですべてです。皆さんにはお馴染みのものでしょう。
私たちは今、あるアイデアにたどり着きました。それは、ほぼすべての同期、すべての小さなステップを、対話の中やLLMのワーキングメモリの中ではなく、外部のファイルシステムに置くというものです。まさにこれです。それでは見ていきましょう。
インテリジェント・ハーネス・ランタイム（IHR）のアーキテクチャ
インテリジェント・ハーネス・ランタイムのアーキテクチャとはどのようなものでしょうか。それはシンプルに共有ランタイムです。そして、明示的な契約、ファイルに書き込まれた永続的な成果物、そしてLLM構造を最適化するための軽量なアダプターを通じてハーネスを実行します。私たちが何をしているのか考えてみてください。中央には素晴らしい知能があります。そう、これはGPT-4oなどのお手持ちのモデルです。
そして、複雑なタスクを実行しようとする際、その中間結果や最初の洞察が何であれ、それをLLMの内部に保持するのではなく、LLMの知能の周りに構築した外部の箱、つまり外部のファイルシステムに置くのです。すべてを外部化し、すべてを分離させるべきであり、私たちはここで原子論的なモデルやアプローチを採用したいと考えており、今年それに気づきました。これらをLLMのコンテキストウィンドウの中に保持したままにすると、次から次へと終わりのない問題が発生してしまいます。ですから現在の考え方は、個人的にはこれが単なる中間ステップであることを望んでいますが、すべての新しいデータや知能のステップを外部のファイルシステムに出力するというものです。この画像をAIの主要な画像として使いましょう。
ランタイムは非常にシンプルで、先ほどお話ししたように3つの部分から構成されています。1つ目は、皆さんがお使いの素晴らしいGPT-4oのようなインループLLMです。2つ目は、バックエンド全体のためのDocker化されたUbuntu 24.04のサンドボックスで、実際のシェルへのアクセスとファイルシステムの状態を提供します。そして3つ目は、親オーケストレーター、つまりメインの知能に対して、子エージェントをどのように立ち上げるかを指示するランタイム憲章、固定された基盤プロンプト、あるいは基本法則です。コンテキストが真か偽かに関わらず、親オーケストレーターの役割は絶対的にオーケストレーターというただ1つの仕事だけであることを強制します。しかし、これがいくつかの問題を引き起こすのですが、それについては後ほど詳しくお話しします。したがって、この親オーケストレーターは、実際のコーディングやウェブ検索などのあらゆる作業を、すべて子エージェントに委任しなければなりません。
外部化されたファイルシステムの構造と利点
ここで最も重要な事実は、例えばAnthropicを使っている方ならご存知の標準的なワークスペースについてです。まずtask.mdがあり、次にハーネススキルのマークダウンファイル、スクリプトへの参照があります。そして状態を表すタスク履歴のJSONがあり、さらに子エージェントのフォルダ、例えば001フォルダの中には、task.md、skill.md、入力データ、スクリプトのスクラッチ、応答の成果物などが含まれています。ご覧のように、これが私たちが構築する標準的なワークスペースの形です。
そして最後の列には、ファイルに裏付けられた状態のためのファイルの役割マッピングがあります。タスクオブジェクトであるtask.mdは、ローカルタスクステートメントを実行し、入力をリンクさせ、出力を指定します。次に応答ですが、これは成功や失敗のステータス、そして成果物へのポインターを伴う正規化された結果です。さらに、さまざまなスキルの参照があり、ハーネススキルのタスクファミリーが独立して、再利用可能な参照やスクリプトとともにロジックを制御します。そしてタスク履歴や子エージェントがあり、すべてがうまく機能します。
それではモジュールを見てみましょう。非常に興味深いものです。スクリーンショットをお見せしますが、エージェントに対し、標準的な状態のルートワークスペースを維持し、ファイルのみを介してノード間でデータをやり取りすることを強制しています。ここでもお分かりのように、ほぼすべての通信はLLMの対話履歴のようなコンテキストウィンドウ内ではなく、ファイルを介して行われています。つまり、情報を外部化し、おそらくマークダウンファイルのように人間にも読める状態にしておきたいわけです。非常にシンプルですね。ファイルに裏付けられた状態を見ると、ルート、ハンドオフ、子パッケージ、そして帳簿があり、皆さんが読めるすべての指示が完全にここに記載されています。
次のポイントは検証の分離です。コードを編集することはできず、厳格な合格または不合格の判定のみを出力する、独立した監査エージェントを明示的に立ち上げます。つまり、特定のジョブの複雑さを制限し、真のマイクロジョブ、マイクロタスクに落とし込んでいるのが分かります。ファイルシステムに外部化することで、ハルシネーションやコンテキストの劣化などの問題に対抗できると期待しているわけです。証拠に基づいた回答ですね。非常に明確です。
AIシステムの自己進化：可能性と矛盾
さて、私にとって現在のシステムに関する最も重要な疑問は、それらが自己進化できるのか、あるいは少なくともその可能性があるのかということです。清華大学によるこの方法論は、次のAIシステムへの開発過程における単なる中間状態だと私は考えているため、これは特に興味深い問題です。なぜなら、LLM自体に頼ることができないからこそ、私たちは外部のファイルシステムを導入したり構築したりしているに過ぎないからです。しかし、もしLLMの能力が現在のレベルを超えて進歩すれば、状況は即座に変わるでしょう。ただ、現在のAIの状態においては、Anthropicが現在実装しているような、自己進化のためのファイルシステムがおそらく必要なのでしょう。
ここでシンプルな疑問があります。英語、ドイツ語、フランス語、イタリア語など、私たちの自然言語が持つ本質的な複雑さや曖昧さ、そしてハルシネーションを引き起こしやすい性質に依存してシステムアーキテクチャを決定しているとしたら、システム全体の信頼性の高い自己進化を一体どうやって達成できるというのでしょうか。著者たちの答えは、この確率的な自然言語を、決定論的でアドレス指定可能なファイルシステムに固定することだとしています。これが、私たちのファイルに裏付けられた状態こそが解決策であるという主張です。
聞こえはいいですが、少し考えてみてください。AIモデルが自身の内部ワーキングメモリに依存するのを取り除くことで、自然言語による、いわゆる自己進化を達成しようとしているのです。これは奇妙なことです。まあ、分かりますが。つまり、自然言語を制御インターフェースとして使用し、LLMに対して自らの思考を物理的なハードドライブに書き出すよう命令するハーネスとして使うわけですが、ここで同時に2つの開発が進行していることになります。
一方では、Anthropicが100万、1,000万、最近では驚くべきことに1億トークンにも及ぶ、どんどん長くなるコンテキストウィンドウを提供してくれています。その一方で、この方法論においては、10万や20万トークンというコンテキストウィンドウを積極的に切り詰め、確率的なモデルであるLLMに対し、次のステップに進む前に、外部に保存された高度に構造化された自身のロジックや結果を常に読み取るよう強制しなければならないと言っているのです。
つまりこれは、LLMの内部的な推論を全く信用していないシステムだと言えます。ハルシネーションを起こしていないという確信が持てないわけです。コンテキストが劣化していないという確信もありませんし、10万トークンのような長いコンテキストがあった場合、途中で情報を忘れていないという確信も持てないのです。
これは興味深いアプローチであり、ますます多くの世界的なAI企業がこの手法を採用しているようです。なぜなら、現実世界に出れば出るほど、AIがハルシネーションを起こし、コンテキストの劣化という現象が発生するという現実的な問題に直面するからです。これではクライアントにこのマシンを売ることはできません。
はっきりさせておきましょう。現在のLLMはこれらを内部で処理できるほど賢くないため、これが2026年初頭における現在の回避策であることは十分に理解しています。しかし私の個人的な意見としては、これは未来の手法ではありません。LLMが存在するのに、そのLLMのあらゆる思考や推論プロセスのすべての結果を付箋に書き出し、自分自身に貼り付けるよう強制しているようなものだからです。素晴らしいですね、これが人工知能の未来ですか。冗談でしょうと言いたくなります。
失敗と反省の分離：コンテキストフォークによる再挑戦
これが彼らの真の未来だとは思わないと述べる前に、状況を整理しておきましょう。この清華大学の特定のモデルにおける自己進化の現在の道筋とは何でしょうか。自然言語のハーネスには明示的な自己進化モジュールが含まれています。私はこれに納得しているわけではありませんが、皆さんにお見せする必要があります。
これによると、仕事を試みて失敗するたびにルールがトリガーされると記載されています。次の試みを計画する前に、いくつかの具体的な失敗シグナルについて反省するのです。これは興味深いアプローチです。従来の単純なエージェント設定では、進化とは単にチャット履歴に失敗を追記することを意味していました。アシスタントがコードを出力し、環境と接触させて、あ、コードが失敗しましたとなると、アシスタントはすべてを文字列として連結し、よし、もう一度このコーディングをやり直そうと言います。私たちは経験上、これが壊滅的な複合エラーにつながることを知っています。悪いコードがアテンションメカニズムを汚染し続けているため、LLMは同じロジックを繰り返し、局所的最小値に陥ってしまいます。そこから抜け出し、全体的な最適解への道筋に乗せるためには、非常に奇妙な推進力が必要になります。
著者たちのアイデアは、ファイルに裏付けられた状態を通じてこれを防ぐというものです。ワーキングメモリ内のプロンプト構造でのインコンテキスト学習において、失敗したコードを保持する代わりに、エージェントに対して絶対的に厳格な物理的現実を強制します。エージェントは失敗した試みを台帳に書き込み、さらに、もし進化させたいのであれば、その反省を独立したファイルに書き込まなければなりません。reflection01.mdというマークダウンファイルに、ああ、こんなことが起きた、これが機能しなかった理由についての私の仮説だ、次のような解決策を提案する、と書き込みます。ご覧の通り、これらは別々のファイルなのです。
そして、AIが、よし、もう一度やろうと言って2回目の試みが始まります。2回目の試みが始まっても、オーケストレーターは単にプロンプトをループさせるわけではありません。コンテキストフォークを動的に実行します。つまり、記憶を完全に失った全く新しい子エージェントを立ち上げるのです。そしてこの新しい子エージェントは、完全な履歴を受け取ることはありません。元のタスクと、どうすれば改善できるかという反省ドキュメントだけを含む、手付かずのまっさらなコンテキストウィンドウだけを渡されます。
つまり、コンテキストウィンドウ内のトークンを最小限に抑えたいのです。過去に何が起きたのかといった、その他の余計な説明は一切不要です。コンテキストで情報を過負荷にしたくありません。絶対的な最小限にとどめ、マークダウン形式の反省ドキュメントのみを渡します。
自然言語による自己進化の実践例とその懸念
しかし、複雑な構造や複雑な数学的・物理的問題を扱う場合、私たちは人間の言葉で作業をしています。コードで作業しているわけではありません。C++やPythonなどでコーディングしているわけではなく、人間の言葉という多様性の中で作業しています。そのため、自己進化はLLM自体のコンテキストウィンドウの拡張の中ではなく、書き出された独立したファイルシステムの中での解釈において発生しています。
いわば、進化とは規律化された単なるリトライのループになります。新しいエージェント、短い情報、もう一度やり直す。新しいエージェント、短い情報、もう一度やり直す。新しいエージェント、短い情報。そして次はどうなるでしょう。またやり直すのです。
ここに例があります。これは論文から抜粋した25,747の例のうちの1つです。興味がある方のために少しお見せしましょう。彼らはここで、ファイルに裏付けられた状態による自己進化を試みています。まず試み1として、エージェントがパッチを生成し、決定論的ツールであるPythonのテストランナーが失敗を返します。
ここで、いわゆる進化フェーズに入ります。オーケストレーターエージェントは、エージェントに対して、失敗の文字列を正確に分析する独立したマークダウンファイルを書き込むよう強制します。LLMは推論し、次元行列の転置が間違っていたという仮説を立てる、次の試行では42行目のみを変更しなければならない、といった具合に結論づけます。
そしてハンドオフが行われます。オーケストレーターは1回目の試みのワーキングメモリを削除します。そして新しい子のソルバーを起動します。このため、Pythonファイルと書き込まれた仮説のマークダウンファイルを渡し、あなたの仕事は特定の進化計画を実行することだけですと指示します。このように厳格なゲートキーピングを行うことで、モデルを物理的なベンチマークにしっかりと適合させることができます。これによりタスクが解決され、他のモデルが失敗したところで、願わくば成功を収めることができるでしょう。
非常にシンプルなデモンストレーションであれば、これが機能することは想像できます。しかし、この方法論を用いて、自然言語の多言語解釈という現実世界の真の複雑さに直面したとしたらどうでしょう。ああ、これはとても興味深いことになりそうです。
論文からの主な発見と検証のズレの問題
そろそろ終わりに近づいてきました。主な発見は何でしょうか。私が本当に気に入っているのは、彼らが、ハーネスは今やファーストクラスオブジェクトになりつつあると述べている点です。LLMの周りのあらゆるものを囲む制御ロジックは、仕事にとってLLMそのものと同じくらい不可欠で、戦略的に重要だということです。したがって、それは何らかの不透明なコードから、実行可能で科学的かつ比較可能なオブジェクトへと抽出されなければなりません。
そこで彼らは人間が読めるテキストという形をとりました。確かに、人間が読めるテキストというのは最適な表現ではないかもしれません。トポロジーやナレッジグラフについて考えてみれば、もっと良いアイデアがあることはお分かりでしょう。
私が気づいた2つ目の興味深いポイントは、検証のズレについてです。彼らは興味深い効果を発見しました。マルチエージェントによる議論や検証の複雑さなど、複雑な評価ループを内部化する場合、成功とは正確に何であるかという内部の検証定義が、環境の外部的な成功定義と完全に一致していないと、これは危険な状態になると彼らは気づきました。なぜなら、アブレーション調査の結果、内部の評価ループがより単純な検証を行っている場合、今後行われる学習は、外部環境のより高いレベルでのグラウンドトゥルースの検証を無視して、その単純な内部検証ステップへとドリフトしていくことが分かったからです。
つまり、大規模な学習バイアスが発生していたわけです。しかし、実行グラフを純粋な自然言語に置き換えることで、私たちは無限の柔軟性を得ることができると思います。人間の言葉で表現できることというのは、本当に素晴らしいものです。
自然言語実行の不確実性と新たなバグの発生
しかし、このアプローチに内在する決定的な限界ではないものの、私自身の考えとしては、実行そのものの確率性こそが問題になると思います。コードは決定的であり、非常に美しいものです。PythonのループでXが5より大きいと記述されていれば、その条件が満たされた場合には完璧に分岐します。
しかし、この新しいエージェントハーネスにおいて、自然言語で、ステージ2で証拠が十分かどうか確認してくださいと記述されていたらどうでしょう。おやまあ、それは一体どういう意味なのでしょうか。証拠という言葉一つとっても、実に多様なデータ構造を意味する可能性があります。十分とは何をもって十分なのでしょうか。単一の数値パラメータなのか、それとも多面的な複雑さを伴うものなのでしょうか。
そのため、オーケストレーターLLMは制約を無視してハルシネーションを起こしながら進んでしまうかもしれません。著者たちが厳格なファイルシステム契約によってこれを軽減しようとしていることは知っています。しかし繰り返しになりますが、複雑な自然言語やコーディングを使うとなると、どうでしょうね。制御フローのロジックに曖昧な自然言語を用いるのは錯覚だと思います。絶対的に純粋な論理において、これは全く予測不可能な新種のランタイムバグを引き起こすことになるでしょう。これがうまくいくかどうか、今後を見守りましょう。
ご覧のように、Anthropicは現在まさにこのハーネスを実装しています。しかし、これが未来の絶対的な叡智と言えるのでしょうか。私はそうは思いません。
今後のアーキテクチャへの疑問と結論
では、新しい方法とは何でしょうか。皆さんには何を持ち帰っていただきたいか。新しい方法として、エージェントハーネスのテキストファイル、つまりskill.mdファイルには契約が含まれています。役割は親オーケストレーターであり、ステージ1では何かを解決するために子エージェントを立ち上げてコードを生成させ、ワークスペースにあるsolution.pyへのパスを定義します。
ステージ2はシンプルに監査と検証です。厳格な監査用の子エージェントを立ち上げ、解決ファイルのみを読み込ませます。もしファイルが例えば5,000文字を超えていた場合、監査エージェントは私たちが愛用するGPT-4oのコンテキストウィンドウを圧迫しないように、リファクタリングして要約されたバージョンで上書きしなければなりません。
さて、どう思われますか。AIを全く信用しないと宣言することがAIの未来なのでしょうか。AIが生成するもの、あるいはAIに入力するすべてのものを外部のファイルシステムに配置し、そのファイルシステム内ですべてを自然言語で保持する。そうすれば確かに、人間がさまざまなステップを踏むように、美しくデバッグを行うことができます。
しかし、これこそが本当に私たちがAIのためにベクトル表現やテンソル表現を用いて構築してきた数学的空間なのでしょうか。AIの内部で起こっていることは望まないからといって、すべてを外部のファイル構造に書き出し、それを再び読み込み直すという、あらゆる推論ステップに対して事実上のRAGアーキテクチャを構築することが、本当に未来なのでしょうか。これが未来のアーキテクチャだと確信することはできないはずです。
しかし、皆さんはどう思いますか。この動画を少しでも楽しんでいただけたなら幸いです。新しい情報もありましたし、現在AI研究のコミュニティで何が起きているのか注目してみてください。驚かされることもあれば、頭を掻きながら、これがそうなのかと戸惑うこともあるでしょう。
そして、この動画の最後まで見てくださった方、聞いてください。LLMの一時的でハルシネーションを起こしやすいアテンションマトリックスではなく、ファイルシステムを権威あるグラウンドトゥルースのシステムとして扱うとしましょう。その意図は十分に理解できます。予測不可能な知能であるLLMに対して、信頼性の高い自己修復可能なソフトウェアシステムのように振る舞うことを強制しているのです。理論上は素晴らしいことです。しかし、ここで何が起きているか分かりますか。考えてみてください。私たちは何を見落としたのでしょうか、あるいは私が見落としたと考えているものは何でしょうか。
そうです。メインのLLMが全く学習していないことにお気づきでしょうか。すべての新しい結果が単に外部のファイルシステムにあるため、すべてを調整するシステムの主要な知能であるメインのオーケストレーションエージェントにとって、新しいアクティブな学習プロセスが存在しないのです。しかし、LLMそのもの、Transformerアーキテクチャのレイヤー内のテンソル構造や、状態メモリを使ったとしても、それらは全く訓練されていません。このアプローチでは、メインのLLMは学習していないのです。
これが私の2つ目の主張であり、さらなるAIシステムの開発において私たちが踏まなければならない、単なる中間ステップに過ぎないのではないかと考えている理由です。しかし、今後どうなるか見守りましょう。明日か数日後には、次世代のAIシステムに向けたさらに興味深いアプローチをご紹介できるかもしれません。
コメント