综合榜单如何掩盖模型的高幻觉率

Hy4 在作者的对抗测试集上，有 89% 的事实声明未通过核验，却仍在综合排行榜上与 Grok 打平。两个数字看似冲突，作者想解释的恰恰是：总分相近，模型出错的方式可能很不一样。

对使用 AI 辅助编程的开发者，这篇短文的价值不在于给 Hy4 判好坏，而在于提醒我们检查两个问题：一个分数究竟统计了什么，评测程序有没有把错误漏掉。

89% 的幻觉率，到底在统计什么

原文开头把 Hy4 描述为在对抗集上有 89% 的时候编造答案，但随后给出了更准确的统计口径：他们没有按每次回答评分，而是按事实声明（claim）评分。

具体做法是，把一份回答拆成可以单独核验的最小事实声明，再逐条对照检索到的来源判断。89% 指的是这些声明中未通过核验的占比。

89% 是事实声明的核验失败率，不能直接读成 89% 的回答都是错的。

这一区别会影响读者如何理解模型表现。一段长回答可能包含许多错误陈述；如果整段只记作一次失败，就看不出它究竟错了多少、错误集中在哪里。作者观察到，Hy4 的错误往往聚集在语气笃定的长段落里，而不是谨慎回答中偶然冒出的一个错误词。

不过，原文没有提供对抗集规模、题目构成、检索来源和核验细则。因此，这个比例应限定在作者的测试设置中，也不能仅凭「核验失败」就认定每条声明都已被证实为编造。

为什么错误很多，还能与 Grok 打平

作者认为，Hy4 的特点是很快给出明确答案，并继续维护这个答案。单看准确率，读者容易忽略这种「自信地答错」的行为模式。

综合排行榜回答的是整体表现如何，逐条核验则揭示回答里的事实是否可靠。两者衡量的角度不同，出现不同观感并不奇怪。

但原文没有公布综合分的组成、权重，也没有提供 Grok 在同一口径下的事实声明核验结果。我们只能确认作者报告了「综合榜打平」，无法进一步解释 Hy4 究竟靠哪些项目抵消了失分，更不能据此判断两个模型的可靠性相当。

作者制作视频，是为了把各次运行并排展示，让读者看到失败过程。这种呈现比一个总分提供了更多观察入口，但短文本身没有附上具体案例。

一个截断错误，就让结果变动四个点

这篇短文里，比排行榜更值得开发者关注的是评测程序的缺陷。

作者发现，长回答在评分前被截断，而且被静默计为正确。也就是说，评分器没有看到完整内容，却给出了正确判定。对于错误集中在长段落里的 Hy4，这会直接扭曲结果。

作者为此把完整评测流程跑了两遍：一次使用原样交付的程序，一次使用修复后的版本。修复让 Hy4 的评测数字变动了四个点，也耗掉了作者一个周末的 GPU 时间。

原文没有说明变动的是哪项指标、朝哪个方向变化，因此不能自行写成「幻觉率上升了四个百分点」。

评测脚本如何处理不完整输出，会直接影响我们对模型能力的判断。

我的判断

作者把注意力从总分转向错误分布，这一点很有价值。对于需要核对技术事实的回答，知道模型会不会连续编造细节，往往比知道它在榜单上排第几更有用。

但逐条核验也有自己的前提：声明拆分是否准确，检索来源是否充分，评分器能否区分「没有找到证据」与「已有证据证明错误」。这些环节原文都没展开，89% 还不足以成为选型结论。

与只看排行榜相比，这种评测更容易暴露事实可靠性问题；与直接运行代码、检查实际输出相比，它又不能替代功能验证。原文没有给出这些方法之间的对照数据，也没有完整披露评测设置。关于 Hy4 出错方式的描述，目前应视为作者在这套测试中的观察。

能拿来做什么

• 阅读模型评测时，先确认统计单位是回答、题目还是事实声明，再比较百分比；遇到综合分，还要查看指标组成和权重。
• 用 AI 查询前端或 Node 技术细节时，可以把回答中的 API 行为、参数含义和兼容性结论拆开核对，避免让一段流畅的解释整体通过审查。
• 自己搭建 AI 编程评测时，要保留完整输出，并把截断或无法评分的结果单独记录；检查评测程序后，再决定是否值得重跑昂贵的测试。