字段级评测:整条 100 分,照样有问题

实测:两种看法,两个结论

15 条标注样本(含 5 条难样本:口语化渠道"小程序"、"半打"、"一打鸡蛋"、含优惠券、昵称当客户名):

【整条准确率】15/15 (100%)  ← 大多数教程只报这一个数

【字段级准确率】
  客户名                    15/15 (100%) ████████████████████
  渠道(枚举)                15/15 (100%) ████████████████████
  总额                     15/15 (100%) ████████████████████
  数量合计                  15/15 (100%) ████████████████████
  总额==明细加总(一致性)      13/15 ( 87%) █████████████████

【错例明细】
  金额一致性:
    「孙姐从咱们小程序上买的,两提抽纸 39.9…」 计算不符
    「王工 App 下单,买了一打鸡蛋 26 元和…」   计算不符

两条错例都很有代表性:

• 第一条含优惠券(39.9×2=79.8,实付 69.8,差的 10 元是券)——模型提取都对,但明细加总天然≠实付;
• 第二条是单位换算("一打鸡蛋"= 12 个,单价是整打的 26 元)——qty 和 price 的口径不一致。

这两条不是模型的错,是你的 schema 没设计好:没有"优惠金额"字段、没规定 qty/price 的口径。而你只有做了一致性检查才会发现这件事。

三层评测,层层往下挖

优化顺序:先看第 3 层(矛盾说明设计有问题)→ 再修第 2 层最低的字段 → 第 1 层自然会涨。

一致性检查怎么设计

针对你的业务写"字段之间应该满足什么关系":

# 金额自洽
calc = sum(i["qty"] * i["price"] for i in data["items"])
assert abs(calc - data["total"]) < 0.01, "明细加总 != 总额"

# 区间合理
assert 0 < data["total"] < 100000, "总额超出合理范围"

# 逻辑一致
if data["status"] == "已退款":
    assert data["refund_time"] is not None, "已退款但无退款时间"

# 枚举与业务规则
if data["channel"] == "phone":
    assert data["operator"] is not None, "电话订单必须有接线员"

这些规则的价值远超"多抓几个错":它们是你的业务知识被写成代码——新人看这段就懂你们的业务规则,而且每次评测都在验证它。

字段级评测的两个副产品

1. 知道该给哪个字段加少样本(ap2.3):渠道识别差 → 给渠道加几个口语化例子,而不是整体重写提示词;
2. 知道哪些字段该做人工复核(ap3.4):准确率最低的字段 = 最该标记 needs_human 的字段。

🔧 动手做:给你的提取建三层评测(15 分钟)

1. 跑本节代码 field_eval.py,看三层结果。
2. 换成你的字段:改 GOLD(至少 15 条,含 5 条难样本)和检查逻辑。
3. 重点设计一致性检查:写下你业务里至少 3 条"字段之间必须满足的关系",写成代码。
4. 跑一遍,看哪个字段最低——那就是你下一步优化的靶子。
5. 针对最低的字段做一次改进(补规则或补少样本),重跑,用 ap2.5 的噪声地板判断是不是真提升。

✅ 做到这里你应该有:三层评测脚本、你的字段准确率排行、至少 3 条一致性规则、一次针对性优化的前后对比。

为什么:这是 AP3 的收口,也是 AP5 评测体系的预演。"整条准确率"是给老板看的,"字段级 + 一致性"是给自己用的——前者告诉你有没有问题,后者告诉你去哪修。没有第二、三层,你的优化只能靠猜。

我的提取 schema 是:【粘贴】。业务背景:【一句话】。请帮我列出 5-8 条「字段之间必须满足的关系」,写成可执行的断言代码(比如金额自洽、区间合理、逻辑依赖、枚举与其他字段的关联),并说明每条能抓住什么样的现实错误。