RAG 运维
这页面向管理员、实施和知识库维护者，重点不是解释算法，而是回答“日常要怎么把知识库维护在一个稳定、可解释、可修复的状态”。
标准操作顺序
- 创建知识源
- 上传少量代表性文档
- 运行 inspect 或 ingestion
- 用 Retrieval Test 验证真实问题是否能命中
- 挂载到目标 Agent
- 在在线对话中复验
- 如果线上效果异常，再进入 debug / inspection / rebuild 链路
关键入口
- Studio
Knowledge Sources - Studio
Agent Detail - Conversations 中的 RAG debug 与 correction publish
- Manual inspection
- Snapshot rebuild
日常维护动作
1. 新建知识源
适合放进同一个 source 的内容应满足：
- 主题相对单一
- chunking 策略需求相近
- 会被同一批 Agent 挂载
不要把完全不同业务线的文档长期混进同一个 source。
2. 小批量导入，再放大
推荐先上传少量高代表性文档，验证：
- parser 是否能稳定解析
- chunking 是否合理
- retrieval test 是否能命中真实问题
验证通过后再扩大导入范围。
3. 挂载到 Agent 前先做 Retrieval Test
不要先把 source 挂到线上 Agent，再用真实用户问题试错。
更稳妥的顺序是：
- source 内完成 ingestion
- 对若干真实 query 运行 retrieval test
- 确认命中质量可接受后再挂载
出问题时怎么分流
症状 A: 文档上传成功，但一直不可用
优先检查：
- document status
- ingestion job 状态
- parser / embedding 阶段是否报错
症状 B: 文档显示 indexed，但检索不到
优先动作：
- 跑 RAG debug
- 看 active sources 是否正确
- 跑 manual inspection 的
vector_health
如果向量异常，再考虑 snapshot rebuild。
症状 C: 检索能命中，但相关性很差
优先动作：
- 跑 retrieval test
- 检查 chunking 是否过碎或过粗
- 用 manual inspection 的
chunking_preview预估换策略后的形态 - 再决定要不要重跑 ingestion
症状 D: 对话答案里有稳定错误，需要长期修补
不要手动改 managed correction source。
正确动作是：
- 在对话上下文里保存 correction draft
- 走 correction publish
- 让系统生成 managed correction source 文档并进入正式检索链路
当前运维工具分别适合解决什么问题
| 工具 | 适合的问题 |
|---|---|
| Retrieval Test | 某个 query 是否能命中正确 chunk |
| RAG Debug | 为什么这次召回 / 没召回 |
Manual Inspection vector_health |
向量是否实际存在于 Qdrant |
Manual Inspection chunking_preview |
另一种 chunking 策略会切成什么样 |
| Snapshot Rebuild | parse snapshot 还在，但现有索引需要重建 |
| Correction Publish | 把线上纠错变成正式知识输入 |
操作原则
- 一个知识源尽量只承载单一业务主题
- 文档替换时避免新旧冲突版本长期并存
- 先用真实问题做 retrieval test，再扩大导入范围
- 调 chunking 前先做 preview，不要直接重跑全量 ingestion
- 发现线上知识错误时优先走 correction publish，而不是直接篡改历史数据
- 不要把
indexed当成“绝对健康”，还要关注vector_status
什么时候需要重建
考虑 rebuild 的典型场景：
- parse snapshot 存在，但当前向量状态异常
- chunking 策略需要整体切换
- 文档内容没有问题，但索引状态已经漂移
如果只是 query 选得不好，先做 retrieval test 和 debug，不要立刻重建。