流式 RAG：边检索边生成的实时体验工程

传统 RAG 的体验瓶颈：串行的等待

传统 RAG 的执行是严格串行的：用户提问 → 等待检索（1–3 秒）→ 等待生成（3–30 秒）→ 完整结果出现——用户在整个过程中只能看到「思考中」的转圈。体验的痛点：等待时间不可见（用户不知道系统在干什么）、长时间的无反馈（超过 5 秒用户就焦虑）、以及完整结果的延迟（最后一个 token 可能 30 秒后才出现）。

流式 RAG 的目标：让用户在等待中看到进展——检索的阶段结果先出现、生成从第一个 token 就流式输出、中间发现需要更多信息时追加检索——把「等待」变成「观看」。

架构模式：渐进式检索与流式生成

模式一：检索阶段的事件流。检索不是一瞬间的——它有内部步骤（查询改写 → 向量检索 → 重排序）——把这些步骤的状态推送为事件（「正在检索相关文档…」「找到 5 篇相关文档」「正在重排序…」）——用户看到检索的进展而非转圈。模式二：流式生成。检索完成后，LLM 的生成是逐 token 的流式输出（本库流式篇）——第一个 token 在检索完成后的 1–2 秒内出现——用户在检索完成后立即开始阅读。模式三：渐进式检索（iterative retrieval）。Agent 式的 RAG（本库 Agentic RAG 篇）中，第一轮检索的初步结果可以先展示、后续的深入检索在后台继续——「我先告诉你初步发现，还在深入调查」——两层结果的时间分离让用户更快获得有价值的信息。

延迟优化的策略：从检索到生成的每一毫秒

检索阶段的优化。检索的并行化：多个知识源的并行检索（不等第一个完成再查第二个——并行发起全部检索——本库弹性伸缩篇的并行思路）、检索结果的渐进展示（重排序完成前先展示 top-10 的原始结果、重排序后更新排序——先给个大概、再给个精确）。生成阶段的优化。前缀缓存（query 的改写部分如果与之前的查询共享前缀——缓存命中消 prefill，本库 Prefix Caching 篇）、prompt 的瘦身（检索上下文的精选而非全塞——本库上下文工程篇）、以及生成引擎的批处理效率（本库 vLLM 篇的连续批处理）。

端到端的延迟预算（目标 TTFT < 3s）：查询理解 < 200ms → 并行检索 < 1s → 重排序 < 500ms → 上下文组装 < 100ms → 首 token < 1s → 流式输出持续。每一段的优化是独立可做的——TTFT 的分解与归因，是流式 RAG 性能调优的核心方法。

流式 UI 的设计：让过程可见且可控

UI 的设计原则。原则一：阶段可见——检索阶段、生成阶段、引用阶段分别展示（「正在检索…找到 5 篇…正在回答…」——让用户知道系统在做什么）。原则二：引用的实时嵌入——生成过程中引用的文档在 UI 上实时标注（生成到「根据文档 3」时，文档 3 的卡片高亮——用户可以边读边溯源）。原则三：追加的优雅处理——Agent 式的追加检索导致回答内容变化时——UI 的增量更新（追加的内容出现在已有回答之后、而非替换全部——增量渲染的工程，本库流式篇）。原则四：中断的优雅处理——用户在流式输出中点击「停止」——已生成的部分保留、未生成的部分标记中断——与完整输出的体验一致。

工程要点：SSE 的多通道事件（本库流式篇——文本、工具调用、检索状态的多通道流）、前端的增量 Markdown 渲染（未闭合的代码块与表格的渐进修正）、以及引用与正文的联动（正文中的引用编号与引用列表的交互高亮）。

## 流式 RAG 的进阶：Agent 式的渐进式检索实现

流式 RAG（正文模式三）的进阶：Agent 式渐进式检索的实现——检索与生成的交错执行。机制的详细拆解。第一轮检索 → 初步结果展示给用户（「找到了以下相关文档…」）→ LLM 基于初步结果生成「初步回答」 → LLM 判断「回答是否足够」——不够则发起第二轮检索（「需要更多信息关于 X」） → 第二轮结果追加 → 更新回答 → 直到满意或达到轮次上限。工程实现：Agent 循环（本库 Agent 工程第 2 章——检索工具 + 生成工具 + 判断工具的循环）、用户端的体验设计（每轮的结果增量追加——不是替换而是补充——用户看到的是「越来越完整的回答」）。渐进式检索的成本：每轮检索 + 生成的 token 成本（两轮 = 两倍成本——成本与质量的权衡：简单问题一轮够、复杂问题两轮好）。渐进式的收束：渐进式检索让 RAG 从「一次定生死」变成「迭代逼近」——用户在第一轮就获得有价值的信息、后续轮次逐步完善——「先给个大概、再给个精确」是用户友好的策略。

流式 RAG 的进阶：多阶段检索的流式体验设计

流式 RAG（正文模式）的进阶：多阶段检索的流式体验——Agentic RAG 的多轮检索如何做流式展示。多阶段检索的流式展示：第一轮检索（快速向量检索）→ 展示初步结果 → 第二轮检索（深入的重排序与交叉检索）→ 更新结果 → 第三轮（如果需要）→ 最终答案。每阶段的流式展示：阶段状态的事件推送（「第一轮检索完成，找到 8 篇」「开始深入分析…」）——用户看到的不是空白等待，是「进展的报告」。多阶段的 UI 设计：阶段之间的过渡动画（检索阶段 → 生成阶段的切换）、阶段结果的渐进展示（每阶段的结果增量追加而非替换——本库流式篇的增量渲染）。多阶段流式的收束：多阶段检索的流式展示，让 Agentic RAG 的「多轮检索」从「黑盒等待」变成「白盒进展」——用户不仅看到答案，还看到「答案是怎么来的」——透明度是信任的基础。

流式 RAG 的实战案例：一个客服系统的流式改造

流式 RAG 的实战案例：客服系统的流式改造——从串行到流式的体验升级。改造前的体验：用户提问 → 等 5 秒 → 完整回答出现（串行的等待体验）。改造后的体验：用户提问 → 1 秒内「正在检索知识库…」→ 检索完成后开始流式输出 → 用户逐字阅读 → 引用实时标注 → 完整回答（等待变成阅读）。改造的技术：检索阶段的事件推送（SSE 的检索状态事件——本库流式篇）、生成的流式输出（SSE 的 token 流——本库流式篇）、前端的流式渲染（增量 Markdown 解析——本库流式篇）。改造的效果：TTFT 从 5 秒降到 1.5 秒、用户满意度提升（感知延迟的大幅降低）。案例的收束：流式改造是 RAG 体验升级中 ROI 最高的项目——技术改造的量不大、体验的提升却是立竿见影的。

流式 RAG 的进阶：前端的流式渲染架构

流式 RAG（正文 UI）的进阶：前端的流式渲染架构——React 中的流式 RAG 渲染。流式渲染的挑战：token 的增量到达（每个 SSE 事件带一个增量 token——前端需要拼接）、Markdown 的渐进渲染（未闭合的代码块与表格——未闭合语法的安全渲染）、引用的实时标注（流式输出中的引用编号——引用的实时插入）。React 的实现方案。状态管理：useReducer 管理流式状态（messages、currentStream、references 的状态分离）。增量 Markdown：每个 token 到达后重新渲染当前段落（而非全文重渲——性能的优化：只渲染变化的段落）。性能的优化：token 的批量渲染（50ms 节流——不是每个 token 单独渲染，而是每 50ms 批量渲染一次——渲染的频率控制是性能的关键）。流式渲染的收束：前端的流式渲染，是「token 的流 + 状态的管理 + 渲染的优化」的组合工程——每一个环节的性能都影响整体体验；React 的 hooks 体系提供了流式渲染的完整工具链。

流式 RAG 的进阶：Agent 式渐进式检索

流式 RAG 的进阶：Agent 式渐进式检索的实现——检索与生成的交错执行。机制的拆解：第一轮检索初步结果展示给用户、LLM 基于初步结果生成初步回答、LLM 判断回答是否足够——不够则发起第二轮检索、第二轮结果追加、更新回答、直到满意或达到轮次上限。工程实现：Agent 循环（检索工具、生成工具、判断工具的循环）、用户端的体验设计（每轮的结果增量追加——不是替换而是补充——用户看到的是越来越完整的回答）。渐进式检索的成本：每轮检索加生成的 token 成本——两轮等于两倍成本——成本与质量的权衡需要预算上限兜底。渐进式检索的收束：渐进式检索让 RAG 从「一次定生死」变成「迭代逼近」——用户在第一轮就获得有价值的信息、后续轮次逐步完善——先给个大概、再给个精确，是用户友好的策略。

流式 RAG 的错误处理与断线重连

流式 RAG 的错误处理：SSE 连接的断线重连（网络抖动导致的连接中断——前端自动重连并从中断处续传——EventSource 的自动重连机制与自定义的断点续传协议）、生成中断的优雅处理（LLM 服务中途失败——已输出的内容保留、失败的位置标注「生成中断」、提供重试按钮——不丢弃已生成的内容）、以及流式状态的可见性（连接状态指示器——实时显示「连接正常/重连中/已断开」——状态可见让用户理解发生了什么）。错误处理的收束：流式体验的错误处理决定「故障时的体验下限」——优雅的断线重连与中断恢复让故障对用户的冲击最小化——流式的可靠性设计与流式的性能设计同等重要。

小结

流式 RAG 把「等待—出结果」的串行体验升级为「边检索边生成边展示」的并行体验：架构上用事件流分离检索与生成的阶段、用渐进式检索让初步结果先行、用流式生成让首个 token 快速到达。延迟优化逐段归因（检索并行化、prompt 瘦身、生成引擎批处理），UI 设计让过程可见可控。流式 RAG 的核心理念：让用户在等待中看到进展——进展感是 AI 产品的体验生命线。