本文收录于「流浪」的系列专栏Linux系统⚙️C数据结构与算法PythonLangChain LangGraph️MySQL 数据库Git 工具计算机网络LLM大厂面试、八股学习筑基专栏 博客主页流浪 原创首发于 CSDN上一篇把知识库构建阶段的最后一环讲完了向量连同原文和元数据一起落进向量库四段字段各管一件事选型看规模、运维和技术栈。库建好之后真正的使用阶段才刚开始——用户敲一句话进来系统要把它变成向量、在库里捞出最相关的几块、把这几块和原来的问题揉成一个像样的提示词最后交给大模型写出答案。本篇就走一遍这条线用户查询、查询向量化、向量检索、提示词增强、大模型生成也就是 RAG 里 R 到 G 的完整过程。检索的流程一、用户查询1.1 用户查询是整个检索与生成流程的起点用户查询User Query是用户在检索系统或对话系统中输入的原始问题、指令或关键词用来表达他的信息需求在 RAG 系统里它是整个检索与生成流程的起点。简单说就是用户向应用发起提问比如我们问公司的 AI 助理「公司新发布的休假政策是什么」这句话就是用户查询。这一步拿到的还是自然语言文本它不会被直接拿去和库里的东西比对后面必须再转成向量才能进入检索。用户查询是入口它决定了后面检索的方向但它本身还不能参与计算得先完成向量化。二、查询向量化2.1 查询必须用与索引阶段相同的嵌入模型转成向量用户输入问题后系统使用与索引阶段相同的嵌入模型把查询文本转换成向量表示使它和知识库中的文档向量处于同一个语义空间。这个步骤和把文本块转成向量的过程完全一样区别只在对象一个是文档块一个是用户的问题。「同一个模型」是硬要求不是建议不同模型产出的向量空间不一样跨模型的距离没有任何意义这件事在讲嵌入模型的时候已经说过一次。查询向量化最容易出错的地方就是换了模型一换模型检索并不会报错只会静默地召回一堆不相关的东西。三、向量检索3.1 向量检索是在库里找出与查询向量距离最近的一批文本块查询转成向量之后系统需要在向量数据库中快速找到语义最接近的文本块这个过程本质上是向量相似度检索用搜索算法去算查询向量与库中所有向量的距离距离越近语义越相似。距离具体怎么算余弦、欧氏、点积前面已经讲过这里看的是检索算法本身也就是怎么在海量向量里把那几个最近的捞出来。检索算法解决的是「怎么找得快」距离度量解决的是「怎么算得像」两层各管一件事。3.2 KNN 逐个算距离取最近的 K 个属于暴力搜索KNNK-Nearest Neighbor是个暴力搜索的过程它的工作流程可以拿一个场景来对照想象你在一个派对上想通过一个人的衣着打扮来判断他的职业逻辑是这样的。第一步确定 k 值决定看周围几个邻居比如 k3。第二步计算距离计算你和派对里每个人的距离算法里通常是欧几里得距离。第三步找邻居找出离你最近的 3 个人。第四步少数服从多数如果这 3 个人里有 2 个是程序员、1 个是设计师那就判定你也是程序员。这里要分清一件事第四步的投票是 KNN 用在分类任务上的做法而在向量检索这个场景里我们要的就是「最近的 K 条」本身取出来直接作为候选并不需要投票。KNN 的缺点比较明显每次预测都要计算和所有已知点的距离数据量一旦达到百万级速度会慢得让人抓狂。KNN 的本质是「一个都不放过」准确但代价是每次都全量计算规模一大就扛不住。3.3 ANN 用索引换速度牺牲极小的精度ANNApproximate Nearest Neighbor近似最近邻牺牲微小的精度换取指数级的速度提升它的工作流程分成两步。第一步建索引提前把数据库里的向量建成一张导航地图比如 HNSW 图或者分类文件夹比如 IVF 聚类。第二步查询查询向量来了之后只在地图的一小片区域里找不去管数据库另一头八竿子打不着的向量。对照着看会更直观想象你要在一座藏书 500 万册的图书馆里找一本和你手里这本内容最像的书。KNN 的做法是把 500 万本书从架子上全部搬下来一本一本翻目录对照耗时数年但能找到绝对最像的那本ANN 是先看一眼图书馆楼层导航图直接冲到「计算机类 / 四楼」只在那几百本书里细挑两分钟就找出三本内容几乎一样、肉眼根本分不出差别的书来。KNN 换的是绝对准确ANN 换的是够快而 RAG 要的是在用户能接受的延迟内给出足够好的候选所以生产环境一律用 ANN。四、提示词增强Augmented4.1 增强做的是知识补全、约束行为、格式化三件事如果说 RRetrieval检索是「找资料」GGeneration生成是「写答案」那么 A增强就是「把资料和问题揉在一起喂给模型并告诉模型怎么用」的核心过程。增强不是简单地把问题和检索到的文本块粘在一起它通常包含三个关键动作。知识补全把大模型原本不知道的私域数据、实时新闻或者长文本细节补充进提示词。约束行为明确告诉模型「请基于下面提供的参考内容来回答不要使用你自己的知识」。格式化把检索到的多个文本块可能格式各异转换成模型最容易理解和遵循的统一格式。增强增强的不是内容量是「模型拿到这批内容以后该怎么做」这件事的确定性。4.2 提示词模板化把原始问题和文本块填进预设模板系统会将你的原始问题和搜索到的文本块填入一个预设的模板中后台预设的模板大致是这个结构你是{角色名称}。请根据以下提供的【参考上下文】回答用户的问题。 【参考上下文】 {检索到的文本块 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 generationHow augmentation enhances RAG outputs 一节】检索回来的内容太多塞不下怎么办答: 靠上下文窗口管理来解决核心手段是过滤、排序和摘要把提示词压到模型吃得下又足够支撑回答的规模。注入过多段落有两种后果一是超出 token 上限直接截断二是稀释模型的注意力反而答不准。常见做法是先重排序挑出相关度最高的几条再对长段落做摘要把关键结论留下来、把铺陈删掉。压缩的前提是不丢关键结论只压篇幅不压信息量否则就是把检索的质量又赔进去一次。【真题·转述自 RAG models explained from indexing to generationHow augmentation enhances RAG outputs 一节】生成阶段大模型到底在做什么如果检索质量很差生成阶段能救回来吗答: 生成是最后一步模型读完增强后的提示词结合自己的语言理解能力和给定的具体段落写出回答同时给出引用来源方便用户核对。因为有依据数据做支撑模型输出的是准确、及时、领域相关的答案而不是基于公开训练数据的泛泛猜测。检索质量差的话生成阶段救不回来如果检索返回的是无关段落即便做了增强模型也只能给出不完整或者不准确的回答。所以排查 RAG 效果问题时的顺序是先查检索再查生成好的生成救不了坏的检索。【真题·转述自 RAG models explained from indexing to generationHow generation works in RAG 一节】语义检索和关键词检索有什么区别RAG 里为什么要考虑两者结合答: 关键词检索找的是字面上的精确匹配语义检索找的是意图和含义上的接近两者处理查询的方式不一样。关键词检索把查询当字面处理对同义词和上下文理解有限比如搜「适合扁平足的跑鞋」只返回含这个短语的结果。语义检索会理解查询背后的意思同样的问题可能召回「稳定型跑鞋」「足弓支撑跑鞋」这些不含原词但真正相关的内容。简单说关键词检索找的是词语义检索找的是意思实际系统里两者结合能同时覆盖术语精确匹配和语义泛化召回。【真题·转述自 What Is Retrieval-Augmented Generation (RAG)?Semantic Search Versus Keyword Search 一节】 应用阶段这三段最容易翻车的是增强——检索做对了但提示词没约束住模型照样能给你编出一段像模像样的错答案。你在项目里是怎么约束模型不乱用自身知识的评论区聊聊。