答案摘要：RAG 知识库项目应按资料台账、解析抽检、权限过滤、检索链路、固定评测和灰度上线六个关口推进。聚匠科技在交付中会把资料负责人、文档版本、用户身份、命中片段、引用来源与发布批次保留为可复核证据；没有权威资料、权限边界或标准问题集时，先做小范围验证，不直接开放全员使用。
立项时先定义任务，不按文件数量定范围
“把公司文档都放进知识库”不是可验收的目标。客服负责人、业务负责人和 IT 负责人应先选出需要解决的任务，例如售后规则查询、产品参数检索、内部制度问答或设备故障排查，再为每类任务写清用户、输入、期望引用、拒答条件和人工接管人。资料准备方法可继续参考 企业资料清洗与分层。
- 问题范围：收集真实问法、同义表达、缺少条件的问法和不应回答的问题。
- 资料范围：确认正式制度、手册、FAQ、表格与附件，排除草稿和无责任人的文件。
- 角色范围：区分访客、员工、部门主管、管理员和外部协作人员。
- 结果范围：约定回答、引用、拒答、追问和转人工分别何时出现。
项目入口可从 企业知识库 RAG核对能力边界。PoC 只选一个责任清楚的业务范围，比一开始接入所有部门更容易判断资料和检索是否真的可用。
资料进入索引前要有台账和解析抽检
每份资料至少登记 document_id、版本、生效状态、适用组织、密级、负责人和替代关系。扫描 PDF、复杂表格、图片附件和多栏文档不能只看“上传成功”，应抽查标题层级、表头、页码、附件关系和关键字段是否被完整解析。解析失败的文件进入待处理队列，不应混入正式索引。
| 关口 | 需要保留的证据 | 不通过时的处理 |
|---|---|---|
| 资料登记 | 来源、版本、负责人、有效期与权限 | 退回补字段或确认责任人 |
| 解析抽检 | 原文与解析文本、表格和附件对照 | 换解析方式或人工整理 |
| 切片检查 | 章节、产品、时间和适用对象上下文 | 调整结构与元数据后重建 |
| 发布批次 | 文件清单、索引版本和配置版本 | 保持旧版在线，问题修复后再发布 |
权限必须在检索前生效
页面隐藏目录、提示词提醒或模型拒答都不能代替权限控制。应用层应把登录身份、部门、项目组、文档密级和授权有效期转换为检索过滤条件，模型只接收当前任务允许使用的片段。引用链接、附件下载、分享页面和后续工具调用还要再次校验身份。
上线前至少用同一问题测试有权、部分有权、无权和权限刚被撤回的账号，核对候选片段与最终回答。更完整的异常样本见 RAG 同题异权与越权测试。云模型 API、混合私有化和全本地推理会改变数据流向与运维责任，但不会自动修复身份和文档治理缺口；有内网要求时可结合 私有化部署评估原文、索引、日志和模型服务的位置。
评测要能定位检索、重排和生成哪一层出错
固定问题集不只记录“回答对不对”，还应保存期望要点、必须引用的资料、允许查看的角色、禁止出现的信息和是否需要人工处理。每次变更文档、切片、嵌入模型、重排、提示词或生成模型后，复跑同一组样本，并分别核对召回、引用、回答、拒答与权限。
- 正常问题能命中当前有效资料，并显示可访问的引用。
- 无答案问题不补写无依据结论，能够拒答或转人工。
- 旧版和冲突资料不会被相似度直接带入正式答案。
- 无权限账号既看不到正文，也不能从标题、引用或缓存推断敏感内容。
- 检索超时、模型失败或引用失效时，有明确降级与问题编号。
评测结果应能追踪到问题、用户身份、命中片段、知识版本、检索配置、模型配置和最终回答。不要只给一个总分，也不要因为更换模型后表达更流畅，就认定资料和检索问题已经解决。
灰度上线前设置放行、停止和回退条件
通过离线评测后，先向内部账号或单一部门开放，记录新版本的命中来源、拒答、转人工和 Badcase。放行条件可以围绕关键问题全部通过、越权样本全部阻断、引用可访问和异常路径可复验；发现旧版引用、权限串读或业务接口产生错误状态时，停止扩大范围，并回退索引、检索配置或路由指针。
以下情况先不要全量上线：资料没有负责人，版本关系不清，权限变化无法同步，问题集只有演示题，或业务方尚未约定错误回答的处置人。多数 RAG 项目也不是从零训练模型，而是把成熟大模型、受控知识库、身份权限、业务接口和人工复核组成可持续运营的系统。上线后的 Badcase、版本发布和回滚可参考 RAG 知识库持续运营方法。
交付时应包含资料台账、解析与切片规则、权限映射、固定评测集、发布记录、监控告警、备份回退和运营责任表。只有团队能用同一问题重复得到符合版本与权限的结果，才算完成可复验的上线。
说明：本文为企业 RAG 知识库建设与验收的通用建议，具体数据范围、部署方式、权限规则和验收口径应结合企业制度、系统架构与合同范围确定。
