大模型评测经验总结与探讨
大模型评测和传统软件测试最大的区别在于：传统功能测试验证的是明确需求，大模型评测面对的是不稳定、开放式、持续变化的能力边界。
因此，大模型评测不能只问“有没有 bug”，而要回答三个问题：
- 这个模型在当前业务阶段是否可用？
- 现有问题是否能通过数据、提示词、工具或流程优化解决？
- 上线后风险是否可控，是否能持续监控？
这篇文章把一次评测体系建设过程抽象成通用方法，重点讨论“评什么、怎么评、如何让评测结果真正推动迭代”。
1. 为什么大模型不能照搬传统测试
传统软件系统通常有清晰的输入、输出和验收标准。只要需求写清楚，测试用例就可以覆盖主要分支。
大模型不同。它的输出受提示词、上下文、采样参数、外部工具、历史对话和模型版本共同影响。同一个问题，模型可能给出多个看似合理但质量不同的答案。
这会带来三个变化：
- 需求边界更模糊：很多需求要在评测中逐步收敛；
- 错误形态更长尾：幻觉、遗漏、风格漂移、工具误用都可能出现；
- 评估目标更动态：Demo 期、开发期、上线期的评测重点并不相同。
所以，大模型评测的定位不是“最后验收”，而是“持续决策系统”。它既要发现问题，也要帮助团队判断下一步该优化什么。
2. 按阶段定义评测目标
2.1 Demo 期：先验证能不能做
Demo 期不要追求完整评测体系，重点是判断方向是否成立。
这个阶段可以只准备 30 到 50 条高价值样本，覆盖最核心、最容易失败的场景。评测目标不是找最优模型，而是排除明显不可行的方案。
建议关注：
- 核心任务是否能跑通；
- 指令遵循是否稳定；
- 是否出现明显安全问题；
- 是否具备继续调优的潜力。
这个阶段的结论应该简单：继续投入、换路线，或者暂缓。
2.2 开发期：定义什么叫好用
进入开发期后，问题从“能不能做”变成“做到什么程度才算可上线”。
这时要把评测维度拆开，例如：
| 维度 | 关注问题 |
|---|---|
| 有用性 | 回答是否解决真实问题 |
| 准确性 | 事实、计算、引用是否可靠 |
| 完整性 | 是否遗漏关键步骤或条件 |
| 稳定性 | 多次运行是否表现一致 |
| 安全性 | 是否触碰合规、隐私或伦理底线 |
| 体验 | 表达是否清楚，交互是否自然 |
不同业务的权重不同。一个报表分析 Agent，准确性和可解释性权重要高；一个创意写作助手，表达质量和多样性权重要高。
2.3 上线期：关注持续监控
模型上线后，离线评测不能替代线上监控。真实用户输入会不断突破评测集边界，所以要把线上 badcase 回流到离线评测集中。
上线期重点关注：
- 低分样本是否集中在某类场景；
- 工具失败是否被模型正确处理；
- 用户追问是否暴露上下文问题；
- 模型版本升级是否带来回退；
- 安全风险是否出现新的形态。
3. 评测集怎么建
一个好的评测集不是随机样本堆砌，而是业务问题的结构化表达。
我更倾向按三层组织：
- 基础能力集：验证模型能否理解常规任务；
- 高频业务集：覆盖真实用户最常见问题；
- 高风险挑战集：专门收集复杂、长尾、容易误判的样本。
每条样本至少包含：
- 用户输入；
- 必要上下文；
- 标准答案或评分规则；
- 关键判分点；
- 风险标签；
- 允许的答案变体。
如果没有判分点，评测就会变成“感觉好不好”。这类评测无法复盘，也无法稳定复用。
4. 指标不要只看总分
总分适合汇报，不适合诊断。真正有价值的是分维度指标。
例如一个智能问答系统可以拆成：
- 事实正确率；
- 引用命中率；
- 拒答准确率；
- 幻觉率；
- 答案完整度；
- 安全违规率；
- 用户可读性评分。
当总分下降时，只有分维度指标能告诉我们是检索失败、模型理解失败、提示词失效，还是安全策略误伤。
5. 人工评测与自动评测如何配合
人工评测适合定义标准，自动评测适合规模化执行。
比较稳的流程是：
- 先人工标注一批高质量样本；
- 形成明确评分规则；
- 用 LLM-as-Judge 批量评估；
- 抽样复核自动评测结果；
- 对低一致性维度重新优化规则；
- 定期把线上 badcase 加回评测集。
自动评测不是为了完全替代人工，而是把人工从重复打分中解放出来，让人工集中处理规则设计、争议样本和根因分析。
6. 安全性必须前置
安全评测不能等到上线前补一轮。它应该贯穿整个生命周期。
至少要覆盖：
- 违法违规内容；
- 偏见与歧视；
- 隐私泄漏；
- 权限越界；
- 工具误操作；
- 虚假承诺；
- 高风险场景拒答。
对于 Agent 系统，还要额外评估工具调用安全：模型是否会在证据不足时执行写操作，是否会把用户输入直接拼进命令，是否能识别权限边界。
7. 评测结果如何驱动优化
评测最大的价值不是得到一个分数，而是形成闭环。
一个有效闭环应该是：
评测发现问题 → badcase 分类 → 定位根因 → 选择优化手段 → 回归验证 → 进入监控优化手段可能是：
- 调整提示词；
- 补充检索资料；
- 改工具返回结构；
- 增加拒答策略；
- 微调模型；
- 改产品交互；
- 加人工确认环节。
不要把所有问题都归因于“模型不够强”。很多失败其实来自上下文组织、工具设计、评测口径和业务流程。
8. 总结
大模型评测是一套工程系统，不是一张打分表。
它应该随着业务阶段变化：Demo 期验证方向，开发期定义质量，上线期持续监控。它也应该连接产品、研发、算法和 QA，让每次评测都能产生明确的优化动作。
真正可靠的大模型应用，不是靠一次漂亮 Demo 证明出来的，而是靠持续评测、持续回流、持续修正打磨出来的。