复杂表格解析总是错位？教你用 RAGFLOW 创建知识库搞定深度文档提取

做知识库问答的时候，最让人头疼的就是 PDF 里的表格。

很多朋友跑来问我：为什么同一份设备说明书或者财报，大模型回答正文内容很准，一问到表格里的具体参数就胡说八道？

上个月我帮一家制造企业做技术文档库，他们的设备参数表非常密，里面大量存在跨行合并的单元格。当时用 LangChain 默认的 PDF 解析器切片，结果一查“某型号阀门在 200 度工况下的承压值”，大模型给出了隔壁型号的数据。

去翻解析出来的原始文本才发现，原本表格里的第 3 行第 2 列，直接被拼到了第 4 行第 1 列后面。整张表的行列关系全乱了。

出现这种问题的根本原因，在于很多人误解了 PDF 文件的本质。

PDF 根本不是类似 Word 或者 HTML 那种结构化文档。在 PDF 的底层代码里，根本没有所谓的 `table`、`tr`、`td` 概念，它只记录每一个字符在页面上的 绝对坐标 (X, Y)，以及画在页面上的线条路径。

传统解析器提取文本时，通常遵循从上到下、从左到右的几何顺序抓取字符。遇到简单的单栏正文没问题，但只要遇到以下几种情况，逻辑就会当场崩塌：

1.跨行合并单元格（Rowspan）：左侧一列对应右侧三列，文本提取器会按行扫描，把左侧单元格的内容硬生生拆散插进右侧各行之间。

2.多行文本单元格：单元格内部换行时，提取器会把这一行的下一句话当作下一行的数据。

3.无边框表格（无线表）：没有黑色线框，靠空白间距对齐。基于规则的提取器会误以为这是普通文本排版，把多列数字直接拼成一长串无意义的段落。

如果喂给大模型的数据源本身就是错位的字符垃圾，后面不论怎么调优 Prompt 或增加检索召回条数，输出的结果也必然是错的。这就是典型的“垃圾进，垃圾出”。

要解决这个问题，就不能把 PDF 当作纯字符流来读，必须引入 视觉版面分析。这也是 RAGFlow 和它的底层引擎 DeepDoc 的核心思路。

RAGFlow 处理文档的过程类似人类看书：它先把 PDF 渲染成图像，通过视觉模型去识别版面，找出哪里是标题、哪里是正文、哪里是表格边界；接着用表格结构识别（Table Structure Recognition, TSR）去推算网格与合并关系；最后把 OCR 识别出的文字准确塞回对应的单元格里，还原成完整的 HTML 或 Markdown 表格。

为了搞清楚各类方案的实际差距，我拿一份包含 50 页复杂财报和设备手册的测试集，对比了目前主流的四种解析方案：

从对比中可以看到，如果你的数据涉密不能出内网，同时文档里又有大量带线表格、合并单元格，RAGFlow 确实是目前在准确度和私有化之间平衡得比较好的一种选择。

接下来，我把在 RAGFlow 中搭建高精度表格知识库的具体步骤完整走一遍。

第一步：部署与基础配置。

RAGFlow 官方提供了 Docker Compose 镜像，部署并不繁琐。但是这里有一个关键的硬件避坑点：如果服务器没有独立显卡，不要盲目给 Docker 分配过低的内存。

•运行 DeepDoc 视觉模型和 PaddleOCR 至少需要 16GB 运行内存，CPU 建议配置在 4核以上。

•如果内存低于 8GB，解析大文件时 Docker 容器经常会直接被系统 OOM Kill（内存溢出杀进程）。

•登录后台后，先在模型管理面板配置好本地的 Embedding 模型，中文场景推荐选择 bge-large-zh-v1.5 或者 bge-m3。

第二步：创建知识库与选择解析模板。

进入“Dataset”页面，点击新建知识库。这一步至关重要，决定了解析效果的上限：

1.找到“Chunk Method”（分块方法）设置项。系统默认选中的通常是 General（通用切片），处理复杂表格时切忌使用 General 模板。

2.下拉菜单中选择 DeepDoc 解析器。如果文档是纯粹的设备规范，也可以选择 Manual 模板。

3.检查底部的 OCR 选项，务必将 OCR 开关置为开启状态，并将识别语言设置为 Chinese & English。哪怕你的 PDF 表面上能复制文字，有些表格单元格内部可能被转成了矢量图形或光栅图，开启 OCR 才能保证字符完全被抓取。

第三步：设置表格输出格式与分块参数。

在 DeepDoc 的详细设置里，有几个核心参数直接影响表格质量：

1.表格输出格式选择 HTML 优先于 Markdown。Markdown 原生语法不支持跨行合并（rowspan）和跨列合并（colspan），如果强行转成 Markdown，多行合并的数据依然会变成空白或重复数据。而 HTML 的 `

2.Chunk Token 尺寸不要设得过小。通用文本通常切 300 到 500 个 Token，但一张 10 行 6 列的复杂参数表，包含 HTML 标签后很容易达到 800 到 1200 个 Token。如果把 Max Token 设为 400，系统会直接从表格中间拦腰切断，导致后半截表格丢失表头。建议将表格类知识库的 Chunk Token 上限设为 1200 至 1500。

第四步：上传文档与可视化复核。

文件上传并解析完成后，不要急着去做问答测试，先点击文档进入切片详情页。

•RAGFlow 最大的优势之一是自带可视化定位视图。界面左侧显示 PDF 原页面，右侧显示切出来的 Chunk 数据。

•点击右侧的某一个表格 Chunk，左侧页面会用彩色方框高亮标出它在原 PDF 上的对应区域。

•仔细观察表头行是否对应正确。如果发现某一行出现了错位，直接在右侧的 Markdown/HTML 预览编辑器中手动修正这几个单元格，保存后系统会自动重新建立该 Chunk 的向量索引。

在实际项目中跑了上万页文档后，我总结了三个必须注意的实战避坑经验：

第一，遇到无边框表格，先做视觉预处理。

DeepDoc 对有实线边框的表格识别率很高，但对于完全没有外框线、只靠空格缩进的无线表，模型有时会把它判定为正文列表。处理这类文档时，可以先用脚本在 PDF 预处理阶段把空白处加上浅灰色参考虚线，或者在上传前转成标准 Word 重新排版再导出，识别率能大幅提高。

第二，跨页长表格必须手动补充表头。

很多长表格会跨越两三页。PDF 解析引擎通常把第二页的表头当作普通数据行，导致第二页的数据丢失了属性标签。大模型在检索第二页内容时，根本不知道那一列数字代表什么含义。操作对策是：在 RAGFlow 的切片管理中，找到第二页的表格块，在表格顶部手动复制粘贴第一页的表头字段，这样可以确保检索语义的连贯。

第三，混合检索比纯向量检索更适合表格。

表格内容通常包含大量生僻的零件型号、数字代号、日期。单一的 Embedding 向量检索对这种冷门数字串非常不敏感。在 RAGFlow 的检索设置里，一定要把检索模式改成 Hybrid（混合检索），结合 BM25 关键词匹配与向量召回，并把 BM25 的权重调高到 0.4 到 0.5。这样既能根据用户问题的语义找到相关说明，又能根据精准的零件编号直接命中对应的表格单元格。

做文档提取没有一步到位的魔法。了解工具的识别边界，选对解析器，根据表格类型设置合理的切片长度，才能让知识库真正读懂那些密密麻麻的数据。

参考来源：

[1] [RAGFlow DeepDoc 技术解析](https://rag.deeptoai.com/docs/rag-project-analysis/04-key-projects-analysis/ragflow)

[2] [RAGFlow GitHub DeepDoc 架构与表格识别实现](https://github.com/infiniflow/ragflow)

[3] [PaddleOCR-VL 与多模态版面分析在 RAG 中的实践](https://aistudio.baidu.com/blog/detail/773385938758213)

[4] [复杂文档解析对比与评测指南](https://rag.deeptoai.com/docs/rag-project-analysis/03-data-processing-indexing/01-%E6%96%87%E6%A1%A3%E8%A7%A3%E6%9E%90%E6%8A%80%E6%9C%AF)