拆解RAG在线工作流程：用户输入一句话，系统背后做了什么

拆解RAG在线工作流程：用户输入一句话，系统背后做了什么

大型语言模型的能力有目共睹，但它们有一个尴尬的短板：知识停留在训练截止日期。你问它昨天的新闻，它不知道；你问它公司内部的产品手册，它更不知道。RAG（Retrieval-Augmented Generation，检索增强生成）正是为解决这个问题而生——在模型生成答案之前，先从外部知识库中“翻书”找到相关资料，再让模型基于资料作答。

听起来很简单：检索，然后生成，两步走。但实际上，一个生产级的RAG系统在收到用户问题之后，要经历一整套精密的流水线处理。把这条链路拆开来看，每一步都有值得推敲的工程细节。

整体链路一览

一个典型的RAG在线流程，从用户输入到系统输出，依次经过六个节点：

#mermaid-svg-aepu0VKa3xugV8PP{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-aepu0VKa3xugV8PP .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-aepu0VKa3xugV8PP .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-aepu0VKa3xugV8PP .error-icon{fill:#552222;}#mermaid-svg-aepu0VKa3xugV8PP .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-aepu0VKa3xugV8PP .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-aepu0VKa3xugV8PP .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-aepu0VKa3xugV8PP .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-aepu0VKa3xugV8PP .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-aepu0VKa3xugV8PP .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-aepu0VKa3xugV8PP .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-aepu0VKa3xugV8PP .marker{fill:#333333;stroke:#333333;}#mermaid-svg-aepu0VKa3xugV8PP .marker.cross{stroke:#333333;}#mermaid-svg-aepu0VKa3xugV8PP svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-aepu0VKa3xugV8PP p{margin:0;}#mermaid-svg-aepu0VKa3xugV8PP .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-aepu0VKa3xugV8PP .cluster-label text{fill:#333;}#mermaid-svg-aepu0VKa3xugV8PP .cluster-label span{color:#333;}#mermaid-svg-aepu0VKa3xugV8PP .cluster-label span p{background-color:transparent;}#mermaid-svg-aepu0VKa3xugV8PP .label text,#mermaid-svg-aepu0VKa3xugV8PP span{fill:#333;color:#333;}#mermaid-svg-aepu0VKa3xugV8PP .node rect,#mermaid-svg-aepu0VKa3xugV8PP .node circle,#mermaid-svg-aepu0VKa3xugV8PP .node ellipse,#mermaid-svg-aepu0VKa3xugV8PP .node polygon,#mermaid-svg-aepu0VKa3xugV8PP .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-aepu0VKa3xugV8PP .rough-node .label text,#mermaid-svg-aepu0VKa3xugV8PP .node .label text,#mermaid-svg-aepu0VKa3xugV8PP .image-shape .label,#mermaid-svg-aepu0VKa3xugV8PP .icon-shape .label{text-anchor:middle;}#mermaid-svg-aepu0VKa3xugV8PP .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-aepu0VKa3xugV8PP .rough-node .label,#mermaid-svg-aepu0VKa3xugV8PP .node .label,#mermaid-svg-aepu0VKa3xugV8PP .image-shape .label,#mermaid-svg-aepu0VKa3xugV8PP .icon-shape .label{text-align:center;}#mermaid-svg-aepu0VKa3xugV8PP .node.clickable{cursor:pointer;}#mermaid-svg-aepu0VKa3xugV8PP .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-aepu0VKa3xugV8PP .arrowheadPath{fill:#333333;}#mermaid-svg-aepu0VKa3xugV8PP .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-aepu0VKa3xugV8PP .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-aepu0VKa3xugV8PP .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-aepu0VKa3xugV8PP .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-aepu0VKa3xugV8PP .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-aepu0VKa3xugV8PP .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-aepu0VKa3xugV8PP .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-aepu0VKa3xugV8PP .cluster text{fill:#333;}#mermaid-svg-aepu0VKa3xugV8PP .cluster span{color:#333;}#mermaid-svg-aepu0VKa3xugV8PP div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-aepu0VKa3xugV8PP .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-aepu0VKa3xugV8PP rect.text{fill:none;stroke-width:0;}#mermaid-svg-aepu0VKa3xugV8PP .icon-shape,#mermaid-svg-aepu0VKa3xugV8PP .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-aepu0VKa3xugV8PP .icon-shape p,#mermaid-svg-aepu0VKa3xugV8PP .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-aepu0VKa3xugV8PP .icon-shape .label rect,#mermaid-svg-aepu0VKa3xugV8PP .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-aepu0VKa3xugV8PP .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-aepu0VKa3xugV8PP .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-aepu0VKa3xugV8PP :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

用户原始Query

① Query预处理

② Query向量化

③ 多路召回

④ Rerank精排

⑤ Prompt拼装

⑥ LLM生成 + 溯源

下面按顺序逐一展开。

分步拆解：六大环节

第一步：Query预处理

用户不会按照检索系统的喜好来提问。真实场景中，用户输入往往是口语化的、带着指代和省略的。比如“上次说的那个方案怎么样了”——离开对话上下文，这句话对检索系统来说毫无意义。又或者用户用词习惯和知识库文档的用词差异很大，直接拿去检索，命中率惨淡。

Query预处理的核心思路是：在检索之前，先把用户的问题“翻译”成适合检索的形式。常见策略有三种：

基础改写，用一个小模型将口语化问题转成独立、完整的检索语句，补全省略信息、消解指代、统一术语。这一步延迟很低，几十毫秒就能完成。

HyDE（Hypothetical Document Embeddings） 的思路更巧妙：不让LLM改写问题，而是让它先“假设性地”写一篇答案，再拿这篇假设答案的向量去做检索。背后的逻辑是，短问题和长文档之间存在严重的模态不匹配，但假设答案和真实文档在文本形态上天然接近，语义空间里的匹配效果更好。这有点像“用答案去找答案”。

多角度扩写则走覆盖路线，把同一个问题扩展成三到五种不同表述，分别检索后合并结果，适合问题本身比较宽泛、可以从多个维度回答的场景。

第二步：Query向量化

Query改写完毕，需要用Embedding模型把它转为向量，才能在向量库里做相似度搜索。

这一步本身不复杂，但有一个容易被忽视的硬性约束：检索时必须用和建库时完全相同的Embedding模型。原因很简单，不同Embedding模型的向量空间是各自独立的。模型A的坐标系里，“苹果手机”和“iPhone”可能是近邻；在模型B的坐标系里，两者可能相距甚远。更不用说输出维度都可能不一样——1024维和1536维之间根本没有距离可算。

工程上的推论是：一旦决定换Embedding模型，整个知识库的向量索引必须重建。老向量和新查询不在同一套坐标系里，任何相似度计算都没有意义。

第三步：多路召回

拿到Query向量后，在向量数据库里做近似最近邻搜索（ANN），按余弦相似度拉回Top-K个候选文档。百万量级的库，几十毫秒就能出结果。

但单靠向量检索不够。向量检索的优势是语义匹配，同义改写、近义表达都能兜住。短板也很明显：精确关键词（产品型号、错误码、专有名词）的识别能力弱，拼写偏差也会把向量带偏。

所以工程上几乎都是双路并行——再加一路BM25关键词检索。BM25基于词频统计，对精确术语的匹配能力是向量检索无法替代的。用户问“LSTM和Transformer的区别”，向量检索能捞到讨论序列模型对比的段落，BM25能锁定同时出现“LSTM”和“Transformer”这两个词的片段，两路互补。

两路结果怎么合并？业界普遍用RRF（Reciprocal Rank Fusion）：

$$score=\sum \frac{1}{k+ran{k}_i}$$

k通常取60。RRF只看排名不看绝对分值，天然免疫不同打分尺度的影响，稳定且无需调参。

第四步：Rerank精排

多路召回合并后，候选集合可能有几十条。显然不可能条条都高质量，噪音是免不了的。Rerank的作用就是从中筛出最精华的那几条。

这里涉及两种模型架构的区别。向量检索用的是Bi-Encoder：Query和Document各自独立编码，然后算向量相似度，速度快但Query和Document在编码时没有交互。Rerank用的是Cross-Encoder：把Query和每个候选Document拼在一起送入模型，通过注意力机制让两者充分交叉，输出一个精细的相关性分数。

那为什么不直接拿Cross-Encoder扫全库？因为太慢了。对百万级文档逐一算分，延迟完全不可接受。所以工程上的两阶段策略是：Bi-Encoder粗排把候选从百万缩到几十，Cross-Encoder再从几十里精挑出3到5条。精排多花几百毫秒，但检索质量提升显著。

第五步：Prompt拼装

精排后的片段到手，接下来把它们和用户问题组装成Prompt。一个典型的模板大概是这样的：

你是一个专业助手，请根据以下参考资料回答用户的问题。
如果参考资料中没有相关信息，请回答「根据现有资料无法回答」，不要自行猜测。

参考资料：
[1] {chunk_1}
[2] {chunk_2}
[3] {chunk_3}

用户问题：{user_query}

模板看着简单，每条指令心思都很明确。“根据参考资料回答”是在给模型划边界，抑制它凭参数记忆自由发挥的冲动——大模型天生喜欢帮忙，资料里没有它也可能自己编。“不知道就说不知道”则进一步堵住信息不足时强行补全的口子。引用编号的存在，是为了后续答案里能标注来源。

Prompt设计是RAG系统中性价比最高的优化点之一，改几行字就可能显著影响答案质量，成本几乎为零。

第六步：LLM生成与溯源

大模型拿到Prompt后基于参考资料生成答案。到这一步，检索增强的核心链路基本走完。

但真正严谨的系统还会要求模型在答案中标明引用来源，比如“根据资料[1]……”。这一步经常被低估。很多人觉得有了RAG就不会有幻觉，实际上大模型拿到资料后仍然可能过度推断或选择性解读。溯源把“答案对不对”的核验权交给了用户——用户可以根据引用标记回到原始文档自行判断。

整个在线链路的耗时分布大致是：Query改写几十毫秒，向量检索几十毫秒，Rerank几百毫秒，Prompt拼装可忽略，模型生成1到10秒（视输出长度而定）。高频Query缓存、向量检索和BM25并行执行，都是常见的进一步压缩延迟的手段。

不止于管道：RAG正在演进的几个方向

上述六步构成了RAG在线流程的基本盘。但RAG技术本身远未定型，它正在沿着几条主线持续演进。

Agentic RAG打破了传统RAG“一次检索就完事”的假设。更智能的系统会在生成过程中动态判断：当前信息够不够？要不要换个角度再搜？检索到的内容有没有矛盾需要核实？RAG从被动执行的管道变成了自主决策的循环。

GraphRAG将知识图谱引入检索增强。向量检索本质上是“找相似的文本”，但现实中有大量需要多跳推理的问题——“这家公司CEO的母校是哪所”的答案散落在不同文档里，单次向量检索几乎不可能命中。GraphRAG从文档中抽取实体和关系构建图谱，让检索变成路径推理，大大拓展了系统处理复杂问题的能力。

多模态RAG则将检索范围从纯文本扩展到图片、表格、音视频。企业知识库里从来不只有文字——PDF里的架构图、Excel里的数据表、会议录音的文字稿，纯文本RAG对这部分内容束手无策。多模态嵌入模型和视觉语言模型的成熟，正在打开这块信息蓝海。

结语

RAG在线流程远不止“检索+生成”四个字。Query预处理决定了输入质量的上限，向量化环节有模型一致性的硬约束，多路召回让语义和关键词互补，Rerank精排完成从粗到细的筛选，Prompt拼装建立行为边界，溯源则让答案可验证、可追溯。每个环节独立看似乎都不复杂，但连在一起，细节处的取舍决定了系统的最终表现。

理解这条链路的每一个节点，是从“会用RAG”走向“做好RAG”的第一步。
束，多路召回让语义和关键词互补，Rerank精排完成从粗到细的筛选，Prompt拼装建立行为边界，溯源则让答案可验证、可追溯。每个环节独立看似乎都不复杂，但连在一起，细节处的取舍决定了系统的最终表现。

理解这条链路的每一个节点，是从“会用RAG”走向“做好RAG”的第一步。