Khối lượng công việc hàng loạt và không đồng bộ — API, chi phí và tích hợp

Lợi nhuận:

Xác định khối lượng công việc nào được xử lý theo lô phù hợp
Hiểu sự cân bằng giữa chi phí/độ trễ giữa xử lý đồng bộ, không đồng bộ và xử lý hàng loạt
Thiết kế quy trình làm việc hàng loạt mạnh mẽ phù hợp với custom_id với kết quả

Hầu hết các tích hợp LLM đều tập trung vào các tình huống “trực tiếp” trong đó người dùng đang chờ phản hồi trước màn hình. Nhưng phần lớn khối lượng công việc chuyên môn không thực sự tồn tại: gắn thẻ hàng nghìn tài liệu chỉ sau một đêm, tóm tắt toàn bộ tập dữ liệu, phân loại toàn bộ bản ghi cuộc gọi trong kho lưu trữ. Trong những vấn đề này, không ai mong đợi câu trả lời ngay lập tức; Điều quan trọng là hoàn thành công việc với chi phí rẻ và đáng tin cậy. Batch chính xác dành cho những khối lượng công việc này. Trong học phần này, bạn sẽ tìm hiểu sự khác biệt giữa xử lý đồng bộ, không đồng bộ và xử lý hàng loạt, khi hàng loạt là lựa chọn phù hợp và một luồng mạnh mẽ tự tin khớp với custom_id và kết quả.

Ba chế độ làm việc

chế độ

Nó hoạt động như thế nào

sự chậm trễ

Chi phí điển hình

công việc phù hợp

đồng bộ

Bạn đưa ra yêu cầu và chờ phản hồi

giây

Tiêu chuẩn

Trò chuyện trực tiếp, trợ lý tức thì

không đồng bộ

Bạn xếp hàng công việc và nhận được thông báo khi nó hoàn thành.

Giây–phút

Tiêu chuẩn

Tác vụ nền, các bước tự động hóa

Lô

Gửi hàng ngàn yêu cầu trong một gói, sau đó nhận kết quả

Phút–giờ

Thường giảm giá

Công việc có khối lượng lớn, chịu được độ trễ

Xử lý hàng loạt là thế này: bạn gửi hàng trăm/nghìn yêu cầu dưới dạng một "công việc" duy nhất cho nhà cung cấp; Nhà cung cấp xử lý chúng theo tốc độ riêng của mình và trả về hàng loạt kết quả sau khi hoàn thành. Đổi lại, bạn nhận được hai điều: (1) chi phí đơn vị thường thấp hơn, (2) khả năng di chuyển khối lượng lớn mà không phải đối mặt với giới hạn tốc độ. Cái giá phải trả là kết quả không đến ngay lập tức mà sau một thời gian.

Khi nào thực hiện hàng loạt, khi nào không?

Quyết định được đưa ra dựa trên một câu hỏi: Hiện tại người dùng có đang chờ kết quả không?

Không, tôi có thể giữ nó → ứng viên đợt. Gắn thẻ ban đêm, tóm tắt hàng loạt, phân loại lưu trữ, làm giàu dữ liệu, thực hiện đánh giá (eval).
Có, đang chờ trên màn hình → đồng bộ hóa. Trò chuyện trực tiếp, tư vấn tức thì, trợ giúp khi điền biểu mẫu.

Mẹo: Hai chế độ có thể cùng tồn tại trong cùng một sản phẩm. Người dùng hoạt động đồng bộ trong trò chuyện trực tiếp; Vào ban đêm, bạn đưa tất cả các cuộc trò chuyện trong ngày hôm đó cho nhóm để phân tích chất lượng. Tách biệt “nhu cầu sống” khỏi “nhu cầu tập thể” là quyết định đầu tiên của kiến trúc.

Cấu trúc của dòng hàng loạt mạnh mẽ

Nguyên tắc kỹ thuật quan trọng nhất của xử lý hàng loạt là kết quả khớp.

Cung cấp cho mỗi yêu cầu một `custom_id` duy nhất. Đây là ID do bạn tạo để xác định yêu cầu (ví dụ: bill-2026-07-18-000431).
Gửi công việc. Tất cả các yêu cầu đều được gói gọn trong một gói; mỗi cái có custom_id riêng.
Thăm dò tình hình. Bạn yêu cầu trạng thái theo từng khoảng thời gian cho đến khi công việc "hoàn thành".
Khớp kết quả với `custom_id`. Kết quả có thể được trả về theo thứ tự khác với thứ tự nộp; vì vậy không bao giờ khớp theo vị trí mà theo custom_id mà mỗi kết quả mang lại.
Kiểm tra loại của từng kết quả. Một yêu cầu có thể thành công, một yêu cầu có thể thất bại, một yêu cầu có thể hết hạn. Quy trình dựa trên thành công/thất bại.

{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Phân loại hóa đơn. Chỉ trả về JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Phân loại hóa đơn. Chỉ trả về JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}

Thận trọng: Việc so khớp kết quả dựa trên thứ tự gửi là sai lầm số một trong việc phân nhóm. Hàng đợi không được bảo tồn. Nếu không có custom_id, bạn không thể tự tin biết kết quả nào thuộc về tài liệu nào - việc khớp sai sẽ âm thầm dẫn đến dữ liệu sai.

Mẫu có thể sao chép

# quy tắc tạo custom_id (duy nhất và có thể theo dõi)Định dạng: <isture>-<date>-<sequence>. Ví dụ: request-20260718-000431Quy tắc: không bao giờ lặp lại trong công việc; Nhúng ID bản ghi tài nguyên vào đó.

# Thẻ công việc hàng loạt (mẫu lập lịch)Tên công việc: .............Số bản ghi: ...........Mẫu: ............. (công việc đơn giản → mô hình nhanh)Max_token mỗi yêu cầu: ............Dung sai thời gian giao hàng dự kiến: ......... giờKhóa khớp kết quả: custom_idTrong trường hợp có lỗi: thử lại / xếp hàng / báo cáo

# Lời nhắc yêu cầu duy nhất theo đợt (ngắn gọn và sơ đồ) Phân loại tài liệu này. Chỉ cần trả lại JSON này, nhận xét:{"category://...","khẩn cấp:"thấp|medium|high"}Tài liệu: """{{document}}"""

# Mã giả xử lý kết quả cho mỗi kết quả: if result.status == "success": record = find(custom_id) save(record, result.output) nếu không: add_to_fail(custom_id, result.error) # sau đó thử lại

Lời nhắc yếu / Lời nhắc mạnh (thiết kế công việc hàng loạt)

# YẾU (thiết kế dễ vỡ)Gửi 10.000 tài liệu theo thứ tự với mô hình mạnh, lưu kết quả trả về theo thứ tự chúng đến.

# MẠNH MẼ (thiết kế bền bỉ) Gửi 10.000 tài liệu trong một đợt với mô hình nhanh. Cung cấp cho mỗi tài liệu một custom_id duy nhất chứa ID bản ghi nguồn. Khớp kết quả với custom_id; xếp hàng những cái không thành công và thử lại. Chạy trong cửa sổ ban đêm; Dung sai giao hàng 6 giờ.

Phiên bản mạnh mẽ; Nó xác định trước việc lựa chọn mô hình, khóa khớp, xử lý lỗi và thời gian. Đây là sự khác biệt trong việc xử lý an toàn hàng chục nghìn bản ghi.

Ba hộp nhỏ

Trường hợp 1 - Gắn thẻ ban đêm. Một nhóm thương mại điện tử sẽ sắp xếp 200.000 đánh giá sản phẩm thành các thẻ cảm tính. Phát trực tiếp đồng bộ phải tuân theo giới hạn tốc độ và tốn kém. Họ thực hiện công việc vào ban đêm theo từng đợt với mô hình nhanh chóng; Đơn giá giảm xuống, toàn bộ bộ máy đã sẵn sàng vào buổi sáng và không có vấn đề gì về giới hạn tốc độ.

Trường hợp 2 - Nhầm lẫn về đơn hàng. Một nhóm nghiên cứu đã tóm tắt 5.000 bài báo nhưng viết kết quả vào các tập tin theo thứ tự chúng đến. Vì kết quả được trả về theo thứ tự khác nên khoảng 900 trong số 5.000 bài tóm tắt được liên kết đến bài viết sai. Họ đã ánh xạ lại nó thành custom_id; vấn đề đã được giải quyết và trải nghiệm này đã trở thành quy tắc lâu dài: "Luôn tùy chỉnh_id theo đợt."

Trường hợp 3 - Chế độ chờ trực tiếp ở chế độ sai. Một nhóm hỗ trợ đã cố gắng đưa ra hàng loạt phản hồi trực tiếp mà người dùng mong đợi trên màn hình; Người dùng bỏ cuộc vì kết quả đến sau đó vài phút. Họ đã chuyển công việc trực tiếp trở lại trạng thái đồng bộ hóa, chỉ để lại phân tích chất lượng hàng đêm theo đợt. Bài học: lô không dành cho chế độ chờ trực tiếp.

Những lỗi thường gặp

Kết quả khớp theo vị trí: Thứ tự không được giữ nguyên; Sử dụng custom_id.
Chuyển công việc trực tiếp sang hàng loạt: Người dùng không thể đợi vài phút; batch dành cho các công việc có khả năng chịu độ trễ.
Không xử lý các trường hợp lỗi: Một số yêu cầu có thể trả về không thành công/hết hạn; Đặt nó vào một hàng đợi riêng và thử lại.
Phản xạ sử dụng mô hình mạnh mẽ theo lô: Mô hình nhanh + lô là sự kết hợp rẻ nhất trong các công việc đơn giản.
Không tạo ra custom_id có thể theo dõi được: Nếu không có bản ghi nguồn nào được nhúng vào ID thì việc liên kết lại kết quả sẽ trở nên khó khăn.
Quên xem xét tình hình: Mong đợi kết quả trước khi công việc kết thúc; Kiểm tra trạng thái hoàn thành.

Chuyên sâu hơn: Giám sát lô và quản lý lỗi một phần

Khía cạnh trưởng thành nhất của xử lý hàng loạt là nó đòi hỏi một tư duy khác với các cuộc gọi riêng lẻ: công việc hàng loạt là một "quy trình", không phải là một "sự kiện". Giả sử rằng hàng chục nghìn yêu cầu đều thành công là điều mong manh; Thiết kế thực tế chấp nhận lỗi một phần ngay từ đầu. Trạng thái của mỗi kết quả có thể khác nhau: thành công, thất bại (ví dụ: đầu vào không hợp lệ), bị hủy hoặc hết hạn. Một luồng mạnh mẽ xử lý trạng thái của từng kết quả một cách riêng biệt khi nó di chuyển qua kết quả đó, đặt các lỗi vào một "hàng đợi thử lại" riêng biệt và chạy hàng đợi đó một cách riêng biệt.

Cách thực hành thứ hai là thiết kế cho tính bình thường (việc chạy cùng một công việc hai lần không gây ra bất kỳ tác hại nào). Nếu một đợt bị gián đoạn và bạn khởi động lại nó, bạn không nên xử lý lại và ghi hai lần các bản ghi đã được xử lý. Việc liên kết custom_id với bản ghi nguồn của bạn cũng hoạt động ở đây: "bản ghi này đã được xử lý chưa?" trước khi lưu kết quả. Việc kiểm tra ngăn chặn việc gõ hai lần.

Điểm thứ ba là xen kẽ các luồng trực tiếp theo đợt. Một số công việc có cả thứ nguyên trực tiếp và hàng loạt: khi người dùng tải tài liệu, bạn cung cấp cho họ bản tóm tắt sơ bộ nhanh chóng (đồng bộ) và xử lý lại cùng một tài liệu để phân tích sâu hơn vào ban đêm (lô). Việc tách biệt hai chế độ một cách có ý thức sẽ tối ưu hóa cả trải nghiệm người dùng và chi phí.

Cuối cùng, trộn cũng là một cách để giải quyết các giới hạn tốc độ (bài 8). Việc gửi khối lượng lớn trong luồng đồng bộ trực tiếp sẽ tạo ra hằng số 429, trong khi việc gửi cùng một khối lượng tới việc truyền hàng loạt sẽ hạn chế áp lực lên lịch trình của chính nhà cung cấp và giúp công việc dễ dự đoán hơn.

Tóm lại

Xử lý hàng loạt nói chung là chế độ rẻ hơn và mạnh mẽ hơn dành cho khối lượng công việc có khối lượng lớn và độ trễ cao. Quyết định của anh ấy là "người dùng có đang chờ kết quả ngay bây giờ không?" quyết định câu hỏi. Quy tắc kỹ thuật quan trọng nhất là cung cấp cho mỗi yêu cầu một custom_id duy nhất, kết quả khớp theo ID thay vì vị trí và xử lý riêng biệt thành công/thất bại của từng kết quả.

Nhiệm vụ ứng dụng

Chọn một công việc có khối lượng lớn (ví dụ: phân loại kho lưu trữ). (1) Quyết định xem tác phẩm này là trực tiếp hay tập thể và biện minh cho nó. (2) Thiết kế định dạng custom_id (bao gồm bản ghi tài nguyên). (3) Điền vào thẻ công việc hàng loạt (model, max_tokens, dung sai, chính sách lỗi). (4) Viết mã giả xử lý kết quả để bao gồm các yêu cầu không thành công.

danh sách kiểm tra

[ ] Tôi có thể phân biệt các chế độ đồng bộ, không đồng bộ và hàng loạt trên trục chi phí/độ trễ.
[ ] Tôi có thể quyết định liệu một công việc có phù hợp với công việc theo đợt hay không bằng cách đặt câu hỏi phù hợp.
[ ] Tôi cung cấp cho mỗi yêu cầu một custom_id duy nhất và khớp kết quả theo ID.
[ ] Tôi có thể xử lý riêng các kết quả không thành công/hết hạn.
[ ] Tôi biết lợi ích của việc chọn mô hình nhanh trong các công việc hàng loạt đơn giản.