📚 本文收录于「流浪」的系列专栏
| 🐧 Linux系统 | ⚙️ C++ |
| 📊 数据结构与算法 | 🐍 Python |
| 🔗 LangChain & LangGraph | 🗄️ MySQL 数据库 |
| 🌿 Git 工具 | 🌐 计算机网络 |
| 🤖 LLM | 💯 大厂面试、八股 |
| 📚 学习筑基专栏 |
🏠 博客主页：流浪 ｜ 📝 原创首发于 CSDN
上一篇把知识库构建阶段的最后一环讲完了：向量连同原文和元数据一起落进向量库， 四段字段各管一件事，选型看规模、运维和技术栈。库建好之后，真正的使用阶段才刚开始------用户敲一句话进来，系统要把它变成向量、在库里捞出最相关的几块、把这几块和原来的问题揉成一个像样的提示词，最后交给大模型写出答案。本篇就走一遍这条线：用户查询、查询向量化、向量检索、提示词增强、大模型生成，也就是 RAG 里 R 到 G 的完整过程。
检索的流程
一、用户查询
1.1 用户查询是整个检索与生成流程的起点
- 用户查询（User Query）是用户在检索系统或对话系统中输入的原始问题、指令或关键词，用来表达他的信息需求，在 RAG 系统里，它是整个检索与生成流程的起点。
- 简单说就是用户向应用发起提问，比如我们问公司的 AI 助理「公司新发布的休假政策是什么？」，这句话就是用户查询。
- 这一步拿到的还是自然语言文本，它不会被直接拿去和库里的东西比对，后面必须再转成向量才能进入检索。
用户查询是入口，它决定了后面检索的方向，但它本身还不能参与计算，得先完成向量化。
二、查询向量化
2.1 查询必须用与索引阶段相同的嵌入模型转成向量
- 用户输入问题后，系统使用与索引阶段相同的嵌入模型，把查询文本转换成向量表示，使它和知识库中的文档向量处于同一个语义空间。
- 这个步骤和把文本块转成向量的过程完全一样，区别只在对象：一个是文档块，一个是用户的问题。
- 「同一个模型」是硬要求，不是建议：不同模型产出的向量空间不一样，跨模型的距离没有任何意义，这件事在讲嵌入模型的时候已经说过一次。
查询向量化最容易出错的地方就是换了模型，一换模型检索并不会报错，只会静默地召回一堆不相关的东西。
三、向量检索
3.1 向量检索是在库里找出与查询向量距离最近的一批文本块
- 查询转成向量之后，系统需要在向量数据库中快速找到语义最接近的文本块，这个过程本质上是向量相似度检索：用搜索算法去算查询向量与库中所有向量的距离，距离越近，语义越相似。
- 距离具体怎么算（余弦、欧氏、点积）前面已经讲过，这里看的是检索算法本身，也就是怎么在海量向量里把那几个最近的捞出来。
检索算法解决的是「怎么找得快」，距离度量解决的是「怎么算得像」，两层各管一件事。
3.2 KNN 逐个算距离取最近的 K 个，属于暴力搜索
-
KNN（K-Nearest Neighbor）是个暴力搜索的过程，它的工作流程可以拿一个场景来对照：想象你在一个派对上，想通过一个人的衣着打扮来判断他的职业，逻辑是这样的。
- 第一步，确定 k 值：决定看周围几个邻居，比如 k=3。
- 第二步，计算距离：计算你和派对里每个人的距离，算法里通常是欧几里得距离。
- 第三步，找邻居：找出离你最近的 3 个人。
- 第四步，少数服从多数：如果这 3 个人里有 2 个是程序员、1 个是设计师，那就判定你也是程序员。
-
这里要分清一件事：第四步的投票是 KNN 用在分类任务上的做法，而在向量检索这个场景里，我们要的就是「最近的 K 条」本身，取出来直接作为候选，并不需要投票。
-
KNN 的缺点比较明显：每次预测都要计算和所有已知点的距离，数据量一旦达到百万级，速度会慢得让人抓狂。
KNN 的本质是「一个都不放过」，准确但代价是每次都全量计算，规模一大就扛不住。
3.3 ANN 用索引换速度，牺牲极小的精度
- ANN（Approximate Nearest Neighbor，近似最近邻）牺牲微小的精度，换取指数级的速度提升，它的工作流程分成两步。
- 第一步，建索引：提前把数据库里的向量建成一张导航地图（比如 HNSW 图）或者分类文件夹（比如 IVF 聚类）。
- 第二步，查询：查询向量来了之后，只在地图的一小片区域里找，不去管数据库另一头八竿子打不着的向量。
- 对照着看会更直观：想象你要在一座藏书 500 万册的图书馆里，找一本和你手里这本内容最像的书。KNN 的做法是把 500 万本书从架子上全部搬下来，一本一本翻目录对照，耗时数年但能找到绝对最像的那本；ANN 是先看一眼图书馆楼层导航图，直接冲到「计算机类 / 四楼」，只在那几百本书里细挑，两分钟就找出三本内容几乎一样、肉眼根本分不出差别的书来。
KNN 换的是绝对准确，ANN 换的是够快，而 RAG 要的是在用户能接受的延迟内给出足够好的候选，所以生产环境一律用 ANN。
四、提示词增强（Augmented）
4.1 增强做的是知识补全、约束行为、格式化三件事
- 如果说 R（Retrieval，检索）是「找资料」，G（Generation，生成）是「写答案」，那么 A（增强）就是「把资料和问题揉在一起喂给模型，并告诉模型怎么用」的核心过程。
- 增强不是简单地把问题和检索到的文本块粘在一起，它通常包含三个关键动作。
- 知识补全：把大模型原本不知道的私域数据、实时新闻或者长文本细节补充进提示词。
- 约束行为：明确告诉模型「请基于下面提供的参考内容来回答，不要使用你自己的知识」。
- 格式化：把检索到的多个文本块（可能格式各异）转换成模型最容易理解和遵循的统一格式。
增强增强的不是内容量，是「模型拿到这批内容以后该怎么做」这件事的确定性。
4.2 提示词模板化把原始问题和文本块填进预设模板
系统会将你的原始问题和搜索到的文本块填入一个预设的模板中，后台预设的模板大致是这个结构：
text
你是{角色名称}。请根据以下提供的【参考上下文】回答用户的问题。
【参考上下文】：
{检索到的文本块 1}
{检索到的文本块 2}
...
【用户问题】：
{用户提问内容}
【回答要求】：
请用专业且亲切的口吻回答，如果文档中未提及补贴金额，请提示用户咨询财务部。模板化的价值在于结构固定：模型每次看到的顺序、标签、要求都一致，输出才稳定，也方便按业务替换其中的角色和要求。
模板把「问题、资料、要求」三件事的位置固定下来，模型不用每次猜哪一段是问题、哪一段是资料。
4.3 上下文压缩与过滤只保留相关度最高的内容
- 有时候检索回来的东西太多，比如找回了 10 个文本块但模型处理不了这么长，增强环节会对这些块进行重排序（Reranking）或者摘要提取，只留下相关度最高的。
- 看一段真实的压缩：搜索到的原始文本块写着「员工连续服务满 1 年后可享受年假。具体标准：服务 1 年以上不满 5 年的，每年 10 个工作日；服务 5 年以上不满 10 年的，每年 15 个工作日；服务 10 年及以上的，每年 20 个工作日。年假需在当年内使用，最多可结转 10 个工作日至次年 3 月底，逾期作废。离职时，未休年假按日基本工资的 300% 补偿。」
- 摘要之后变成一句话：「年假：工龄 1-5 年 10 天，5-10 年 15 天，10 年以上 20 天。可结转 10 天，离职按 3 倍结算。」
- 信息一条没少，占用的上下文却大幅下降，这就是压缩的意义。
上下文压缩不是删信息，是在保住关键结论的前提下把篇幅压下去，给真正相关的块腾出位置。
4.4 角色设定把「只能依据参考内容回答」写成硬约束
- 在提示词中加入指令，明确告诉模型「你是基于参考资料的助手」，这是增强里成本最低、收益最高的一步。
- 比如这样写：你现在是「比特科技 HR 政策专家」。忠实原则：你只能依据给定的参考上下文回答。如果上下文中没有提到具体的数额，绝对严禁引用你记忆中的通用知识，只能回答「公司暂未公示」。
- 当然增强的步骤不是固定的，要根据业务具体情况来进行专门的处理。
角色设定的作用是关掉模型「自由发挥」的口子，让它把答案的边界锁在参考内容里。
4.5 增强与直接拼接的差别，在客服问答里最明显
- 举个例子：用户问「我的笔记本电脑保修期是多久？」，我们从库里面召回了三段内容，分别是官方保修政策、用户的订单记录，以及一句「我上次修电脑说只保 1 年，太坑了」的抱怨。
- 增强之后是这样的结构：系统指令里写明「必须严格根据参考内容回答」「没有答案就直接说找不到相关信息」「存在矛盾时优先采用官网政策或订单记录」「不要使用预训练知识中的保修政策」；参考内容只保留前两条，并且各自标注来源。
- 如果直接拼接，把问题、三个文本块和一句「请回答」堆在一起，模型很可能被那段抱怨误导，或者把信息混着用，给出「保修期可能是 1 到 2 年」这种模糊甚至错误的答案。
增强的关键动作不是把内容加进去，而是把噪声挡在外面、把规则写清楚。
五、LLM 生成
5.1 大模型在这一环承担四件事
- 融合检索信息：将检索模块返回的多个文本片段与原始查询（或者对话历史）进行整合。
- 生成最终输出：以自然语言形式生成答案、摘要、解释等，而不是简单地把检索到的原文返回回去。
- 处理不确定性：当检索结果不完整或者相互矛盾时，利用模型自身的知识进行合理推断，或者明确指出信息不足。
- 保持风格与流畅性：确保输出符合预期的语气、格式和语言习惯。
大模型在 RAG 里干的不是「复述检索结果」，而是把几块零散的证据组织成一个能直接用的回答。
5.2 生成结果是信息融合，不是原文复述
- 比如用户问「我买的笔记本电脑用了 13 个月，屏幕坏了，能免费保修吗？」，检索到两段信息：片段 A 说整机免费保修 12 个月、主要部件（主板、CPU、内存、屏幕）免费保修 24 个月；片段 B 说屏幕属于主要部件、保修期 24 个月，但需排除人为损坏。
- 生成的结果是这样的：「您的电脑用了 13 个月，虽然整机保修（12 个月）已经过了，但屏幕属于主要部件，保修期是 24 个月，所以屏幕本身可以免费保修。不过需要确认不是人为损坏（比如摔裂、进水）。」
- 可以看到，它不是简单地返回原文，而是把两条信息融合起来做了判断，整体的语气也非常清晰直接。
生成这一环的价值，在于把两块各自只说了一半的事实拼成一个能直接执行的结论。
六、本篇小结
- 应用阶段这条线是：用户提问 → 查询用同一个模型转成向量 → 在库里用 ANN 索引捞回最相近的几块 → 经过模板化、压缩过滤、角色设定揉成提示词 → 交给大模型融合生成。
- 三件事最容易出问题：查询换了模型导致空间不一致、检索算法撑不住规模导致延迟、增强没做约束导致模型自由发挥。
- 到这里，RAG 的完整工作机制就算走通了一遍，后面再看它的发展范式和常见问题。
检索决定了有没有找对，增强决定了模型会不会乱用，生成决定了最后说出来的是不是人话，三段各自有各自的失败点。
七、文末面试题（真题）
- RAG 的检索阶段具体做了哪几步？
答: 典型流程是把用户查询编码成向量，系统检索语义相近的数据，把最相关的检索结果加进模型上下文，最后基于这些检索到的数据生成回答。
- 检索是三个环节中的第二段，前面是抽取（数据被切块、嵌入、建索引存进向量库），后面是生成。
- 很多系统还会在检索阶段后面挂一个重排序模型，从候选里再挑出最相关的那几条，用来提升最终回答的准确度。
- 检索阶段常用向量检索加关键词检索两种方式，最终目的是给生成环节提供可靠的依据。
【真题·转述自 What Is Retrieval-Augmented Generation (RAG)?（NVIDIA 技术词条）】
- 为什么大规模 RAG 系统普遍用 ANN 而不是精确最近邻？
答: 在高维空间里精确找最近邻，规模一大算力就撑不住了，ANN 用可控的精度损失换来了可用性。
- HNSW 建多层图把相似向量连起来，检索时从远到近逐层导航，搜索复杂度是对数级的，速度和精度可以通过参数调节。
- IVF-PQ 先把向量空间切成簇做粗过滤，再用乘积量化压缩向量降低内存占用，让十亿级向量在普通硬件上也能搜。
- 代价是 ANN 可能漏掉真正的最近邻，实际调好的索引能找回 95% 到 99% 的精确 Top-K，对 RAG 来说完全够用。
【真题·转述自 Retrieval Augmented Generation (RAG)（Approximate Nearest Neighbor Search 一节）】
- 提示词增强这一步到底增强了什么？直接把检索结果拼进去行不行？
答: 增强是把检索到的上下文和用户的原始问题组合成一个结构化的提示词，通常包含用户的问题、检索到的段落、以及约束指令三部分。
- 指令部分的作用是让模型把答案建立在给定上下文上，而不是用它自己的训练知识，这包括让模型在上下文不足时直接说不知道。
- 上下文窗口管理也在这一步：塞太多段落会超出 token 上限或者稀释注意力，所以要靠过滤、排序、摘要来保证提示词高效。
- 增强做得对不对，决定了这是一个有依据的 RAG 回答，还是模型自己猜的一个答案。
【真题·转述自 RAG models explained from indexing to generation（How augmentation enhances RAG outputs 一节）】
- 检索回来的内容太多塞不下怎么办？
答: 靠上下文窗口管理来解决，核心手段是过滤、排序和摘要，把提示词压到模型吃得下又足够支撑回答的规模。
- 注入过多段落有两种后果：一是超出 token 上限直接截断，二是稀释模型的注意力，反而答不准。
- 常见做法是先重排序挑出相关度最高的几条，再对长段落做摘要，把关键结论留下来、把铺陈删掉。
- 压缩的前提是不丢关键结论，只压篇幅不压信息量，否则就是把检索的质量又赔进去一次。
【真题·转述自 RAG models explained from indexing to generation（How augmentation enhances RAG outputs 一节）】
- 生成阶段大模型到底在做什么？如果检索质量很差，生成阶段能救回来吗？
答: 生成是最后一步，模型读完增强后的提示词，结合自己的语言理解能力和给定的具体段落写出回答，同时给出引用来源方便用户核对。
- 因为有依据数据做支撑，模型输出的是准确、及时、领域相关的答案，而不是基于公开训练数据的泛泛猜测。
- 检索质量差的话生成阶段救不回来：如果检索返回的是无关段落，即便做了增强，模型也只能给出不完整或者不准确的回答。
- 所以排查 RAG 效果问题时的顺序是先查检索，再查生成，好的生成救不了坏的检索。
【真题·转述自 RAG models explained from indexing to generation（How generation works in RAG 一节）】
- 语义检索和关键词检索有什么区别？RAG 里为什么要考虑两者结合？
答: 关键词检索找的是字面上的精确匹配，语义检索找的是意图和含义上的接近，两者处理查询的方式不一样。
- 关键词检索把查询当字面处理，对同义词和上下文理解有限，比如搜「适合扁平足的跑鞋」，只返回含这个短语的结果。
- 语义检索会理解查询背后的意思，同样的问题可能召回「稳定型跑鞋」「足弓支撑跑鞋」这些不含原词但真正相关的内容。
- 简单说，关键词检索找的是词，语义检索找的是意思；实际系统里两者结合能同时覆盖术语精确匹配和语义泛化召回。
【真题·转述自 What Is Retrieval-Augmented Generation (RAG)?（Semantic Search Versus Keyword Search 一节）】
💬 应用阶段这三段，最容易翻车的是增强------检索做对了但提示词没约束住，模型照样能给你编出一段像模像样的错答案。你在项目里是怎么约束模型不乱用自身知识的，评论区聊聊。