RAG 上线检查清单：从 Demo 到 Production
一份面向生产环境的 RAG 发布前检查清单，覆盖数据、检索、生成、权限、评测、观测、成本和运维边界。
很多 RAG 项目不是败在 Demo 阶段，而是败在上线后。Demo 只要能回答几个样例问题就够了；生产系统要面对脏数据、权限、延迟、成本、用户追问、错误引用、灰度发布和持续回归。
这篇文章给出一份 RAG 上线检查清单。它不是为了把系统做复杂，而是帮助你判断：这个 RAG 现在是否已经具备可发布、可观测、可修复、可持续迭代的最低条件。
核心判断
如果一次错误回答无法复现、无法归因、无法进入回归评测集，这个 RAG 还没有真正进入生产状态。
一张上线地图
上线检查不是只检查链路能不能跑通，而是检查每个环节有没有清晰的失败边界和修复入口。
1. 数据是否可用
RAG 的质量上限通常由数据决定。上线前先确认数据不是“看起来已经导入”，而是真的适合被检索和引用。
| 检查项 | 通过标准 |
|---|---|
| 数据范围 | 明确哪些文档进入系统，哪些不进入系统。 |
| 数据新鲜度 | 知道数据更新时间、同步频率和失败告警。 |
| 文档结构 | 标题、层级、表格、列表、代码块没有在解析时严重丢失。 |
| 元数据 | source、owner、updated_at、acl、doc_type 等字段可用。 |
| 去重策略 | 重复版本、历史版本、临时文件不会污染检索结果。 |
最容易被忽略的是“历史版本”。如果新旧制度、旧接口文档、废弃 SOP 混在一个索引里，模型很容易给出看似合理但已经过期的答案。
2. Chunk 是否有工程边界
Chunk 不是越小越好，也不是越大越好。生产系统需要能解释为什么这样切分，以及这个切分方式会在哪些场景失败。
一个实用判断：如果 chunk 被单独放进答案引用里，用户是否能看懂它为什么支持这句话。看不懂，就需要 parent context 或更好的 citation 粒度。
3. 检索是否有基线
上线前不要只看“问几个问题效果还行”。至少要有一组固定评测问题，覆盖高频问题、边界问题、旧版本冲突、同义表达和跨文档问题。
| 能力 | 检查方式 |
|---|---|
| 关键词召回 | 直接术语、产品名、错误码、接口名能命中。 |
| 语义召回 | 用户换一种说法仍能命中正确文档。 |
| 混合检索 | BM25 和向量召回能互补，而不是互相稀释。 |
| 重排效果 | 正确证据能稳定进入最终上下文。 |
| Query Rewrite | 改写不会丢失约束条件、时间范围、权限范围。 |
最小可用门禁可以从 Evidence Recall@K 开始。也就是：正确证据是否进入候选集。这个指标不完美，但它能快速区分“没找到材料”和“找到了但没答好”。
4. 上下文是否可控
RAG 的上下文组装决定了模型实际看到什么。很多 bad case 表面是模型答错，本质是上下文把错误证据、过期证据、无关证据一起塞给了模型。
上线前至少要检查三件事：
- 是否有 token budget，避免上下文无界膨胀。
- 是否有冲突处理，尤其是新旧版本同时出现时。
- 是否保留 citation mapping，答案里的引用能回到具体 chunk 或文档段落。
5. 生成是否受约束
生产级 RAG 的 prompt 不应该只写“请基于资料回答”。它需要明确告诉模型如何处理缺证据、证据冲突、引用、权限和不确定性。
回答规则：
1. 只基于提供的上下文回答。
2. 如果上下文不足，说明缺少什么信息，不要编造。
3. 如果上下文存在冲突，指出冲突来源，并优先使用更新时间更晚或权威级别更高的来源。
4. 关键结论必须给出引用。
5. 不要输出用户无权访问的内容。这里的重点不是 prompt 写得多，而是把产品策略变成可测试的行为约束。
6. 权限和安全是否前置
权限不能只靠模型“自觉不说”。生产 RAG 应该在检索前、检索中和生成后都有边界。
| 层级 | 检查项 |
|---|---|
| Pre-filter | 根据用户身份、租户、团队、文档 ACL 裁剪可检索范围。 |
| Retrieval | 检索结果包含权限元数据，不能混入无权 chunk。 |
| Cache | 缓存 key 包含权限上下文，避免跨用户污染。 |
| Prompt | 不把无权内容放进上下文，再要求模型不要泄露。 |
| Log | 日志和 trace 不长期明文保存敏感内容。 |
如果系统有多租户、企业知识库、客户数据或内部策略文档，权限检查应该是上线门禁，而不是后续优化项。
7. 评测是否能挡发布
评测如果只做展示，不影响发布决策，就很难持续发挥作用。上线前建议至少准备三类样本。
| 样本类型 | 目的 |
|---|---|
| Golden Set | 验证核心高频问题是否稳定。 |
| Bad Case Set | 防止已经修过的问题回归。 |
| Safety Set | 验证拒答、权限、敏感内容和 prompt injection。 |
评测指标可以先少一点，但要稳定：Evidence Recall@K、Context Precision、Faithfulness、Citation Accuracy。延迟和成本也要看，但不要用它们替代质量门禁。
8. Trace 是否足够复现
上线后一定会有坏例。区别在于：你能不能在十分钟内复现它。
一次请求至少应该能查到：
{
"request_id": "req_20260707_001",
"user_scope": "team:ai-platform",
"query": "RAG 召回率下降怎么排查？",
"rewritten_queries": ["RAG recall drop troubleshooting"],
"retrieved_chunks": [
{ "chunk_id": "rag_eval_12", "rank": 1, "score": 0.83, "source": "vector" }
],
"context_chunks": ["rag_eval_12"],
"prompt_version": "rag_answer_v4",
"model": "gpt-5.5",
"latency_ms": 2140,
"citations": ["/docs/llm-wiki-rag/rag-evaluation"]
}不要只保存最终 prompt。只保存 prompt 会让你看不到召回、重排、过滤、上下文裁剪这些关键环节。
9. 延迟和成本是否可解释
RAG 的成本不是只有 LLM token。embedding、向量库、reranker、跨区域访问、日志存储、评测任务都会成为成本项。
| 成本/延迟项 | 优化方向 |
|---|---|
| Embedding | 增量索引、批处理、缓存。 |
| Retrieval | 控制召回路数、Top-K、过滤条件。 |
| Rerank | 分层重排，只对候选子集使用强 reranker。 |
| Context | 压缩、去重、parent-child 策略。 |
| LLM | 流式输出、回答长度限制、模型分级。 |
上线前不一定要做到最低成本，但要知道每次请求贵在哪里、慢在哪里，以及触发降级时应该舍弃哪一层能力。
10. 是否有降级和人工入口
生产系统不能假设所有依赖都稳定。向量库、reranker、LLM、权限服务、文档同步都有可能失败。
检索失败时可以退回关键词检索；reranker 超时时可以使用初排；LLM 超时时可以返回引用材料和明确提示。
高风险问题、低置信度答案、用户差评应该能进入人工审核或工单流，而不是只停留在聊天记录里。
Prompt、索引版本、reranker 配置、模型版本都应该可回滚，并能关联到发布记录和评测报告。
最小上线门槛
如果要压缩成一份最短清单，我会保留这些门槛：
- 数据源、同步频率、权限边界明确。
- Chunk 和元数据经过抽样检查。
- 有固定 Golden Set 和 Bad Case Set。
- 正确证据能稳定进入 Top-K。
- 答案必须能引用到具体证据。
- 无证据、证据冲突、无权限时有明确行为。
- 每次请求有可复现 trace。
- 延迟、成本、错误率、拒答率有基础监控。
- Prompt、索引、模型和配置可以回滚。
相关阅读
- RAG 架构：从检索到生成的最小闭环
- 混合检索：BM25、向量召回与 RRF
- RAG 评测：不要只看模型回答像不像
- RAG Bad Case 分析：从 Trace 到回归评测集
- RAG 可观测性：一次回答背后应该记录什么
结论
RAG 上线不是把检索结果塞进大模型，而是建立一套能持续处理不确定性的工程系统。真正的生产门槛不是“能不能答”，而是答错之后能不能知道为什么错、怎么修、如何防止下次再错。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。