大家好我是herosunly。985院校硕士毕业现担任算法工程师一职获得CSDN博客之星第一名热衷于大模型算法的研究与应用。曾担任百度千帆AI应用挑战赛、英特尔AI创新应用大赛等比赛评委科大讯飞AI大学堂荣誉讲师编写微软OpenAI考试认证指导手册。曾获得多项AI顶级比赛的Top名次其中包括阿里云天池比赛第一名科大讯飞分类挑战赛第一名。在技术创新领域拥有多项授权发明。本文选取两张脱敏复刻的临床嵌套表单给药费用表、人员资质授权表共 7 个预期嵌套子表对 TextIn xParse、MinerU VLM、PaddleOCR-VL、GLM-OCR 四款文档解析模型进行横向评测。评测不止于识别准确率还将各模型输出接入本地 SQLite ETL 自动质控流程验证解析结果能否直接写入下游关系表。结果显示字识别准确并不等于结构可用只有完整保留“父区块 子表 子表行“层级的输出才能被下游直接使用。全文可为临床表单、报销明细、资质档案等复杂表格场景的解析选型提供参考。文章目录一、前言一个被 OCR 准确率掩盖的问题二、实战准备样本构造与四模型调用配置2.1 测试样本两张脱敏复刻的临床嵌套表单2.2 四款模型调用方式与参数配置三、实战验证从结构保留到下游入库3.1 结构对比文本召回之外的父子层级保留3.2 下游验证本地 SQLite ETL与自动质控四、结论一、前言一个被 OCR 准确率掩盖的问题做过文档类数据入库的人大概都遇到过这么一个别扭的情况一份表单OCR 跑完去看表头、金额、日期、姓名字面上一个不差识别得很完整。可真把它接进下游进 ETL、跑质控、喂给检索数据就是用不了。我最近在处理一批临床业务表单时又遇到了同样的问题。排查到最后症结落在一类很不起眼的结构上表中表。临床试验的给药费用表、研究人员资质授权表都有这个特点大表里套着小表父子层级本身是有意义的。“这笔标本运输费属于哪个费用区块”“这条 GCP 培训记录挂在哪个人员档案下”层级一旦丢失OCR 字认得再准下游也无法确定这行数据该放在哪里。换句话说文字识别准确不等于结构被保留更不等于能直接入库。那么到底哪些解析工具能把这层结构完整保留下来本文选取两张脱敏复刻的临床表单对 TextIn xParse、MinerU VLM、PaddleOCR-VL、GLM-OCR 四款模型进行横向评测。评测不仅比较识别准确度还搭建了一套本地 SQLite ETL 自动质控流程直接验证各模型的输出能否被下游写入数据库以下是完整过程与结果。二、实战准备样本构造与四模型调用配置2.1 测试样本两张脱敏复刻的临床嵌套表单本文样本为内部脱敏复刻的临床业务表单不是真实患者原始数据也不是医院生产系统中的数据。但结构特征完整保留——表中表、合并单元格、父子字段、金额位数表均在其中用于观察不同模型对嵌套结构的保留能力。下游验证仅为本地 SQLite ETL 自动质控流程不代表任何生产数据库或医院系统的真实接入。第一张为给药与访视费用类业务表单包含 3 个预期嵌套子表父字段/父区块预期子表下游含义试验药物给药分组及样本量安排给药方案、周期、计划例数等给药明细访视补助与标本物流费用补助金额小写访视补助金额位数表访视补助与标本物流费用标本运输费用标本物流费用明细第二张为研究人员资质与项目授权类表单包含 4 个预期嵌套子表父字段/父区块预期子表下游含义研究人员基本情况教育经历人员档案明细研究人员基本情况GCP培训与资质情况资质核验记录项目授权与职责项目经历与授权职责项目授权台账项目授权与职责方案培训记录授权前培训质控记录两张表合计包含 7 个预期嵌套子表。后续各项对比均围绕这 7 个子表的结构保留情况展开。2.2 四款模型调用方式与参数配置四款模型使用同一批样本进行测试均调用官方API。为保证对比公平测试前清空历史结果、重新完整运行一遍所有输出统一保存后作为对比依据。下面列出各模型的调用方式与关键参数便于复现仅展示参数、运行方式与成功状态不涉及任何密钥或账号信息。总览如下模型运行方式本轮参数配置摘要状态TextIn xParseAPI 调用VLM 解析模式include_hierarchyTrue、include_table_structureTrue、title_treeTrue、table_viewhtml、parse_modevlm成功MinerU VLMAPI/VLM 方式解析model_versionvlm、enable_tableTrue成功PaddleOCR-VL异步 OCR 任务接口MODELPaddleOCR-VL-1.6、useDocOrientationClassifyFalse、useDocUnwarpingFalse、useChartRecognitionFalse成功GLM-OCROCR API文本与坐标基线tool_typehand_write、language_typeCHN_ENG、probabilityTrue成功以下分别说明四款模型本轮的运行情况。2.2.1 TextIn xParsexParse 通过 API 调用采用 VLM 解析模式并开启了表格结构相关能力。核心配置即上表中的几个参数include_hierarchy、include_table_structure、title_tree、table_viewhtml、parse_modevlm它们直接决定 xParse 是否输出父子层级是本轮的观察重点。调用成功返回后生成两份样本对应的 Markdown 结构化结果文件后续所有结构对比与 ETL 写入均基于这两份结果。2.2.2 MinerU VLMMinerU 采用批量解析任务调用时指定model_versionvlm并开启表格识别enable_tableTrue。任务申请、文件上传、轮询均已完成结果解压后生成 Markdown 文件用于后续结构对比。2.2.3 PaddleOCR-VLPaddleOCR-VL 通过异步 OCR 任务接口调用模型指定为PaddleOCR-VL-1.6。本轮关闭了方向分类、文档矫正、图表识别等非核心项useDocOrientationClassifyFalse、useDocUnwarpingFalse、useChartRecognitionFalse专注版式与表格解析。任务完成后返回结果地址下载后导出页面级 Markdown。2.2.4 GLM-OCRGLM-OCR 本轮定位为 OCR 文本/坐标基线采用hand_write工具类型、中英文识别language_typeCHN_ENG、返回置信度probabilityTrue。调用成功后获得行级文字、坐标与置信度用于对照——即在仅有文本和坐标、没有表格层级时观察下游的处理情况。三、实战验证从结构保留到下游入库3.1 结构对比文本召回之外的父子层级保留评价指标包括关键文本项召回、HTML 表格数量、真正嵌套的table数量、最大表格深度。其中“关键文本项召回”仅反映标题、父区块名、子表名等文字是否被识别出来并不代表结构是否被保留——这一点很重要后文可以看到两者能够明显分离。第一张样本TextIn xParse 返回 7 个表格其中 3 个为嵌套表格正好对应 3 个预期子表MinerU VLM 和 PaddleOCR-VL 均返回 4 个表格但嵌套表格数为 0GLM-OCR 仅有文本和坐标层面的结果不返回表格层级。第二张样本TextIn xParse 返回 5 个表格其中 4 个为嵌套表格对应 4 个预期子表MinerU VLM 和 PaddleOCR-VL 均只返回 1 个表格嵌套数仍为 0GLM-OCR 依旧作为文本/坐标基线。各模型在两张样本上的结构指标汇总如下这里有一处细节需要单独说明。第二张样本中xParse 的精确关键词命中为 5/7原因是两个父区块术语未被逐字命中。但这只是文本层的字面匹配口径与结构可用是两回事——xParse 在这张表中仍完整保留了 4 个嵌套表格后续本地 ETL 也实现了 4/4 写入详见下游验证部分。这恰好说明字面召回与结构可用是两个不同的维度下游真正依赖的是后者。值得注意的是PaddleOCR-VL 在样本二的关键词命中为满分 7/7高于 xParse但其嵌套表格数为 0文字全部识别正确结构却没有保留下来。3.1.1 界面直观对比先从产品界面直观感受各工具的差异。同一张嵌套表格,解析后在各家产品界面中的呈现如下:TextIn xParse 界面截图MinerU VLM 界面截图PaddleOCR-VL 界面截图单看渲染效果,几款工具的表格都相当规整,行列边界、合并单元格都适合人工阅读。但看起来整齐和结构可用是两回事——界面上的差异只是表象,真正决定下游能否入库的,是底层 HTML 里是否携带父区块 子表这层关系。下面从源码层面逐一验证。3.1.2 源码实证TextIn xParsexParse 输出中可以看到父单元格内部保留子表tableMinerU VLMMinerU VLM 的输出包含表格和文本内容但本轮结果中子表更多被展开为同层结构下游需要额外推断父子归属PaddleOCR-VLPaddleOCR-VL 也能输出普通 HTML 表格并保留部分行列合并但在本轮样本中子表被表达为同一张表内的 rowspan/colspan 结构而不是父单元格内再嵌套一个子table。GLM-OCRGLM-OCR 返回逐行文字和坐标更适合作为 OCR 文本召回基线同时还有一处容易混淆的地方视觉规整不等于结构可用。单看渲染效果MinerU VLM 和 PaddleOCR-VL 的表格其实相当规整行列边界、合并单元格都适合人工阅读。但本文统计的嵌套表格数衡量的不是表格是否美观而是 HTML/Markdown 中是否保留了父区块 子表 子表行这层关系。一个模型完全可以输出一张外观漂亮的普通大表同时把子表全部摊平其中此时下游若要写入子表结构仍需自行推断该子表归属于哪个父区块。因此对比的核心并非“谁识别的文字更多”真正拉开差距的是输出中是否携带“该子表属于哪个父区块”的结构信息。3.2 下游验证本地 SQLite ETL与自动质控仅凭肉眼观察输出不足以说明问题因此本轮还搭建了一套本地 SQLite ETL 自动质控流程。该流程读取四款模型的解析结果将可直接识别的嵌套子表写入两张目标表nested_tables和nested_table_rows并执行父子归属与行数完整性质控。这里是本地验证流程不是生产数据库也未接入任何医院系统。目的只有一个检验解析结果是否已足够结构化能否直接进入下游的关系表。流程运行完成后数据库写入统计如下表记录数model_runs8forms8nested_tables7nested_table_rows13qc_results35其中nested_tables7全部来自 xParse——两张样本分别写入 3 个和 4 个预期子表。其余三款模型因未直接保留可入库的父子结构均未写入nested_tables而是进入质控结果中的修复/重建标记。qc_results35为 8 次模型运行产生的质控记录覆盖父子归属、行数完整性等检查状态分布为通过 14 条、需修复 14 条、需重建 6 条、失败 1 条。其中失败的 1 条来自 GLM-OCR 在第一张样本中对给药分组及样本量安排的父子归属检查——GLM-OCR 作为纯 OCR 文本/坐标基线未提供可直接使用的嵌套子表因此判为失败。这并非 xParse 的写入失败。四款模型在 ETL 流程中的写入结果如下MinerU VLM 和 PaddleOCR-VL 本轮均有表格内容和关键文本但未直接给出嵌套父子结构因此标记为“需修复父子关系”。这并非否定其文本召回价值而是说明若要进入同样的子表结构仍需额外进行一遍父子关系修复。GLM-OCR 定位为 OCR 基线需从文本和坐标重新构造表格与父子关系因此标记为“需重建表格”。xParse 在两张样本中写入了全部 7 个预期子表。下表给出两种口径的行数以避免两个数字被误读为不一致网格行数含表头是解析出的表格总行数写入数据行不含表头是真正落入子表明细的数据行两者的差值恰好对应每个子表的 1 行表头。两个口径分别求和网格行数含表头422333320写入数据行不含表头311222213与nested_table_rows13一致。两个数字口径不同但可以相互印证每个子表恰好扣除 1 行表头。查询本地数据库的子表记录可以看到两张样本共写入 7 个预期子表给药费用表 3 个、人员授权表 4 个每个子表的实际数据行数均与预期一致状态正常。关键在于**xParse 的输出不只是“外观像一张表”而是能将父区块、子表名与行数校验一起落入关系表。**进一步展开到明细层13 行子表明细也全部入库因此 ETL 可以从父区块、子表名、行数据三个层面取用结果。四、结论在很多文档问答场景中模型只要能答出某个值就容易被认为解析成功。但临床表中表更关注的是—这个值究竟属于哪里。 例如问标本运输费用是多少仅回答120 元并不完整。下游真正需要的是带有路径的结果访视补助与标本物流费用 标本运输费用 120 元再如问某研究人员有哪些 GCP 资质记录仅报出培训名称也不够系统需要知道这些记录来自研究人员基本情况 GCP培训与资质情况再如问已授权的项目职责是什么该职责值必须绑定到项目授权与职责 项目经历与授权职责 对应项目记录缺少父路径答案看似有值却无法稳定追溯到正确的业务区块。一旦进入质控、审计、RAG 溯源或自动入库环节这层缺失就会转化为实际成本需要额外规则判断子表边界、补全父字段、重建层级甚至在多个相近金额、多条相似培训记录之间重新做归属判断。因此表中表解析的目标从来不只是“把文字转出来”而是把业务对象转成下游可以直接使用的结构化数据。回到本轮实战结论比较清楚表中表解析不是单纯的 OCR 准确率问题而是结构可用性问题。四款模型的表现汇总如下模型嵌套结构ETL 写入本轮定位TextIn xParse完整保留34 共 7 个子表7/7 可直接入库可直接入库MinerU VLM表格/文本有召回未保留父子结构0需修复父子关系需父子关系修复PaddleOCR-VL表格/文本有召回子表被摊平0需修复父子关系需父子关系修复GLM-OCR仅有文本/坐标无表格层级0需重建表格OCR 基线MinerU VLM 和 PaddleOCR-VL 本轮文本与表格内容均有召回只是未直接保留嵌套父子结构下游若要稳定写库仍需先补一遍父子关系。GLM-OCR 更适合作为 OCR 文本/坐标基线提供文字与坐标但不返回表格层级。TextIn xParse 的价值正在于此它输出的不是一堆 OCR 文本或一张普通二维表而是将父子层级一并带出的结构化结果能够直接被 LLM、Agent、RAG、ETL 等下游取用。对于临床表单、报销明细、资质档案这类复杂表格场景选型时的建议是**不要只关注“识别出多少字”更要检查结构是否保留、父子关系是否清晰、下游能否直接取用。**最直接的验证方式是拿一张自己最棘手的嵌套表实测一遍。如果你对复杂表格解析、文档结构化处理等方向感兴趣可以体验 TextIn xParse进一步了解其在真实业务场景中的解析效果体验链接注册送1000页额度https://www.textin.com/register/code/ZR28L4