利益:
- バッチ処理がどのワークロードに適しているかを判断します
- 同期、非同期、バッチ処理の間のコストとレイテンシのトレードオフを理解する
- Custom_id と結果を照合する堅牢なバッチ ワークフローを設計します。
ほとんどの LLM 統合は、ユーザーが画面の前で応答を待っている「ライブ」シナリオに焦点を当てています。しかし、プロのワークロードの大部分は実際には稼働していません。一晩で数千のドキュメントにタグ付けしたり、データセット全体を要約したり、アーカイブ内の通話録音全体を分類したりする必要があります。こうした問題については、誰も即座に答えが得られることを期待していません。大切なのは安く確実に仕事を終わらせることです。 Batch はまさにこれらのワークロードに適しています。この単元では、同期、非同期、バッチ処理の違いと、バッチが正しい選択である場合の、custom_id と結果を確実に照合する堅牢なフローについて学びます。
3 つの動作モード
モード
どのように機能するのか
遅延
一般的なコスト
適職
同期
リクエストを送信し、応答を待ちます
秒
標準
ライブチャット、インスタントアシスタント
非同期
ジョブをキューに入れ、完了すると通知を受け取ります。
秒～分
標準
バックグラウンドタスク、自動化ステップ
バッチ
1 つのパッケージで数千のリクエストを送信し、結果を取得します
分～時間
通常は割引されます
大量の遅延を許容するジョブ
バッチ処理は次のとおりです。数百または数千のリクエストを単一の「ジョブ」としてプロバイダーに送信します。プロバイダーは独自のペースでそれらを処理し、完了するとすべての結果を一括して返します。その代わりに、(1) 一般的に単価が安くなる、(2) 速度制限に対処することなく大量に移動できる、という 2 つのメリットが得られます。その代償として、結果はすぐには得られず、時間が経ってから現れます。
バッチ処理を行う場合とそうでない場合は?
決定は 1 つの質問に帰着します。ユーザーは今結果を待っているのか?
- いや、持てる→バッチ候補。夜間タグ付け、バッチ要約、アーカイブ分類、データ強化、評価 (eval) の実行。
- はい、画面上で待機中→同期します。ライブチャット、即時アドバイス、フォーム記入時のサポート。
ヒント: 同じ製品内で 2 つのモードを共存できます。ユーザーはライブチャットで同期的に作業します。夜には、品質分析のためにその日のすべての会話をバッチに渡します。 「生活上のニーズ」と「集団のニーズ」を分離することが建築の最初の決定です。
堅牢なバッチ フローの構造
バッチ処理の最も重要な技術的ルールは、結果のマッチングです。
- 各リクエストに一意の「custom_id」を与えます。これはリクエストを識別する生成された ID です (例: invoice-2026-07-18-000431)。
- ジョブを送信します。すべてのリクエストは 1 つのパッケージにまとめられます。それぞれに独自のcustom_idが付いています。
- 状況を調査します。ジョブが「完了」するまで、一定の間隔でステータスを要求します。
- 結果を「custom_id」と照合します。結果は、送信順序とは異なる順序で返される場合があります。したがって、位置によって一致することはなく、各結果が持つcustom_idによって一致します。
- 各結果のタイプを確認してください。 1 つのリクエストは成功する可能性があり、1 つは失敗する可能性があり、もう 1 つは期限切れになる可能性があります。成功/失敗に基づいたプロセス。
{ "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 を埋め込みます。
# バッチジョブカード (スケジュールテンプレート)ジョブ名: ............................レコード数: ............................モデル: ........................ (単純ジョブ → 高速モデル)リクエストあたりの最大トークン数: ............................予想納期許容範囲: ......... 時間結果一致キー:custom_idエラーの場合: リトライ / キュー / レポート
# バッチ内の 1 つのリクエスト プロンプト (短い図式) このドキュメントを分類します。次の JSON をコメントとして返します:{"category":"...","urgency":"low|medium|high"}Document: """{{document}}"""
# 各結果の結果処理疑似コード: if result.status == "success": Record = find(custom_id) save(record, result.output) それ以外の場合: add_to_fail(custom_id, result.error) # その後、再試行します
弱いプロンプト / 強いプロンプト (バッチ ジョブ設計)
# WEAK (脆弱な設計) 強力なモデルで 10,000 件のドキュメントを順番に送信し、返された結果を到着順に保存します。
# STRONG (耐久性のある設計) 高速モデルで 10,000 枚のドキュメントを一度に送信します。各ドキュメントに、ソース レコード ID を含む一意の Custom_id を与えます。結果をcustom_idと照合します。失敗したものをキューに入れて再試行します。夜間ウィンドウで実行します。配達許容範囲は6時間です。
強力なバージョン。モデルの選択、キーの照合、エラー処理、タイミングが事前に定義されています。これは、数万のレコードを安全に処理する場合の違いです。
ミニケース3個
ケース 1 — 夜間のタグ付け。 e コマース チームは、200,000 件の製品レビューをセンチメント タグに分類します。ライブ同期ストリーミングには速度制限があり、コストがかかりました。彼らは、高速モデルを使用して作業を夜間にまとめて実行しました。単価は下がり、朝にはすべてのセットが準備でき、速度制限の問題もなくなりました。
ケース 2 — 注文の混乱。研究チームは 5,000 件の論文をバッチで要約しましたが、結果は到着した順にファイルに書き込まれました。結果が異なる順序で返されたため、5,000 件の要約のうち約 900 件が間違った記事にリンクされていました。彼らはそれをcustom_idに再マップしました。問題は解決され、このエクスペリエンスは「常にバッチ内のカスタム ID」という永続的なルールになりました。
ケース 3 — 間違ったモードでのライブ スタンバイ。サポート チームは、ユーザーが画面上で期待するライブ応答をバッチで提供しようとしました。結果が数分後に届いたため、ユーザーは放棄しました。彼らはライブ ジョブを同期に戻し、バッチには夜間の品質分析のみを残しました。教訓: バッチはライブ スタンバイ用ではありません。
よくある間違い
- 位置による結果の照合: 順序は保持されません。 Custom_id を使用します。
- ライブ ジョブをバッチに転送: ユーザーは何分も待つことができません。バッチは遅延を許容するジョブ用です。
- エラーケースを処理しない: 一部のリクエストは失敗または期限切れを返す場合があります。別のキューに入れて再試行してください。
- バッチでの強力なモデル使用反射: 単純なジョブでは、高速なモデル + バッチが最も安価な組み合わせです。
- Custom_id を追跡可能にしない: ID にソース レコードが埋め込まれていない場合、結果をリンクすることが困難になります。
- 状況を検討することを忘れる: 仕事が終わる前に結果を期待する。完了ステータスを確認します。
さらに詳しく: バッチの監視と部分的な障害の管理
バッチ処理の最も成熟した側面は、個々の呼び出しとは異なる考え方が必要であることです。つまり、バッチ ジョブは「イベント」ではなく「プロセス」です。何万ものリクエストがすべて成功すると仮定するのは脆弱です。現実的な設計は最初から部分的な故障を許容します。各結果のステータスは、成功、失敗 (無効な入力など)、キャンセル、または期限切れなど、異なる場合があります。堅牢なフローは、各結果が通過するときにそのステータスを個別に処理し、失敗を別の「再試行キュー」に入れて、そのキューを個別に実行します。
2 番目の実践は、冪等性 (同じジョブを 2 回実行しても問題が発生しないこと) を考慮して設計することです。バッチが中断され、バッチを再開する場合は、既に処理されたレコードを再処理して 2 回書き込むべきではありません。 Custom_id をソース レコードにバインドすることは、ここでも機能します。「このレコードはすでに処理されていますか?」結果を保存する前に。チェックを入れることで二重入力を防ぐことができます。
3 番目のポイントは、バッチでライブ ストリームを時間差で実行することです。一部のジョブにはライブ ディメンションとバッチ ディメンションの両方があります。ユーザーがドキュメントをロードするときに、簡単な予備的な概要をユーザーに提供し (同期)、夜間に詳細な分析を行うために同じドキュメントを再処理します (バッチ)。 2 つのモードを意識的に分離することで、ユーザー エクスペリエンスとコストの両方が最適化されます。
最後に、バッチ処理は速度制限に対処する方法でもあります (ユニット 8)。ライブ同期フローで大量の送信を行うと定数 429 が生成されますが、同じ量をバッチ転送に送信すると、プロバイダー自身のスケジューリングへの負担が制限され、ジョブがより予測可能になります。
要約すれば
バッチ処理は、一般に、耐遅延性が高く、大量のワークロードにとって、より安価で堅牢なモードです。彼の決断は、「ユーザーは今結果を待っているのか？」というものでした。質問が決まります。最も重要な技術的ルールは、各リクエストに一意のcustom_idを与え、結果を場所ではなくIDで照合し、各結果の成功/失敗を個別に扱うことです。
アプリケーションタスク
大量のジョブ (アーカイブ分類など) を選択します。 (1) この作品がライブ作品であるか集団作品であるかを判断し、それを正当化します。 (2)custom_id形式を設計します(リソースレコードを含めます)。 (3) バッチ ジョブ カード (モデル、max_tokens、許容値、エラー ポリシー) を入力します。 (4) 失敗したリクエストを含めた結果処理の擬似コードを記述します。
チェックリスト
- [ ] コスト/遅延軸で同期モード、非同期モード、バッチ モードを区別できます。
- [ ] 適切な質問をすることで、ジョブがバッチに適しているかどうかを判断できます。
- [ ] 各リクエストに一意のcustom_idを与え、結果をIDで照合します。
- [ ] 失敗した/期限切れの結果を個別に処理できます。
- [ ] 単純なバッチ ジョブで高速モデルを選択する利点はわかっています。