如何按用户、团队和组织控制知识库文档读取权限？

把权限建模为可信身份、组织成员关系、资源授权和每次访问时的强制过滤。认证后由服务端取得用户、租户及有效团队/组织成员关系，计算其可读知识库与文档范围；文档切片继承ACL，向量、关键词、补充读取和引用下载都执行同一授权。

用户属于某团队或组织，并不天然能读全部资料。继承、显式共享和拒绝规则要由产品权限模型定义，不能把相似度、模型判断或前端隐藏当作授权。

用户与团队/组织成员关系、角色或资源授权分别维护；知识库和文档记录所属租户、所有者及授权主体，片段保留doc_id与ACL版本。按需要支持知识库继承和文档例外，明确多个授权如何合并、拒绝优先还是其他策略。

请求里的身份来自已验证凭据，不能由模型自由填写user_id或team_id。系统为本次查询注入有效范围，客户端传来的知识库ID也要再次检查归属与读取权限。

能在检索前或检索时过滤就尽早过滤，避免其他用户片段进入重排模型、日志或生成上下文；物理独立集合和共享集合加过滤都可考虑，按隔离与运维要求选择。

过滤发生在ANN候选之后时，可能返回不足K条，应在不放宽权限的前提下增加授权范围内的搜索或采用适合的执行策略。原文回读、相邻块扩展、图遍历、附件链接和缓存结果也要检查权限，不能只保护第一轮向量查询。

用户退出团队、文档撤回或共享收紧后，更新授权版本并失效相关缓存、摘要和索引权限；敏感撤权优先在访问层阻断，不能等低优先级重建。缓存键或命中验证包含身份/授权范围与数据版本，避免把管理员答案复用给普通用户。

关系数据库可用行级策略作为额外保护，但要核对连接身份和owner、管理员、绕过角色等例外；应用用统一高权限账号连库时，数据库不会自动知道当前终端用户是谁。

用同租户不同团队、跨租户、文档例外、成员关系变化和引用下载做正反用例，交错查询并触发缓存。检查检索候选、模型输入和最终输出，而不只是答案有没有显示敏感内容。无权读取与资料不存在可以采用符合业务要求的响应，避免通过数量或错误细节泄露资源信息。

国内：RAG文档处理与切分策略：文档元数据与来源位置的处理说明权限必须随切片一起保留，避免原文受限而片段失去边界。
国内：RAG知识库更新与维护：借鉴权限变化与派生更新的链路，说明正文中索引、摘要和缓存需要同步失效的要求。
国内：Agent RAG与混合检索工程高频考点：RAG治理中的元数据和授权说明所有检索路径需使用同一业务访问范围。
国外：Document-level access control in Azure AI Search：依据文档级访问控制中用户、组和 ACL 的关联，说明正文中服务端注入可信授权范围、所有检索分支统一执行的设计。
国外：PostgreSQL：Row Security Policies：行级策略与默认拒绝机制提供数据库侧的防护参照，也说明高权限账号为什么可能绕过预期规则。

参考答案