𝗦𝗰𝗼𝗿𝗶𝗻𝗴 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀: 𝗗𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰 𝗠𝗲𝘁𝗿𝗶𝗰𝘀 + 𝗮𝗻 𝗟𝗟𝗠 𝗝𝘂𝗱𝗴𝗲

多くの小さなAIエージェントを運用しているとします。バックエンド、フロントエンド、モバイル、DevOpsなど、各エージェントにはそれぞれ一つの役割があります。

エージェントの数が増えると、ある問題に直面します。それらが「良い」のかどうかが分からなくなるのです。プロンプトを編集した結果、性能が上がったのか下がったのかも判断できません。規模が大きくなると、「見た感じ大丈夫そう」といった主観的な判断は通用しません。

私はこの問題を解決するために、パフォーマンスを数値で測定し、プロンプトを自動的に改善するフレームワークを構築しました。

戦略

まず、数学的に測定可能なものを測定します。LLMジャッジは、どうしても必要な場合にのみ使用します。決定論的メトリクスは高速でコストがかかりません。一方で、LLMジャッジは低速でコストが発生します。

システムの仕組み：

• ハーネスは、各エージェントを個別のプロセスとして実行します。 • エージェントにタスクを入力します。 • 出力をキャプチャします。 • 期待されるデータと比較して結果をスコアリングします。

エージェントは stdin から読み込み、stdout に書き出すだけで済みます。Pythonでもシェルスクリプトでも構いません。ハーネスはそれを問いません。

追跡すべき5つのコアメトリクス：

  • Accuracy（正解率）: 出力は目標に一致しているか？
  • Fuzzy score（ファジー・スコア）: テキストはターゲットにどの程度似ているか？
  • Timeout rate（タイムアウト率）: エージェントが完了に失敗する頻度はどのくらいか？
  • Safety violations（セーフティ違反）: 出力に不適切なパターンが含まれていないか？
  • Reproducibility variance（再現性の分散）: エージェントは毎回同じ回答を返すか？

エージェントの回答が正しくても、一貫性がない場合はバグです。

LLMジャッジ

数学的な測定が困難なものもあります。エージェントが自身の役割を維持しているか、あるいは制約に従っているかを知る必要がある場合です。

こうしたケースでは、LLMジャッジが作業内容をレビューします。ジャッジには評価基準（ルーブリック）とエージェントの出力が渡されます。そして、構造化された判定結果が返されます。レポートが壊れないよう、この判定結果をJSONスキーマで検証しています。

ジャッジの役割は採点だけではありません。修正案を提示する必要があります。「これは不十分です」といった批判は役に立ちません。「プロンプトにJSONブロックを追加してください」といった批判こそが、実行可能なアクションにつながります。

改善ループ

失敗した事例はファイルに保存されます。このファイルが自動化されたループに供給されます。システムはプロンプトの最も弱い部分を特定し、それを修正しようと試みます。優れた候補をプールに蓄積し、最も優れたバージョンをコードに書き戻します。

単一のスコアは、ある一瞬の切り抜きに過ぎません。履歴を使用して傾向を追跡してください。これにより、時間が経つにつれて改善されているかどうかが分かります。

決定論的メトリクスを基盤として構築してください。ジャッジはハンマーではなく、メスとして使いましょう。

ソース: https://dev.to/pponali/scoring-ai-agents-deterministic-metrics-an-llm-judge-poj

オプションの学習コミュニティ: https://t.me/GyaanSetuAi