💡 一句话总结：把文档里的表格渲染成图、压缩到 64 个视觉 token，模型读不出具体数字，却还能准确判断"哪张表和问题相关"——爱丁堡大学团队据此设计了两段式问答：先用压缩图找表，再对找出的表做原生分辨率推理，长文档上省 41% token、准确率反涨 7 个点。做文档 QA / RAG 的人值得花十分钟读完。
导语
先问一个可能戳到你的问题：你的文档问答 pipeline 接了一份 100 页的年报，里面 80 张表格。为了保住表格结构，你老老实实用 HTML 序列化塞进上下文——十几万 token 就这么烧出去了，账单和延迟一起起飞。
你可能也关注过今年很火的"光学上下文压缩"（optical context compression，把文本渲染成图片喂给模型，因为图占的 token 比原文少）。DeepSeek-OCR 那句"contexts compression"让不少人眼前一亮：文字拍成照片，token 打对折。听起来像是长文档成本问题的解药。
但真把财报丢进去你就发现不对劲了：正文压得动，表格压不动。表格是文档里信息密度最高的东西，压狠了模型根本读不清单元格里的数字，答非所问。于是表格只能原样塞 HTML，token 成本的最后一座大山纹丝不动。
爱丁堡大学 Alonso 和 Lapata 的这篇新论文（A Table Is Worth 64 Tokens: Pixel-level Compression for Multi-Table Document Question Answering，arXiv:2608.26949）就是冲着这座山来的。他们的结论有点反直觉：表格可以压到很狠——前提是，你别指望模型直接从压缩图里读数。
想自己动手试？
- 📄 论文：arXiv 2608.26949（HTML 全文）
- 📊 数据集：MultiHiertt · FinLongDocQA
- 💻 代码：论文注明"发表后放出"，截至发文还没挂出来
🎯 这篇论文到底想解决什么问题？
先把场景说具体。金融文档问答是长上下文里最难受的一类：文本和表格交错、问题全是数值推理（"2021 年第三季度的经营费用占收入的百分之几？"），而且答案经常藏在七八十张表里的某一张。
现在的做法基本是把表格序列化成 HTML 塞进上下文。HTML 能保住多级表头和合并单元格这些结构信息，但代价惨重：论文里用的长文档数据集，光正文文本就有 6 万多 token，表格序列化再翻着倍地往上加。高效注意力再怎么优化，超长上下文该贵还是贵，超过预训练长度后该掉智商还是掉智商。
光学压缩看起来是条出路——把表格渲染成图片，一张表图消耗的视觉 token（visual token，模型"看图"时消耗的等价字数）比 HTML 序列化少得多。问题在于，之前所有"光学压缩可行"的证据都建立在纯文本上，表格没验证过。而表格和正文不一样：读表格要求逐格辨认数字，这是细粒度感知，恰恰是压缩最先杀死的东西。
所以论文的核心问题一句话就能说清：像素级的表格压缩，能不能在不牺牲（甚至提升）问答准确率的前提下，把多表文档 QA 的 token 成本打下来？
🧠 它的思路是什么？
作者的打法很扎实：先别急着提方法，把"压缩到底毁掉什么、保住什么"测清楚。他们在 2 个多表文档问答数据集（短文档的 MultiHiertt、约 100 页长文档的 FinLongDocQA）上，拿 Gemma 4 和 Qwen 两家的 5 个开源视觉语言模型（VLM，Vision-Language Model，能同时处理文本和图像的模型），把每张表图统一压到 64 / 128 / 256 / 512 / 1024 五档视觉 token 预算，逐层测试。
第一层测的是"还认不认得出表格"。他们用 TEDS（表格还原相似度，基于树编辑距离打分，0 到 1 越高越好）让模型把表图转录回 HTML，结果毫无悬念：预算越低转录越烂，压到 64 token 时分数已经明显掉下 80。对照组还揭示了个小尴尬：让模型把 LaTeX 格式的表格转成 HTML 也会掉分——部分误差压根不是"看不清"，纯粹是格式转换手潮。
图说：彩色点是各模型从表图转录的得分，从右往左（预算收紧）一路下行；灰十字和红三角是两个纯文本对照。
第二层测直接问答，出现了一个更微妙的坏消息。压缩狠了准确率下滑不奇怪，奇怪的是模型生成的 token 反而变多了。为什么会这样？想象你近视没戴眼镜去核对一张报表：看不清，就反复眯眼、换个角度再看一遍、跟邻列比对着猜——模型也一样，对着糊掉的单元格反复读数、犹豫、自我纠正，思维链越拉越长。
先看输入视角，压缩确实在省钱：
图说：横轴输入 token、纵轴准确率。图像表示用更少的输入做到接近 HTML 的准确率，但预算标签一旦掉到 128、64，分数就守不住了。
可把视角换成总账（输入 + 生成一起算），故事立刻变了味：
图说：看蓝线（HTML 表示）——64 预算的点落在横轴 13700 附近，比不压缩的 HTML 点（9500 左右）还贵。省下的输入 token，被"看不清就反复琢磨"的生成开销成倍吃了回去。
这就是很多人漏算的账：光盯着输入 token 省了多少，不看生成端膨胀了多少，压缩的收益就被高估了。听起来离谱，但账本就是这么写的——压得越狠，总成本反而可能越高。
那压缩是不是就一文不值？第三层实验翻出了全文最漂亮的发现。让模型在压缩上下文里只做一件事——判断哪些表和问题相关（不答题，只报表号），结果识别准确率几乎不随预算变化：压到 64 token，找表能力和给完整高清图时基本一样。作者还留了个"狠"对照：把每张表整个删掉、只留一个表编号占位（tableid），模型光靠上下文文字也能猜个大概——但在那之上，64 token 的压缩图实打实多贡献了 16 个 F1 点（Gemma 4 26B；Qwen 3.5-9B 是 +10。F1 是查全与查准的调和平均，同时衡量"该找的找齐了没"和"不该找的混进来没"，越高越好）。压缩图是真的保留了信息的，只是保留的不是数字，而是"这张表是讲什么的"。
图说：柱顶百分比是该配置的下游问答准确率；两条虚线分别是瞎猜基线和专用检索器 ColQwen2 的最佳工作点。
一个类比：把财报缩印到邮票大小，你确实看不清任何数字了，但你依然认得出哪页是现金流量表、哪页是利润表——版式、标题、行列轮廓这些粗信号，比单元格数字抗压缩得多。
顺带交代下压缩本身怎么做的：把每张表的 HTML 用无头浏览器渲染成黑白、统一字体的图片，再按模型视觉编码器的折算规则（Qwen 系是每 32×32 像素折 1 个视觉 token）保持纵横比缩到预算以内。渲染时特意让图像和 HTML 内容逐格一致，这样两种表示的性能差异才能干净地归因于"表示方式"而不是"内容不同"——实验设计的严谨度在线。
思路到这就水到渠成了：既然"读数"和"找表"对压缩的敏感度天差地别，那就别让压缩图去干"阅读"的活，让它只干"找表"的活。两段式方法登场——
- 第一步（identify）：模型拿到整份文档——正文是文本，所有表格都是压缩到 64 token 的小图，每张表前有
[TABLE_n]标记。它不答题，只输出要哪几张表。这一步还刻意关掉了测试时推理（test-time reasoning，即"先打草稿再作答"的长思维链模式），把开销压到最低——反正只是找表，犯不着深思。 - 第二步（reason later）：被点名的表以 1024 视觉 token 的原生分辨率追加进对话，模型这才开动思维链，在清晰可读的单元格上做数值推理，给出答案。
整个过程免训练、只靠提示词、不挑模型。用一句话概括这套哲学：压缩负责"找到证据"，原生分辨率负责"读懂证据"——让 64 token 的模糊小图去干它们擅长的路由活，别逼它们读数。
📈 效果到底怎么样？
主战场是约 100 页、80 张表的长文档数据集 FinLongDocQA，这也是最能体现方法价值的地方，直接上数字：
- 准确率：两段法在所有压缩预算上都超过"原生分辨率表格的单步问答"。压到 64 token 时，Qwen 3.5-9B 高出 11.2 个点、Gemma 4 26B 高出 3.0 个点；两个模型平均 +7.1 个点。
- token 成本：同样压到 64 token 时，比原生单步平均省 40.6% 的总 token（输入 + 视觉 + 生成一起算）。这就是摘要里"省 41%、涨 7 个点"的出处。
图说：横轴是总 token 成本，纵轴是准确率——绿线又左又高，红线低预算时直落到 15 分上下。
图说：哪怕最狠的 64 token 预算，绿线依然站在红线左上方——省最多的钱，考更高的分。
顺着图多说一句我的读法：绿线最值得注意的不是高，是平——从 1024 压到 64，两段法的准确率几乎不掉。这说明压缩图只要能完成"找表"任务，压多狠都无所谓，真正的阅读发生在第二步的高清表上。
还有两组对照值得一提。跟专用检索器比：视觉检索模型 ColQwen2 找证据表的 F1 确实更高，但这个优势传导不到最终答案上——同成本下两段法在长文档上高出 16 个点；Gemma 4 26B 上检索最多反超 7.3 个点，可两段法只用它 45% 的 token 就追平了同一水平线。更实用的是，两段法还能叠在检索后面再省一轮：在 BGE-M3 检索出的上下文上，匹配相同准确率最多能再省 72.5% 的 token。也就是说它不是检索的竞品，是检索的"节能外挂"。
短文档上也不是全无亮点，只是账要算细：Gemma 4 26B 在 256 token 预算下省 33.8% 成本、只亏 3.9 个点；Qwen 3.5-9B 则在省 20.9% token 的同时完全保住了原生分辨率的准确率。只是到了 64 token 这种最狠的档位，平均收益就薄了——方法的舒适区明确在长文档。
诚实的另一面也得说：在只有 3 张表的短文档 MultiHiertt 上，这套方法平均是亏 4.4 个点的——文档短、表格少，识别步那道"全文再过一遍"的固定开销摊不平。省 41% 的故事只在长文档上成立，而这恰好是它瞄准的场景。
💼 为什么你要关心？
如果你的工作涉及文档 QA、RAG 或者任何"喂长报告给模型"的 pipeline，这篇论文有三处能直接落地的价值：
- 一个即插即用的提示模式：identify-first-reason-later 不需要训练、不挑模型，本质就是两段提示词 + 图片分辨率切换。你的多表文档 QA 明天就能试：第一遍让模型只报表号，第二遍把点名的表给高清图。顺手还能把"报表号"的输出接到你的审计日志里——模型用了哪些证据，一目了然。
- 一个成本估算动作：先量一下你手里文档的"表格 HTML token 占比"。占比越高（财报、招股书、研报都是重灾区），这套方法的潜在收益越大；反之如果你的文档表格稀疏，正文文本那 6 万 token 的固定成本省不掉，收益会缩水——别盲目套。
- 一个测量口径的修正：以后评估任何压缩方案（prompt 压缩、视觉压缩、token 剪枝都算），把生成 token 一起计入账单。这篇论文清楚地演示了"输入省了、生成炸了"的隐性通胀——只报输入 token 的压缩论文，都在给你看半张账单。
再往远看一层，这篇工作其实给"光学上下文压缩"这个方向重新定了位：压缩表示的价值不必在于"模型能从里面读出一切"，而在于"模型能借它便宜地完成路由"。这个思路对 RAG 里的索引压缩、agent 的记忆压缩都是可以借走的架构直觉。
🤔 理性看待
几处需要保持清醒的地方。收益构成上，+7 个点并非全部来自"压缩"：论文自己承认，两段法在 1024 预算（约等于不压缩）下也有明显提升——"先找证据再答题"这个流程本身就涨分，压缩的独立贡献是把这个流程做便宜、且低预算不掉分。读 headline 数字时建议心里把这个拆开记。
适用边界也要划清：实验只覆盖英文金融文档、2 个数据集；表格是从干净 HTML 渲染的黑白图，真实世界的扫描件、花式排版没验证；方法假设表格边界已知，原始文档得先过一道表格检测；效率只统计了 decoder token，两步推理的额外延迟没进账——"省 41% token"不等于"快 41%"。另外代码承诺"发表后放出"，截至发文还没挂出，想复现的朋友可以盯一下作者的 arXiv 页面。
作者：lusca
版本：lusca-paper-blog v1.5.0
出处：https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog
