规则评分:能用代码判的,先用代码判

规则评分能判什么

一条经验:凡是你能写出判断条件的,都该用规则——它不花钱,所以可以每次改动都全量跑。

实测:规则的天花板在哪

12 条人工标注样本(含 4 条"意思对但换了说法"的答案):

  人工=True  规则=False 模型=True  ❌规则判错  「一周之内都可以退。」
  人工=True  规则=False 模型=True  ❌规则判错  「会员一年不到两百块。」
  人工=True  规则=False 模型=True  ❌规则判错  「订单满五十九元即可免运。」
  人工=True  规则=False 模型=True  ❌规则判错  「两小时内必须响应。」
  人工=False 规则=True  模型=False ❌规则判错  「24 小时内响应即可。」

  规则评分准确率:7/12 (58%)
  模型判分准确率:12/12 (100%)

两类失败,方向相反:

① 漏判(把对的判成错):答案用中文数字("五十九元")、近义表达("一周之内")、换算说法("不到两百块")——字面不匹配,但意思完全正确。

② 误判(把错的判成对):最后一条更危险——标准答案是"2 小时",候选答案是"24 小时内响应即可",里面恰好包含字符 2,规则判它通过了!

这个坑非常常见:用 "2" in answer 判分,24、12、2026 全都会误命中。

把规则写得更结实(五个技巧)

# ❌ 危险:子串匹配
"2" in ans

# ✅ 用词边界 + 单位
re.search(r'(?<!\d)2\s*(小时|h)', ans)

# ✅ 数字归一化:全半角、中文数字、空格
normalize("两小时") == normalize("2 小时")

# ✅ 多个可接受表述都列上
any(p in ans for p in ["7 天", "7天", "七天", "一周", "7 个自然日"])

# ✅ 拒答识别单独判,别混进正确性
refused = any(w in ans for w in ["没有查到", "无法确认", "不掌握"])

最实用的一招是第三条:写一个 normalize() 统一处理全半角、中文数字、单位空格,再比对——本课实测里 5 个规则失败案例中,有 3 个能靠归一化救回来。

规则 + 模型的分工

成本上的现实:规则评分可以每次提交跑 500 条;模型判分跑 500 条要花钱和时间——所以主力用规则、模型判分只覆盖规则判不了的那部分,是绝大多数团队的实际做法。

🔧 动手做:给你的评测写一套结实的规则(12 分钟)

1. 跑本节代码,重点看规则判错的那 5 条,理解两类失败(漏判 / 误判)。
2. 写你的 normalize():处理全半角、中文数字、单位空格,至少覆盖你评测集里的数字表述。
3. 修掉子串误命中:检查你现有的规则,有没有 "2" in ans 这类写法?换成带词边界的正则。
4. 重跑你的评测集:规则评分准确率(以人工标注为真值)提升了多少?
5. 标记出规则判不了的那些条目——它们就是下一节模型判分的工作范围。

✅ 做到这里你应该有:一个带归一化的规则评分器 + 你的规则准确率 + 一份"规则判不了"的清单。

为什么:规则评分是评测体系的基础设施——它便宜到可以每次提交都跑,这决定了它能成为门禁(ap5.5)。模型判分再准,也不可能每次 commit 都跑 500 条。先把能自动化的自动化,把贵的留给真正需要的地方。

我的评测要判断:【描述判断标准,比如「答案里是否包含正确的金额」】。请帮我写判分函数,要求:1) 处理数字的多种表述(阿拉伯/中文数字、全半角、单位与空格);2) 避免子串误命中(如「2」命中「24」);3) 拒答识别单独返回,不混入正确性;4) 给出一组测试用例验证判分器本身正确(含容易误判的边界)。