RAG 知识库上线后的持续运营，不是定期上传文件，而是把 Badcase 分类、固定评测集、文档版本、灰度发布和回滚证据串成一个可复验流程。资料更新不应直接覆盖线上索引；先生成待发布版本，用同一组问题回归，再面向试点部门或指定用户灰度。出现引用旧版、权限串读、拒答失效或回答偏差时，应能把线上指针切回上个可用版本，并保留本次变更的来源、责任人与复核记录。
把每次资料变更当成一次可验收发布
知识管理员收到制度、产品手册或客服口径后，先登记来源，不要立即进入线上索引。每条资料至少保留以下字段，后续才能解释某次回答为什么引用了它：
- source_id 与文件版本：稳定标识资料，区分修订版、附件和重复文件。
- 生效与失效时间：明确何时开始使用，旧版何时停止参与检索。
- 适用范围与权限：部门、角色、客户等级或项目范围分别记录。
- 业务负责人：由能判断口径正确的人确认，不把判断责任全部交给技术团队。
- 变更原因与前一版本：方便回溯差异，也为回滚保留目标。
资料清洗与分层可参考企业知识库 RAG 服务页。如果不同制度同时有效，还要先处理版本优先级，而不是让检索结果自行决定答案。
Badcase 要落到可处理的原因，而不是只记“回答不好”
运营人员应把真实问答中的问题按处理动作分类：无资料由业务补文档；资料过期由知识管理员下线旧版；召回偏差检查切分、元数据与检索条件；生成扩写调整回答约束；权限异常检查身份透传与检索过滤；工具或接口失败进入人工队列。每条 Badcase 记录问题、用户角色、命中片段、回答、期望结果、严重程度和处理人，修复后回填复验结果。
对于客服场景，低置信度、投诉、退款、合同、隐私等问题还应配置转人工边界。可结合AI 客服与知识库服务页核对渠道、工单和人工接管链路。
固定评测集要覆盖正常、边界和越权问题
如果每次发布都换一批测试题，就无法判断版本是否退步。评测集应从真实高频问题和 Badcase 中沉淀，并为每道题记录期望答案要点、必须引用的来源、禁止出现的内容、允许回答的角色、是否必须转人工。回归时分别检查召回、引用、答案、拒答、权限和多轮追问，不用一个总分掩盖高风险错误。
- 正常题：验证常见问题能引用当前有效资料。
- 旧版题：确认失效制度不再被命中。
- 同题异权：不同角色提同一问题时，只返回各自可见内容。
- 诱导题：尝试绕过权限、索取隐私或让模型补写无依据结论。
- 异常题：模拟检索超时、资料缺失和接口失败，检查拒答与转人工。
权限回归可继续参考RAG 同题异权与越权测试清单。
灰度发布要把新旧索引和观察范围分开
一次资料更新可以先构建独立索引版本，冻结本次文件清单和配置，再完成离线回归。通过后只向试点部门、内部账号或指定业务线开放，并在同一时段记录新旧版本的命中来源、拒答、转人工和 Badcase。观察范围、放行条件和停止条件应在发布前写明，不能上线后再临时判断。
灰度阶段发现问题时，优先回退索引版本或路由指针，不要边改线上文档边继续放量。若变更同时涉及提示词、重排、模型或权限规则，需要分别记录版本，避免回滚知识库后仍被其他配置影响。
回滚完成不等于问题结束，还要核对业务结果
回滚后要重新执行触发问题的测试题，确认引用回到有效版本、权限恢复、缓存失效，并检查工单、订单或审批等外部系统有没有留下重复写入或错误状态。对于调用业务接口的智能体，还要核对幂等键、补偿记录和人工处置队列。单纯看到页面恢复，不代表整条业务链路已经复原。
哪些情况先不要直接自动发布知识
资料没有负责人、版本互相冲突、权限标签缺失、评测集尚未建立，或业务方无法定义错误答案的处置方式时，先保留人工审核与小范围试点。高风险制度、合同、财务、隐私和对外承诺不宜由系统自动合并结论。多数企业项目也不是从零训练模型，而是基于成熟大模型、企业知识库、权限控制、业务接口与人工复核完成软件化落地。
聚匠科技可围绕AI 智能体与 RAG 项目整理资料版本、评测集、灰度和回滚交付物；验收应以可重复的测试题、引用来源、权限日志和异常处理记录为准。
说明：本文为通用落地建议，具体资料权限、发布流程和验收口径需结合企业制度、系统架构与合同范围确定。
