最近 OpenAI 官方 Cookbook 联合 Fractional AI 发布了一份非常硬核的实战案例: 用 AI 自动审核报销单据。乍听是个普通的 OCR 任务, 真正点开 Notebook 才发现, 这其实是一份关于"如何把 AI 应用从 demo 推向生产"的方法论圣经, 也是当前业界讨论最热的 Eval-Driven System Design (评估驱动系统设计) 最完整的开源示例。
更有意思的是这套方法论解决的不是技术问题, 而是一个困扰所有 AI 工程师的根本问题: 如何确认我改的 prompt 是真的变好了, 还是只是看起来变好了? 本文将用最通俗的方式拆解这个 OpenAI 收据审核 案例, 提炼出 5 个对所有 AI 应用开发者都有启发的工程经验。
🎯 快速导览: 案例来自 cookbook.openai.com 的 eval_driven_system_design 目录, 作者是 Fractional AI 团队 (Hugh Wimberly / Joshua Marker / Eddie Siegel) 与 OpenAI Shikhar Kwatra。完整代码位于 OpenAI 官方 Cookbook 仓库, 通过 API易 apiyi.com 这类 OpenAI 官转网关可以一字不改地复现整套流程, 适合国内开发者直接学习。
OpenAI 收据审核案例的业务背景: 为什么这是真问题
在直接讲技术之前, 我们先把案例的商业背景讲清楚。这不是一个为了演示 API 而硬造的玩具问题, 而是一个非常真实、有明确 ROI 数字的企业场景。
| 业务维度 | 具体数字 | 含义 |
|---|---|---|
| 年处理量 | 约 100 万张 | 中型企业典型规模 |
| AI 单张处理成本 | $0.20 | 模型调用费 |
| 人工审核单价 | $2.00 | 财务人员复核 |
| 漏审罚款 | $30 / 单 | 合规/税务处罚 |
| 当前人工审核率 | 5% | 仅疑难单据 |
把这些数字相乘你会发现, 哪怕是 1% 的审核准确率提升, 落到 100 万单的体量上就是 数十万美元的年化收益。这就是 Fractional AI 团队反复强调的"把评估指标绑定到美元 (Dollar Impact)"——不是为了卷指标, 而是为了让每一次 prompt 改动都对应得上业务账本。
整个 AI 系统的目标也非常明确: 用 GPT-4o 自动审核大部分单据, 只把"低置信度"的少量单据交给人工, 让审核成本和漏审风险都降下来。听起来简单, 但魔鬼藏在细节里。
Eval-Driven Design 是什么: 一个吃过亏才会懂的方法论
如果你问 100 个 AI 工程师"你们怎么验证 prompt 改得对不对", 99 个会告诉你"跑几个例子看看输出感觉对不对"。这就是 Fractional AI 团队抨击的 vibe-coding (凭感觉调), 也是 Eval-Driven Design (以下简称 EDD) 想要彻底取代的开发方式。
两种开发方式的差异可以用下面这张表说清楚:
| 对比维度 | Vibe-Coding (凭感觉调) | Eval-Driven Design (评估驱动) |
|---|---|---|
| 验证方式 | 跑 3-5 个例子看输出 | 跑 20-100+ 个标注样本算指标 |
| 改动判断 | "感觉好像变好了" | "准确率从 78% 提升到 85%" |
| 业务对齐 | 凭感觉是否重要 | 直接换算成美元影响 |
| 回归风险 | 改 A 可能改坏 B 没人知道 | 全套指标自动跑过 |
| 协作扩展性 | 只有原作者看得懂 | 任何工程师能 debug |
Fractional AI 在文章里有一句话被广泛引用: "评估不是工具, 而是做专业 AI 开发唯一的方式"。这句话听起来夸张, 但在收据审核这种业务关键场景中, 没有 evals 等于在生产环境玩抽奖, 没人敢真正放心地 ship。
💡 类比理解: Eval-Driven Design 就像考试有标准答案, 你能算出每次改动让"卷子总分"提升了多少。Vibe-Coding 则像凭感觉答题, 改完一道题不知道是变好还是变差。生产级 AI 必须是前者。
OpenAI 收据审核案例的三阶段实施流程
OpenAI Cookbook 把整个案例拆成三个非常清晰的阶段, 这个流程几乎可以套到任何"图像/文档输入 + 结构化决策输出"的 AI 应用上。
下面我用最通俗的方式把每个阶段拆开来讲。
阶段一: 测试数据生成,聪明地省下 80% 标注成本
如果你以为团队是从 0 开始手工标注几千张收据图, 那就太低估工程师的偷懒能力了。Fractional AI 用了一个非常聪明的策略: 先让 V0 模型跑一遍, 再让专家修正。
具体流程是这样的: 从 Roboflow 公开数据集 (CC BY 4.0 协议) 拿 20 张真实收据图, 直接喂给一个简单版本的 GPT-4o + Pydantic 抽取流程, 拿到 V0 的输出。然后让财务领域专家在这个输出基础上做"找错改错", 而不是从零开始一字一句敲数据。
这种"先生成再修正"的方法把领域专家的时间利用率提升了 5-10 倍, 因为大部分字段 V0 已经识别对了, 专家只需要修正错的部分。最终产出的 EvaluationRecord 数据结构也很优雅, 同时记录了"原图路径、正确细节、模型预测细节、正确审核决策、模型预测审核决策", 一条记录覆盖整条流水线。
🔧 复用建议: 这套"V0 先跑一遍 → 专家修正"的标注策略, 几乎可以套到所有 AI 应用的冷启动阶段。你只需要通过 OpenAI 官转 API 平台快速跑出 V0 输出, 就能把领域专家的精力集中在最值钱的判断环节。
阶段二: 结构化输出评估,Pydantic 是真正的英雄
整个 AI 系统由两次 LLM 调用串成, 这种职责分离的设计是 EDD 的精髓之一。
async def extract_receipt_details(
image_path: str, model: str = "o4-mini"
) -> ReceiptDetails:
"""第一步: 从图像抽取结构化收据信息"""
response = await client.responses.parse(
model=model,
input=[{"role": "user", "content": [
{"type": "input_text", "text": prompt},
{"type": "input_image", "image_url": data_url}
]}],
text_format=ReceiptDetails # Pydantic 模型强约束
)
return response.output_parsed
async def evaluate_receipt_for_audit(
receipt_details: ReceiptDetails, model: str = "o4-mini"
) -> AuditDecision:
"""第二步: 基于结构化数据做审核决策"""
# ... 调用 LLM 输出 AuditDecision Pydantic 模型
为什么要拆成两步? 因为这两个任务的能力要求完全不同: 第一步是"读图识字" (vision + 信息抽取), 第二步是"逻辑判断" (推理决策)。把它们混在一个 prompt 里调用, 不仅模型容易混淆任务边界, 你想 debug 也找不到出错的环节。
ReceiptDetails 和 AuditDecision 这两个 Pydantic 模型的字段设计, 是这个案例最值得学习的地方:
| 模型 | 关键字段 | 业务含义 |
|---|---|---|
| ReceiptDetails | merchant / location / time / items / subtotal / tax / total / handwritten_notes | 收据上能看到的所有信息 |
| AuditDecision | not_travel_related / amount_over_limit / math_error / handwritten_x / reasoning / needs_audit | 审核 4 个判断条件 + 推理过程 + 最终结论 |
特别注意 AuditDecision 里的 reasoning 字段——它强制让模型在给出最终决策前写出推理过程, 这是后续做 chain-of-thought 评估的关键。也注意 needs_audit 是前面四个 bool 字段的逻辑 OR, 这种"先打分项再合成决策"的设计让评估指标可以拆得很细。
🚀 接入提示: 上面这段
client.responses.parse()是 OpenAI 最新的结构化输出接口, 能直接把 Pydantic 模型当成输出格式约束, 几乎完全消除了 JSON 解析失败的风险。我们建议通过 apiyi.com 这类 OpenAI 官转 API 平台调用, 因为该接口对 SDK 版本有要求, 官转网关确保协议同步更新。
阶段三: 迭代精进,18 个 grader 让改动都可量化
这一阶段是 EDD 真正发光的地方。Fractional AI 团队为这个收据审核系统设置了 18 个独立的评估指标 (graders), 把"系统好不好"这个模糊问题分解成 18 个可量化的小问题。
这 18 个 grader 大致分为三类:
| Grader 类型 | 代表指标 | 评估方式 |
|---|---|---|
| 抽取准确性 (9 个) | 商家名 / 地址 / 总金额匹配 | 字符串精确匹配 / 模糊匹配 |
| 审核决策准确性 (5 个) | 差旅判定 / 超额判定 / 算错检测 / 手写X识别 / 最终决策 | 二元分类准确率 |
| 业务对齐指标 (4 个) | 缺失商品 / 多出商品 / 商品准确度 / 推理质量 | LLM-as-Judge (0-10 分) |
初始评估在 20 个样本上发现了 2 个假阴性 + 2 个假阳性, 这个数字看上去不大, 但放到年 100 万单的规模就是数千起漏审。Fractional 团队的处理方式非常工程化:
- 根因分析: 看每个错例的 reasoning 字段, 找出模型卡在哪个判断
- 针对性改 prompt: 加 few-shot 示例、明确"差旅相关"定义、把 JSON 示例用 XML 包起来
- 重新跑评估集: 验证改动是真的修了 bug 而不是引入了新 bug
- 模型替换实验: 同一套 prompt 在 o4-mini 和 gpt-4.1-mini 上分别跑, 选 ROI 更优的
最后一步的结果非常震撼: 从 o4-mini 切换到 gpt-4.1-mini, 成本降低 67%, 年成本从约 $180K 降到 $170K, 而准确率几乎没有下降。如果没有完整的评估集, 谁敢做这个降本决策?
📊 关键洞察: 18 个 grader 不是为了凑数, 而是把一个看起来无法量化的问题"AI 准确不准确"分解成 18 个可独立修复、可独立度量的小问题。在 apiyi.com 上调用 OpenAI Evals API 也能创建类似的 grader 体系, 接口与官方完全兼容。
OpenAI 收据审核案例的 5 个工程启示
读完整个案例, 我提炼出 5 个对任何 AI 应用都通用的启示, 这些是花真金白银买来的经验。
启示一: 把评估绑定到美元, 不要追求所有指标都 100%
案例里有个非常反直觉的发现——商家名字识别的准确率提升对最终审核决策几乎没有影响, 因为审核规则不依赖商家名。如果团队执着于把商家名识别从 92% 提到 98%, 那是在浪费工程资源。
相反, 手写"X"的识别错误每年导致约 $75,000 的漏审损失, 这才是优先级最高的指标。所以指标的选择永远要回答一个问题: "改对这个错, 我能省多少钱?"
启示二: 先用最强模型跑通, 再考虑省钱
案例里 V0 阶段直接选了 o4-mini 这种当时最强的模型, 不是因为团队不在意成本, 而是因为他们知道让一个能力不足的模型勉强工作, 远比让一个能力过剩的模型便宜地工作要难。先跑通业务逻辑、建立完整的评估体系, 再做模型替换实验, 这个顺序不能颠倒。
启示三: 抽取和决策一定要拆开, 别贪心写一个万能 prompt
很多新手会想: 一次调用就能从图片直接得到"是否需审核"的结论, 多省钱啊! 但这种设计有两个致命缺陷: 不可调试——出错了不知道是看错图还是判错逻辑; 不可复用——抽取结果只能用于这一个决策。拆成两步看起来多调一次 API, 实际上让整个系统的可维护性提升了一个数量级。
启示四: chain-of-thought 评估能抓出"答对了但理由错"的隐患
AuditDecision 里那个看似冗余的 reasoning 字段, 在评估时被用来识别一种危险情况: 模型给出了正确的最终答案, 但推理过程是错的。这种"运气式正确"在小样本下看不出来, 一旦数据分布稍微变化就会大面积翻车。强制输出推理 + 用 LLM-as-Judge 评估推理质量, 是生产级 AI 应用的必备保险。
启示五: 标注成本可以工程化降低
不要被"AI 项目需要海量标注数据"这种刻板印象吓到。20 张 + 专家修正 V0 输出的策略已经能支撑出有用的评估集, 关键是让评估集和真实业务数据分布一致, 而不是追求样本数量。Fractional 的经验是用初期 V0 输出做"种子标注", 比从 0 开始手工标注效率提升 5-10 倍。
国内复现 OpenAI 收据审核案例的注意事项
国内开发者要复现这套 cookbook 需要解决三个问题: 能不能调到 o4-mini / gpt-4.1-mini 这些新模型、能不能用 responses.parse 这个最新接口、能不能调通 Evals API 端点。
直连 OpenAI 在国内体验非常不稳定, 尤其图像类接口因为 payload 大, 失败率比文本接口更高。用官转 API 网关基本可以一键解决这三个问题, 关键代码只需要改一行 base_url:
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url="https://vip.apiyi.com/v1", # 唯一需要改的一行
api_key="你的 API易 Key"
)
# 后续所有代码与 cookbook 一字不差
response = await client.responses.parse(
model="gpt-4.1-mini",
input=[...],
text_format=ReceiptDetails
)
这就是"OpenAI 官转 API"和"OpenAI 兼容 API"的关键差异——前者保证接口与 OpenAI 官方同步, 后者只兼容基础接口, 像 responses.parse、Evals API 这类高级能力可能不支持。复现 cookbook 这种官方案例时, 选官转网关能避免一堆兼容性坑。
OpenAI 收据审核案例 FAQ
Q1: 这套方法只能用于收据吗?
完全不是。Eval-Driven Design 适用于任何"输入相对开放、输出需要结构化决策"的场景: 合同审核、医疗影像分诊、客服质检、招聘简历筛选、欺诈检测都可以套这套三阶段流程。换汤不换药的就是 Pydantic schema 和评估 grader 的设计。
Q2: 18 个 grader 是不是太多了, 小团队搞不动?
可以从 5-6 个核心 grader 起步, 例如最终决策准确率 + 关键字段抽取准确率。重要的不是数量, 而是每个 grader 都对应一个具体的失败模式。我们建议在 apiyi.com 控制台先跑 GPT-4o 的少量样本, 等业务跑通后再扩充评估维度。
Q3: V0 直接用 o4-mini 不会很贵吗?
V0 阶段调用量通常是几十到几百次, 总成本几美元到几十美元, 完全可以承受。真正要省钱的是生产环境的百万级调用, 那时候已经有完整评估集做模型替换实验了, 就像案例里 o4-mini → gpt-4.1-mini 那一刀降了 67%。
Q4: GPT-4o Vision 读手写中文收据效果怎么样?
英文打印收据准确率非常高 (95%+), 中文打印也不错 (90%+), 中文手写则取决于字迹清晰度。建议先用 100 张真实样本建立评估集, 而不是相信 demo 视频。通过官转 API 调用 GPT-4o Vision 的成本与官方一致, 适合做大规模评估实验。
Q5: 如果我没有 Evals API 权限, 能跑这个 cookbook 吗?
可以。Evals API 主要是把 grader 配置和运行管理托管给 OpenAI, 实际评估逻辑你自己用 Python 跑也完全等效。cookbook 里的 grader 函数全部开源, 复制到本地就能用。后续如果业务规模上来了, 再考虑迁移到托管 Evals。
Q6: APIYI 调用这套案例和官方有什么区别?
接口协议、模型版本、参数支持都与 OpenAI 官方完全同步, 这是"官转"的核心承诺。区别主要在网络层面: 国内直连 OpenAI 经常出现 SSL 握手失败、超时, 而官转网关在国内 IDC 部署, 图像类接口的稳定性提升尤为明显。这对于跑长时间评估任务非常关键。
总结
OpenAI 收据审核 这个案例之所以值得反复研读, 是因为它把"如何用 AI 解决一个真实业务问题"这个抽象命题, 拆解成了三阶段、18 个评估指标、可量化到美元影响的具体工程实践。这是中文社区目前最缺的 AI 工程化范本。
如果你正在做任何"输入文档/图像、输出结构化决策"的 AI 应用, 强烈建议把这份 cookbook 完整跑一遍。不要只看不动手, eval-driven design 真正的价值要在你看到指标变化的瞬间才能感受到。我们建议通过 apiyi.com 这类 OpenAI 官转 API 平台直接复现, 可以省去环境调试的所有麻烦, 把精力集中在方法论本身。
把"评估驱动"这四个字刻进开发流程, 你的 AI 系统就从"看着挺像那么回事"的玩具, 升级成了"敢放上生产、敢算 ROI"的工程产物。这中间的差距, 可能就是 $75,000。
📌 作者: APIYI Team — 长期跟踪 OpenAI / Anthropic / Google 多模态 API 的工程实践案例, 更多 cookbook 实战解读和官转 API 接入指南见 apiyi.com 文档中心。
