このページでは
短い答え
ユーザーが完了する必要があるタスクから始めます。現実的なテスト ケースを選択し、合格が何を意味するかを書き留めます。コードで正確なルールを確認してください。文脈が必要な回答を判断するよう査読者に依頼します。同じケースで各変更をテストし、リリース前に重大な障害を検査します。
何を持ち帰るか
- ユーザーのリクエストから最終結果に至るまで、ワークフロー全体をテストします。
- 平均スコアが向上した場合でも、重大な失敗を独自に追跡します。
- テスト ケース、システム設定、回答、および各スコアの理由を保存します。
ソースをチェックしました .研究総合と Rubrex の推奨事項。例とローカル実験にはラベルが付けられています。これらはクライアントの結果ではありません。
ガイダンスの内容
Anthropic の 2026 年 1 月ガイドでは、エージェント テストをタスク、繰り返し実行、スコアリング ルール、およびテスト環境に分割しています。また、エージェントの発言と実際の行動も区別されます。たとえば、エージェントは、レコードが変更されていないにもかかわらず、レコードを保存したと言うかもしれません。会話だけでなく結果も採点します。これはモデル ベンダーからのアドバイスであり、1 つの方法がすべてのシステムで機能することを証明するものではありません。
テストでサポートする必要がある決定を選択してください
リリースの質問を 1 文で書きます。たとえば、サポート アシスタントは、承認できない払い戻しを約束せずにアカウント ポリシーを説明できますか?これにより、テストに明確なユーザー、タスク、リスクが与えられます。 「もっと役立つようにする」などの漠然とした目標では、間違ったスムーズな答えが得られる可能性があります。
ワークフローのどの部分をテストするかを決定します。要約ツールとしては 1 つの回答で十分な場合があります。チャット アシスタントには会話全体が必要な場合があります。エージェントがレコードを編集する場合は、保存されたレコードも確認してください。モデルのバージョン、プロンプト、検索設定、およびツールの権限を保存します。これらのいずれかを変更すると、結果が変わる可能性があります。
確認できる小さなテスト セットを構築する
Rubrex は、一般的なタスク、エッジ ケース、既知の障害という 3 つのケース グループを推奨しています。ケースごとに、予想される動作と、そのケースがテストに含まれる理由を書きます。システムのチューニング中は、いくつかのケースを控えてください。スコアを使用してリリースをサポートする前に、最初のテスト実行を使用して不明瞭な要件を見つけます。
コードを使用して、必須フィールドや許可されたレコード ID などの正確なルールを確認します。意味、欠落している詳細、正直な不確実性については、採点ガイドを使用してください。レビュー担当者に、小規模な共有セットを独自に採点してもらいます。さらに多くの事件について自動裁判官を信頼する前に、意見の相違点について話し合ってください。スコア付けできないケースはレポートに残し、その理由を説明します。
- 元のバージョンと、失敗したリクエストを含むすべての回答を保存します。
- 変更されたバージョンを同じ入力と制限で実行します。
- 改善したケースと悪化したケースを検査します。
- ブロックを解放する各失敗に名前付きの所有者を与えます。
例: 政策を説明するアシスタント
アシスタントが現在のポリシーを引用し、例外を説明し、承認の約束を避けなければならないとします。最初の 2 つのルールを満たしていても、返金を約束することで失敗する可能性があります。各ルールにスコアを付けて、チームが問題を見つけられるようにします。また、回答がすべての必須ルールに合格したかどうかも記録します。
ここで、新しいプロンプトによって引用は修正されましたが、サポートされていない約束が増えたとします。それはまちまちの結果です。 Promise を目的とした変更をテストし、以前のケースを再実行して新たな障害がないか確認します。これはテスト計画の例であり、Rubrex クライアントからの結果ではありません。
次のエンジニアにテストを再実行するのに十分な時間を与えてください
ケース、スコアリング ルール、システム バージョン、元の回答を共有します。失敗を原因ごとにグループ化し、何がまだ不明であるかを説明します。テストを再実行し、起動後に見つかった失敗を追加する手順を含めます。別のエンジニアは、作成者のスライドデッキを必要とせずに決定をチェックできる必要があります。証拠が弱すぎて判断できない場合は、欠落しているデータと次のテストに名前を付けます。
各スコアの意味を記録する
リリースの質問に答える対策を選択してください。 Rubrex は、サポート アシスタントに対して、間違った回答、サポートされていない主張、完了したタスク、および有用な回答のコストを追跡することをお勧めします。それぞれのカウントが何をカバーするかを述べてください。 100 件の回答のうち 10 件が失敗したということは、100 件のセッションのうち 10 件が失敗したこととは意味が異なります。応答がなかったリクエストも含めます。
1 つのテストで 1 つの要件がチェックされます。テスト スイートは、いくつかの要件とシステムが失敗する可能性がある方法をチェックします。アプリケーションの結果を公開モデルのベンチマーク スコアから分離してください。新旧のバージョン、テストされたケース、スコアの定義、リリースを妨げた失敗を記載した短い意思決定記録を作成します。次のテストの所有者の名前を指定してください。
証拠の限界
テスト セットは、システムが受け取る可能性のある入力の一部のみをカバーします。これに合格したからといって、今後のすべての答えが安全であるか正しいことを証明するものではありません。このワークフローは、Rubrex が推奨する開始点です。これは、普遍的なリリース標準ではなく、公開されたガイダンスによって通知されます。
よくある質問
すべての出力には人間によるレビューが必要ですか?
いいえ、コードは正確なルールをチェックできます。不明瞭な回答や重大な結果をもたらす回答については、検討する必要があります。スケールアップする前に、レビュー担当者がスコアリング ルールに同意していることを確認してください。
ベンチマーク スコアが優れていれば、アプリケーションは準備完了になりますか?
いいえ。公開ベンチマークでは、データ、ユーザー ワークフロー、ツールの権限、ルールをテストして、合格する答えを得るわけではありません。
出典と詳細情報
このブリーフィングの背後にある主な情報源。情報源の発見は、その情報源自身の研究条件に当てはまります。 arXiv での出版は査読を確立しません。
- AI エージェントの eval をわかりやすく説明する 人間的 · 2026 · 技術指導レビュー済み: 技術記事.アクセス済み 2026年9月25日.
質問または修正がありますか? Rubrex に書き込む. 編集アプローチを読む.