很多 RAG 项目效果不达标，第一反应是"换个更强的模型"——但我的经验是：问题大概率不在生成，而在检索链路没调对。
这篇文章从一个真实落地的专利撰写知识库项目出发，把 RAG 拆成「离线索引 + 在线检索生成」两条链路完整讲一遍。读完你就知道是怎么回事了
📖 正文
最近用 RAG 做了一个专利生成的知识库项目，结合这个项目的开发流程梳理了一份 RAG 工作流程。
一、RAG 是什么
RAG（Retrieval-Augmented Generation，检索增强生成）本质上是：先检索、再生成。把知识库里的相关内容找出来，塞进 Prompt，让大模型"照着资料回答"，从而降低幻觉、支持溯源。
RAG 的执行过程主要分为两个阶段：
- 【离线】索引构建链路（Indexing） ：文档加载 → 清洗解析 → 分片（Chunking）→ 向量化（Embedding）→ 写入向量库/索引
- 【在线】检索生成链路（Retrieval + Generation） ：用户 Query → Query 改写 → 混合检索（向量 + 关键词）→ Rerank 重排 → 上下文拼装 → LLM 生成 → 引用溯源/后处理
RAG 混合检索流程全景图
二、离线索引链路
结合专利撰写知识库项目，实战讲解各环节具体是做什么的。
项目背景：这是一个面向专利撰写人员初稿撰写场景的 AI 辅助平台。整体流程是：用户输入主题，系统返回专利所需格式的初稿，大大提高撰写人员的效率。
1. 文档加载与解析（Load & Parse）
- 专利文献解析清洗。专利有强结构（权利要求书、说明书、摘要、附图说明），解析时要保留这些章节边界。
2. 分片（Chunking）⭐ 这是 RAG 效果的关键
在我的专利撰写项目中用了 "语义 + 章节结构"双维度分片，即先按专利章节结构切（保证语义边界），再在长章节内做语义切分。这里面还通过 bad case 分析持续调优分片粒度，这正是实际工程里最花时间的地方。
3. 向量化（Embedding）
用 Embedding 进行向量化后写入 Milvus（向量数据库）。同时还建了 Elasticsearch 关键词索引——为后面的混合检索做准备。
💡 关键理解：向量检索擅长"语义相似"（换个说法也能查到），关键词检索擅长"精确匹配"（专业术语、专利号、化学式等）。专利场景术语多，所以两者都要。
三、在线检索生成链路
4. Query 处理
在这个专利撰写的项目中，流程是：用户输入"选题描述"，系统据此发起查新检索。
5. 混合检索（Hybrid Retrieval）⭐
在专利撰写知识库项目中做了混合检索，正是"混合召回"：
- 向量检索（Milvus）：召回语义相似的 TopK
- 关键词检索（Elasticsearch / BM25）：召回术语精确匹配的 TopK
- 再融合（如 RRF）
调优召回 TopK 配置——TopK 太小可能漏掉相关文献，太大引入噪声、撑爆上下文。
6. Rerank 重排序 ⭐
- 调优了 Rerank 参数，这直接带来了"召回相关度提升约 40%"的成果。
💡 检索的经典范式： "粗召回（高召回率、快）+ 精排（高准确率、慢）" 。混合检索负责多召回，Rerank 负责筛准。
7. 上下文拼装 + Prompt 注入
在这个专利项目中，流程是这样的：
- 把召回的相似专利文献注入 Prompt 上下文
- 结构化输出约束（让模型按专利章节格式输出）
- 还处理了输出截断、格式漂移、内容不完整的兜底——这是真实工程的痛点。
8. LLM 生成
最后就是：用 DeepSeek 生成结构化专利初稿，并通过 Dify 工作流编排为多阶段（查新检索 → 大纲生成 → 分章撰写 → 格式校验），用 Function Calling 在生成中回查文献、回填结构化数据。
9. 引用溯源与后处理 ⭐
逐段标注引用来源，点击跳转原文片段，降低幻觉、提升业务信任度。
四、检索链路调优
所有调优都是同一套：构建评估集 → 只改一个变量做对比实验 → 看指标 + bad case 分析 → 迭代到收敛。不靠感觉，靠数据。
1. 先厘清：RAG 里其实有"两个 TopK"，别混淆
粗召回 Rerank 精排 注入 Prompt
│ │ │
│ 向量/关键词各召回 K1 → │ 精排后取 K2 条 → │ 拼进上下文喂给 LLM
│ │ │
【召回 K】 【精排 TopN】 （就是 K2）
| 名称 | 位置 | 调它影响什么 |
|---|---|---|
| 召回 K（Retrieval TopK） | 粗召回阶段，进 Rerank 的候选数 | 召回率 vs Rerank 计算成本 |
| 精排 N（Rerank TopN） | 精排后注入 Prompt 的数量 | 上下文信息量 vs 噪声/成本 |
2. 召回 K（粗召回）怎么调
核心矛盾
- K 太小 → 真正相关的文献根本没被召回进来，后面 Rerank 再准也救不回来（漏召回，天花板被锁死）
- K 太大 → Rerank 计算量上升、延迟变高，且引入更多噪声候选
调优方法：盯着 Recall@K 找拐点
- 用评估集，逐步放大 K：10 → 20 → 50 → 100
- 每个 K 算 Recall@K（真正相关的文献，有多少被召回进来了）
- 画出 Recall 随 K 增长的曲线
- 找"边际收益递减的拐点"
关键判断：比如 K 从 20→50，Recall 从 75% 涨到 92%（提升明显，值得）；K 从 50→100，Recall 只从 92% 涨到 94%（涨得很少，但 Rerank 成本翻倍，不划算）。那 K=50 就是拐点，是较优选择。
💡 一句话原则：召回 K 要设到"Recall 基本饱和"的位置——保证不漏，但别浪费。因为召回阶段的使命是"多召回、别漏"，精准度交给 Rerank。
3. 精排 N（注入 Prompt）怎么调
核心矛盾
- N 太小 → 喂给模型的资料不够，生成内容不完整、引用不足
- N 太大 → 撑爆上下文窗口、稀释关键信息（"迷失在中间" Lost in the Middle）、增加 token 成本、甚至加剧幻觉
调优方法：盯着生成质量指标
这个不看 Recall 了，看下游生成效果：
- N 取 3 / 5 / 8 分别跑
- 看评估集的三个指标：章节完整性、引用准确性、格式合规率
- 找生成质量最好的 N
经验：N 通常比想象的小。太多文献反而让模型抓不住重点。专利这种长文档场景，往往精选 3-5 条高相关的比塞 10 条效果好。
4. Rerank 环节到底有哪些"可调的东西"
很多人以为 Rerank 就是调一个参数，其实可调的是这几类：
| 可调项 | 具体内容 | 影响 |
|---|---|---|
| ① Rerank 模型选型 | 用哪个 Cross-Encoder（如 bge-reranker、Cohere Rerank 等） | 精排质量的上限 |
| ② 召回 TopK（进 Rerank 的候选数） | 检索粗召回给多少条进 Rerank | 召回率 vs 计算成本 |
| ③ Rerank 后取 TopN（进 Prompt 的数量） | 精排后保留几条注入上下文 | 信息量 vs 噪声 |
| ④ 相关性分数阈值 | 低于某分数的直接丢弃 | 过滤无关文献 |
| ⑤ 混合检索融合权重 | 向量路和关键词路的权重 / RRF 参数 | 影响进 Rerank 的候选质量 |
"Rerank 参数调优"主要指 ②③④⑤ 这几个数值的组合调整，外加 ① 模型选型。
5. 用什么调优 —— 核心是"评估集驱动的对比实验"
关键是：调优不是靠感觉，是靠一个评估样本集 + 指标对比。我的做法是 bad case 分析持续优化 + 人工评估样本集。完整流程是这样的：
-
构建评估集：准备一批「查询 → 应该被召回的相关专利文献」的标注样本（Ground Truth）
-
定义指标：主要看检索/排序类指标——
- Recall@K（前 K 条里召回了多少真正相关的）
- Precision@K / MRR（第一个相关结果的排名）
- NDCG（考虑相关性排序质量的指标）⭐ Rerank 最常看这个
-
跑对比实验（A/B） ：固定其他条件，只改一个变量，跑评估集，对比指标。例：TopK=20 vs 50 vs 100，看 Recall 和 NDCG 变化
-
Bad case 分析：把「该召回却没排上来」的 case 挑出来，看是分片问题、模型问题还是阈值问题，针对性调
-
迭代到指标收敛
五、总结
回顾整个项目，RAG 落地的核心认知可以浓缩成三点：
- RAG 的本质是"先检索、再生成"，工程上分两条链路。离线把文档解析、分片、写入向量库和全文索引；在线做混合检索 + Rerank + Prompt 注入。专利这种术语密集的场景，单靠向量检索不够，"语义 + 关键词"混合召回是标配。
- "两个 TopK"别混淆，调法也完全不同。召回 K 的使命是"宁多勿漏"，盯 Recall@K 曲线找拐点；注入 Prompt 的 N 要"精选不贪多"，盯下游生成质量。前者保召回率，后者保信噪比，混为一谈是很多调优无效的根源。
- 调优不靠感觉，靠"评估集 + 单变量实验 + bad case 分析" 。每轮只改一个变量，看指标变化，再把 bad case 逐个归因到分片、召回、精排或注入环节。这套方法换到任何 RAG 项目都适用——最终我们用它在内部评估集上把检索相关度提升了约 40%。
