企业官网建设流程全解析

一、先回到底层：为什么需要 RAG

还是上一题那个出发点——LLM 的本质是自回归生成P(xᵢ | x₁...xᵢ₋₁)，这带来两个硬伤：

1. 知识截止：权重在训练完成那一刻就冻结了，永远不知道之后发生的事；

2. 幻觉：它在"生成最像答案的文本"，而不是"查询事实数据库"。上下文里没有什么，它就敢编什么。

RAG（Retrieval-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 的标准组合拳

其他步骤的坑（次要但真实）

• 改写过度：改写丢了用户本意，查回来的资料方向偏了；

• 拼 prompt 时不标注来源：多份资料矛盾时模型不知道该信谁；

• 生成环节不"照抄"：给了对的资料，模型仍然自由发挥——解法是指令约束"仅基于所给资料作答，资料没有就说不知道"。

四、一句话总结

RAG 就是"先查资料再回答"。LLM 负责的两头（改写、生成）相对不容易出错；中间"资料对不对"的链路（分块 → 检索 → 重排）才是生命线——切错块、查错文，生成模型再强也救不回来。判断一个 RAG 好不好，先看它怎么分块、用什么检索策略，而不是看用了多贵的模型。