一、先回到底层为什么需要 RAG还是上一题那个出发点——LLM 的本质是自回归生成P(xᵢ | x₁...xᵢ₋₁)这带来两个硬伤知识截止权重在训练完成那一刻就冻结了永远不知道之后发生的事幻觉它在生成最像答案的文本而不是查询事实数据库。上下文里没有什么它就敢编什么。RAGRetrieval-Augmented Generation的思路因此非常直接既然模型的知识只取决于拼进上下文的文字那就先查资料把查到的资料塞进上下文再让它生成。模型不需要记住任何东西只需要会照着资料说。所以 RAG 的全部工程就是回答一个问题怎么把对的资料在对的时候以对的形态放进上下文。二、从提问到答案的六步用户提问 │ ▼ ① 理解/改写 把口语化、缺上下文的问题改写成适合检索的查询 │ Q 那个谁上个月说的营收咋样了 │ 改写XX公司 2026年9月 营收 数据 ▼ ② 检索 用查询去向量库/搜索引擎找候选文档 │ embedding 语义相似度 Top-K或混合检索 ▼ ③ 重排 Rerank 对 Top-K 再精排把真正相关的提到前面 │ 向量粗排保召回rerank 保精度 ▼ ④ 拼进 Prompt 把精选片段组装进上下文外加引用来源 │ ▼ ⑤ 生成 LLM 基于上下文里的资料作答 │ ▼ ⑥ 返回答案理想情况带上引用可追溯另外藏着一个第 0 步分块Chunking——入库之前文档怎么切。它发生在用户提问之前却决定了后面所有步骤的天花板。三、最容易烂的是哪步结论表面上是检索实际上是检索 它背后的第 0 步分块。这两个是 RAG 最常见的死因生成环节反而很少是真正的锅。死因 1分块切烂第 0 步隐蔽但致命Embedding 是把一段文字压成一个向量向量代表的是这一段的整体语义。切错了语义就碎了表格被从中间切开 → 表头和数据分家查回来的片段根本没有可读性一个定义跨了两段 → 前半段说X 是一种……后半段才说……满足条件 Y切开之后两个块都不完整块太大 → 噪音淹没信号相似度被稀释块太小 → 丢上下文。分块烂了后面五步全白搭——这就像图书馆里书全被撕成碎片还放错了架子检索员再敬业也没用。死因 2检索查错最显性的死因Embedding 相似度有个根本缺陷它度量的是语义像不像而不是事实对不对。具体表现为对精确术语不敏感ABC-2000X 型号和DEF-3000Y 型号在向量空间里可能非常近都是产品型号但用户要的就是前者对数字不敏感利率 3.5%和利率 4.8%语义上几乎重合业务上完全是两回事对 ID、代码、专有名词不敏感这些恰恰是精确检索需求里最常见的元素。怎么救成熟 RAG 的标准组合拳手段作用混合检索关键词 BM25 向量关键词管精确匹配术语、数字、ID向量管语义召回两路结果取并集Rerank用更强的交叉编码模型对候选精排把语义沾边但事实无关的排下去查询改写/多路查询一个问法多角度改写提高召回率分块策略优化按语义边界/结构切表格整块保留、段落为界加重叠防止断章元数据过滤先按时间、来源、部门过滤再检索缩小搜索空间其他步骤的坑次要但真实改写过度改写丢了用户本意查回来的资料方向偏了拼 prompt 时不标注来源多份资料矛盾时模型不知道该信谁生成环节不照抄给了对的资料模型仍然自由发挥——解法是指令约束仅基于所给资料作答资料没有就说不知道。四、一句话总结RAG 就是先查资料再回答。LLM 负责的两头改写、生成相对不容易出错中间资料对不对的链路分块 → 检索 → 重排才是生命线——切错块、查错文生成模型再强也救不回来。判断一个 RAG 好不好先看它怎么分块、用什么检索策略而不是看用了多贵的模型。