EVIE-8B 對比 EVIE-Preview-4.5B：以 32 倍更寬的向量換取 1.39 分的提升

在騰訊發布 EVIE-Preview-4.5B 並宣稱它是 ViDoRe 榜單上最精確的視覺文件檢索器三週後，騰訊又發布了 EVIE-8B，悄悄移動了自家 128 維模型原本立足的球門柱。EVIE-8B 是擁有 4096 維逐 token 嵌入的 8.41B 旗艦教師模型；EVIE-Preview-4.5B 則是 4.54B 的緊湊型檢索器，其賣點在於 128 維就足以擊敗體積四倍於己的模型。在 EVIE-8B 模型卡內更新後的排行榜上，EVIE-Preview-4.5B 如今在自己家族中位列第三——落後於新的 EVIE-8B，也落後於騰訊同日上午推出的學生模型 EVIE-4.5B。若你正在決定要用這兩個具名模型中的哪一個來對文件語料庫建立索引，騰訊模型卡上的數字顯示，8B 在 ViDoRe V3 上高出約 1.39 分，在 ViDoRe V2 上高出 3.36 分——但代價是每個向量要多耗費 32 倍的索引空間。本文要探討的是這個取捨是否值得，而開頭必須誠實說明：兩份成績單都出自騰訊自家，且皆未經獨立重現驗證。

簡短版本

• 如果檢索準確度是瓶頸，且你的語料庫小到原始索引大小無關緊要——規模是數千頁而非數百萬頁——而且你想要 Tencent 已發布的最佳開放檢索器，請選擇 EVIE-8B。

如果索引成本、每頁延遲或 GPU 預算確實是實際限制，請選擇 EVIE-Preview-4.5B——其 128D 向量正是它存在的全部理由，而它與 8B 之間的準確度差距，在 ViDoRe V1 上很小，在 V3 上則屬中等。

• 在你做出承諾前，先以 EVIE-4.5B 再次檢查兩者：騰訊當天釋出了一個具備運行時可截斷向量與詞元壓縮的學生模型，在效率前沿上勝過兩者；任何忽略它的比較都已經過時。

• 請將此處的所有數字都視為廠商回報的數據。EVIE-8B 尚未由騰訊以外的任何人運行過；EVIE-Preview-4.5B 的數據則來自騰訊自己的重現腳本。

它們實際不同之處

• 參數 — EVIE-8B：8.41B。EVIE-Preview-4.5B：4.54B。

• 骨幹 — Qwen3.5-9B 採用全雙向注意力；Qwen3.5-4B 則交錯採用 GatedDeltaNet 線性注意力與全注意力。

• 嵌入 — 4096維逐詞元多向量 vs 原生128維逐詞元多向量，兩者皆以MaxSim後期交互進行評分。

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

• ViDoRe V2（4 個任務，nDCG@5）— 74.23 vs 70.87。這是最大的相對差距。

• ViDoRe V3（48項任務，nDCG@10）— 66.75 對比 65.36。

• 這些標題數字背後的視覺 token 預算——EVIE-8B 的評測為每頁 1,024 個 token，而 EVIE-Preview-4.5B 的標題層級為每頁 1,792 個 token（在其 768 個 token 的訓練層級下，該預覽版達到 64.56）。

• 每 1M 頁的原始 BF16 索引——未公布 EVIE-8B 的數值；相較之下，預覽版在每頁 768 tokens 時為 179.2 GiB，在每頁 1,792 tokens 時為 420.5 GiB。

• 授權與發布 — Apache-2.0，靜默發布 2026-09-04 對比 Apache-2.0，靜默發布 2026-08-17。

上方的計分板重申了同一寫照。閱讀時請牢記兩點注意事項：EVIE-8B 欄與 EVIE-Preview-4.5B 欄來自兩份不同的騰訊模型卡，而且 8B 的頭條 V3 數字是在比預覽版頭條數字更低的每頁視覺 token 預算下測得的。

兩張騰訊卡，正在互相交談

對於這場對決，最誠實的框架是：這是一場家庭爭執，而非獨立競賽。EVIE-Preview-4.5B 自家的模型卡於 8 月 17 日發布，宣稱以 65.36 nDCG@10 取得「Rank #1 on ViDoRe V3」，領先 webAI-ColVec1.1-8b 達 0.04。EVIE-8B 的模型卡於 9 月 4 日發布，將同一個 65.36 重新列為頁面上第三佳的數字，僅次於 EVIE-8B 的 66.75 與 EVIE-4.5B 的 66.02，並顯示 8B 在八個公開的 ViDoRe V3 領域中全數勝過預覽版。這兩份評分卡都是由騰訊自家的評估工具產出，而且迄今文獻中沒有任何一個模型有獨立執行的跑分。因此，你正在讀的這份比較，是騰訊對騰訊擊敗騰訊的描述——內部一致、很可能是刻意為之，也未經任何與結果無利害關係的人驗證。

上方的 tencent/EVIE-8B 卡片是挑戰者的公開面貌：一個具備 4096D 嵌入的 8.41B 旗艦教師模型，頂部還有該系列更新後的 ViDoRe 表格。

上方 tencent/EVIE-Preview-4.5B 的卡片正是現任者的：一個 4.54B 檢索器，其原生 128D 向量與已發表的索引成本計算，仍是其最具代表性的特點。

這個1.39分的問題

ViDoRe V3上的原始差距很小——EVIE-8B的66.75與EVIE-Preview-4.5B的65.36之間僅差1.39個nDCG@10分——但這附帶一個對部署至關重要的token預算附註。EVIE-8B的評估協議將每頁文件上限設為1,024個視覺token；預覽版則需要每頁1,792個token才能達到其宣傳的65.36，而在其自訂的768個token訓練預算下僅得到64.56。就這些數字而言，8B不僅在相近預算下更準確——它在更小的預算下也更準確，而這正是每頁延遲所期望的改進方向。更大的相對優勢出現在ViDoRe V2上，EVIE-8B取得74.23，對比預覽版的70.87，在包含更難的合成文件任務的排行榜上躍升了3.36分。ViDoRe V1是歷史最悠久且競爭最飽和的排行榜，幾乎沒有變動：92.18對91.73。這種模式——在所有人都已接近天花板之處表現平淡，在任務更新也更難之處表現決定性——是真正能力提升的特徵，而非排行榜上的隨機波動，但這依然是騰訊自己的測量結果。

指數才是真正的對手

準確度只是這個決策的一半，因為這兩個模型對於你儲存的內容做出了截然不同的承諾。EVIE-Preview-4.5B 存在的原因在於其原生 128 維 token 向量：其規格表公布了精確的索引數學（在其訓練預算下，每百萬頁對應 179.2 GiB 的原始 BF16 索引；在推估擴展等級則為 420.5 GiB），並指出更窄的向量會以正比關係直接降低儲存與 MaxSim 評分的工作量。EVIE-8B 的 token 向量則為 4096 維——每個向量寬了 32 倍——而且 EVIE-8B 的規格表完全沒有發布任何索引大小數字。這個遺漏本身就是一項資訊：在相同每頁 token 數下，原始 BF16 EVIE-8B 索引大約是 preview 版的 32 倍，這使得百萬頁等級的語料庫在量化之前就落在數 TB 的範圍內，也讓這款旗艦型號變成你只會用在幾十萬頁規模的東西，而不是隨意就能大規模部署的對象。旗艦型號的寬度換來的是檢索保真度；它換不來可部署性。

騰訊當天推出的第三個選項

若要做誠實的比較，就不能只停在這兩個具名模型上，因為包含 EVIE-8B 的那次發布也包含了 EVIE-4.5B——一個從 8B 教師模型蒸餾而來的 4.61B 學生模型。它具有單一 2048 維投影，可在執行時截斷至 64、128、256、512、1024 或 2048 維；此外還有一段騰訊稱之為 HAC 的免訓練 token 壓縮流程，可將頁面的視覺 token 聚類成 32–64 個向量；而根據模型卡，每百萬頁的索引佔用空間為 3.81 GiB。在騰訊自己的表格中，EVIE-4.5B 在 ViDoRe V3 上得到 66.02 分——僅比 8B 教師模型低 0.73，比 EVIE-Preview-4.5B 高 0.66——因此它正是這個對決所提出的難題的解答。如果你想要的是「沒有 8B 索引卻擁有 8B 大部分準確度」，騰訊已經推出了那款模型，而它既不是本頁標題所指的那兩者之一。EVIE-Preview-4.5B 剩下的理由雖然狹窄但確實存在：對任何在八月部署它的人來說，它是已在生產環境使用的 checkpoint；而且其固定的 128D 設定，比一個要求你在執行時自行選擇維度的俄羅斯套娃式方案更容易理解。

您應該以哪個作為索引？

將模型與實際具約束力的條件相匹配：

• 若您正在建立準確度參考點——例如基準測試、數十萬頁的高價值法律或科學語料庫，或是一個檢索遺漏代價高昂、儲存成本低廉的系統——請在 EVIE-8B 上建立索引。您是在為該系列曲線的頂端付費，而此系列預期您日後擴展的對象是 4.5B 學生模型。

• 若你已經用 EVIE-Preview-4.5B 建立索引，且實測品質可接受，那就繼續留在這個版本——重新索引是實實在在的成本，而你想追的 V3 增益，不過是廠商數據卡上無人獨立確認過的 1.39 分而已。

• 若您正要以有意義的規模從零開始，請先評估 EVIE-4.5B。Prefix-MRL 截斷與 HAC 壓縮正是針對上述儲存算術而生，而騰訊自家的數據顯示，其效能已逼近教師模型。

這三者中沒有任何一個在包括 OrcaRouter 在內的任何平台上具備代管 API，所以無論選哪一個，檢索階段都得自架。後面的階段則不必如此。像 OrcaRouter 橫跨 200 多個模型運行的那種路由器，會把負責讀取你檢索到的頁面並撰寫答案的模型置於單一 API 之後；該 API 具備跨供應商的自動容錯移轉，供應商牌價也以 0% 加成如實轉嫁——當其上游檢索器只是個三天前才出爐、宣稱未經證實的 checkpoint 時，這正是你最需要的配置。以符合你儲存需求的檢索器建立索引，並讓管線其餘部分保持可抽換，直到 Tencent 以外有人確認這些評分卡哪一份才是真的為止。