表示
超・人工知能研究所 Super AI Research Lab トップへ超・人工知能研究所AI Research Lab / ぱそ太郎工事中

since
平成38年9月29日

← 検索結果に戻る

閲覧権限に合わせて検索索引を重ねて配置するHONEYBEE

HONEYBEE

保存した記事を見るこのブラウザに保存します。無料会員で端末間の同期・フォルダ整理

概要

  • RBACの権限対応を使い、文書の重複を許す検索区画と検索経路を設計する。
  • 保存量と再現率の条件の下で、区画構成と索引の探索の深さを調整する。
  • 要旨と本文で性能値が異なるため、導入判断には比較条件と導入先での測定が必要である。
補足:編集した模式図で仕組みを確認する

VISUAL EXPLAINER

図でつかむ、HONEYBEEの仕組み

左から右へ読む
  1. 01文書・権限・検索文
  2. 02重なる区画を設計
  3. 03権限別に検索・統合
  4. 04許可文書の上位件

原論文の説明をもとにした模式図です。処理の細部は省略しています。

研究の背景

HONEYBEEが扱うのは、閲覧権限を守りながら意味の近い文書を探す検索である。ベクトル検索では文書や検索文を数値列で表し、近いものを探す。社内文書では関連性だけでなく、利用者が読める文書に結果を限る必要がある。

ロールベースアクセス制御(RBAC)は、利用者を職務などのロールに結び付け、ロールへ文書の権限を与える方法だ。権限別に索引を増やすと保存量が増え、共通索引で検索後に権限を確認すると応答時間や検索の取りこぼしが問題になる。

手法

HONEYBEEは、文書ベクトルと利用者・ロール・文書の権限対応を受け取り、検索用の区画を設計する。区画は索引を作る文書のまとまりで、同じ文書が複数の区画に入ってもよい。保存量と再現率の条件を置き、各区画の索引と探索の深さを決める。さらに、ロールの組み合わせごとに必要な区画を選ぶ検索経路を記録する。

例えば人事と経理の両ロールを持つ利用者なら、記録した経路から必要な区画を選び、検索文のベクトルに近い文書を探す。必要に応じて権限外の候補を除き、各区画の結果を類似度順にまとめて上位件を返す。探索の深さは索引内で調べる候補の範囲に関わり、深くすると再現率と検索時間の両方に影響する。

新規性

HONEYBEEはロールを分割の最小単位とし、同じ文書を複数の区画に置くことを許す。区画を完全に分けるか一つにまとめるかの二択ではなく、保存量の上限に応じて構成を選べる。

著者らは検索時間と再現率の予測モデルを用い、保存量と再現率の条件を満たしながら平均検索時間を抑える問題として区画設計を定式化する。再現率は、権限を考慮した全件探索の正解上位文書を、索引検索でどれだけ得られたかを示す割合である。

従来手法との違い

ロールごとに専用索引を作れば、検索先を権限内の文書に絞れる。一方、複数ロールが読める文書は重複する。著者らは、ロール別に分割しても単一索引の27倍の保存量を要した実験例を挙げる。

単一索引で候補を探してから権限で絞る方式は、文書の重複を避けられる。ただし閲覧可能な文書が少ない利用者では候補の多くが除かれ、探索範囲を広げる必要がある。HONEYBEEは区画の重なりと検索の深さを調整する。

実験結果

著者らはRBACの権限設定を持つ検索処理で、検索時間、保存量、再現率を評価したと述べる。本文には、pgvectorのHNSW索引を使った比較がある。HNSWは近いベクトル同士を結ぶ索引方式で、本文は行単位の権限制御を使う共通索引との比較で最大6倍の高速化、保存量1.4倍と記す。

一方、要旨は行単位の権限制御との比較で検索時間が最大13.5倍短く、保存量は1.24倍と記す。両者の条件差は確認できた本文の範囲では特定できないため、単一の代表値にはまとめられない。実データを使ったとの記述はあるが、データセット名と条件別の結果表は確認できない。

応用の可能性

編集上の応用案 · 論文が実証した用途とは区別しています。

編集上の応用案:部署別の閲覧権限がある社内文書検索に使う。入力は文書のベクトル、利用者とロールの対応、ロールと文書の権限対応、検索文のベクトルとする。出力は、その利用者が閲覧できる類似文書の一覧である。

既存の権限情報から区画を設計し、検索時は利用者のロールに応じて区画を選ぶ。必要なデータは文書ベクトルと権限対応で、権限対応が閲覧可否のラベルになる。物理センサーは要らない。導入先の権限変更を索引と検索経路へ反映する手順は別途設計する。

応用先の候補からNauhに相談できます。

導入時の検証

導入時の検証案 · 対象データでの再評価が必要です。

導入時の検証案:一部の文書ベクトル、利用者とロールの対応、ロールと文書の権限対応を抽出する。権限対応を閲覧可否のラベルとし、検索文と利用者の組を用意する。物理センサーは不要だが、検索時間と再現率の予測モデルを導入先に合わせて調整するための検索データが要る。

同じ検索文と利用者で、単一索引から検索後に権限で絞る方式を基準に比較する。問い合わせ時間、重複を含む保存量、権限内文書の再現率を測る。再現率の正解は権限を適用した全件探索で作り、ロール変更後の結果と権限外文書の混入も確認する。

限界と課題

著者らは再現率のモデルを単純化し、検索文と権限条件の相関を扱わないと記す。検索時間のモデルでも、データ分布やベクトルの実質的な次元が及ぼす影響を省いている。このため予測値は導入先の検索処理で確かめる必要がある。

編集上の検証事項は、権限変更後に区画と検索経路が更新されるか、複数ロールを持つ利用者にも権限外文書が返らないかである。確認できた本文の範囲では、これらの運用時の測定値や更新費用は判断できない。

応用先の候補
研究内容と応用案に基づく分類です。業界での導入実績を示すものではありません。

出典

元のタイトル・要旨を確認する(英語)

HONEYBEE: Efficient Role-based Access Control for Vector Databases via Dynamic Partitioning[Technical Report]

Enterprise deployments of vector databases require access control policies to protect sensitive data. These systems often implement access control through hybrid vector queries that combine nearest-neighbor search with relational predicates based on user permissions. However, existing approaches face a fundamental trade-off: dedicated per-user indexes minimize query latency but incur high memory redundancy, while shared indexes with post-search filtering reduce memory overhead at the cost of increased latency. This paper introduces HONEYBEE, a dynamic partitioning framework that leverages the structure of Role-Based Access Control (RBAC) policies to create a smooth trade-off between these extremes. RBAC policies organize users into roles and assign permissions at the role level, creating a natural ``thin waist`` in the permission structure that is ideal for partitioning decisions. Specifically, HONEYBEE produces overlapping partitions where vectors can be strategically replicated across different partitions to reduce query latency while controlling memory overhead. To guide these decisions, HONEYBEE develops analytical models of vector search performance and recall, and formulates partitioning as a constrained optimization problem that balances memory usage, query efficiency, and recall. Evaluations on RBAC workloads demonstrate that HONEYBEE achieves up to 13.5X lower query latency than row-level security with only a 1.24X increase in memory usage, while achieving comparable query performance to dedicated, per-role indexes with 90.4% reduction in additional memory consumption, offering a practical middle ground for secure and efficient vector search.

論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01