第十篇：实战落地
前九篇我们拆解了 RAG 的每一个零件：从文档解析、切片策略、Embedding 选型、混合检索、重排序、上下文组装，到高级模式、幻觉控制和性能优化。
但把零件拼成一台能跑的车，和造出零件是两回事。
很多团队的问题不是"不会做"，而是"不知道先做什么后做什么"。这篇不讲新算法，只做一件事：把前九篇的知识点串成一条可落地的 SOP。无论你是在做内部知识库、客服机器人还是产品文档助手，这份清单都能帮你避开 80% 的坑。
一、项目启动前的三个灵魂拷问
在写第一行代码前，先回答这三个问题。答案决定了你的技术选型和投入边界。
-
用户是谁？容忍度多高？
- 内部员工查制度 → 准确率要求高，延迟可接受 2-3s
- C 端用户闲聊 → 延迟敏感，准确率要求低
- 合规/医疗/法律场景 → 零容忍幻觉，必须上多层校验
-
数据长什么样？量有多大？
- 纯文本 PDF → 基础 RAG 够用
- 大量表格/扫描件 → 必须上 Unstructured + OCR
- 文档超 1000 页且常问"总结/趋势" → 考虑 GraphRAG
-
上线标准是什么？
- "能用就行" → 基础 RAG + 流式输出
- "不能出错" → 必须建黄金测试集 + 对抗性测试 + 引用校验
- "要扛住流量" → 缓存 + 并行 + 降级方案
经验法则： 不要一上来就搞 GraphRAG 或 Agentic RAG。先把基础 RAG 做到 80 分，再考虑高级模式。
二、完整落地 SOP：六步走
第一步：数据工程（占 40% 精力）
这是最枯燥但最重要的环节。垃圾进，垃圾出。
- 解析：用 Unstructured 处理 PDF，保留标题层级；表格单独提取转 Markdown；扫描件上 PaddleOCR。
- 清洗：正则去页眉页脚、乱码；按段落+标题语义切片（Chunk Size 500-800，Overlap 100-200）。
- 元数据增强 ：给每个 Chunk 打标签
{source, date, dept, doc_version}。这是后续过滤检索和引用溯源的基础。 - 去重：按 Chunk Hash 去重，避免同一内容被索引多次。
交付物：干净的、带元数据的 Chunk 列表。
第二步：索引构建（离线阶段）
-
双路索引：
- 向量库（Milvus/Qdrant/PGVector）：存 BGE-M3 或 bge-large-zh-v1.5 向量。
- 全文索引（Elasticsearch）：存 BM25 倒排索引，title 字段权重设为正文的 3 倍。
-
预计算 ：编写 ETL 脚本，离线完成所有 Embedding 计算。严禁在线算向量。
-
验证：抽样 20 条 Chunk，人工检查语义是否完整、元数据是否正确。
交付物：可查询的向量库 + ES 索引。
第三步：检索链路开发（核心逻辑）
按以下顺序实现，每步都有明确验收标准：
- Query 预处理：拼写纠错 + 同义词扩展（可选）。
- 混合召回：并发调用向量检索和 BM25，各取 Top 20。
- RRF 合并：用 Reciprocal Rank Fusion 合并两路结果，k=60。
- 重排序：BGE-Reranker-Large 精排，取 Top 5-10。
- 上下文组装：三明治排序 + 引用标注 + 截断到 8K tokens 以内。
验收标准：用黄金测试集跑检索评估，Hit@10 > 80%，MRR@10 > 0.6。
第四步：生成与服务化
- Prompt 模板：强制引用 + 拒答话术 + Temperature=0。
- 流式输出：SSE 推送，首字延迟 < 1s。
- 缓存层：语义缓存（相似度 > 0.95 直接返回），TTL 设为文档更新周期。
- 接口封装：FastAPI + 异步 + 限流 + 健康检查。
交付物：可用的 API 端点。
第五步：评估与迭代（上线前必做）
- 建黄金数据集：至少 50 条，覆盖事实类、政策类、对比类、陷阱题。
- 跑自动化评估：Ragas 或 DeepEval，测 Context Recall、Faithfulness、Answer Relevancy。
- 对抗性测试：20 条陷阱题，幻觉率 < 5% 才允许上线。
- 人工抽检：每周抽 30 条线上问答，打分跟踪趋势。
交付物：评估报告 + Bad Case 修复清单。
第六步：上线与监控
-
灰度发布：先开放给 10% 用户，观察 3 天无重大事故再全量。
-
核心监控看板：
- TTFT / P99 延迟
- 缓存命中率
- 拒答率 / 点踩率
- Embedding / Reranker 耗时
-
反馈闭环：用户点踩 → 自动记录 Query + 上下文 → 每周分析 → 反哺切片策略或 Prompt 优化。
三、常见坑与应对策略
| 坑 | 表现 | 应对 |
|---|---|---|
| 切片太碎 | 召回了但信息不全 | 改用父子文档或按标题切片 |
| 检索不准 | Hit Rate 低 | 先检查解析质量，再换 Embedding，最后加 BM25 |
| 回答编造 | 幻觉率高 | 强化 Prompt + 引用校验 + NLI 后置检查 |
| 响应太慢 | 用户流失 | 加语义缓存 + 流式输出 + 模型分级 |
| 文档更新后答案旧 | 缓存未失效 | Cache Key 包含文档版本号 |
| 复杂问题答不好 | 基础 RAG 天花板 | 先确认基础链路无问题，再考虑 GraphRAG 或多跳 |
总结：RAG 是持续运营，不是一次性项目
上线不是终点，而是起点。
RAG 系统的效果高度依赖数据质量和用户反馈。文档在变、用户在变、问题在变，你的系统也必须跟着变。
一个健康的 RAG 项目节奏：
- 每天：看监控看板，处理紧急告警
- 每周：分析 Bad Case，优化 Prompt 或切片策略
- 每月：更新黄金测试集，重新评估，规划下一轮优化
把这套 SOP 跑通一次，你就拥有了可复用的 RAG 工程能力。下次换业务、换数据源，无非是调整参数和替换组件，底层方法论不变。