大模型应用上线后，经常会遇到一个尴尬问题：感觉改了提示词以后更好了，但一上线又出现新错误。原因往往不是模型突然变差，而是团队没有稳定评测集。没有评测集，每次优化都像凭感觉调参。
评测集不是越大越好。更重要的是问题是否真实、答案是否可判断、边界是否覆盖、坏例是否能持续沉淀。
真实问题比编造问题更有价值
评测集最好从真实用户问题开始。用户会用不完整表达、错别字、口语、上下文省略、模糊指代来提问，这些比标准题更能暴露系统问题。只用人工编写的整齐问题，容易高估模型表现。
当然，真实问题也要清洗。要去掉隐私信息，合并重复问题，标注任务类型和期望行为。一个问题是要回答、拒答、追问，还是调用工具，必须先定义清楚，否则评测结果没有意义。
坏例要成为长期资产
线上每次出错，都应该进入坏例库。坏例不只是保存用户问题和错误答案，还要记录当时的模型版本、提示词版本、检索结果、工具调用、人工判断和修复动作。这样下次改动时，才能知道旧问题有没有复发。
坏例还要分类。事实错误、证据不足、越权回答、格式错误、工具参数错误、回答太空、过度拒答，背后的修复方法都不同。分类越清楚，优化越有方向。
边界样本决定系统底线
很多评测只看正常问题，忽略边界。真正上线后，边界样本更关键：资料缺失时是否拒答，权限不足时是否泄露，用户问题模糊时是否追问，高风险操作是否确认，模型不知道时是否编造。
这些样本不一定数量多，但必须稳定存在。每次更新模型、提示词、检索策略或工具逻辑，都要跑一遍。边界样本能保护系统底线，不让优化某个指标时把安全和可信度牺牲掉。
人工标注要有标准
人工评审不能只写“好”或“不好”。需要明确评价维度：事实是否正确，依据是否充分，表达是否可用，是否遵守权限，是否需要追问，是否过度拒答。不同标注人之间也要有一致口径。
如果资源有限，可以先维护小而稳定的核心评测集：高频问题、历史坏例、边界样本和业务关键路径。这个集合不需要一开始很大，但要每次改动都能跑，长期积累会越来越有价值。
面试里可以这样说：我不会只用人工感觉判断大模型效果，而会建设固定评测集和线上坏例集。每次优化都看哪些问题变好、哪些问题退化、是否影响成本和延迟。这样大模型应用才有持续迭代的工程基础。
评测集也要分层维护。核心回归集保持稳定，用来判断每次改动是否退化；探索集可以不断加入新问题，用来发现能力边界；线上坏例集则反映真实用户最近遇到的问题。三类集合目标不同，不能混成一个大列表。
面试里如果能说出“稳定集不轻易改，坏例集持续扩充”，会比只说收集用户反馈更专业。因为评测的价值在于可比较，集合频繁变化却没有分层，指标上下波动就很难解释。
最后还要记录评测结果的原因，而不只是分数。一次回答失败，是因为资料缺失、模型编造、格式不合规，还是权限判断错误？原因分类能指导下一步修复。否则评测分数下降了，团队仍然不知道该改检索、改提示词还是改业务规则。