Qazanclar:
- Toplu emalın hansı iş yükləri üçün uyğun olduğunu müəyyən edir
- Sinxron, asinxron və toplu emal arasında xərc/gecikmə uzlaşmasını başa düşür
- Custom_id ilə nəticələrə uyğun gələn möhkəm toplu iş axını dizayn edir
Əksər LLM inteqrasiyaları istifadəçinin ekran qarşısında cavab gözlədiyi “canlı” ssenarilərə diqqət yetirir. Lakin peşəkar iş yüklərinin əksəriyyəti əslində canlı deyil: bir gecədə minlərlə sənədi etiketləmək, bütün məlumat dəstini ümumiləşdirmək, arxivdəki bütün zəng qeydlərini təsnif etmək. Bu məsələlərdə heç kim ani cavab gözləmir; Önəmli olan işi ucuz və etibarlı şəkildə bitirməkdir. Batch məhz bu iş yükləri üçündür. Bu bölmədə siz toplu düzgün seçim olduqda sinxron, asinxron və toplu emal arasındakı fərqi və custom_id və nəticələrə inamla uyğun gələn möhkəm axını öyrənəcəksiniz.
Üç iş rejimi
rejimi
Necə işləyir
gecikmə
Tipik xərc
uyğun iş
sinxron
Müraciət edirsiniz və cavab gözləyirsiniz
saniyə
Standart
Canlı söhbət, ani köməkçi
asinxron
Siz işi növbəyə qoyursunuz və iş bitdikdə bildiriş alırsınız.
Saniyələr - dəqiqələr
Standart
Fon tapşırıqları, avtomatlaşdırma addımları
Dəstə
Bir paketdə minlərlə sorğu göndərir, sonra nəticələri alır
Dəqiqələr - saatlar
Adətən endirim olunur
Yüksək həcmli, gecikməyə dözümlü işlər
Toplu emal belədir: siz yüzlərlə/minlərlə sorğunu provayderə tək "iş" kimi göndərirsiniz; Provayder onları öz sürəti ilə emal edir və tamamlandıqdan sonra bütün nəticələri toplu şəkildə qaytarır. Bunun müqabilində siz iki şey əldə edirsiniz: (1) ümumiyyətlə daha aşağı vahid dəyəri, (2) sürət məhdudiyyətləri ilə məşğul olmadan yüksək səsi hərəkət etdirmək imkanı. Qiymət odur ki, nəticələr dərhal deyil, bir müddət sonra gəlir.
Nə vaxt yığılmalı, nə vaxt yox?
Qərar bir suala gəlir: İstifadəçi indi nəticəni gözləyirmi?
- Xeyr, mən onu saxlaya bilərəm → partiya namizədi. Gecə etiketlənməsi, partiyaların ümumiləşdirilməsi, arxiv təsnifatı, məlumatların zənginləşdirilməsi, qiymətləndirmə (qiymətləndirmə) icrası.
- Bəli, ekranda gözləyirik → sinxronizasiya. Canlı söhbət, ani məsləhət, formaları doldurarkən kömək.
İpucu: Eyni məhsulda iki rejim birlikdə mövcud ola bilər. İstifadəçi canlı söhbətdə sinxron işləyir; Gecələr o günün bütün söhbətlərini keyfiyyətli analiz üçün partiyaya verirsiniz. “Canlı ehtiyac”ı “kollektiv ehtiyac”dan ayırmaq memarlığın ilk qərarıdır.
Güclü Batch Flow Anatomiyası
Partiya emalının ən mühüm texniki qaydası nəticənin uyğunlaşdırılmasıdır.
- Hər sorğuya unikal “xüsusi_id” verin. Bu, sorğunu müəyyən edən yaradılan ID-nizdir (məsələn, faktura-2026-07-18-000431).
- İşi təqdim edin. Bütün sorğular bir paketə daxil olur; hər birinin öz custom_id-i var.
- Vəziyyəti sorğulayın. İş “bitənə” qədər fasilələrlə status soruşursunuz.
- Nəticələri `custom_id` ilə uyğunlaşdırın. Nəticələr təqdim etmə sifarişindən fərqli qaydada qaytarıla bilər; buna görə heç vaxt mövqeyə uyğun gəlməyin, lakin hər bir nəticənin daşıdığı custom_id.
- Hər bir nəticənin növünü yoxlayın. Bir sorğu uğur qazana bilər, biri uğursuz ola bilər, birinin müddəti bitə bilər. Uğur/uğursuzluğa əsaslanan proses.
{ "istəklər": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "sistem": "Faturanı təsnif edin. Yalnız JSON qaytarın.", "messages": "{"erle" "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "maks_tokens": 128, "sistem": "Faturanı təsnif edin. "Yalnız "JSON" qaytarın", ":"er", ":". "content": "{{invoice_text_2}}" }] } } ]}
Diqqət: Təqdimat sifarişinə əsaslanan nəticələrin uyğunlaşdırılması qruplaşdırmada bir nömrəli səhvdir. Növbə qorunmur. custom_id olmadan siz hansı nəticənin hansı sənədə aid olduğunu əminliklə bilə bilməzsiniz — səhv uyğunluq səssizcə yanlış məlumatlara gətirib çıxarır.
Kopyalana bilən şablonlar
# xüsusi_id yaratma qaydası (unikal və izlənilə bilən)Format: <isture>-<tarix>-<sequence>. Nümunə: sorğu-20260718-000431Qayda: işdə heç vaxt təkrarlama; Resurs qeydinin identifikatorunu daxil edin.
# Toplu iş kartı (planlaşdırma şablonu)İşin adı: .............Qeydlərin sayı: .............Model: ............. (sadə iş → sürətli model)Sorğu üzrə maksimum_tokenlər: .............Gözlənilən çatdırılma müddətinə dözümlülük: ......... saatNəticə uyğun açar: custom_idSəhv olduqda: təkrar cəhd / növbə / hesabat
# Paketdə tək sorğu sorğusu (qısa və sxematik) Bu sənədi təsnif edin. Sadəcə şərh edərək bu JSON-u qaytarın:{"kateqoriya":"...","təcili":"aşağı|orta|yüksək"}Sənəd: """{{sənəd}}"""
# Hər bir nəticə üçün psevdokodu emal edən nəticə: əgər result.status == "uğur" olarsa: qeyd = tap(xüsusi_id) saxla(qeyd, nəticə.çıxış) əks halda: uğursuzluğa_əlavə et(xüsusi_id, nəticə.error) # sonra yenidən cəhd edin
Zəif tez / Güclü təklif (toplu iş dizaynı)
# ZƏFLƏK (kövrək dizayn) Güclü model ilə 10.000 sənədi sıra ilə göndərin, geri qaytarılan nəticələri çatdıqları sırada yadda saxlayın.
# GÜÇLÜ (davamlı dizayn) Sürətli model ilə bir partiyada 10.000 sənəd göndərin. Hər bir sənədə mənbə qeydinin identifikatorunu ehtiva edən unikal custom_id verin. Nəticələri custom_id ilə uyğunlaşdırın; uğursuz olanları növbəyə qoyun və yenidən cəhd edin. Gecə pəncərəsində işləyin; Çatdırılma tolerantlığı 6 saat.
Güclü versiya; O, model seçimini, uyğun açarı, səhvlərin idarə edilməsini və vaxtı əvvəlcədən müəyyənləşdirir. Bu, on minlərlə qeydin etibarlı şəkildə işlənməsində fərqdir.
Üç mini qutu
1-ci hal - Gecə etiketlənməsi. Elektron ticarət komandası 200.000 məhsul rəyini hiss etiketlərinə ayıracaq. Canlı sinxron axın sürət məhdudiyyətlərinə məruz qaldı və baha başa gəldi. Sürətli bir modellə bir dəstə olaraq işi gecəyə qədər aparırdılar; Vahidin qiyməti düşdü, bütün dəst səhər hazır idi və sürət həddi ilə bağlı heç bir problem yox idi.
2-ci hal - Sifariş qarışıqlığı. Tədqiqat qrupu 5000 məqalənin abstraktını çıxardı, lakin nəticələri gəldikləri sıra ilə fayllara yazdı. Nəticələr fərqli ardıcıllıqla qaytarıldığı üçün 5000 tezisdən təxminən 900-ü səhv məqalə ilə əlaqələndirilib. Onu custom_id-ə dəyişdirdilər; problem həll olundu və bu təcrübə daimi qaydaya çevrildi: "Həmişə custom_id topluda."
3-cü hal — Yanlış rejimdə canlı gözləmə rejimi. Dəstək qrupu istifadəçinin ekranda gözlədiyi canlı cavabları toplu şəkildə verməyə cəhd etdi; Nəticələr bir neçə dəqiqə sonra gəldiyi üçün istifadəçilər tərk etdilər. Onlar partiyada yalnız gecə keyfiyyət analizini buraxaraq canlı işi sinxronizasiyaya köçürdülər. Dərs: toplu canlı gözləmə üçün deyil.
Ümumi səhvlər
- Nəticələrin mövqeyə uyğunluğu: Sifariş qorunmur; custom_id istifadə edin.
- Canlı işi partiyaya köçürmək: İstifadəçi dəqiqələrlə gözləyə bilməz; toplu gecikməyə dözümlü işlər üçündür.
- Səhv hallarına baxmamaq: Bəzi sorğular uğursuz/müddəti bitmiş qaytara bilər; Onu ayrıca növbəyə qoyun və yenidən cəhd edin.
- Partiyada güclü model istifadə refleksi: Sürətli model + toplu sadə işlərdə ən ucuz birləşmədir.
- custom_id-in izlənilə bilməməsi: ID-yə heç bir mənbə qeydi daxil edilməyibsə, nəticəni yenidən əlaqələndirmək çətinləşir.
- Vəziyyəti araşdırmağı unutmaq: İş bitməmiş nəticə gözləmək; Tamamlama vəziyyətini yoxlayın.
Daha dərin: Dəstənin monitorinqi və qismən uğursuzluğun idarə edilməsi
Toplu emalın ən yetkin cəhəti odur ki, o, fərdi çağırışlardan fərqli düşüncə tərzi tələb edir: toplu iş “hadisə” deyil, “prosesdir”. On minlərlə sorğunun hamısının uğur qazanacağını fərz etmək kövrəkdir; Realist dizayn başlanğıcdan qismən uğursuzluğu qəbul edir. Hər bir nəticənin statusu fərqli ola bilər: uğurlu, uğursuz (məsələn, yanlış daxiletmə), ləğv edilmiş və ya vaxtı keçmiş. Güclü axın hər bir nəticənin vəziyyətini oradan keçərkən ayrıca emal edir, uğursuzluqları ayrıca "yenidən cəhd növbəsinə" qoyur və həmin növbəni ayrıca işə salır.
İkinci təcrübə, qeyri-müəyyənlik üçün dizayn etməkdir (eyni işi iki dəfə yerinə yetirmək heç bir zərər vermir). Partiya kəsilirsə və siz onu yenidən başladırsanız, artıq işlənmiş qeydləri iki dəfə təkrar emal etməməli və yazmamalısınız. custom_id kodunu mənbə qeydinizə bağlamaq burada da işləyir: "bu qeyd artıq işlənibmi?" nəticəni saxlamaqdan əvvəl. Yoxlama ikiqat yazmağın qarşısını alır.
Üçüncü nöqtə, canlı yayımları toplu ilə qarışdırmaqdır. Bəzi işlərin həm canlı, həm də toplu ölçüləri var: istifadəçi sənədi yüklədikdə, siz onlara tez ilkin xülasə verirsiniz (sinxron) və gecə (toplu) daha dərin təhlil üçün eyni sənədi yenidən emal edirsiniz. İki rejimi şüurlu şəkildə ayırmaq həm istifadəçi təcrübəsini, həm də xərcləri optimallaşdırır.
Nəhayət, toplu iş də sürət məhdudiyyətləri ilə məşğul olmaq üçün bir yoldur (vahid 8). Canlı sinxron axında yüksək həcmin göndərilməsi sabit 429 yaradır, eyni həcmin toplu köçürmələrə göndərilməsi isə provayderin öz planlaşdırmasına təzyiqi məhdudlaşdırır və işi daha proqnozlaşdırıla bilən edir.
Xülasə
Toplu emal ümumiyyətlə gecikməyə dözümlü və yüksək həcmli iş yükləri üçün daha ucuz və daha möhkəm rejimdir. Onun qərarı "istifadəçi indi nəticəni gözləyir?" sualını müəyyən edir. Ən kritik texniki qayda hər sorğuya unikal custom_id vermək, nəticələri məkandan çox ID ilə uyğunlaşdırmaq və hər bir nəticənin uğur/uğurunu ayrıca nəzərdən keçirməkdir.
Tətbiq tapşırığı
Yüksək həcmli bir iş seçin (məsələn, arxiv təsnifatı). (1) Bu işin canlı və ya kollektiv olduğuna qərar verin və onu əsaslandırın. (2) custom_id formatını tərtib edin (resurs qeydini daxil edin). (3) Toplu iş kartını doldurun (model, max_tokens, tolerantlıq, səhv siyasəti). (4) Uğursuz sorğuları daxil etmək üçün nəticə emal psevdokodu yazın.
yoxlama siyahısı
- [ ] Mən xərc/gecikmə oxunda sinxron, asinxron və toplu rejimləri ayıra bilirəm.
- [ ] Mən düzgün sual verməklə bir işin toplu üçün uyğun olub-olmamasına qərar verə bilərəm.
- [ ] Mən hər sorğuya unikal custom_id verirəm və nəticələri ID ilə uyğunlaşdırıram.
- [ ] Mən uğursuz/müddəti bitmiş nəticələri ayrıca idarə edə bilərəm.
- [ ] Sadə toplu işlərdə sürətli model seçməyin faydalarını bilirəm.