変更で起きる困りごと
新しい問い合わせを直したら、以前の引き継ぎを失った
新商品の質問に答えられるよう、問い合わせ分類の指示を変える。 試した質問には詳しく答えられるようになった。 しかし、以前は担当者へ引き継いでいた返品相談にも、自動で回答するようになった。 これは本稿の想定例である。 新しい仕事の改善と、既存の仕事の後退が、同じ変更で起きている。
担当者が知りたいのは、平均点が上がったかだけではない。 新商品の回答を使えるようにしながら、返品の条件が不明な案件を確実に渡してもらえるかだ。 どの変更を受け入れ、何を直すまで保留するかを判断するには、改善した課題と維持すべき動作を別に見る必要がある。
本稿は、評価の設計、手順の版と実行記録、操作の制限を、その判断のために結び付ける。 評価を持つ組織ほど必ず導入が速いという測定結果は示さない。 重視するのは、変更の結果を担当者が説明でき、ユーザーが後退の発見役を引き受けずに済む条件である。
改善と維持
伸ばしたい能力と、失ってはいけない動作を分ける
1月9日のAnthropicのエージェント評価解説は、苦手な仕事の改善を測る能力評価と、以前できた仕事を保つ回帰評価を分ける。 解説が紹介するDescriptの動画編集エージェントも、品質の比較と回帰検査に別の評価群を使うという。 これはベンダーが紹介する運用例であり、二つの評価群を作れば導入が速くなるという比較実験ではない。
問い合わせの例では、新商品の条件を読み取り、適切な案内を作れるかを能力評価へ置く。 返品の条件が不明なら担当者へ渡す、別の顧客の注文を使わない、未処理の返金を完了と表示しない、といった維持条件は回帰評価へ置ける。 同じ質問への回答の質と、操作を進めてよい条件を一つの点数に混ぜない。
改善した件数が、後退した件数を上回るだけでは受け入れられない変更もある。 新商品の説明が十件良くなっても、一件で別の顧客へ返金すれば、失敗を相殺したとは判断できない。 この件数は説明のための想定である。 何を相殺できずに保留条件とするかは、業務の責任者が事前に決める必要がある。
能力の改善を問う
以前は難しかった質問を、必要な資料で解けるようになったか。 良くなった範囲を調べる。
既存動作の維持を問う
引き継ぎ、顧客の照合、失敗時の停止が残ったか。 新しい成功で埋め合わせられない後退を調べる。
同じ条件で比べる
変更したものと、固定したものを記録する
Anthropicの解説は、課題、各試行、採点方法、実行記録、最終状態を区別する。 本稿では、この区別を候補版と現行版の比較に使う。 依頼、初期の注文状態、使える資料、期待する結果をそろえて、それぞれを複数回試す。 前の試行が残した顧客情報や処理結果を、次の試行の出発点にしない。
比較の記録には、課題と採点基準、モデルと指示、ツール、資料、分岐条件、環境の版を結び付ける。 分類の指示だけを変えたつもりでも、ツールが参照する返品規則が変われば、点数の差を指示の効果と決められない。 逆に、採点器だけが古い規則を見ていれば、正しい回答を落とす可能性がある。
すべての条件を永遠に固定するための記録ではない。 変更の目的に合わせ、今回は何を変え、何を比べるかを説明するためである。 新しい規則で評価する必要が生じたら、現行版も同じ規則で評価し直す。 異なる基準の旧点数と新点数を、そのまま改善量にしない。
成果の判定
良い返答と、実際に終わった処理を別に採点する
「返金が完了しました」と丁寧に返しても、外部の注文システムに返金記録がなければ、完了していない。 この想定例では、実際の顧客、注文、金額、処理状態を確認する採点と、説明が正確で分かりやすいかを読む採点を分ける。 文章の質が高いことを、処理の成功の代わりにしない。
Anthropicの解説は、コードによる採点が正しい別表現に弱い場合と、モデルによる採点が非決定的で、人の判断と一致するかの確認を要することを説明する。 本稿の例なら、注文IDや返金状態は決まった処理で照合し、案内文の分かりやすさは人の評価と照らした基準で見る。 同じ採点器を全項目へ使う必要はない。
採点に失敗した候補を直す前に、既知の正しい処理や回答が、その採点を通るかも確かめたい。 正しい引き継ぎ文の言い換えを落としているなら、候補より採点の期待文字列が問題かもしれない。 一方、理由の説明が良くても、引き継ぎ先に案件が作られていなければ、本稿の成果条件は満たしていない。 何を根拠に不合格としたかを、担当者が再確認できる形にする。
失敗の原因へ戻る
結果の違いを、どの工程が作ったか
Foundryの複数エージェントワークフローの公開プレビューは、保存ごとの不変版と、変数や分岐の追跡を説明する。 初期の観測はワークフロー内の個々のFoundryエージェントが中心である。 AgentKitの発表も、手順の版管理と実行記録を使う評価を示す。 ただし、Agent Builderはベータで、ChatKitやEvalsとは提供段階が異なる。
こうした機能は、結果だけでは分からない原因を調べる材料になる。 返品相談が引き継がれなかったとき、分類が通常の質問へ変わったのか、分類は同じでも分岐が変わったのか、引き継ぎのツールが失敗したのかを追う。 原因によって、直す対象は指示、処理定義、外部との接続に分かれる。
実行記録が示す範囲にも注意が要る。 画面にツール呼び出しが見えても、外部システムで案件が保存された証拠とは限らない。 呼び出しの入力・応答と、外部の結果を対応付けて確認する。 製品に観測機能があることから、すべての外部操作を完全に検証できるとは判断しない。
制限と評価の関係
止める仕組みがあっても、正しい案件へ進むかを試す
AgentCoreのPolicyとEvaluationsのプレビュー発表は、関連付けたGatewayのツール呼び出しを制限する仕組みと、実行の品質を評価する仕組みを説明する。 Policyには強制する設定と、記録のみの設定がある。 発表の返金例が使う役割と200未満という金額条件は、操作の許可を判定する材料である。
金額条件に収まる誤った顧客への返金は、その条件だけでは見つけられない。 逆に、制限が誤って正しい返金を全部止めるなら、禁止された操作がゼロでも仕事は成り立たない。 進めるべき案件を進めたかと、止めるべき案件を止めたかの両方を、この想定例の評価に置く。
実行前の制限、実行後の品質評価、人への引き継ぎは、それぞれ異なる役割を持つ。 同じ発表の抽出した実行への品質評価を、全呼び出しが事前に許可された証拠とは扱わない。 評価が通った候補でも、本番の制限が記録のみなら強制は働かない。 評価に使った設定と、公開する設定が一致しているかまで確認したい。
基準も更新する
以前の動作を守ることと、古い規則を守ることを区別する
回帰評価は、過去の出力をすべて固定するためのものではない。 返品期限が十四日から三十日へ変わった、という想定を置く。 二十日目の正当な申請を拒む旧回答を維持すれば、回帰検査には通っても、新しい業務規則には合わない。 維持するのは承認された規則への適合であって、古い返答そのものではない。
この場合は規則の変更を記録し、対象商品の条件や起算日を確かめてから、期待する結果を更新する。 候補が失敗したから都合よく基準を緩める変更とは分ける。 期限を確かめられない案件で補足を求めた結果も、適切な停止なら失敗としない。 担当者が正解を一意に説明できない課題は、先に条件を具体化する必要がある。
Anthropicのツール設計の解説は、実際の仕事を代表し、成果を確かめられる課題と、未使用の評価課題による確認を勧める。 本稿では、指示の修正に使った返品相談だけでなく、未使用の言い回しや条件でも試す。 既知の失敗に答えを合わせただけなのか、維持条件を保てるようになったのかを区別するためだ。
受け入れる判断
ユーザーに後退を発見させる前に、残る負担を説明する
冒頭の候補版は、新商品の説明が改善しても、必要な引き継ぎを失っていれば、そのまま受け入れない。 原因を直し、改善課題と維持課題を同じ条件で再確認する。 案件を人へ渡しすぎていないか、処理時間や費用、担当者の再調査が増えていないかも見る。 自動化率だけを上げれば、必要な引き継ぎまで減らす方向へ進み得る。
評価の作成と維持にも時間がかかる。 最初からあらゆる仕事を採点するより、変更の影響を受ける仕事と、失敗の負担が大きい条件から始める判断がある。 自動評価で見えない実際の問い合わせは、公開後の記録と担当者の報告から追加する。 事前評価の合格を、未知の入力すべての保証にはしない。
版、実行記録、採点をそろえる価値は、点数を管理できることにとどまらない。 何が良くなり、何が残り、どの条件が変わったかを説明して、受け入れや保留を決められることにある。 変更のたびにユーザーの苦情を待って調べ直す仕事を減らせるか。 その問いまで答えて初めて、評価を持つことが問い合わせ対応の改善へつながる。