RAG 回答流程问题容易漏步骤，核心原因是：标准 chunk 级检索只保证“片段相关”，不保证“流程完整”。当上线流程、审批流程、权限申请流程被切成多个片段后，系统可能只召回其中最相似的几段，模型就会把局部步骤当成完整流程来回答。
解决思路不是简单调大 topK，而是给流程类知识增加文档级结构：用文档总览说明主题，用完整步骤保住主路径，再用命中片段回答细节。这样才能同时兼顾检索精准度和流程完整性。
RAG（Retrieval-Augmented Generation，检索增强生成）在知识问答里已经很常见。它的基本思路是：先检索相关知识片段，再让大模型基于片段生成答案。
这个模式在很多问题上都有效，尤其适合 FAQ、概念解释、规则查询、单点事实问答。
比如：
- 某个术语是什么意思？
- 某个系统入口在哪里？
- 某类工单适用于什么场景？
- 某个错误码代表什么？
这些问题通常是“点状”的。只要召回一个或几个相关片段，模型就可以生成相对完整的回答。
但流程类知识不一样。
流程类问题要的不是一个知识点，而是一条完整路径。用户真正想知道的是：
我应该按什么顺序做？每一步做什么？在哪里做？谁来做？有什么前置条件和注意事项？
这正是标准 RAG 容易出问题的地方：它能召回相关片段，但不一定能还原完整流程。
一、流程类问题为什么更难
企业知识里有大量流程类内容，例如：
- 一个需求从提报到上线要经过哪些步骤？
- 申请测试环境需要走什么流程？
- 新员工开通权限需要做哪些准备？
- 系统上线前、中、后分别要检查什么？
- 生产问题应急处理流程是什么？
这些问题和普通知识问答有几个明显区别。
1. 顺序很重要
流程不是步骤列表的简单集合，而是一条有前后依赖的路径。
“先测试再审批”和“先审批再测试”，可能对应完全不同的执行要求。模型如果只召回中间某个步骤，就很容易给出顺序不完整甚至顺序错误的答案。
2. 前置条件很重要
很多流程不是任何时候都能开始。它可能要求：
- 已完成某个评审；
- 已具备某个权限；
- 已通过测试；
- 已完成资料准备；
- 已获得相关负责人确认。
如果回答只给中间步骤，不给前置条件，用户可能从错误的位置开始执行。
3. 角色分工很重要
企业流程通常涉及多个角色：申请人、审批人、负责人、执行人、验收人、运营人员等。
同一个步骤由谁做，往往和步骤本身一样重要。
4. 异常和兜底很重要
流程执行中经常遇到异常：审批不通过、权限不足、系统不可用、信息不完整、发布失败等。
如果回答缺少异常处理和兜底指引，用户仍然需要回到人工咨询。
这些特征决定了：流程类知识不能只用“片段相关性”来处理，还必须考虑“流程完整性”。
二、标准 chunk 级 RAG 的局限
很多 RAG 系统默认以 chunk 作为检索和上下文注入的基本单位。文档会被拆成若干片段，用户提问时，系统召回 topK 个最相关片段，再交给大模型生成回答。
这个设计本身没有问题。
切片可以提升检索精度，控制上下文长度，也方便向量化和索引。但在流程类知识问答中，它会带来一个结构性局限：
chunk 是局部的，流程是全局的。
一个完整流程可能包含：
- 背景说明；
- 适用范围；
- 前置条件；
- 角色分工；
- 具体步骤；
- 审批节点；
- 系统入口；
- 异常处理；
- 后置检查；
- 注意事项。
当这些内容被切成多个 chunk 后，检索系统通常只能召回其中最相似的几个片段。它能保证“相关”，却不一定能保证“完整”。
这就是流程类 RAG 的关键矛盾：
为了检索精准，需要切片；
但为了回答完整，又需要跨片段理解整个流程。三、一个典型例子
假设有一篇抽象化流程文档，标题是《应用上线流程》，内容结构如下：
1. 上线前准备
1.1 需求验收
1.2 测试通过
1.3 代码合并
1.4 发布计划确认
2. 上线审批
2.1 创建审批单
2.2 选择影响范围
2.3 填写回滚方案
2.4 负责人审批
3. 发布执行
3.1 灰度发布
3.2 监控观察
3.3 全量发布
4. 上线后验证
4.1 功能回归
4.2 日志检查
4.3 业务确认
4.4 复盘记录用户问：
应用上线流程怎么走？
如果系统召回的是“上线审批”这一段，因为“上线流程”和“审批”有较强相关性，模型可能回答：
应用上线需要先创建审批单，选择影响范围，填写回滚方案，并等待负责人审批。这个回答并不是完全错误的，但它是不完整的。
它漏掉了：
- 上线前准备；
- 需求验收；
- 测试通过；
- 代码合并；
- 发布计划确认；
- 灰度发布；
- 监控观察；
- 上线后验证；
- 业务确认和复盘。
对于用户来说，这种答案反而有风险。因为它让用户误以为“上线流程就是提审批”。
流程类问答最麻烦的地方就在这里：答案局部正确，但全局错误。
在企业流程场景中，局部正确但缺步骤，可能比直接回答“不知道”更危险。
四、为什么标准 RAG 容易漏步骤
1. 切片破坏了流程整体结构
切片通常以长度、标题、段落或语义边界为单位。无论采用哪种方式，完整流程都会被拆开。
流程本身具有顺序性和依赖关系：
前置条件 → 操作步骤 → 审批节点 → 执行动作 → 验证闭环但 chunk 之间通常只是松散相关。检索系统未必知道某个 chunk 是流程的第几步，也未必知道它前后还依赖哪些步骤。
2. topK 限制导致上下文截断
为了控制成本、延迟和上下文长度，RAG 系统通常会限制召回数量，例如 top3、top5 或 top10。
如果一个完整流程分布在十几个 chunk 中，即使每个 chunk 都相关，也不可能全部进入上下文。
结果是：
- 召回少了，答案缺步骤；
- 召回多了，成本升高、噪声增加、模型注意力分散。
这是流程问答中的典型工程取舍。
3. 相似度排序偏向局部强匹配
向量相似度和关键词匹配都更擅长判断“这个片段是否与问题相关”，但不擅长判断“这个片段是否能代表完整流程”。
某些片段因为标题、关键词或描述更接近用户问题，会排得很靠前；但完整流程中其他必要步骤，可能因为文字不够相似而被排到后面，甚至被 topK 截断。
4. 模型可能自动补全，形成隐性幻觉
如果 Prompt 约束不够强，大模型看到部分流程后，可能会根据通用经验补全缺失步骤。
比如看到“审批”和“发布”，模型可能自动补出“测试”“回滚”“监控”等内容。
这些内容可能符合常识，但不一定符合原文要求。它带来的问题更隐蔽：
- 答案看起来更完整；
- 用户更容易相信；
- 但其中部分步骤没有知识来源；
- 后续执行时可能与真实流程冲突。
所以流程类 RAG 不仅要防止“答少了”，还要防止“补多了”。
五、改进思路：从片段级 RAG 到双层上下文建模
解决这个问题的关键不是放弃 chunk，而是给 chunk 增加文档级上下文。
可以把方案概括为：
片段负责精准召回，文档级总览和完整步骤负责补足全局结构。
也就是建立“双层上下文建模”：
文档级上下文
- 文档标题
- 文档摘要 / 总览
- 适用范围
- 完整步骤
- 关键注意事项
切片级上下文
- 命中标题路径
- 命中片段内容
- 局部细节
- 图片 / 表格 / 示例在线检索时，不只是把命中的 chunk 交给模型，而是：
用户问题
↓
召回相关 chunk
↓
根据 chunk 找到所属文档
↓
带上该文档的总览和完整步骤
↓
再附加具体命中片段
↓
让模型基于“总览 + 步骤 + 细节”回答这样可以同时保留两种能力：
- chunk 的精准召回能力；
- 文档级结构的完整性。
六、文档级总览：让模型先知道这篇文档讲什么
总览字段可以理解为文档级摘要，但它不只是压缩正文，而是帮助模型建立全局判断。
一个好的总览字段应该包括：
- 文档主题；
- 适用对象；
- 适用场景；
- 核心结论；
- 与其他流程或系统的关系；
- 重要限制或注意事项。
例如：
本文档说明应用上线从准备、审批、发布到上线后验证的完整流程，适用于常规应用版本发布。上线前需完成需求验收、测试通过、代码合并和发布计划确认；上线过程中需完成审批、灰度发布和监控观察；上线后需进行功能回归、日志检查和业务确认。这个总览不替代正文，但能让模型知道：当前命中的片段属于哪一类流程，完整流程大致覆盖哪些阶段。
当用户问宽泛问题时，总览尤其有用。
七、完整步骤字段：专门解决流程缺步
完整步骤字段是流程类 RAG 的关键设计。
它不是普通摘要，而是结构化抽取出来的流程骨架。
例如：
1. 完成上线前准备：确认需求验收、测试通过、代码合并和发布计划。
2. 创建上线审批：填写影响范围、回滚方案和发布时间。
3. 等待负责人审批：审批通过后进入发布执行。
4. 执行灰度发布：先发布部分流量或部分实例。
5. 观察监控指标：确认错误率、延迟和核心业务指标正常。
6. 执行全量发布：灰度无异常后完成全量发布。
7. 完成上线后验证：进行功能回归、日志检查和业务确认。
8. 记录结果或复盘：如有异常，补充问题记录和改进措施。完整步骤字段的目标不是包含所有细节，而是保证模型在回答流程类问题时不会漏掉主路径。
它解决的是：
- chunk 只命中局部；
- topK 无法覆盖全部步骤；
- 模型不知道流程全貌；
- 回答容易缺前置和后置动作。
可以把完整步骤理解为“文档级流程索引”。
八、命中细节：保留精准回答能力
只带总览和完整步骤还不够。用户很多时候问的是流程中的某个细节。
例如：
- 上线审批需要填哪些字段？
- 灰度发布后要观察什么指标？
- 如果审批不通过怎么办？
- 上线后验证由谁确认？
这些问题需要命中具体 chunk。
因此，最终给模型的上下文最好包含三类信息：
文档总览：告诉模型这篇文档讲什么
完整步骤：告诉模型流程主路径是什么
命中细节：告诉模型用户问题具体落在哪个局部这三者的关系可以理解为：
- 总览负责“定方向”；
- 完整步骤负责“保完整”；
- 命中细节负责“答具体”。
九、推荐的数据结构
可以用一个通用结构表示文档和切片。
文档级字段：
document_id 文档唯一 ID
source_type 知识来源类型
title 文档标题
summary 文档总览 / 摘要
scope 适用范围
full_steps 完整步骤
version 文档版本
updated_at 更新时间
acl_tags 权限标签
content_hash 内容哈希切片级字段：
chunk_id 切片唯一 ID
document_id 所属文档 ID
chunk_index 切片序号
heading_path 标题路径
content_text 纯文本内容
content_markdown 保留格式的内容
embedding 向量
keywords 关键词在线检索命中 chunk 后，根据 document_id 关联文档级字段，再组装上下文。
一个推荐的上下文格式如下：
【命中文档】应用上线流程
摘要：本文档说明应用上线从准备、审批、发布到上线后验证的完整流程...
完整步骤：
1. 完成上线前准备...
2. 创建上线审批...
3. 等待负责人审批...
...
命中细节：
[片段1] 上线审批 > 填写回滚方案
上线审批单中需要填写影响范围、回滚方案、发布时间...
[片段2] 发布执行 > 灰度发布
灰度发布后需要观察错误率、延迟和核心业务指标...需要注意：summary 和 full_steps 本身也属于知识内容，也要经过权限控制、版本管理和审计。
十、Prompt 也要配合
有了总览和完整步骤字段，还需要在 Prompt 中明确告诉模型如何使用它们。
否则模型可能仍然只盯着命中片段，忽略完整步骤。
可以增加类似约束：
回答流程类问题时，优先依据“完整步骤”给出主流程顺序。
如果“命中细节”只覆盖局部步骤，不得将局部步骤当作完整流程。
如果某个步骤缺少具体操作细节，可以说明“该步骤的详细操作未在检索结果中体现”。
不得根据常识补充未出现在检索结果中的企业流程。这类 Prompt 约束非常关键。它把模型从“总结检索片段”引导为“基于文档级结构回答流程问题”。
十一、不同问题要用不同上下文策略
流程类问题可以分成两类。
1. 宽泛流程问题
例如：
- 上线流程怎么走？
- 权限申请需要哪些步骤？
- 新项目环境申请流程是什么？
这类问题应该优先使用完整步骤字段，输出完整主路径。
回答重点是：
- 阶段；
- 顺序；
- 前置条件；
- 关键节点；
- 必要系统或工单；
- 注意事项。
2. 细节追问问题
例如：
- 上线审批单里的回滚方案怎么填？
- 灰度发布要观察哪些指标？
- 权限申请被驳回怎么办？
这类问题应该以命中细节为主，同时利用完整步骤说明该细节处于流程的哪个位置。
换句话说：
问全流程 → 用完整步骤兜住主路径
问局部细节 → 用命中片段答细节，用完整步骤补位置感十二、怎么评估流程类 RAG 是否有效
流程类 RAG 的评估不能只看“有没有召回相关文档”，还要看“回答是否完整”。
建议构建专门的评测维度：
| 评估维度 | 说明 |
|---|---|
| 步骤完整性 | 是否覆盖主流程中的关键步骤 |
| 顺序正确性 | 步骤顺序是否符合原文 |
| 前置条件 | 是否说明必要前置条件 |
| 角色责任 | 是否说明关键角色或负责人 |
| 系统入口 | 是否给出必要系统或工单入口 |
| 异常处理 | 是否说明失败、驳回、权限不足等兜底情况 |
| 来源一致性 | 回答内容是否都能在检索结果中找到依据 |
| 拒答能力 | 原文没有的信息是否避免编造 |
可以为每个流程维护黄金答案，例如：
问题：应用上线流程怎么走？
必须包含：上线前准备、审批、灰度发布、监控观察、全量发布、上线后验证
不能出现：原文未提到的审批系统、未授权的发布方式、虚构负责人这样才能真正评估流程类回答的质量。
十三、落地时的取舍
双层上下文建模不是没有成本。
1. 需要额外的数据生产
summary 和 full_steps 需要抽取、审核和维护。可以由模型辅助生成，但关键流程建议人工审核。
2. 需要版本同步
正文更新后，summary 和 full_steps 也必须同步更新，否则会出现正文和流程骨架不一致的问题。
如果 summary 和 full_steps 由模型辅助生成，还要防止模型把原文没有的步骤“整理”进流程骨架。一旦错误内容被写入文档级字段，后续检索会把它当成正式知识反复使用。因此建议保存生成来源、依据片段、审核状态和版本号，关键流程必须经过人工确认后再发布。
3. 上下文长度会增加
每次命中文档都带上总览和完整步骤，会增加上下文长度。可以通过以下方式控制：
- 只对流程类文档启用；
- 只对宽泛流程问题启用完整步骤；
- 对多个命中文档去重；
- 限制进入上下文的文档数量；
- 将 full_steps 控制为主路径，而非所有细节。
4. 仍然需要权限控制
文档级总览和完整步骤可能包含敏感流程信息，不能因为它们是摘要就跳过权限控制。
十四、总结
标准 RAG 解决的是“如何找到相关内容”，但流程类知识问答真正需要解决的是“如何还原完整路径”。
这两件事并不等价。
对于 FAQ、概念解释、单点事实查询，chunk 级召回通常已经足够；但对于审批、上线、权限、资源申请、工单办理、应急处理等流程类场景，只召回相关片段很容易导致答案缺步骤、缺前置条件、缺后续验证，甚至诱发模型用常识补全企业流程。
因此，流程类 RAG 更适合采用“双层上下文建模”：
切片级内容负责精准召回；
文档级总览负责理解全局主题；
文档级完整步骤负责保证流程完整；
命中细节负责回答具体问题。这套设计的核心价值可以概括为一句话：
RAG 能找到相关内容，但业务用户需要的是完整可执行路径。
把这个问题处理好，RAG 才能从“知识问答工具”进一步走向“流程助手”。
完整源码
这篇文章诊断的“标准 chunk 容易漏步骤”，在 agent-runtime-lab 里能直接观察到：它的知识库就是按段落切片（带 overlap 和标题路径）+ 混合检索的标准形态，遇到流程类问题同样可能召回不全。至于本文提出的双层上下文、完整步骤字段这些改进，目前还没在项目里实现，是可以继续做的方向——如果你想拿它当改进起点，切片和检索代码在 src/runtime/knowledge/。
本系列文章
- 第一篇：本文 — 流程类 RAG 的专项问题与双层上下文方案
- 第二篇：企业级 RAG 怎么落地？ — 知识治理、权限、安全与运营闭环
- 第三篇：RAG 检索不准？先别换模型，把问题问对再说 — 查询转换、路由与查询构建
- 第四篇：RAG 答非所问？从索引到生成，打通最后一公里 — 索引、检索与生成