AIチャットボットとLLM機能のテスト：非決定論的出力のためのフレームワーク
Yunhao Jiao
ログインフォームのテストは簡単だ。入力は決定論的であり、期待される出力も決定論的だ。正しいパスワードを入力すればアクセスできる。間違ったパスワードを入力すればエラーが発生する。
AIチャットボットのテストはまったく別世界だ。同じ入力を2回行っても、出力がそれぞれ異なる場合がある。レスポンスは確率論的であり、決定論的ではない。「レスポンスが期待値と等しいことをアサートする」という従来のアサーションベースのテストは、実行するたびに期待される出力が変わる場合には機能しない。
これがAI搭載機能を構築するすべてのチームが直面するテストの課題だ：「正しく動作する」の定義が曖昧な場合、どのようにして正しく動作していることを検証するのか？
LLM機能で従来のテストが機能しない理由
従来のE2Eテストは正確な出力を検証する。ボタンをクリックし、テキストが「Success.」に等しいことをアサートする。APIを呼び出し、レスポンスボディがスキーマと一致することをアサートする。このような二値的な合否チェックは、決定論的なシステムでは機能する。
LLM搭載機能は、一定の範囲内で正しい出力を生成する。AIカスタマーサポートチャットボットは役立つ正確なレスポンスを提供すべきだが、具体的な文言は毎回異なる。コード生成機能は動作するコードを生成すべきだが、実装は異なる場合がある。
LLM機能で失敗するテストアプローチ：
- 完全な文字列マッチング（出力はリクエストごとに異なる）
- スナップショットテスト（実行するたびに新しいスナップショットが生成される）
- 記録と再生（記録されたレスポンスはライブAI出力と一致しない）
インテントベースのテストフレームワーク
解決策は、正確な出力ではなくインテントをテストすることだ。チャットボットが正確に「ご注文は金曜日までに届きます」と言うことをアサートする代わりに、レスポンスが以下を満たすことをアサートする：
- 関連する配送情報が含まれている
- 注文データと事実上一致している
- ハルシネーションされた詳細を含んでいない
- 適切なトーンを維持している
- 許容可能なレイテンシ内でレスポンスを返す
これには異なる種類のアサーション、つまり文字列マッチングではなくセマンティック検証が必要だ。
TestSpriteのテストエンジンは、インテントベースのアサーションを通じて非決定論的な出力を処理する。LLM搭載機能をテストする際、エージェントは正確な期待出力と一致するかどうかではなく、レスポンスが動作要件を満たしているかどうかを評価する。
LLM機能の実践的なテストパターン
パターン1：境界テスト。LLMが絶対にすべきでないことをテストする。システムプロンプトを公開してはならない、有害なコンテンツを生成してはならない、存在しない注文番号をハルシネーションしてはならない。境界テストは、出力が非決定論的であっても決定論的だ。
パターン2：一貫性テスト。異なる言い回しで同じ質問をする。回答はセマンティックに一貫性があるべきだ。「注文状況はどうですか？」と「荷物はどこにありますか？」が矛盾した回答を生成する場合、バグが存在する。
パターン3：動作のリグレッションテスト。モデルの更新やプロンプトの変更後に、コアの動作が維持されていることを確認する。チャットボットは引き続き返金リクエストを処理し、適切にエスカレーションし、会話のコンテキストを維持すべきだ。
パターン4：LLM周辺のインテグレーションテスト。LLMの出力が変化しても、周辺システムは決定論的だ。APIはレスポンスを正しく処理し、UIは適切に表示し、ログは正確にキャプチャすべきだ。これらのインテグレーションポイントは標準的なアサーションでテスト可能だ。
TestSprite は4つのパターンすべてにわたるテストを生成し、確定的なインテグレーション層とLLM出力のセマンティック検証の両方をカバーします。
TestSpriteを無料で試す →