审核者与编写者不应是同一个人。
文档更新不是"上传一下就完事"
RAG 系统的资料在持续变化 ✔：政策改、手册改、产品改 ✔。如果更新流程不清晰 ✗，
就会出现：旧版还在被检索、新版没进索引、改了没人知道 ✔ —— 三类问题都会让答案出错 ✔。
把"文档更新"做成流程 ✔：谁改、谁审、何时生效、如何通知 ✔。
一、四个角色（小团队可以兼任，但职责要写明）
```
① 提出者：业务方提出变更（附原因与影响范围 ✔）
② 编写者：改文档（保持结构，便于切分 ✔）
③ 审核者：确认内容正确 + 合规（谁有权批 ✔）
④ 发布者：触发索引更新并确认生效（自动化最好 ✔）
```
要点：审核者与编写者不应是同一个人 ✗ ✔（至少对高影响文档 ✔）。
二、五个必须记录的字段
```
doc_id（稳定不变 ✔）｜ version ｜ 生效时间（effective_from ✔）
变更摘要（一句话 ✔）｜ 审核人 + 时间 ✔
```
生效时间很关键 ✗：很多变更应"未来生效" ✔（例如新政策下月执行 ✔），
否则会出现"提前按新规回答"的错误 ✔。
三、更新要自动触发索引（别靠人记得 ✗）
```
文档库变更 → 触发解析/切分/嵌入 → 生成新版本 → 切换 current → 旧版标 superseded
```
· 删除要同步（下线文档必须从索引移除 ✔）；
· 重建要有灰度（新索引与旧索引并存，切流后再删旧 ✔ —— 见新鲜度那篇 ✔）；
· 验证：更新后自动抽查 5 个相关问题 ✔，确认新内容可检索 ✔。
四、通知谁
· 值班/客服（他们最先被用户问到 ✔）；
· 产品/运营（涉及口径变化 ✔）；
· 高影响变更：提前通知用户 ✔（见变更说明那篇 ✔）。
五、三个反模式
· 直接覆盖文件 ✗（没有版本，无法回退 ✔）；
· 改了不通知 ✗（一线还在按旧口径答 ✔）；
· 上传即生效 ✗（未审核内容进索引 ✔）。
六、一个小检查清单
```
□ 每次更新有 doc_id / version / 生效时间 / 审核人
□ 索引更新自动触发，且删除同步
□ 更新后自动抽查 5 个问题
□ 旧版标 superseded（不删）
□ 值班与客服收到通知
□ 高影响变更提前对外说明
```
一条判据
> 从"业务方提出改一份文档"到"用户能看到新答案" ✔，平均要多久 ✔？谁负责 ✔？
> 答不出，说明更新还没有流程 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把重复问题聚类：从处理个案到修一类问题
下一篇：AI 功能的分层定价：把成本映射到价格 →
第 112 / 171 篇