ZipBench：压缩大模型评测，先降低压缩本身的成本

评测集可以压缩，但挑出代表性样本往往先要积累大量模型评测日志。ZipBench 用六个真实锚点模型、合成日志和样本指纹降低这笔前置成本。本文拆解其方法、分数与排名保真结果，以及它用于 Agent 评测时的成本和误差边界。

想靠少测几道题省钱，可能得先花钱知道哪些题可以少测

大模型评测越来越像一项持续发生的基础设施开销：模型换了、推理配置改了、Agent 流程调整了，都需要重新跑一轮。

如果评测集中存在冗余，自然会想到一个办法：只保留少量代表性样本，用它们估计完整评测集的分数和模型排名。

问题是，代表性不是看题目内容就一定能判断出来的。

两道语义相似的题，可能对不同模型有完全不同的区分能力；两道内容不相似的题，也可能呈现高度重合的模型成败模式。要找到这些关系，很多基准压缩方法会先收集大量模型的逐样本评测结果，再做响应建模、聚类或样本选择。

这就需要区分两笔账：

• 后续评测成本：压缩集建好之后，每个待测模型少跑多少样本。

• 压缩集构建成本：为了决定保留哪些样本，前面需要让多少模型跑完整基准。

对于已有公开日志的 MMLU 等基准，第二笔成本可以借用历史数据摊掉。但对于新发布的基准，尤其是需要工具调用、环境交互的 Agent 任务，可能必须先跑一批昂贵的完整评测，才能获得以后省钱的机会。

ZipBench 的切入点就在这里。它不是只问“能删掉多少题”，而是问：

在没有海量公开逐样本日志的情况下，能不能用很少的真实评测记录，构建一个足够可靠的压缩代理？

这比单纯追求更高压缩率更贴近实际使用中的瓶颈。

六个真实模型提供信号，合成日志补充覆盖

ZipBench 的流程分为三个阶段：完整评测少量锚点、合成表现记录、学习样本表示并选取代表。

其中最重要的设计，是没有把“减少真实模型数量”理解成“随便找几个模型就够了”。

先让锚点尽量覆盖不同能力水平

论文默认使用六个真实锚点模型，让它们跑完整基准。作者希望这些模型的准确率尽量分散，而不是集中在一个窄区间。

得到的数据可以理解为一张响应矩阵：

• 每一行对应一个锚点模型。

• 每一列对应一个评测样本。

• 每个元素表示模型在这个样本上是否成功。

这里的“六条真实记录”指六个模型各自覆盖完整基准的表现记录，不是只评测六道题。

对于连续指标，论文先做方向统一与归一化，再利用构建阶段的锚点记录确定二值化阈值。这意味着，进入样本表示学习阶段的信号，是经过处理的成功或失败模式。

为什么锚点需要分散？因为如果六个模型能力接近，大量题目可能得到同样的响应：要么全对，要么全错。这样的矩阵很难告诉算法，哪些题在区分弱模型、中等模型和强模型。

论文附录的实验也支持这一点：更宽的初始准确率覆盖通常带来更低的 MAE 和更小的波动。真实锚点虽然少，但不能缺少能力差异。

合成的是表现记录，不是题目，也不是模型回答

第二阶段不再调用额外模型，而是组合已有二元结果。

具体做法是枚举真实锚点的不同子集，将每个子集视作一个“虚拟模型”。对每道题，按照论文定义的投票规则，把子集成员的成功或失败结果合成一个二元结果，由此得到一整行伪日志。

这里投票的是“是否答对”，不是把模型生成的答案拿来做集成推理。ZipBench 没有生成新题目，也没有训练或运行一个新的真实模型。

随后，算法把真实锚点的最低、最高准确率之间划分为等宽桶。只有当候选伪日志的准确率落入尚未填充的桶时，才将其接受，以便让表现记录在已观察区间内更均匀地分布。

这个设计的目标不是让日志越多越好，而是用廉价组合补充能力覆盖。

论文的消融显示，适量合成有帮助，但过量合成会增加冗余、稀释真实记录信号。因此，默认预算是六个真实锚点加六个合成锚点；实际搜索会受到可用候选组合的限制。

我的理解是，合成日志更像对已有行为信号的重新组织，而不是凭空获得新的观测。它能补充覆盖，但质量仍然依赖最初六个模型提供了什么信息。

不同基准与压缩率下，聚集、正态和均匀锚点准确率分布的误差对比（图片来自论文 arXiv:2609.12475）

样本指纹描述的是“怎样区分模型”，不是“题目讲什么”

拿到扩充后的响应矩阵，ZipBench 用项目反应理论，也就是 IRT，学习模型和样本的低维指纹。

其核心模型是：

其中， 是模型指纹， 是样本指纹，二者的内积决定预测成功概率。训练通过最小化响应矩阵上的负对数似然完成。

这和直接对题目文本做 embedding 聚类有一个关键区别：样本表示来自模型实际表现，而不是文本语义相似度。

说白了，ZipBench 想把“对模型产生相似区分效果”的题聚到一起。题目主题可以不同，但如果它们对各个锚点呈现相近的成功概率，就可能在评测统计上承担相似作用。

论文统一使用五维指纹，学习率为 0.1，训练 2000 个 epoch，然后对样本指纹做 K-means，每个簇选一个代表样本。作者没有逐基准调整这些训练超参数，附录实验也表明，增加指纹维度不一定改善结果，反而可能引入噪声。

还有一个容易忽略的细节：最终不是把选出的样本直接等权平均。

如果某个代表样本来自一个包含很多原始题目的簇，它应该承担更大的权重。设原始基准有  个样本，第  个簇为 ，代表样本为 ，压缩集计分采用：

因此，ZipBench 的输出不只是“题目子集”，还包含对应的簇权重。丢掉权重、直接平均，会改变论文所定义的代理分数。

实验支持的是低成本代理，而不是无损替代

作者构建了 ZipBench Zoo，覆盖 100 多个文本、多模态和 Agent 基准代理。这里更适合说“代理”，而不是把它们理解成 100 多个全新独立基准：不同任务配置、指标或版本可以对应不同代理。

评估使用未参与构建的模型，并主要观察两个指标：

• MAE：压缩分数与完整分数之间的平均绝对误差，衡量分数接近程度。

• Spearman 相关系数：两套分数产生的模型排名相关性，衡量整体排序是否保留。

这两个指标不能互相替代。分数接近，不一定意味着实力接近的模型不会交换名次；排名一致，也不意味着绝对分数没有偏差。

论文提供 small 和 tiny 两档。表 2 的平均结果是：

在 0 到 1 的分数尺度上，0.008 和 0.015 分别相当于约 0.8 和 1.5 个百分点的平均绝对偏差。但这是跨模型、跨基准的平均统计，不能解释成每次评测都落在这样的误差范围内。

表2中small与tiny的平均MAE分别为0.008和0.015，说明更强压缩需要在评测成本与分数保真之间取舍。（本文根据材料数据绘制）

tiny 用更多删减换取更低评测开销，同时牺牲了一部分分数保真度。它的平均排名相关性仍然较高，但单项结果并不全部接近 1：例如 tiny 版 MBPP Plus 和 MuSR 的 Spearman 均为 0.92。

样本缩减比例也不能直接等同于费用或墙钟时间降幅。尤其是 Agent 任务，不同样本的执行时长、工具调用次数和环境开销可能不同。论文另行报告，评测成本平均降至原始的 20%–40%；这与表中的样本缩减统计不是同一个指标。

表2汇总结果中，tiny比small删减更多样本，但样本缩减比例不能直接等同于实际费用或耗时降幅。（本文根据材料数据绘制）

另一个值得关注的实验，是把其他压缩方法也放到只有六个真实模型完整记录的条件下进行比较。ZipBench 在这一有限日志设置中表现出更低的误差和更好的稳定性。

这支持了论文最核心的主张：它适合真实日志不足的构建场景。

但不能据此扩写成“全面超过已有方法”。这些实验限制了构建日志预算，并不代表所有方法在拥有充足公开日志、不同压缩率和不同任务条件下的完整性能对比。

到了 Agent 评测，省钱空间和误差边界都要重新看

Agent 评测可能从压缩中获得较大收益，因为一次完整运行不只是生成一个答案，还可能涉及代码执行、工具调用和环境交互。

但同样的原因，也让 ZipBench 的前置成本不能忽略：没有兼容公开日志时，六个真实锚点仍然要完整跑一遍基准。

论文表中的部分 Agent 代理构建成本为零，含义是可以复用现有记录，没有新增评测支出，不是 Agent 评测本身没有成本。作者也明确要求公开记录能够对齐目标样本，并按官方指标处理；日志不兼容时，仍需回到真实锚点评测。

此外，Agent 基准不一定有很高冗余。表 2 中：

• Terminal-Bench 2.0 的 tiny 版从 89 个样本降至 50 个，缩减 43.8%。

• Toolathlon 的 tiny 版从 108 个降至 58 个，缩减 46.3%。

它们明显没有达到平均约 75% 的缩减水平。作者并未强行统一压缩率，而是根据保真度选择不同规模。

这点很关键：低成本代理不是越小越好。如果原始任务数量已经不多、任务之间差异又大，进一步删样本可能更快损失有效信号。

能力范围变化也会增加误差。论文的 OOD 实验用连续的 75% 模型准确率窗口构建代理，再测试窗口之外的模型。ZipBench 的平均 MAE 为 0.0309，高于常规 Zoo 结果中的误差水平。

它在这组比较中仍取得最低平均 MAE，但这个数字提醒我们：基于当前模型群体构建的代理，面对更强或更弱、超出构建范围的模型，保真度会下降。它不是对未来所有模型都同样可靠的固定测量工具。

理论保证有前提，实际用途也应该有分层

ZipBench 给出了分数误差与排名一致性的理论分析，但这些保证并不是无条件成立的。

分数误差界建立在 IRT 响应模型之上，与模型指纹范数、簇内样本到代表样本的最大距离有关。排名保证还依赖分数分布的密度上界等假设，分析的是期望排名相关性。

因此，理论更适合解释“为什么覆盖分散的锚点和紧凑的样本簇有帮助”，而不是证明压缩集对所有真实模型都不会出错。实际响应偏离 IRT 近似、模型能力分布改变，都可能影响保证的适用性。

同样，平均 Spearman 为 0.98，不意味着每一对模型的先后关系都能保留，更不意味着每项细粒度能力信号都没有损失。论文的局限性也明确承认，压缩子集无法保留完整基准的全部信号。

基于这些证据，我更愿意把 ZipBench 放在分层评测流程里：

日常迭代先用代理低成本观察整体变化；需要判断接近模型之间的胜负、确认小幅提升，或者检查细分能力时，再回到更完整的评测。

这不是贬低压缩评测的价值，而是把它放到合适的位置。ZipBench 真正降低的是两种门槛：后续模型少测一些样本，以及新基准不必先积累海量真实日志才能做压缩。

它提供的不是“完整评测已经不需要了”，而是“完整评测之外，可以多一个构建成本也较低的日常代理”。

原始链接

论文：https://arxiv.org/abs/2609.12475

代码：https://github.com/MilkThink-Lab/ZipBench