Benchmark选模型？别被厂商的“最优”数据忽悠了

这个帖子真的说到我心坎里了。我最近也在纠结模型选型的问题，正好想请教一下。你提到的LiveCodeBench和AIME的数学推理分数，我理解它们更贴近真实逻辑验证，但像SimpleQA这种低幻觉率的指标，具体怎么测出来的？是自己搭测试集还是有什么公开的评测框架可以复现？我最近在搞一个知识库问答的场景，特别怕模型胡编乱造，但厂商给的报告里幻觉率都标得特别低，实际一测就露馅。

还有，你那个代码补全项目后来怎么收场的？是换了模型还是做了prompt工程上的调整？我听说有些团队会在模型前面加一层规则校验，比如对TypeScript类型推断这种高频操作写死规则兜底，但这样又失去了模型的灵活性。另外，你提到Chatbot Arena的社区评分只能反映对话体验，那对于工程任务，你觉得有没有什么更靠谱的社区榜单或者用户反馈渠道值得参考？我翻过一些开源模型在GitHub上的issue区，但感觉噪音很大，不好量化。

最后想问下，你实测的那个API文档问答模型，18%的幻觉率具体是在哪些类型的问题上翻车的？是常见API的参数遗漏，还是冷门接口的文档存在严重错误？我想知道这种问题是不是通过few-shot示例就能缓解，还是说模型底子就不行，必须换基座。

这个帖子说到点子上了。SWE-bench的问题其实圈里不少人心里都有数，它测的是“从头修一个bug”这种完整链路，但实际开发里大部分时间是增量改代码，上下文依赖完全不一样。我团队之前试过几个在SWE-bench上刷到前列的模型，丢进我们的TypeScript代码库做自动补全，结果变量类型推导直接翻车，反而是某个没进榜单前三的开源模型表现更稳。

你提到LiveCodeBench防刷分，这个我赞同，但得补充一点——它更贴近真实场景的前提是任务拆解得够细。我最近在关注CodeScope和RepoBench-R1，前者专门测增量代码补全的上下文利用率，后者测的是跨文件引用推理，这两个维度对工程落地比单纯修bug更有参考价值。

至于AIME和SimpleQA的关联性，这个观察很敏锐。数学推理强通常意味着逻辑链稳定，但低幻觉率在工程场景里其实是生死线。我去年做过一个API文档问答的压力测试，某模型在SimpleQA上幻觉率12%，但一换到我们内部私有API的文档（结构更复杂），直接飙到21%。后来发现是模型对长尾实体名的泛化能力差，跟benchmark里那些常见API名完全不同。

所以现在选模型，我一般先跑个私有数据的“压力测试”——比如故意给几个模糊查询或者跨文档的链式问题，看它会不会一本正经地胡说八道。厂商给的benchmark高分只能当参考线，真正上线前得拿自己的业务场景做正交验证，特别是代码类任务，最好把模型的注意力分布可视化一下，看看它是不是真在理解逻辑结构，还是在靠模式匹配糊弄人。

这个分享太有用了，我最近也在选代码模型，之前光盯着SWE-bench看，差点踩坑。你提到的SimpleQA低幻觉率这点特别戳我，想问下你是怎么测出那18%的幻觉率的？是自己搭的测试集还是有现成的工具？另外，除了这几种benchmark，有没有什么更轻量的方法能快速筛掉不靠谱的模型？