一步步设计
先定义 schema 与允许空值
虚构报名邮件要抽取姓名、活动日期和联系人邮箱。字段可以 null，明确“未出现”与“无法判断”的区别。schema 约束解决类型与必填形状，不能证明邮箱真是该联系人的邮箱；语义正确性需要原文支持。
首轮得到候选，不急着写入
可用较小的生成模型或规则生成候选 JSON，保存输入、模型版本、字段跨度与解析错误。代码先检查 schema、邮箱格式和日期有效性。首轮失败也算流程成本，不能从报告里删掉。
逐字段验证语义支持
官方级联配方用 TypeSafe 的判断检查抽取值是否缺少来源或来自无关文字。本例问“该邮箱是否明确属于联系人角色”，而不是只问字符串是否存在。Noul 高低要与问题方向对应：若问“是否错误”，高值意味着升级。
升级有明确条件和终点
字段错误、来源缺失、关键冲突或验证调用失败进入升级队列。可调用更强模型重新抽取，之后仍做格式与来源检查；第二轮失败转人工，不能无限循环。正确字段与待复核字段分开保存，不让部分错误覆盖全部已有事实。
测验证器漏检与全链路费用
假设每件首轮0.01、验证0.005、升级0.04，升级率25%，虚构均值0.025。只用于算术练习，未引用当前价格。还要看错误候选被接受的比例、正确候选被升级的比例、最终错误与 p95 延迟，不能只比较小模型首次调用费。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 邮箱格式合法，但属于主办方 | 类型对，角色错 | 升级联系人字段 |
| 日期不在原文中 | 缺少来源支持 | null或重新抽取并复核 |
| 候选均受原文支持且校验通过 | 符合预设接受条件 | 保存结果与来源记录 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Offline arithmetic only; invented costs, not current prices.
initial, verification, escalation = 0.01, 0.005, 0.04
escalation_rate = 0.25
average = initial + verification + escalation_rate * escalation
print(round(average, 3)) # 0.025
# Add retries, other services, and review costs for a real study.容易踩的坑
- schema 通过就认为语义正确。
- 升级后不再验证。
- 费用报告忽略验证与失败重试。
TRY / THINK / COMPARE
先想一想，再看解析
初轮姓名对，邮箱错，是否把整条记录当正确？
展开解析
不能。记录字段级状态；按策略升级邮箱，最后仍需检查整条记录能否满足业务要求。
交付前检查
- schema、null 与字段角色清楚。
- 验证问题方向及来源可追溯。
- 升级条件、次数与人工终点明确。
- 费用包含所有阶段，漏检单独测量。
常见问题
级联一定更便宜吗？
验证费和升级率较高时可能更贵，需要实际数据。
Jev 是这里的抽取生成器吗？
本设计中它验证候选；初轮及升级的生成工作由其他组件完成。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。