build-test-suite

役に立つCovalテストスイートを構築する

製品の意思決定を変えるテストを作成します。異なる失敗メカニズムを網羅する少数のテストは、成功する基本パターンを言い換えたものを多数用意するより有用です。

内容を把握して再利用する

組織／ワークスペース、エージェント、スコープを確認します。選択したエージェント、既存のケース、関連する録音、顧客の信頼できる情報源に関するポリシーを調べます。coval --agent agents get <id>、test-sets get、test-cases list --test-set-id <id>を使用します。コマンドのヘルプ、エラー、ページネーションも確認してください。既存のスイートを置き換えたり、不具合のあるエージェントのプロンプトだけを根拠に要件を導き出したりしないでください。

大規模なコーパスでは、distill-test-setを使って元データの行を絞り込めます。生成された入力と期待値のペアを確認してください。まだ調査していない会話には、coval-discover-failuresを使用できます。要件が明確な場合、どちらも必須ではありません。

文章を書く前に網羅範囲を設計する

要件または観測された失敗、情報源、意味のある変化、シナリオ、期待される振る舞い、必要な証拠、リスク／優先度を含む簡潔なマトリクスを作成します。観測された失敗、ポリシー要件、仮説に基づく想定を区別してください。

振る舞いを変える可能性のある軸を選びます。たとえば、曖昧な依頼、変更された情報、ツールの結果がない場合、未対応の依頼、依頼者による訂正、関連する音声条件などです。機械的にすべての組み合わせを作らないでください。まず組み合わせを生成し、次に現実的な依頼者シナリオを作成します。実現不可能な組み合わせと意味が重複するものは除外してください。後の回帰テスト用に、変更を加えていないケースをいくつか残します。

音声の場合は、シナリオ、ペルソナ、音声条件を分けます。通常の音声から始め、明示した仮説がある場合に限り、アクセント／ノイズ／割り込みを変化させます。合成ケースに実在する顧客の機微な情報を含めないでください。顧客が対応する言語とワークフローに合わせて、架空で現実的な例を使用します。

公開されている診療時間が月曜日から金曜日の午前8時から午後5時までのクリニックの例：

ケース	依頼者のシナリオ	期待されるエージェントの振る舞い	情報源
営業時間	金曜日の閉院時刻を尋ね、回答にお礼を言って会話を終える	金曜日は午後5時に閉まると伝える	クリニックのポリシー
休診日	日曜日に診療しているか尋ね、回答を誘導しない	日曜日は休診だと伝え、日曜日の診療時間をでっち上げない	クリニックのポリシー
訂正	木曜日について尋ねた後、金曜日に訂正する	訂正後の曜日について回答する	仮説上の修復失敗

これは情報を検証するものであり、予約が保存されたことを検証するものではありません。

評価可能な期待値を作成する

必須の振る舞いはそれぞれ別の配列項目として記述します。関連する前提条件と観測可能な結果を明記してください。「役に立つ」といった曖昧な表現や根拠のない数値スコアは避け、正確な言い回しでなくても正しい言い換えが許容される場合は、特定の表現を必須にしないでください。

input_strやペルソナの指示で答えを漏らさないでください。シナリオは依頼者の目的を定めるものであり、エージェントの応答を定めるものではありません。現在のテストケース仕様に基づいて入力モードを選びます。柔軟なやり取りにはSCENARIOを使用し、依頼者の発話を厳密に指定する必要がある場合に限りSCRIPTを使用してください。生成された対話を、実際の本番環境の証拠と呼ばないでください。

会話の振る舞いにはトランスクリプトの証拠、音響上の振る舞いには音声、実際の副作用には相関付けられたツールの結果を使用します。証拠が基準を裏付けられない場合は、採点の前に基準を見直すか、計測上の不足として明示してください。

作成と読み戻し

書き込み権限の不足を確認する前に、正確なケースをローカルで準備します。 会話内ですでに許可されている作成を尊重します。顧客の文章をシェル文字列に埋め込むのではなく、構造化 JSON を使用します。

coval --agent test-sets create --input-json @test-set.json
coval --agent test-cases create --input-json @case.json

test-set.json では、公開 API の形式を使用します。

{"display_name":"Clinic information checks","test_set_type":"SCENARIO"}

実際のテストセット ID を取得した後、case.json は次のようになります。

{
  "test_set_id":"<returned-id>",
  "input_str":"Ask when the clinic closes on Friday. After the answer, thank them and end the conversation.",
  "expected_behaviors":["The assistant states that the clinic closes at 5pm on Friday."],
  "description":"Friday closing time; source: office policy",
  "input_type":"SCENARIO"
}

作成前に coval test-cases create --help と現在の test-cases スキーマを確認します。 CLI が構造化入力に対応していない場合は、文書化された公開 API を使用できます。次の項目を作成する前に各レスポンスを確認します。タイムアウトの結果が不明な場合は、重複を避けるため、再試行する前に既存のリソースを調べます。作成した各ケースを読み戻し、入力と個々の期待動作を検証します。必要に応じてページネーションを使用して件数を確認します。

引き継ぎ

カバレッジマトリクス、ID、未テストのギャップを提示します。ソースの分布と、意図的に比重を高めた失敗ケースは分けて扱います。スイートを作成しても、その実行が許可されたことにはなりません。イテレーション、ペルソナ、ベースケースとミューテーションを含む件数を明記し、quick-eval に含める小規模なサブセットを明確に提案します。configure-metrics を使用して、適切な基準を暫定的な指標にします。