RAG 进阶：生产级 RAG 的系统工程实战
RAG（检索增强生成）是企业让大模型"基于自家知识"回答的主流方案。但"照着教程拼一个 demo"和"做出生产级准、全、稳的系统"之间，隔着一整个工程鸿沟——demo 能答对的问题，生产里可能十答九错。本文不再罗列名词，而是把 RAG 拆成索引、查询、生成、评估四大子系统，给出每个子系统的关键决策与进阶实践。
1、先把架构看清：不是流水线，是四大子系统
┌─ 索引侧（离线）─ 切块 → Embedding → 写入向量库（含元数据）
│
├─ 查询侧（在线）─ 查询改写 → 混合检索 → Rerank → 上下文组装
│
├─ 生成侧（在线）─ 约束式生成 → 引用回链 → 拒答兜底
│
└─ 评估侧（持续）─ RAGAS 指标 + Bad Case 闭环 + 在线监控大多数失败的项目，都是只做了"索引 + 一把向量检索 + 生成"，忽略了查询侧的精修与评估侧的闭环。下面逐个子系统拆解。
2、索引侧：切块决定召回上限
"垃圾进，垃圾出"，切块质量是 RAG 的地基。别再机械地"每 500 字一刀"。递归切块：按"章节→段落→句子"的层级分隔符逐级切，尽量沿语义边界。父子块（small-to-big）：用小块做检索（匹配精准），命中的块对应返回大块给模型（上下文完整），兼顾精度与完整。结构化内容特处理：表格、代码别粗暴切断，保留结构或整体成块。保留元数据：来源、标题、章节、时间、权限标签，后面过滤与引用全靠它。Embedding 选型：按语种和任务选（bge-m3、text-embedding-3 等），注意维度与多语言能力。
3、查询侧：RAG 提质的主战场
这是最容易被忽略、却回报最高的一环，分四步：
① 查询改写。用户提问往往口语化、有指代、含多义。先用模型优化：指代消解（把"它"还原成实体）、查询分解（把复合问题拆成子问题）、HyDE（先让模型"假设答案"，再用假设答案去检索）、多查询扩展（生成多个角度并行检索再合并）。
用户问："它支持自定义吗？" （上文在聊某产品）
↓ 指代消解 + 改写
"XX 产品是否支持自定义配置？" → 去检索② 混合检索。纯向量擅长"语义相似"，却会漏掉精确匹配（人名、编号、术语）。生产级标配是向量 + 关键词（BM25）+ 元数据过滤多路召回，再用 RRF（倒数排名融合）合并去重。
查询 → 向量检索（语义）┐
→ BM25（精确匹配）┤→ RRF 融合去重 → 候选集
→ 元数据过滤（权限/时间）┘③ 重排（Rerank）。召回追求"别漏"，可以宽松；重排追求"排准"，用更强的 cross-encoder（如 bge-reranker）对候选逐一打分，把最相关的顶到前面。这一步成本低、提升明显，是性价比最高的优化。
④ 上下文组装。去重、去噪、按相关度排序，并控制总长度——警惕"lost in the middle"（塞太多片段，模型反而忽略中间内容）。必要时只喂 Top-3～5 精排结果。
4、生成侧：让答案"有据可依、不胡说"
生成的关键不是"写得漂亮"，而是"只基于检索内容"。用 system prompt 强约束："仅根据提供的上下文回答，不在上下文中的内容就回答'资料中未提及'"；要求引用回链（每条结论标注来源片段）；不确定时显式拒答。这三条能极大压低幻觉，让答案可追溯、可核验。
5、进阶能力：Agentic RAG、GraphRAG、结构化 RAG
基础 RAG 是"一问一检索"，进阶玩法让它更聪明：Agentic RAG——把检索变成 Agent 的工具，由模型自己决定"要不要查、查哪个库、查到的够不够、要不要再查一次"，能自纠正、做多跳推理（复杂问题分解成多次检索）。GraphRAG——先从文档抽取实体与关系建知识图谱，检索时走"关系"而非只靠相似度，擅长"某主题涉及哪些实体、它们什么关系"这类多跳问题。结构化 RAG——对表格/数据库用 Text-to-SQL，对 API 用函数调用，混合非结构化检索。
// Agentic RAG 循环
问题 → 判断需要检索？→ 检索 → 够吗？
↑ ↓ 不够
└── 改写/换库再查 ←
够 → 生成答案（带引用）6、评估：没有度量就没有改进
凭"感觉"调 RAG 是黑箱。用 RAGAS 等框架量化四个维度：RAGAS 官网。
Faithfulness（忠实度） 答案是否忠于检索内容、不编造
Answer Relevancy 答案是否切题
Context Precision 检索片段是否真的相关（精不精）
Context Recall 该召回的是否都召回了（全不全）再配一个"Bad Case 闭环"：把线上答错的案例收集起来，标注、回归、回归，驱动迭代。离线指标 + 在线 bad case，缺一不可。
7、生产化：增量索引、权限、缓存、监控
上生产还要补工程课：增量索引（文档更新只重算变化部分，别全量重建）；访问控制（按用户权限过滤可见片段，别把机密答给无权的人）；语义缓存（相似问题直接复用历史答案，省成本降延迟）；监控（召回率、引用命中率、拒答率、延迟、成本）。这些"无聊"的工作，恰恰决定 RAG 能不能稳定上线。
8、常见坑与排查
坑 1：答非所问。多半是召回不准 → 上 Rerank、查改写。坑 2：该答的答不出。召回漏了 → 加混合检索、放宽 Top-K。坑 3：胡编。生成没约束 → 强 system prompt + 拒答 + 引用。坑 4：表格/数字答错。结构化内容被切碎 → 特殊处理或上 Text-to-SQL。坑 5：改一处不知道好坏。没评估 → 先建 RAGAS + bad case，再谈优化。
9、总结
生产级 RAG 是"系统工程"而非"拼接 demo"。索引侧做好切块与元数据，查询侧做好改写+混合检索+Rerank+组装，生成侧做好约束+引用+拒答，再用 RAGAS 与 bad case 持续评估，最后用增量索引/权限/缓存/监控把它推上生产。Agentic RAG、GraphRAG 是更聪明的进阶形态。
关键要点：
- 四大子系统：索引 / 查询 / 生成 / 评估，缺一不可
- 查询侧是提质主战场：改写 + 混合检索 + Rerank + 组装
- 生成侧强约束 + 引用 + 拒答，压低幻觉
- Agentic RAG / GraphRAG 进阶；RAGAS + bad case 闭环驱动迭代
对于构建企业知识库的团队而言，把"四大子系统 + 评估闭环 + 生产工程"这条体系打磨好，比一味"换个更强的模型"更能决定 RAG 的成败。先让检索又准又全、让生成有据可依，再谈 Agentic 进阶——RAG 才真正配得上"生产级"三个字，而不是一个"看起来能答"的玩具。
