一份三十多页的供应商对账明细被上传到企业的智能助手之后财务人员开始用它替代翻表的动作。有人问某家供应商三月的应付金额助手给出一个数字金额本身看着合理也确实是这一列里的数据直到月末复核时才发现这个数字来自相邻一行的另一家供应商两家的名称只差一个字。系统按供应商名称这一自然语言串去检索相近名称的明细行被混入同一查询串位由此发生。遇到这类结果常见的反应是怀疑切片设得不对于是把表格按行切、按页切各试一遍或者干脆让模型重新读整张表。这些动作有时能碰对有时反而更乱。根源在于表格一旦被还原成连续的文字行列之间的对应关系就不再被保留数值与它所属的行、列、表头失去了联系。表格被读成文字之后失去了什么解析环节通常把页面上的文字按阅读顺序排出表格因此变成一串文本。单元格之间的边界被抹平一行里的多个字段连在一起上一行的内容与下一行接续行与列的坐标没有留下。多级表头与合并单元格会把偏移放大展开之后某个数值可能落到相邻列的位置上。跨页的表格还有另一种情形后一页往往不重复表头数据行失去归属只能凭位置去猜。同一列里有的单元格是数字有的带着备注文字按阅读顺序排出后备注会与相邻行的数值粘在一起取值时就更容易串位。取数为什么应当走结构而不是检索关键数值类的问答与普通知识问答不同前者要的是确定的一个数而不是一段相关的内容。文本检索按相似度召回片段同一张表里的多个金额措辞相近召回到哪一段都算合理而错位的数值又往往落在彼此接近的字面上答案因此读起来通顺却对不上原件。可用于定位业务对象的信息应优先使用供应商ID、客户编码、单据号等稳定业务键名称只作为展示或辅助匹配名称相近、重名或别名无法唯一定位时应先做消歧。日期区间等条件若只以文本形式留在正文里就无法被用来限定取值范围取值只能依赖位置。一种做法是让数值类问题走结构化查询先用业务键定位到确定的行集合再按列取值当问题指向一个汇总值例如某供应商三月的应付金额应在命中的多行上对应付金额字段做求和而不是只取单个单元格。文本检索则留给说明性内容。取数过程的定位信息应优先保存来源文件版本、table ID、稳定业务行键、列路径以及原始页码与单元格坐标行号可以作为展示信息但不作为唯一审计锚点答案里同时给出定位信息与聚合口径用户顺着核对即可。行列级的校验与存疑标注结构化之后仍然需要校验。当原表存在明确的小计、合计或其他可验证公式时可以利用这些关系做结构一致性检查没有已知计算关系时不自行假设求和规则例如对不能直接求和的字段、比例、去重数或公式结果强行相加合计本身也可能在原表中填错系统不应以自行推算的合计去反推原件。这类检查不需要外部数据就能完成。对于表头继承失败、单元格内含多个值、行身份不确定或字段类型存疑的情形系统应当对单元格值、表头映射、行身份与字段类型分别下调可信标注并在答案里提示需要人工复核而不是把它们与其他取数结果一样输出。解析产物还要登记来源文件的版本与页码便于事后回到原件比对。通用模型与Agent平台通常会提供文档解析与表格抽取能力但表头如何继承、合并单元格如何展开、数值类问题是否改走结构化取数这些仍要结合企业自身的数据形态来确定。在青山不语AI工作室的企业AI定制方案中表格按行列结构解析并保留单元格坐标表头按多级拼接规则继承跨页继承前先验证列数、列结构、表格标识、版式与上下文一致无法确认属于同一逻辑表时不自动继承而进入存疑复核数值类问答优先用供应商ID、客户编码、单据号等稳定业务键定位再走结构化取数定位信息保存来源文件版本、table ID、稳定业务行键、列路径与原始页码单元格坐标行号仅作展示汇总类问题在命中行上做多行聚合并对单元格值、表头映射、行身份与字段类型分别做存疑标注。这套机制的边界在于它能还原表格的结构与取数路径却无法判断表格里的数字本身是否填错原始数据的准确性与口径归属仍由业务部门负责遇到扫描件本身模糊、单元格被截断的情形识别结果存在上限这类行只能进入人工复核清单。验收可以先用一份含多级表头与跨页的构造样例逐列核对解析出的坐标再抽几个数值问题看答案附带的定位信息能否对上原件并验证跨页断裂是否会被误判为同一张表。测试数据同样应当使用构造内容不要使用真实对账数据。我认为表格类问答的成败不在模型能不能读表而在系统有没有把读取结果落到带坐标的结构上并用稳定业务键而非名称去定位。企业在挑选AI定制服务时一个可以问的问题是这套方案返回一个金额时能不能同时说清它用哪个业务键定位、取自哪张表的哪些行哪一列聚合值是否来自多行汇总。这个问题能被回答数值类问答才有核对的余地。