RAG（检索增强生成）的说法很直觉：模型不知道的东西，先去你的资料里查，查到了再让它回答。 听上去就是「检索 + 塞进提示词」，但真正做起来，决定效果好坏的**全在中间那些工程环节**。这篇按调用顺序走一遍，并标出每一步的坑。 ## 整体链路 ``` 文档 → 切分 → 嵌入 → 入库 ↓ 用户提问 → 嵌入 → 召回 → 重排 → 组装提示词 → 生成 → 引用标注 ``` 七个环节，每一环都能决定成败。 ## 1. 切分：上限在这一步就定了 最常见的错误是按固定字数硬切。 问题很直接：一段完整的配置说明被从中间劈开，前半段说「修改 /etc/ssh/sshd_config 的以下选项」，后半段才是选项列表。用户问「怎么禁用密码登录」，检索到的是前半段——模型拿不到关键内容，只能编。 更合理的做法： - **按结构切**：Markdown 按标题层级、代码按函数、文档按章节； - **保留上下文**：每个切片带上它所属的标题路径，比如 `SSH 加固 > 配置 > 认证方式`； - **适度重叠**：相邻切片之间留 10% 到 20% 的重叠，避免跨边界的信息断开； - **别切太小**：一两句话的片段缺乏语境，embedding 表示不好，人也读不懂。 ## 2. 嵌入：中文场景别默认用英文模型 embedding 模型的选择直接决定「什么算相似」。 中文语料上训练不足的模型，会把「内存」和「存储」判得远，或者把「端口暴露」和「端口映射」混为一谈。做中文知识库，**要选在中文检索评测上表现好的模型**，不能照搬英文教程里的推荐。 另一个容易忽略的点：**入库和查询必须用同一个模型**。换了模型不重新嵌入，整个库的向量空间就废了。 ## 3. 召回：宁可多召回，交给后面筛 召回阶段的目标是「别漏」，不是「别多」。 通常先取 Top 20 到 50 条，后面靠重排精选。只召回 Top 3 就直接喂给模型，一旦第一步判断偏了，后面再怎么优化都没用。 混合检索在这里落地：向量召回一路、关键词（BM25）召回一路，合并去重。前面提过，两路各有短板，合起来才稳。 ## 4. 重排：性价比最高的一步 rerank 模型做的事是：拿问题和每个候选片段**逐个精细打分**，然后重排序。它比向量召回慢，但准得多。 流程是「粗召回 50 条 → 重排取前 5 条 → 送进生成」。 如果你的 RAG 效果不好，**先加重排**，这一步的投入产出比远高于换 embedding 模型或调向量库参数。 ## 5. 组装提示词：明确告诉模型「只能用这些」 这一步决定模型会不会胡编： ``` 只根据下面提供的资料回答。 如果资料中没有答案，直接说"资料中没有提到"，不要推测。 回答时标注你引用了哪几条资料。 [资料 1] ... [资料 2] ... 问题：... ``` 两个关键点：**允许模型说不知道**，以及**要求标注引用来源**。前者避免幻觉，后者让你能验证答案。 ## 6. 生成与引用：可验证才有价值 让模型输出引用编号，用户在前端点一下就能跳到原文。 这不是锦上添花——**在严肃场景里，不可验证的 AI 答案基本没有价值**。用户没法判断对错，就只能全部怀疑。 ## 7. 评估：别靠感觉 最容易被跳过的一步。随便试几个问题觉得还行就上线，之后改任何一环都不知道是变好还是变坏。 最小可行的做法： - 手工攒 **30 到 50 个真实问题**，每个标注「正确答案应该来自哪段原文」； - 定义指标：召回的片段里有没有包含正确答案（召回率）、最终答案对不对（准确率）； - 每次改动跑一遍，对比数字。 有了这套东西，你才知道「换了 embedding 模型」到底是变好还是变坏。 ## 小结 RAG 的完整链路里，**模型只是最后一环**。前面切分、嵌入、召回、重排这四步加起来，对最终效果的影响远大于换更强的生成模型。 给刚上手的人一个顺序建议：先把切分做对，再加混合检索，然后加重排，最后建测试集。按这个顺序走，每一步都能看到实际改善。