ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;display: table;padding: 0.5em 1em;color: rgb(63, 63, 63);text-shadow: rgba(0, 0, 0, 0.1) 2px 2px 4px;">背景ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-indent: 2em;letter-spacing: 0.1em;color: rgb(63, 63, 63);">KonwFlow v0.0.4 实现了 RAGFlow 采用 MinerU 模型进行文档解析，并支持了多种文件格式。在社区同学的协助下，进一步完善了 MinerU GPU 支持，使得产品达到可用状态。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-indent: 2em;letter-spacing: 0.1em;color: rgb(63, 63, 63);">基于从可用到好用的产品迭代思路，KnowFlow v0.0.5 正式发布，进一步ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: inherit;color: rgb(0, 152, 116);">增强 MinerU 解析产物 Markdown 文件的分块策略，增强分块检索效果，从而增强最终召回准确率。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;color: rgb(63, 63, 63);"> ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;margin: 0.1em auto 0.5em;border-radius: 8px;box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 8px;" title="null"/>ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-indent: 2em;letter-spacing: 0.1em;color: rgb(63, 63, 63);">同时基于社区反馈，对于ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: inherit;color: rgb(0, 152, 116);">RAGFlow 接入微信、企业微信应用等三方接入的能力支持，我们做了进一步增强，以上方案在实际客户落地过程中得到充分验证。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;display: table;padding: 0.5em 1em;color: rgb(63, 63, 63);text-shadow: rgba(0, 0, 0, 0.1) 2px 2px 4px;">为什么要优化 Markdown 分块?ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-indent: 2em;letter-spacing: 0.1em;color: rgb(63, 63, 63);">市场上绝大多数 OCR 开源项目最终会把 PDF、DOC 等格式文件转化为 Markdown，随着 OCR 技术的不断完善，MarkDown 的生成质量会不断提升。但 RAGFlow 对于 MarkDown 的分块策略，通过提取表格、图片、文本内容，把相关信息存储到键值对。但整体分块策略非常粗暴，比如 naive 分块策略存在的问题如下： - 2. 没有考虑 Markdown 语法结构，可能在代码块中间分割
最核心的问题在于没有基于语义分块，而是直接提取 Markdown 重要元素，通过固定的 token 数粗暴拆解，有可能会破坏表格、列表、标题上下文结构。
而这些问题将会直接导致后续的检索效果不符合预期。  理想化的分块效果什么？对于 Markdown 文件来说，我们期望的效果是：每一个分块都应该是语义完整、上下文连贯、结构明确且内容相关的最小单元。 - • 分块太细，向量数量增加，检索成本和索引开销上升
- • 分块太粗，效果下降，由于内容分布稀疏，召回率降低
对于 token 数量，业内一般实践经验如下：  对于 Markdown 我们推荐在 300 左右，根据文档的结构适当调整。 我们是怎么实现分块增强的？考虑到不同场景需要用到不同的分块策略，我们提供了三种策略模式，适用于不同的场景，可以通过配置项进行选择。  策略 1 ： Basic 分块方法（基础原生方案）这是 RAGFlow 原生方案，原理如下：
优点在于性能最快、简单可靠，缺点语义理解较差，分块质量一般。 策略 2 ：Smart AST 分块策略Smart AST 分块策略技术实现如下： - 1.通过 markdown-it-py 解析 Markdown 为 AST（抽象语法树）；
- 2. 基于语义边界进行智能分块，如标题、段落、表格、代码块；
- 3. 维护上下文关系， 保持标题间的层级关系，如 H1、H2、H3;
- 4. 对于特殊内容，如表格、代码块，我们特殊考虑，可以突破 token 数量限制，保证且内容完整性
基于 AST 理解文档结构，在合理的语义边界分块
✅ 质量稳定 - Token 分布更均匀（106-1672，平均422）
✅ 内容保护 - 自动保持表格、代码块、列表的完整性
✅ 上下文感知 - 维护标题层级关系，分块时考虑文档结构
✅ 性能平衡 - 在样本数据测试仅比基础方案慢 0.005s，性价比高 策略 3 ：基于标题层级的 Markdown 分块该策略主要设计思路是以标题驱动为主，所以相对来说分块较大，同时支持上下文增强以及重叠串设置： - 1. 标题驱动分块 - 以 H1、H2、H3 作为主要分块边界
- 2. 动态大小控制 - 目标 300-600 tokens，最大 800 tokens，最小 50 tokens
- 3. 智能分割策略 - 处理超大分块时在段落边界进一步分割
- 4. 智能合并策略 - 处理超小分块时与相邻分块合并
- 5. 特殊内容保护 - 维护表格、代码块、公式的完整性
相比原生和 Smart 方案的优势：
✅ 最佳分块质量 - 平均 504 tokens，分布最合理
✅ 智能优化 - 自动处理过大/过小分块问题
✅ 上下文增强 - 小分块自动添加相关标题背景
✅ 容错性强 - 出错时自动降级到 Smart 方案
✅ 灵活配置 - 支持重叠分块、最小 Token 数等高级参数 缺点在于分块偏大，不太稳定，适合于标题层级较多，层与层之前文本不多，细而碎的这种文本结构。 三方接入支持自动创建会话之前的微信三方接入系统中，要求在配置文件中配置会话 ID ，在并发场景下，多个人采用相同会话 ID 会串行等待。 本次优化针对不同的会话 ID 创建不同的 RAGFlow 会话，这种设计支持不同的会话存在不同的上下文，且同时简化了配置复杂度，更好满足企业生产环境三方应用接入。 总结本次在测试过程中，发现同一份文档不同的分块策略，在特定的问题检索上差异巨大，其中策略 2 表现效果远远超出预期。 但文档的结构解析仍然存在巨大的提升空间，我们把 PDF 送到 MinerU 在线体现环境里测试，对于表格结构的识别效果仍然差强人意，要真正的落地到生产环境，MinerU 目前的解析能力远远不够，后续我们将会接入在线付费 API 进行测试，期望能实现解析这个过程的突破 |
