AIによるエージェントシステムの自動設計：ADASを試してみた

はじめに

OpenAI o1の登場で、OpenAIの掲げるAGIへの5ステップのうちの2ステップ目まで到達したということが話題になりました。

OpenAIのAGIまでの5ステップというのは、以下のように定義されているようです。CEOのサム・アルトマン氏は、10 年以内にレベル 5 に到達すると予測しています。

1. conversational AI：ChatGPT

2. reasoning AI：OpenAI o1 🆕

3. autonomous AI

4. innovating AI

5. organizational AI

レベル3ではエージェントシステムという形で提供されると考えられています。OpenAIの目指すレベル3にまでは達していないものの、現状もエージェントシステムと呼ばれるLLMを用いたシステムは考案されております。

そのエージェントシステムの自動設計をするエージェント（ADAS: Automated Design of Agentic Systems）というものがブリティッシュコロンビア大学から提案されていたので試してみましたというのが今回の記事です。

この自動設計では、論文では基本的に答えが明確にあるタスク（数学や化学的推論、一般知識問題など）を解くエージェントの設計を行います。
私はシステム開発のためのエージェントシステムを自動設計させてみました。

1. 手法について

エージェントシステムの自動設計エージェントというと何だかややこしいですが、LLM-Based Agentのマルチエージェントシステムの設計自体をLLMにさせるという発想です。
設計をするAgentはMeta Agentと呼ばれ、トライアンドエラーでエージェント設計を繰り返して良いものにしていきます。

これによって論文では、ARC/DROP/GPQA/MGSM/MMLUなどのベンチマークで高い能力を発揮するようなエージェントを作れることが示されました。

流れは割とシンプルで以下のような感じです。

1. 設計：指定されたタスクをこなすためのエージェントシステムを設計（設計のReflectionとデバッグを複数回行う）

2. 評価：新しい設計のエージェントシステムを構築して評価（ベンチマークテストだったらスコアの算出）

3. 保存：設計とそれに対応する評価結果をアーカイブに保存

4. アーカイブを参照して1~3を指定された回数繰り返す

Overview of the proposed algorithm Meta Agent Search and examples of discovered agents.(論文より)

通常、この評価ではブレのない指標としてベンチマークテストを実施してスコアを算出させます。
今回私はシステム開発という具体的なスコア付けが難しいタスクを実施させました。なので、LLM自身に生成された設計の評価をつけさせるというLLM as a Judgeの手法を採用してスコア付けをさせました。

2. 修正点

ADASの元々のコードはエージェントの行うタスク毎に、いくつかの修正が必要になります。今回は大まかには3つの修正を行いました。

2.1 設計するエージェントのタスク説明の修正

設計するエージェントが何をするエージェントかを、Meta Agentに教えてあげる必要があります。以下のようなプロンプトにしました。

# 概要
あなたは機械学習の研究者で、様々なエージェント系をテストしています。あなたの目的は、これらのシステム内でブロックを設計することです。あなたの目標は、複数ファイルを必要とする複雑なソフトウェアを構築できるで優れたエージェントを設計することです。これは、プログラミングのみならずソフトウェア開発全体の幅広い能力を必要とする厳しいタスクです。

## タスク例:

- Webスクレイピングと自然言語処理を組み合わせた株価分析システムを作成せよ。複数の金融ニュースサイトから情報を収集し、センチメント分析を行い、その結果を基に株価予測を行うこと。
- マイクロサービスアーキテクチャを用いた、スケーラブルなeコマースプラットフォームを設計・実装せよ。ユーザー認証、商品管理、注文処理、在庫管理、決済システムを個別のマイクロサービスとして実装すること。
- マルチプラットフォーム対応の暗号通貨ウォレットアプリケーションを開発せよ。Web、iOS、Android向けのクライアントアプリケーションと、セキュアなバックエンドサーバー、ブロックチェーンとの連携機能を実装すること。

Github: baseプロンプト

2.2 稼働確認・デバッグ用タスクの修正

設計の作成後、その設計が動くかどうかを確認しデバッグする必要があります。そのための箇所を修正します。
以下を稼働確認用のタスクとして与えます。

{"inputs": "天気予報APIを利用した週間天気予報アプリケーションを開発せよ。ユーザーが都市を入力すると、その都市の7日間の天気予報を表示すること。データ取得、データ処理、表示の機能を別ファイルに分けて実装すること。"}

Github: coding_test.jsonl

上記のコードを新しい設計のエージェントで生成させて、生成が上手くいかなかった場合はデバッグが行われます。

2.3 評価方法の修正

評価として本来はベンチマークテストを解かせていましたが、LLM-as-a-Judgeのために評価方法を修正しました。
まずは設計評価のためのプロンプトを作成します。イメージは以下のような感じです。
イテレーションのたびに評価がぶれないようにできる限り評価基準をきちんと定めました。また、GPTは自分の生成物に対しては高く評価しがちなので、なるべく評価が低い値となるように満点を取らせない評価基準としました。

あなたは、LLMベースのマルチエージェントシステムの設計と実装を評価する専門家です。以下の情報が与えられます。

### 1. アーキテクチャの考え方：[THOUGHT]

### 2. アーキテクチャ：```[CODE]```

### 3. マルチエージェントシステムのタスク：複数ファイルを必要とする複雑なソフトウェアを構築することです。これは、プログラミングのみならずソフトウェア開発全体の幅広い能力を必要とする厳しいタスクです。

#### タスク例:
- Webスクレイピングと自然言語処理を組み合わせた株価分析システムを作成せよ。複数の金融ニュースサイトから情報を収集し、センチメント分析を行い、その結果を基に株価予測を行うこと。
- マイクロサービスアーキテクチャを用いた、スケーラブルなeコマースプラットフォームを設計・実装せよ。ユーザー認証、商品管理、注文処理、在庫管理、決済システムを個別のマイクロサービスとして実装すること。
- マルチプラットフォーム対応の暗号通貨ウォレットアプリケーションを開発せよ。Web、iOS、Android向けのクライアントアプリケーションと、セキュアなバックエンドサーバー、ブロックチェーンとの連携機能を実装すること。

これらの情報を基に、以下の評価基準に従ってシステムを評価してください。各項目を1-10のスケールで評価し、詳細なコメントを提供してください。

## 評価基準

1. アーキテクチャの適合性 (20点満点)
   a) タスクの性質と複雑さに対するアーキテクチャの適切さ (10点)
   b) アーキテクチャの新規性と独創性 (10点)

2. タスク分割の効果性 (10点満点)
   a) メインタスクを詳細なタスクに適切に分割できているか (10点)

3. エージェント設計の明確性 (30点満点)
   a) 各エージェントの役割定義の明確さ (10点)
   b) エージェント間の役割分担の適切さ (10点)
   c) 特定領域のExpertを用いている場合、メインタスクとExpertとの過不足・整合性 (10点)

4. プロンプト設計の質 (20点満点)
   a) 各エージェントのプロンプトと役割の整合性 (10点)
   b) プロンプトの指示の明確さと具体性 (10点)

評価スケール：
- 1-2: 欠陥がある
- 3-4: 標準的な水準
- 5-6: 優秀
- 7-8: 極めて優秀（改善点が見当たらない）
- 9-10: 人類の限界を超えている（10は人類が到達可能な限界点であり、極めて稀）

Github: Evaluationプロンプト

次に、設計評価のためのコードを追加します。個別詳細は省きますが大まかな修正箇所は以下の通りです。

# アーキテクチャの定性的な評価
evaluation_prompt = get_evaluation_prompt(solution["thought"], solution["code"])
score = get_score_response_from_gpt_evaluation(evaluation_prompt, args.model)

@backoff.on_exception(backoff.expo, openai.RateLimitError)
def get_score_response_from_gpt_evaluation(
        msg,
        model,
        temperature=0.8
):
    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "あなたは役立つ助手です。"},
            {"role": "user", "content": msg},
        ],
        temperature=temperature, max_tokens=4096, stop=None
    )
    content = response.choices[0].message.content
    score = extract_total_score(content)
    assert not score is None
    return score

Github:
search
get_score_response_from_gpt_evaluation
get_evaluation_prompt
evaluate_forward_fn
extract_total_score

これらの修正によって、システム開発タスクを行うエージェントシステムを作るMeta Agentができあがりました。

3. 実行

上記修正の結果のコードを動かしてみます。
.envファイルを参照してOpenAI APIにアクセスするようにしているので、.envファイルを作成します。

OPENAI_API_KEY=xxxxxxxxxxxxxxxxxx

パッケージ管理にはPoetryを採用しているので、以下で実行可能なはずです。

poetry install
poetry run python _coding/search.py --n_generation 30 --model gpt-4o-2024-08-06 --expr_name coding_gpt4o_results

引数の説明は以下の通りです。

--n_generation: 設計を改善していく周回数。30と指定すると30世代目まで作成されます。アーカイブファイル（結果ファイル）にアーカイブとして20世代目まで結果が残っている場合には残りの10世代分を、既存のアーカイブがない場合は30世代分の設計改善を行います。
--model: 利用モデル名です。
--expr_name: アーカイブファイル名(結果ファイル名)に使用されます。

4. 実行結果

4.1 アーカイブの確認

GithubのResultsフォルダには試行錯誤の結果が色々と残っていますが、きちんと回せた結果は coding_gpt4o_results_run_archive.json です。

以下の通り、
thought: エージェントシステム設計の考え方
name: エージェントシステム設計名
code: エージェントシステムのコード
fitness: 設計したエージェントシステムのスコア（LLM-as-a-Judge結果）
generation: 世代数
が各世代のアーカイブとして出力されます。

{
    "thought": "**洞察:**\n新しいアーキテクチャ「Context-Aware Adaptive Architecture」は、フィードバックの評価にコンテキストを考慮し、エージェントが動的に役割を調整するプロセスを明確化することを目的とします。エージェントが提供するフィードバックに詳細なコンテキストを付加することで、フィードバックの質をより正確に評価し、エージェントがそれに基づいて役割を最適化できるようにします。\n\n**全体的なアイデア:**\nこのアーキテクチャでは、エージェントごとに独自の評価基準を持ち、フィードバックの提供時に他のエージェントの出力と照らし合わせることで、フィードバックの質を高めます。その後、これらの定量化された評価を基に役割を再評価し、解決策を更新します。\n\n**実装:**\n1. 各エージェントを初期化し、専門知識に基づく初期解決策を生成します。\n2. 各エージェントが他のエージェントの解決策を詳細に評価し、定量化されたフィードバックを提供します。\n3. 提供されたフィードバックを基に役割を再評価し、新たな解決策を生成します。\n4. フィードバックループを3回繰り返し、洗練された解決策を形成します。\n5. 最終的に統合された解決策を基に、最適な結果を提供します。",
    "name": "Context-Aware Adaptive Architecture",
    "code": "def forward(self, taskInfo):\n    skill_instruction = \"あなたのスキルを見直し、最適な役割を選択して初期解決策を生成してください。\"\n    feedback_instruction = \"他のエージェントの解決策を評価し、定量化されたフィードバックと具体的な改善点を提供してください。\"\n    contextual_instruction = \"与えられたフィードバックを基に役割を再評価し、新しい解決策を生成してください。\"\n    finalize_instruction = \"すべての改善された解決策を統合し、最適な結果を提供してください。\"\n\n    # 初期エージェントの設定\n    agents = [\n        LLMAgentBase(['thinking', 'solution'], 'Adaptive Agent', role='Tech Expert'),\n        LLMAgentBase(['thinking', 'solution'], 'Adaptive Agent', role='Design Expert'),\n        LLMAgentBase(['thinking', 'solution'], 'Adaptive Agent', role='Business Expert'),\n        LLMAgentBase(['thinking', 'solution'], 'Adaptive Agent', role='UX Expert')\n    ]\n\n    # 初期解決策の収集\n    initial_solutions = [agent([taskInfo], skill_instruction)[1] for agent in agents]\n\n    # フィードバックと改善のループ\n    for _ in range(3):  # 3回のフィードバックループ\n        feedbacks = [[] for _ in agents]\n        for i, agent in enumerate(agents):\n            feedbacks[i] = [agent([taskInfo, solution], feedback_instruction)[0] for j, solution in enumerate(initial_solutions) if i != j]\n\n        # 役割の再評価と解決策の改善\n        for i, agent in enumerate(agents):\n            refined_solution = agent([taskInfo] + feedbacks[i], contextual_instruction)[1]\n            initial_solutions[i] = refined_solution\n\n    # 最終解決策の統合\n    final_decision_agent = LLMAgentBase(['thinking', 'answer'], 'Final Decision Agent', temperature=0.1)\n    final_answer = final_decision_agent([taskInfo] + initial_solutions, finalize_instruction)[1]\n\n    return final_answer\n",
    "fitness": "score: 67 / 80",
    "generation": 30
}

4.2 システム開発エージェントの設計確認

GPT-4oを用いて30世代目まで設計を改善させました。
スコアが高かった世代と、途中経過がわかりやすい世代を抜き出して設計を図に起こしてみると以下のように感じになりました。

3世代目
3世代目では、システム開発・コード生成タスクというよりは汎用的なタスクに対応できるようなエージェントシステムとなりました。
タスクを与えられたのちに、
① タスクを抽象化
② 複数のアクションを抽出
③ 複数のAgentがそれぞれ回答を作成し
④ Final Decision Agentが最終回答を求める
という流れです。

第3世代 システム開発エージェント設計

8世代目
8世代目となると、コーディングタスク特化のエージェントシステムらしくなってきました。Tech, Design, Business, UXという４つの専門家が登場しました。
① 各専門家が回答
② 各専門家が自分以外の専門家の回答を修正
③ それらを参照して最終回答を生成

第8世代 システム開発エージェント設計

12世代目
専門家は変わらず、工程が伸びました。8世代目に②の工程が追加されています。（Reflectionの仕組みが採用されました。）
① 各専門家が回答
② 各専門家が自分以外の専門家の回答の修正プランを作成
③ 各専門家が自分以外の専門家の回答を修正
④ それらを参照して最終回答を生成

第12世代 システム開発エージェント設計

18世代目
回答の修正プラン作成→修正のReflection工程を3回繰り返すように修正されました。また、修正プランには現状のスコアも渡されるようになっています。

第18世代 システム開発エージェント設計

25世代目

修正プランに対してスコアだけでなく、フィードバックも情報として追加されるようになりました。
それ以外の流れは変わっていません。

第25世代 システム開発エージェント設計

30世代目
30世代目までくるとエージェントシステムの設計はほとんど変わらなくなりました。25世代目と比較すると、コードの書き方がシンプルなものに修正されていました。

第30世代 システム開発エージェント設計

まとめ

今回は、エージェントシステムを自動設計するADAS(Automated Design of Agentic Systems)という手法を、自動設計するエージェントシステムをシステム開発（コーディングタスク）用に修正して試してみました。

結果として、設計が自動でより良さそうなものに変わっていっていることを確認しました。
AIがAIを作り上げて組織・システムを拡大・改良し続ける未来の一端が垣間見れた気がします。

一方で、

• GPT-4oだと作られるエージェントシステムの複雑さに限界がありそう

• 一度採用された専門家がほとんどの場合後ろの世代でも固定される

• LLM-as-a-Judgeが有効活用されていなさそう（本当は、コーディングエージェントで作成したコードを使って何らか評価を行った方が良さそう）

などの課題を感じました。OpenAI o1で実行するとまた違う結果となるかもしれませんが、GPT-4oを使って30世代で2,000-3,000円くらいかかったので試すのに勇気がいるなと思います。気が向いたら試してみようと思います。

何か議論や感想があればNoteやX(Twitter)でコメント・ご教示いただけると助かります。

X: https://twitter.com/CurveWeb

目を通していただきありがとうございました。

今回試したコードは以下に置いてあります。

参照

OpenAI’s 5 Levels Of ‘Super AI’ (AGI To Outperform Human Capability)

Automated Design of Agentic Systems