先这样答
企业知识库 RAG 的坑，我按踩到的频率排。
第一坑：文档质量比想象的差得多。历史 PDF 是扫描件、表格是图片、PPT 里的信息靠排版表达、同一份制度有五个版本的流传件，解析出来全是碎片和噪音，检索的原料就是坏的，后面模型再好也白搭。所以落地的第一步是数据体检：摸清文档库的格式构成、解析损耗率、重复率，先修数据再建索引。
第二坑：数据是活的，系统当它是死的。制度改版、产品更新，知识库还挂着旧文档，答案引用半年前的规定。企业文档天然有版本和生效期，RAG 系统必须管：元数据带版本和生效时间、新旧版本的关系要维护、失效文档要下架而不是留在库里被检索到。
第三坑：权限。销售不该查到薪资制度，实习生不该查到合同库，但向量库默认人人可查。权限必须在检索层接住：按用户身份过滤可检索范围（检索前过滤，或带权限元数据的过滤查询），这一步做晚了返工最大，因为它影响整个索引设计。
第四坑：预期管理。demo 阶段喂的是精选的干净文档，效果惊艳；上线接了全量真实文档，效果跳水。提前把评测集建在真实数据上，给业务方看的是「真实数据 + 目标指标」，不是精心挑过的演示。
第五坑：没人认领运营。知识库 RAG 不是一次性交付物，谁负责文档准入、谁处理「答错」的反馈、多久复盘一次指标，要有明确 owner。多数失效的 RAG 系统，问题出在没人运营，不在算法。
面试官会怎么追问
- 数据体检具体查什么？ 格式分布、解析后的字符损耗率（解析前后的内容量对比）、重复与冲突文档、时效分布（多少文档超过一年没更新）、权限标签覆盖率。
- 权限过滤对检索性能影响大吗？ 检索前过滤会缩小搜索空间，通常反而更快；要点是索引设计时就把权限标签作为一等元数据，而不是事后补。
- 「答错」的责任怎么界定？ 答案必须带引用和文档版本号：答错是资料错了还是系统错了，靠引用定位；这个可追溯性设计要从第一天就有。
回答的坑
- 从「切分策略、模型选型」讲起。企业落地场景里数据工程和权限才是大头，开口第一句就见经验深浅。
- 不提运营归属。RAG 是需要持续运营的系统，主动说这条非常加分。
—— 本题完 ——