日本研究者如何打造一把能公平衡量所有"搜索引擎大脑"的天平？——HAKARI-Bench评测体系全解析

这项研究由独立研究者田野雄一（Yuichi Tateno）完成，以预印本形式发表于2026年6月，论文编号为arXiv:2606.22778，感兴趣的读者可通过该编号查询完整论文。

**研究概要：当"找东西"这件事变得越来越复杂**

每天你都在用各种"找东西"的工具——搜索引擎、智能客服、AI问答助手。这些工具之所以能准确找到你想要的内容，背后都依赖一种叫做"文本检索模型"的技术大脑。这个大脑的工作原理，有点像图书馆里一位经验丰富的管理员：你说出你的需求，它迅速从数百万本书中找出最相关的那几本。

但随着AI技术的飞速发展，这样的"图书馆管理员"越来越多，种类也越来越复杂。有的擅长处理英文，有的精通多种语言；有的专注于代码搜索，有的善于处理医学文献。面对这么多候选者，我们怎么公平地评估它们谁更厉害？过去的做法是给它们做一套庞大的考试——每次考试动辄包含数百万道题，耗时极长，成本极高，普通开发者根本无法频繁使用。

更棘手的问题是，在实际部署这些"管理员"时，我们经常需要做出取舍：是用原始的完整版本，还是把它压缩一下节省空间？是保持全精度运算，还是降低精度换取速度？这些"节能模式"下的性能表现，几乎没有人在同一套标准下系统地比较过。

正是为了解决这些问题，田野雄一构建了一套名为HAKARI-Bench的轻量级评测基础设施。"HAKARI"来自日语中"秤"（はかり）这个词，寓意公平称量、精准比较。这套系统把现有的各类大型评测题库精心压缩成小型"纳米题集"（Nano-sets），覆盖35个基准测试集、551个检索任务、43种语言，并能在同一条件下同时评估五大类检索技术方案，还能统一比较各种"节能压缩"配置下的性能变化。最令人印象深刻的是，这套轻量化工具产出的模型排名，与原始大型评测的相关性高达Spearman 0.97以上——换句话说，用这把"小秤"称出来的结果，和用"巨型工业天平"称出来的几乎一样可靠。

---

**一、为什么我们需要给"图书馆管理员"打分？**

回到那个图书馆的比喻。现代AI系统里有各种各样的"管理员"，它们的工作方式大相径庭。有的管理员靠关键词匹配（这就是传统的BM25方法，类似于按书名索引查书）；有的管理员把每本书提炼成一段"语义摘要"，通过比较摘要的相似度来找书（这是稠密检索，也叫dense retrieval）；有的管理员则维护着一张超大的关键词权重表，对稀疏出现的专业词汇特别敏感（这是稀疏检索，SPLADE系列模型）；还有一种高级管理员不满足于整体摘要，会逐词逐句仔细比对查询和每本书（这是后期交互，ColBERT系列）。此外还有一类专门的"复审官"——它们不负责从海量书库中初步筛选，而是拿到初步候选名单之后再仔细精读、重新排序（这就是重排序器reranker）。

这五种角色在真实的搜索系统里各有分工，有时候单独使用其中一种，有时候组合使用。但过去大多数评测体系要么只关注某一类，要么虽然都覆盖了，却用不同的规则来评判它们，就像用不同标准的卷子同时考不同的学生，结果根本无法横向比较。

BEIR这个由德国达姆施塔特工业大学等机构联合提出的评测基准，是第一个尝试用同一套规则来同台比较这五类检索方案的框架，成为了业内的重要参考。之后MTEB（大规模文本嵌入基准）和MMTEB（大规模多语言版本）进一步扩展了评测的广度，覆盖了数百种语言和500多个任务。然而，这些系统都有一个共同的痛点：太重了。跑一次完整评测需要消耗大量计算资源和时间，开发者在日常调试模型时根本不可能频繁使用。而且，当你想测试"如果把这个模型的向量维度从1024压缩到256，性能会损失多少"这类问题时，现有框架几乎没有统一的答案——每个模型团队各自测各自的，结果无法直接比较。

NanoBEIR是一个方向正确的先驱——它把BEIR的每个数据集压缩成约50个查询和最多一万篇文档的小规模版本，大大降低了评测成本。但NanoBEIR仅限于英文领域，也没有系统性地覆盖维度压缩和量化等效率配置的评测。HAKARI-Bench的核心野心，正是在继承这些前辈优点的基础上，把这把"秤"做得更大、更全面、更公平。

**二、这把"秤"是怎么造出来的？**

造一把好秤，首先需要设计好刻度盘，其次需要确保每次称量的条件完全一致，最后需要验证这把秤的读数和"标准秤"有多大偏差。HAKARI-Bench的设计思路完全遵循这三个原则。

刻度盘的设计，体现在纳米题集（Nano-sets）的构建方式上。研究者从现有的大型评测数据集中抽样，每个任务保留约50到200个查询、约1000到1万篇文档。这个压缩比例颇为激进，相比原始数据集动辄数十万篇的文档规模，缩减了几个数量级。具体的抽样方法是：先从原始数据集里挑选最多200个不重复的查询，每个查询至少有一个已知相关文档；然后把所有被选中查询的相关文档全部保留；剩余的文档配额，优先填入"已知不相关"的困难负样本，最后按原始顺序填满。这样构建出来的小题集，保留了原始数据集里最有区分度的部分，同时把无关的"背景噪音"尽量剔除。

确保称量条件一致，体现在候选集的设计上。这是HAKARI-Bench最精妙的设计之一，也是它能同台比较"初步筛选型管理员"和"精读复审型复审官"的关键所在。对于每个任务，系统预先用两种方式各自检索出前500篇候选文档——一种是传统的关键词匹配方法（BM25），另一种是用一个固定的通用稠密检索模型——然后把两个候选列表用一种叫做"互惠排名融合"（RRF）的方法合并，取前100篇作为最终的固定候选集。这个候选集一旦确定，就保存下来供所有模型使用。

为什么这样设计很重要？因为这意味着不同的模型在"精读复审"阶段面对的是完全相同的100篇文章，任何性能差异都纯粹来自模型自身对相关性的判断能力，而非因为候选集不同导致的基础条件差异。此外，系统还设置了一个"保障规则"：如果某个查询对应的100篇候选文档里碰巧没有任何相关文档，就强制把一篇相关文档添加到第101位。这确保了每个查询至少有一篇相关文档可以被排序，让复审型模型的评测具有实际意义。

整套系统的架构是一条清晰的五段流水线。第一段是任务规格说明，把每个数据集的来源、版本（精确到代码仓库的提交哈希值）、语言和领域类别写成声明式配置文件。第二段是统一任务格式，确保所有任务都遵循"文档库+查询+相关性标注+固定候选集"这个四元组结构。第三段是评测执行，对五大类模型以及各种效率变体统一运行。第四段是结果存储，所有运行结果以统一的模式存入数据库，包括每个查询的前100名排序、各类指标分数、数据集版本记录等。第五段是聚合与展示，结果汇总到DuckDB数据仓库，并以多维度过滤的排行榜形式对外呈现。

在这套体系中，数据集版本的精确记录是一个容易被忽视但极为重要的细节。每次评测运行都会记录使用的数据集版本（具体到Git提交哈希），这意味着即使将来数据集内容有所更新，历史结果和新结果也可以被精确区分，确保了纵向的可比性。

**三、这把秤能称什么？——五大检索家族与效率变体**

HAKARI-Bench能够评测五大类检索方案，每一类都扮演着不同的角色，就像图书馆里的不同工作岗位各司其职。

关键词匹配方法（BM25）是最古老也最可靠的方案，它像一个精通索引目录的老派图书馆员，只认书面文字，不理解语义，但在某些场合出奇地有效。稠密检索（dense retrieval）是目前最主流的神经网络方案，它把每个文档和查询都压缩成一个数百维的"语义摘要向量"，通过计算两个向量的相似度来判断相关性——类似于图书馆员记住了每本书的"内容精髓"，用感性理解来匹配读者需求。稀疏检索（sparse retrieval）以SPLADE系列为代表，它生成的是一个非常稀疏的权重向量，只有少数几个维度有非零值，这些维度对应着与文档内容高度相关的词汇——类似于图书馆员给每本书整理了一份精简的关键词权重清单。后期交互（late interaction）以ColBERT系列为代表，它不把整个文档压缩成一个向量，而是保留每个词的独立表示，匹配时计算查询中每个词与文档中最相关词之间的最大相似度之和——类似于图书馆员逐句对比读者问题和书中内容。重排序器（reranker）则是在初步候选集上工作的精读专家，它直接读取查询和文档的完整文本，输出一个精确的相关性分数，用于重新排列候选文档的顺序。

在评测具体操作上，稠密检索有一个细节值得关注：对于每个模型和每个任务，系统会同时计算余弦相似度和内积相似度，然后取两者中更高的那个分数作为该模型在该任务上的得分。这相当于给每个模型选择最适合它的"度量方式"，是一种对所有稠密模型统一适用的"上界"计算方法，能更公平地反映模型的真实能力上限。

对于效率变体的评测，HAKARI-Bench提供了一套系统化的衍生方案。维度压缩方面，系统支持对向量的前若干维进行截断，这背后的理念来自"马特里约什卡表示学习"（Matryoshka representation learning）——就像俄罗斯套娃一样，外层包含完整信息，里层的子集也能独立工作。通过截断到256维或更少，可以在保留大部分语义信息的同时大幅减少存储和计算开销。

量化压缩方面，系统支持int8量化和二值量化两种形式。int8量化把每个维度从原来的4字节浮点数压缩成1字节整数，存储空间缩减到原来的四分之一；具体做法是对语料库侧的向量做每维度的最小值/最大值标定，然后把每个浮点数映射到0到255之间的256个整数桶中，标定时刻意不使用查询侧的数据，避免对评测查询过拟合。二值量化更为激进，只保留每个维度的正负符号（1比特），把存储压缩到极致。

"浮点重打分"（rescore）则是一种两阶段策略：先用量化后的向量快速检索出前100篇候选文档，然后用原始的浮点向量对这100篇文档重新精确打分、重新排序。这种策略在生产环境中非常实用，因为存储在服务器上的通常是量化后的廉价版本用于快速初筛，而少量候选文档的精确重打分计算代价很小。

对于稀疏检索模型，系统支持对查询侧和文档侧分别独立设置"最大活跃维度数"，也就是最多保留多少个非零权重维度。查询侧的维度数直接影响搜索时的计算速度；文档侧的维度数影响倒排索引的存储大小和内存占用。通过对这两个参数的独立调节，可以精细地分析在给定延迟预算和存储预算下，最优的压缩配置是什么。

**四、551个任务的江湖——任务集的版图与分布**

HAKARI-Bench覆盖的551个任务，构成了一张极其丰富的多语言多领域地图。从语言分布来看，排名前十的语言按任务数量依次是英语（201个任务）、越南语（40个）、德语（30个）、法语（29个）、荷兰语（28个）、日语（27个）、西班牙语（26个）、泰语（24个）、韩语（20个）、阿拉伯语和波斯语（各19个），非英语任务总数超过450个。这意味着在这套评测体系里，单纯擅长英文的模型是无法获得高分的——多语言能力是衡量一个模型综合实力的重要维度。

从领域分布来看，526个任务属于自然语言类，覆盖了约6万9千条查询和超过300万篇文档；25个任务属于代码类，包含约4400条查询和超过15万篇文档。代码任务分布在5个基准测试集中，其中NanoCoIR和NanoCodeRAG是纯代码任务集，而NanoBRIGHT、NanoRTEB和NanoRARb则是自然语言与代码混合的任务集。

35个基准测试集可以大致分为五个家族。第一个家族是BEIR家族，以MNanoBEIR为代表，把BEIR的13个经典英文数据集扩展到了14种语言，总共182个任务——这是任务数量最多的单个基准，在聚合计算时为了避免它主导总排名，系统会先在每个BEIR数据集内部对14种语言求平均，再对13个数据集求平均，最终作为一个整体参与宏观平均计算。

第二个家族是官方MTEB/MMTEB家族，包括NanoMTEB-v2（10个任务，英文为主）、NanoMMTEB-v2（18个任务，多语言）以及针对各语言的专项集，如NanoMTEB-Dutch（荷兰语，27个任务）、NanoMTEB-Polish（波兰语，14个任务）、NanoJMTEB-v2（日语，11个任务）、NanoVNMTEB（越南语，26个任务）等。

第三个家族是多语言通用检索集，包括NanoMIRACL（覆盖18种语言的单语检索任务）、NanoMLDR（13种语言的长文档检索）、NanoIndicQA（11种印度次大陆语言）和NanoMuPLeR（14种语言的欧盟法律文件并行语料）。

第四个家族是长文档、指令跟随、专家领域和推理型任务，这是最具挑战性的集合，包括NanoLongEmbed（文档长度从数千到超过三十万字符）、NanoIFIR（需要理解复杂指令的检索任务）、NanoChemTEB（化学领域）、NanoR2MED（需要推理的医疗文献检索）、NanoBIRCO（复杂目标检索）、NanoBRIGHT（高难度推理型检索）、NanoRARb（把推理过程本身作为检索目标）以及法律（NanoLaw）和医疗（NanoMedical）综合任务集。

第五个家族是代码检索集，包括NanoCoIR（代码信息检索综合集，10个任务）和NanoCodeRAG（代码增强生成检索，4个任务）。

值得一提的是，不同任务集之间存在一些来自同一原始数据集的重复任务——比如scidocs、treccovid等数据集在不同的任务家族里各有一个版本，但由于两个版本的抽样方法不同，构成了不同的评测表面，因此系统选择保留而非合并这些重复任务。这种做法在等权重微观平均时可能会轻微放大这些任务的权重，但在宏观平均（每个基准测试集等权重）时影响会被有效抵消。

**五、称量结果——55个模型的全面测评**

这次评测共涉及55个模型，其中稠密检索模型33个、稀疏检索模型4个、后期交互模型6个、重排序器11个（10个传统交叉编码器型、1个大语言模型风格），以及1个BM25词汇基线。所有神经网络模型的参数规模都在10亿以下，覆盖了当前主流的中小型检索模型范围。

从总体表现来看，稠密检索模型的每基准宏观平均（乘以100后的分数，满分100）差异显著。排名靠前的基准有代码检索（NanoCodeRAG平均77.94分）、俄语（NanoRuMTEB平均74.04分）、化学领域（NanoChemTEB平均72.61分）和代码信息检索（NanoCoIR平均72.31分）；排名靠后的则是推理检索（NanoRARb平均仅22.00分）、医疗推理（NanoR2MED平均23.98分）、跨领域专利检索（NanoDAPFAM平均26.67分）和复杂目标检索（NanoBIRCO平均26.73分）。最高和最低之间相差超过50分，这个巨大的差距说明：现有的嵌入模型对于专家领域、指令跟随和复杂推理类任务仍然存在明显的短板，而这些短板只有通过多领域评测才能被暴露出来。

在稠密模型的整体排名中，按宏观平均分数排列，前五名依次是jina-embeddings-v5-text-small（64.93分）、jina-embeddings-v5-text-nano（63.80分）、harrier-oss-v1-0.6b（63.68分）、pplx-embed-v1-0.6b（63.64分）和embeddinggemma-300m（62.58分）。BM25作为词汇基线得分为50.24（宏观平均），虽然低于顶级稠密模型群，但它在所有任务上都能提供一个公平的基线参照。

**六、量化和压缩到底会损失多少性能？**

这是整个研究中最具实用价值的发现之一。研究者对所有33个稠密检索模型统一应用了int8量化、二值量化以及对应的"浮点重打分"变体，计算每种设置相对于原始浮点基准的平均性能变化。

结论相当明确。二值量化单独使用时平均损失6.50分，这是最大的性能损耗；int8量化单独使用时只损失1.95分，非常温和；二值量化加浮点重打分后平均只损失0.93分；而int8量化加浮点重打分后几乎没有损耗，仅0.09分。换句话说，int8量化配合重打分，几乎是完全无损的——存储空间缩减到四分之一，性能损失几乎可以忽略不计。

更有趣的发现是模型之间的差异性。二值量化的性能损耗在模型之间差异极大，从最小的损失2.01分到最大的损失35.79分。损耗最严重的是多语言E5系列：mE5-small损失35.8分，mE5-base损失20.7分，mE5-large损失17.9分。同样基于E5系列的bilingual-embedding-small也损失了16.2分。五个E5及其衍生模型的平均损耗约为19分，远远高于其他模型（大多数模型在2到10分之间）。

相比之下，专门针对量化鲁棒性进行训练的模型（jina-embeddings-v5系列、embeddinggemma-300m、snowflake-arctic-embed-l-v2.0、Qwen3-Embedding-0.6B）在二值量化后的损耗仅在2到4分之间。

这种差异与模型的维度大小无关，也与参数数量无关——相同维度下，mE5-small（384维）损耗35.8分，而all-MiniLM-L6-v2（同样384维）仅损耗4.4分；相同1024维度下，mE5-large损耗17.9分，而jina-embeddings-v5-text-small仅损耗2.0分。这个发现告诉我们：二值量化的鲁棒性是模型训练策略决定的，而非规模决定的。

对于维度压缩，分析结果同样令人安心。按照本地维度的比例来对齐各模型（比较截断到50%维度时的性能保留率），大多数模型在截断到50%本地维度时能保留约99%的基准性能，截断到25%时能保留约95%。最为出色的jina-embeddings-v3（本地维度1024）甚至在截断到12.5%（仅128维）时仍能保留96%的性能。

从跨模型排名的角度来看，int8量化几乎不影响排名（与浮点排名的Spearman相关系数高达0.995），int8加重打分更是完美保持排名（相关系数1.000）。二值量化单独使用时会相当大地打乱排名（相关系数降到0.937），但加上浮点重打分后又恢复到接近浮点排名的状态（0.988）。这意味着：如果你想用int8方案，直接参考浮点排行榜选模型就行；如果你想用二值方案，必须同时启用浮点重打分，才能让"好模型"依然是"好模型"。

**七、稀疏检索的压缩空间在哪里？**

对于4个稀疏检索模型，研究者专门测试了查询侧和文档侧分别独立剪枝的影响。以naver/splade-v3为例，研究者尝试了4×4=16种组合：查询侧最大活跃维度q取{8, 16, 24, 32}，文档侧最大活跃维度d取{64, 128, 256, 512}。

结果呈现出一个清晰的不对称格局。文档侧可以激进压缩：从512维减少到256维几乎没有任何损耗（保留100.6%的基准性能），减少到128维仍然保留99.1%，只有减少到64维才会造成约5.5%的损耗。而查询侧则相当敏感：从32维减少到24维能保留99.5%，从32维减少到16维就会损失约3%，减少到8维会损失约10%。

这个发现有很强的实践指导价值：你可以大胆压缩文档侧的维度来减少存储索引的大小（这是离线构建的，成本相对低廉），但在查询侧必须保守一些，因为这直接影响每次实时搜索的延迟。使99%性能保留率的"安全操作范围"是：查询侧q≥24，文档侧d≥128。选择d=256、q=24这个组合时，在几乎不损失质量的同时，既大幅压缩了索引体积，又将查询时的计算量控制在合理范围内。

**八、重排序器在什么情况下真的有用？**

重排序器的评测结果呈现出一幅复杂而有趣的图景。总体来看，在全部551个任务的宏观平均下，能够超越最佳稠密模型（jina-embeddings-v5-text-small作为重排序器在候选集上得分65.51）的只有一个：大语言模型风格的重排序器Qwen3-Reranker-0.6B，得分68.03。传统的多语言交叉编码器型重排序器（如BAAI/bge-reranker-v2-m3得分63.07、mGTE重排序器得分62.97）全部低于最佳稠密模型。

但"总体落后"并不意味着"处处落后"。当把范围限定在查询和文档都较短（查询不超过70个字符，文档不超过1000个字符）的多语言任务上时，多语言交叉编码器bge-reranker-v2-m3以宏观平均67.41分超越了最佳稠密模型（65.91分）；在同样限定条件的英文任务上，英文专用交叉编码器ettin-reranker-400m-v1以70.23分显著超越了最佳稠密模型（68.59分）。

这说明，重排序器的优势高度依赖于任务的特征。传统交叉编码器是在短查询/段落数据（如MS MARCO）上训练的，在完全匹配这种使用场景时效果出色，一旦遇到长文档、代码、复杂推理或多语言混合任务，就会大幅退步。Qwen3-Reranker-0.6B作为一个基于大语言模型的重排序器，本质上继承了大语言模型的指令理解能力，因此在长文本（长任务的z-score高达+1.62）和复杂推理场景中保持稳健，不受查询长度影响。

从每个基准测试集的角度来看，重排序器优势最大的领域在多语言任务（NanoMLDR上重排序器最佳与稠密最佳的差距高达+13.33分）。即便在重排序器整体落后的基准上，劣势通常也很小。

研究者还分析了"稠密检索模型重新评估自己候选集"的情况：当一个稠密模型对自己生成的混合候选集重新打分时，平均只能提升1.9分（不含保障规则时为1.5分）。这个提升非常微小，因为混合候选集本身已经包含了该稠密模型的检索top候选，几乎和完整语料库检索的结果相同。这也说明：混合候选集相比于纯BM25候选集，能够更公平地评估重排序效果，不会因为候选集和某种方法的"天然兼容性"而制造虚假的大幅提升。

**九、最关键的验证：这把"小秤"和"大秤"差多少？**

所有上述分析都建立在一个核心前提之上：纳米题集确实能代表原始大型评测的结论。研究者进行了三组独立的对比验证。

第一组，把NanoMMTEB-v2的结果与官方MMTEB v2多语言检索评测对比，找出两者都有完整结果的24个模型、18个共同任务。结论：Spearman秩相关系数0.975，平均秩差1.208，最大秩差仅4；基于Borda分数的Pearson相关系数0.969。

第二组，把NanoMTEB-v2的结果与官方MTEB检索v2评测对比，共同模型18个、共同任务10个。结论：Spearman秩相关系数0.983，平均秩差0.722，最大秩差仅2；Pearson相关系数0.981。

第三组，把NanoBEIR-en的结果与英文BEIR原始完整版对比，共同模型19个、共同任务13个。结论：Spearman秩相关系数0.973，最大秩差3；Pearson相关系数0.974。

三次独立对比都达到了0.97以上的Spearman相关系数，这是一个极高的数字。为了量化置信度，研究者对共同模型集进行了1万次自助重抽样，得到的95%置信区间下限分别为0.915（MMTEB）、0.912（MTEB-v2）和0.882（BEIR-en），即便是在最保守的估计下，相关系数仍然保持很高。特别值得关注的是，在MMTEB和MTEB-v2的对比中，排名第一的模型在官方评测和纳米题集评测中都是第一，秩差为零，体现了顶端排名的高度稳定性。

当然，纳米题集并非完美复制了原始评测的所有特性。从绝对分数来看，纳米题集侧的平均nDCG分数与MMTEB相比约低7分，而与MTEB-v2相比约高7分——连偏差的方向都不一致，说明绝对分数是不能跨基准比较的，纳米题集只能作为相对排名的代理，绝不能当作绝对性能的直接参照。

在典型的偏差案例中，fever_hard_negatives任务（判断一个陈述是否真实，是典型的难负样本任务）在官方版本中模型得分范围是27.5到92.9分，而在纳米版本中却是74.1到99.1分——不是因为变容易了，而是因为候选池的设计和语料库规模的变化使得区分度被压缩到了高分段。这是纳米题集设计的一个已知局限，研究者在论文中坦率地指出了这一点。

**十、实际场景下，如何用这把秤做决策？**

HAKARI-Bench最终的价值，不是告诉你"哪个模型最厉害"，而是帮助你回答"对于我的具体需求，哪个模型最合适"。研究者通过几个具体场景展示了这套体系的实用价值。

在多语言语义搜索场景下（以NanoMIRACL为代表，短查询配短段落，18种语言），整体排名第10的BAAI/bge-m3在这个场景里是38个第一阶段检索系统里的第一名，整体排名第15的multilingual-e5-large排第3名。这些模型正是为多语言语义搜索场景特别优化的，而且在这个场景里表现出了与顶级通用模型同等甚至更好的效果。

在长文档检索场景下（NanoMLDR平均文档长度5000到28000字，NanoLongEmbed文档长度高达30万字以上），整体排名第24的BM25在两个场景中都是第1名。原因清晰：许多稠密检索模型有最大输入长度限制，当文档过长时相关段落就被截断了，而BM25没有这个限制，能完整匹配全文。在稠密模型中，专门针对长上下文训练的Qwen3-Embedding-0.6B在NanoLongEmbed上排第2，在NanoMLDR上排第4，是这个场景下最优秀的稠密方案。

在日语专项场景下（NanoJMTEB-v2），整体排名第28的日语专用模型cl-nagoya/ruri-v3-310m是第1名，远超整体排名靠前的通用多语言模型。这再次说明：当目标语言有成熟的专用模型时，通用模型的全面领先并不能延伸到该特定语言场景。

在英文BEIR场景下（限定为MNanoBEIR里的13个英文任务），后期交互方案（ColBERT系列）的表现令人瞩目：lightonai/ColBERT-Zero以67.97分位列第1，lightonai/GTE-ModernColBERT-v1以67.47分位列第2，均超过最佳稠密模型的66.97分。前12名中有5个后期交互模型，稀疏检索模型naver/splade-v3也排在第13位，跻身前四分之一。这些都是在英文精确匹配任务上的专长体现，在多语言全任务集上则因为语言范围限制而排名靠后。

**十一、这把秤的局限性——研究者自己怎么说？**

研究者对这套体系的局限性相当坦诚。

纳米题集压缩了检索空间（约1万篇文档 vs 原始的数十万至数百万篇），这使得一些碰巧相似但不相关的文档不太可能出现在候选集里，从而让任务整体变得比原来容易。因此，二值量化等设置的性能损耗在纳米题集上可能比在真实大规模语料库上偏乐观——量化的影响在小语料库里更容易被弥补。

由于每个任务的查询数量只有50到200个，单个任务的统计误差较大。研究者通过2000次自助重抽样计算了宏观平均的95%置信区间，半宽平均为±2.1分，最大±2.3分。具体到排名稳定性：排名第1的模型从未在2000次重抽样中跌至第2，说明前几名的差距足够大；但排名2到4的模型彼此之间差距约0.1分，排名交换概率高达31%到45%。结论是：宏观平均分差低于1分的排名差距，不应该被认真对待。

固定候选集的设计，虽然确保了公平比较，但也带来了一个问题：重排序器的评测建立在"每个查询至少有一篇相关文档在候选集里"这个保障规则上，这不等于真实双阶段检索中的情况——在生产环境里，第一阶段检索可能完全漏掉所有相关文档，导致重排序器根本无法挽回。候选集里相关文档的覆盖率（约87%）和查询覆盖率（因保障规则达到100%）是两个需要分开理解的指标。

在量化评测方面，HAKARI-Bench使用的是简单的事后标量量化（int8）和符号二值量化，与生产级别的近似最近邻搜索（ANN）系统中使用的更高级量化方法（如乘积量化、优化标量量化、带理论误差界的RaBitQ等）相比，存在较大差距。真实生产系统的最终量化鲁棒性可能与这里的测量值有所不同，更精确的生产级评测属于ANN-Benchmarks等专项基准的范畴。

评测范围方面，目前覆盖的是参数规模约10亿以下的开源模型，不包含OpenAI、Cohere、Voyage等商业API模型。在数据污染方面，部分模型（如multilingual-E5明确报告使用了MS MARCO和MIRACL训练数据）在对应的纳米题集上可能存在间接的领域适应优势；更广泛的是，随着预训练语料库越来越大，测试集中的查询和文档被纳入训练数据的可能性越来越难以排除，这是整个领域面临的共同挑战，HAKARI-Bench也不例外。

最后，推理速度不在评测范围之内。研究者详细解释了原因：速度高度依赖硬件、批次大小、序列长度、并行策略以及各模型是否支持优化注意力机制等实现细节，在同一条件下公平测量所有模型的"最优速度"极为困难，不恰当的测量反而会误导选型决策。系统记录了每个模型的活跃参数数量（作为推理计算量的粗略代理）和总参数数量（作为内存占用的代理），但不提供实际延迟数字。

**十二、未来的路——这把秤还能怎么升级？**

研究者提出了三个方向的未来工作。第一是扩展评测模型范围，纳入超过10亿参数的大型公开模型和商业API模型，使排行榜更有参考价值。第二是把实验室场景延伸到大规模语料库验证，检验纳米题集上的性能差异是否能在完整语料库规模下重现。第三是改进纳米题集的构建方法，特别是针对原始数据集没有困难负样本的情况——目前这类任务用原始语料库顺序填充剩余文档，导致检索空间偏简单。如果能够引入通过第一阶段检索挖掘的困难负样本，或者使用考虑难度和多样性的文档抽样策略，纳米题集的区分度和绝对分数代表性都会提升，从而在保持排名复现性的同时，让分数分布更贴近原始评测。

---

**归根结底，HAKARI-Bench做了一件听起来简单、做起来极难的事：把一套原本需要耗费大量资源的"工业大秤"，压缩成了一把随时可用的"口袋小秤"，同时确保读数的可靠性。在这把小秤上，英文好手、多语言通才、代码专家、长文档能手都能找到属于自己的舞台，各种"节能模式"的性能代价也一目了然。对于每一个需要在复杂需求和有限预算之间做权衡的工程师来说，这套工具的实际价值远超过一张简单的总排名榜单。**

如果你希望深入了解这套体系的技术细节，包括完整的模型列表、所有任务的数据来源以及详细的实验结果，可以通过论文编号arXiv:2606.22778查阅原文，相关代码和数据集也已在GitHub和Hugging Face上以MIT协议公开发布。

---

Q&A

Q1：HAKARI-Bench的纳米题集评测结果和原始大规模评测相差多少？

A：三次独立验证的Spearman秩相关系数均超过0.97，平均秩差约1，最大秩差不超过4，说明纳米题集能高保真地复现模型排名。但绝对分数与原始评测不可比——同一套纳米题集相对MMTEB偏低约7分，相对MTEB-v2偏高约7分，连偏差方向都不一致，因此只能用于排名参考，不能直接对比分数数值。

Q2：int8量化和二值量化对检索性能的影响有多大？

A：int8量化平均仅损失约1.95分，加上浮点重打分后几乎无损（仅0.09分），可视为"几乎免费"的存储节省手段。二值量化单独使用平均损失6.50分，但模型差异极大，multilingual-E5系列损失高达17到35分，而专为量化鲁棒性训练的模型仅损失2到4分。加上浮点重打分后大多数模型都能恢复到接近浮点性能的水平。

Q3：重排序器（reranker）在什么情况下比稠密检索模型表现更好？

A：在短查询配短文档的多语言语义搜索场景下，多语言交叉编码器型重排序器（如bge-reranker-v2-m3）明显优于最佳稠密模型；在短英文任务上，英文专用交叉编码器ettin-reranker也有明显优势。但在覆盖代码、长文档、复杂推理等多样化任务的全任务集上，传统交叉编码器普遍低于最佳稠密模型，只有基于大语言模型的Qwen3-Reranker-0.6B因其指令跟随能力而超越。