上周三晚上十一点多一个技术群突然炸了有人甩出一张榜单截图配文就四个字鬼故事来了。截图上写着 DeepSeek4.1 在好几项公开测评上压过了 Opus5 和 GPT5.6群里立刻分成两派一派说这是刷分刷出来的一派说格局真要变了。我没参与吵架因为那两天正好在给手头的两个项目做模型选型干脆把这几个最近风头最劲的版本拉到同一套任务里实打实跑了一遍。这篇就是那次横评的完整记录不吹不黑只讲我在什么任务上看到了什么结果以及为什么同一个模型换个用法结论就能整个反过来。如果你也在纠结到底该用哪个或者单纯被各种榜单刷得眼花这篇应该能帮你省下几天试错时间。1. 先别急着信榜单模型更强这句话到底值多少钱每次新版本一出来最先流出来的永远是几行数字然后是一堆转发和惊叹。但我做模型选型这几年被榜单坑过的次数不算少最典型的一次是照着某项推理测评的排名选了一个模型结果上线后发现在我们的实际业务里它连最简单的字段抽取都做不稳。后来复盘才明白榜单测的是出题人关心的能力跟我关心的能力之间隔着一层翻译。这层翻译没做数字再好看也没用。所以我现在的习惯是看到任何某某比某某更强的说法第一步不是去争论而是先把这个说法拆开看看它在说什么、没说什么。1.1 榜单分数里最常见的三种水分来源第一个水分来源是训练数据污染。公开测评集的题目在网上流传太广模型训练时大概率见过类似的题面和答案模板。这种情况下它答对不代表它真的会推理只代表它记得住。判断方法其实不复杂你把题目里的数字、人名、场景换掉只保留解题结构如果分数掉得很厉害那基本可以怀疑是记忆而非能力。第二个是格式对齐带来的虚高分。很多测评最后是用另一个模型当裁判打分的而裁判天然偏好结构整齐、分点清晰、篇幅更长的回答。于是模型会被优化成更会写作文而不是更会解决问题。我见过一个模型在主观题上得分很高但只要把裁判换成规则匹配分数立刻掉三分之一。这不是模型变笨了是评分口径变了。第三个水分是只报最好那一次。同一道题跑十次总有一次运气特别好。如果只挑那一次上报任何模型都能看起来很能打。所以我现在看别人给的分数第一句话一定问跑了几次方差多少是不是固定了采样参数。提示判断一个测评是否值得参考先看它有没有公开题目、有没有说明运行次数和采样参数。缺任何一项数字都只能当参考值不能当结论。1.2 把更强翻译成三个可以动手验证的维度比起纠结谁第一我更愿意把更强拆成三个自己能测的维度。第一个是一次做对率也就是不追问、不重试、不加提示词的情况下第一次输出就能用的比例。这个指标最贴近真实使用场景因为你在线上的用户不会给你第二次机会。第二个是自我纠错能力。故意在中间塞一句错误的前提或者给一份带脏数据的内容看它是照单全收还是能指出来。这个能力在长链路任务里价值极高因为长任务出错是常态关键在于错了之后能不能被发现。第三个是稳定性也就是方差。同样的输入重复十次输出质量的波动范围有多大。波动小的模型你才敢把它接进自动化流程里波动大的模型你只能让人盯着用。这三个维度都能用很小的成本测出来不需要等任何榜单。我做横评时最先跑的就是这三项跑完基本就有感觉了后面的细节测试只是验证。2. 我那套横评流程从出题到打分讲结论之前得先讲方法不然你没法判断我的结论对你自己有没有参考价值。我这套流程搭了大概两天算不上严谨的学术测评但足够让结论站得住脚。核心就一句话让模型去做我真实工作里会遇到的活而不是去做为它设计的题。2.1 题库怎么出才不至于变成背题比赛我的题库分三块全部来自我自己的真实工作。第一块是代码任务从两个正在维护的项目里挑了十二个真实需求包含一次跨五个文件的重构、一次接口层的错误处理补齐、一次把同步调用改成异步。第二块是中文写作包括技术方案说明、给非技术同事看的科普稿、以及一份需要保持统一口吻的产品更新说明。第三块是结构化处理把乱七八糟的用户反馈抽成固定字段的表格再接一步工具调用把结果写进指定格式。关键在于这些题目从来没有在任何公开测评集里出现过而且每道题的正确答案我手里都有因为结果要么能编译、要么能跑、要么我之前人工写过。这样就绕开了污染问题。你如果是做电商、做教育或者做客服的完全可以照着这个思路出自己的题库用你自己业务的真实数据比任何公开榜单都有说服力。出题的时候有个细节容易忽略题目要可验证。写作文这种主观题你自己心里得有评分标准比如是否包含某几个要点、有没有跑题、专业术语用得对不对。没有标准的题跑完还是拍脑袋。2.2 裁判不能既当运动员又当裁判主观题怎么打分是个麻烦事。我的做法是三步走。主观性弱的部分直接用规则判定比如代码能不能编译、返回的 JSON 能不能被解析、字段有没有缺主观性强的那部分我会用另一个模型当裁判但裁判模型跟我正在比较的模型不是同一个家族避免偏袒。同时所有主观题的输出我都会自己抽看二十条以上用来校准裁判的判断是否离谱。这里有个坑我踩过早期我让裁判模型给回答打一到十分结果分数全部挤在七八分区分度极低。后来改成两两对比让裁判在 A 和 B 之间选一个更好的并说明理由区分度一下就上来了。因为模型做绝对评分时尺度很不稳做相对比较反而靠谱得多。2.3 记录方式把每一次对话都留痕这一步听起来琐碎但不做的话你三天后就没法复现自己的结论。我用一段很短的脚本把每次调用的输入、输出、耗时、token 消耗、模型标识全部落进一张表里格式大致是这样import json, time, hashlib from pathlib import Path def run_case(client, model, prompt, case_id, paramsNone): params params or {} t0 time.time() resp client.chat(modelmodel, messages[{role: user, content: prompt}], **params) elapsed time.time() - t0 record { case_id: case_id, model: model, prompt_hash: hashlib.md5(prompt.encode()).hexdigest(), output: resp[content], latency_s: round(elapsed, 2), tokens: resp.get(usage, {}), params: params, } path Path(results) / f{case_id}__{model}.json path.write_text(json.dumps(record, ensure_asciiFalse, indent2)) return record这张表最大的价值不是存档而是让我能做回溯分析。比如后来发现某个模型在超过一定长度后质量明显下滑我就能翻出当时的记录确认是任务本身变难了还是上下文被截断了。没有留痕这种判断只能靠印象而印象几乎总是错的。3. 同一批任务里三个模型的真实差异方法讲完进入正题。先说明一点下面所有的对比都是我在这批具体任务上的观察样本量不大也不代表这些模型在所有场景下的表现。你要做的是看趋势而不是抄结论。3.1 长链路代码重构谁在中途丢掉了上下文我挑的那次重构任务需要跨五个文件改动并且要保证旧接口还能兼容。三个模型第一次输出的结果里只有 DeepSeek4.1 完整地改到了第五个文件另外两个都停在第三四个文件就收尾了剩下的部分用以此类推糊过去。这一点在代码任务里非常致命因为它看起来像完成了实际上一编译就报错。更值得说的是第二轮。我把编译错误贴回去之后DeepSeek4.1 基本能定位到具体哪一行改错了并且会说明为什么会漏Opus5 也能修但它倾向于整段重写导致本来没问题的部分被带坏GPT5.6 修复单个错误的准确率不错但只要一次给多个错误它就会顾此失彼修好一个弄坏另一个。这里暴露出来的其实是长链路一致性问题。模型在小任务上都很能打差距体现在任务变长之后。我的经验是处理超过四个文件的改动时不要指望一次对话搞定把任务切成先只改类型定义、再改调用方、最后跑测试三段每个模型的表现都会好一大截。这不是模型不行是用法不对。3.2 中文长文写作风格漂移比语法错误更致命写作这块的差异很直观。我给的题目是写一份八千字左右的技术科普要求是保持统一口吻、不能出现明显的模板腔。跑下来GPT5.6 的句子质量最稳但有个毛病写长之后会不自觉地往总结归纳的套路走每隔几段就来一句承上启下读起来像在念报告。Opus5 的用词更讲究但中文语境下偶尔会冒出不太自然的书面表达一看就是按英文语感翻过来的。DeepSeek4.1 在这块的优势是接地气口语化表达和逻辑衔接更接近真人写的技术博客中间很少出现那种一眼假的过渡句。但它也有缺点写长了之后偶尔会漂移前面用第一人称后面突然变成第三人称。解决办法很简单在长文任务里每隔两千字左右把风格要求重述一次或者干脆分段生成最后再统一润色漂移问题基本能压下去。注意评判中文写作别只看单段质量一定要通读全篇看口吻是否一致。单段好看、全篇散架的稿子返工成本比重新写还高。3.3 结构化抽取与工具调用格式服从性差异这块是最工程的部分也是我认为选型时最该优先测的因为它直接决定能不能接自动化流程。我的测试是把两百条真实用户反馈抽成固定字段再接一步写文件的工具调用。结果是纯抽取环节三个模型的准确率差距不大都能到九成上下但到了工具调用环节差距就拉开了。Opus5 和 GPT5.6 在参数格式上更规范基本不需要重试DeepSeek4.1 在参数嵌套层级比较深的时候出现过几次格式偏差需要加一道校验重试。不过 DeepSeek4.1 有个实际优势它对指令里的约束条件记得更牢比如我要求不确定的字段填 null 而不是猜它遵守得最好另外两个偶尔会为了填满而编造内容。这个差异对我影响很大因为下游流程最怕的从来不是空值而是编造出来的错值。错值会一路传下去最后变成脏数据清理成本极高。3.4 横向汇总没有全能冠军只有分工把上面的观察整理成表大概是这样任务类型表现突出的版本主要短板我的使用建议多文件代码重构DeepSeek4.1超长上下文时偶有遗漏拆成三段执行逐段验证中文长文写作DeepSeek4.1 / GPT5.6长文口吻漂移、模板腔分段生成加统一润色结构化抽取三者接近差异主要在边界处理加一道格式校验即可工具调用Opus5 / GPT5.6参数格式偶发偏差严格 schema 加自动重试错误自我识别DeepSeek4.1修复时偶有过度改动限定改动范围再让它修看完这张表你会发现谁比谁强这个问题本身就不太成立。它们在不同任务上的排序是变化的而我的项目里代码和中文写作的权重最高所以我的选择自然偏向在长链路和中文表达上更顺的那个。选型的本质是给你的任务排序不是给模型排序。4. 那些能让结论整个反转的隐藏变量这一节是我最想说的部分。因为我上面所有结论只要改动几个参数就能全部推翻。如果你测出来的结果跟我不一样很可能不是谁测错了而是这些变量没对齐。4.1 上下文长度和截断策略我最早那次测试就吃了这个亏。当时我把三份文档一次性塞进去总长度超过了一万五千字跑出来的结果是某个模型很差后来才发现是输入被默默截断了模型只看到了前面一部分。这个坑极其隐蔽因为接口通常不会报错只会安静地丢掉超出的内容。我现在固定会做两件事一是记录每次输入的实际长度二是做一次探针测试在输入的最开头和最结尾各放一个只有看过才知道的标记然后在提问里要求模型复述。如果结尾的标记丢了就说明被截断了。这个测试花不了一分钟但能避免大量误判。顺便说一个经验长文档任务不要硬塞先做分块再让模型汇总效果通常比一次性喂进去更好因为模型在超长输入上的注意力分布本来就不均匀中间部分最容易被忽略。这是结构性问题不是哪个版本特有的缺陷。4.2 采样参数与复现性陷阱温度、top_p 这些参数对结果的影响比大多数人想的大。我做过一次对比同一道推理题温度调到接近零时三个模型的答案趋于一致一旦调到比较高的值方差立刻放大原来稳定的那个模型反而开始飘。所以如果你测出来的结论是某模型不稳定先检查你是不是用了偏高的采样参数尤其是做代码和结构化抽取的时候低温基本是默认选项。另一个容易被忽略的是系统提示词。有些版本对系统提示的敏感度差别很大。我惯用的做法是把关键约束放在系统提示里然后测它有没有被执行。实测下来DeepSeek4.1 对系统提示里必须遵守类约束的执行度比较稳另外两个在长对话后偶尔会忘记需要在用户消息里再强调一次。4.3 服务侧的延迟、限流与降级最后这个变量最非技术但影响最直接。我跑横评时是三个模型轮着来结果发现某个模型的响应时间在高负载时段明显变长本来三秒能返回的内容要等十几秒。更麻烦的是高峰期偶发的失败重试会打断我的批量脚本。这件事提醒我选型不能只看质量还要看它在你要用的时段里稳不稳。我的做法是把每个模型的平均延迟和超时率也记进那张结果表里一个月之后回看趋势。如果某个模型的质量优势只在深夜稳定出现那对白天要跑批的业务来说就等于没有优势。提示把延迟和失败率当成跟准确率同等重要的指标来记录。只看输出质量的选型上线之后一定会被稳定性问题打回来。5. 落到选型上我最后是怎么配的前面啰嗦了这么多方法论最后说点实际的。我不喜欢只选一个这种做法因为不同任务的最优解本来就不一样强行统一只会牺牲整体效率。5.1 按任务分流的混用策略我现在的配置是按任务类型分流。代码和长链路改造走 DeepSeek4.1因为它在中途丢上下文的情况最少错误定位也更准工具调用和需要严格遵循 schema 的环节走 Opus5 或 GPT5.6参数格式更规范重试率低中文面向用户的文案走前面那个因为它写出来的东西最少模板腔。这套配置听起来复杂但落地上就是几行路由判断成本很低。真正需要花心思的是兜底逻辑。任何一个模型都会失败所以每个环节我都会判断输出是否合法不合法就带着具体的错误信息重试一次再不行就降级到另一个模型。这套兜底比调参有用得多因为它解决的是 任意一次调用失败 这个必然会发生的场景。5.2 把成本和延迟折算成同一个分母比价这件事容易做错因为各家计费口径不一样。我的做法是把所有模型折算成同一个分母完成一件具体任务需要多少钱、多少秒。同一份用户反馈抽取两百条我跑完算下来token 花费和耗时差别能到两三倍。这个换算表比单价表有用得多因为你真正在意的是把这个功能做完要花多少。有个细节值得注意很多时候省钱的办法不是换便宜模型而是把提示词改短。我用一份冗长的提示词跑出来的账单精简之后能省三分之一质量几乎没变。提示词本身就是成本这一点经常被忽略。5.3 上线之后的回归测试怎么做模型这东西是活的接口后面的版本随时可能变所以上线只是开始。我固定每周跑一次小规模回归从题库里抽二十道题覆盖代码、抽取、写作三类跑完只看三个数通过率、平均延迟、失败重试次数。这三个数只要有一个明显波动我就会去看具体的失败案例。这套回归机制帮我抓到过一次很隐蔽的问题某个环节的通过率从九成掉到了八成翻日志发现是输出格式在边界情况下变了而下游的解析器没跟上。如果只看人工抽查这个问题很可能被漏掉直到用户投诉才暴露。最后分享一个我自己的体会。这次横评里最有价值的收获不是搞清楚了谁更强而是建立了一套自己能重复运行的评测流程。榜单会变模型会更新但用我的真实任务去测这件事永远不会过时。我现在拿到任何一个新版本第一反应都是把它丢进那二十道题的回归里跑一遍跑完心里就有数了。这套流程搭起来花了两天但之后每一次选型都省下了大量试错时间性价比高得离谱。