EVIE-8B：騰訊悄然發布迄今最精準的視覺文件檢索器

三週前，騰訊的 EVIE-Preview-4.5B 是 ViDoRe 排行榜上最準確的開源視覺文件檢索器，憑藉的是騰訊自己報告的數據。9月4日，騰訊悄悄將自家排行榜榜首的那個模型換下——不是換上外部挑戰者，而是換成同一天早上發布的更大規模的兄弟模型。EVIE-8B 是一個基於 Qwen3.5-9B 骨幹、具有 4096 維每 token 嵌入的 8.41B 參數延遲交互檢索器，以權重與程式碼的形式上架 Hugging Face 和 GitHub，沒有公告、沒有部落格文章，也沒有論文。第三個檢查點 EVIE-4.5B 也在同一分鐘出現，現在位居兩者之間。與這次發布相關的每一項宣稱——分數、架構，甚至這些模型的用途——目前都仰賴騰訊自家儲存庫的說法，因為除了騰訊以外，還沒有任何人發布過關於 EVIE-8B 的任何內容。這就是目前從該儲存庫真正能得知的資訊，以及尚未獲得證實的部分。

騰訊在9月4日發布了什麼

2026-09-04，Hugging Face 上的 tencent 組織中約相隔一分鐘出現了兩個新倉庫：tencent/EVIE-8B 與 tencent/EVIE-4.5B。與此同時，一個整合後的 GitHub 倉庫 Tencent/EVIE 也一併上線，其中包含訓練程式碼、ColQwen3.5 推論引擎，以及 138 項任務的評測框架。兩個模型倉庫皆採用 Apache-2.0 授權、皆使用 colpali-engine 函式庫，且都帶有視覺文件檢索管線（visual-document-retrieval pipeline）標籤。較舊的 EVIE-Preview-4.5B（8 月 17 日發布）仍以「Preview」名稱留在 Hugging Face 上，但它已不再是該系列的旗艦版本：在 EVIE-8B 模型卡內更新的排行榜中，騰訊將自家三個檢查點列於頂端——EVIE-8B 以 ViDoRe V3 nDCG@10 66.75 居首，EVIE-4.5B 為 66.02，EVIE-Preview-4.5B 則為 65.36。

目前沒有任何公開公告。EVIE-8B 卡片的發布說明指出，權重、推論管線與評估套件皆已開源，隨後補充：「完整的技術細節、架構消融實驗與正式研究論文將在後續版本中更新」。截至撰稿當下，該 GitHub 儲存庫僅有四次提交，且沒有任何發行版本。這兩個新儲存庫目前也尚未展現出有意義的採用情形——沒有社群分支產出獨立結果，沒有第三方評估，且儲存庫公開兩天後下載計數仍接近於零。就現有證據而言，這是騰訊一次「先釋出權重、後撰寫論文」的發布，與該實驗室八月發布 EVIE-Preview-4.5B 和 UI-Mate-9B 時的低調模式如出一轍。

上述 tencent/EVIE-8B 模型卡是此次發佈的對外公開門面：一個標記為 colpali-engine 函式庫使用的視覺文件檢索檢查點，採用 Apache-2.0 授權，具備 4096 維晚期互動嵌入，而該系列自身更新的 ViDoRe 基準表則位於模型卡頂端附近。

EVIE-8B，旗艦教師

在架構上，EVIE-8B 屬於 ColPali/ColBERT 晚期交互（late-interaction）家族。它不會像單向量稠密檢索那樣，把一頁內容壓縮成單一嵌入向量——那正是有損（lossy）的做法——而是讓視覺-語言主幹網路（vision-language backbone）處理頁面影像，並保留每個 token 的多向量表示，接著用 MaxSim 運算子來進行相關性評分：每個查詢 token 在頁面所有 token 中選取最佳匹配，再將這些最大值加總為相關性分數。EVIE-8B 的具體選擇，是採用 Qwen3.5-9B 作為主幹，以完整雙向注意力運行（模型經過 encoder 化處理，因此在視覺-文字序列上會關閉因果遮罩），並為每個 token 配備寬達 4096 維的投影。寬度的意義在於保真度：空間版面、排版、圖表結構與表格關聯都能在表示中留存下來，而不是被平均化而抹除。

騰訊明確將 EVIE-8B 定位為「旗艦教師」。EVIE-4.5B 學生模型是透過騰訊稱之為 EVIE-ARD 的配方從中訓練而來——這是一種保留錨點、容量感知的關係蒸餾，可遷移 token 之間的關係拓撲，並採用難負樣本邊際監督。換言之，這個 8B 模型肩負兩項任務：為產品線設定準確度上限，以及作為輕量學生模型進行蒸餾時的品質錨點。在訓練方面，模型卡報告了 775,635 個文件-查詢配對，其中挖掘出的難負樣本會由多模態評判器重新判定：將可回答的候選提升為正樣本，將模糊不清的樣本自損失中遮罩排除，僅保留嚴格無關的頁面作為真正的負樣本。發布的「a40」檢查點本身即為兩個獨立訓練分支在 α = 0.40 下的權重空間混合。

騰訊為自己寫下的記分板

以下所有數字均由廠商回報，來自騰訊自家的模型卡，並使用騰訊在其儲存庫中提供的評測框架所產生；這些數字皆未經獨立重現，且 EVIE-8B 尚未有任何實驗室以外的人員執行過。

• 參數 / 主幹網路 — 8.41B，Qwen3.5-9B，雙向全注意力。

• 嵌入 — 每個 token 的 4096 維多向量，採用 MaxSim 後期交互。

• ViDoRe V1（10 個任務，nDCG@5）— 92.18。

• ViDoRe V2（4 項任務，nDCG@5）— 74.23。

• ViDoRe V3（48項任務，nDCG@10）— 66.75，透過逐領域掃描，該卡片聲稱在所有八個公共領域中皆獲勝。

• JinaVDR（76個任務，nDCG@10）— 83.30；在138個任務的套件中，四個任務集的宏平均 nDCG@10 — 79.51。

許可證 — Apache-2.0；權重、推論及評估程式碼均開放。

騰訊的排行榜中最有趣的一行，是騰訊擊敗騰訊的那一行。八月發布的 EVIE-Preview-4.5B 卡片宣稱以 65.36 nDCG@10 在 ViDoRe V3 上「排名第一」，略勝 webAI-ColVec1.1-8b 的 65.32。在 EVIE-8B 卡片內更新後的表格中，同一個 65.36 如今總排名第三，落後 EVIE-8B 的 66.75 與 EVIE-4.5B 的 66.02。EVIE-8B 的逐領域細項在全部八個公開的 ViDoRe V3 領域中都勝過舊版預覽——CompSci 81.86 對 80.65、Finance EN 71.23 對 70.50、Pharma 70.81 對 69.20，以此類推——平均提升 1.39 分。這項提升能否在獨立重跑中存活，正是那個待解的開放問題；但內部一致性值得留意，因為一個打不過自己學生的教師模型，若就這樣出貨未免奇怪。

上方的模型家族圖表重申了騰訊於9月4日在EVIE-8B模型卡中發布的三個檢查點排名——EVIE-8B為66.75，EVIE-4.5B為66.02，EVIE-Preview-4.5B在ViDoRe V3 nDCG@10上為65.36——其中128D預覽版讓位於4096D教師模型與Prefix-MRL學生模型。

為什麼旗艦產品不是部署模式

準確率領先者之所以被稱為教師而非預設，是有原因的。寬度會增加儲存與評分計算成本，而每個 token 4096 維度是非常寬的。在 BF16 下，一個 EVIE-8B token 向量在量化前佔 8 KiB，而一個密集頁面可以產生數百個 token 向量——該模型卡自身的評估協議將每頁文件限制在 1,024 個視覺 token。騰訊未公布 EVIE-8B 的索引大小數據，這點相當引人注目，因為 EVIE-Preview-4.5B 的模型卡對其 128 維索引公布了精確數據：在其 768 token 的訓練預算下，每百萬頁原始 BF16 索引為 179.2 GiB；在推估的 1,792 token 層級則為 420.5 GiB。向量對向量比較，EVIE-8B 的嵌入寬度是預覽版的 32 倍，因此在相同 token 預算下，原始 EVIE-8B 索引每百萬頁就會達到數 TB 等級——這還沒算上必須將它保存在 RAM 中的檢索系統。

EVIE-4.5B 於同日發布，正是騰訊預期該張力如何化解的訊號。EVIE-4.5B 是規模 4.61B 的學生模型，配備單一 2048 維投影，在執行時可截斷為 64、128、256、512、1024 或 2048 維（騰訊稱此機制為 Prefix-MRL）；此外還有一道不需訓練的 token 壓縮流程，騰訊稱之為 HAC，可將單頁約 750 個視覺 token 聚類為 32 至 64 個向量。騰訊對該模型的主打數字是每百萬頁 3.81 GiB 的索引佔用空間——這個數字與其他數據一樣，皆為廠商自行回報。整體觀之，這次發布與其說是「一個新的 8B 模型」，不如說是一個經過縝密規劃的系列：8B 模型設定天花板並訓練學生模型，而真正適合實際部署於生產環境索引背後的，是那個學生模型。

今天如何執行 EVIE-8B

EVIE-8B 僅以權重形式發布。目前沒有任何平台提供託管 API——包括 OrcaRouter——所以現階段唯一的方式是自行託管 checkpoint，並透過 colpali-engine 中的 ColQwen3.5 路徑來運行。模型卡的快速入門內容很短：以 BF16 搭配 flash-attention 載入模型、呼叫 enable_bidirectional_attention()、將頁面影像與文字查詢分別嵌入，然後用處理器的 MaxSim 進行評分。雙向步驟並不是可有可無的裝飾——已發布的 colpali-engine 預設以因果遮罩建構 ColQwen3.5，且預覽模型的模型卡記載：保留遮罩會使頂部命中 MaxSim 損失約 1.1 個點。相同的輔助函式也隨 EVIE-8B 提供。以每個參數 2 位元組的經驗法則計算，8.41B 的 BF16 checkpoint 權重約為 17 GB，因此這是「單張 GPU 且有餘裕」才能負擔的方案，而非邊緣裝置模型；而語料庫則存放在你保存索引的位置，並不在模型上。

EVIE-8B 為文件 RAG 技術棧帶來了哪些改變

對於任何在掃描檔、申報文件、圖表或表單之上建構檢索的人來說，實際的變化是：開放式視覺文件檢索的品質天花板剛剛被抬升了，而且是被抬升到一個如今橫跨三個價格效能點的產品家族之內。不過，檢索器只負責幫你取得頁面。真正讀取那些頁面並撰寫答案的模型，是另一個獨立的決策——而正是在這一層，路由（routing）才真正發揮價值：OrcaRouter 以 0% 加成、供應商列表價，在 200 多個模型之間暴露單一 API，因此你檢索器背後的閱讀模型可以在不改寫程式碼的情況下隨意替換，而任何路由模型若供應商宣布降價，當天即可生效。當檢索那一半還是全新、未經驗證的檢查點時，這種分離就更加重要——你可以採用 EVIE-8B 來做索引，同時將生成層保留在一個不會讓你被任何單一模型綁死的介面之後。

接下來要看什麼

三件事能讓這次低調的 repo 發布變成一個塵埃落定的故事。首先，獨立的驗證：在騰訊以外的人重現 ViDoRe 與 JinaVDR 的數據之前，EVIE-8B 的「排名第一」和舊版預覽的「排名第一」都只是自我申報的宣稱，而且兩者恰好互相矛盾。其次，承諾要發布的論文與消融實驗——4096 維的選擇、weight-mix checkpoint，以及蒸餾配方——目前都只是缺乏論文背書的斷言。第三，命名問題：既然 EVIE-4.5B 現在佔據了三週前 EVIE-Preview-4.5B 的位置，騰訊究竟會繼續保留「Preview」產品線，還是將其併入更名後的家庭系列，仍是未解之問。考量到發布節奏——三週內推出三個視覺文件檢索 checkpoint——比較合理的假設是，這條產品線正被大力投資，而這些低調的發布正是該實驗室在論文發表之前搶先出貨的方式。