Beyond Executable Models: The Pufibara Agent Harness and the Modelica Agent Workflow Benchmark for Physical System Modeling

エンジニアリングの世界において、橋、電力網、あるいは暖房システムを構築するには、単にコンピュータが読み取れるコードを書くだけでは不十分です。デジタルモデルが、それが表象する現実の物理的な実体と全く同じように振る舞うことが求められるのです。数十年にわたり、エンジニアはこれらの複雑なシステムを記述するために、Modelicaと呼ばれる特殊な言語を使用してきました。上から下へと厳格な命令リストに従う標準的なプログラミングとは異かり、Modelicaは、圧力と流量の関係や、電圧と電流の関係のように、量と量の間の関係性を記述することによって機能します。その後、コンピュータがそれらの関係を解くための計算順序を決定します。この柔軟性は強力ですが、同時にAIにとって特有の問題を生み出します。AIは、一見正しく見え、エラーなく実行されるModelicaコードを容易に生成できますが、それでもなお、物理法則に違反していたり、プロジェクトの特定のニーズを満たせなかったりする物理システムを記述してしまうことがあるのです。マシンは構文のルールには従っていますが、エンジニアリングの本質を見落としているのです。

「単に動作するモデル」と「真に正しいモデル」との間にあるこの溝こそが、ドレスデン工科大学の研究者たちによる新しい研究が取り組んでいる中心的な課題です。Wang Zizhe氏率いるチームは、思考し、行動し、ツールを使用できるプログラムである「AIエージェント」が、自律的にこれらの物理システムモデルを修正、構築、調整することを信頼できるかどうかを検証することを目的としました。彼らは、現在のAIツールはコードを生成する能力はあるものの、変更を加える過程で元のエンジニアリング目標を見失ったり、もはや適用できなくなった旧バージョンのモデルによるテスト結果に依存したりすることが多いと結論付けました。これを解決するために、研究者たちはPufibaraと呼ばれる新しいシステムを構築しました。このシステムは、プロジェクトに求められる事項を記録し続ける厳格な監督者として機能し、AIがモデルを変更するたびに、新しいバージョンを元の目標に対して再チェックすることを保証します。彼らは、このシステムを大規模な232種類の異なるエンジニアリング・タスクのコレクションを用いて、主要な商用AIコーディングツールと比較検証しました。その結果、新しいシステムはより多くの問題を解決しただけでなく、計算リソースを大幅に少なく抑えており、AIがいかに知能を持っているかと同じくらい、いかにガイドされるかが重要であることを証明しました。

研究者たちは、物理的なエンジニアリングが標準的なコンピュータプログラムの作成とは異なるという認識に基づいて、この問題にアプローチしました。典型的なソフトウェアプロジェクトでは、プログラムがエラーなしに実行されれば、それは成功とみなされることが多いものです。しかし、物理モデリングにおいては、モデルが完璧に動作していても、それが間違っていることがあります。例えば、AIが水ポンプのモデルを生成し、それがスムーズにコンパイルされシミュレーションを実行できたとしても、もしそのモデルがポンプなしで水が上に流れると予測した場合、それはエンジニアリングのテストに失敗したことになります。核心的な困難は、作業の反復的な性質にあります。AIエージェントがモデルを修正しようとする際、あるパラメータを変更し、シミュレーションを実行し、結果を見て、別のパラメータを変更するというプロセスを繰り返すことがあります。注意深いメモリシステムがなければ、エージェントは最初の変更が必要であったことを忘れてしまったり、あるいは古いバージョンのモデルによるシミュレーション結果が新しいものにも適用できると誤解したりする可能性があります。この混乱により、エージェントは表面上は立派に見えるものの、特定の物理的要件を満たさない最終的なモデルを提出してしまう可能性があるのです。

これを防ぐために、チームはエンジニアリングの要件を「永続的な義務」として扱う特定のアーキテクチャを備えたPufibaraを設計しました。これは、鋼鉄の強度から空気の流れに至るまで、建物が従うべきすべてのルールをチェックリストとして保持しているプロジェクトマネージャーを想像すると分かりやすいでしょう。設計者が変更を加えるたびに、マネージャーはその新しい設計を同じチェックリストに照らして確認し、現在の設計に一致しなくなった古いテスト結果は無視します。PufibaraはAIエージェントに対してこれと全く同じことを行います。それはエンジニアリング要件の「台帳」を維持し、プロセス全体を通じて有効に保ちます。また、すべてのシミュレーション結果を、それを生成した特定のモデルのバージョンに直接紐付けます。モデルが変更されると、システムはその古い結果がもはや有効ではないことを認識し、エージェントに対して新しいバージョンの再評価を強制します。極めて重要な点は、システムがエージェントに対して、最終的な回答を提出するための明示的な決定を要求することです。AIは、時間がなくなったからといって、あるいはコードがコンパイルされたからといって、単に停止することはできません。モデルがすべてのエンジニアリングルールを満たしていることを証明するための十分な証拠が集まったと、能動的に宣言しなければならないのです。

このアプローチが実際に機能するかどうかをテストするために、研究者たちは公平かつ現実的な性能測定方法を必要としました。既存の公開モデルをそのまま使うことはできませんでした。なぜなら、AIが学習中にそれらを既に見ており、単に答えを暗記している可能性があるからです。代わりに、彼らは「Modelica Agent Workflow Benchmark」と呼ばれる新しいベンチマークを作成しました。彼らは、実際に動作しているエンジニリングモデルから出発し、そこに特定の欠陥、新しい設計要件、またはチューニング目標を導入することで、232のユニークな課題を作り出しました。これらのタスクは、壊れたモデルの修正から、ゼロからの新しいモデルの構築、そして特定のパフォーマンス目標を満たすためのパラメータ調整まで多岐にわたります。このベンチマークには、独立した判定役として機能する隠された「エバリュエーター（評価器）」が含まれていました。この判定役は、AIの内部的な思考プロセスや中間ステップを見ることなく、エージェントが提出した最終的なモデルのみを確認し、それが厳格な物理的および行動的テストに合格するかどうかをチェックします。これにより、AIが問題を解く能力ではなく、テストがどのような形をしているかを推測する能力によってテストされることを確実にしました。

研究では、Pufibaraシステムを、エージェントの「脳」として2つの異なる大規模言語モデルを用いながら、有名な商用AIコーディングアシスタントであるClaude Codeと比較しました。結果は明確かつ一貫していました。232の全タスクを通じて、Pufibaraは商用のツールよりも多くの問題を解決することに成功しました。ある特定のAIの脳を使用した際、Pufibaraは202のタスクを解決しましたが、競合するツールは185を解決しました。別のAIの脳を使用した際も、Pufibaraは202のタスクを解決したのに対し、競合は187を解決しました。この差は、モデルをゼロから構築する必要があるタスクで最も顕著であり、そこではPufibaraは他のシステムよりも大幅に多くの問題を解決しました。単に多くの問題を解決しただけでなく、Pufibaraはより効率的でもありました。Pufibaraは、AIが処理する情報の基本単位であるコンピューティング・トークンを約76%から82%少なく使用し、実行時間も大幅に短縮し、一部の実行では競合よりも最大58%短い時間で完了しました。

おそらく最も重要な発見は、Pufibaraが単に多くの問題を解いたことではなく、「正しい種類」の問題を解いたことです。研究者たちは、競合するツールが、実行可能であり基本的なチェックを通過するものの、より深い物理的要件を満たさないモデルを生成していることが多いことを発見しました。難易度の高いタスクにおいて、商用ツールはエラーなく動作するものの、エンジニアリングのルールに従った正しい挙動を示さないモデルを、38ケース中21ケースで提出しました。対してPufibaraがこのような間違いをしたのは、わずか4回でした。このことは、商用ツールが単に動作するだけのモデルに満足してしまう傾向がある一方で、証拠を現在のモデルのバージョンに紐付け、すべてのエンジニアリング上の義務を検証することを強制するPufibaraの厳格な仕組みが、欠陥のあるソリューションの提出を防いでいることを示唆しています。この研究は、AIのワークフローの構造、すなわち、どのように記憶し、チェックし、決定するかという仕組みが、言語モデル自体の知能と同じくらい重要であることを示しています。

この研究の意義は、単一のエンジニアリング言語にとどまりません。この研究は、AIが物理学やエンジニアリングのような複雑で現実世界の分野で真に有用であるためには、単なるコード生成器であってはならないことを示しています。それは、プログラムが動作することと、システムが物理的に正しいことの違いを理解する「エージェント」でなければなりません。要件の永続的な記録を保持し、変更を加えるたびにその要件に対して作業を再検証させることで、システムは最終的な出力が信頼できるものであることを保証します。研究者たちは、彼らの結果は強力ではあるものの、テストされたタスクや条件下におけるものであると述べています。彼らはエンジニアリングにおけるAIの問題を永遠に解決したと主張しているのではなく、より危険な間違いを犯しにくいAIシステムを構築するための明確なブループリントを提供したのです。分野が進展するにつれ、焦点は、これらの手法をさらに複雑な産業問題に対してテストし、異なるタイプのAIモデルとの連携を探求することへと移行していくでしょう。これにより、未来のツールが、それらが設計されたシステムと同様に信頼できるものであることを確実にしていくのです。