検索は役立つが、正しい回答を保証はしない
検索拡張生成（RAG）は、言語モデルが回答する前に、選択されたドキュメントをモデルに供給します。これは回答を企業の情報により関連性の高いものにできますが、システムは依然として誤った箇所を検索したり、例外を見落としたり、ソースが裏付けていない主張を生成したりすることがあります。
明確に定義されたタスクから始めてください。たとえば、サポートスタッフが現行の返品ポリシーを見つけるのを手助けすることです。どのソースが信頼できるか、誰がそれらを維持するか、回答がいつ人間のレビューを必要とするかを決めてください。「当社のドキュメントを使う」という一般的な指示は、受け入れ基準にはなりません。
使える根拠を準備し検索する
ドキュメントを箇所に分割する際は、見出し、ドキュメントの同一性、バージョン、ソースリンクを保持してください。例外は、それが限定する規則とともに保ってください。1つの手法や固定のチャンクサイズが常に最善だと仮定するのではなく、代表的な質問に対してキーワード検索、ベクトル検索、組み合わせ検索を比較してください。必要な根拠が検索結果に現れるかどうかを、最終的なレスポンスがそれを正確に使うかどうかとは別にテストしてください。 MicrosoftのRAGアーキテクチャ概要.
テキストがモデルに届く前に権限を適用する
認証済みユーザーのテナントとドキュメントの権限に基づいて、検索対象を制限します。機密情報を隠すようモデルに指示するプロンプトは、認可の境界にはなりません。ソースリンク、生成された要約、会話履歴、キャッシュされた回答にもアクセス制御が必要です。権限の変更やドキュメントの削除は、インデックスと派生するすべての保存先にも反映しなければなりません。
実装例については、 Azure AI Searchはクエリ時の権限フィルタリングを文書化しています。そのプラットフォーム固有の機能とプレビューの制限は、意図するデプロイ向けに確認が必要です。
裏付けのない質問を明示的な結果にする
重要な主張の裏にある箇所を示し、ユーザーがそれを検査できるようにしてください。引用は、実際に回答を裏付けている場合にのみ有用です。ソースが欠けていたり、矛盾していたり、古かったりする場合は、何が確認できなかったかを述べ、関連する検索結果または引き継ぎを提示してください。弱い検索スコアを、でっち上げた信頼度のパーセンテージに変えないでください。
例： あるポリシーでは、未開封の商品は30日以内に返品できるとされていますが、海外返送の送料については何も述べられていません。「海外送料を払い戻してもらえますか？」に対しては、適切な回答はその欠けている情報を特定し、ポリシーまたはサポートチームを案内します。30日ルールを繰り返しても、その質問には答えていません。
挙動全体を評価する
- 回答可能な質問、曖昧な質問、古い質問、意図的に裏付けのない質問を含めてください。
- 各ケースについて、期待される根拠、許可されたユーザーロール、受け入れ可能な回答または回答の見送りを記録してください。
- 検索の網羅性、個々の主張の裏付け、引用の正確さ、権限の漏洩、レイテンシーとコストを個別に確認します。
- ドキュメント、検索設定、プロンプトまたはモデルを変更した後にセットを繰り返します。不要な個人データを削除した後、実際の失敗例を追加します。
これは提案された評価アプローチであり、過去のクライアントデータセットに関する主張ではありません。有限のテストセットによって、将来の回答が常に正しいと証明できるものはありません。影響の大きいアクションには、ワークフローに適した追加の管理、承認または人によるレビューが必要です。
アプリケーション内のAI機能には LLM統合 を、複数のシステムにまたがる業務には ワークフロー自動化 をご検討ください。開発ツールの環境と、デプロイされた製品のデータフローは、それぞれ別に検討すべき事項です。
