LLM评测如何产生可比分数：解剖一个逆向工程基准

大语言模型的排行榜数字满天飞，但很少有人追问：这些分数是怎么来的？为什么A模型的78分能和B模型的43分放在一张表里比较？答案不在模型本身，而在评测管线的设计。本文以LFORLA的逆向工程（Reverse Engineering）基准为例，拆解一套评测机制如何把杂乱的模型输出变成可比较的数字。

LLM评测基准产生可比分数的机制

可比的数字从何而来

可比性不是偶然产生的，它是一套固定管线的输出结果。原文用逆向工程基准作为范例，归纳出四个关键环节。理解这四点，基本就能看懂任何一张排行榜的可信度。

相同的提示词，相同的任务

该基准名为Reverse Engineering（Binary to Source），任务是从被剥离符号的二进制文件中还原出函数的C语言源码。模型可以选择带工具模式或无工具模式。关键在于：每个模型拿到的提示词和二进制文件完全一致，两次运行之间除了模型本身，其他变量全部锁定。这是可比性的第一块基石——如果提示词因模型而异，分数就失去了横向比较的意义。

固定且确定的裁判

评分采用确定性的token相似度比对，参照答案只保存在服务器端，不向模型展示。裁判不会即兴发挥，它比对的是token而非"感觉"。正是这种确定性，让分数在不同模型之间、不同时间之间都保持可比。换句话说，同样的答案无论何时提交，都会得到同样的分数。

词袋余弦相似度（Bag-of-Words Cosine Similarity）衡量的是两段文本在词频向量空间中的夹角余弦值：将文本拆成token集合，忽略顺序，只统计各token出现频率，再计算两个频率向量的夹角。这种方法对词汇重叠敏感，但对语序不敏感。最长公共子序列（LCS）则相反，它在保持相对顺序的前提下，找出两段文本中最长的公共token序列，对结构和顺序的匹配更为严格。将两者以60/40的比例混合，是一种在"覆盖广度"与"结构忠实度"之间的工程权衡：余弦贡献确保宽泛的词汇重叠得到奖励，LCS贡献则惩罚那些词汇相似但逻辑顺序混乱的输出。这一权重选择并无理论最优解，属于基准设计者的主观判断，原文也在局限性一节中对此作了坦承。

分轴评分的细则

单一数字掩盖了太多信息，因此该基准拆成四个维度报告：

Completeness（完整度）：提交内容覆盖参照答案token数量的比例，0到100%，越高越好。
Code Similarity（代码相似度）：混合token相似度，由60%的词袋余弦相似度加40%的最长公共子序列（LCS）比率构成。
Percent Reversed（整体还原度）：整体混合分，同样是60%余弦加40%LCS。
Function Recovery（函数恢复率）：一个二元门槛——token相似度达到或超过0.75才算通过。

这种分轴设计的价值在于，它能告诉你模型强在哪里、在哪里只是在"猜"。

Function Recovery采用的0.75二元门槛在逆向工程语境下有其特殊含义。源码函数具有强结构约束：变量名、控制流、返回类型缺一不可。一个token相似度只有0.6的函数，在编译器眼中可能已经是完全不同的逻辑。设置硬性通过线，而非给出连续分数，是在模拟工程实际——代码要么能用，要么不能用，没有"差不多能用"。这种二元设计的副作用是：它对接近门槛的模型非常不友好，0.74和0.80在分数上天壤之别，但实际能力差异可能微乎其微。阅读排行榜时，留意这类门槛往往能解释为何某些模型的综合排名与直觉预期不符。

公开的逐字记录

每一份提交都会被保留，任何人都能重新查看模型实际给出的答案。如果某个分数看起来反常，你可以直接打开那份答案，自己核对token。这正是排行榜与黑盒之间的根本区别——可审计性。

真实的分数对比

原文给出了两个模型的实测数据：

模型	提供方	分数
Nemotron 3 Ultra（免费，via opencode）	deepseek^广告	43.49
GLM 5.2（作者自己的提交）	lforla	78.0

需要说明的是，GLM 5.2是作者自己提交的条目，原文也坦承应当以与其他模型同等的审视眼光看待这个数字。

排名差距背后的含义

78分与43分之间的差距并非四舍五入的噪声，它直接反映了每个模型实际重建了多少参照源码。接近78分意味着提交覆盖了参照答案的大部分token，且在60%余弦加40%LCS的混合指标下匹配得相当紧密。而接近43分则意味着大约一半的参照内容缺失或错位。

Function Recovery这一轴更为严苛，它只在token相似度达到0.75时才触发。这意味着一个模型可能在完整度上看起来还不错，却仍然过不了这道二元门槛。各个维度合在一起，才真正勾勒出模型能力的轮廓。

从业者该如何据此选模型

不要凭一个头条数字选模型，而要看与你的工作负载最匹配的那个维度。

如果你需要完整的源码重建，重点看Completeness和Function Recovery；如果你需要紧密的token级保真度，看Code Similarity；如果只需要一个笼统的信号，看Percent Reversed。然后针对你真正关心的案例去读逐字记录。

一个在简单二进制上表现优异、却在困难样本上翻车的模型，与一个表现稳定一致的模型，完全不是一回事。平均分往往会把这种差异抹平。

读懂排行榜的五个步骤

原文给出了一套实用的核查清单：

确认提示词和裁判是否固定。如果每次运行都在变，这些数字就不可比。
先读懂各轴的定义，再看排名。混合分会隐藏权重分配。
寻找像Function Recovery这样的二元门槛，它能告诉你模型是否真的解决了任务。
至少打开一份提交的逐字记录，确认分数与答案相符。
按照契合你用例的维度去比较模型，而不是只看总排名。

诚实的局限性

原文难得地主动列出了方法的边界，这本身就是评测可信度的一部分：

Token相似度不等于语义正确性。一份提交可能token匹配，但结构上依然是错的。60%余弦加40%LCS的混合比例是一个设计选择，而非普适真理。逆向工程基准只覆盖了一类任务家族，结果不会自动迁移到其他代码或推理任务上。此处展示的排行榜只是一个快照，随着更多模型提交，分数会发生变动。

逆向工程作为评测任务有一个值得关注的特性：它的参照答案通常是唯一的（原始源码），但实际上同一个二进制文件可以由多种语义等价的C源码编译得到。token相似度比对会将这些等价写法视为错误，因为它们的token序列与参照答案不同。这是所有基于字符串匹配的代码评测都面临的根本困境，并非LFORLA独有。更严格的评测方案会将模型输出重新编译并执行，对比二进制行为而非源码文本，但这需要可执行的测试环境，工程成本远高于token比对。理解这一局限，有助于将该基准的分数定位为"文本层面的还原能力"，而非"语义层面的逆向理解能力"。

结语

LLM评测是一套机制，而非玄学。相同的提示词、固定的裁判、分轴的评分细则，再加上公开的逐字记录，才是把原始答案转化为可比数字的四根支柱。对于任何想认真解读模型能力的人来说，比起盯着排行榜顶端的名次，理解这套机制、学会按维度拆解分数，才是更可靠的判断方式。