知識にはアクセスの境界がある

アシスタントは閲覧を許可された情報から答えるべきです。本人確認と権限制御は文章の指示ではなく、検索と実行の仕組みで確実に適用します。

permission aware retrieval

要点は何ですか?

現在の、出典を示せる業務知識は検索に置くことが多いですが、アクセスルールも一緒に運ばなければなりません。呼び出し元を認証し、候補レコードがモデルに届く前に絞り、書き込み前に権限を再確認します。プロンプトの丁寧な指示ではテナントの境界を強制できません。権限の変更や古い索引にも対応する必要があります。

詳しく見る
このページの内容

出典付きの答えが契約書を指しています。しかし、その契約は別の顧客のものです。この例では、サポート用アシスタントが更新日を探すために二つの顧客のフォルダーを検索しました。別の顧客の似た契約を見つけ、文脈に入れて流暢に答えます。

これは報告された事故ではありません。出典があるため慎重に見える答えが、別の顧客のデータを漏らしています。欠陥はモデルが文章を書く前に起きました。

AI の知識を置く場所に関する講演は、利用者によって異なる知識には、アクセスを制御した検索層が必要だという構造上の論点を示します。Microsoft の文書単位のアクセス制御ガイドは、索引の文書と照会時の識別子を結ぶ権限確認を説明します。一般的なルールは製品固有の仕組みより簡単です。許可された資料だけを、答えを作る経路に入れます。

答えの前に境界を置く

プロンプトは、簡潔に、出典を付けて、必要なら確認するようアシスタントに指示できます。しかし別の顧客の文書を渡しておいて、「それを使わないように」と安全に頼むことはできません。検索がすでに境界を越えていれば、プロンプトにアクセス失敗を取り消させようとしているのです。

アプリケーションは呼び出し元の識別子を確立しなければなりません。検索照会には領域に応じてテナント、役割、アカウント、文書の権限など、その範囲を含めます。候補の文章をモデルに渡す前に、絞り込むか認可します。答えが書き込みを起こし得るなら、書き込み経路で対象レコードの権限をもう一度確認します。

  1. 呼び出し元の識別子

    アプリケーションで認証

  2. 範囲を絞った検索 テナント · 役割 · 文書

    モデルに渡す前に選別

  3. 証拠に基づく答え

    許された資料を出典に示す

  4. 書き込みの認可

    対象レコードを再確認

回答の経路でアクセス制御を適用する場所 アプリケーションが呼び出し元を認証し、範囲を絞った検索で未許可のレコードを除き、モデルは許された証拠から答え、書き込み時には再び認可します。

これはベクトル検索だけの問題ではありません。キーワード検索、保存された要約、会話の記憶、ツールの結果も非公開の内容を運びます。あるテナントの文書から作った要約は、元の文章が短くなっても私的です。

業務ツールをつなぐガイドは、各レコードの所有者と権威あるシステムを問います。アシスタントにはさらに、このレコードの存在を知ってよい人は誰か、と問います。

小さな例で順序が分かる

例として、索引に文書が四つあるとします。公開ヘルプ記事二つ、テナント A の契約一つ、テナント B の契約一つです。テナント A の利用者が請求条件を尋ねます。意味的に最も近いのは、たまたまテナント B の契約です。

範囲のない検索ならそれを返します。後から「テナント A についてだけ答える」と指示しても、安全は保証できません。内容はすでにモデルに渡っています。範囲を絞った検索なら、順位付け前にテナント B の文書を除くか、許可された候補だけを返します。アシスタントは A の契約から答えるか、必要な資料がないと言えます。

実装の詳細は基盤によります。Azure AI Search のセキュリティフィルターの方式では、文書にグループ IDを付け、各照会でフィルターをかけます。文書は、応答から権限フィールドを隠すだけではアクセス制御にならないとも警告します。強制できる部分は、フィルターと、その背後にある呼び出し元の識別子です。

権限が変わると、この違いは重要になります。担当者がアクセスを失ったら、古い保存結果や索引が文書を提供し続けてはいけません。最初の許可を試すだけでなく、取り消しの更新経路とテストが必要です。検索サービスが元の資料の権限モデルを守れないなら、資料をその索引にコピーする構造自体が誤りかもしれません。

権限と関連性は別々に試す

許可された文書でも、無関係または古いかもしれません。正確な答えでも、未許可かもしれません。失敗の種類が違うため、別々に評価します。

まず境界を試します。一つのテナントの呼び出し元が、別のテナントの私的内容を取得、引用、推測できるでしょうか。直接の質問、言い換え、要約を含めます。次に許された資料の中で答えの質を試します。現在の方針を選び、証拠がないと認めるでしょうか。Microsoft の RAG ガイドは検索時のアクセス制御と、取得した内容を信頼できないものとして扱うことを勧めます。

費用はあります。権限を考慮した索引には、メタデータ、識別子の対応付け、権限取り消しの処理が必要です。選別後に結果が空になることもあります。呼び出し元に証拠を見る権限がないなら、それは正しい結果です。自信に満ちた推測で穴を埋めれば、アクセス上の保護が正確さの問題に変わります。

この境界は自動化の例外に関する記事で述べた広い規則の実用的な試験でもあります。許可された検索結果が空ならどうすべきでしょうか。よい設計は「この答えの資料にはアクセスできません」と返し、適切な問い合わせ先を示せます。別のテナントまで検索を広げたり、古い答えを再利用したり、文書の題名から非公開の内容を推測したりしません。空の結果を、ワークフローの通常の、試せる状態として扱います。権限は公開後に修正する特例ではなく、正しさの一部です。

役立つアシスタントとは、会社のすべてを知るものではありません。呼び出し元の権限の中で適切な証拠を見つけ、境界によって答えられないときにそう言えるものです。

よくある質問

プロンプトで非公開のレコードを漏らさないよう指示できますか?

振る舞いは説明できますが、認可の代わりにはなりません。呼び出し元が見てよい文書だけを検索し、影響のある行動の前に権限を再確認します。

検索システムではテナントの権限をどこで適用しますか?

認証済みの呼び出し元を照会に結び付け、候補文書の内容がモデルに入る前に選別または認可します。アクセスが変われば権限のメタデータも更新します。

出典表示があれば答えは信頼できますか?

いいえ。出典は答えの由来を示しますが、呼び出し元が資料を見る権限を持つことも、元データが現在かつ正確であることも証明しません。

先行利用を申し込む

お名前と会社のメールアドレスを入力してください。Tajoへのアクセス申請を確認するためのリンクをメールでお送りします。

Brevoを取得