非決定性、プロンプト変更、外部依存の変化を扱う開発手順です。正解例と閾値を業務側が承認し、変更時と定期実行で評価します。 検索の精度が高くても、回答に必要な情報が欠ける場合があります。集計値に加え、質問ごとの失敗と採用基準を確認することが焦点です。 動くデモから受け入れの証拠へ進める AWSは11月12日、Agent Development Lifecycleを解説しました。Agent DLCと呼ぶ手順で、Agentを本番へ出せるかを一貫して判断する考えです。通常のソフトウェアのテストは引き続き必要ですが、それだけでは足りないと説明しました。同じ入力でも結果が変わり、プロンプトや検索設定の変更でも振る舞いが変わります。外部モデルやAPIはコードを変更しなくても更新されます。そこで、検証可能な条件、閾値、承認済みの例をまとめた基準を作ります。原文はこれをgold standardと定義し、業務の責任者が受け入れ判定の基礎として承認するとしました。 検索の当たり方と必要情報の網羅を分ける 解説では社内人事方針を答える参考実装を使っています。取得した文書片が関係するかを測る精度が高くても、質問に必要な情報を取得できていない例を示しました。回答の根拠との一致、文書片や事実ごとの必要性、検索の網羅、回答の過不足を分けて採点します。これは顧客の本番成果でも一般的な性能順位でもありません。対象が狭い参考実装の測定で、再実行や版によって数値は変わり得ます。開発チームには、変更と評価の来歴を結び付ける作業が加わります。業務側には、何を正解とし、どの失敗を許容するかを決める責任が残ります。複数回実行して成功率と失敗の分布を見ることで、単発の成功だけでは見えない不安定さを把握しやすくなる可能性があります。一部の質問の失敗が平均値に隠れていないかも確認します。部署ごとに必要な答えが異なる場合、全体の点数だけでは受け入れを決めにくいと考えられます。 評価を回せる費用と担当者を定める 運用では、評価の網羅性と継続できる費用の両立が論点です。すべての変更を大規模に評価すれば費用と待ち時間が増える可能性があります。重要な業務例と失敗時の影響を踏まえて、判定する対象を決める必要があると見られます。採点に別のモデルを使う場合、その判定の繰り返しやすさも確認します。平均値の改善だけで公開を決めず、権限外の操作や重要情報の欠落を個別に扱います。依存先が変わることに備え、コード更新時以外の定期評価と逸脱時の通知も含めます。基準を更新した場合は、以前の結果との比較可能性が変わる点に注意が必要です。実装、評価、業務の承認が同じ記録を参照できるようにすることが、継続改善の判断を支えると見られます。公開後に基準を外れた場合の停止や差し戻しも定めます。評価を継続する担当者が変わっても、判断の理由を引き継げる記録が必要になると見られます。