Keuntungan:
- Menentukan beban kerja pemprosesan kelompok yang sesuai untuknya
- Memahami pertukaran kos/kependaman antara pemprosesan segerak, tak segerak dan kelompok
- Mereka bentuk aliran kerja kelompok yang mantap yang sepadan dengan custom_id dengan hasil
Kebanyakan penyepaduan LLM memfokuskan pada senario "langsung" di mana pengguna sedang menunggu respons di hadapan skrin. Tetapi majoriti beban kerja profesional sebenarnya tidak langsung: menandakan beribu-ribu dokumen dalam sekelip mata, meringkaskan keseluruhan set data, mengklasifikasikan keseluruhan rakaman panggilan dalam arkib. Dalam perkara ini, tiada siapa yang mengharapkan jawapan segera; Yang penting ialah selesaikan kerja dengan murah dan boleh dipercayai. Batch adalah tepat untuk beban kerja ini. Dalam unit ini, anda akan mengetahui perbezaan antara pemprosesan segerak, tak segerak dan kelompok, apabila kelompok ialah pilihan yang tepat dan aliran mantap yang padan dengan custom_id dan hasil dengan yakin.
Tiga Mod Kerja
mod
Bagaimana ia berfungsi
kelewatan
Kos biasa
pekerjaan yang sesuai
segerak
Anda membuat permintaan dan menunggu jawapan
detik
Standard
Sembang langsung, pembantu segera
tak segerak
Anda beratur kerja dan mendapat pemberitahuan apabila kerja itu selesai.
Saat–minit
Standard
Tugas latar belakang, langkah automasi
Kumpulan
Menghantar beribu-ribu permintaan dalam satu pakej, kemudian mendapat hasilnya
Minit–jam
Biasanya diskaun
Pekerjaan volum tinggi, bertolak ansur dengan kelewatan
Pemprosesan kelompok adalah ini: anda menghantar ratusan/ribuan permintaan sebagai satu "pekerjaan" kepada pembekal; Pembekal memprosesnya mengikut kadarnya sendiri dan mengembalikan semua hasil secara pukal setelah selesai. Sebagai balasan, anda mendapat dua perkara: (1) secara amnya kos unit yang lebih rendah, (2) keupayaan untuk menggerakkan volum tinggi tanpa perlu berurusan dengan had laju. Harganya adalah bahawa hasilnya tidak datang serta-merta, tetapi selepas beberapa waktu.
Bila Batch, Bila Tidak?
Keputusan datang kepada satu soalan: Adakah pengguna menunggu hasilnya sekarang?
- Tidak, saya boleh tahan → calon kelompok. Penandaan malam, ringkasan kelompok, klasifikasi arkib, pengayaan data, pelaksanaan penilaian (eval).
- Ya, menunggu pada skrin → penyegerakan. Sembang langsung, nasihat segera, bantuan semasa mengisi borang.
Petua: Dua mod boleh wujud bersama dalam produk yang sama. Pengguna berfungsi serentak dalam sembang langsung; Pada waktu malam, anda memberikan semua perbualan pada hari itu kepada kumpulan untuk analisis kualiti. Memisahkan "keperluan hidup" daripada "keperluan kolektif" ialah keputusan pertama seni bina.
Anatomi Aliran Kelompok Teguh
Peraturan teknikal yang paling penting dalam pemprosesan kelompok ialah padanan hasil.
- Beri setiap permintaan `custom_id` yang unik. Ini ialah ID yang dijana anda yang mengenal pasti permintaan (mis. invois-2026-07-18-000431).
- Hantar kerja. Semua permintaan masuk dalam satu pakej; masing-masing mempunyai custom_id sendiri.
- Tinjau keadaan. Anda meminta status pada selang waktu sehingga kerja "selesai."
- Padankan keputusan dengan `custom_id`. Keputusan boleh dikembalikan dalam susunan yang berbeza daripada perintah penyerahan; jadi jangan sekali-kali padan mengikut kedudukan tetapi mengikut custom_id yang dibawa oleh setiap hasil.
- Semak jenis setiap hasil. Satu permintaan mungkin berjaya, satu mungkin gagal, satu mungkin tamat tempoh. Proses berdasarkan kejayaan/kegagalan.
{ "requests": [ { "custom_id": "invois-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasskan invois. Kembalikan JSON sahaja.", "message": [{ ""{content": "user": "text}" } }, { "custom_id": "invois-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasskan invois. Kembalikan JSON sahaja.", "message": [{ "role"": "user_}}" }] } ]}
Awas: Keputusan pemadanan berdasarkan pesanan penyerahan adalah kesilapan nombor satu dalam batching. Barisan tidak dipelihara. Tanpa custom_id anda tidak boleh yakin dengan pasti hasil yang mana milik dokumen mana — padanan yang salah secara senyap membawa kepada data yang salah.
Templat Boleh Disalin
# peraturan penjanaan custom_id (unik dan boleh dikesan)Format: <isture>-<tarikh>-<jujukan>. Contoh: request-20260718-000431Peraturan: jangan ulangi kerja; Benamkan ID rekod sumber di dalamnya.
# Kad kerja kelompok (templat penjadualan)Nama kerja: .............Bilangan rekod: .............Model: ............. (kerja ringkas → model pantas)Max_token setiap permintaan: .............Toleransi masa penghantaran yang dijangka: ......... jam Kekunci padanan keputusan: custom_idJika berlaku ralat: cuba semula / giliran / laporkan
# Gesaan permintaan tunggal dalam kelompok (pendek dan skema)Kelaskan dokumen ini. Hanya kembalikan JSON ini, mengulas:{"category":"...","urgent":"low|medium|high"}Dokumen: """{{document}}"""
# Pemprosesan hasil pseudo-kod untuk setiap hasil: jika result.status == "berjaya": rekod = cari(custom_id) save(record, result.output) jika tidak: add_to_fail(custom_id, result.error) # kemudian cuba lagi
Gesaan lemah / Gesaan kuat (reka bentuk kerja kelompok)
# LEMAH (reka bentuk rapuh)Hantar 10,000 dokumen mengikut urutan dengan model yang kukuh, simpan hasil yang dikembalikan mengikut susunan yang diterima.
# KUAT (reka bentuk tahan lama) Hantar 10,000 dokumen dalam satu kelompok dengan model pantas. Beri setiap dokumen custom_id unik yang mengandungi ID rekod sumber. Padankan keputusan dengan custom_id; beratur yang gagal dan cuba lagi. Jalankan dalam tetingkap malam; Toleransi penghantaran 6 jam.
Versi berkuasa; Ia pra-takrif pemilihan model, kekunci padanan, pengendalian ralat dan pemasaan. Ini adalah perbezaan dalam memproses berpuluh-puluh ribu rekod dengan selamat.
Tiga Kes Mini
Kes 1 — Penandaan malam. Pasukan e-dagang akan menyusun 200,000 ulasan produk ke dalam teg sentimen. Penstriman segerak langsung tertakluk pada had laju dan mahal. Mereka membawa kerja ke malam sebagai satu kumpulan dengan model pantas; Kos unit menurun, keseluruhan set siap pada waktu pagi, dan tiada masalah had laju.
Kes 2 — Kekeliruan pesanan. Satu kumpulan pasukan penyelidik mengabstrakkan 5,000 artikel, tetapi menulis hasilnya ke dalam fail mengikut urutan ia tiba. Oleh kerana keputusan dikembalikan dalam susunan yang berbeza, kira-kira 900 daripada 5,000 abstrak telah dipautkan kepada artikel yang salah. Mereka memetakan semula ke custom_id; masalah diselesaikan dan pengalaman ini menjadi peraturan tetap: "Sentiasa custom_id dalam kelompok."
Kes 3 — Bersedia langsung dalam mod yang salah. Pasukan sokongan cuba memberikan kumpulan respons langsung yang diharapkan oleh pengguna pada skrin; Pengguna ditinggalkan kerana keputusan tiba beberapa minit kemudian. Mereka mengalihkan tugas langsung kembali ke penyegerakan, hanya meninggalkan analisis kualiti setiap malam dalam kelompok. Pengajaran: kumpulan bukan untuk siap sedia secara langsung.
Kesilapan biasa
- Keputusan sepadan mengikut kedudukan: Pesanan tidak disimpan; Gunakan custom_id.
- Memindahkan kerja langsung ke kelompok: Pengguna tidak boleh menunggu beberapa minit; batch adalah untuk kerja yang bertolak ansur dengan kelewatan.
- Tidak mengendalikan kes ralat: Sesetengah permintaan mungkin gagal/tamat; Letakkannya dalam baris gilir yang berasingan dan cuba lagi.
- Refleks penggunaan model yang kuat dalam kelompok: Model pantas + kelompok ialah gabungan termurah dalam kerja mudah.
- Tidak menjadikan custom_id boleh dikesan: Jika tiada rekod sumber dibenamkan dalam ID, ia menjadi sukar untuk memautkan hasilnya kembali.
- Terlupa untuk memeriksa keadaan: Mengharapkan hasil sebelum kerja selesai; Semak status penyiapan.
Lebih mendalam: Memantau Kelompok dan Mengurus Kegagalan Separa
Aspek pemprosesan kelompok yang paling matang ialah ia memerlukan pemikiran yang berbeza daripada panggilan individu: kerja kelompok ialah "proses", bukan "peristiwa". Dengan mengandaikan bahawa berpuluh-puluh ribu permintaan semuanya akan berjaya adalah rapuh; Reka bentuk realistik menerima kegagalan separa dari awal. Status setiap keputusan mungkin berbeza: berjaya, gagal (cth. input tidak sah), dibatalkan atau tamat tempoh. Aliran mantap memproses status setiap hasil secara berasingan semasa ia melaluinya, meletakkan kegagalan ke dalam "baris gilir cuba semula" yang berasingan dan menjalankan baris gilir itu secara berasingan.
Amalan kedua ialah mereka bentuk untuk mati pucuk (menjalankan kerja yang sama dua kali tidak mendatangkan bahaya). Jika kumpulan terganggu dan anda memulakannya semula, anda tidak seharusnya memproses semula dan menulis dua kali rekod yang telah diproses. Mengikat custom_id pada rekod sumber anda juga berfungsi di sini: "adakah rekod ini sudah diproses?" sebelum menyimpan hasilnya. Menyemak menghalang menaip dua kali.
Perkara ketiga ialah membuat strim langsung secara berperingkat-peringkat. Sesetengah kerja mempunyai kedua-dua dimensi langsung dan kelompok: apabila pengguna memuatkan dokumen, anda memberi mereka ringkasan awal yang pantas (segerak) dan memproses semula dokumen yang sama untuk analisis yang lebih mendalam pada waktu malam (kelompok). Mengasingkan kedua-dua mod secara sedar akan mengoptimumkan pengalaman pengguna dan kos.
Akhir sekali, batching juga merupakan satu cara untuk menangani had laju (unit 8). Menghantar volum tinggi dalam aliran segerak langsung menghasilkan 429 malar, sementara menghantar volum yang sama ke pemindahan batch mengehadkan tekanan kepada penjadualan penyedia sendiri dan menjadikan kerja lebih mudah diramal.
Secara ringkasnya
Pemprosesan kelompok secara amnya merupakan mod yang lebih murah dan lebih mantap untuk beban kerja yang tahan latensi dan volum tinggi. Keputusannya ialah "adakah pengguna menunggu keputusan sekarang?" menentukan soalan. Peraturan teknikal yang paling kritikal adalah untuk memberikan setiap permintaan custom_id yang unik, padankan keputusan mengikut ID dan bukannya lokasi dan layan setiap kejayaan/kegagalan keputusan secara berasingan.
Tugasan permohonan
Pilih kerja volum tinggi (mis. klasifikasi arkib). (1) Tentukan sama ada karya ini secara langsung atau kolektif dan justifikasikannya. (2) Reka bentuk format custom_id (termasuk rekod sumber). (3) Isikan kad kerja kelompok (model, token_maks, toleransi, dasar ralat). (4) Tulis pseudokod pemprosesan hasil untuk memasukkan permintaan yang gagal.
senarai semak
- [ ] Saya boleh membezakan mod segerak, tak segerak dan kelompok pada paksi kos/tunda.
- [ ] Saya boleh memutuskan sama ada sesuatu pekerjaan itu sesuai untuk kumpulan atau tidak dengan bertanya soalan yang betul.
- [ ] Saya memberikan setiap permintaan custom_id unik dan memadankan keputusan mengikut ID.
- [ ] Saya boleh mengendalikan keputusan gagal/tamat tempoh secara berasingan.
- [ ] Saya tahu faedah memilih model pantas dalam kerja kelompok mudah.