正在加载，请稍候
向量检索只算相似度，不算权限。用 2026 年 UpGuard 对 Supabase 托管库的调查说明为什么文档级 ACL 必须在摄入阶段固化，并给出检索过滤、引用溯源两层要留下的产物，以及一套越权评测集模板。
RAG 知识库搭建里最容易被跳过的一段，是权限层。某集团内部问答上线第 11 天，销售在对话框里翻出了人力资源的调薪表——系统没被黑，接口也没越权，是检索那一步把 A 部门的文档交给了 B 部门的人看。
2026 年 9 月 25 日，TechCrunch 报道了安全公司 UpGuard 的一项调查：约 16,000 个托管在 Supabase 上的数据库存在不同程度的个人数据暴露，涉及姓名、住址、电话与用户密码，还有少量认证令牌。报道点得很准——这类外泄主要来自"AI 生成、快速上线"的应用在配置与默认值上出的错。
Supabase 首席信息安全官 Bil Harmer 回应称自家项目"默认安全"，并把安全定义成厂商与客户的共同责任。这话在数据库语境下没毛病，但它恰好暴露了边界：默认值只能保护没动过配置的人，而权限一旦要按租户、按部门、按密级细分，默认值就不存在了。UpGuard 研究员 Greg Pollock 的表述更克制，强调这轮研究的意义在于让数据暴露这件事被看见。
把镜头拉回知识库。向量索引存的是数值向量，只回答"哪段文字最像"，它不知道谁在提问、属于哪个租户、有没有资格看。对照 PostgreSQL 官方文档对行级安全的描述——表开启 RLS 后如果没建策略，就是 default-deny（默认拒绝），任何行都不可见——绝大多数向量库连这套可审计机制都没有，只给一个命名空间或 metadata 过滤条件，而这个条件由应用代码拼出来。传错一个参数，召回集就是全库。
权限只写在应用代码里，它是一次性的、不可回归的；写进数据模型，它才能被测试。工程上分三段落地。
解析完成、切分之前，就要给每一条 chunk 打上权限字段：租户标识、可见组、密级、来源文档版本号。这一步要留下的产物是一份入库清单——任意时刻能回答"上周三进的 1,240 条 chunk 分别属于谁"。如果 ACL 是入库之后补的，历史数据要么重灌，要么留一个永久说不清的窗口。
过滤条件必须来自请求主体（登录态、租户上下文），绝不能来自用户输入。第二个产物是检索日志：每次召回都留下主体声明与过滤表达式，出问题时能定位到具体是哪一次过滤失效。工程上建议做成双保险——向量库侧的 metadata 过滤做一次，取回后用应用层断言再校验一次，两道都过才进上下文窗口。
模型输出的每一条论断都要挂 chunk 标识，前端能点开看到原文档与所属租户。这一段的产物是引用可追溯率：抽 100 条答案，有多少条能一路点回原文。若某次召回的片段已判定无权，直接丢弃并写审计，不要送给模型"参考一下"。
| 隔离层 | 动作 | 落地产物 | 失效时的表现 |
|---|---|---|---|
| 摄入层 | chunk 固化租户 / 组 / 密级字段 | 入库清单与版本号 | 历史数据无法回填，权限只能事后猜 |
| 检索层 | 按主体过滤 + 取回后断言 | 检索日志（主体、表达式） | 召回集退化，或无权片段混入上下文 |
| 生成层 | 答案挂 chunk 引用 | 引用可追溯率 | 答对了但说不清来源，无法追责 |
权限层不能靠"我们测过"交差，得有两个口径上的数字。
样本配比建议 6:4 到 7:3，正例多于负例。负例要覆盖三类：同租户但密级不够、同一份文档的旧版本、跨租户但文本高度近似的对照文档。第三类最容易漏，也最容易在客户面前翻车。
采集分两路：从检索审计日志里采样真实的越权尝试，再人工构造对抗样本。评测跑完看两个数字的关系——如果越权率压到零，但召回率掉了 5% 以上，通常说明过滤表达式过严，得回去查是哪一层把有权文档误杀了。
知识库这条线我们拆成三层，各写一篇，别混着看。解析层看《企业知识库 AI 解析层：LiteParse 提速后的三笔账》，那一篇算的是解析提速之后省了多少、错在哪；检索层看《企业知识库 AI 检索层选型：什么规模才该换量化索引》，那一篇算的是什么时候该换索引结构。本篇只讲权限层——也就是前两段都跑通之后，谁有资格看到哪一段文字。
这三篇都归在工程化栏目下，也可以在技术博客首页按层翻阅，或对照成功案例里知识管理类项目的交付口径。如果权限层要在立项前就定下来，把上面三层的产物清单拿去和供应商逐条对；需要按你们自己的数据源与密级规则先算一遍改造工作量，可以走预约咨询。
不是完全没有，而是形态不同。多数向量库提供命名空间隔离与 metadata 过滤，但过滤条件由调用方拼装，缺少数据库行级安全那种"无策略即默认拒绝"的兜底。责任落点因此不同：在关系库里权限可以被数据库强制，在向量库里它必须由摄入与检索两段管道共同保证。
看隔离等级要求与租户数量。共用一套索引加强制过滤字段，运维成本最低，适合几十到几百个中小租户；独立集合适合强隔离场景（金融、医疗）或单租户数据量极大、过滤后召回质量明显下降的情况。混合做法也常见：大客户独立，长尾共用。
先按来源系统反推。文档管理系统、网盘、工单系统大多本身记录了可见范围，能批量回填。反推不出来的部分，建议标记为"需人工确认"并从检索集中排除，而不是给一个猜的默认值——猜错的方向往往是把不该看的放出去。
跟着权限变更走，不是跟着日历走。组织架构调整、密级规则变化、新增数据源这三类事件之后必须重跑；日常保持每周一次抽样回归即可。评测集本身要版本化，否则两次结果没有可比性。