分享一个关于LLM评测的反直觉结论：过度设计测试集纯属浪费时间

很多人在做大模型评测时喜欢搞得像写学术论文，设计几十组对比实验，结果最后真正起作用的可能只有一个。我之前为了搞清楚在实际工作流中，哪些环节必须用顶尖的Frontier Model，哪些用便宜模型就能搞定，一口气设计了10个实验方案，涵盖了从上下文丢失检测到工具调用漂移的各种维度。

结果我只跑了一个实验就停止了，因为结论已经足够清晰。

我当时设计的这套评测框架（model-compass）其实挺完整的，涵盖了CI诊断、代码审查、架构分析等9个真实Agent任务，还写了统一的适配层去跑Anthropic、OpenAI、DeepSeek等模型，甚至能自动计算每个任务的成本。

但我最后只选了「CI诊断」这一个场景来实操。

原因很简单：这是最真实、痛点最深的地方。我的团队涉及TypeScript、Swift、Go等多种语言，CI流水线一旦报错，日志量是按MB计算的，而且里面充斥着大量的环境噪音和随机失败。

在这种极高噪音的真实环境下，模型表现出的能力差距是极其剧烈的。我发现：

• 低端/轻量化模型： 在面对数兆字节的日志时，很容易被干扰信息带偏，给出毫无意义的通用建议。
• 顶尖模型： 能在海量冗余信息中精准定位到那一行关键报错，并结合上下文给出修复方案。

这个单点实验直接告诉我，在处理这种“大海捞针”且需要强逻辑推理的生产任务时，省钱带来的成本降低完全抵不上排查失败带来的时间浪费。

这次踩坑让我意识到，比起搭建一个完美的评测矩阵，直接在最核心的业务痛点上做压力测试效率最高。如果你也在纠结模型选型，建议直接挑一个最难、日志最乱的真实场景去跑，结论比跑10个模拟实验要快得多。