大模型测试，我们在测试什么（一）

小菜cai

219人浏览 · 2026-07-21 17:16:52

小菜cai · 2026-07-21 17:16:52 发布

写在前面：

在开始动手测试之前，我们首先要搞清楚一个问题：大模型测试的对象到底是什么？

是一个模型，还是一个系统，是一个代码程序还是一个有“自主”意识的工具?

不同的测试对象，决定了不同的测试策略、工具选择和判断标准。

真实的测试场景：

假设你接手了一个大模型项目：《一个智能客服Bot》，用户提问后，系统会检索公司知识库，然后让大模型生成回答。

第一天，产品经理跑过来说："模型回答不够准确，去测一下。"

第二天，算法工程师说："我们换了一个更强的基座模型，去测一下。"

第三天，后端开发说："检索逻辑改了，去测一下。"

第四天，业务方说："用户反馈语气太正式了，Prompt改一下，去测一下。"

问题来了，每一次改动，你测的都是同一个东西吗？

在回答这个问题之前，我们来看下这个测试场景和我们之前传统软件测试的差异点：

1.需求定义从“精确规格”变成了“模糊意图”

传统测试中，需求告诉你“正确是什么”；大模型测试中，需求只告诉你“正确大概长什么样”。

2.设计依据从“需求文档”变成了“探索与经验”

传统测试的用例设计，是演绎法：从需求出发，推演出所有测试场景。

大模型测试的用例设计，是归纳法：从模型的行为边界中探索未知风险。

3.方案制定的确定性 vs 不确定性

传统测试方案可以精确回答：

测什么？（需求文档说了算）
测多少？（等价类+边界值，有穷尽的数学依据）
怎么测？（按测试用例一步一步执行）
怎么判断？（预期输出 vs 实际输出，非黑即白）
什么时候测完？（所有用例执行完毕，bug修复率达到标准）

大模型测试方案只能模糊回答：

测什么？（我们觉得重要的场景 + 线上常出现的场景 + 历史上出过错的场景）
测多少？（取决于预算和token成本，通常是一个“差不多”的数量）
怎么测？（批量跑 + 统计 + LLM-as-Judge + 人工抽样）
怎么判断？（看通过率是否在可接受范围内，看人工评分是否达标，但“达标线”本身也是个讨论出来的数字）
什么时候测完？（测试集跑完一轮只是开始，线上还要持续监控）

4.回归测试的“牵一发动全身”

传统测试中，改了一个功能，影响范围相对可控——你大概知道哪些模块受牵连，可以有针对性地做回归测试。

每一次改动，都相当于对整个系统做了一次“全局回归”。你无法精准地说“我只测这几个模块”，因为你不知道模型的内部决策边界在哪里。

回到最初的问题：每次改动，你测的都是同一个东西吗？

如果你问的是测试目标——是的，都是为了让这个应用更好用
如果你问的是测试对象——是的，都是同一个应用系统
如果你问的是测试的范围、重点、判断标准——完全不同

换基座模型，你测的是模型能力的迁移——哪些能力提升了，哪些能力反而退步了？
改Prompt，你测的是指令遵循度的变化——新的Prompt是否让模型更听话了？
改检索逻辑，你测的是检索质量的波动——召回率提升了还是下降了？牺牲了什么？
改知识库，你测的是知识覆盖和准确性——新知识是否被正确使用？旧知识是否被干扰了？

在这里我补充一下，这四层是我检索了很多资料得出的，一开始我也不知道大模型测试的分层概念，后面仔细一想想，其实之前做的测试工作就是遵循于这四层开始的，大部分是后面三层的测试工作，即Prompt、检索逻辑与知识库。

如果你把这些都混在一起测，就像去医院挂了一个"万能号"，医生看了一眼说"回去多喝热水"——你永远找不到真正的病灶在哪里。