EvoUndo:自己進化するLLMエージェントに安全な復元性を与える
導入
LLMエージェントが自分のプロンプト、ツール、ミドルウェア、リソース、実行ハーネスを変更できれば、能力を高められる可能性があります。しかし、性能を改善する変更が、そのまま安全な変更になるわけではありません。変更が永続的な影響を残した場合、作成時の状態では機能した復元手順が、環境の変化後には使えなくなることがあります。
EvoUndoはこの問題を、単なる修正生成ではなく「別の状態に移った後も、変更を検証可能な形で元に戻せるか」という観点から扱います。変更の表現、復元手順の合成、失敗診断、独立した検証を一つの枠組みにまとめ、反実仮想的な状態を含めて評価します。
主な結果
- 未知の一回限りの自己進化タスク600件から、能力は向上したものの復元性検証に失敗した変更を197件確認しました。
- 元の復元表現と一般的な修復戦略では、これらの自然な失敗を1件も復元できず、結果は0/197でした。
- 決定論的なオラクル分析では、元の復元言語L0で48/197件を復元できました。拡張された復元計算体系では、経験的なオラクル復元数が191/197件まで増加しました。
- プロトコルを固定した2×2介入により、状態アドレスの正確さと、復元言語の表現力という二つのボトルネックを分離しました。
- 元の言語で十分なケースでは、正確なアドレス診断を追加することで、成功率が0/48から38/48、79.2%へ上昇しました。オラクルが定義したS1層では、言語の拡張により142/143件、99.3%を復元できました。
- 主なgpt-oss-120b実験では、豊かな復元言語に正確なアドレス診断を加えた結果は133/143、93.0%でした。Qwen3.8-27Bの再現実験では、状態特定と表現力の効果は保たれましたが、この負の相互作用は再現されず、モデル依存の現象であることが示唆されます。
意義
EvoUndoが示すのは、自己進化を「より良い変更を作れるか」だけで評価するのは不十分だということです。安全なエージェントには、変更が作用した状態を正確に指定する仕組み、復元を裏付ける証拠の意味論、複雑な取り消し操作を記述できる言語、そして結果を独立に確認する検証器が必要です。
エージェント基盤の設計では、変更APIだけでなく、状態アドレス、復元操作、証拠の扱い、検証プロトコルを同時に設計する必要があります。評価側も、一度の能力向上だけでなく、その後の状態変化や反実仮想的な条件で安全に戻れるかを測るべきです。
また、gpt-oss-120bとQwen3.8-27Bの差は、診断情報と復元言語の組み合わせがモデルごとに異なる結果を生む可能性を示します。結局、信頼できる自己進化には、能力向上と復元性を別々の後付け機能として扱わず、一体のシステム要件として設計することが求められます。
コメント
ログイン状態を確認中…
コメントを読み込み中…