AIチャットボットとLLM機能のテスト：非決定論的な出力に対するフレームワーク

ログインフォームのテストは簡単です。入力は決定論的であり、期待される出力も決定論的です。正しいパスワードを入力すればアクセスが許可され、誤ったパスワードを入力すればエラーが返されます。

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を無料で試す →