怎样评估 Claude 输出 从验收标准到回归集
为自己的应用设计可复查评估,分别检验事实、格式、严重错误和运行成本。
把好用写成可观察条件
先确定结果将用于什么动作。客服摘要需要保留诉求和事实,代码建议需要通过测试,资料问答需要可追溯来源。官方评估指南强调先定义成功条件。不要把“语言流畅”当成总目标,也不要用未经校准的模型自评分替代正确答案。
准备相互分离的数据
从获得授权的材料中选代表性样例,脱敏后标注输入、理想结果、可接受变体和严重错误。用于改提示词的数据与最后验证的数据分开;重复或几乎相同的样例不要同时放在两边。边界情况要包括空输入、冲突资料、缺字段和无答案问题。
不同要求用不同评分
固定标签和字段可用程序判定;事实与语气需要明确人工规则,必要时采用模型辅助评分并与人工样本校准。评分器也会受措辞和顺序影响,应测试位置互换、冗长答案和刻意迎合评分词的情况。多个模型给出相同分数不自动成为独立证据。
一个具体的字段验收
假设任务从虚构工单提取订单号和诉求。验收时不只看JSON能否解析,还检查订单号是否来自原文、缺失时是否留空、诉求是否增加退款承诺。下面的离线函数只展示字段准确率计算;它不能评价语义正确性或业务安全。 必填字段缺失与明确输出null分开计分;额外字段、数据类型和业务规则需另做schema校验。
def field_accuracy(actual, expected):
if not expected:
raise ValueError("empty_expected")
return sum(k in actual and actual[k] == v for k, v in expected.items()) / len(expected)
assert field_accuracy({"order":"A1", "intent":"repair"},
{"order":"A1", "intent":"repair"}) == 1.0
assert field_accuracy({"order":"A1"}, {"order":"A1", "intent":"repair"}) == 0.5
assert field_accuracy({}, {"order": None}) == 0.0
assert field_accuracy({"order": None}, {"order": None}) == 1.0记录成本与不确定性
报告样本数、模型ID、提示版本、工具、时间和失败分布。质量均值之外,单列严重错误、格式失败、重试与人工介入;耗时应区分首次响应和完整交付。小样本不要给过于精确的胜负结论,一次全过也不能证明未来不会出错。
把评估纳入发布
把关键样例变成回归集,升级模型或提示词后重跑。CI可阻止格式和确定性条件退步,涉及主观或高风险判断仍需人工审核。阈值应根据业务风险确定,不照搬文章里的示范数字。保存失败案例并定期更新分布,防止只对固定题库表现良好。
参考来源
资料核对日期:2026-10-04。涉及产品与账户条件时,请以当前官方说明为准。