RAG 实战：切分、Embedding、检索、重排一条线

大模型最让人头疼的一点是：它会很自然地编故事。而 RAG（Retrieval-Augmented Generation）要做的事很直接：在回答前先检索资料，把“依据”塞进上下文，让回答变得可追溯。

这篇按一条完整链路讲清楚：从文档入库到最终回答，中间每一步你都能解释“为什么这样做”。

1) 一句话解释 RAG

RAG = 检索（找资料） + 生成（用资料回答）。

你可以把它理解为：

模型先翻书，再回答；而不是闭眼瞎编。

2) 一条标准流水线（建议照这个拆分模块）

1
2
3

文档 -> 清洗 -> 切分(chunk) -> Embedding -> 向量库
                                |
用户问题 -> Embedding -> 检索 topK -> 重排(re-rank) -> 组 Prompt -> LLM 输出

3) 切分（Chunking）：别把知识切碎，也别切太大

切分常见坑：

• 切太小：语义不完整，检索到的是碎片
• 切太大：噪音太多，浪费上下文，模型更难抓重点

经验建议（起步值）：

• 以 段落/标题 为边界优先
• chunk 大小：几百 token 量级起步
• overlap：适度重叠，避免关键句被切断

4) Embedding：把文本变成向量（用于相似度）

Embedding 的重点是“一致性”：

• 入库用什么 embedding 模型
• 查询也必须用同一个（或同一空间兼容的）模型

5) 检索 topK：宁可多取一点，再交给重排

常见做法：

• 先取 topK（比如 20）
• 再用 re-rank 模型（或更强的相关性判断）筛到 topN（比如 5）

原因很简单：

• 向量相似度是“粗筛”
• 重排更像“精排”

6) Prompt 组装：把“依据”和“指令”分清楚

建议 Prompt 结构：

• 系统：输出格式、风格、安全边界
• 用户：问题
• 资料：检索片段（带来源编号）

并且明确要求：

• 只根据资料回答
• 不知道就说不知道
• 引用编号（方便你定位是哪段资料起作用）

7) 最重要但最容易被忽略：评估（Eval）

RAG 的优化不能靠“感觉”，建议至少做：

• 一组固定问题集（20~50 个起步）
• 记录：命中率、回答正确率、引用是否相关
• 每次调 chunk/topK/重排都跑一遍对比

总结

RAG 做得好不好，关键不在“把向量库搭起来”，而在：

• chunk 切得是否合理
• 检索召回是否够稳
• 重排是否能把真正相关的片段顶上来
• prompt 是否能约束模型“按证据说话”

把这条链路跑通，你的大模型应用就会从“像在聊天”变成“像在查资料办事”。

封面与配图来自 Unsplash（免费使用授权）。