Xử lý theo lô với Message Batches API

Message Batches API cho bạn gửi một lần thật nhiều yêu cầu, để Anthropic xử lý dần, rồi lấy kết quả sau. Đổi lại cho việc phải chờ, mọi yêu cầu chỉ tính nửa giá.

Bài này giúp bạn trả lời: việc nào nên gửi theo lô, việc nào phải gọi trực tiếp, và vận hành một hệ thống chạy theo lô thế nào cho ổn?

Ví dụ xuyên suốt: sàn thương mại điện tử và mô tả sản phẩm

Một sàn thương mại điện tử dùng Claude cho ba việc:

1. Mỗi đêm viết lại mô tả cho khoảng 40.000 sản phẩm mới hoặc vừa sửa, để sáng hôm sau đăng.
2. Khi người bán bấm "Đăng tin", kiểm tra tin có vi phạm quy định không. Người bán ngồi chờ kết quả rồi tin mới hiện lên.
3. Mô tả sản phẩm của người bán gửi tới liên tục trong ngày. Sàn cam kết với người bán: mô tả viết lại có trong vòng 36 giờ kể từ khi gửi.

Đội vận hành đề xuất chuyển cả ba sang batch để tiết kiệm một nửa chi phí.

Batch rẻ một nửa, đổi lại phải chờ

Theo tài liệu Claude API:

Điểm mấu chốt: không có cam kết về thời gian chờ (no guaranteed latency SLA). "Phần lớn xong trong một giờ" không có nghĩa là lô của bạn sẽ xong trong một giờ.

Việc nào gửi theo lô, việc nào gọi trực tiếp

Batch hợp với việc không ai đang chờ, chậm vài giờ cũng không sao: báo cáo qua đêm, kiểm tra hằng tuần, sinh test hằng đêm. Batch không hợp với việc có người hoặc quy trình đang bị chặn lại chờ kết quả, như kiểm tra bắt buộc trước khi merge code.

Áp vào ví dụ:

Batch không chạy vòng gọi tool của bạn

Mỗi yêu cầu trong lô được trả lời một lần. Nếu Claude muốn gọi một tool do bạn viết (ví dụ tra_ton_kho), câu trả lời dừng ở đó với stop_reason: "tool_use". Không có cách nào chạy tool của bạn giữa chừng rồi gửi kết quả về trong cùng yêu cầu đó; muốn đi tiếp, bạn phải gửi một yêu cầu mới. Đề thi diễn đạt ý này là batch không hỗ trợ gọi tool nhiều lượt trong một yêu cầu (cannot execute tools mid-request and return results).

Tài liệu Claude API hiện tại cho biết một lô vẫn chứa được yêu cầu có tool và cuộc trò chuyện nhiều lượt (bạn gửi sẵn lịch sử). Các tool chạy ở phía Anthropic như web search hay code execution thì tự chạy được trong yêu cầu. Nhưng tool của chính bạn thì vẫn như trên. Trong đề, đáp án là batch không hợp với việc cần agent gọi tool nhiều vòng.

custom_id và gửi lại yêu cầu lỗi

Mỗi yêu cầu trong lô có một custom_id do bạn đặt, ví dụ mã sản phẩm SP-884213. Tài liệu Claude API lưu ý kết quả có thể trả về không theo thứ tự gửi, nên phải dùng custom_id để ghép kết quả với yêu cầu.

Mỗi kết quả có một trong bốn loại: succeeded, errored, canceled, expired. Giả sử lô 40.000 sản phẩm có 600 yêu cầu errored vì mô tả gốc quá dài, vượt giới hạn context. Cách làm:

1. Lọc ra 600 custom_id bị lỗi.
2. Sửa những yêu cầu đó cho hợp, ở đây là chia mô tả dài thành nhiều phần.
3. Chỉ gửi lại 600 yêu cầu đã sửa, không gửi lại cả lô.

Gửi lại y nguyên thì 600 yêu cầu đó lỗi lại y như cũ. Gửi lại cả lô thì trả tiền lần nữa cho 39.400 yêu cầu đã xong.

Trước khi chạy cả lô lớn, nên thử prompt trên một mẫu nhỏ (vài trăm sản phẩm) bằng cách gọi trực tiếp, sửa prompt tới khi tỉ lệ đạt ngay lần đầu cao, rồi mới gửi cả lô. Làm vậy thì đỡ phải gửi lại nhiều lần. Tài liệu Claude API cũng khuyên kiểm hình dạng yêu cầu bằng Messages API trước, vì lỗi trong lô chỉ hiện ra khi cả lô đã chạy xong.

Tính tần suất gửi lô theo cam kết thời gian

Việc 3: mô tả tới liên tục, cam kết 36 giờ. Một mô tả tới ngay sau khi lô vừa gửi đi phải chờ tới lô sau, rồi lô đó có thể mất tới 24 giờ. Vậy:

Thời gian chờ xấu nhất = khoảng cách giữa hai lô + 24 giờ
Cần: khoảng cách giữa hai lô + 24 ≤ 36  →  khoảng cách ≤ 12 giờ

Gửi lô mỗi 12 giờ thì vừa khít, không còn chỗ cho lúc gửi chậm hay phải gửi lại. Chọn khoảng ngắn hơn, ví dụ mỗi 8 giờ, để còn dư 4 giờ. Đề thi hay hỏi đúng kiểu tính này, ví dụ cam kết 30 giờ thì gửi lô mỗi 4 giờ.