ある変更がエージェントを良くしたのか悪くしたのかに数値をつけられないなら、あなたはそれをエンジニアリングしているのではなく、余計な手順を踏んで推測しているだけだ。エージェントプロジェクトが停滞する最もよくある原因はモデルの弱さではなく、評価ハーネスの不在だ。それがなければ、プロンプトの微調整もツールの変更もモデルの入れ替えも、誰かが少数の出力を眺めて「良くなったっぽい」と宣言することで評価されることになり、それはリグレッションをリリースしてからユーザーに気づかされるやり方だ。スコアボードはエージェントより先に存在しなければならない。採点できないものは改善できないからだ。

捉え直し方はこうだ。評価セットは確率的なコードのためのテストスイートだ。テストのないサービスをリファクタリングして、見た目が問題なさそうだからという理由だけでリリースすることはしないはずだ。エージェントはそのサービスよりも理由づけが難しい存在であり、易しいわけではない。だからこそスコアボードをより必要とするのであって、より不要になるわけではない。

エージェントより先にハーネスを構築する

評価ハーネスは地味で、最初は小さく始まる。代表的な入力のセット、それぞれに対する良い出力の定義、そして現在のシステムをそのすべてに対して実行してスコアを得る手段だ。実際の、あるいは想定されるトラフィックから引いた20〜50個の実例は、千個の合成例よりも優れている。ポイントは固定のものさしを持つことであり、それによって「エージェントを改善した」という主張が、感覚ではなく検証可能な主張になる。

ハーネスが存在すれば、ワークフローは逆転する。すべての変更、新しいプロンプト、新しいツール、新しいモデルは、まずハーネスに対して実行される。スコアを上げる変更はリリースされ、下げる変更は、どれだけ賢く見えてもリリースされない。Bedrockでは、Model Evaluationがこのための管理された経路を提供し、自動メトリクスと人間によるレビューを備えており、必要になるずっと前に一般提供が始まっている。ツールそのものよりも重要なのは規律だ。採点してから決める。

LLM-as-a-judge、そしてそれが嘘をつく場所

オープンエンドな出力を手作業で採点するのはスケールしないため、標準的なやり方はモデルを審査員として使うことだ。強力なモデルに入力、エージェントの出力、ルーブリックを与え、採点させる。Bedrock Model Evaluationはまさにこれをサポートしている。これは本当に有用であると同時に、誤りうるコンポーネントでもあり、審査員がきれいな数字を吐き出し始めた瞬間にチームはそのことを忘れがちだ。

審査員には予測可能な失敗モードがあり、それを見越して設計しなければならない。

  • 位置バイアスと冗長性バイアス。審査員は正しさとは無関係に、最初に示された選択肢や、より長く自信ありげな答えを好む傾向がある。順序をランダム化し、長さを制御すること。
  • 自己優遇。同じモデルファミリー出身の審査員は、自分のファミリーの出力を高く評価しがちだ。重要な場面では、テスト対象のモデルとは異なるファミリーの審査員を使うこと。
  • ルーブリックのドリフト。「この答えは良いか」のような曖昧なルーブリックは、曖昧で不安定なスコアを生む。「答えはポリシーの該当箇所を引用しているか、その引用箇所は正しいか」のような具体的なルーブリックは、行動に移せるスコアを生む。
  • 間違った答えへの自信ありげな同調。入力に誤った前提が含まれている場合、審査員はそれに乗っかった出力に報酬を与えてしまうことがある。正しい振る舞いが拒否や訂正であるような敵対的なケースを含めること。

審査員は正解そのものではない。小さな人手ラベル付きセットに対して較正する、正解の高速で安価な近似にすぎない。そのセットで審査員と人間の判断が食い違うなら、残りを審査員に任せる前にルーブリックを直すこと。

答えだけでなく軌跡を採点する

エージェントに特有の話として、最終的な答えは気にすべきことの半分にすぎない。エージェントは間違った経路で正しい答えにたどり着くことがある。呼ぶべきでないツールを呼んだり、2ステップのタスクに10ステップを費やしたり、途中でログにデータを漏らしたりしながらだ。出力だけでなく軌跡も評価すること。想定されたツールを使ったか。許可された行動の範囲内に留まったか。まともなステップ数で完了したか。触れるはずのなかった削除APIを呼びながら正しい答えにたどり着いたエージェントは、最終的なテキストが何と言っていようと、評価には失敗している。

結論

順番は交渉の余地がない。まず評価ハーネス、次にエージェントだ。ハーネスとは、定義済みの良い出力を持つ実際の入力からなる小さく固定されたセットであり、繰り返し使えるスコアであり、すべての変更を雰囲気チェックから測定済みの決定へと変える。採点をスケールさせるためにLLM-as-a-judgeを使うが、それを誤りうるコンポーネントとして扱うこと。バイアスを制御し、具体的なルーブリックを与え、人間のラベルに対して較正すること。結果だけでなく経路を採点すること。採点できないものはリリースできず、信頼できるエージェントをリリースしているチームは、プレイヤーを作る前にスコアボードを作ったチームだ。

次に読む

評価をデリバリーパイプラインに組み込むプラットフォーム側の話は、クラウドのフィールドノートがercan.cloudにあり、ハブはercanermis.comにある。