AI システムが間違いから回復し、最適なソリューションを見つけるのに役立つ新しいフレームワーク

消費者向け AI システムを使用している場合は、AI の「ブレイン フォグ」のようなものを経験したことがあるでしょう。会話にかなり夢中になっているのに、突然 AI が、あなたが話していたさまざまなアイデアとそれらがどのように組み合わされているのかを見失ったように見えます。

プログラマーが「エージェント」、つまり特定の複数ステップのタスクを解決するために大規模言語モデル (LLM) と記号コンピューター プログラムを使用するシステムを構築するときにも、同じ問題が発生します。このようなプログラムが一定のサイズに達すると、つまりコードが多くのステップを含む決定を行うようになると、LLM はほぼ必然的にエラーを発生します。

同窓生によって設立された企業 Asari AI が率いる科学者チームは、カリフォルニア工科大学とマサチューセッツ工科大学の研究者とともに、プログラマーがエージェントのコア ロジックを書き換えることなく、エージェントを改善して間違いを減らし、エラーから迅速に回復できるようにする新しいフレームワークを開発しました。 EnCompass と呼ばれるこのフレームワークを使用すると、プログラマはエラーが発生したときに簡単に後戻りし、さまざまな検索戦略、つまりコードを通じて考えられるさまざまな実行経路に沿って検索する方法をテストすることができます。研究者たち 提示された EnCompass の 第 39 回神経情報処理システム年次会議 (NeurIPS) 先月サンディエゴで。

「医療から政府、工学設計に至るまで、社会が直面する最も困難な問題に取り組むことができる AI システムを開発したいのであれば、AI システムの中核となるロジックを整理するためのより優れたツールが必要です」とカリフォルニア工科大学のコンピューティングおよび数理科学の教授である Yisong Yue 氏は述べています。 「EnCompass フレームワークは、エージェント ロジックがより複雑になる中、AI エージェント プログラマーがクリーンなコード構成を維持できるようにするための重要なステップです。」

重要なのは、AI エージェントは、ワークフローを通じて膨大な数の潜在的な経路を持つ大規模なニューラル ネットワークを使用していることです。推論の各ステップでさらなる不確実性が忍び込み、小さなエラーが蓄積していきます。

「初期の推論ステップで犯した間違いがすぐに悲惨な結果につながるわけではないかもしれませんが、そのような間違いはさらに重なり、最終的には失敗につながります」と、Asari AI の創設者兼 CEO で Yue の元大学院生である Stephan Zheng 博士は言います。

プログラムが有効な解決策を見つけることを保証するために、プログラマーは、バックトラックするタイミングを指示し、エラーが発生していないことを確認する決定点のルールを含む、複雑なループを使用するコードを作成する場合があります。しかし、エージェントが複雑になるにつれて、この「ハードコーディング」は非常に面倒になります。

「その結果、反復や実験に抵抗するモノリシックなシステムが生まれます。これはまさに、LLM を使用してエージェントを構築するときに望ましくないものです」と Zheng 氏は言います。

EnCompass を使用すると、エージェントは機敏さを保ちながらエラーから迅速に回復できます。プログラマーは、ロジックをハードコーディングするのではなく、再検討する可能性のある意思決定ポイントを「分岐点」としてマークし、特定のパスの有用性を評価するのに役立つ場所を「スコア」としてマークします。これらの単純なアノテーションを導入することで、EnCompass はエージェントのコア ロジックをその検索戦略から切り離し、プログラマがコードを大幅に書き直すことなく、さまざまな検索戦略を簡単に実験できるようにします。

プログラマーがコードのリポジトリを、あるプログラミング言語 Java から Python などの別のプログラミング言語に翻訳したいと考えていると想像してください。 LLM を使用して各 Java 関数 (コードのブロック) を Python に変換し、変換が成功したかどうかをテストする場合があります。

エージェントをテストするために、プログラマは、プログラムが答えに到達するまでにたどる可能性のあるさまざまなパスを調べ、結果を評価したいと考えます。プログラマは、ある実行では、プログラムがポイント A で変換が間違っているパスをたどる一方、別の実行では、ポイント B で別の関数の誤った変換が原因で、ポイント C で関数が正しくない分岐パスをたどることに気づく場合があります。

「まれに、LLM がすべてのステップで正しく翻訳を行って成功する、プログラム内で 1 つまたは 2 つのパスが存在します。これらは、プログラマーがプログラムに理想的にとらせたいパスです」と、EnCompass に関する論文の主著者であり、Zheng 氏の下で Asari AI でインターンをした MIT 大学院生の Zhening Li 氏は述べています。

最適な経路を見つけるために、プログラマは 1 つ以上の検索戦略に従うコードを作成します。すべての経路の合計は、段階的な分岐に沿ったノードに出力を持つ分岐ツリーとして表すことができます。

最も単純な検索戦略は、LLM を使用して「グローバル ベストオブ N」ソリューションを見つけることです。これには、エージェントを複数回実行し、最良の結果を選択することが含まれます。視覚的には、各実行はツリーの頂上から一番下まで直線的なパスのように見えます。

より微妙な検索戦略は、コードの各ステップでエージェントがそのステップを複数回試行し、最良の結果を選択してから次に進み、後続の各ステップでプロセスを繰り返す「ローカルのベストオブ N」ソリューションを探すことです。選択したパスは、枝分かれした木を下る途中でジグザグを描く場合があります。

「しかし、これらの検索戦略を実装するには、通常、それらをエージェントのコア ロジックに組み込む必要があります」と Li 氏は言います。つまり、プログラマーは、別の検索戦略を試したいたびに、戻って大きなセクションを書き直す必要があります。さらに、より高度な戦略は実装が面倒で、コードの可読性が低下します。

「EnCompass を使用すると、さまざまな検索戦略を迅速かつ簡単に試すことができます」と Li 氏は言います。 「つまり、最もパフォーマンスの高い戦略を効率的に見つけることができるのです。」

全体として、研究者らは次のことを発見しました。 エンコンパス 検索の実装に必要なコードの量を 80% 削減できます。エージェントを使用してリポジトリを Java から Python に変換するという特定のケースで、EnCompass は最適な検索戦略を評価し、ノードからの追加分岐を伴うビーム検索と呼ばれる戦略では、新しいフレームワークなしで同じ検索を実行するのに必要なコード行数 423 行に対して 75 行のコードが必要であると結論付けました。同時に、ビーム検索により、いくつかの異なるリポジトリでエージェントの精度が 15% から 40% に向上しました。

MITのArmando Solar-Lezama氏はLi氏の大学院顧問であり、この論文の追加執筆者でもある。