![氛围图](https://developer.qcloudimg.com/http-save/8729876/51d6fa6fadd85cbf02318b06bca8bc08.jpg)

> 💡 **一句话总结**：把文档里的表格渲染成图、压缩到 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](https://arxiv.org/abs/2608.26949)（[HTML 全文](https://arxiv.org/html/2608.26949v1)）
> - 📊 数据集：[MultiHiertt](https://aclanthology.org/2022.acl-long.454/) · [FinLongDocQA](https://arxiv.org/abs/2604.03664)
> - 💻 代码：论文注明"发表后放出"，截至发文还没挂出来

## 🎯 这篇论文到底想解决什么问题？

先把场景说具体。金融文档问答是长上下文里最难受的一类：文本和表格交错、问题全是数值推理（"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



💡 一句话总结：把文档里的表格渲染成图、压缩到 64 个视觉 token，模型读不出具体数字，却还能准确判断"哪张表和问题相关"——爱丁堡大学团队据此设计了两段式问答：先用压缩图找表，再对找出的表做原生分辨率推理，长文档上省 41% token、准确率反涨 7 个点。做文档 QA / RAG 的人值得花十分钟读完。

把表格压成 64 个 token，长文档问答反而更准了：先找表，再看数

人工智能

算法

新闻资讯

表格压缩至64视觉token虽致读数失效，却意外强化了“找表”能力。爱丁堡大学据此提出两段式问答：先用压缩图定位相关表格，再对选中表格做高清推理。在100页长文档QA任务上，该方法节省41%总token，准确率反升7.1个点。这套免训练的“先找后读”模式，为多表文档问答提供了新的成本优化思路。

DeepSeek

路由

2026上云采购 | AI焕新·智启新局

documentocr

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

把表格压成 64 个 token，长文档问答反而更准了：先找表，再看数-腾讯云开发者社区-腾讯云

把表格压成 64 个 token，长文档问答反而更准了：先找表，再看数

把表格压成 64 个 token，长文档问答反而更准了：先找表，再看数

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐