本番運用の RAG：検索、権限、コスト管理

「正しい回答」とは何かを定義する

検索拡張生成（RAG）は、モデルが回答する前に関連する資料を渡す仕組みです。変化する知識や社内の知識に役立ちますが、検索したからといって、取得した資料が正確で完全であり、そのユーザーが閲覧を許可されているとは限りません。

まずは、バージョン管理された製品マニュアルに関する質問に答えるといった、範囲の狭いユースケースから始めましょう。許容できる回答の例、必要な引用、システムが回答を断るべき場合や人に引き継ぐべき場合を書き出します。回答の生成は、業務データを変更するツールとは切り離しておきます。

検索に備えて文書を準備する

見出し、表の文脈、バージョン番号、出典 URL を保持します。各チャンクに安定した文書 ID を付け、アクセスルールと改訂日も残します。すべての文書に同じトークン数が合うと考えるのではなく、意味のまとまりで分割しましょう。答えが2つのセクションにまたがる質問や、脚注に左右される質問もテストします。

文書の削除や権限の変更は、検索インデックスとキャッシュに反映されなければなりません。文書の埋め込みを作り直したときに、古くてアクセス可能なチャンクが残ってはいけません。取り込みの失敗を記録し、どの根拠が欠けているかを運用担当者が把握できるようにします。

検索方式を比較する

エラーコード、SKU、バージョン番号のような正確な語句には、キーワード検索が効果的なことが多いです。埋め込みは概念的な類似性に役立ちます。ハイブリッド方式では両方の結果を組み合わせ、ランク融合や再ランキングを使えますが、コストとレイテンシが増えます。

工程を追加する前に、ラベル付きの質問セットを作ります。関連があり閲覧が許可された文章が検索結果に含まれるか、そして最終的な回答がその文章に裏付けられているかを測定します。曖昧な質問、答えのない質問、古くなった質問も含めましょう。特定の上位件数での適合率は検索の指標であり、全体的な事実の正確さを測るものではありません。

コンテキストを渡す前にアクセス制御を適用する

1. 信頼できるアプリケーションコードでユーザーを認証し、テナントと文書の権限を確定します。
2. 検索に認可の制約を適用し、最終的に選ばれた文章がモデルに渡る前に検証します。
3. 取得したテキストは信頼できないデータとして扱います。秘密情報の開示やツールの呼び出しを求める文書内の指示が、アプリケーションのポリシーより優先されてはいけません。
4. ツールは必要な操作に限定し、モデルの出力とは独立して引数、権限、業務ルールを検証します。
5. 影響の大きい操作には適切な確認やレビューの手順を設け、最小限の監査記録を残します。

誤った回答を共有せずにコストを抑える

検索、埋め込み、再ランキング、生成のコストを、p50 と p95 のレイテンシとあわせて個別に追跡します。コンテキストは回答に役立つ文章に絞り、出力の長さに上限を設け、評価セットをもとにモデルの性能を選びます。

キャッシュは、完全一致と明確な無効化戦略から始めます。キーはテナント、アクセスポリシーのバージョン、文書のバージョン、モデル、プロンプトのバージョンで区切ります。言い回しが似ているだけでは、2人のユーザーが同じ回答を受け取る権利があるとは言えません。セマンティックキャッシュには誤一致や古い回答への追加テストが必要で、検索や埋め込みの処理も引き続き発生します。

測定可能な受け入れ基準でリリースする

ユースケースのリスクに見合った基準値を設定します。引用、回答拒否、権限の境界、悪意のある文書、タイムアウト、ツールの失敗をテストします。構造化された JSON は解析を確実にしますが、スキーマが正しくても、主張が真実になるわけでも、操作が許可されるわけでもありません。

リリース後は、誤った回答と検索の取りこぼしを振り返ります。デモ向けに調整するのではなく、それらを保留しておいた回帰テスト用のセットに加えましょう。回答の根拠となる出典をユーザーに示し、手元の資料で質問に答えられない場合は不確かさを明示します。

出典と参考資料

• pgvector：検索、インデックス、ハイブリッド検索
• OWASP：プロンプトインジェクションの防止

あわせて読みたい

AI アプリケーション開発をご覧いただくか、信頼できるバックグラウンド処理のためのキューと冪等性のガイドをお読みください。