模型对比检测实验

很多人做模型对比，就是把同一个问题分别丢给两个模型，看谁答得顺眼就下结论，结果换个问题结论又反了。问题不在模型，在实验设计：指标没定、样本太少、评测方式带着偏向。这篇给一套能直接照做的流程——先定可比口径，再选指标和样本，最后按固定顺序读结果，让对比从「我觉得」变成「有依据」。

做模型对比最容易掉进一个坑：拿一个自认为典型的问题，分别问两个模型，谁的回答读起来顺眼就拍板。换几个问题再试，结论可能就反过来了。问题往往不出在模型上，而出在实验设计——指标没提前定、样本量不够、评判时自己已经知道哪个答案来自哪个模型。这篇给一套能直接照做的流程，让对比从「我觉得」变成「有依据」。

整套流程分四步：先把不可比的因素掐掉，再按任务类型选指标，接着设计有代表性的样本，最后按固定顺序读结果。四步里最容易省掉的是第一步和第四步，也恰恰是决定结论能不能站住的两步。

第一步：先把不可比的因素掐掉

对比实验里最常见的假结论，来自变量没控住。温度、最大输出长度、系统提示词、上下文拼接方式，只要有一项不同，差异就可能来自参数而不是模型本身。建议所有候选模型跑同一份请求模板，把参数显式写进记录表，别靠脑子记。

指标选错，后面做得再规范也白搭。抽取、分类、改错、结构化输出这类客观任务，可以用可自动判定的指标：命中率、字段完整率、格式合规率。关键是提前写好判定脚本，别事后人工数，人工数的时候你会不自觉地放水。

写作、问答、代码、咨询这类开放任务，自动指标基本失效，改用分维度打分：正确性、完整性、可执行性、是否编造。每个维度给三档描述，两个以上的人独立打，把分歧项单独拎出来复盘。

从真实业务里抽题，不要用自己临时想的例子。一个可行做法是翻最近一段时间的工单、日志或聊天记录，脱敏后挑出高频场景，每类场景保证有若干条。样本量按差异预期来定：如果两个候选实力接近，题量太少根本分不出来，这时候要么加题量，要么承认这次分不出差异，比强行下结论靠谱。

先看失败案例再看总分。把两边都答错的题挑出来，这类题往往说明任务本身定义不清，不是模型的锅；把一边答对一边答错的题单独列出来，这些才是区分度所在。同一题换个说法再跑一遍，如果结论翻转，说明这个差异不稳定，不要写进结论。

只用一个提示词比多个模型，能算对比实验吗？

可以算初步摸底，但得不出可靠结论。单个样本的差异可能来自措辞巧合、生成随机性或者当时的负载。想让结论站得住，至少要有覆盖几类真实场景的一批题，并且同一题在不同模型上跑的口径完全一致。如果时间有限，与其多测几个模型，不如把题量加够。

人工打分主观性太强，有没有省事的替代？

分两条路：能自动判定的任务就用脚本判，提前写规则；不能自动判定的，就退一步只打粗粒度档位（可用／勉强／不可用），减少打分人的自由发挥空间。再让两个人独立打，只对分歧项讨论。比追求精细分数更重要的是把判定标准写清楚，别人拿着你的标准能复现。

测出来两个模型差不多，怎么定？

先确认是不是题量不够导致分不出来，可以补一批高难度题再跑。如果确实接近，就把决策权交给其他维度：成本、延迟、稳定性、许可证和部署方式。这几个维度往往有明确差距，不会都打平。可以到 /models 和 /benchmarks 查当时的可比数据，再结合自己的用量算一遍账。