先建评测集，再写提示词：一套可落地的做法

「我改了下提示词，感觉准了一点。」

这句话是 AI 项目里最危险的一句话。它意味着团队正在凭直觉做优化， 而直觉在这个领域出错的概率高得惊人——我们做过盲测， 工程师对「这次改动是变好还是变坏」的判断准确率大约在六成左右， 比抛硬币好一点，但远不足以支撑决策。

这篇写我们实际在用的做法。不涉及复杂工具，核心就是一个 JSONL 文件和一个评分函数。

第一步：先收集失败案例，而不是设计测试用例

很多团队建评测集的方式是坐在会议室里"设计"问题。这样产出的样本 往往偏简单、偏均匀，跟真实用户的提问分布差得很远。

更好的顺序是：先让系统跑起来（哪怕很粗糙）， 收集 200 条真实提问，然后从里面挑。挑的原则是：

• 60% 高频常见问题——这决定用户的日常体感
• 25% 已知会答错的问题——这是优化的靶子
• 15% 应该拒答的问题——超出范围、信息不足、或者有安全风险的

最后那 15% 是最容易被忘掉、也最重要的。一个不会拒答的系统在专业场景里是不能上线的。

第二步：让业务专家标注，不要让工程师标注

工程师标注出来的"正确答案"，业务专家看了往往会说"这么写不行"。 标注这件事必须由真正懂业务的人做，工程师的角色是设计标注格式、 把标注过程做得足够省力。

实操经验：一次标注会议控制在两小时以内，一次标 30–50 条。 超过这个量标注质量会明显下降。三到四次会议能出一套 150 条左右的可用评测集。

标注格式我们用得最顺的是这样——注意它记录的不是"标准答案全文"， 而是可判定的约束条件：

# 评测集就是一个 JSONL 文件。不需要平台，不需要框架。
{"id": "defect-0142",
 "question": "KYN28-12 开关柜出现局放告警，怎么处理？",
 "must_include": ["停电检查", "局部放电检测"],
 "must_not_include": ["带电操作"],
 "must_cite": ["Q/GDW-1799.1-2013"],
 "acceptable_refusal": False,
 "labeled_by": "王工", "date": "2026-03-11"}

# 评分：能用规则判的就别用 LLM 判，便宜且稳定
def score(case, answer, citations):
    if case["must_not_include"] and any(
            k in answer for k in case["must_not_include"]):
        return 0, "contains forbidden guidance"   # 安全红线，直接 0 分
    hit = sum(k in answer for k in case["must_include"])
    cite_ok = set(case["must_cite"]) <= set(citations)
    return hit / len(case["must_include"]) * (1 if cite_ok else 0.5), ""

为什么不记标准答案全文？因为自然语言的表达方式太多， 逐字比对没有意义，而用 LLM 判断语义相似又引入了新的不确定性。 记关键词和引用要求，用规则就能判，稳定、便宜、可复现。

第三步：分层评分，安全项一票否决

不是所有错误都等价。在设备运维场景里，"漏掉一个检查步骤"和 "建议带电操作"是完全不同量级的问题。所以评分要分层：

1. 安全红线——出现即 0 分，且触发告警。这一项不参与平均分计算， 单独统计，必须为零。
2. 引用正确性——引用了不存在的文件，或者引用错了条款， 按半分计。这一项是幻觉的直接指标。
3. 要点覆盖——关键处置步骤覆盖了多少，这是主要的准确率指标。
4. 拒答正确性——该拒答的拒答了没有，不该拒答的是不是过度保守了。

我们通常汇报四个数字而不是一个"准确率"。一个数字掩盖了太多信息： 要点覆盖从 78% 涨到 85%，但拒答率从 12% 掉到 3%——这不是进步，是模型变得更爱瞎猜了。

第四步：每次改动都跑回归，看 diff 而不是看均值

这是评测集真正发挥价值的地方。改完提示词跑一遍全量， 输出的不应该只是"准确率 82% → 84%"，而应该是：

• 变对了：12 条（列出 id）
• 变错了：5 条（列出 id 和差异）
• 无变化：133 条

那 5 条变错的必须逐条看。很多时候均值涨了但变错的恰好是最重要的场景， 这种改动应该回退。只看均值是看不出来的。

评测集的价值不在于告诉你系统有多好， 而在于告诉你刚才那个改动到底做了什么。

关于用 LLM 做评委

LLM-as-judge 有用，但我们把它放在最后，而且只用在规则判不了的地方， 比如"回答的语气是否符合客服规范"。使用时注意三点：

• 给评委模型明确的评分标准和示例，不要只说"打个分"
• 让它先输出理由再输出分数，顺序反了准确率会下降
• 定期抽样人工复核评委的判断——评委也会漂移

成本和收益

建一套 150 条的评测集，大致需要业务专家 6–8 小时、工程师 2–3 天。 这个投入在项目初期看起来很奢侈，尤其是当所有人都急着看到 Demo 的时候。

但它带来的是：改动可以被验证、模型可以被替换、 效果承诺可以写进合同、以及最重要的——当客户问"到底准不准"的时候， 你有一个可以拿出来讨论的数字，而不是一句"感觉还不错"。