文档更新不是"上传一下就完事"
RAG 系统的资料在持续变化 ✔：政策改、手册改、产品改 ✔。如果更新流程不清晰 ✗，
就会出现：**旧版还在被检索**、**新版没进索引**、**改了没人知道** ✔ —— 三类问题都会让答案出错 ✔。
**把"文档更新"做成流程** ✔：谁改、谁审、何时生效、如何通知 ✔。
一、四个角色（小团队可以兼任，但职责要写明）
```
① 提出者：业务方提出变更（附原因与影响范围 ✔）
② 编写者：改文档（保持结构，便于切分 ✔）
③ 审核者：确认内容正确 + 合规（谁有权批 ✔）
④ 发布者：触发索引更新并确认生效（自动化最好 ✔）
```
**要点**：**审核者与编写者不应是同一个人** ✗ ✔（至少对高影响文档 ✔）。
二、五个必须记录的字段
```
doc_id（稳定不变 ✔）｜ version ｜ 生效时间（effective_from ✔）
变更摘要（一句话 ✔）｜ 审核人 + 时间 ✔
```
**生效时间很关键** ✗：很多变更应"未来生效" ✔（例如新政策下月执行 ✔），
否则会出现"提前按新规回答"的错误 ✔。
三、更新要自动触发索引（别靠人记得 ✗）
```
文档库变更 → 触发解析/切分/嵌入 → 生成新版本 → 切换 current → 旧版标 superseded
```
四、通知谁
五、三个反模式
六、一个小检查清单
```
□ 每次更新有 doc_id / version / 生效时间 / 审核人
□ 索引更新自动触发，且删除同步
□ 更新后自动抽查 5 个问题
□ 旧版标 superseded（不删）
□ 值班与客服收到通知
□ 高影响变更提前对外说明
```
一条判据
> 从"业务方提出改一份文档"到"用户能看到新答案" ✔，平均要多久 ✔？谁负责 ✔？
> 答不出，说明更新还没有流程 ✗。