企业搭 RAG 知识库，最常见的翻车点不是检索、不是模型，是文档处理：辛苦把几百份 PDF 传上去，一问三不知——追查下去，表格在入库时就被读错了：串行、断裂、合并单元格丢失。RAG 的效果上限在数据质量，垃圾进、垃圾出。向量空间 JBoltAI开发框架（V4.5 起）为此自研了 PDF 表格提取引擎，把表格 1:1 还原作为知识入库的前置关卡。
先看翻车现场
企业文档的真实构成：PDF 占大头，而 PDF 里的核心信息又大量在表格里——价格表、参数表、 BOM 清单、报关单、检验标准。传统解析按"文本流"处理 PDF，表格就遭了殃：
| 表格灾难 | 长什么样 |
|---|---|
| 串行 | 一行数据被拆得七零八落，"物料 A 单价 3.2"变成三个不相干的片段 |
| 跨页断裂 | 一张表跨两页，下半截的行和表头对不上，数据错位入库 |
| 合并单元格丢失 | 分类行的层级关系没了，子项不知道归谁 |
| 数字精度丢失 | 3.20 变 3.2、千分位逗号被当分隔符——问数时数字对不上账 |
这些错误一旦入库，后面的检索和生成再优秀也救不回来——AI 一本正经地引用一个错掉的数，比答不知道危害大得多。
为什么传统解析救不了
PDF 本质上是"打印格式"：它记录的是"这个字在页面的什么位置"，而不是"这是一个表格"。传统按行提取文本，等于把表格当成一堆恰好排得整齐的字——格式信息（行、列、单元格的从属）全部丢失。
要还原表格，解析器必须做"结构理解"：
- 网格识别：从文字的位置关系里识别出表格的行列网格；
- 合并检测：判断哪些单元格是合并出来的，恢复层级；
- 跨页拼接：识别"这页的表是上页那张的延续"，把行接回正确的表头下。
这是视觉和版式层面的工程，不是"换个更强的模型"能解决的——它得被当作一个专门的问题去做。
JBoltAI 的做法
JBoltAI 框架在 V4.5 版本把这块作为重点攻坚：自研的表格提取引擎（TableMergeAnalyzer），核心就是网格化合并检测加跨页合并——目标是 PDF 里的表格1:1 还原入库，配套整段的知识提取精度提升。工程逻辑很朴素：与其在检索端做各种花活弥补数据错误，不如在入库端把数据搞对。
对自建 RAG 的团队，这也是一个检查清单：拿你们最复杂的三份 PDF（带跨页表格、带合并单元格的那种），看入库后表格数据是否完整正确——这一关过不了，别急着调检索参数。
常见问题（FAQ）
企业 RAG 知识库答不准，最常见的根源是什么？ 多数时候不是检索和模型的问题，是文档入库时就读错了：PDF 表格串行、跨页断裂、合并单元格丢失、数字精度损失——错误数据入了库，检索和生成再好也救不回来，AI 还会一本正经引用错误数据。检查方法：拿最复杂的三份 PDF 验证入库后表格数据是否完整正确。
PDF 表格为什么特别难被 AI 正确读取？ 因为 PDF 是打印格式，记录的是文字的位置而不是表格结构：表格的行列、单元格从属关系需要解析器做结构理解（网格识别、合并检测、跨页拼接）才能还原。按行提取文本的传统方式会把这些格式信息全部丢掉——这是专门要攻的工程问题，换更强的模型解决不了。
JBoltAI 框架怎么解决 PDF 表格解析问题？ V4.5 起自研表格提取引擎（TableMergeAnalyzer）：网格化合并检测恢复单元格层级、跨页合并把断表拼回正确表头，实现 PDF 表格 1:1 还原入库，知识提取精度整体提升——工程思路是在入库端把数据搞对，而不是在检索端弥补数据错误。
一句话总结：RAG 的效果上限在数据质量——表格读错了，后面全白搭；入库端 1:1 还原，是一切问答可信的前提。
- 了解产品：向量空间 JBoltAI开发框架
