数字没抄错，RAG为什么还是读错了表？

助手从报告里找到了“30”，还附上了能打开的PDF引用，却把“西区、预算、千元”说成了“东区、实际、万元”。

数字没有抄错，关系全错了。

RAG——先检索资料、再据此生成回答——处理普通段落时，往往把文字前后相邻视为重要线索。但表格不是一条排开的句子：一个单元格的意思，可能同时写在左边的行名、上方的两层列名、表题的单位和表后的脚注里。本篇要回答的是：怎样让数字离开原表后，仍然带着自己的身份？

AI原创概念插画：木质分格标本柜旁，红色种荚分别出现在格内与柜外纸片上；植物图牌与黄铜放大镜作关系定位的视觉隐喻，不代表真实植物分类或表格解析结果。

从一个很小的表开始Copy Anchor Link

下面是完全虚构的活动经费表，用于说明信息表示；没有对应真实机构，也没有运行OCR、模型或向量数据库。

原报告表题为“读书活动经费，单位：千元”。上层列头分成“东区”和“西区”，每个区下各有“预算”“实际”两列。为便于本文阅读，先把两层表头展开写成一层：

表后脚注：“实际金额截至9月底，均不含税；破折号表示尚未结算，不表示零。”

读者问：“西区场地实际花了多少？”

答案不在“30”这个数里。30属于西区预算；实际一栏是破折号，且脚注明确说尚未结算。因此，这份材料只能支持：西区场地实际金额尚未结算，不能按零或预算数回答。

若解析结果只留下下面这行：

场地 20 18 30 —

它保留了字符，却不足以独立解释每个数字。此时增大检索数量，也不能从这些字符中恢复已经丢失的表头关系。若上游仍保存原表，可以重新读取；若只保存扁平文本，就需要回到源文件重新解析，而不是让模型猜列序。

表头关系不是装饰Copy Anchor Link

W3C的表格无障碍教程讨论了一个相邻但不同的问题：如何让辅助技术理解跨行、跨列表头。[1] 它用colgroup与rowgroup等范围关系，把上层表头关联到相应数据单元格；双层表头示例中，同名的下层列头要与各自的上层组名一起解释。

这不是RAG性能论文，也没有证明某种序列化方式必然提高回答准确率。但它说明了一个可直接借鉴的结构事实：数据格与表头的关联需要被表达，不能只保存视觉上读起来顺眼的字符顺序。

在经费表中，“实际”出现两次，仅保存这个下层列名仍不够。需要的是“西区 → 实际”这条完整路径；行头若也分层，还要保留“活动类型 → 项目”等对应路径。

这与补读相邻段落不同。表后的脚注可能离数字很近，但上层合并表头在文本提取顺序里可能离它很远；二维位置与层级关系不能简单替换成“前后多取两句话”。

第一关：解析时先别把结构扔掉Copy Anchor Link

Microsoft的Document Intelligence布局输出文档说明：其Markdown输出中的表格采用HTML表格语法，支持用rowspan、colspan保留合并单元格，也保存表题，并将表格脚注作为表后的独立段落。[2]

这里值得注意的不是“HTML一定比Markdown更聪明”，而是输出格式能否表达原表实际需要的关系。简单矩形表用普通Markdown可能足够；有合并表头、分组行或复杂布局时，普通竖线表格未必完整表达结构。

同样，“脚注在结果里”不等于“脚注已经跟每个相关格绑定”。如果切块时将表与后面的脚注拆开，模型最终还是可能看不到“—不等于零”。因此，应分别验收：

• 源文件里的列与行是否被正确识别，跨页续表有没有串到另一张表？
• 合并单元格的跨度与表头层级是否正确，而不只是输出里出现了HTML标签？
• 单位、统计范围、截止时间和脚注是否保留，并能按可靠来源关系取回？

厂商文档描述的是该布局接口的输出能力，不是对任意扫描件、任意版本的无误识别保证。本篇没有调用该服务。模糊扫描、旋转页面、脚注符号或跨页重复表头，都需要用自己的样本核对。

第二关：大表可以拆，但关系要随行Copy Anchor Link

把整张表一直塞进模型上下文，并不总是可行。表可能很长，读者只问其中一个地区、一个项目。

Unstructured的分块文档区分Table与TableChunk：表在容量允许时单独保留，过大的表会拆成特殊表格块；其基本策略说明会考虑按行拆表。[3] 这说明表可以有区别于普通叙述文字的处理单元，不等于工具替应用保证了每个片段都已带齐全部表头、单位和脚注。这件事要检查实际输出，不能从类型名字推断。

针对案例，一种应用层设计是：保留原始结构表，再为检索构造带身份的行记录。下面是本文建议的设计示意，不是任何SDK字段契约，也不是API返回：

来源：活动经费说明／已核对版本／表2／场地行
表题：读书活动经费
单位：千元
行路径：场地
列路径与原值：
  东区／预算：20
  东区／实际：18
  西区／预算：30
  西区／实际：—
关联脚注：截至9月底；实际金额不含税；—表示尚未结算
回查位置：源文件相应页、表、行及原表片段

这份记录比“场地20 18 30—”更长，却允许读者检查数字究竟属于谁。具体系统可以选择重复关键表头，或以稳定ID关联到表级元数据；关键是实际交给回答阶段的内容必须能还原这些关系，而非只在数据库的某个角落存着。

还要保留原值与解释的区别。“—”可以映射为业务状态“尚未结算”，但不能抹去原始符号；没有脚注依据时，不应擅自把所有破折号都映射成同一状态。空白、零、不适用、未披露与尚未结算，也不是通用的同义词。

第三关：摘要负责找表，原格负责支持结论Copy Anchor Link

表格摘要可以帮助定位，例如“按地区列示场地与物料的预算、实际经费”。但如果摘要省略了西区实际尚未结算，不能拿它直接回答金额问题。

本文建议将两份材料分开使用：

1. **定位材料：**表题、摘要、行名和检索用文本，帮助找到可能相关的表或行。
2. **证据材料：**命中后读取的原表格片段、完整表头路径、单位、相关脚注与来源位置，用来支持具体回答。

这是工程设计建议，不是上述三个来源共同规定的标准架构。即使采用它，仍需单独验证检索有没有找到正确行、结构解析是否可靠，以及模型有没有遵守证据边界。

引用也应能指回具体表和位置。一个能打开的整份PDF链接，只证明来源可访问；不证明答案中的“30”真是那张表的“实际支出”。如果只能定位到表、无法确定格与表头关系，应报告这个缺口，不能用高相关分数替代确认。

何时该换成结构化查询Copy Anchor Link

对“西区场地实际是多少”这样的定位问题，保留结构的表格片段可能已经足够。但若任务是跨很多行求和、筛选或连接多张表，让语言模型从长文本中目测计算，往往不是最容易审计的路线。

一种可选方案是：先核对表结构，将数据装入受控的结构化表示，再由确定性程序执行获授权的计算；输出仍带回源表位置、单位与缺失值处理规则。这里没有自动化捷径：如果上游把“千元”误读成“万元”，计算程序可以非常精确地算出错误结果。

本篇没有进行计算实验，也不声称SQL或某种框架必然更准确。选择路线时，应看问题类型、表格质量、审计要求和数据权限，而不只看能不能把文本塞进上下文。

一份可直接使用的验收清单Copy Anchor Link

下面是建议测试项，未作为模型评测执行：

• 任取一个数值，能否同时指出行路径、完整列路径、单位和原表位置？
• 两个上层分组含同名下层列头时，会不会只剩“预算／实际”而串区？
• 合并单元格、跨页续表及重复表头是否用真实样本核对？
• “—”、空白、零与不适用是否按原表说明区分，缺解释时保留未知？
• 表题中的单位、表外脚注和截止时间能否跟命中行一起进入最终阅读材料？
• 拆表后随机检查中间块，而不只检查带首行表头的第一块？
• 摘要只负责定位时，数值回答是否仍回查原格，而非引用摘要代替证据？
• 做聚合前，是否明确币种、单位、缺失值与纳入范围，并保留计算依据？
• 原始结构、规范化记录、最终模型输入与答案引用之间能否逐步对账？
• 表级扩展是否仍执行当前用户的读取权限和版本限制？

若要做对照评测，可以固定同一批问题和源文件，比较扁平文本、结构表、带表头路径的行记录。将“选对表”“选对行列”“解释缺失值”“最终答复”分开评分，并保存最终模型实际拿到的材料；不要把人工案例的推理当作准确率提升。

数字本身通常很短，解释它的关系却不一定短。RAG读表的第一步，不是催模型再算一遍，而是让每一个格子在离开页面时，仍然知道自己属于哪一行、哪一列。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。经费表、错误答复与记录格式均为手工概念材料；未调用OCR、模型、嵌入服务、向量数据库或表格处理SDK。资料检索截止：2026年10月22日11:52 UTC。

1. W3C WAI：Tables with Irregular Headers。公开教程，所读正文未核实独立发布日期或固定版本；本轮实际阅读概览、双层列头、跨行跨列表头与示例代码。它支撑表头关联机制，不是RAG效果或OCR准确率来源。
2. Microsoft Learn：Document Intelligence Layout API Markdown输出格式。页面标注更新日期2026-04-16，链接视图为doc-intel-4.0.0；实际阅读Table相关完整正文，核对HTML表格、合并单元格、表题与独立脚注的说明。未把文档能力当作本轮服务实测。
3. Unstructured：Chunking。动态文档，未锁定软件发布版，所读正文未核实独立发布日期；实际阅读元素类型、Table／TableChunk、基本分块与表格按行边界处理的相关正文。不据此声称任意输出片段自动保留全部解释信息。