RAG检索增强生成

RAG 的直觉很朴素：大模型不知道的东西，不要逼它凭记忆猜；先从你的资料库里找出相关段落，再让它围绕这些段落回答。它把“生成能力”和“外部知识”接在一起。

Variant B2 · 讲义图谱版 · 深色单栏 + 右侧速查

先看知识图谱

读 RAG 时先抓住这张图：中心不是大模型，而是“问题如何找到正确材料”。Embedding、向量库、检索、Prompt 和 LLM 只是围绕这个目标协作的部件。

RAG中心动作：先检索，再生成。

外部知识库文档、工单、手册，是答案依据的来源。

切块 Chunk把长文档变成可检索的知识单元。

Embedding把文本变成向量，让语义相似可以计算。

向量库保存文档向量，提供相似度搜索入口。

检索 Top-K找回最可能相关的片段，这是质量命门。

Prompt 组装把材料、问题和回答规则放到一起。

LLM 生成基于材料输出答案，并尽量附引用来源。

这张图的重点是依赖关系：RAG 的质量上限主要由“能不能找回正确片段”决定，而不是只由最终 LLM 决定。

RAG 是什么

RAG 是 Retrieval-Augmented Generation，中文通常叫检索增强生成。它把一次问答拆成两个动作：先检索，再生成。用户提问后，系统用这个问题去知识库中查找相关材料；查到的材料会和原问题一起放进 prompt，交给大模型写答案。

这和直接问大模型不同。直接问时，模型只能依赖训练时形成的参数记忆。RAG 则像开卷考试：模型可以在回答前看到与你的问题最相关的几页资料。

一句话：RAG 不是让模型“记住”你的文档，而是让模型在回答时“查到”你的文档。

一条最小链路

一个最小可用的 RAG 系统通常包含两条流水线。离线链路负责把资料变成可检索的索引，在线链路负责每次提问时找材料、拼上下文、生成答案。

离线建库

收集文档docs + metadata

切块chunk size / overlap

嵌入embedding model

写入向量库vector index

在线问答

问题嵌入same model

检索 Top-Kretrieve chunks

可选重排rerank

拼 Promptcontext + question

LLM 生成answer + sources

两个检查点最关键：建库时的 chunk 是否能表达完整知识，问答时的 Top-K 是否把正确片段找回来。

切块解决的是颗粒度问题。整篇文档太长，直接检索会太粗；切成段落后，每个段落都能成为可命中的知识单元。

嵌入解决的是相似度问题。文字被转成向量后，语义相近的内容在向量空间里距离更近。检索其实就是找离问题向量最近的文档块。

生成解决的是表达问题。检索出的片段通常只是材料，最终还需要模型把材料整理成自然语言答案。

为什么不用微调解决

很多人第一次接触 RAG 时会问：为什么不直接把资料拿去训练或微调？原因是两者解决的问题不同。

RAG 更适合

知识量大，经常变化。
答案需要引用来源。
资料是内部文档或实时数据。
希望改资料库就能改变答案依据。

微调更适合

固定输出格式。
固定语气和角色风格。
让模型学习某类任务模式。
输入输出样例稳定且可批量准备。

简单说，RAG 主要管“说什么”，微调主要管“怎么说”。实际项目里它们可以组合：用微调规范回答风格，用 RAG 注入事实依据。

检索质量决定上限

RAG 最常见的失败不是模型不会写，而是检索没有找回正确材料。错误材料进入 prompt 后，模型往往会顺着错误材料生成一个看起来很流畅的错误答案。

检索不到，生成就没有米下锅；检索错了，生成会把错材料说得更像真的。

优化时先看三个旋钮：chunk size 是否合适，Top-K 是否过少或过多，是否需要混合检索或 rerank。对于产品型号、错误码、专有名词这类字面匹配很重要的场景，纯向量检索经常不够，关键词检索和向量检索结合会更稳。

chunk size

太大噪声多，太小语义碎。先让每块能独立表达一个知识点。

top-k

太小容易漏，太大引入噪声。常从 3 到 5 起步，再用评测调。

rerank

先粗召回，再精排序。对相似但不够准的检索结果很有用。

怎么判断它做得好不好

不要只靠主观试问。更可靠的做法是准备一组小评测集：每个问题都标出“应该命中的文档片段”。然后观察正确片段是否被检索出来，以及它在结果中的排名。

如果正确片段没有进入 Top-K，问题在检索层；如果正确片段已经进入 prompt 但答案仍然错，再去看提示词、引用约束和生成模型。