Dobici:
- Određuje za koja radna opterećenja je prikladna skupna obrada
- Razumije odnos troškova/kašnjenja između sinkrone, asinkrone i skupne obrade
- Dizajnira robustan skupni tijek rada koji podudara custom_id s rezultatima
Većina LLM integracija usredotočuje se na scenarije "uživo" u kojima korisnik čeka odgovor ispred ekrana. But the majority of professional workloads are not actually live: tagging thousands of documents overnight, summarizing an entire dataset, classifying entire call recordings in the archive. U ovim stvarima nitko ne očekuje trenutni odgovor; Važno je posao završiti jeftino i pouzdano. Serija je upravo za ova radna opterećenja. U ovoj jedinici naučit ćete razliku između sinkrone, asinkrone i skupne obrade, kada je serija pravi izbor i robusnog tijeka koji pouzdano odgovara custom_id-u i rezultatima.
Tri načina rada
način rada
Kako radi
delay
Tipični trošak
prikladan posao
sinkroni
Napravite zahtjev i čekate odgovor
sekundi
Standardno
Live chat, trenutni pomoćnik
asinkroni
Posao stavljate u red čekanja i dobivate obavijest kada bude gotov.
Sekunde – minute
Standardno
Pozadinski zadaci, koraci automatizacije
Serija
Šalje tisuće zahtjeva u jednom paketu, a zatim dobiva rezultate
Minute–sati
Obično na popustu
Poslovi velikog obima, tolerantni na kašnjenje
Skupna obrada je sljedeća: šaljete stotine/tisuće zahtjeva kao jedan "posao" pružatelju; Pružatelj ih obrađuje vlastitim tempom i vraća sve rezultate skupa kada se dovrše. Zauzvrat dobivate dvije stvari: (1) općenito nižu jediničnu cijenu, (2) mogućnost premještanja velike količine bez suočavanja s ograničenjima brzine. Cijena je da rezultati ne dolaze odmah, već nakon nekog vremena.
Kada batch, kada ne?
Odluka se svodi na jedno pitanje: Čeka li korisnik sada rezultat?
- Ne, mogu ga zadržati → kandidat za seriju. Noćno označavanje, sažimanje serije, klasificiranje arhiva, obogaćivanje podataka, izvođenje evaluacije (ocjenjivanja).
- Da, čekanje na zaslonu → sinkronizacija. Live chat, instant savjet, pomoć pri ispunjavanju formulara.
Savjet: dva načina rada mogu koegzistirati u istom proizvodu. Korisnik radi sinkronizirano u live chatu; Noću dajete sve razgovore tog dana grupi na kvalitetnu analizu. Odvajanje "životne potrebe" od "kolektivne potrebe" prva je odluka arhitekture.
Anatomija robusnog šaržnog protoka
Najvažnije tehničko pravilo skupne obrade je podudaranje rezultata.
- Svakom zahtjevu dodijelite jedinstveni `custom_id`. This is your generated ID that identifies the request (e.g. invoice-2026-07-18-000431).
- Pošaljite posao. Svi zahtjevi idu u jednom paketu; svaki sa svojim custom_id.
- Ispitajte situaciju. Pitate status u intervalima dok posao ne bude "gotov".
- Povežite rezultate s "custom_id". Results may be returned in a different order than the submission order; tako da se nikad ne podudaraju prema poziciji nego prema custom_id-u koji nosi svaki rezultat.
- Provjerite vrstu svakog rezultata. One request might succeed, one might fail, one might expire. Proces temeljen na uspjehu/neuspjehu.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasificiraj fakturu. Vrati samo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Klasificiraj fakturu. Vrati samo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Oprez: Uparivanje rezultata na temelju redoslijeda podnošenja je pogreška broj jedan u grupiranju. Red čekanja nije sačuvan. Bez custom_id-a ne možete pouzdano znati koji rezultat pripada kojem dokumentu — krivo podudaranje tiho dovodi do pogrešnih podataka.
Predlošci koji se mogu kopirati
# custom_id pravilo generiranja (jedinstveno i sljedivo) Format: <isture>-<date>-<sequence>. Primjer: request-20260718-000431Pravilo: nikada ne ponavljati u radu; U njega ugradite ID zapisa resursa.
# Kartica skupnog posla (predložak rasporeda) Naziv posla: .............Broj zapisa: .............Model: ............. (jednostavan posao → brzi model)Maks_tokena po zahtjevu: .............Tolerancija očekivanog vremena isporuke: ......... sati Ključ za podudaranje rezultata: custom_id U slučaju pogreške: ponovni pokušaj / red / izvješće
# Jedan upit za zahtjev u paketu (kratko i shematski) Klasificirajte ovaj dokument. Samo vratite ovaj JSON, komentirajući:{"category":"...","urency":"low|medium|high"}Dokument: """{{document}}"""
# Pseudokod obrade rezultata za svaki rezultat: if result.status == "uspjeh": record = find(custom_id) save(record, result.output) inače: add_to_fail(custom_id, result.error) # zatim pokušajte ponovno
Slab prompt / Jak prompt (serijski dizajn posla)
# SLABO (krhki dizajn) Pošaljite 10 000 dokumenata po redu s jakim modelom, spremite vraćene rezultate redoslijedom kojim stižu.
# SNAŽAN (izdržljiv dizajn) Pošaljite 10 000 dokumenata u jednoj seriji s brzim modelom. Svakom dokumentu dodijelite jedinstveni custom_id koji sadrži ID izvornog zapisa. Povežite rezultate s custom_id; stavite u red neuspješne i pokušajte ponovo. Trčite u noćnom prozoru; Tolerancija isporuke 6 sati.
Snažna verzija; Unaprijed definira odabir modela, odgovarajući ključ, obradu grešaka i vrijeme. To je razlika u sigurnoj obradi desetaka tisuća zapisa.
Tri mini kućišta
Slučaj 1 — Noćno označavanje. Tim za e-trgovinu sortirao bi 200.000 recenzija proizvoda u oznake mišljenja. Sinkroni prijenos uživo podlijegao je ograničenjima brzine i bio je skup. Posao su nosili u noć kao serija s brzim modelom; Jedinični trošak je pao, cijeli set je bio spreman ujutro i nije bilo problema s ograničenjem brzine.
Slučaj 2 — Zabuna u narudžbi. Skupina istraživačkog tima abstrahirala je 5000 članaka, ali je rezultate zapisala u datoteke redoslijedom kojim su pristizali. Budući da su rezultati vraćeni drugačijim redoslijedom, približno 900 od 5000 sažetaka bilo je povezano s krivim člankom. Ponovno su ga mapirali u custom_id; problem riješen i ovo iskustvo postalo je trajno pravilo: "Uvijek custom_id u seriji."
Slučaj 3 — Stanje pripravnosti uživo u pogrešnom načinu rada. Tim za podršku pokušao je dati skupinu odgovora uživo koje je korisnik očekivao na ekranu; Korisnici su odustali jer su rezultati stigli nekoliko minuta kasnije. Pomaknuli su posao uživo natrag na sinkronizaciju, ostavljajući samo noćnu analizu kvalitete u seriji. Lekcija: serija nije za live standby.
Uobičajene greške
- Usklađivanje rezultata prema poziciji: Redoslijed nije sačuvan; Koristite custom_id.
- Prijenos živog posla u paket: korisnik ne može čekati nekoliko minuta; serija je za poslove tolerantne na kašnjenje.
- Ne obrađuje slučajeve pogrešaka: neki zahtjevi mogu vratiti neuspjele/istekle; Stavite ga u zaseban red čekanja i pokušajte ponovno.
- Snažan refleks korištenja modela u seriji: Brzi model + serija je najjeftinija kombinacija u jednostavnim poslovima.
- Nemogućnost praćenja custom_id-a: Ako izvorni zapis nije ugrađen u ID, postaje teško ponovno povezati rezultat.
- Forgetting to examine the situation: Expecting results before the job is finished; Provjerite status završetka.
Deeper: Praćenje serije i upravljanje djelomičnim neuspjehom
Najzreliji aspekt skupne obrade je da zahtijeva drugačiji način razmišljanja od pojedinačnih poziva: skupni posao je "proces", a ne "događaj". Pretpostavka da će deseci tisuća zahtjeva uspjeti je krhka; Realističan dizajn prihvaća djelomični kvar od samog početka. The status of each result can be different: successful, failed (e.g. invalid input), canceled or expired. Robusni tok obrađuje status svakog rezultata zasebno dok putuje kroz njega, smješta greške u zaseban "red ponovnog pokušaja" i pokreće taj red zasebno.
Druga praksa je dizajniranje za idempotenciju (da dvaput pokretanje istog posla ne uzrokuje nikakvu štetu). Ako se paket prekine i ponovno ga pokrenete, ne biste trebali ponovno obrađivati i pisati dva puta već obrađene zapise. Povezivanje custom_id-a s vašim izvornim zapisom radi i ovdje: "je li ovaj zapis već obrađen?" prije spremanja rezultata. Provjera sprječava dvostruko tipkanje.
Treća točka je rasporediti live streamove sa serijom. Neki poslovi imaju žive i skupne dimenzije: kada korisnik učita dokument, dajete mu brzi preliminarni sažetak (sinkrono) i ponovno obrađujete isti dokument za dublju analizu noću (serija). Svjesno odvajanje dvaju načina optimizira korisničko iskustvo i troškove.
Konačno, grupiranje je također način rješavanja ograničenja brzine (jedinica 8). Slanje velikog volumena u sinkronom protoku uživo proizvodi konstantu 429, dok slanje istog volumena u paketne prijenose ograničava pritisak na vlastito zakazivanje pružatelja i čini posao predvidljivijim.
Ukratko
Skupna obrada općenito je jeftiniji i robusniji način za radna opterećenja koja su tolerantna na latenciju i velika volumena. Njegova je odluka bila "čeka li korisnik sada rezultat?" određuje pitanje. Najvažnije tehničko pravilo je dati svakom zahtjevu jedinstveni custom_id, upariti rezultate prema ID-u umjesto prema lokaciji i tretirati uspjeh/neuspjeh svakog rezultata zasebno.
Zadatak aplikacije
Odaberite posao velikog volumena (npr. klasificiranje arhive). (1) Odlučite je li ovo djelo uživo ili kolektivno i obrazložite ga. (2) Dizajnirajte custom_id format (uključite zapis resursa). (3) Ispunite karticu skupnog posla (model, max_tokeni, tolerancija, politika pogreške). (4) Napišite pseudokod obrade rezultata da biste uključili neuspjele zahtjeve.
popis za provjeru
- [ ] Mogu razlikovati sinkroni, asinkroni i skupni način rada na osi trošak/odgoda.
- [ ] Mogu odlučiti je li posao prikladan za seriju ili ne postavljanjem pravog pitanja.
- [ ] Svakom zahtjevu dajem jedinstveni custom_id i povezujem rezultate prema ID-u.
- [ ] Neuspješne/istekle rezultate mogu obraditi odvojeno.
- [ ] Znam koje su prednosti odabira brzog modela u jednostavnim serijskim poslovima.