Keuntungan:
- Menentukan beban kerja mana yang cocok untuk pemrosesan batch
- Memahami tradeoff biaya/latensi antara pemrosesan sinkron, asinkron, dan batch
- Merancang alur kerja batch yang kuat yang mencocokkan custom_id dengan hasil
Sebagian besar integrasi LLM berfokus pada skenario “langsung” di mana pengguna menunggu respons di depan layar. Namun sebagian besar beban kerja profesional tidak benar-benar aktif: menandai ribuan dokumen dalam semalam, meringkas seluruh kumpulan data, mengklasifikasikan seluruh rekaman panggilan ke dalam arsip. Dalam permasalahan ini, tidak seorang pun mengharapkan jawaban instan; Yang penting adalah menyelesaikan pekerjaan dengan murah dan andal. Batch tepat untuk beban kerja ini. Dalam unit ini, Anda akan mempelajari perbedaan antara pemrosesan sinkron, asinkron, dan batch, kapan batch adalah pilihan yang tepat, dan aliran kuat yang cocok dengan custom_id dan hasil.
Tiga Mode Kerja
modus
Bagaimana cara kerjanya
penundaan
Biaya tipikal
pekerjaan yang cocok
sinkron
Anda membuat permintaan dan menunggu tanggapan
detik
Standar
Obrolan langsung, asisten instan
asinkron
Anda mengantri pekerjaan dan mendapat pemberitahuan jika sudah selesai.
Detik–menit
Standar
Tugas latar belakang, langkah otomatisasi
kumpulan
Mengirim ribuan permintaan dalam satu paket, lalu mendapatkan hasilnya
Menit–jam
Biasanya didiskon
Pekerjaan bervolume tinggi dan toleran terhadap penundaan
Pemrosesan batch adalah sebagai berikut: Anda mengirim ratusan/ribuan permintaan sebagai satu "pekerjaan" ke penyedia; Penyedia memprosesnya sesuai kecepatannya sendiri dan mengembalikan semua hasil secara massal setelah selesai. Sebagai imbalannya, Anda mendapatkan dua hal: (1) biaya unit yang umumnya lebih rendah, (2) kemampuan untuk memindahkan volume tinggi tanpa harus berurusan dengan batas kecepatan. Harganya adalah hasilnya tidak datang secara instan, tetapi setelah beberapa waktu.
Kapan Melakukan Batch, Kapan Tidak?
Keputusannya tergantung pada satu pertanyaan: Apakah pengguna menunggu hasilnya sekarang?
- Tidak, saya bisa menahannya → calon angkatan. Penandaan malam, ringkasan batch, klasifikasi arsip, pengayaan data, pelaksanaan evaluasi (eval).
- Ya, menunggu di layar → sinkronisasi. Obrolan langsung, saran instan, bantuan saat mengisi formulir.
Tip: Dua mode dapat hidup berdampingan dalam produk yang sama. Pengguna bekerja secara serempak dalam obrolan langsung; Di malam hari, Anda memberikan semua percakapan hari itu ke kelompok untuk analisis kualitas. Memisahkan "kebutuhan hidup" dari "kebutuhan kolektif" adalah keputusan pertama dalam arsitektur.
Anatomi Aliran Batch yang Kuat
Aturan teknis terpenting dalam pemrosesan batch adalah pencocokan hasil.
- Berikan setiap permintaan `custom_id` yang unik. Ini adalah ID yang Anda buat yang mengidentifikasi permintaan (misalnya invoice-2026-07-18-000431).
- Kirimkan pekerjaan. Semua permintaan masuk dalam satu paket; masing-masing dengan custom_idnya sendiri.
- Jajak pendapat tentang situasinya. Anda menanyakan status secara berkala hingga pekerjaan "selesai".
- Cocokkan hasilnya dengan `custom_id`. Hasil dapat dikembalikan dalam urutan yang berbeda dari urutan penyerahan; jadi jangan pernah mencocokkan berdasarkan posisi tetapi berdasarkan custom_id yang dimiliki setiap hasil.
- Periksa jenis setiap hasil. Satu permintaan mungkin berhasil, satu lagi mungkin gagal, satu lagi mungkin kedaluwarsa. Proses berdasarkan keberhasilan/kegagalan.
{ "permintaan": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasifikasi faktur. Kembalikan JSON saja.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasifikasi faktur. Kembalikan JSON saja.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Perhatian: Mencocokkan hasil berdasarkan urutan penyerahan adalah kesalahan nomor satu dalam pengelompokan. Antrian tidak dipertahankan. Tanpa custom_id Anda tidak dapat mengetahui dengan yakin hasil mana yang dimiliki dokumen tertentu — pencocokan yang salah secara diam-diam akan menghasilkan data yang salah.
Templat yang Dapat Disalin
# aturan pembuatan custom_id (unik dan dapat dilacak)Format: <isture>-<date>-<sequence>. Contoh: request-20260718-000431Aturan: jangan pernah mengulang pekerjaan; Sematkan ID catatan sumber daya di dalamnya.
# Kartu pekerjaan batch (templat penjadwalan) Nama pekerjaan: ............. Jumlah catatan: ............. Model: ............. (pekerjaan sederhana → model cepat) Max_tokens per permintaan: ............. Toleransi waktu pengiriman yang diharapkan: ......... jam Kunci pencocokan hasil: custom_id Jika terjadi kesalahan: coba lagi / antrian / laporkan
# Prompt permintaan tunggal dalam batch (pendek dan skematis)Klasifikasikan dokumen ini. Kembalikan saja JSON ini, beri komentar:{"category":"...","urgency":"low|medium|high"}Dokumen: """{{document}}"""
# Hasil pemrosesan pseudo-code untuk setiap hasil: if result.status == "success": record = find(custom_id) save(record, result.output) sebaliknya: add_to_fail(custom_id, result.error) # lalu coba lagi
Prompt lemah / Prompt kuat (desain pekerjaan batch)
# LEMAH (desain rapuh)Kirim 10.000 dokumen secara berurutan dengan model yang kuat, simpan hasil yang dikembalikan sesuai urutan kedatangannya.
# STRONG (desain tahan lama) Kirim 10.000 dokumen dalam satu batch dengan model cepat. Berikan setiap dokumen custom_id unik yang berisi ID rekaman sumber. Cocokkan hasilnya dengan custom_id; antri yang gagal dan coba lagi. Jalankan di jendela malam; Toleransi pengiriman 6 jam.
Versi yang kuat; Ini telah menentukan sebelumnya pemilihan model, kunci pencocokan, penanganan kesalahan, dan pengaturan waktu. Inilah perbedaan dalam memproses puluhan ribu catatan dengan aman.
Tiga Kasus Mini
Kasus 1 — Penandaan malam. Tim e-niaga akan mengurutkan 200.000 ulasan produk ke dalam tag sentimen. Streaming sinkron langsung tunduk pada batas kecepatan dan mahal. Mereka melaksanakan pekerjaan tersebut hingga malam hari sebagai batch dengan model yang cepat; Biaya unit turun, seluruh set siap di pagi hari, dan tidak ada masalah batas kecepatan.
Kasus 2 — Kebingungan pesanan. Sebuah kelompok peneliti mengabstraksi 5.000 artikel, tetapi menulis hasilnya ke dalam file sesuai urutan kedatangannya. Karena hasilnya dikembalikan dalam urutan berbeda, sekitar 900 dari 5.000 abstrak ditautkan ke artikel yang salah. Mereka memetakannya kembali ke custom_id; masalah terpecahkan dan pengalaman ini menjadi aturan permanen: "Selalu custom_id dalam batch."
Kasus 3 — Siaga langsung dalam mode yang salah. Tim dukungan berusaha memberikan tanggapan langsung yang diharapkan pengguna di layar; Pengguna ditinggalkan karena hasilnya tiba beberapa menit kemudian. Mereka memindahkan pekerjaan langsung kembali ke sinkronisasi, hanya menyisakan analisis kualitas malam dalam kumpulan. Pelajaran: batch bukan untuk live standby.
Kesalahan umum
- Mencocokkan hasil berdasarkan posisi: Pesanan tidak dipertahankan; Gunakan custom_id.
- Mentransfer pekerjaan langsung ke batch: Pengguna tidak dapat menunggu beberapa menit; batch adalah untuk pekerjaan yang toleran terhadap penundaan.
- Tidak menangani kasus kesalahan: Beberapa permintaan mungkin gagal/kedaluwarsa; Masukkan ke dalam antrean terpisah dan coba lagi.
- Refleks penggunaan model yang kuat dalam batch: Model cepat + batch adalah kombinasi termurah dalam pekerjaan sederhana.
- Tidak membuat custom_id dapat dilacak: Jika tidak ada catatan sumber yang tertanam dalam ID, akan sulit untuk menautkan kembali hasilnya.
- Lupa memeriksa situasi: Mengharapkan hasil sebelum pekerjaan selesai; Periksa status penyelesaian.
Lebih Dalam: Memantau Batch dan Mengelola Kegagalan Parsial
Aspek paling matang dari pemrosesan batch adalah bahwa hal ini memerlukan pola pikir yang berbeda dari panggilan individual: tugas batch adalah "proses", bukan "peristiwa". Berasumsi bahwa puluhan ribu permintaan semuanya akan berhasil adalah hal yang rapuh; Desain realistis menerima kegagalan sebagian sejak awal. Status setiap hasil bisa berbeda: berhasil, gagal (misalnya input tidak valid), dibatalkan, atau kedaluwarsa. Aliran yang kuat memproses status setiap hasil secara terpisah saat melewatinya, menempatkan kegagalan ke dalam "antrean percobaan ulang" yang terpisah dan menjalankan antrean tersebut secara terpisah.
Praktik kedua adalah merancang idempotensi (menjalankan pekerjaan yang sama dua kali tidak menimbulkan bahaya apa pun). Jika batch terganggu dan Anda memulai ulang, Anda tidak boleh memproses ulang dan menulis dua kali rekaman yang sudah diproses. Mengikat custom_id ke rekaman sumber Anda juga berfungsi di sini: "apakah rekaman ini sudah diproses?" sebelum menyimpan hasilnya. Pengecekan mencegah pengetikan ganda.
Poin ketiga adalah mengatur streaming langsung secara batch. Beberapa pekerjaan memiliki dimensi langsung dan batch: saat pengguna memuat dokumen, Anda memberi mereka ringkasan awal yang cepat (sinkron), dan memproses ulang dokumen yang sama untuk analisis lebih dalam di malam hari (batch). Memisahkan kedua mode secara sadar akan mengoptimalkan pengalaman pengguna dan biaya.
Terakhir, batching juga merupakan cara untuk menangani batas kecepatan (unit 8). Pengiriman volume tinggi dalam aliran sinkron langsung menghasilkan konstanta 429, sementara pengiriman volume yang sama ke transfer batch membatasi tekanan pada penjadwalan penyedia sendiri dan membuat pekerjaan lebih dapat diprediksi.
Singkatnya
Pemrosesan batch umumnya merupakan mode yang lebih murah dan tangguh untuk beban kerja yang toleran terhadap latensi dan bervolume tinggi. Keputusannya adalah "apakah pengguna menunggu hasilnya sekarang?" menentukan pertanyaannya. Aturan teknis yang paling penting adalah memberikan custom_id yang unik pada setiap permintaan, mencocokkan hasil berdasarkan ID, bukan berdasarkan lokasi, dan memperlakukan keberhasilan/kegagalan setiap hasil secara terpisah.
Tugas aplikasi
Pilih pekerjaan bervolume tinggi (misalnya klasifikasi arsip). (1) Putuskan apakah karya ini bersifat live atau kolektif dan berikan alasan. (2) Rancang format custom_id (sertakan catatan sumber daya). (3) Isi kartu pekerjaan batch (model, max_tokens, toleransi, kebijakan kesalahan). (4) Tulis kodesemu pemrosesan hasil untuk menyertakan permintaan yang gagal.
daftar periksa
- [ ] Saya dapat membedakan mode sinkron, asinkron, dan batch pada sumbu biaya/penundaan.
- [ ] Saya dapat memutuskan apakah suatu pekerjaan cocok untuk batch atau tidak dengan mengajukan pertanyaan yang tepat.
- [] Saya memberikan setiap permintaan custom_id unik dan mencocokkan hasilnya berdasarkan ID.
- [ ] Saya dapat menangani hasil yang gagal/kedaluwarsa secara terpisah.
- [ ] Saya mengetahui manfaat memilih model cepat dalam pekerjaan batch sederhana.