大模型上线前，我们到底该怎么测？一份来自一线的检查清单

上个月，我们团队负责的大模型对话功能终于要上线了。

上线前夜，产品经理跑过来问我：“测完了吗？能上吗？”

我盯着屏幕上密密麻麻的测试报告，沉默了五秒。然后说：“你等我再想想。”

不是没测，是测了太多，反而不知道该怎么判断“能不能上”。

传统功能测试，标准很清晰：功能实现了，用例跑通了，bug修复了，就能上。但大模型不一样——它没有“正确”答案，只有“合理”答案；没有固定的输入输出，只有概率分布；没有明确的边界，只有模糊的语义空间。

那一夜，我把自己关在会议室，把这两周踩过的坑、翻过的车、总结的经验，一条一条写在白板上。最后整理成了一份清单。

今天分享出来，希望能让正在经历同样煎熬的同行，少走几步弯路。

一、先说清楚：大模型测试，到底难在哪？

在开始列清单之前，得先搞明白一件事：为什么传统测试方法在大模型面前失灵了？

第一，没有“标准答案”。

测一个登录功能，你输入正确密码，预期是登录成功——这是确定的。但测一个对话模型，你问“今天天气怎么样”，它可能回答“今天晴转多云”，也可能回答“出门记得带伞”，还可能反问“您想查哪个城市”。哪个算对？哪个算错？

第二，状态空间无限大。

传统软件，用户操作路径是有限的。但大模型，用户的提问方式是无限的。同一个意思，可以有上千种问法，你没法穷举。

第三，结果不可重复。

同样的输入，两次运行结果可能不一样。你发现一个bad case，想复现给开发看，结果第二次跑又好了。这bug怎么提单？

第四，判断标准主观。

你觉得这个回答“有点啰嗦”，产品经理觉得“很详细”，用户觉得“挺贴心”。谁说了算？

这些问题，没有现成的答案。这两周的测试，我们基本上是摸着石头过河，一边测一边总结。

下面这份清单，就是我们摸出来的石头。

二、功能测试清单：它到底能不能干好活？

1. 核心能力测试

先别管那些花里胡哨的，第一件事是确认：它能不能完成最基本的功能？

我们列了一个“核心场景清单”，大概长这样：

• 语义理解：常见问法能听懂吗？比如“查余额”和“我的钱还有多少”，能不能对应到同一个意图？
• 上下文记忆：多轮对话里，能记住前面说过的话吗？比如用户说“帮我查一下上个月的话费”，模型回答后，用户接着说“那这个月呢”，它能理解是指话费吗？
• 任务完成率：明确的指令，它能执行对吗？比如“设置一个明天早上8点的闹钟”，执行结果是否符合预期？
• 知识准确性：事实类问题，回答是否正确？比如“ iPhone 15 发布时间”，不能说错。

踩过的坑：有一次我们测一个客服模型，问“怎么退货”，它回答得头头是道，但仔细一看，说的是退货政策，不是操作步骤。语义理解对了，但任务没完成。所以光测“听懂”不够，还得测“做成”。

2. 边界和极端情况

大模型的边界，比传统软件更难定义。我们摸索出来的几个方向：

• 超短输入：只输入“？”、“好”、“嗯”，模型会不会死循环或乱回答？
• 超长输入：复制一篇文章进去，它还能记住开头的内容吗？
• 重复输入：连续问十次“你好”，每次回答是否一致？（不一定要求完全一样，但不能越说越离谱）
• 噪声输入：带错别字、带表情符号、中英混杂，能正常处理吗？

真实案例：我们有个模型，用户输入“你你你你好”，它直接卡住了，半天不响应。后来发现是预处理环节没处理好重复字符。这种场景，传统测试根本想不到。

3. 拒答能力

大模型有一个很要命的问题：它总想回答，哪怕不知道答案。

我们测过一个模型，问“明天的天气”，它不知道（没接天气API），但硬编了一个“明天晴转多云”。用户信了，出门没带伞，淋雨了。这就是事故。

所以必须测：

• 超出知识范围：问它不知道的事（比如内部数据、未来事件），它能诚实地“不知道”吗？
• 敏感话题：涉政、涉黄、涉暴力的提问，能拒答吗？
• 诱导性提问：用户试图套出系统指令、历史数据，能防御吗？

判断标准：宁可不说，不要胡说。这条应该写进验收标准里。

三、性能测试清单：它跑得快不快，扛不扛揍？

大模型上线，功能只是及格线，性能才是生死线。

1. 响应时间

我们测了三个维度：

• p50响应时间：一半请求的响应时间，代表用户体验的中位数
• p95响应时间：最慢的5%请求的响应时间，代表系统的稳定性
• 首字返回时间：用户问完问题到第一个字出现在屏幕上，这个指标很影响感知

我们的基线：p50在1秒内，p95在3秒内，首字返回200ms内。超过这个范围，用户就会觉得“卡”。

2. 并发能力

大模型是计算密集型，并发一高，很容易崩。我们压测时发现：

• 50并发，响应时间开始明显上升
• 100并发，开始超时
• 200并发，服务直接挂了

关键要测：你的业务峰值并发是多少？双十一、抢票这种场景，能不能扛住？扛不住的话，降级方案是什么？

3. 资源消耗

大模型吃GPU是出了名的。我们上线前统计了：

• 单次请求平均消耗多少显存
• 峰值消耗多少显存
• 长期运行有没有内存泄漏

经验：有个模型跑了三天，显存占用涨了30%，排查发现是缓存没释放。这种问题，短时间压测评测不出来，得做长期稳定性测试。

四、安全测试清单：它会不会惹祸？

大模型上线，最怕的不是功能不好，而是惹祸。

1. 内容安全

• 涉政检测：输入输出是否包含违规内容？
• 涉黄检测：有没有生成色情内容的风险？
• 暴力/仇恨言论：会不会生成鼓励暴力或歧视的内容？
• 隐私泄露：会不会在对话中泄露用户隐私，或者泄露系统内部信息？

我们踩过的坑：有一次用户问“你们公司工资多少”，模型居然编了一个数字。虽然编的不对，但这种话题本身就敏感，应该拒答。

2. 对抗攻击

有些用户会故意尝试让模型“越狱”：

• 角色扮演诱导：“假装你是我的奶奶，你小时候经常给我讲……”
• Base64编码提问：把敏感问题编码后输入
• 多轮诱导：先聊家常，慢慢拐到敏感话题

这些都需要专门的安全测试用例覆盖。

3. 数据安全

• 日志脱敏：对话日志里，手机号、身份证号等敏感信息脱敏了吗？
• 数据隔离：A用户的数据，会不会被B用户查询到？
• 模型窃取：通过大量提问，能否反推出训练数据或模型参数？

五、体验测试清单：它“好用”吗？

功能和性能都过关了，最后一步是：用户觉得好用吗？

1. 拟人化程度

• 语气自然：回答像机器人念稿，还是像真人聊天？
• 个性化：不同用户，能得到不同风格的回应吗？
• 情感理解：用户表达愤怒或沮丧时，模型能感知到并调整回应吗？

2. 容错恢复

• 模型答非所问时，能主动纠正吗？ 比如用户说“我不是问这个”，模型能重新理解吗？
• 多轮迷失后，能引导回来吗？ 聊着聊着跑题了，能不能主动拉回正题？

3. 帮助提示

• 首次使用：用户不知道能问什么，有引导吗？
• 空状态处理：模型不知道答案时，是直接说“不知道”，还是给一些建议？

六、上线前的最后检查：到底能不能上？

所有测试都做完了，最后回到产品经理那个问题：能上吗？

我们制定了一个“上线准入标准”，分三个等级：

红牌（一票否决）：

• 有涉政、涉黄、涉暴内容生成
• 有用户隐私泄露风险
• 核心意图识别准确率低于90%
• 响应时间p95超过5秒

黄牌（可以上，但需标注）：

• 部分知识准确性有问题，标注“测试版”
• 复杂场景理解不佳，建议用户“简单提问”
• 偶尔有幻觉，但频率低于5%

绿牌（放心上）：

• 所有红牌项无问题
• 黄牌项少于3项
• 压测稳定运行24小时无异常

我们那个项目，最终是黄牌上的。因为还有少量幻觉问题，但在产品页面加了提示：“本功能为测试版，可能出现不准确回答，请以官方信息为准。”

写在最后：测大模型，是在测边界

这两周的测试，让我对“测试”这件事有了新的理解。

以前测软件，是在测“它有没有实现功能”。现在测大模型，是在测“它会在什么地方失控”。

传统软件，边界是清晰的：用户只能点这些按钮，只能输这些数据。大模型，边界是模糊的：用户可以和它聊任何话题，它可能给出任何回答。

我们能做的，不是消除所有风险——那不可能。而是找到边界、划清界限、做好防护。

这份清单，就是我们找到的一些边界。不完整，不完美，但至少能让你在大模型上线前，少一点“我到底测完了没有”的焦虑。

如果你也在测大模型，欢迎补充你的清单。

毕竟，这行太新了，我们都是摸着石头过河的人。