导语：检索增强生成（RAG）技术发展至今，行业逐渐触碰到一个核心矛盾——"检索到了，但没读懂"。KnowFlow v2.3.4 给出了一个不同的答案：让 AI 像人类专家一样，先定位、再精读、再作答。
一个真实的场景
某制造业客户的质量工程师，需要从一份 200 页的国标文件中找到"涂层体系的环境适应性要求"。他在企业知识库里输入问题，系统返回了 5 段文本片段——有的来自"术语定义"，有的来自"检测方法"，有的确实来自"性能要求"章节，但只截取了半段话。
工程师看了一眼，关掉页面，打开 PDF 自己翻。
这不是个例。传统 RAG 系统的检索-生成管线，在面对结构复杂的专业文档时，几乎都会遇到同样的困境：检索环节能找到相关片段，但生成环节无法还原文档的完整逻辑链。一个跨越三个章节的技术规范，被切成孤立的文本块后，上下文断裂、因果关系丢失，AI 只能拼凑出一个看似通顺但经不起推敲的回答。
KnowFlow v2.3.4 的核心升级，就是为了解决这个问题。
为什么传统 RAG 不够用？
在展开新版本之前，有必要厘清一个被行业普遍忽视的问题。
主流 RAG 系统的工作流程是：分块 → 向量化 → 检索 Top-K → 拼接进 Prompt → 大模型生成。这个流程的假设是——"只要检索到最相关的几段文本，大模型就能给出正确答案"。
简单问答场景下确实成立。比如"公司的退货政策是什么"，答案大概率在某一段话里写得明明白白。但当问题变复杂，这个假设就开始崩塌：
-
• 信息分散——"哪些条款涉及供应商的连带责任？"答案可能散落在合同正文、附件条款、补充协议三个不同位置。Top-K 检索最多召回其中两处，第三处因为表述差异被排在了第 20 名之后。
-
• 上下文截断——"第三章提到的'特殊情形'具体指什么？"检索到的片段可能只包含定义，缺少上一段的适用条件和下一段的排除情形。
-
• 结构感缺失——专业文档有严格的章节层级、交叉引用和术语体系。传统分块把文档打散成平坦的文本碎片，章节从属关系、引用链条全部丢失。
这些问题不是靠"增大 Top-K"或"优化分块策略"能根本解决的。它们指向一个更深层的需求：RAG 系统不仅需要"检索"能力，还需要"阅读"能力。
Agentic RAG：从"检索"到"深度阅读"
KnowFlow v2.3.4 引入的 DeepRead 模式，是一套基于 Agentic RAG 架构的深度阅读方案。核心思路借鉴了学术界的 locate-then-read 策略：先定位，再精读，必要时多轮迭代，直到信息充分才作答。
与传统"一次检索、直接生成"不同，DeepRead 的工作过程更接近一个人类研究员查阅资料的方式：
-
1. 语义检索，锁定目标文档。 Agent 发起语义检索，召回候选片段。但它不会直接把片段喂给大模型，而是先分析这些片段来自哪些文档、哪些章节。
-
2. 加载文档目录，建立结构地图。 对命中的每份文档，Agent 自动加载其目录结构（TOC）。这份目录在文档解析阶段预构建，包含完整的章节层级。有了结构地图，Agent 就能判断"这段话处于文档的什么位置""它的上下文章节是什么"。
-
3. 按章节精读。 当 Agent 发现某个片段信息不完整时，按照目录结构读取该章节的完整内容。如果答案涉及多个章节，同一轮内可并发读取，减少延迟。
-
4. 信息充分性判断。 每轮工具调用后，Agent 评估当前信息是否足以回答问题。不够则自主发起新一轮检索或阅读，最多循环 5 轮（可配置）。
-
5. 结构化作答。 信息充分后，基于所有收集到的段落生成最终答案，附上
[ID:N]格式的引用标注，每句话可追溯来源。
回到开头的场景——质量工程师询问"涂层体系的环境适应性要求"，DeepRead 会先检索到"性能要求"章节的片段，然后加载文档目录，发现该章节下还有"气候适应性""化学介质适应性""机械应力适应性"三个子节，逐一精读后给出一个覆盖全面、层次清晰的回答。
查询澄清：在"模糊地带"主动沟通
DeepRead 的另一个配套能力是查询澄清（Query Clarification）。
企业用户的提问经常是模糊的——"关于冻结的规定"可能指资产冻结、账户冻结或冷冻储存规定。传统 RAG 系统会硬着头皮检索，大概率返回一个不完全对题的答案。
v2.3.4 在检索之前增加了一层智能门控：
-
• 高置信度查询（检索结果相似度高且集中）→ 直接进入 DeepRead，不打断用户。
-
• 低置信度查询（几乎没有匹配结果）→ 同样直接处理，由下游环节告知用户。
-
• 模糊地带（多个不同方向的匹配）→ 主动澄清意图，提供 2-3 个可能的解读方向供选择。
关键在于不滥用澄清。门控机制基于检索相似度的客观指标，而非完全依赖大模型的主观判断——问题足够明确时，系统不会画蛇添足地反问。
分块算法的又一次进化
RAG 系统的检索质量，根基在分块。这个版本对 smart 和 parent_child 两种分块算法做了重大优化。
七层原子性绑定
分块质量的核心难题不在于"怎么切"，而在于"哪些东西不能切开"。
一张表格被从标题处劈成两半，一段代码和它的说明文字被分到不同的 chunk，一个公式失去了前面的推导上下文——这些都是典型的原子性破坏，直接导致检索到的片段"看不懂"。
v2.3.4 在 smart 分块中实现了一套七层原子性绑定机制，在 AST 语义分割之前，先把不可拆分的内容单元锁定为整体：
|
绑定类型
|
规则说明
|
| --- | --- |
| 图表 + 标题 |
检测 <img> 标签与相邻图注段落，绑定为不可分割单元
|
| 列表 + 引导段落 |
识别"包括但不限于：""具体要求如下"等句式，将引导段落与后续列表绑定
|
| 表格 + 描述 |
匹配"如下表""见表 3"等引用句式，将描述段落与表格绑定
|
| 代码块 + 说明 |
匹配"示例如下：""代码实现："等句式，将代码块与说明绑定
|
| 数学公式 + 上下文 |
将公式块与前文推导、后文解释段落绑定
|
| 连续列表 |
多个相邻列表合并为整体，避免同组枚举项分散到不同 chunk
|
| 定义块 |
连续的"术语: 定义"格式段落合并为完整术语表
|
七层绑定按固定顺序依次执行，绑定后的原子单元作为整体参与切割——宁可让 chunk 略大，也不拆散有语义关联的内容。
父子分块：动态层级切割
Parent-child 分块的思路是"小块检索、大块返回"——子块做向量匹配，父块提供上下文。
此前的常见做法是静态切割：固定按 H2 标题划分父块。问题很明显——H2 章节有 20 页内容时父块膨胀，某些段落没有 H2 包裹时找不到父块。
v2.3.4 让父块的边界跟着子块走。每个子块在 smart 分块阶段携带完整的标题层级信息（如 H1:第三章 > H2:性能要求 > H3:环境适应性）。构建父块时，系统从子块所在的最深层标题开始，沿层级向上查找，第一个完整章节即为该子块的父块。
效果是：深层子块对应小节级父块，浅层子块对应大章节级父块，粒度自适应。父子分块同样继承全部原子性规则，子块内的表格、公式、图表不会被拆散。
PaddleOCR VL v1.5：标题不再是"猜"出来的
PDF 解析是 RAG 的第一道关卡。标题层级识别的准确度，直接决定后续分块和目录构建的质量。
这个版本将 PaddleOCR 的视觉语言模型升级到 v1.5，标题层级识别能力明显提升。此前版本在处理排版不规范的文档时（标题字号与正文接近，或使用非常规编号格式），经常出现标题漏识别或层级混淆。v1.5 通过视觉 + 语义的联合判断，对这类边缘情况的处理更加稳健。
使用 MinerU 作为 PDF 解析器的用户同样受益——DeepRead 的目录结构依赖标题层级，标题识别越准确，Agent 的章节定位能力越强。
工程细节：那些不起眼但重要的改进
检索异步化。 v2.3.4 将检索接口全面改为异步调用。DeepRead 的多轮工具循环中，Agent 可能同时发起多个 read_section 请求，异步架构让这些请求并发执行，直接减少端到端延迟。
图文混排稳定性。 此前版本中，图片引用在 LLM 生成过程中偶尔被错误修改或丢失。v2.3.4 优化了图片引用的保护机制和提示词模板，确保图文混排输出的稳定性。
Milvus 大文档写入。 处理超大文档时 Milvus 的批量插入偶尔触发异常，这个版本修复了相关的边界处理。
企业微信适配。 开启思考模式后企业微信机器人的流式输出会异常中断，v2.3.4 修复了这个兼容性问题。
技术选型的思考
最小 Agent 哲学
回顾这个版本的核心设计，有一个贯穿始终的理念：Agentic RAG 应该尽可能轻，只在必须由 LLM 做决策的环节才引入 Agent。
行业里不乏另一种思路——给 Agent 挂上十几个工具，让它自主决定调用搜索引擎、数据库、计算器、代码解释器……理论上无所不能，实际上经常失控。工具越多，决策空间越大，每一步都可能走偏，最终的回答质量反而不如一个精心设计的确定性管线。
KnowFlow 的 DeepRead 只保留三个工具：retrieve（语义检索）、read_section（按章节精读）、read_page（按页码精读）。Agent 的决策空间被严格限定在一个问题上——当前收集到的信息够不够回答用户的问题？ 够了就生成答案，不够就决定下一步读哪里。其余环节——分词、向量召回、混合排序、引用标注——全部走确定性的代码逻辑，不给 LLM 任何"自由发挥"的空间。
确定性管线 + 最小决策循环，换来的是可预测性。代价是增加 1-2 轮 LLM 调用的延迟——但对企业级应用来说，一个质量合规团队宁可等 10 秒拿到可靠答案，也不愿 2 秒内收到一个需要人工复核的回答。
Milvus 混合检索：踩过的坑和最佳实践
混合检索（BM25 关键词 + 向量语义）是当前 RAG 系统的标配方案，但在 Milvus 上真正跑通并不容易。
分词不一致的代价。 Milvus 内置的 BM25 Function 默认使用 jieba 分词器，而 KnowFlow 的检索管线从一开始就使用自研的 RAG 专用分词器——"规范性引用文件"在 jieba 下被切成"规范/性/引用/文件"，RAG 分词器则保留"规范性"和"引用文件"这样的语义完整片段。两套分词器不一致，直接导致某些查询的 BM25 分数为零。
解决方案是彻底绕开 Milvus 内置分词：BM25 分析器设为 whitespace（仅按空格切分），写入时由 KnowFlow 预先完成分词，检索时同样先用 KnowFlow 分词器处理查询。整条链路分词统一后，BM25 召回质量有了质的提升。
VARCHAR 65535 字节限制。 企业文档中一个 chunk 的原始文本（带格式标记、表格 HTML）很容易超过 Milvus VARCHAR 的 65535 字节上限。我们的处理策略分两层：展示用大字段超过 50KB 时自动 zlib 压缩 + base64 编码，读取时透明解压；极端情况下压缩后仍超限，才执行截断——截断函数用二分查找定位 UTF-8 安全切断点，避免多字节字符中间截断导致乱码。
这两个问题看似工程细节，但直接决定混合检索的实际效果。分词不一致让 BM25 形同虚设，字段溢出导致写入失败或内容丢失——在 Milvus 上做混合检索，这些是必须处理好的基础设施问题。
下一步：KnowFlow 的产品方向
v2.3.4 是一个技术纵深的版本，接下来的迭代会更多地转向产品层面。
做减法，找最优解
RAG 系统的配置项越来越多——分块方法、分块大小、PDF 解析器、向量模型、相似度阈值、Top-K……一个知识库从创建到可用，用户需要做十几个决策，其中大多数并没有一个"明显正确"的选项。
KnowFlow 下一阶段的思路是在繁琐的配置中寻找通用场景最优解，用产品侧的默认策略替代手动调参。让用户上传文档、提问就能得到高质量回答，而不是先花半小时研究参数。
工程化层面，我们计划将 OCR、版面分析、分块三阶段彻底解耦——换分块方法不需要重新跑 OCR，文档版本可追溯、可回滚。此外，内部使用的 RAG 效果评测系统 KnowEval 将在后续版本中开源，帮助用户量化回答"换了这个配置，效果到底好了还是差了"。
面向场景的 Agent 应用
知识库的价值最终要落到具体业务场景中。KnowFlow 接下来会以智能客服和合同审核两个高频场景为切入点，打造开箱即用的 Agent 应用产品。
智能客服要求快速响应、多轮追问、口语化表达；合同审核则需要逐条比对条款、识别风险点、交叉引用多份文件，对文档结构理解深度要求极高，恰好是 DeepRead 的用武之地。一快一慢、一浅一深，覆盖企业知识库应用的两个典型模式。
Agentic RAG 持续演进
DeepRead v1 验证了"最小 Agent + 确定性管线"的可行性。下一步方向：更精准的信息充分性判断、跨文档关联推理、基于用户反馈的检索策略自适应。核心原则不变——Agent 保持最轻，只在必须决策的环节介入。
KnowFlow v2.3.4 现已发布。 如需了解 KnowFlow 更多细节，欢迎关注公众号KnowFlow 企业知识库或者访问官网[1]联系我们获取定制化方案与 POC 支持。
引用链接
[1] 官网: www.knowflowchat.cn
