1.2.4 从用户提问到模型回答，中间数据流是怎么走的？

如果你已经知道 RAG 的大致流程，下一步最值得理解的就是：一条真实请求进来以后，数据到底怎么流动。

因为很多问题只有放到数据流里看，才会变得清楚。

第一步：用户输入问题

一切都从用户问题开始。系统先拿到用户原始输入，比如：

“我们产品的退款规则是什么？”

这时系统拿到的只是原始自然语言，还没有进入真正的检索阶段。

第二步：问题预处理

很多系统不会直接拿原问题去查，而是会先做一些处理，比如：

• 提取关键词
• 改写提问
• 结合对话历史补全语义
• 识别时间范围、业务范围、权限范围

这一步的输出，不一定还是用户原话，而更像一个“更适合检索的查询表达”。

第三步：检索知识库

系统拿着处理后的查询，到知识库中查找相关内容。

这一步通常会读到的数据包括：

• 文本片段
• 向量表示
• 关键词索引
• 元数据

最终会得到一批候选结果，比如若干个最相关的 Chunk。

第四步：候选结果排序和筛选

初始候选结果往往只是“可能相关”，还不是最终上下文。

系统通常会继续做一些处理：

• 去掉重复内容
• 用元数据做过滤
• 对结果重排
• 合并相邻片段
• 去掉明显无关或质量差的结果

这一步结束后，系统会留下更少但质量更高的一组内容。

第五步：构造模型输入上下文

接下来，系统会把保留下来的内容组织成模型能直接消费的输入。

这时通常会形成一份结构化输入，里面至少包含：

• 用户问题
• 检索到的资料
• 回答约束
• 可能还有引用格式要求

可以理解为：系统在这一刻把“原始材料”变成了“可回答材料”。

第六步：模型生成回答

大模型读取这份上下文以后，生成最终文本答案。

如果系统设计得比较严格，模型还可能被要求：

• 只基于提供材料作答
• 资料不足时明确说明
• 输出来源引用

所以这一步虽然是“生成”，但它并不是无约束的自由发挥。

第七步：系统返回结果

最后系统会把结果返回给用户。返回内容可能包括：

• 回答正文
• 引用来源
• 相关文档链接
• 置信提示或补充说明

有些系统还会把这次请求的中间数据记录下来，用于后续评测、诊断和优化。

为什么理解数据流很重要

因为 RAG 的很多问题，其实都能落到某个具体流转节点上。

例如：

• 回答过时，可能是知识源更新没同步
• 找不到资料，可能是查询处理或检索出错
• 资料找到了但没用上，可能是排序或上下文构造有问题
• 资料够了但模型仍乱答，可能是生成约束不够强

当你把一条请求看成一段连续数据流，就更容易理解：RAG 的问题很少只属于“模型”这一层。

如果某一步出问题，通常会表现成什么现象

把数据流理解清楚以后，一个很实用的价值是：你可以把不同问题更快定位到不同节点。

问题预处理出错，常见表现是：

• 用户换一种说法，系统就突然找不到资料
• 多轮对话里代词和上下文接不上
• 系统查出来的内容和用户真正想问的不是一回事

检索阶段出错，常见表现是：

• 明明知识库里有答案，但候选结果里没有
• 召回结果大量重复或明显不相关
• 不同相似问题召回稳定性很差

排序和筛选出错，常见表现是：

• 正确内容在候选里，但总排不进前面
• 过期内容和当前内容混在一起
• 噪声片段总是挤掉真正关键的证据

上下文构造出错，常见表现是：

• 模型答得散
• 明明给了材料，但模型抓错重点
• 长答案里出现多个来源被错误拼接

生成阶段出错，常见表现是：

• 资料不足时仍然强行补全
• 回答语气很确定，但证据其实不够
• 引用了来源，但结论并不真正忠于来源

所以这篇最重要的价值是什么

不是让你把一条请求背成流程图，而是让你以后看到问题时，能先问：

• 这件事是在哪一层开始偏的？
• 偏差是发生在找资料之前、找资料过程中，还是拿到资料之后？

只要这个视角建立起来，后面你读数据、检索、重排和生成时就会轻松很多。