このページの内容
返品注文についての返信が、そのまま送れそうに見えます。文法は正しく、親しみやすく、短い文章です。この例では自動採点が満点を付けます。しかしアシスタントは、決済システムを誰も確認していないのに、返金済みだと顧客に伝えています。
誤りは文の弱さではありません。よい仕事の定義が弱いのです。
取り込まれた評価の実演では、ソフトウェア文書を書くエージェントの評価基準を作ります。興味深いのは、仕事を知る人が品質の意味を説明し、道具がそれを基準に変える瞬間です。後で低い点が付いたときは、エージェントを直すべきか、それとも評価を直すべきかという適切な疑問が生まれます。
評価基準は課題についての仮説です。仮説を試しましょう。
まず失格になる誤りから始める
チームは明確さ、口調、構造、網羅性など、採点しやすい項目から始めがちです。役には立ちますが、十分であることはまれです。
例の返金返信なら、「決済記録なしに返金完了と主張しない」は文章の質より上に置くべきです。データ同期なら、「請求先のメールをアカウント所有者のメールに対応させない」は、対応表の説明が読みやすいかより重要です。
領域の専門家に三種類の事例を求めます。明らかによい事例、明らかに悪い事例、知識のある人の間でも意見が分かれる事例です。元の記録と、それぞれの判断理由を残します。変わり得るルールに依存する事例なら、判定とともにルールの版も記します。
最初の組は小さくて構いません。ただし曖昧にはできません。
- 課題の責任者
よい、悪い、意見の分かれる事例
- 正確な確認 識別子 · 許可 · 送信先
コードで事実を検証
- 意味の評価基準
解釈が必要な点だけを判定
- 不一致の審査
判定と基準を訂正
| 確認すること | 適した担当 | 理由 |
|---|---|---|
| 必要な許可がある | コードと権威ある記録 | 正確に判定でき、影響が大きい事実 |
| 送信先の ID が元の識別子と一致する | コードとテストレコード | モデルが識別子を推測すべきでない |
| 返信が顧客の問いに答える | 人が審査した基準と、必要ならモデルの判定 | 意味の解釈が必要 |
| 状況に口調が合う | 人が審査した基準と、必要ならモデルの判定 | 許容できる形が複数ある |
既存のワークフローに AI を組み込むガイドも、モデルに任せる判断と、コードで確認する値や制約の境界を考える助けになります。モデルの確信度が許可に変わるわけではありません。
点数は基準の見落としを引き継ぐ
「すべてのエージェントの実行を人は審査できない。拡張できる判定器が必要だ」という反論はもっともです。問題は、何を拡張するかです。
評価基準が洗練された文章を褒め、実際に返金されたかを確認しなければ、自動化は見落としを拡大します。小数点以下二桁の数値は精密に見えますが、別のものを測っているかもしれません。
Google Cloud の判定モデル評価文書は実務的な確認方法を示します。人による評価付きの事例を準備し、モデルの指標を実行して、点数を比較します。一人の見方が絶対だという話ではありません。モデルの点に重みを持たせる前に、外部の基準が必要なのです。
平均一致率だけでなく、不一致を調べます。サポート責任者が拒否した返信を判定器が通したなら、どの基準が欠けていたかを問います。専門家二人が意見を異にするなら、両方の判定を残し、解釈の違うルールを見つけます。黙って平均してはいけません。
標本の選び方は基準の文言と同じくらい重要です。普通の成功例ばかり集めると、難しい事例には触れずに判定器が信頼できるように見えます。不完全なレコード、矛盾した指示、正しい答えが停止して尋ねることである事例を含めます。基準の作成者が調整に使っていない別の事例集合も保ちます。なじみのある事例で改善した変更は、別の場所でも証明が必要です。業務ルールが変われば判定と期待する結果を更新します。固定したテスト集合が昨日の方針を褒めてはいけません。
成果を評価に結び付ける
同期エージェントの評価基準は、顧客の結果まで追うべきです。正しい連絡先が変わったか。同意は守られたか。失敗したレコードを影響のある行動の重複なしに再実行できるか。
Brevo コネクターガイドは、API 呼び出しが成功しても属性が欠け得る理由を説明します。操作を呼んだかだけ見る評価では結果を見逃します。送信先だけ見る評価では、たまたま正しい値になった禁止された経路を見逃します。経路にリスクがあるなら両方必要です。
狭い課題と少数の失敗の種類から始めます。課題の責任者と事例を判定し、正確な確認はコードに置き、言葉や解釈が本当に必要なところだけモデルに判定させます。プロンプト、モデル、ツールを変えた後も同じ事例を試します。後の失敗から分かった基準の欠落も記録します。
先に専門家の時間が必要です。その代わり、後の点数には、誰かが説明できる意味が生まれます。
画面は点数を示せます。しかし、何を数えたかを教えるのは評価基準だけです。
よくある質問
AI エージェントの評価基準は誰が定めるべきですか？
課題と影響を知る人が許容できる結果と失格になる誤りを定めます。技術者はその判断を繰り返せる確認に変え、モデルの判定が人の評価に合うかを調べられます。
判定器の点数が高ければ、エージェントが動く証明になりますか？
いいえ。点数は試した事例について評価基準との一致を測ります。弱い基準、偏った事例、調整の不十分な判定器なら、有害な結果にも高得点を付け得ます。
モデルの判定でなくコードで確認すべきものは？
正確な権限、レコード識別子、必須のツール呼び出し、送信先の状態は、可能な限りコードで確認します。モデルによる判定は、厳密なルールで確定できない意味上の質に役立ちます。