評価駆動型エージェント開発：感覚でプロンプトを調整するのをやめた理由

プロンプトを変更した。次の実行結果は良くなった。その変更が役に立ったのか、それとも単に運が良かっただけなのか？

長い間、私の答えは「そう思う」でした。コマンドを微調整し、パイプラインを実行し、成功するのを見届けて、そのままリリースする。これが「感覚ベースのエンジニアリング（vibes-based engineering）」です。エージェントを構築しているほぼ全員がこれを行っています。なぜなら、それ以外の方法は難しく感じるからです。

しかし、コーディングエージェントは非決定論的です。同じタスクを2回実行しても、異なる結果が得られることがあります。一度の成功だけでは何も分かりません。変更が機能したのか、それとも単にサイコロの目が良かっただけなのかを判断することはできないのです。

私はこれを、機械学習の規律（discipline）を取り入れることで解決しました。システム全体を包み込む評価フレームワークを構築したのです。

フレームワークの仕組みは以下の通りです：

• Target（ターゲット）: 固定されたコードベース。スコアを比較可能にするため、これは変更しません。 • Task（タスク）: プロンプトとオラクル（正解）を持つ特定のベンチマーク項目。 • Oracle（オラクル）: 決定論的なチェック。これらはパスしなければならないシェルコマンドです。 • Variant（バリアント）: テスト対象となる具体的な変更（新しいプランナーなど）。 • Trial（トライアル）: 単一の実行。ランダム性を考慮するため、すべてのタスクを複数回実行します。

異なる種類の失敗を捉えるために、2種類のスコアリングを使用しています：

• Code Graders（コード・グレーダー / 決定論的）: テストの合格率、コスト、時間、およびファイルの変更を確認します。
• LLM Judge（LLMジャッジ / 確率論的）: 別の固定されたモデルが、仕様の品質と実装の忠実度をスコアリングします。

コード・グレーダーはコードが動作するかを教えてくれます。ジャッジはコードが良いかどうかを教えてくれます。両方が必要なのです。

また、平均値を使うのもやめました。平均値はエージェントの実態を誤魔化します。タスクが3回中2回成功すれば、一見良さそうに見えます。しかし、それは信頼できるとは言えません。代わりに、私は2つの指標を使用しています：

• pass@k: エージェントは少なくとも1回成功したか？（能力）
• pass^k: エージェントは毎回必ず成功したか？（信頼性）

pass^kの向上こそが真の勝利です。それは、エージェントが単に運が良かったのではなく、一貫性を持てるようになったことを意味します。

システムを研ぎ澄ませ続けるために、深い理解を必要とする難易度の高いタスクを追加しています。エージェントが実際のバグで失敗したとき、その失敗を恒久的なタスクへと変えます。これにより、クローズドループが形成されます。エージェントが向上するにつれて、ベンチマークもより難しくなっていきます。

このインフラ構築には多大な労力がかかりますが、私が構築した中で最もレバレッジの効くものです。「これで良くなったと思う」を、「コストを抑えつつ、信頼性が20%向上した」という言葉に変えてくれました。

コーディングエージェントはデモをするのは簡単ですが、信頼を得るのは困難です。デモの段階を超えたいのであれば、「測定する」と決意しなければなりません。

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi