系列导航

• 第 0 章 前言：为什么企业 AI 工程师必须掌握 RAGFlow
• 第 1 章：安装部署与基础配置**——从零跑通第一个 RAG Pipeline
• 第 2 章：RAGFlow RAGFlow 代码介绍
• 第 3 章：攻克企业复杂文档——理解 DeepDoc、Naive、MinerU 与 Docling 的区别
  • 第一节 RAGFlow 配置参数全景图与实验结论
  • 第二节 实验Chunk Method (解析方法与布局识别)（本文）
  • 第三节 实验Chunk Token Num & Overlap (切片与重叠)
  • 第四节 实验Similarity Threshold (相似度阈值)
  • 第五节 实验Vector/Keyword Weight (混合搜索权重)
  • 第六节 MinuerBridge安装配置与运行使用
• 第 4 章：理解 Agentic RAG 核心——定义与低代码实现
• 第 5 章：工作流编排——构建基于图（Graph）的 RAG
• 第 6 章：Deep Research 模板应用——部署自动拆解子问题的深度研究智能体
• 第 7 章：企业级扩展——API 接入与外部工具集成（MCP）
• 第 8 章：评估与复盘——从"玄学"到量化 RAG 性能指标评测

1. 官方定义与通俗理解

官方定义：决定系统如何将上传的文件识别并切分为有意义的语义块（Chunks）。
通俗理解：这是给 RAGFlow 戴上不同精度的“眼镜”。

• 如果你选 Naive，它把文档看作一串长字符，机械地按长度切，不管哪里是标题，哪里是表格。
• 如果你选 Paper，它能识别出这是“摘要”、那是“图表注释”，并把它们分别打包，保持语义的完整。
• 如果你选 General，它能在机械切分与语义识别之间找到平衡——既能识别出常见的段落、标题和列表结构，又不会像 Paper 那样对学术元素做深度解析，适合大多数日常办公文档。

2. 核心架构流转图 (Code Flow)

下面的 Mermaid 图标展示了代码中是如何通过 parser_id 从用户界面传递到后端执行引擎的：

3. 关键代码位置证明

在 rag/svr/task_executor.py 中，你可以看到这个核心的分发逻辑：

• (Line 84-101): FACTORY 字典建立了 UI ID 到 Python 模块的映射。
• (Line 251): chunker = FACTORY[task["parser_id"].lower()] 实现了动态加载。
• (Line 272): await thread_pool_exec(chunker.chunk, ...) 执行了具体的算法。

4. 实验测试方案：如何实际感受差异？

首先我们的目标是处理好企业文档：特点是大量PDF格式文档, 绝大部分文档是有清晰章节和段落结构的, 并且文档中包含大量的表格（文字表格、数据表格、 多页表格、以及合并单元格后的表格 ）。
为了让你切身体会解析策略的重要性，我们设计以下实验：

A. 实验数据源准备

• 文件名: 某企业年报.pdf
• 内容要求:
  1. 表格类型: 包含文字表格、数据表格、 以及合并单元格后的表格。
  2. 跨页: 各种表格都有跨页的情况, 甚至是多页表格。
  3. 文字: 有章节+段落组织的文本内容。

B. 参数对比设置

我们针对同一份文件，创建三个不同的知识库（或在同一知识库中多次上传并修改设置）：

1. 对照组 0: Chunk Method = Naive
2. 对照组 A: Chunk Method = Paper
3. 实验组 B: Chunk Method = General； layout_recognize = deepdoc
4. 实验组 C: Chunk Method = General; layout_recognize = MinerU

注: 实验组C是后来添加的, 由于实验组B并不能达到处理复杂表格的最低期望, 所以在实验过程中引入了MinerU。对于MinerU的安装和使用我们会在后继的章节中详细说明。

C. 观测指标

切片预览 (Chunk Preview):

• 观察表格是否被切割成碎片？（Naive 往往会把表格行和列拆碎）。
• 观察段落是否在行间被腰斩？

5. 实验记录

根据 4. 实验测试方案 中的参数对比设置，我们对同一份 某企业年报.pdf 进行了切片预览观测，结果如下：

• Paper 解析后跨页表格被截断为多段
  

• Deepdoc / Docling 将两列合并成一列， 两行合并成一行的错误表现
  
  

• Deepdoc / Docling 复杂表格识别失败
  

补充观察：

• ✅ 文字解析准确性：以上所有解析方式对于 PDF 中的普通文字内容（段落、标题、列表等）解析效果都比较准确，未发现明显文字错漏或乱码等差异。
• ✅ ChunkSize 参数影响：经过对比实验，ChunkSize（切片最大长度）对于表格或文字段落的语义完整性没有影响。因为：
  • 一个表格（即使跨多页）在识别后被视为 一个原子级的语义单元，不会被 ChunkSize 强行截断；
    
  • 一个完整的文字段落（即便长度超过 ChunkSize）同样不会被截断，系统会保留其整体性。
    
  • 换言之，ChunkSize 仅在拆分连续的非结构化文本（如无段落边界的长文本）时发挥作用，对已有明确语义边界的内容不生效。 所以复杂表格成功解析入库的主要依赖是"布局分析"工具，在本次实验中，General+MinerU是表格识别效果最好的组合。

6. 总结与建议

• 默认处理方式： 标准文档 (pdf/docx) -> General +MinerU(表格识别能力最好)。
• 简单文本 (txt/md) -> Naive (速度最快)。
• 表格数据严重 -> Table (专门针对 Excel/CSV 优化)。
• 学术/技术文档 -> Paper (结构化能力最强)。

[!TIP]
实验结论：RAG 垃圾进，垃圾出 (GIGO)。如果 Parser 没选对，后面无论怎么调 Similarity Threshold 都是徒劳。