评测集怎么建：没有它就只能凭感觉调

AI 项目调优最常见的工作方式是：改一处、试几个问题、觉得变好了、提交。问题在于「试几个问题」每次试的不是同一批，而主观印象对变化的敏感度很低 —— 准确率从七成掉到六成，凭感觉基本察觉不到。

题目从哪里来

最好的来源是真实发生过的提问：客服记录、搜索日志、试用期间用户实际输入的内容。自己编的题目有一个系统性偏差 —— 编题的人知道系统能做什么，会不自觉地避开它不擅长的表述。

分布也要接近真实。如果线上八成是简单的常见问题、两成是复杂的，评测集也应当大致如此。全部用难题组成的评测集会让人低估系统的实际表现，反过来也一样。

必须包含的几类

• 正常问题：覆盖主要业务场景，这是主体；
• 边界问题：材料里没有答案的、信息不完整的、超出服务范围的。这类题检验的是系统会不会硬答；
• 表述变体：同一个意思的不同问法、口语化表达、有错别字的输入；
• 已经出过错的真实案例：每修复一个线上问题就把它加进来，形成回归保护。

多少条够用

几十条就能发现明显的回归，两三百条能给出比较稳定的准确率估计。规模不是越大越好 —— 评测集需要维护，每次业务变化都要复核期望答案，太大反而会荒废。从三五十条开始，随着发现问题逐步补充，是比较实际的路径。

没有标准答案的题怎么评

很多问题的答案不唯一，不能用逐字匹配。可行的做法是检查几个要点是否出现：必须提到的关键信息有没有、不应出现的内容有没有出现、格式是否符合要求。把这些要点写成清单，评判就从主观变成了可重复的核对。

用另一个模型来评分也是常见做法，但要清楚它本身也会出错，适合做初筛，不适合作为唯一依据。关键的那部分题仍然需要人工确认。

怎么用

每次改动提示词、换模型、调整检索参数之后，全量跑一遍并记录结果。重点不是绝对分数，而是和上一次比哪些题变好了、哪些变差了。变差的那几题往往比整体分数更有信息量。相关的验收口径见企业知识库解决方案与合作流程。