收益：
- 确定批处理适合哪些工作负载
- 了解同步、异步和批处理之间的成本/延迟权衡
- 设计一个强大的批处理工作流程，将 custom_id 与结果相匹配
大多数法学硕士集成侧重于“实时”场景，即用户在屏幕前等待响应。但大多数专业工作负载实际上并不是实时的：一夜之间标记数千份文档，总结整个数据集，对存档中的整个通话录音进行分类。在这些问题上，没有人期望立即得到答案。重要的是要廉价且可靠地完成工作。 Batch 正是针对这些工作负载。在本单元中，您将了解同步、异步和批处理（当批处理是正确选择时）之间的区别，以及自信地匹配 custom_id 和结果的强大流程。
三种工作模式
模式
它是如何运作的
延迟
典型成本
合适的工作
同步的
您提出请求并等待响应
秒
标准型
实时聊天，即时助手
异步
您将作业排队并在完成后收到通知。
秒-分钟
标准型
后台任务、自动化步骤
批次
在一个包中发送数千个请求，然后获取结果
分钟–小时
通常有折扣
大批量、耐延迟的作业
批处理是这样的：您将数百/数千个请求作为单个“作业”发送给提供商；提供商按照自己的节奏处理它们，并在完成后批量返回所有结果。作为回报，您可以获得两件事：(1) 单位成本普遍较低，(2) 能够大批量移动而无需处理速度限制。代价是结果不会立即出现，而是要经过一段时间后才能出现。
何时批处理，何时不批处理？
该决定归结为一个问题：用户现在正在等待结果吗？
- 不，我可以持有→批次候选人。夜间标记、批量汇总、归档分类、数据充实、评估（eval）执行。
- 是的，等待屏幕→同步。实时聊天、即时建议、填写表格时提供帮助。
提示：两种模式可以在同一产品中共存。用户在实时聊天中同步工作；晚上，您将当天的所有对话提供给批次进行质量分析。将“居住需求”与“集体需求”分开是建筑的首要决定。
稳健批量流程剖析
批处理最重要的技术规则是结果匹配。
- 为每个请求提供唯一的“custom_id”。这是您生成的用于标识请求的 ID（例如，invoice-2026-07-18-000431）。
- 提交作业。所有请求都放在一个包中；每个都有自己的custom_id。
- 调查情况。您每隔一段时间就会询问状态，直到工作“完成”。
- 将结果与“custom_id”进行匹配。返回结果的顺序可能与提交顺序不同；所以永远不要按位置匹配，而是按每个结果携带的 custom_id 匹配。
- 检查每个结果的类型。一项请求可能会成功，一项可能会失败，一项可能会过期。基于成功/失败的流程。
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "对发票进行分类。仅返回 JSON。", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "对发票进行分类。仅返回 JSON。", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
注意：根据提交顺序匹配结果是批处理中的第一个错误。不保留队列。如果没有custom_id，您就无法自信地知道哪个结果属于哪个文档——错误的匹配会默默地导致错误的数据。
可复制模板
# custom_id生成规则（唯一且可追溯）格式：<isture>-<date>-<sequence>。示例：request-20260718-000431规则：工作中绝不重复；将资源记录 ID 嵌入其中。
# 批量作业卡（调度模板）作业名称：................记录数：........................型号：................（简单作业→快速模型）每个请求的Max_tokens：........................预计交付时间容差：........小时结果匹配键：custom_id出错时：重试/队列/报告
# 批量单个请求提示（简短且示意性）对此文档进行分类。只需返回此 JSON，注释：{"category":"...","urgency":"low|medium|high"}Document: """{{document}}"""
# 每个结果的结果处理伪代码: if result.status == "success": record = find(custom_id) save(record, result.output) else: add_to_fail(custom_id, result.error) # then try again
弱提示/强提示（批量作业设计）
# WEAK（脆弱设计）按照强模型的顺序发送10000个文档，按照到达的顺序保存返回结果。
# STRONG（耐用设计）使用快速模型一次性发送 10,000 个文档。为每个文档提供一个唯一的 custom_id，其中包含源记录 ID。将结果与custom_id进行匹配；将失败的进行排队，然后重试。在夜窗中运行；交货容差6小时。
强大版本；它预先定义了模型选择、匹配键、错误处理和计时。这就是安全处理数万条记录的区别。
三个迷你箱
案例 1 — 夜间标记。电子商务团队会将 200,000 条产品评论分类为情绪标签。直播同步流媒体受到速度限制并且成本高昂。他们用快速模型将工作批量进行到深夜；单位成本下降，早上整套就准备好了，也不存在限速问题。
案例 2 — 订单混乱。一个研究小组批量提取了 5,000 篇文章，但按照结果到达的顺序将结果写入文件。由于结果以不同的顺序返回，因此 5,000 篇摘要中大约有 900 篇链接到了错误的文章。他们将其重新映射到custom_id；问题解决了，这个经验成为永久的规则：“总是批量定制id。”
情况 3 — 处于错误模式的实时待机。支持团队尝试批量提供用户期望在屏幕上显示的实时响应；用户放弃了，因为结果在几分钟后才到达。他们将实时作业恢复同步，只留下批次中的夜间质量分析。教训：批处理不适用于实时备用。
常见错误
- 按位置匹配结果：不保留顺序；使用自定义 ID。
- 将实时作业转移到批处理：用户不能等待几分钟；批处理用于延迟容忍作业。
- 不处理错误情况：某些请求可能返回失败/过期；将其放入单独的队列中并重试。
- 批量中强大的模型使用反射：快速模型+批量是简单作业中最便宜的组合。
- 不使 custom_id 可追踪：如果 ID 中没有嵌入源记录，则很难将结果链接回来。
- 忘记检查情况：工作完成之前就期待结果；检查完成状态。
更深入：监控批次和管理部分故障
批处理最成熟的方面是它需要与单独调用不同的思维方式：批处理作业是一个“过程”，而不是“事件”。假设数以万计的请求都会成功是脆弱的；现实的设计从一开始就接受部分失败。每个结果的状态可以不同：成功、失败（例如无效输入）、取消或过期。强大的流程会在每个结果通过时单独处理每个结果的状态，将失败放入单独的“重试队列”中并单独运行该队列。
第二种做法是设计幂等性（运行相同的作业两次不会造成任何损害）。如果批处理被中断并重新启动它，则不应重新处理并写入两次已处理的记录。将 custom_id 绑定到源记录也可以在这里工作：“此记录是否已被处理？”在保存结果之前。检查可以防止重复输入。
第三点是直播和批处理错开。有些作业同时具有实时和批处理维度：当用户加载文档时，您可以为他们提供快速的初步摘要（同步），并在晚上重新处理同一文档以进行更深入的分析（批处理）。有意识地分离这两种模式可以优化用户体验和成本。
最后，批处理也是处理速度限制的一种方法（单元 8）。在实时同步流中发送大量数据会产生常量 429，而将相同数据量发送到批量传输可限制提供商自身调度的压力，并使作业更加可预测。
总之
对于延迟容忍和大容量工作负载来说，批处理通常是一种更便宜、更稳健的模式。他的决定是“用户现在正在等待结果吗？”决定了问题。最关键的技术规则是给每个请求一个唯一的custom_id，通过ID而不是位置来匹配结果，并分别处理每个结果的成功/失败。
应用任务
选择大批量作业（例如档案分类）。 (1) 决定该作品是现场作品还是集体作品，并证明其合理性。 （2）设计custom_id格式（包含资源记录）。 （3）填写批处理作业卡（model、max_tokens、tolerance、errorpolicy）。 (4) 编写结果处理伪代码以包含失败的请求。
清单
- [ ] 我可以在成本/延迟轴上区分同步、异步和批处理模式。
- [ ] 我可以通过提出正确的问题来决定一项工作是否适合批量。
- [ ] 我给每个请求一个唯一的custom_id，并通过ID匹配结果。
- [ ] 我可以单独处理失败/过期的结果。
- [ ] 我知道在简单的批处理作业中选择快速模型的好处。