# FDE W3D3 评测题 · 权限和文档治理（Chunk 级 ACL / 失效删除 / 死信重试） > 配套手册：《FDE-W3D3-权限和文档治理-学习手册.html》 > 定位：W3 Day3 · A 级（必须掌握，面试核心） > 场景背景：医疗保险 / 特药理赔 / 保险知识库（候选人 36 岁，Java + 大数据 + 医疗，有 ETL / 数据治理经验） ## 评测说明 - 共 **13 题**，按难度分 4 级：**L1 基础（3 题）/ L2 进阶（4 题）/ L3 深度（3 题）/ L4 场景（3 题）**。 - 每题含：**考察点**、**评分维度**、**参考答案（`
` 折叠，点击展开）**。 - 评分采用 5 分制（0=不会 / 1=方向错 / 2=关键点缺 / 3=基本正确 / 4=完整 / 5=完整且有工程洞察）。 - 达标线见文末「评分汇总表 + 达标线」。 --- ## L1 基础（概念与定义） ### Q1（L1 基础）企业 RAG 为什么必须做权限控制和文档治理？ **考察点**：理解治理是合规红线，而非可选项。 **评分维度**： - 能否联系医疗/保险受个保法、监管约束，越权泄露客户健康信息是事故； - 能否说明"不仅是能搜到，更要搜得对的人、旧的退得去、错的兜得住"； - 是否点出治理与 W3D1 元数据强绑定。
参考答案 消费级 RAG 不用管权限，但企业 RAG 直接关系商业机密与个人隐私。医疗保险受《个人信息保护法》与保险监管约束，越权泄露客户健康信息是直接违规事故。治理三命题：权限（谁该看→Chunk 级 ACL）、生命周期（旧的怎么退场→失效/删除/增量）、可靠性（错的怎么兜→重试/死信/一致性校验）。它不是"锦上添花"而是上线前置条件，且与 W3D1 的元数据（ACL/状态/版本字段）强绑定。
### Q2（L1 基础）什么是 Chunk 级 ACL？为什么不做 Document 级？ **考察点**：理解权限粒度与最小授权原则。 **评分维度**： - 能否说明 ACL 挂在每个 chunk 而非整篇文档； - 能否举例"一份 PDF 里混着公开与机密段落"； - 是否提到角色/部门/用户三维 + 默认最小权限。
参考答案 Chunk 级 ACL 是把访问控制列表挂到每个切片上（而非整篇文档）。因为一份 PDF 里常混着公开段落与仅限理赔审核岗的机密段落，Document 级太粗——要么过度暴露要么过度限制。Chunk 级遵循最小授权，用"角色+部门+用户"三维组合（命中任一即放行），并默认最小权限（未标注当 internal），防止漏配泄露。chunk 默认继承文档级 ACL，敏感段落可单独收紧。
### Q3（L1 基础）文档"失效、删除、替换"三种下线语义有什么区别？ **考察点**：区分生命周期操作的不同处理。 **评分维度**： - 失效：保留审计，标 status=deprecated，检索排除； - 删除：物理移除 + 删除日志； - 替换：新 active + 旧 deprecated，原子切换。
参考答案 三种语义：① 失效（deprecate）——条款过期但保留审计，chunk.status=deprecated，检索过滤排除，可回滚；② 删除（delete）——彻底移除向量+元数据，记删除日志与备份点；③ 替换（replace）——新版上线旧版退场，新 chunk active + 旧 chunk deprecated，要求原子切换避免用户看到混合版本。医疗合规优先软失效，仅确认无审计价值才硬删。
--- ## L2 进阶（设计与机制） ### Q4（L2 进阶）检索时怎么用 ES 实现 ACL 过滤？为什么必须在检索层而非应用层？ **考察点**：能写出过滤查询并论证检索层过滤的必要性。 **评分维度**： - 能否写 bool.filter + terms + minimum_should_match=1； - 能否说明身份从服务端会话取、不信任前端； - 能否论证应用层遮罩可被直查向量库绕过。
参考答案 ES 用 `bool.filter` 上下文挂 ACL 条件：`terms` 查询匹配用户角色/部门/显式用户集合（命中任一即放行，minimum_should_match=1），filter 不评分还能被缓存提速。关键：用户身份必须从服务端会话/网关取，不能信前端传的角色（可伪造）。权限过滤必须放检索阶段（预过滤），让越权 chunk 根本不进候选——若只在应用层"展示时遮罩"，攻击者可直查向量库/API 绕过，造成泄露。传给 LLM 的也必须是已过滤 chunks。
### Q5（L2 进阶）增量更新时如何保证"原文件、解析结果、向量索引"三者一致？ **考察点**：理解一致性三要素与级联更新。 **评分维度**： - 能否说明增量只更新受影响 chunk 并级联更新另两份； - 能否列出三要素（版本/计数/引用一致）； - 是否提到一致性校验与修复队列。
参考答案 增量更新：定位变更 chunk → 重解析 → 重算 embedding → 原子替换旧向量，并级联更新另两份数据，防索引腐化。一致性三要素：① 版本一致（chunk 的 doc_version/embedding_version 与实际匹配）；② 计数一致（document 的 chunk 数 = 索引中该 doc 的 active chunk 数）；③ 引用一致（chunk 的 source/page 指向真实内容）。定期/事件触发一致性校验（hash 比对、chunk 数=向量数、status/version 一致、文档↔chunk 映射），不一致自动进修复队列。
### Q6（L2 进阶）失败重试与死信队列（DLQ）怎么设计？为什么不能无限重试？ **考察点**：理解重试策略与死信隔离。 **评分维度**： - 能否区分瞬时故障（退避重试）vs 持久错误（进 DLQ）； - 能否说明 DLQ 隔离避免主流程被拖死； - 是否提到死信记录内容（task_id/阶段/错误/重试次数）与重放。
参考答案 重试策略：瞬时故障（网络抖、限流）用立即重试（短退避）或指数退避（带 jitter 防风暴）；持久错误（格式不支持、权限错）重试也没用，超过最大次数进死信队列（DLQ）隔离，告警+人工/定时重放。无限重试持久错误会占满 worker、产生错误结果、拖垮整个摄取管道。死信记录至少含 task_id、失败阶段、错误类型、原始输入引用、重试次数、payload 快照，便于排查与重放。这正是 ETL"失败进异常表"的翻版。
### Q7（L2 进阶）LangChain 自查询检索器（Self-Query）在权限场景怎么用才安全？ **考察点**：理解自查询原理与权限不外包给 LLM。 **评分维度**： - 能否说明 LLM 从自然语言抽结构化 filter； - 能否强调生成的 filter 须与服务端真实 ACL 取交集； - 是否提到防 prompt 注入越权 + 字段白名单。
参考答案 自查询检索器用 LLM 从自然语言问题自动抽取 metadata filter（如"理赔审核岗能看的靶向药范围"→ allowed_roles contains claims_auditor），减少手写规则。但安全底线：LLM 生成的 filter 必须再和服务端真实 ACL 取交集，绝不能让 LLM 决定"用户能看到什么"——否则被 prompt 注入就能越权。同时要字段白名单校验，非法字段直接拒绝；高频场景可缓存或降级为规则，避免每次多一次 LLM 调用。
--- ## L3 深度（原理与权衡） ### Q8（L3 深度）一致性校验具体校验哪四项？发现不一致怎么处理？ **考察点**：能把"三份数据一致性"落到可执行校验项。 **评分维度**： - 文件↔解析（hash 比对）、解析↔索引（chunk 数=向量数）； - 索引↔元数据（status/version）、文档↔chunk 映射（计数）； - 是否强调"可修复"而非只报警 + 幂等。
参考答案 四项校验：① 文件↔解析：重算 file_hash 比对，抽样全文比对，不一致重新解析；② 解析↔索引：每个 chunk 应有对应向量，向量数=active chunk 数，缺则补算；③ 索引↔元数据：chunk 的 status/version 与实际一致，错则修正；④ 文档↔chunk 映射：doc.chunk_count = 索引中该 doc 的 chunk 数，清理孤儿/补建。处理原则：校验必须"可修复"——发现缺失向量自动进修复队列重算，而非只报警；修复要幂等，定时全量兜底+增量查变更 doc；校验任务自身要超时重试。
### Q9（L3 深度）软失效（deprecated）相比硬删除有什么利弊？何时才硬删？ **考察点**：权衡审计可追溯与存储/性能。 **评分维度**： - 能否说明软失效保留审计链、支持回滚、零风险； - 能否说明软失效长期不清理会占存储、拖慢索引； - 是否点出硬删前提（无审计价值+合规允许+留日志备份）。
参考答案 软失效（status=deprecated）优势：保留完整审计链、支持一键回滚、零误删风险，医疗合规首选。劣势：长期不物理清理会占存储、拖慢索引（检索要过滤掉）。硬删除前提：确认无审计价值、合规允许、并留删除日志与备份点。工程上做法：先软失效，定期出"软失效占比"报表，对确无价值的批量硬删并归档；替换操作要原子切换新旧，避免过渡期混合版本被召回。
### Q10（L3 深度）权限/治理类评测集该怎么设计才能"测出越权漏洞"？ **考察点**：理解负向 case 在权限评测中的必要性。 **评分维度**： - 能否说明必须包含"越权应召回 0"的负向 case； - 能否列出权限/失效/死信三类新增 case； - 是否提到评测集版本同步（eval_v2）。
参考答案 权限类评测必须含负向 case，否则只测正向会漏掉最危险的越权漏洞。W3D1 的 10 个基础 case 扩到 30：+10 权限/ACL case（普通客服检索"高净值特药额度"应召回 0；理赔审核岗同内容应命中）+10 失效/删除/一致性/重试 case（手册失效后旧条款不应再召回、解析失败不污染检索）。关键：验证"旧版本确实不再被召回""失败任务不污染结果"。评测集要同步版本（eval_v2）才可比。
--- ## L4 场景（医疗保险实战） ### Q11（L4 场景）一名普通客服检索"高净值客户特药年度额度"却返回了机密内容，请定位并修复。 **考察点**：综合诊断越权召回故障。 **评分维度**： - 能否定位：ACL 没挂/过滤没生效/身份校验缺失/应用层遮罩被绕过； - 能否给出修复：chunk 挂 ACL + 检索层 bool.filter + 服务端身份； - 是否提到补"越权应召回 0"的评测 case。
参考答案 定位：① chunk 未挂 ACL 或默认权限设成公开；② 检索时没用 bool.filter 做 ACL 预过滤（只在前端遮罩）；③ 身份从前端传可被伪造；④ 自查询生成的 filter 没和真实 ACL 取交集。修复：给机密 chunk 挂 acl（allowed_roles 限理赔审核岗，默认最小权限），检索用 ES bool.filter + terms 在服务端做预过滤，身份从会话取；补"普通客服检索应召回 0"的负向评测 case 防回归。核心是权限必须在检索层硬隔离。
### Q12（L4 场景）《特药理赔手册》修订后，用户仍搜到旧版条款，请给出排查与修复。 **考察点**：诊断失效/替换一致性故障。 **评分维度**： - 能否定位：替换非原子、软失效没同步文档→chunk 映射、旧 chunk 仍 active； - 能否给出：原子切换 + 一致性校验 + 修复队列； - 是否提到用 doc_version/status 字段追踪。
参考答案 排查：① 替换非原子——新旧切换瞬间用户看到混合版本；② 失效后没同步"文档→chunk"映射，旧 chunk 仍是 status=active 被召回；③ 增量更新只改了向量忘了更新 doc_version，版本漂移。修复：用"先标新 active 再标旧 deprecated"或版本指针原子切换；跑一致性校验（doc.chunk_count = 索引 active 数、status/version 一致），发现孤儿/旧 active 进修复队列；用 chunk 上的 doc_version/status 字段全程追踪，确保检索 filter 排除 deprecated。
### Q13（L4 场景）某批扫描件 PDF 解析失败，导致这些手册"搜不到也无人知"，如何设计兜底？ **考察点**：失败隔离与可观测性设计。 **评分维度**： - 能否说明解析失败进 DLQ + 告警，主流程不卡死； - 能否说明监控"死信堆积/向量覆盖度"及早发现缺口； - 是否提到补"解析失败不污染检索"的评测 case。
参考答案 兜底设计：① 解析失败按持久错误进死信队列（DLQ），带 task_id/阶段/错误/重试次数，告警+定时重放，主摄取管道不被拖死；② 监控"死信堆积""向量覆盖度（active chunk 有向量比例）""孤儿 chunk"，死信>0 即处理，避免"搜不到也无人知"的知识库缺口；③ 解析失败的手册不应产生脏 chunk 污染检索（失败即不写索引）；④ 补"解析失败不污染检索结果"的评测 case。扫描件务必走 OCR 路径（呼应 W3D1），否则抽空文本也是解析"成功"的假象。
--- ## 评分汇总表 | 题号 | 等级 | 考察点 | 满分 | |------|------|--------|------| | Q1 | L1 基础 | 为什么必须治理 | 5 | | Q2 | L1 基础 | Chunk 级 ACL 与粒度 | 5 | | Q3 | L1 基础 | 失效/删除/替换语义 | 5 | | Q4 | L2 进阶 | ES ACL 过滤 + 检索层 | 5 | | Q5 | L2 进阶 | 增量更新一致性 | 5 | | Q6 | L2 进阶 | 重试与死信队列 | 5 | | Q7 | L2 进阶 | 自查询检索器安全 | 5 | | Q8 | L3 深度 | 一致性校验四项 | 5 | | Q9 | L3 深度 | 软失效 vs 硬删除 | 5 | | Q10 | L3 深度 | 权限评测设计 | 5 | | Q11 | L4 场景 | 越权召回故障 | 5 | | Q12 | L4 场景 | 旧版条款召回 | 5 | | Q13 | L4 场景 | 解析失败兜底 | 5 | | **合计** | — | — | **65** | ### 达标线 - **合格线（L1+L2 全对 + L3 基本正确）**：总分 ≥ 45，且 L1/L2 不得有 0~1 分题。能讲清 Chunk 级 ACL 怎么实现、检索时怎么过滤（达标线①）。 - **优秀线（面试通过）**：总分 ≥ 55，L3/L4 能完整回答并展现工程洞察（如越权负向评测、原子替换、死信隔离）。能讲清文档更新/删除时索引一致性怎么保证、死信和重试怎么设计（达标线②）。 - **一票否决**：认为"权限在应用层遮罩就够了"或"解析失败重试无限次没关系"——基础认知错误，直接判不合格。 > 自评方法：先口头作答，再展开 `
` 对照；L3/L4 答不全的回到手册对应章节（s2/s3/s4/s6/s7/s12/s13）重读「🎤面试话术」「⚠易错点」。