测试模型有哪几种 有什么差别

很多人一说要测模型，第一反应就是跑个榜单分数，结果测完还是不知道该选哪个。问题往往不在模型，而在测试类型和目标对不上：想验证业务效果却做了通用问答，想比成本却只看了质量。这篇把常见的几类模型测试拆开讲，说清各自测什么、结果能信到什么程度、什么情况下不适用，并给一张按目的选测试方法的对照表，让你测之前就知道该拿什么结论。

很多人一说要测模型，第一反应就是跑个榜单分数，测完还是不知道该选哪个。问题往往不在模型，而在测试类型和目标对不上：想验证业务效果却做了通用问答，想比成本却只看了质量。这篇把常见的几类模型测试拆开讲，说清各自测什么、结果能信到什么程度、什么情况下不适用，并给一张按目的选测试方法的对照表，让你测之前就知道该拿什么结论。

先说明一个前提：不同测试类型之间没有谁更高级，只有对不对得上你当前要做的决定。选型时该用的方法，放到验收环节可能完全不够用；验收时该抠的细节，放到粗筛又太费时间。所以下面每一节都会配上判断标准和排查动作，你可以直接照着对号入座。

先分清你要的是哪类结论，再决定测什么

模型测试至少服务于四种目的：选型、验收、监控、回归。四者对样本和指标的要求完全不同。选型只要排出大概的先后顺序，样本可以少一些、指标可以粗一些；验收要形成能签字的证据链，样本必须覆盖真实输入分布，判分规则还得能被人复核；监控看的是长期趋势，关注的是有没有突然变差；回归看的是改动前后有没有踩坏老功能，重点在固定题目集和可重复。目的没定清就开测，最常见的后果是选型看不出版本差异、验收又拿不出可用证据。

选型

在几个候选里排出优先顺序，结论可以是「先用 A 试，B 作备选」

验收

确认某个模型在你的业务里达到可上线标准，结论要能被人复核

监控

上线后长期观察质量有没有漂移，重点是趋势而不是单次分数

回归

改动提示词、版本或参数后，确认老功能没被踩坏

判断标准很简单：先写下这次测试要支撑的那个决定，写不出来就别开测。比如「决定下周把线上流量切给哪个候选模型」是一个能落地的决定，「看看哪个模型更强」不是。不适用场景也得说清：如果你想做的是长期趋势观察，那属于监控而不是一次性测试，两者不能共用一套流程。

能力类测试：通用题、领域题与自建题的差别

能力类测试是大家最熟悉的一类，但内部差别很大。通用题库偏广度，适合做粗筛，能快速把明显不行的候选剔掉；领域题偏深度，适合做二次确认，看模型在你的专业范围内是不是真的站得住；自建题最贴近你的真实输入分布，是唯一能支撑业务结论的一类。三类题目的关系是漏斗：先用通用题收缩范围，再用领域题确认，最后用自建题下结论。

• 自建题的难点在出题和判分：纯人工成本高，纯模型判分又会引入新的偏差
• 常见做法是人工定标一小批，把判分规则校准后再放大到全量，中间抽查一致性
• 出题时把输入长度、语言、是否带图这些条件固定下来，否则版本之间没法比
• 这类测试的结论只对题目覆盖的任务成立，换个输入分布就不适用，想替代真实业务验证做不到

出题时最容易忽略的是输入分布的还原。如果你从真实日志里抽样，要按业务量占比分层抽，别只挑顺手的那几类；如果全靠自己编题，至少标注每题对应什么业务场景，避免全落在同一个角落。判断题目集合格的标准不是题多，而是每道题都能说清它代表线上哪一类请求。不适用场景：任务本身还在快速变化、输入格式每周都改的时候，自建题刚出完就过期，这时优先用领域题做临时判断。

人工评测、模型判分与线上数据，各能信到什么程度

这三类方法经常被混着用，其实可信度的量级不一样。人工评测适合打标准和判断细微差别，但前提是人和人之间的一致性先校准过，否则分歧会盖过模型差异。做法是让两个人独立打一小批，看分歧有多大、分歧集中在哪些维度，把标准写细再继续。用模型给模型判分省事，适合粗排和大批量筛选，但对风格相近的答案容易偏向某一方，不宜作为最终依据。线上真实数据最有说服力，前提是已经上线且有分流和埋点，还没上线时它帮不上忙。

常用组合是人工定小样本标准、模型判分放大到全量、线上数据做最终确认，三步缺哪一步结论都要打折扣。判断标准：如果三步里有任意一步缺席，结论只能写成「初步倾向」，不能写成「已确认」。不适用场景：预算和周期只够做一步时，优先做人工定标而不是模型判分，因为人工结果还能反过来校准判分规则。

按任务测：问答、抽取、写作、代码、多模态各看什么

同一模型在不同任务上表现差异很大，跨任务把分数直接相加没有意义。按任务测的关键是给每类任务定出独立的判分维度。问答看事实准确与拒答是否合理，答错和该拒没拒要分开统计；抽取看字段完整率和格式合规，字段缺失和格式跑偏是两类不同的问题；写作看可读性与一致性，没有唯一答案的题要用维度打分而不是对错判断。

• 代码和多模态的判分依赖能否运行、能否还原，这类测试的样本准备成本最高
• 建议先小批验证判分链路再扩量，别一上来就攒几百道题
• 代码题要记录运行环境，多模态题要记录素材来源和格式，否则结果无法复现
• 每类任务单独出一张结果表，不要合并成一个大分数

不适用场景：任务还需要大量人工兜底时，测出来的差距未必能在实际流程里体现出来。比如写作类任务即使模型得分高，后面还是有编辑逐句改，那这个分差对上线决策的参考价值就有限。这时候更应该测的是「人工修改耗时有没有下降」，而不是模型本身的写作分数。

成本与速度测试：跟质量测试分开做

质量、成本、速度三者要分开测再合并看，混在一次测试里很容易得出「又快又好」的错觉。速度测的是首字延迟和稳定输出速度，必须固定上下文长度、并发数和是否流式，否则数字之间不可比。同一模型在不同并发下表现差别很大，所以测速度时要把并发档位写进记录，别只报一个数字。具体单价和折算口径到 /official-api 和各平台页核对当时的数字，站内 /price-watch 也会追踪变动。

成本要按你自己的输入输出比例折算，单看单价说明不了实际问题。一个长输入短输出的场景和一个短输入长输出的场景，同样的单价算下来完全不是一回事。做法是先从真实流量里统计平均输入输出长度和调用量，再按这个比例折算到每个候选模型上。判断标准：折算后的成本要和你实际能接受的预算比，而不是和别家模型比。不适用场景：低并发的小规模内部工具，延迟差异通常感受不到，不必为速度指标过度优化。

1. 统计真实输入输出从日志里取近期调用，算平均输入长度和输出长度，分成几档记录，别只取平均
2. 固定测速条件限定上下文长度、并发档位和是否流式，每个条件单独跑，记录首字延迟和输出速度
3. 折算成本按上一步的比例把单价折成实际单次调用成本，站内 /official-api 和各平台页有当时的口径可核
4. 合并出结论把质量、成本、速度三张表并排看，明确哪个指标是一票否决项，再排最终顺序

测试框架怎么搭，以及最常见的三类误用

搭测试框架要固定四件事：题目集、判分规则、运行参数、记录格式。任何一项变了，前后结果就不能直接比。题目集必须有版本号，改动要单独记一笔；运行参数包括温度、最大输出长度、是否流式，这些写在配置文件里而不是靠记忆；记录格式统一成一张表，原始输出单独存，方便后面有人质疑时回溯。这四件事固定下来，测试才能从一次性活动变成可复用的资产。

• 误用一：拿榜单分数当业务结论，榜单和你业务的相关性没人验证过
• 误用二：题目和调参反复来回看，改一版测一版，最后过拟合到测试集上
• 误用三：样本量太小，把噪声当差异，两个模型差一点就下结论
• 扩样本之前先做一次同模型重复跑，看自身波动有多大，波动比差异大时加样本是浪费

关于榜单的定位，已有文章 model-select 讲透了榜单与真实任务的差距，这里只补一句：榜单用来缩小候选范围，不用来定最终结论。具体到分数、名次这类会变的信息，到 /rankings 核对当时的数字，不要凭记忆引用。判断标准：如果你的测试结论里出现「因为榜单上它排前面」这种理由，说明还没测到点上。

一份可直接照做的测试流程

下面这份流程按顺序走，每一步都有可验证的产出。核心原则是每一步都留原始记录，后面有人质疑结论时能回溯。如果中途改了题目或参数，把前面结果作废重跑，不要拼接两组数据。

1. 定目的和通过线写下这次测试要支撑的决定，并提前定好什么算通过、什么算不通过，别等结果出来再定标准
2. 从真实输入抽样出题按业务量占比分层抽，覆盖主要场景，标注每题对应的业务类型
3. 人工定标小批由两个人独立打一小批，校准一致性，把分歧点写进判分规则
4. 固定参数跑候选温度、最大输出长度、是否流式等参数写进配置并记录，原始输出单独存档
5. 校验判分规则用人工结果对照模型判分，看一致率有多少，不一致的题回看是规则问题还是题目问题
6. 放大样本复跑样本扩到能覆盖主要场景的量，同时做同模型重复跑，确认波动幅度
7. 结合成本出结论把质量结果和成本、速度数据并排看，给出首选和备选，并写清适用条件

走完这套流程，你手里应该有三样东西：一份带版本号的题目集、一套校准过的判分规则、一张包含原始输出的结果表。下次再做类似测试，直接复用前三步的产出，只跑后面的步骤就行。反过来，如果这三样都没有，说明这次测试更像一次性尝试，结论要谨慎对待。