Nyereség:
- Meghatározza, hogy mely munkaterhelésekre alkalmas a kötegelt feldolgozás
- Megérti a szinkron, aszinkron és kötegelt feldolgozás közötti költség/késleltetés közötti kompromisszumot
- Robusztus kötegelt munkafolyamatot tervez, amely a custom_id-t az eredményekhez igazítja
A legtöbb LLM-integráció az „élő” forgatókönyvekre összpontosít, amikor a felhasználó a képernyő előtt várja a választ. A professzionális munkaterhelések többsége azonban valójában nem él: több ezer dokumentum címkézése egyik napról a másikra, egy teljes adatkészlet összegzése, teljes hívásfelvételek osztályozása az archívumban. Ezekben a kérdésekben senki sem vár azonnali választ; A lényeg az, hogy olcsón és megbízhatóan végezze el a munkát. A Batch pontosan ezekhez a munkaterhelésekhez való. Ebben az egységben megtudhatja, mi a különbség a szinkron, aszinkron és kötegelt feldolgozás között, amikor a kötegelt feldolgozás a megfelelő választás, és egy robusztus folyamat, amely magabiztosan illeszkedik a custom_id és az eredmények között.
Három működési mód
módban
Hogyan működik
késleltetés
Tipikus költség
megfelelő munkakör
szinkron
Kérelmet nyújt be, és várja a választ
másodpercig
Szabványos
Élő chat, azonnali asszisztens
aszinkron
Sorba állítja a munkát, és értesítést kap, ha befejeződött.
Másodpercek – percek
Szabványos
Háttérfeladatok, automatizálási lépések
Batch
Több ezer kérést küld egy csomagban, majd megkapja az eredményeket
Percek – órák
Általában kedvezményes
Nagy volumenű, késleltetéstűrő munkák
A kötegelt feldolgozás a következő: több száz/ezer kérést küld el egyetlen "feladatként" a szolgáltatónak; A szolgáltató a saját ütemében dolgozza fel őket, és az összes eredményt tömegesen küldi vissza, miután elkészült. Cserébe két dolgot kapsz: (1) általában alacsonyabb fajlagos költséget, (2) nagy mennyiséget mozgathatsz anélkül, hogy a sebességkorlátozásokkal kellene foglalkoznod. Az ára az, hogy az eredmények nem azonnal, hanem egy idő után jönnek.
Mikor kell kötegelni, mikor nem?
A döntés egy kérdésre vezethető vissza: A felhasználó most várja az eredményt?
- Nem, meg tudom tartani → kötegjelölt. Éjszakai címkézés, kötegösszegzés, archív osztályozás, adatgazdagítás, kiértékelés (eval) végrehajtás.
- Igen, vár a képernyőn → szinkronizálás. Élő chat, azonnali tanácsadás, segítség az űrlapok kitöltéséhez.
Tipp: Ugyanabban a termékben két mód is létezhet. A felhasználó szinkronban dolgozik az élő chatben; Éjszaka az aznapi összes beszélgetést átadja a kötegnek minőségi elemzés céljából. Az építészet első döntése az „élő szükséglet” és a „kollektív szükséglet” elkülönítése.
A robusztus szakaszos áramlás anatómiája
A kötegelt feldolgozás legfontosabb technikai szabálya az eredményillesztés.
- Adjon meg minden kérésnek egy egyedi "custom_id" értéket. Ez az Ön által generált azonosító, amely azonosítja a kérést (pl. számla-2026-07-18-000431).
- Adja be a munkát. Minden kérés egy csomagba kerül; mindegyiknek saját custom_id.
- Szavazz a helyzetről. Időközönként kéred a státuszt, amíg a munka "elkészül".
- Párosítsa az eredményeket a "custom_id" paraméterrel. Az eredményeket a benyújtási sorrendtől eltérő sorrendben lehet visszaküldeni; tehát soha ne egyezzen pozíció szerint, hanem az egyes eredmények által hordozott custom_id alapján.
- Ellenőrizze az egyes eredmények típusát. Egy kérés lehet sikeres, egy sikertelen, egy lejárhat. Sikeren/kudarcon alapuló folyamat.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Számla besorolása. Csak JSON visszaküldése.", "üzenetek": [{t"erro":le "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Számla besorolása. Visszaküldés csak a JSON-hoz", ": "csak JSON", "a usssaerges". "tartalom": "{{invoice_text_2}}" }] } } ]}
Figyelem: Az eredmények beküldési sorrend alapján történő egyeztetése az első számú hiba a kötegelés során. A sor nem marad meg. A custom_id nélkül nem tudhatja magabiztosan, hogy melyik eredmény melyik dokumentumhoz tartozik – a rossz egyezés csendben rossz adatokhoz vezet.
Másolható sablonok
# custom_id generálási szabály (egyedi és nyomon követhető) Formátum: <isztúra>-<dátum>-<sorozat>. Példa: request-20260718-000431Szabály: soha ne ismételje meg a munkát; Illessze be az erőforrásrekord azonosítóját.
# Kötegelt feladatkártya (ütemezési sablon)Munka neve: .............Rekordok száma: .............Modell: ............. (egyszerű munka → gyors modell)Max._token kérésenként: .............Várható szállítási idő tolerancia: ......... óra Eredményegyeztetési kulcs: custom_idHiba esetén: újrapróbálkozás / sor / jelentés
# Egyetlen kérés üzenet kötegben (rövid és sematikus) Osztályozza ezt a dokumentumot. Csak küldje vissza ezt a JSON-t, megjegyzéssel:{"kategória":"...","urgency":"low|medium|high"}Dokumentum: """"{{document}}"""
# Az eredményfeldolgozás pszeudokódja minden eredményhez: if result.status == "siker": rekord = find(custom_id) save(rekord, eredmény.kimenet) egyébként: add_to_fail(custom_id, result.error) # majd próbáld újra
Gyenge felszólítás / Erős felszólítás (kötegelt feladat tervezése)
# GYENGE (törékeny kialakítás) 10 000 dokumentumot küldjön sorrendben az erős modellel, és mentse el a visszaküldött eredményeket érkezési sorrendben.
# ERŐS (tartós kivitel) 10 000 dokumentum küldése egy kötegben egy gyors modellel. Adjon meg minden dokumentumnak egy egyedi custom_id-t, amely tartalmazza a forrásrekord azonosítóját. Párosítsa az eredményeket a custom_id-vel; állítsa sorba a sikerteleneket, és próbálja újra.Fuss az éjszakai ablakban; Szállítási tűrés 6 óra.
Erőteljes változat; Előre meghatározza a modell kiválasztását, a megfelelő kulcsot, a hibakezelést és az időzítést. Ez a különbség több tízezer rekord biztonságos feldolgozásában.
Három mini tok
1. eset – Éjszakai címkézés. Egy e-kereskedelmi csapat 200 000 termékértékelést válogatna hangulatcímkékbe. Az élő szinkron közvetítésre sebességkorlátozások vonatkoztak, és költséges volt. Gyors modellel kötegként vitték a munkát éjszakába; Csökkent az egységköltség, reggelre készen volt az egész készlet, és nem volt sebességkorlátozási probléma.
2. eset – Zavart rendelni. Egy kutatócsoport 5000 cikket vett ki, de az eredményeket beérkezésük sorrendjében fájlba írta. Mivel az eredményeket eltérő sorrendben küldték vissza, az 5000 absztraktból körülbelül 900 rossz cikkhez kapcsolódott. Újra leképezték a custom_id-re; probléma megoldódott, és ez a tapasztalat állandó szabály lett: "Mindig az custom_id kötegben."
3. eset – Élő készenlét rossz módban. Egy támogatási csapat megpróbálta a felhasználó által a képernyőn várt élő válaszokat köteggel megadni; A felhasználók elhagyták, mert az eredmények percekkel később érkeztek meg. Az élő munkát visszahelyezték a szinkronizálásra, így csak az éjszakai minőségelemzés maradt a kötegben. Tanulság: A köteg nem élő készenléti üzemmódra való.
Gyakori hibák
- Helyezési eredmények: A sorrend nem marad meg; Használja az custom_id.
- Élő feladat átvitele kötegbe: A felhasználó nem tud perceket várni; kötegelt késleltetéstűrő munkákhoz.
- Nem kezeli a hibaeseteket: Egyes kérések sikertelenül/lejártként térhetnek vissza; Tedd egy külön sorba, és próbáld újra.
- Erős modellhasználati reflex kötegben: A gyors modell + köteg a legolcsóbb kombináció egyszerű munkáknál.
- Nem teszi nyomon követhetővé a custom_id-t: Ha nincs forrásrekord beágyazva az azonosítóba, nehéz lesz visszakapcsolni az eredményt.
- Elfelejti megvizsgálni a helyzetet: eredményeket vár a munka befejezése előtt; Ellenőrizze a befejezés állapotát.
Deeper: A köteg figyelése és a részleges meghibásodás kezelése
A kötegelt feldolgozás legérettebb aspektusa az, hogy más gondolkodásmódot igényel, mint az egyéni hívások: a kötegelt munka „folyamat”, nem „esemény”. Feltételezve, hogy kérések tízezrei mind sikeresek lesznek, törékeny; A valósághű tervezés kezdettől fogva elfogadja a részleges kudarcot. Az egyes eredmények állapota eltérő lehet: sikeres, sikertelen (pl. érvénytelen bevitel), törölt vagy lejárt. Egy robusztus folyam külön-külön dolgozza fel az egyes eredmények állapotát, miközben áthalad rajta, a hibákat egy külön "újrapróbálkozási sorba" helyezi, és ezt a sort külön-külön futtatja.
A második gyakorlat az idempotenciára való tervezés (hogy ugyanazt a munkát kétszer lefuttatva nem okoz kárt). Ha egy köteg megszakad, és újraindítja, ne dolgozza fel újra, és ne írja be kétszer a már feldolgozott rekordokat. A custom_id forrásrekordhoz való hozzárendelése itt is működik: "ezt a rekordot már feldolgozták?" az eredmény mentése előtt. Az ellenőrzés megakadályozza a dupla gépelést.
A harmadik pont az élő közvetítések szakaszolása köteggel. Egyes feladatok élő és kötegelt dimenziókkal is rendelkeznek: amikor a felhasználó betölt egy dokumentumot, gyors előzetes összefoglalót ad neki (szinkron), és ugyanazt a dokumentumot újra feldolgozza az éjszakai mélyebb elemzés érdekében (köteg). A két mód tudatos szétválasztása optimalizálja a felhasználói élményt és a költségeket egyaránt.
Végül a kötegelés a sebességkorlátozások kezelésének egyik módja (8. egység). A nagy mennyiség élő szinkron áramlásban történő küldése állandó 429-et eredményez, míg ugyanazt a mennyiséget kötegelt átvitelre küldve korlátozza a nyomást a szolgáltató saját ütemezésében, és kiszámíthatóbbá teszi a munkát.
Összefoglalva
A kötegelt feldolgozás általában olcsóbb és robusztusabb mód a késleltetéstűrő és nagy volumenű munkaterhelésekhez. Döntése az volt, hogy "a felhasználó most az eredményre vár?" határozza meg a kérdést. A legkritikusabb technikai szabály az, hogy minden kérésnek egyedi custom_id-t kell megadnia, az eredményeket hely helyett azonosító alapján kell párosítani, és minden eredményt külön kell kezelni.
Pályázati feladat
Válasszon nagy volumenű munkát (pl. archív besorolás). (1) Döntse el, hogy ez a mű élő vagy közös, és indokolja meg. (2) Tervezzen meg egy custom_id formátumot (beleértve az erőforrásrekordot). (3) Töltse ki a kötegelt munkakártyát (modell, max_tokens, tolerancia, hibapolitika). (4) Írja be az eredményfeldolgozási pszeudokódot, hogy tartalmazza a sikertelen kéréseket.
ellenőrző lista
- [ ] A költség/késleltetés tengelyen meg tudom különböztetni a szinkron, aszinkron és kötegelt módokat.
- [ ] A megfelelő kérdés feltevésével el tudom dönteni, hogy egy munka alkalmas-e kötegeltre vagy sem.
- [ ] Minden kérésnek egyedi custom_id-t adok, és az eredményeket azonosítóval egyeztetem.
- [ ] A sikertelen/lejárt eredményeket külön is tudom kezelni.
- [ ] Ismerem a gyors modell kiválasztásának előnyeit egyszerű kötegelt munkáknál.