RAG检索增强生成

RAG(Retrieval-Augmented Generation,检索增强生成)是一套把外部知识接进大模型的架构。流程是:用户提问 → 从知识库里检索出相关片段 → 把这些片段连同问题一起塞进 Prompt → 模型基于给定材料生成回答。

它解决的是大模型两个绕不开的硬约束:模型只知道训练截止日期之前的事,而且完全不知道你公司内部的资料。微调可以部分解决,但代价高、更新慢;RAG 是成本低得多、也灵活得多的路子。

一条完整的 RAG 链路

离线建索引

• 切块(Chunking):把文档切成几百 Token 的片段。切得太碎丢上下文,切得太大混入噪音——这一步的质量往往决定整个系统的上限。
• 向量化:每个片段过一遍 Embedding 模型,变成一串数字。
• 入库:向量存进向量数据库,原文和元信息(来源、时间、权限)一并存好。

在线查询

• 检索:问题也向量化,在库里找最相似的 K 个片段。
• 重排(Rerank):用更精细的模型对这 K 个片段重新打分排序,把真正相关的顶到前面。这一步性价比极高,很多团队漏掉了。
• 生成:把片段拼进 Prompt,要求模型只依据给定材料作答,并标注引用来源。

为什么大部分 RAG 效果不好

几乎所有失败都不在"生成"这一步,而在检索:

• 检索不到。用户的问法和文档的写法用词不同,纯向量检索抓不住。混合检索(向量 + 关键词 BM25)通常能显著改善。
• 检索到了但排在后面。没做 Rerank,真正有用的片段被淹在 K 个里,模型注意力分散。
• 切块切坏了。一张表格被从中间劈开,一个结论和它的前提被分到两块,检索到哪块都是错的。
• 知识库本身就脏。过期文档、重复文档、互相矛盾的文档同时被检索到,模型只能挑一个信。

一个务实的排查顺序:先看检索结果对不对,再看生成对不对。八成的问题在第一步就能定位。

RAG 和微调怎么选

	RAG	微调
解决的问题	模型不知道这些事实	模型不会这种风格 / 格式 / 任务
更新知识	改库里的文档即可,分钟级	要重新训练
可溯源	能标出处	不能
成本	主要是检索和更长的 Prompt	训练 + 部署一套自己的权重

大多数场景的答案是 RAG 先上,微调按需再叠,而不是二选一。

常见误解

"上了 RAG 就没有幻觉了"——不对。RAG 大幅降低幻觉,但模型仍可能曲解材料、在材料没覆盖的地方自行补全。真正的兜底是要求引用出处并让用户能点开原文核对。