目录一、一张业务申请表里的解析盲区二、什么是嵌套表格三、为什么嵌套表格难以被解析工具“看懂”**根因一二维网格模型装不下树形结构****根因二输出 schema 不支持嵌套****根因三版面边界模糊**四、嵌套表格数据丢失下游会发生什么ETL / 数据入库金额字段写入错误RAG / 文档问答金额查询答非所问合同 / 采购审核付款金额漏审Agent 自动化金额驱动的任务链路中断五、解决嵌套表难题要做对哪些事一、一张业务申请表里的解析盲区你接入了某个文档解析服务处理一批扫描的业务申请表。表格主体看起来规整——账户名称、账号等各占一行。但在各项“金额”栏里旁边还嵌着一个小表格分别列出“万、仟、佰、拾、元、角、分”对应的大写汉字金额。解析结果拿到后主表格的行列都对文字也没少。但金额小表中大写数字被拍平成几行散落的文本和主表格混在一起。你无法判断它们分别对应的是哪一笔申请也不知道它和下面的小写数字是什么关系。表格结构识别错误这不是文字识别出错而是表格结构识别的问题——具体来说是嵌套表格的解析失败了。本文聚焦这一特定类型拆解它的难点、场景和解决思路。二、什么是嵌套表格嵌套表格Nested Table指的是在表格的某个单元格内部存在另一个具有独立行列结构的子表格。它和“相邻的两张表”“跨页表”本质不同——关键在父子隶属关系。这种结构在真实业务文档里并不少见常见形式包括​一对多明细​客户信息表里每个客户名下挂一段订单明细。这是最高频的一类。​金额分项表​业务申请表、报销单、发票中总金额旁嵌着大小写对照、币种拆分、费用类目明细等子表。​条款内的计划表​合同条款中嵌入付款计划付款阶段、条件、金额一一列出。​分类下的子项​财务报表中某个科目单元格内展开子科目明细。对于下游系统来说嵌套表格的数据价值不在“被识别出来”而在父子关系被准确保留。子表一旦被拍平和主表的关联就断了——对下游而言这张表等于白解析了。子表格隶属关系三、为什么嵌套表格难以被解析工具“看懂”嵌套表格不是单一技术点的挑战而是对解析系统数据模型、输出架构和版面理解能力的综合考验。核心难点有三个。根因一二维网格模型装不下树形结构大多数表格解析工具的底层假设是“一张表格 一个 M×N 矩阵”每个单元格由行列索引唯一确定。这个模型在处理规整表格时高效但嵌套表格本质上是一个树形结构——一个单元格的内部不是“一个值”而是“一张子表”。用网格去套树子表信息必然被丢弃或拍平。​解析失败后是什么情况​如上面的 Bad Case 图例所示解析结果中主表的行列依然规整但子表的内容变成了主表中凭空多出的几行和主表信息混在同一层级。你分不清这些大写数字属于哪一行的金额字段——主表结构看起来完整但子表数据已经“溶”进了主表里父子关系彻底消失。根因二输出 schema 不支持嵌套主流文档解析的输出格式比如 Markdown 或扁平 JSON 数组在设计时并没有考虑“单元格内容可能是另一张表”这种情况。即便识别环节在内部检测到了嵌套关系最终输出时也会因为 schema 不支持而被强制扁平化。解析器其实“看见了”但它“输不出”。​解析失败后是什么情况​即使解析系统在内部处理时识别出了嵌套结构最终输出的 JSON 里子表依然被展开成一串扁平对象。原本应该是这样的嵌套结构{ 客户: A公司, 订单明细: [ { 订单号: 001, 金额: 5000 }, { 订单号: 002, 金额: 3000 } ] }实际拿到的却是三条平铺的记录{ 客户: A公司 } { 订单号: 001, 金额: 5000 } { 订单号: 002, 金额: 3000 }下游系统拿到后根本没法判断后两条订单属于谁。根因三版面边界模糊嵌套表格的子表通常没有完整边框只靠缩进、字号变化或轻微的分隔线与外层区分。人眼能根据上下文判断边界但算法容易把子表的行当作主表的新行或者把子表内容和外层单元格的相邻文本混在一起。边界识别错误是嵌套表格最常见的失败模式。​解析失败后是什么情况​子表的第一行被正确归入外层单元格但第二行起因为缩进偏移或分隔线缺失被误判为一张独立的新表。原本属于同一个父单元格的子表被拆成了两块——一块留在原位一块变成了“孤儿表”。下游看到的是一张和原始上下文完全断开关系的表格碎片。四、嵌套表格数据丢失下游会发生什么回到开头的业务申请表。如果那张金额子表在解析中丢失或拍平下游系统会发生什么这不仅仅是“少了几行数据”的问题而是一连串连锁反应。ETL / 数据入库金额字段写入错误业务申请表中的大小写金额子表本质上是同一笔金额的结构化表达——小写数字用于计算大写汉字用于合规校验。解析时如果子表丢失或拍平小写金额和大写金额的对应关系就断了。入库后可能出现大写金额挂错申请记录、大小写金额不一致却无法校验、甚至金额子表中的“角、分”被写入了其他字段的情况。对于一个日均处理上万份申请的系统来说这类错误不是偶发 bug而是系统性脏数据。RAG / 文档问答金额查询答非所问用户问“这笔申请的大写金额是多少”RAG 系统检索到了子表中的汉字金额。但父子关系断裂后模型无法判断“捌仟元整”对应的是哪一笔申请记录。返回的答案可能是另一笔申请的金额——数字本身没错但对应关系是错的。在金融、财务、审计这类场景里“看起来很对”比“找不到答案”更危险。合同 / 采购审核付款金额漏审合同中的付款计划往往以嵌套表格形式出现——每一笔付款的金额、条件、时间节点依次列出。如果金额子表被拍平审核系统可能漏掉对某一笔付款金额的校验。比如分三期付款、每期金额不同的条款解析后变成了孤立的几个数字审核规则根本无法匹配到对应阶段。Agent 自动化金额驱动的任务链路中断Agent 需要“读取每笔申请的金额 → 根据金额大小分流审批 → 对大额申请触发补充材料流程”这样的层级操作。嵌套关系丢失后Agent 无法将大写金额、小写金额和申请记录一一绑定。后续的金额判断、规则匹配、审批流转全部无法执行——不是某一环出错而是整个金额驱动的自动化流程中断。五、解决嵌套表难题要做对哪些事TextIn xParse 在嵌套表格上实际给出了什么样的结果我们来看三个关键点。第一输出结果保留嵌套结构xParse 的输出中当一个单元格包含子表时该单元格的值不是字符串而是一个完整的子表对象——有自己的行列结构、表头和内容。开发者拿到结果后可以直接遍历父行再从父行中获取子表数据进行二次遍历不需要从扁平数据中反向推断归属关系。第二子表边界被准确识别从输出结果来看子表的内容被完整保留在所属单元格内不会溢出到主表的其他行列中。无论是通过缩进对齐的无线框子表还是字号缩小以示区分的嵌套明细最终输出中子表和外层单元格的隶属关系明确不会出现“半个子表在外、半个在内”的情况。业务申请表里的“万、仟、佰、拾、元、角、分”金额子表会被完整保留在对应的金额字段下。第三父子映射自动建立输出的 JSON 结构中子表记录的路径天然包含父行信息。开发者不需要通过行号推算或关键词匹配来重建主从关系。拿到结果后可以直接消费——ETL 写入主表和从表、Agent 做层级遍历、RAG 做上下文关联都不需要额外写后处理逻辑。