微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 ConceptFormer:让AI学会用"隐藏概念"看懂文档里的图表和细节

ConceptFormer:让AI学会用"隐藏概念"看懂文档里的图表和细节

2026-08-26 10:27
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-08-26 10:27 科技行者

你有没有遇到过这种情况:拿着一份带图表的PDF去问AI"这张表里第三行的数字是多少",结果它压根没找对地方,反而给你扯了一堆表格标题周围的无关内容。

这不是AI偷懒,而是它压根不知道该往哪儿看。

现在的文档检索系统,处理的早就不是纯文字了。财报里的柱状图、地图上的色块、幻灯片里的排版结构,这些视觉信息藏着大量关键证据,可传统的检索模型往往只会"整页扫一遍",然后给你打一个笼统的相关性分数。就像你让一个人去图书馆帮你找一本书里某段话的出处,他把整本书举起来说"就是这本",却说不出具体在第几页第几行。

这篇来自东北大学、清华大学等机构联合发表的论文《ConceptFormer》,就是想解决这个"知道大概方向,却抓不住具体证据"的老问题。

当AI只会"整页打分":问题到底出在哪

先说说这个领域现在卡在哪儿。

视觉文档检索*:给AI一句提问,让它从一堆文档页面截图里,找出哪一页真正能回答这个问题。检索靠的不是读文字,而是直接理解图片里的内容。

早期的做法很朴素:先用OCR把图片里的文字提取出来,再套用传统的文本检索方法,比如BM25或者BGE这类稠密检索器。问题很明显,OCR会出错,遇到复杂表格或者手写体经常认错字,而且图表、色块、空间布局这些非文字信息,OCR压根抓不住。论文里的实验数据显示,就算是表现最好的OCR文本检索器NV-Embed-v2,在Wikimedia Maps这种以地图为主的数据集上,NDCG@10也只有9.92分,惨不忍睹。

后来大家开始直接处理图片,不走OCR这一步了。像DSE、VisRAG-Ret、VDocRetriever这些模型,直接把整页截图和查询一起塞进视觉语言模型里编码,然后做对比学习,让匹配的查询-文档对在向量空间里靠得近一点,不匹配的推得远一点。这一步进步很大,但天花板也很明显:这种训练方式只在"整页"这个粒度上做监督,模型知道"这一页大体上对",却从来没被明确告知"证据具体在哪个角落"。

对比学习*:一种训练方法,让模型学会把相似的东西在向量空间里拉近,把不相似的东西推远,靠正例和负例的对比来学习特征。

后来有研究者想办法引入更细粒度的信号。一部分工作走"文字描述"路线,比如ReAlign这篇论文,让强力的视觉语言模型去圈出图片里的关键区域,再生成对应的文字描述,把这些描述当作辅助监督信号。另一部分工作走"局部区域"路线,比如ColPali,用多向量交互的方式去捕捉页面局部语义,或者像Argus-Retriever那样直接对齐视觉区域特征。

这两条路子各有各的硬伤。

文字描述听起来省事,但你试着用语言去描述一张复杂的柱状图或者地图色块试试,很多视觉结构根本没法用一句话说清楚,尤其是空间关系、颜色编码这种东西,语言天生就笨拙。而纯粹的局部视觉区域呢,抠得再准,也丢失了页面级别的全局语境,比如那个数字到底属于哪一年、哪个国家、哪份报告,这些上下文信息往往藏在页面的其他角落。

这就好比你去医院拍了张CT片,一个方案是让放射科医生写一份文字报告告诉你哪里有问题(描述准确但细节会丢),另一个方案是直接把片子上那块阴影抠出来给你看(细节保留了,但你根本看不出这块阴影和其他器官的关系,也不知道它意味着什么)。要是不把两者结合起来,你要么得到一份读不懂全貌的抽象报告,要么得到一张没有上下文的孤立截图,两种都没法真正帮你做判断。

论文作者们琢磨的方向是:能不能不用文字,也不直接依赖裁剪出来的视觉区域,而是让模型自己学一种介于两者之间的"隐藏表示"?这就是ConceptFormer的核心思路。

核心设计一:让AI自己算出"这道题需要多少概念token"

ConceptFormer这个名字里的"概念",指的是一种叫做潜在概念*的东西。

潜在概念(Latent Concept):不是人类能读懂的文字,也不是直接的图像像素,而是模型内部生成的一串连续向量,专门用来表示"回答这个问题需要哪些证据"。它是一种中间表示,架在查询和文档之间。

这套系统的训练分成两步走,第一步是先搞清楚"这道题到底需要多复杂的证据"。

具体做法是这样的:训练时,先用一个很强的视觉语言模型(论文里用的是Qwen3.6-Plus)当"证据侦察员",给它一个问题和对应的正确文档页面,让它去定位真正相关的视觉区域,输出的是带坐标的边界框,外加一句话描述这个区域为什么相关。

Matryoshka表示*:这里指一种自适应容量分配思路,灵感来自俄罗斯套娃玩具,模型可以根据实际需要动态调整表示的"大小",而不是所有样本都用同一个固定尺寸。

拿到这些边界框之后,ConceptFormer干了一件挺聪明的事:它不是直接把这些框当成最终答案,而是把这些框投影到检索模型自己的视觉token网格上,也就是说,检索器把一张图片切成多少个小方块(patch),这些边界框覆盖了多少个方块,就统计出多少个方块。覆盖的方块数量加起来,就是这道题所需要的"潜在概念长度"。

这里有个细节特别值得说一说:不同的检索器骨干网络,切图片的方式是不一样的,有的切得细,有的切得粗。所以ConceptFormer没有用一个放之四海而皆准的固定数字,而是根据具体使用的检索模型的切图方式来算,这样保证了这套容量分配机制是"量身定制"的,而不是拍脑袋定的。

论文里给出的实际统计数据挺有意思:超过一半的样本只需要不超过64个概念token,中位数是50个。但分布有个长尾,15.1%的样本需要129到256个token,7.9%的样本甚至需要超过256个,第90百分位数达到224。

这组数字说明什么?说明查询相关的证据规模差异极大,根本没有一个"万能长度"能覆盖所有情况。简单的事实类问题可能几十个token就够了,但如果问题涉及跨越图表多个区域的比较,或者需要读懂一整张地图的色块分布,需要的容量就会翻好几倍。

这就好比你去银行办业务,有人只是来问一下取款机在哪儿,一句话就能解决,有人是来处理一笔跨境遗产继承的复杂手续,可能得排一整天的号、填十几张表。如果银行非要规定"每个人办业务必须占用固定15分钟窗口",那简单业务会造成资源浪费,复杂业务又根本办不完。ConceptFormer做的事情,本质上就是让"办事窗口"的时长跟着"业务复杂度"走。

论文里专门做了个对比实验来验证这个设计到底有没有用。他们把概念长度固定成8、16、32、64、128、256这几档,分别训练模型,结果发现固定长度的表现始终不如自适应分配,固定256个token时NDCG@10是74.24,而自适应分配达到了75.97。更关键的是,固定长度增加token数量并不会带来单调提升,说明简单粗暴地"给更多空间"不是答案,关键是给对空间。

核心设计二:概念不是描述文档,而是学着模仿"提问者的排序偏好"

算出了容量之后,第二步就是真正去"训练"这些潜在概念token,让它们学会承载有用的信息。

具体流程是这样的:ConceptFormer往检索器的输入里塞进一串特殊的占位符token,都用同一个标记`<|lcon|>`表示,长度就是刚才算出来的那个数字。然后让检索器自己,基于查询、正确文档、还有一个起始标记`<|lcon_start|>`,逐个生成这些token对应的隐藏状态。生成完之后,把这些隐藏状态做个平均池化*,压缩成一个统一的"概念表示"。

平均池化(Mean Pooling):把一串向量取平均值,压缩成一个向量,常用来把多个token的信息汇总成一个整体表示。

问题来了:这个概念表示学出来之后,怎么知道它学得对不对?总不能拿人工标注去逐个比对。

论文给出的答案挺巧妙,叫做排序蒸馏。原本查询本身可以计算出一个"文档排序偏好分布",也就是说,用真实的查询向量去跟一批候选文档比对相似度,得到一个概率分布,这个分布告诉我们哪篇文档最该排第一。现在把查询换成刚才生成的那个概念表示,也能算出一个类似的排序分布。ConceptFormer要求这两个分布尽可能接近,用的是KL散度*来衡量差距,让概念表示学会去"复现"查询本身的排序行为。

KL散度(KL Divergence):一种衡量两个概率分布差异程度的数学工具,数值越小说明两个分布越接近。

这里有个很关键的对照实验,论文里专门测试了一种"对比学习版本"的替代方案,叫Query-Concept Matching,直接让概念表示去跟正确文档做对比学习,而不是去模仿整个排序分布。结果显示,用排序蒸馏(对齐分布)的方式比直接对比学习的效果更好,平均NDCG@10从75.15提升到75.97。这说明什么?说明"学会模仿一整套排序逻辑"比"单纯记住谁是正确答案"要学到更本质的东西。

这就好比培养一个新人接待员,你可以只告诉他"这个客户该被优先接待"(对比学习式的单点标注),也可以让他跟着一位资深接待员实习一整天,观察她是怎么给二十个客户排优先级的(排序蒸馏)。前者他记住的是孤立的个案,后者他学到的是一整套判断逻辑,能推广到没见过的新客户身上。如果只教孤立的正确答案,遇到没标注过的边界情况,新人就会懵。

论文还做了一个对比,把这套"潜在概念"跟另外两种替代方案摆在一起比较:一种是纯文字描述的概念代理,另一种是直接聚合视觉区域特征的概念代理。结果很清楚,纯视觉聚合的效果最差(平均72.81),纯文字描述效果次之(平均74.85),而ConceptFormer的潜在概念表示效果最好(平均75.97)。有意思的是,文字描述比纯视觉聚合效果好,论文的解释是,文字化的表述提供了更有信息量的语义监督,比直接堆砌视觉特征更有效,但这两者都比不上模型自己学出来的连续潜在表示。

三维视角下的概念空间:潜在概念到底强在哪

为了更直观地展示这套潜在概念到底好在哪儿,论文设计了一套三维评估体系,从三个角度衡量一个表示的质量。

查询区分度*:衡量一个表示能不能把匹配的查询和不匹配的查询分开。

页面区分度*:衡量一个表示能不能把正确的文档页面和错误的页面分开。

检索对齐度*:衡量一个表示引导出来的文档排序,跟原始查询引导出来的排序有多接近。

论文用这三个指标分别评估了视觉概念代理、文字概念代理、和ConceptFormer的潜在概念,在ChartQA、SlideVQA、InfoVQA、Wikimedia Maps四个数据集上画出了对比图。

结果很一致:视觉概念代理保留了细粒度的视觉定位能力,但在查询区分度和检索对齐度上表现较弱。文字概念代理能捕捉更高层的语义抽象,但在图像密集型的数据集上明显掉链子,比如Wikimedia Maps这种地图数据集,地理布局、空间关系、色块编码、分散的文字标签,这些东西没法靠一句话描述完整传达。而ConceptFormer学出来的潜在概念,在这三个维度上都稳定地表现更强。

这说明一件事:潜在概念不是简单模仿视觉或者文字中的任何一种代理,而是把局部视觉证据、查询语义、页面级上下文信号,整合成了一种全新的、专门为检索这个任务优化出来的表示形式。这就像一个真正的双语翻译,不是把一种语言逐字替换成另一种语言,而是理解了意思之后,用最适合表达场景的方式重新组织语言,有时候会带出原文里都没有直接说出来的言外之意。

实验结果:数字说话

说了这么多设计思路,最终还是要靠数据检验。论文在六个视觉文档检索基准上做了系统评测,包括InfoVQA(信息图表,作为域内测试)、ChartQA(图表)、SlideVQA(幻灯片)、TQA(教科书表格)、OWID Charts(统计图表)、Wikimedia Maps(地图)。

| 方法 | InfoVQA N@10 | ChartQA N@10 | SlideVQA N@10 | TQA N@10 | Wikimedia Maps N@10 | 平均 N@10 |

|---|---|---|---|---|---|---|

| BM25(文本) | 68.91 | 48.88 | 73.55 | 12.73 | 3.26 | 49.27 |

| NV-Embed-v2(文本,最强) | 73.66 | 80.91 | 79.40 | 34.77 | 9.92 | 62.24 |

| DSE(视觉) | 71.36 | 82.90 | 76.15 | 39.46 | 29.01 | 65.05 |

| VDocRetriever(视觉) | 68.54 | 86.79 | 78.96 | 37.19 | 22.59 | 64.30 |

| VisRAG-Ret(视觉,最强) | 69.16 | 85.14 | 71.92 | 32.18 | 29.04 | 63.48 |

| ConceptFormer(Phi3V) | 76.41 | 88.66 | 78.56 | 39.53 | 25.89 | 67.00 |

| **ConceptFormer(Qwen)** | **79.23** | **95.79** | **82.41** | **41.30** | **61.69** | **75.97** |

这张表最扎眼的地方,是Wikimedia Maps这一列。之前所有方法在这个数据集上的NDCG@10都在30分以下,最好的VisRAG-Ret也只有29.04,而ConceptFormer(Qwen版本)直接跳到了61.69,翻了一倍还多。

为什么偏偏是地图数据集提升这么夸张?论文的解释是,地图这种文档形式,相关证据往往是空间分布的,一个色块、一段图例、一个坐标点,它们分散在页面各处,很难用一个单一的整页表示去捕捉。而ConceptFormer的自适应潜在概念,恰好是为这种"证据分散型"场景量身定制的。

综合来看,ConceptFormer在平均NDCG@10上,相较于最强的视觉检索基线(VisRAG-Ret)提升了16.7%,相较于最强的OCR文本检索基线(NV-Embed-v2)提升了22.1%。而且这个提升不只是靠换了更强的骨干网络堆出来的,论文特意对比了Phi3V和Qwen两种骨干版本,发现即便用相对较弱的Phi3V骨干,ConceptFormer依然比现有最强视觉检索器高出约4个百分点,说明这套框架本身的设计就在起作用,而不只是"用了更大的模型所以更强"这么简单。

案例现场:AI到底在看哪里

论文里还放了一个很直观的案例,问题是"2011年世界杯半决赛新西兰队的比分是多少",答案藏在一张圆形图表里。

要回答这个问题,模型得同时抓住两类线索:页面顶部写着"ICC Cricket World Cup 2011",提供了事件背景;而圆形图表的中心区域,藏着具体的分数数字。

论文对比了四种方法在这张图上的注意力热力图。只用传统对比学习训练的模型(InfoNCE),注意力散得到处都是,新西兰这个放大区域被激活了,圆形图表的一部分也被激活了,页面边角的一些无关元素也被激活了,但它没能把"2011年世界杯"这个背景信息和"具体分数"这个局部证据真正联系起来。只用文字对齐训练的版本,对新西兰周围的文字线索反应更强,但对顶部的年份和赛事背景反应较弱。只用视觉对齐训练的版本正好相反,抓住了顶部的标志和年份,但对图表里那个小小的分数数字反应很弱。

而ConceptFormer给出的注意力信号明显更均衡,同时响应了顶部的赛事年份区域和中心图表里新西兰的半决赛得分区域。

这个案例说明的道理挺直白:真实世界的问题往往需要"跨区域拼图",一个信息点单独看没有意义,得配合另一个区域的背景信息才能确认答案。就像你拼一幅拼图,光有中间那一小块图案,你不知道它属于哪片天空的哪个位置,只有把边缘的拼图块也放对了,中间那块才有意义。ConceptFormer的潜在概念机制,恰恰是在训练过程中被要求同时兼顾这种局部证据和全局背景的绑定关系。

写在后面

读完这篇论文,最让我停下来想的一个细节,是那个"潜在概念长度"的分布图,中位数50个token,但有7.9%的样本需要超过256个。这个长尾分布本身就是个很有意思的信号:它说明"文档理解的难度"这件事,压根不是均匀分布的,绝大多数问题是简单的,但总有一小撮问题复杂到需要几倍的资源去处理。这跟很多现实世界的资源分配问题结构上很像,比如城市里大部分交通拥堵是常规级别的,但总有极端天气或者事故导致个别路段需要调用几倍的应急资源。

另一个值得琢磨的地方是,论文发现"纯视觉聚合"效果反而不如"纯文字描述",这跟直觉可能有点反着来,你可能觉得既然最终要处理的是图片,直接聚合视觉特征应该更"原汁原味"才对。但实验说明,视觉特征如果没有经过某种语义层面的提炼,噪声太大,反而不如先做一次语言层面的抽象过滤。这提示了一个更普遍的道理:多模态信息融合,未必是"越原始越好",有时候中间的一层转译恰恰是必要的降噪步骤。

这套框架目前还有一个没细说的边界:训练阶段依赖一个很强的视觉语言模型(Qwen3.6-Plus)去当"证据侦察员",如果这个侦察员本身判断错了区域,整个容量分配和后续训练都会跟着跑偏。这个环节的稳健性,论文里没有做专门的错误分析,倒是个值得继续追问的地方。

Q&A

Q1:ConceptFormer是什么?

A:ConceptFormer是一种视觉文档检索框架,核心思路是让AI模型学习一种叫做"潜在概念"的中间表示,把查询相关的证据用连续向量而不是文字或裁剪图片来表达,从而更准确地在文档图片里找到跟问题相关的内容。

Q2:ConceptFormer和传统的OCR文本检索有什么区别?

A:传统方法先用OCR把图片转成文字再检索,容易丢失图表、地图、排版这类非文字信息,而ConceptFormer直接处理文档图片本身,并且额外引入了自适应的潜在概念机制,能捕捉到OCR压根抓不住的视觉结构,实验显示平均检索效果提升了22.1%。

Q3:ConceptFormer为什么要动态调整潜在概念的数量,而不是用固定长度?

A:因为不同问题需要的证据复杂度差异很大,简单问题可能几十个token就够了,复杂的跨区域比较问题可能需要两百多个token。论文实验证明固定长度的效果始终不如根据具体证据覆盖范围动态分配的效果好。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-