RAG：检索增强生成的工作方式与边界

RAG，全称 Retrieval-Augmented Generation，通常翻译为检索增强生成。它的基本思路很直接：模型回答问题前，先从外部文档中检索相关片段，再把这些片段放进上下文，让 LLM 基于材料作答。

RAG 解决的是模型无法直接访问私有资料、训练数据过时、回答需要引用来源等问题。它并不会让模型真正“记住”你的资料，而是在每次提问时临时把相关资料找出来。

基本流程

一个典型 RAG 系统可以拆成两条链路：离线入库链路和在线查询链路。

离线入库

文档收集 -> 清洗 -> 切片 -> 生成 embedding -> 写入向量库

切片质量会直接影响后续回答。如果切得太碎，模型拿不到完整上下文；如果切得太大，检索命中会变粗，token 成本也会上升。

常见切片策略包括：

• 按标题层级切。
• 按段落切。
• 固定 token 长度切。
• 带 overlap 的滑动窗口。

技术文档更适合按标题结构切，聊天记录或会议纪要则可能需要按时间和话题切。

在线查询

用户提问 -> 查询改写 -> 向量召回 -> rerank -> prompt 拼装 -> LLM 回答

这里最容易被低估的是 rerank。只靠 embedding 粗召回，可能会找出语义相近但不真正回答问题的片段；reranker 可以在候选片段里重新排序，把最相关的内容放到上下文前面。

两阶段检索

一个常见实现会包含：

1. 粗召回：用嵌入模型把文档切片向量化，通过语义搜索找出 Top-K 候选片段。
2. 精排：用 reranker 对候选片段重新排序，挑出最相关的内容进入上下文。

例如：

Top 50 embedding recall
  -> rerank
  -> Top 5 context chunks
  -> answer with citations

这个过程的目标不是“找很多材料”，而是“找足够相关且互相补充的材料”。

适合做什么

RAG 很适合这些场景：

• 公司内部文档问答。
• 论文、教程、手册的快速查询。
• 大量非结构化资料的语义搜索。
• 客服知识库。
• 需要“基于资料回答”的聊天助手。

它的优势是接入快，不要求先把所有资料整理成知识图谱或 Wiki。只要能切片、嵌入、检索，就能开始使用。

它不擅长什么

RAG 也有明显边界：

一个典型失败例子是综合复盘类问题：“这个项目从需求到上线的关键决策是什么？”如果资料散落在会议记录、PR、设计稿、聊天记录里，RAG 可能能找到片段，但很难自动形成稳定的决策脉络。

检索质量怎么判断

RAG 的质量不应该只看回答是否流畅，而要看检索是否命中。可以从四个问题检查：

1. 应该命中的文档有没有被召回。
2. 召回片段是否包含完整上下文。
3. 排名前几的片段是否真正回答问题。
4. 模型回答是否忠于材料，而不是自己补完。

如果回答错了，不一定是模型差，也可能是：

• 文档切片太差。
• embedding 模型不适合中文或领域术语。
• Top-K 太小。
• 缺少 rerank。
• prompt 没要求基于引用回答。

和 LLM Wiki 的区别

RAG 是查询时范式：知识在提问时临时组装。

LLM Wiki 是整理时范式：知识提前被整理成结构化页面，并在之后持续维护。

对于个人知识管理，二者可以互补：

• RAG 负责从大量 raw 资料里找线索。
• LLM Wiki 负责把稳定知识沉淀成页面。
• 博客负责把适合公开的内容重新编辑成文章。

如果只用 RAG，知识容易停留在“可检索但未消化”的状态；如果只用 Wiki，面对海量原始资料又会缺少快速检索能力。更实用的方案是把两者放在不同层级。