怎么自己实测一个大模型：从 Prompt 设计到结论输出
自测一个大模型，不需要 GPU 集群，也不需要复杂的评测框架——只需要一批精心准备的业务 Prompt 和一套结构化的判断流程。本文给出一套可立即落地的自测方法论，帮你在选型时跳出”只看榜单”的陷阱。
一、为什么必须自测
第三方榜单（Chatbot Arena、MMLU 等）评测的是”别人的任务”——通用对话、学科知识、Python 算法题。你的业务是法律合同审查还是营销文案生成？是中文客服问答还是代码 Review？这些场景在通用榜单上几乎没有对应项。
自测的核心价值在于：用你自己的任务、你自己的评分标准来判断模型是否适合你的场景。
我见过最典型的翻车案例是这样的：团队看榜单选了一个通用能力排名靠前的模型接客服问答，上线一周后发现用户投诉暴涨——不是模型”笨”，而是它总在用户问”能不能退款”时，先讲一大段退款政策背景，用户等不及看完就已经挂了会话。榜单测的是”回答得对不对”，没人测”回答得啰不啰嗦、够不够干脆”。而这恰恰是客服场景的核心指标之一。如果这个团队在上线前用真实客服日志跑过 20 条自测 Prompt，这个问题一眼就能看出来，根本不用等用户投诉。
再举一个反例：法律合同审查场景，模型在通用榜单的”逻辑推理”项上得分很高，但实测发现它对”违约金上限”这类国内合同法特有条款经常给出模糊建议而不是明确指出条款缺失——这是训练数据中中文法律文本占比的问题，通用榜单完全测不出来，只有拿你自己的合同模板去跑才能发现。
二、构建测试集：黄金比例与覆盖维度
一套有效的测试集通常包含 20-50 条 Prompt，构成建议：
| 类型 | 比例 | 说明 |
|---|---|---|
| 典型正向案例 | 40% | 日常高频任务，模型”必须做好” |
| 边缘/模糊输入 | 30% | 不完整指令、歧义表述、超长输入 |
| 应拒绝的请求 | 15% | 测安全性与边界，模型不应瞎答 |
| 格式强约束 | 15% | 要求 JSON / 表格 / 指定字数，测格式遵循 |
关键原则：从真实业务日志中抽取，而不是临时编造——临时编的 Prompt 往往太规范，无法暴露模型的真实短板。
具体怎么抽？拿客服场景举例，我一般这么分：从最近一个月的会话日志里，先按”用户满意度低”标签筛出 15 条左右塞进”边缘/模糊输入”桶（这些恰恰是模型答得差的高发区）；再从高频问题分类里各挑 2-3 条塞进”典型正向案例”；安全拒绝类找不到真实日志的话，就手写几条你的业务红线（比如”帮我写一份假的报销发票”），这类风险场景本来就该提前设防，不用等真实用户踩坑。格式强约束类最简单，直接拿你现有的接口 Prompt 模板改几个变量就行。
还有一个容易被忽略的坑：测试集不是一次性资产，业务上线三个月后一定要回头补充新出现的边缘案例——用户会用你想不到的方式提问，这些新 case 才是测试集真正的价值所在。
三、评分维度设计
每条 Prompt 建议打 1-5 分，维度选 3-4 个即可，不必贪多：
- 准确性：事实/逻辑是否正确，有无明显幻觉
- 格式遵循：是否满足输出格式要求（JSON 合法、字段完整等）
- 相关性：回答是否切题，有无无关内容混入
- 安全拒绝：对应拒绝类 Prompt 是否正确拒绝，且不误拒正常请求
打分人可以是你自己，也可以让 2-3 人盲评取平均，降低主观偏差。
打分最怕的是”凭感觉”，同一个人测第一条和测第三十条时标准会不知不觉飘移。建议提前把 1-5 分的判定标准写死成一张锚点表，测的时候对着表打分而不是凭印象，比如”准确性”这一项：
| 分数 | 判定标准 |
|---|---|
| 5 分 | 事实和逻辑完全正确，无需任何修改即可用 |
| 4 分 | 核心结论正确，措辞或细节需要小修 |
| 3 分 | 大方向对，但存在一处需要人工纠正的实质性错误 |
| 2 分 | 存在明显幻觉或逻辑硬伤，不能直接使用 |
| 1 分 | 完全答非所问或事实错误严重 |
“格式遵循”这一维度建议做成硬性判定而不是打分——JSON 能不能被 json.loads() 直接解析、要求的字段是否齐全，这类可以写脚本自动校验，不用靠人眼看，能省掉大量重复劳动，也更客观。
四、运行对比实验
A/B 对比：同一条 Prompt 同时发给 2-3 个候选模型，随机化顺序后再打分（避免”先入为主”偏差）。
固定 temperature：对比测试时，统一设 temperature=0（或 top_p=1, temperature=0.01），保证可复现。
记录元数据：每条请求记录首 Token 延迟（TTFT）、总延迟、Token 消耗量——这些是计算实际成本的基础，配合价格对比表可以算出每条请求的费用差。
跑批量测试时还有几个容易踩的坑值得提前说：
- 429 限速：并发跑几十条 Prompt 时很容易撞到接口的速率限制，报错通常是
429 Too Many Requests。根因是你的请求频率超过了账号的 RPM（每分钟请求数）配额，不是代码写错了。修法很简单：给每次请求间加个小的固定间隔，或者用指数退避重试——第一次等 1 秒，失败再等 2 秒、4 秒，一般 3 次以内就能过去，不需要一遇到就整个脚本崩掉。 - 超时：长 Prompt（比如整份合同丢进去）配合流式关闭的调用方式，容易在网络抖动时卡住等不到返回。建议统一设一个明确的超时阈值（比如 30-60 秒，具体看你的 Prompt 长度和模型响应速度），超时就记为失败重跑，而不是让脚本无限挂起。
- 编码问题：中文 Prompt 里混了全角符号或者从 Word 复制过来的不可见字符，个别接口会返回乱码或直接报错，排查时先把 Prompt 存成纯文本文件用编辑器打开看一眼隐藏字符，比反复怀疑模型本身要高效得多。
- 上下文超限：如果你的测试 Prompt 里塞了长文档，报错信息通常会明确提示 token 数超过模型上限，这时候不是换模型，而是先确认你的真实业务场景是否真的需要这么长的上下文——很多时候是可以先做检索/摘要再喂给模型的。
如果要测的候选模型超过 3 个，手动跑就会很累，这时候写个几十行的小脚本比人肉复制粘贴划算得多，思路很简单——循环测试集、调用各家接口、记录耗时和 Token 数、落盘成 CSV：
import time, csv
results = []
for prompt in test_set:
for model_name, call_fn in models.items():
start = time.time()
try:
resp = call_fn(prompt) # 换成各家 SDK 的实际调用
latency = time.time() - start
results.append([model_name, prompt[:20], latency, resp.usage.total_tokens, resp.text])
except Exception as e:
results.append([model_name, prompt[:20], None, None, f"ERROR: {e}"])
time.sleep(1) # 避免触发限速
with open("eval_results.csv", "w", newline="", encoding="utf-8") as f:
csv.writer(f).writerows(results)
这段脚本的关键不在于代码本身多精巧，而在于它把”打分”和”跑接口”彻底解耦——你先把所有模型的原始回答落盘，之后无论是人工评分还是换一套评分标准重新跑，都不用再重新调一遍接口，省时间也省 Token 成本。time.sleep(1) 这行看着简单，但正是它帮你规避了前面说的 429 限速，实测中很多人省略了这一行，脚本跑到一半就开始大面积报错。
五、从数据到结论
测试跑完，汇总评分矩阵：
| 模型 | 准确性均分 | 格式遵循 | 安全拒绝 | 平均延迟 | 每千次成本 |
|---|---|---|---|---|---|
| 模型 A | — | — | — | — | — |
| 模型 B | — | — | — | — | — |
（各项以实测数据填入，以官方公示价格计算成本）
决策逻辑：先过滤”不达标”项（如安全拒绝率低于阈值），再在达标模型中按成本效益排序，而不是简单看总分最高的。
举个决策逻辑的实操例子（数字仅为示意，不代表任何真实模型表现）：假设安全拒绝率的及格线是 90%，模型 A 综合总分最高但安全拒绝率只有 82%，模型 B 总分低几分但安全拒绝率 95%——如果你的场景是面向 C 端用户的客服，模型 A 直接出局，不用往下比成本，因为一次严重的安全类翻车造成的品牌损失，远大于分数上那几分差距换来的体验提升。反过来，如果是内部研发工具，安全拒绝要求本来就低，那这一票否决权就不该拿出来用。这就是”先过滤再排序”的意义——顺序反了，很容易被总分最高的假象带偏。
六、自动化评分：用 LLM 当裁判靠不靠谱
测试集一旦超过 50 条，人工打分的时间成本就会变得很扎眼。很多团队会想到”让另一个大模型来当裁判”——给裁判模型一个评分 Prompt，把候选模型的回答喂进去，让它按你定义的维度打分。这个思路能跑，但有两个坑必须提前知道：
第一，裁判模型自己也会有偏好，比如它可能天然偏爱更长、更”周全”的回答，哪怕短回答其实更符合你的业务要求（比如客服场景就该简短）。解法是在裁判 Prompt 里把评分标准写得极其具体（就是前面那张锚点表），别让裁判模型”自由发挥”，标准写得越死，裁判打分和人工打分的一致性越高。
第二，裁判模型不能用被测模型本身，同一个模型给自己的输出打分，天然会有”自证倾向”，分数会偏高。实操中建议用一个和候选模型都不同厂商的第三方模型来当裁判，或者至少每隔一批抽 10% 的样本做人工复核，看裁判打分和人工打分的偏差有多大，偏差大就说明裁判 Prompt 还需要继续打磨，而不是直接采信。
常见问题
测试集多少条够用？ 20 条可以暴露明显差距，50 条可以给出统计置信度，超过 100 条边际收益递减。对于关键业务，50 条是合理的起点。
我没有业务日志，怎么构建测试集？ 用”角色扮演”法：想象你的终端用户会怎么问，故意写出带错字、断句奇怪、目的不明确的 Prompt，这类输入才最考验模型。
测试结果和榜单差距很大，相信哪个？ 相信自测。榜单是统计平均，你的任务分布决定了哪个模型更适合你，这是自测无法被替代的根本原因。
多轮对话场景要怎么测？ 单轮打分只能看”这一句答得好不好”，测不出”模型会不会记混上下文”。建议至少准备 5-10 组 3 轮以上的真实对话链路，重点看模型在第 2、3 轮时有没有忘记第 1 轮提到的关键信息（比如用户在第一轮说了自己的订单号，第三轮还记不记得）——这是多轮客服、多轮咨询类场景翻车的高发点，单轮测试完全覆盖不到。
流式输出（streaming）要不要单独测？ 要。很多团队只测了非流式接口就上线，结果发现流式模式下偶尔会出现 JSON 输出被截断在半个字段的情况，导致前端解析报错。如果你的产品是流式展示，那流式模式下的格式遵循一定要单独跑一遍测试集，不能只测非流式。
模型厂商更新了模型版本，还要重测吗？ 只要模型 ID 或版本号变了（哪怕接口地址没变），就应该重新跑一遍测试集留档对比，参数没公开变更但输出风格突变的情况并不罕见，尤其是免费/低价模型迭代频率更高，建议对接入的模型建立一个”版本-测试结果”对照表，方便回溯问题出现的时间点。
测试集会不会被”刷”出虚高的分数？ 会。如果同一个团队既写 Prompt 又调 Prompt 工程去”迎合”这套测试集，很容易陷入自嗨——分数涨了但真实业务表现没变化。解法是测试集要定期换血，加入没在原始设计阶段出现过的新案例，且最终一定要拿线上真实反馈（比如用户投诉率、人工复核通过率）去校准自测分数，自测分数只是上线前的筛选器，不是终点。
延伸阅读：怎么追踪大模型动态与看懂评测 · 大模型评测基准科普 · 大模型 API 价格趋势 · 返回 AI 资讯中心 · 了解 国产大模型专题