ユーザーがアクセス権を持たないドキュメントを見つける検索は、最終リンクをインターフェースで隠していても、すでに失敗しています。文書システム、案件、バックオフィス、ナレッジベースでは、リスクはさらに前に現れます。つまり、インデックス、取得されたチャンク、表示されるメタデータ、そして認可されていないコンテキストから生成された応答です。
PHPにおける権限付きセマンティック検索では、認可をビューの装飾的なチェックではなく、取得の一部として扱う必要があります。目的は有用な結果を返すことだけではありません。候補チャンク、引用、応答のすべてが、その時点で認証済みプリンシパルが参照できるコンテンツのみから導出されることを保証することです。
インデックス化前に確定すべき判断
まず、コーパスとそのアクセスモデルを定義します。すべてのコンテンツが同じライフサイクルや機密性を持つわけではありません。公開ポリシー、社内マニュアル、案件、外部共有ファイルには、それぞれ異なるルールが必要です。また、検索によって可能にするアクションも決める必要があります。タイトルの発見、抜粋の閲覧、ドキュメントを開くこと、添付ファイルのダウンロード、要約の要求です。発見の権限があることは、必ずしも閲覧権限を意味しません。
- プリンシパル: クエリを実行するユーザー、サービスアカウント、または委任セッション。
- スコープ: 検索可能な組織、ワークスペース、プロジェクト、案件、またはリポジトリ。
- アクション: 発見、閲覧、ダウンロード、または管理。
- リソース: 状態、分類、所属を持つドキュメントおよびチャンク。
- エラー許容度: 認可では非開示を優先すべきです。偽陰性は不便ですが、偽陽性は侵害になり得ます。
ベクトル類似性はビジネスルールを理解しません。embeddingは意味的な近さを表現するものであり、アクセスの正当性を表すものではありません。そのため、設計は「似ている」結果が安全であることにも、生成モデルが不適切なコンテキストを無視することにも依存できません。
参照アーキテクチャと信頼できる情報源
権限はトランザクション上の信頼できる情報源に保持します。PHPアプリケーション、そのデータベース、またはリソースを統制する文書システムです。インデックスは再構築可能な投影であり、アクセスを決定する権威ではありません。インデックスが破損、遅延、不完全なデータを受け取った場合でも、認可層は提供を阻止できなければなりません。
堅牢なフローでは、4つの段階を分離します。
- 識別可能なバージョンのドキュメントからコンテンツを抽出し、一貫した境界でチャンクに分割します。
- 取得用の表現を計算し、スコープとバージョンのメタデータとともに保存します。
- クエリはプリンシパルに対して認可可能なフィルタを構築し、そのスコープ内だけで候補を取得します。
- アプリケーションは、各候補を表示またはコンテキストとして使用する前に、権限と有効性を再確認します。
PHPでは、これらの責務をカプセル化してください。ポリシーサービスはcan($principal, 'read', $documento)を解決し、インデックスアダプタはその決定から導出されたフィルタを受け取り、結果アセンブラは検証済み候補のみを受け入れるべきです。コントローラー、テンプレート、プロンプトが独自に権限フィルタを組み立てることは避けてください。
推測せずにフィルタリングできるメタデータ
各ドキュメントとチャンクには、安定した組織およびリソース識別子、コンテンツバージョン、インデックス状態、親ドキュメントへの参照が必要です。ポリシーを表現するために必要な属性を追加しますが、不要に機密データを複製してはいけません。
- tenant_idまたは組織: マルチテナント環境で必須の境界。
- document_idとchunk_id: 結果からソースへのトレーサビリティ。
- acl_revision: インデックス作成時に適用されたポリシーのバージョン。
- audience: 社内公開、チーム、プロジェクト、案件などの単純なスコープ。
- lifecycle_state: アクティブ、アーカイブ済み、削除済み、またはレビュー待ち。
- content_revision: すでに置き換えられたバージョンの引用を防止します。
ポリシーが変動するグループに基づく場合、チャンクごとに巨大なユーザーリストをインデックス化しないでください。コストが増え、関係性を露出し、劣化しやすくなります。可能であれば安定したスコープでフィルタリングし、例外は後段の検証で解決するほうが望ましいです。取得エンジンが信頼できるフィルタをサポートしない場合、同じ検索可能空間で複数のセキュリティスコープのコンテンツを扱わせてはいけません。
取得前にフィルタし、後で検証する
事前フィルタリングは露出面を減らします。セマンティッククエリには、最終候補を計算する前に、組織、アクティブ状態、許可されたスコープを含める必要があります。これにより、禁止されたテキストがランキング、抜粋、支援付き応答のコンテキストに影響することを防ぎます。
後段の検証は依然として必要です。クエリから閲覧までの間に権限が変わる可能性があり、継承が投影されていないデータに依存する場合や、インデックスが遅延している場合もあります。各候補について、現在のドキュメントを取得するか、安全な無効化を備えた認可キャッシュを照会してください。チェックに失敗した場合は、タイトル、スコア、存在を明かさずにチャンクを破棄します。
支援付き生成を行う場合、モデルには認可・検証済みのチャンクだけを渡してください。取得結果を要約するなど、具体的なユースケースを定義します。許可・禁止ケースで応答を評価し、検証可能な引用を保持し、クエリあたりのコストを制限し、結果一覧など非生成の代替手段を維持してください。モデルはアクセスポリシーや、機密コンテンツに対する人間の統制を代替するものではありません。
単純な設計を壊す継承、リンク、取り消し
グループ、継承されたフォルダー、共有リンクは間接的な変更をもたらします。ある人がグループを離脱すること、ドキュメントがフォルダーを変更すること、リンクが期限切れになることは、開く操作と取得の両方に影響しなければなりません。直接権限、継承、拒否の優先順位を明示的にモデル化し、競合をテストしてください。
取り消しには、付与よりも厳格な戦略が必要です。トランザクションキューまたは変更ログを通じて、コンテンツおよびACL変更イベントを公開します。ワーカーがメタデータを再計算し、チャンクを削除または再インデックス化します。インデックスが収束する間、後段の検証が提供を保護します。削除については、信頼できる情報源でリソースを直ちに利用不可としてマークし、そのチャンクを非同期にパージします。遅延が運用目標を超えた場合はアラートを出します。
検証可能な結果、テスト、可観測性
タイトル、制限された抜粋、場所、日付は、それらのフィールド自体も閲覧可能な場合にのみ表示してください。各結果は、認可済みの元リソースへつながる必要があります。引用によって、非表示ドキュメントのパス、作成者、テキストを露出してはいけません。結果がない場合は中立的なメッセージを使用し、ユーザーのスコープ外にコンテンツが存在するかどうかを確認してはいけません。
異なる組織のユーザー、グループのメンバーと非メンバー、権限が制限された管理者、期限切れリンク、セッション中に取り消されたリソースを含むテストマトリクスを構築してください。直接クエリ、同義語、まれな用語、禁止コンテンツを引き出すよう設計された質問をテストします。想定される結果には、関連するすべての内容が禁止されている場合の空リストが含まれます。
不要な機密クエリを保存せずに、インデックスバージョン、適用フィルタ、検証前後の候補数、レイテンシ、拒否、同期遅延を記録してください。後段での破棄の増加はACLの古さを示す可能性があります。移行後の結果ゼロは過剰なフィルタを示す可能性があり、組織間クエリは分離に関するアラートです。
別の解決策を選ぶべき場合と完了リスト
セマンティック検索が常に見合うとは限りません。小規模なカタログと安定した語彙では、フィルタ、テキスト検索、階層ナビゲーションのほうが説明しやすく、低コストです。また、権限が非常に動的で、エンジンが属性で安全にフィルタリングできない場合にも、これらが望ましい選択です。自然言語で表現されたクエリに実質的な価値をもたらし、完全なアクセス制御を維持できる場合に、セマンティック検索を使用してください。
- 信頼できる情報源がアクセスを決定し、インデックスは再構築できる。
- すべてのチャンクに組織、ドキュメント、バージョン、状態がある。
- クエリは取得前にフィルタし、提供前に検証する。
- 付与、変更、取り消し、削除には可観測な同期がある。
- 支援付き応答は認可済みコンテキスト、引用、AIを使わない代替手段だけを使用する。
- テストには意図的な不正アクセスの試行と空の結果が含まれる。
