4.5 Batch Processing Strategies

Những gì cần nắm

Message Batches API là công cụ tối ưu chi phí, kèm theo những ràng buộc cứng mà đề thi hỏi thẳng. Biết khi nào nên dùng — và khi nào không — chính là lõi của task statement này.

Message Batches API: các con số

Ràng buộc là cố định, và bạn phải thiết kế xoay quanh chúng:

Giảm 50% chi phí so với gọi API đồng bộ
Cửa sổ xử lý tối đa 24 giờ — kết quả có thể về sau vài phút, cũng có thể mất tới 24 giờ
Không có SLA về độ trễ — bạn không thể trông cậy kết quả về trong bất kỳ khung thời gian cụ thể nào
Không hỗ trợ multi-turn tool calling trong một batch request — model không thể chạy tool giữa chừng rồi dùng kết quả để xử lý tiếp
Field custom_id để ghép cặp request/response — mỗi request trong batch có một định danh riêng dùng để khớp với response của nó

Quy tắc ghép đúng workflow

Đây là khái niệm bị hỏi nhiều nhất trong task statement này:

API đồng bộ: Dành cho workflow chặn, tức là có người hoặc có thứ gì đó đang chờ kết quả. Pre-merge check trong CI/CD, phản hồi code review thời gian thực, mọi workflow mà developer bị chặn cho tới khi có kết quả.

Batch API: Dành cho workflow chịu được độ trễ, kết quả được tiêu thụ sau. Báo cáo technical debt chạy qua đêm, tổng hợp code audit hàng tuần, sinh test ban đêm, extraction tài liệu theo lô.

Đề thi có một tình huống cụ thể (Câu 11 trong bộ câu hỏi mẫu) trong đó một quản lý đề xuất chuyển hết mọi thứ sang batch để tiết kiệm chi phí. Đáp án đúng là giữ workflow chặn ở chế độ đồng bộ và chỉ chuyển những workflow chịu được độ trễ sang batch.

// Synchronous — developer is waiting for this
const preMergeReview = await client.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 4096,
  messages: [{ role: "user", content: prDiffContent }]
});

// Batch — results consumed tomorrow morning
const batchRequest = await client.messages.batches.create({
  requests: technicalDebtDocuments.map((doc, i) => ({
    custom_id: `debt-report-${i}`,
    params: {
      model: "claude-sonnet-5",
      max_tokens: 4096,
      messages: [{ role: "user", content: doc }]
    }
  }))
});

Tính lịch theo SLA

Khi lên lịch batch processing, bạn phải tính theo cửa sổ xử lý tối đa 24 giờ. Nếu tổ chức yêu cầu SLA 30 giờ cho một báo cáo:

24 giờ là cửa sổ tối đa, không phải cam kết giao kết quả. Batch không xong trong khoảng đó sẽ trả về trạng thái expired, nên hãy tính lịch theo đúng tình huống xấu nhất và coi batch expired là ca phải submit lại
SLA 30 giờ trừ 24 giờ tình huống xấu nhất = 6 giờ đệm để gom request, validate input hoặc hấp thụ các trục trặc vận hành
Submit batch mỗi 4 giờ trong khoảng đệm đó để luôn có một batch mới đang chạy. Nhịp 6 giờ không chừa lại chút biên nào

Đề thi có thể ra câu hỏi lên lịch, trong đó bạn phải tính ngược từ SLA ra tần suất submit.

Xử lý request thất bại trong batch

Không phải tài liệu nào trong batch cũng thành công. Pattern xử lý thất bại đúng gồm ba bước:

1. Xác định request thất bại theo custom_id. Mỗi request có một định danh riêng. Parse kết quả batch để tìm những custom_id nào đã fail.

2. Chỉ submit lại phần thất bại, kèm chỉnh sửa. Đừng submit lại cả batch. Các chỉnh sửa hay dùng gồm:

Chia nhỏ tài liệu quá khổ vượt giới hạn context
Đơn giản hóa prompt extraction cho tài liệu có cấu trúc lạ
Thêm few-shot example theo định dạng cho những tài liệu fail vì cấu trúc khác thường

3. Tinh chỉnh prompt trên một tập mẫu TRƯỚC khi chạy batch. Đây là bước chủ động giúp tối đa hóa tỷ lệ thành công ngay lượt đầu và giảm chi phí submit lại. Hãy thử prompt trên một tập mẫu đại diện (5–10 tài liệu phủ hết các định dạng và edge case) trước khi chạy toàn bộ batch.

// Poll until the batch has finished before reading results
let batch = await client.messages.batches.retrieve(batchId);
while (batch.processing_status !== "ended") {
  await new Promise(r => setTimeout(r, 60_000));
  batch = await client.messages.batches.retrieve(batchId);
}

// results() returns a JSONL async iterable, not an array — accumulate it.
// Treat `expired` as a failure too: that is what an overrun batch returns.
const failedIds: string[] = [];
for await (const result of client.messages.batches.results(batchId)) {
  if (result.result.type === "errored" || result.result.type === "expired") {
    failedIds.push(result.custom_id);
  }
}

// Resubmit only failures with modifications
const retryRequests = failedIds.map(id => {
  const originalDoc = documentsById[id];
  return {
    custom_id: `${id}-retry-1`,
    params: {
      model: "claude-sonnet-5",
      max_tokens: 8192,  // increased for oversized docs
      messages: [{
        role: "user",
        content: chunkIfNeeded(originalDoc)
      }]
    }
  };
});

Giới hạn về multi-turn tool calling

Batch API không hỗ trợ multi-turn tool calling trong một request. Nghĩa là bạn không thể:

Định nghĩa tool rồi để model gọi chúng giữa chừng request
Xử lý tool result và tiếp tục hội thoại trong cùng một item của batch
Chạy agentic loop bên trong một batch request

Nếu workflow của bạn cần chạy tool giữa chừng, bạn phải dùng API đồng bộ. Giới hạn này là điểm thi trực tiếp — nếu một tình huống mô tả batch workflow cần gọi tool bên ngoài trong lúc xử lý, đáp án đúng là dùng API đồng bộ cho bước đó.

Exam guide v1.0 phát biểu giới hạn đúng như trên, và đó là đáp án được chấm. Tài liệu batch processing của Anthropic (kiểm tra tháng 9/2026) nay tách giới hạn này theo loại tool. Server tool (web search, web fetch, code execution, MCP connector, tool search) chạy đúng cái agentic loop phía server bên trong một batch request giống như khi chạy đồng bộ, và một kết quả batch có thể trả về với stop_reason: "pause_turn" để bạn tiếp tục ở request kế. Client tool, tức những tool do chính code của bạn chạy, vẫn không hoàn tất được một vòng lặp bên trong một batch item: request kết thúc ở tool_use, bạn chạy tool sau khi lấy kết quả, rồi submit một request tiếp theo. Khi đề bài nhắc tới một tool do code của bạn chạy (một truy vấn nội bộ, một câu query database), quy tắc của guide và tài liệu hiện tại cho cùng một đáp án. Trong phòng thi, trả lời theo guide: không có multi-turn tool calling trong batch request, nên bước nào cần chạy tool giữa chừng thì chạy trên API đồng bộ.

Tối ưu prompt trước khi submit batch

Chiến lược batch processing tiết kiệm nhất là dồn thời gian vào tinh chỉnh prompt trước khi submit khối lượng lớn:

Thử trên tập mẫu: Lấy 5–10 tài liệu đại diện, phủ hết các định dạng, edge case và loại tài liệu có trong batch
Lặp trên tập mẫu: Tinh chỉnh prompt extraction, thêm few-shot example, chỉnh thiết kế schema cho tới khi tập mẫu đạt độ chính xác cao
Submit toàn bộ batch: Với prompt đã tinh chỉnh, tỷ lệ thành công ngay lượt đầu sẽ cao hơn hẳn
Xử lý phần thất bại: Chỉ submit lại những tài liệu fail, kèm chỉnh sửa nhắm đúng nguyên nhân

Quy trình này cắt mạnh tổng chi phí. Tỷ lệ thành công lượt đầu 90% trên 1.000 tài liệu nghĩa là chỉ 100 lần retry. Tỷ lệ 60% nghĩa là 400 lần retry, gấp bốn lần chi phí submit lại, cộng thêm chi phí batch processing cho chính số retry đó.

Bẫy thi

Tình huống luyện tập

Team bạn muốn giảm chi phí API cho phần phân tích tự động. Bạn có hai workflow: (1) một pre-merge check chặn, phải xong trước khi developer merge, và (2) một báo cáo technical debt sinh qua đêm để xem vào sáng hôm sau. Quản lý của bạn đề xuất chuyển cả hai sang Message Batches API để tiết kiệm 50% chi phí. Bạn đánh giá đề xuất này thế nào?

A. Chuyển cả hai sang batch processing và poll trạng thái để biết khi nào xong
B. Chỉ dùng batch processing cho báo cáo technical debt; giữ call thời gian thực cho pre-merge check
C. Giữ call thời gian thực cho cả hai để tránh vấn đề thứ tự kết quả trong batch
D. Chuyển cả hai sang batch processing, kèm cơ chế timeout fallback về thời gian thực nếu batch chạy quá lâu

Đáp án & giải thích

Đúng: B

A — Poll trạng thái không thay đổi được ràng buộc gốc: batch API không có SLA về độ trễ. Pre-merge check không thể phụ thuộc vào cửa sổ xử lý 24 giờ, bất kể chiến lược poll thế nào.
B — Pre-merge check là workflow chặn — developer đang chờ kết quả. Cửa sổ xử lý 24 giờ là không chấp nhận được. Báo cáo technical debt chạy qua đêm và chịu được độ trễ, quá hợp để chạy batch với mức tiết kiệm 50%.
C — Kết quả batch được ghép cặp bằng field custom_id, nên thứ tự không phải vấn đề. Mối lo thật là yêu cầu về độ trễ, và đáp án này nhận diện sai.
D — Cách này thêm phức tạp không cần thiết. Cách đơn giản và đúng là ghép mỗi workflow với API phù hợp dựa trên yêu cầu độ trễ của nó.

Nguồn

Claude Certified Architect Foundations Exam Guide — Task Statement 4.5 — Anthropic
Message Batches API — Anthropic
Building with Claude API (Skilljar) — Anthropic

Exam Simulator

Sáu câu trắc nghiệm theo format đề thi về Batch Processing Strategies. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Quản lý của bạn đề xuất chuyển cả pre-merge code review (workflow chặn) lẫn báo cáo technical debt qua đêm sang Message Batches API để tiết kiệm 50% chi phí. Bạn đánh giá đề xuất này thế nào?

A. Chuyển cả hai sang batch processing và poll trạng thái để biết khi nào xong
B. Giữ call thời gian thực cho cả hai để tránh vấn đề thứ tự kết quả trong batch
C. Chỉ dùng batch processing cho báo cáo technical debt, giữ call thời gian thực cho pre-merge check
D. Chuyển cả hai sang batch, kèm timeout fallback về thời gian thực nếu batch chạy quá lâu

Đáp án & giải thích

Đúng: C

A sai vì poll trạng thái không thay đổi được ràng buộc gốc: batch API không có SLA về độ trễ. Pre-merge check không thể phụ thuộc vào cửa sổ 24 giờ.
B sai vì kết quả batch được ghép cặp bằng field custom_id, nên thứ tự không phải vấn đề. Mối lo thật là yêu cầu về độ trễ.
C đúng vì pre-merge check là workflow chặn, developer đang chờ. Cửa sổ 24 giờ là không chấp nhận được. Báo cáo technical debt chạy qua đêm và chịu được độ trễ — quá hợp để chạy batch với mức tiết kiệm 50%.
D sai vì cách này thêm phức tạp không cần thiết. Hãy ghép mỗi workflow với API phù hợp dựa trên yêu cầu độ trễ.

Câu 2

Tổ chức của bạn yêu cầu báo cáo code audit hàng tuần phải có vào 09:00 thứ Hai. Bạn muốn dùng Message Batches API. Thời điểm muộn nhất có thể submit batch là khi nào?

A. 09:00 Chủ nhật (24 giờ trước hạn)
B. 09:00 thứ Sáu (72 giờ trước hạn, cho chắc)
C. 06:00 thứ Hai (3 giờ trước hạn, vì batch thường xong nhanh)
D. 03:00 Chủ nhật, tức 30 giờ trước hạn và vẫn nằm trong cửa sổ batch

Đáp án & giải thích

Đúng: D

A sai vì submit đúng 24 giờ trước hạn là không chừa chút đệm nào. Nếu batch chạy đủ 24 giờ, bạn chạm hạn mà không còn biên nào.
B sai vì 72 giờ là dè dặt quá mức không cần thiết. Đệm 6 giờ ngoài mốc tối đa 24 giờ là đủ.
C sai vì “thường xong nhanh” không phải cam kết. Batch API không có SLA về độ trễ. Thiết kế theo kịch bản tốt nhất là không đáng tin.
D đúng vì bạn phải tính theo tình huống xấu nhất: chạy đủ 24 giờ. 30 giờ trước hạn cho bạn 6 giờ đệm để xử lý sự cố.

Câu 3

Một batch 500 tài liệu chạy xong với 450 thành công và 50 thất bại. Cách xử lý thất bại đúng là gì?

A. Xác định 50 ca thất bại theo custom_id, áp chỉnh sửa nhắm đúng nguyên nhân, rồi chỉ submit lại 50 ca đó
B. Submit lại toàn bộ 500 tài liệu để đảm bảo tính nhất quán
C. Bỏ phần thất bại và chỉ báo cáo 450 kết quả extraction thành công
D. Giảm kích thước batch xuống 50 tài liệu và xử lý lại mọi thứ theo từng lô nhỏ

Đáp án & giải thích

Đúng: A

A đúng vì field custom_id cho biết tài liệu nào đã fail. Các chỉnh sửa nhắm đúng đích (chia nhỏ, đơn giản hóa prompt, thêm ví dụ theo định dạng) xử lý đúng nguyên nhân thất bại.
B sai vì submit lại cả 500 là tốn tiền cho 450 tài liệu đã thành công và nhân đôi chi phí xử lý.
C sai vì bỏ 10% kết quả làm giảm tính đầy đủ của dữ liệu. Nhiều ca thất bại sửa được bằng retry có định hướng.
D sai vì kích thước batch không phải vấn đề. Retry có định hướng cho phần thất bại hiệu quả hơn xử lý lại toàn bộ.

Câu 4

Workflow extraction của bạn cần Claude gọi một tool giữa chừng request, dùng kết quả tool đó rồi xử lý tiếp trong cùng request. Nên dùng API nào?

A. Message Batches API, kèm định nghĩa tool trong batch request
B. Messages API đồng bộ, vì nó hỗ trợ multi-turn tool calling
C. Message Batches API kèm webhook để xử lý tool call bất đồng bộ
D. API nào cũng được, vì tool calling hoạt động giống nhau ở cả hai

Đáp án & giải thích

Đúng: B

A sai vì batch API không hỗ trợ multi-turn tool calling trong một request, kể cả khi có định nghĩa tool.
B đúng vì batch API không thể chạy tool giữa chừng rồi dùng kết quả để xử lý tiếp. Multi-turn tool calling cần API đồng bộ.
C sai vì webhook không thể tiêm tool result ngược vào một batch request đang chạy dở.
D sai vì hành vi tool calling khác nhau giữa hai API. Batch API thiếu multi-turn tool calling.

Câu 5

Trước khi submit một batch 1.000 tài liệu, đồng nghiệp của bạn đề xuất thử prompt trên một tập mẫu 5 tài liệu trước. Vì sao đây là cách đúng?

A. Để tinh chỉnh prompt và tối đa hóa tỷ lệ thành công lượt đầu, giảm tổng chi phí do phải submit lại
B. Để kiểm tra kết nối API và xác thực trước một lần submit lớn
C. Để ước lượng thời gian xử lý nhằm lên lịch submit batch
D. Để kiểm tra model có hỗ trợ định dạng tài liệu không trước khi cam kết xử lý toàn bộ

Đáp án & giải thích

Đúng: A

A đúng vì tinh chỉnh prompt trên một tập mẫu đại diện tối đa hóa tỷ lệ thành công lượt đầu. Tỷ lệ 90% nghĩa là 100 lần retry. Tỷ lệ 60% nghĩa là 400 lần retry — gấp bốn lần chi phí submit lại.
B sai vì kiểm tra kết nối API là thao tác vận hành cơ bản, không phải mục đích chính của việc chạy thử tập mẫu.
C sai vì batch processing không có SLA về độ trễ, nên bạn không ước lượng được thời gian xử lý từ một tập mẫu.
D sai vì hỗ trợ định dạng là mối quan tâm thứ yếu. Lợi ích chính là cải thiện chất lượng prompt trước khi chạy quy mô lớn.

Câu 6

Trường hợp nào sau đây KHÔNG phải use case hợp lệ cho Message Batches API?

A. Sinh test case ban đêm từ tài liệu code
B. Tổng hợp audit hàng tuần các phát hiện code review
C. Pre-merge check mà developer đang chờ trước khi merge
D. Extraction dữ liệu tài chính qua đêm từ 2.000 hóa đơn

Đáp án & giải thích

Đúng: C

A sai vì sinh test ban đêm chịu được độ trễ — kết quả dùng vào ngày làm việc kế tiếp. Use case batch hợp lệ.
B sai vì tổng hợp audit hàng tuần không phụ thuộc thời gian thực. Use case batch hợp lệ.
C đúng vì pre-merge check là workflow chặn. Developer đang chờ kết quả. Cửa sổ xử lý 24 giờ là không chấp nhận được với workflow chặn.
D sai vì extraction qua đêm được tiêu thụ vào sáng hôm sau. Use case batch hợp lệ.