做个盲测。
给你 1000 份乱糟糟的文档，有扫描件、有 PDF、有表格、有图表，有中文有英文有日文。现在你问一句「这份合同里违约金是怎么算的」，模型要找出最相关的那一页。
传统做法是什么？先跑 OCR 把图片转成文字，切块，向量化，进向量库。
问题来了。OCR 一跑，表格的行列结构没了，图表的标题位置跑了，扫描件歪着的文字识别率直接打折。你折腾半天建好的索引，搜「违约金」还行，搜「这个数怎么来的」就抓瞎，因为关键信息可能在一个歪着扫描的截图里。
腾讯的答案很干脆：别 OCR 了，直接拿图片检索。
把文档当图片扔进去
EVIE-Preview-4.5B 是腾讯 8 月 17 日在 Hugging Face 开源的多语言视觉文档检索模型，4.54B 参数，Apache 2.0 协议。
它的思路很简单：不做文字提取，直接把文档页面和用户查询都变成向量，在向量空间里比相似度。
具体来说，模型用 Qwen3.5-4B 做 backbone，采用 ColPali 风格的晚期交互机制（Late Interaction）。查询和文档各自编码成大量 token 级的小向量（每 token 128 维），而不是压成一个大向量。「晚期」的意思是两边向量先独立生成，到最后比对阶段才做交叉注意力，保留了更细粒度的匹配能力。
这样做有个直接好处：表格、图表、扫描件的布局信息全部保留，不需要 OCR 识别文字，不需要知道图表画的是什么。
跑分党狂喜
ViDoRe V3 是一个看文档检索能力的基准，EVIE-Preview-4.5B 目前的成绩是 65.36 分，排名第一。
这里有个有意思的点：排第二的 webAI-ColVec1.1-8B 有 8.4B 参数，比 EVIE 大了将近一倍，分是 65.32，差 0.04，几乎一样。
也就是说，EVIE 用更小的参数跑出了和更大模型相当的检索效果。
背后原因可能是晚期交互机制本身对细粒度匹配更友好，以及训练数据质量（80 万组高质量图文对，多语言覆盖）。模型用了硬负例挖掘，负例还要经过大多模态模型的裁判判断才进损失函数，训练策略上下了功夫。
索引体积很友好
128 维的 token 向量是个折中：比 640 维的竞品小了不少，但维度又不是太低，保持了匹配精度。
官方给的数据：100 万页文档的索引体积约 180GB。
对于想在本地跑文档检索的个人开发者或中小企业来说，这个体积可以接受。
不过需要注意：EVIE 是个检索模型，不是阅读理解模型。它只负责找到最相关的那一页，后面的答案提取要另接一个阅读模型完成。检索 + 阅读才是完整 pipeline。
多语言覆盖意外地全
英语、法语、德语、意大利语、西班牙语、葡萄牙语、中文都支持，还包括日文页面。
这对在中国市场做跨境文档检索的场景很有用，比如一份中日双语的技术文档，或者日文发票扫描件，直接用中文查询就能召回。
快速上手
Hugging Face 页面有 Chat Template，直接在页面右上角体验。也可以用 transformers 加载本地跑，BF16 checkpoint 约 8.5GB。
训练细节没有完全公开，但论文引用格式已经挂出来了，估计正式论文快了。
核心就一句话：以后文档检索不用折腾 OCR 了，直接把图片扔进去，模型帮你找。