Ken W Alger 在 dev.to 发了篇《Nothing Reported It》，10 月 22 挂出来，30 号又更新过一版。
光看标题我以为是本地跑小模型的常规记录——Raspberry Pi 4 加 Ollama，两个小模型，消息路由、信息抽取、文档问答三个工作流，95 个测试用例。这些都不是重点。他自己开头就交了底：同一个周末在测试框架里挖出五个缺陷。
我对他后半句没太上心，是读到 urllib 吞响应体那段才确认值得点。第一次抽取跑到第 7/30 个用例就撞上 Ollama 500，urllib 的 HTTPError 把响应体整个吞了，光一个 500 什么都不给你看。得手动 e.read() 才能看到真正原因：模型因为 token 重复上限被中止了。这个坑不点原文看不到，多数人看到 500 会直接当网络抖动重试。
先讲那个最扎眼的数字。360M 在 50 条消息里，43 条选了升级人工。剩下 7 条里 3 条 confident wrong，得分 3。1.5B 正确率 46%，这个指标得分 26。换成人话就是：一个几乎不干活的模型，指标反而显得更安全。
原因只有一条——作者定义 confident wrong 时没把升级人工算错。升级人工不算错，那升级越多当然越安全。这不叫 bug。这就是评分器在奖励逃避。
grounded QA 也一样。15 道题，4 道没有答案。1.5B 对其中 13 道回答“材料里没有答案”，于是 4 道无答案题拿了 4/4 满分。模型什么都没答，评分器觉得它全对。作者管这个叫同类奖励安全失败——你拿不回答对付无答案题，评分器会发奖状。
keyword check 更不行。它只检查参考答案里任意词有没有出现在回复里。一次无效运行里，两个模型都只命中 1/11。唯一命中的词是 reservation，出现在一条把正确费用 40 美元写成 100 美元的回复里——词命中了，答案是错的。修完语料后，这个检查给 1.5B 打到 11/11。人工读一遍，只有 9 题真对，其中一题算术还是错。作者最后把 keyword check 标成弱下界，原话大意是它答案差时偏悲观、答案好时偏乐观。
这一步值回点击。知道自己手里的检查器什么时候在骗你，比换一个更准的检查器重要。
速度衰减检测那段我也记了。Raspberry Pi 4 热降频，作者写了个检测比较一次运行前三分之一和后三分之一的生成速度。第一次跑出来从 4.3 到 7.6 tokens/s，检测报告 steady。后来发现那个数字来自 eval_duration，不是墙钟。再一查，报告的 tokens/s 和 n/((n-1)t) 吻合——eval_count 记了 n 个 token，eval_duration 只覆盖约 n-1 个间隔，短答案会被高估。那次运行 token 间隔约 0.26 秒，基本平坦，所以加速是假的。本地模型测吞吐，短输出基本没法信。
但我最想说的是缺失语料。语料加载函数在 glob 没匹配到时返回空字符串，不抛异常。四份参考文档的目录从来没进仓库。于是 15 个 grounded QA 全在空参考块上跑。一个模型按指令反复回答“材料没有答案”，另一个凭训练记忆编造了一款酒。每次调用都返回 HTTP 200——服务端没报任何错，因为模型确实答了，只是答的依据是空的。
这个太阴了。我一直以为测试框架最差会告诉你“文件没读到”。它没有。它返回了 200，几百个用例照常跑。
作者还提了一个数字：中位提示只有 97 token，最大 112 token，参考文档有 447 词。这个比例不可能，本该一眼看出材料没进提示。但他当时把这个数字误读成上下文余量充足。100 出头的 token，空间还有的是。他说这是不可能的比例。数据明显不对却解释成一切正常——尤其容易发生在自己给自己写测试框架的时候。
他的总结我直接引：「警告只能说明有问题，不能说明原因。方向正确但归因错误的监控比没有监控更危险，因为它会终止继续排查。」
他原有的弃答集中度检测在无效运行里确实响了，提示 13/15 题被弃答。但他当时把原因误判成模型拒答。实际不是拒答，是模型按指令面对空材料做了正确反应。故障在更上游——语料目录整个没提交。监控响了，方向和归因都错，排查就停在一个错误结论上。这句我想抄桌上。
评论区有人问速度检测读的到底是 eval_duration 还是墙钟，并给了 13/15 的 Wilson 区间，62% 到 96%。作者确认读的是 eval_duration，还补了一组数：62.1% 到 96.3%，4/4 下界约 51.0%。13/15 的正确率，置信区间宽成这样——这点样本量撑不起任何结论。这个数字我盯着看了两遍。
作者在文末提了两个预测模板问题：这些数字要变得没意义需要什么条件成立？测试框架能不能自己提示这一点？然后他数了自己那 22 条预测——全部都在说模型会怎么答、会怎么错，没有一条关于测量代码。
这就是这篇最扎人的地方。我们搞小模型测评，预测全写在模型行为上。没人预测评分器会怎么瞎、语料加载有没有真把文件读进来、速度数据是不是 eval_duration 糊出来的。测量代码是隐形的，默认它诚实。
作者把测试框架、fixtures、已提交的预测和包含无效运行的完整记录全公开了，仓库在 github.com/kenwalger/right-size-the-model。这篇我没法顺手跑，它要的不是环境配置，是把每个输出从头到尾读一遍。
不点链接也能带走一句：跑测评之前先问自己的评分器会不会奖励弃答、奖励幻觉，甚至奖励根本没读过材料。