Пакетна и асинхрона радна оптерећења

Добици:

• Одређује за која је радна оптерећења групна обрада погодна
• Разуме компромис између цене и кашњења између синхроне, асинхроне и групне обраде
• Дизајнира робустан групни радни ток који одговара цустом_ид са резултатима

Већина ЛЛМ интеграција се фокусира на „живе“ сценарије у којима корисник чека одговор испред екрана. Али већина професионалних задатака заправо није активна: означавање хиљада докумената преко ноћи, сумирање читавог скупа података, класификовање читавих снимака позива у архиву. У овим питањима нико не очекује тренутни одговор; Важно је да посао завршите јефтино и поуздано. Батцх је управо за ова оптерећења. У овој јединици ћете научити разлику између синхроне, асинхроне и групне обраде, када је серија прави избор, и робусног тока који поуздано одговара цустом_ид-у и резултатима.

Три режима рада

режим

Како то ради

кашњење

Типични трошак

одговарајући посао

синхрони

Поднесете захтев и чекате одговор

секунди

Стандард

Ћаскање уживо, тренутни асистент

асинхрони

Стављате посао у ред чекања и добијате обавештење када се заврши.

Секунде – минуте

Стандард

Позадински задаци, кораци аутоматизације

Батцх

Шаље хиљаде захтева у једном пакету, а затим добија резултате

Минуте–сати

Обично снижено

Послови великог обима, толерантни на кашњење

Групна обрада је следећа: шаљете стотине/хиљаде захтева као један "посао" добављачу; Добављач их обрађује сопственим темпом и враћа све резултате на велико када се заврши. Заузврат добијате две ствари: (1) генерално нижу јединичну цену, (2) могућност кретања великог обима без потребе да се носите са ограничењима брзине. Цена је у томе што резултати не долазе одмах, већ након неког времена.

Када се мешати, када не?

Одлука се своди на једно питање: Да ли корисник сада чека резултат?

• Не, могу да задржим → кандидат за групу. Ноћно означавање, сумирање серије, класификација архиве, обогаћивање података, извршење евалуације (евал).
• Да, чека се на екрану → синхронизација. Ћаскање уживо, тренутни савети, помоћ при попуњавању образаца.

Савет: Два режима могу коегзистирати у истом производу. Корисник ради синхроно у ћаскању уживо; Ноћу све разговоре тог дана дајете групи на квалитетну анализу. Раздвајање „животне потребе“ од „колективне потребе“ је прва одлука архитектуре.

Анатомија робусног шаржног тока

Најважније техничко правило групне обраде је подударање резултата.

1. Дајте сваком захтеву јединствени `цустом_ид`. Ово је ваш генерисани ИД који идентификује захтев (нпр. фактура-2026-07-18-000431).
2. Пошаљите посао. Сви захтеви иду у једном пакету; сваки са сопственим цустом_ид.
3. Испитајте ситуацију. Тражите статус у интервалима све док посао није „готов“.
4. Упарите резултате са `цустом_ид`. Резултати се могу вратити другачијим редоследом од редоследа за подношење; тако да се никада не подударајте по позицији већ према цустом_ид-у који сваки резултат носи.
5. Проверите врсту сваког резултата. Један захтев може успети, један пропасти, један може истећи. Процес заснован на успеху/неуспеху.

{ "рекуестс": [ { "цустом_ид": "инвоице-000431", "парамс": { "модел": "цлауде-хаику-4-5", "мак_токенс": 128, "систем": "Класификујте фактуру. Врати само ЈСОН.", "мессагес": "": " "{{инвоице_тект}}" }] } }, { "цустом_ид": "инвоице-000432", "парамс": { "модел": "цлауде-хаику-4-5", "мак_токенс": 128, "систем": "Класификуј фактуру.", "Врати само ЈСОНгес", "Врати само ЈСОН". "цонтент": "{{инвоице_тект_2}}" }] } } ]}

Опрез: Упаривање резултата на основу налога за подношење је грешка број један у груписању. Ред није сачуван. Без цустом_ид не можете са сигурношћу знати који резултат припада којем документу — погрешно подударање тихо води до погрешних података.

Цопиабле Темплатес

# правило генерисања цустом_ид (јединствено и следљиво)Формат: <истуре>-<датум>-<секвенца>. Пример: захтев-20260718-000431Правило: никада се не понављајте у раду; Уградите ИД записа ресурса у њега.

# Картица пакетног посла (шаблон за планирање) Назив посла: .............Број записа: .............Модел: ............. (једноставан посао → брзи модел)Максимални_токени по захтеву: .............Очекивана толеранција времена испоруке: ......... сати Кључ подударања резултата: цустом_идУ случају грешке: покушај поново / ред / извештај

# Један захтев у групи (кратак и шематски) Класификујте овај документ. Само вратите овај ЈСОН, коментаришући:{"цатегори":"...","ургенци":"лов|медиум|хигх"}Документ: """{{доцумент}}"""

# Обрада псеудо кода резултата за сваки резултат: иф ресулт.статус == "успех": рецорд = финд(цустом_ид) саве(рецорд, ресулт.оутпут) иначе: адд_то_фаил(цустом_ид, ресулт.еррор) # затим покушајте поново

Слабо обавештење / Јако обавештење (дизајн групног посла)

# СЛАБО (крхки дизајн) Пошаљите 10.000 докумената по реду са јаким моделом, сачувајте враћене резултате редоследом којим стижу.

# СНАЖАН (издржљив дизајн) Пошаљите 10.000 докумената у једној серији са брзим моделом. Дајте сваком документу јединствени цустом_ид који садржи ИД изворног записа. Ускладите резултате са цустом_ид; ставите неуспеле у ред и покушајте поново. Трчите у ноћном прозору; Толеранција испоруке 6 сати.

Моћна верзија; Он унапред дефинише избор модела, одговарајући кључ, руковање грешкама и тајминг. Ово је разлика у безбедној обради десетина хиљада записа.

Три мини кућишта

Случај 1 — Ноћно означавање. Тим за е-трговину би сортирао 200.000 рецензија производа у ознаке сентимента. Синхрони стриминг уживо подлегао је ограничењима брзине и био је скуп. Носили су посао у ноћ као серија са брзим моделом; Јединични трошак је пао, цео сет је био спреман ујутру и није било проблема са ограничењем брзине.

Случај 2 — Забуна налога. Група истраживачког тима је апстраховала 5.000 чланака, али је резултате записала у фајлове редоследом којим су стигли. Пошто су резултати враћени другачијим редоследом, отприлике 900 од 5.000 сажетака је повезано са погрешним чланком. Пресликали су га на цустом_ид; проблем је решен и ово искуство је постало трајно правило: "Увек цустом_ид у групи."

Случај 3 — Стање приправности уживо у погрешном режиму. Тим за подршку је покушао да на екрану да серију одговора уживо које је корисник очекивао; Корисници су одустали јер су резултати стигли неколико минута касније. Померили су посао уживо назад на синхронизацију, остављајући само ноћну анализу квалитета у групи. Лекција: серија није за ливе стандби.

Уобичајене грешке

• Резултати подударања по позицији: Редослед није сачуван; Користите цустом_ид.
• Пренос живог посла у групу: Корисник не може да чека неколико минута; серија је за послове толерантне на кашњење.
• Не обрађује случајеве грешке: Неки захтеви могу да врате неуспешне/истекле; Ставите га у посебан ред и покушајте поново.
• Снажан рефлекс употребе модела у серији: Брзи модел + серија је најјефтинија комбинација у једноставним пословима.
• Не омогућава праћење цустом_ид: Ако ниједан изворни запис није уграђен у ИД, постаје тешко поново повезати резултат.
• Заборављање да се испита ситуација: Очекивање резултата пре него што се посао заврши; Проверите статус завршетка.

Дубље: надгледање серије и управљање делимичним кваром

Најзрелији аспект групне обраде је да захтева другачији начин размишљања од појединачних позива: групни посао је „процес“, а не „догађај“. Под претпоставком да ће десетине хиљада захтева сви успети је крхко; Реалистичан дизајн прихвата делимични неуспех од самог почетка. Статус сваког резултата може бити различит: успешан, неуспешан (нпр. неважећи унос), отказан или истекао. Робустан ток обрађује статус сваког резултата посебно док путује кроз њега, ставља грешке у посебан „ред за поновни покушај“ и покреће тај ред одвојено.

Друга пракса је дизајнирање за идемпотенцију (да покретање истог посла двапут не узрокује никакву штету). Ако је серија прекинута и поново је покренете, не би требало да поново обрађујете и пишете два пута већ обрађене записе. Везивање цустом_ид за ваш изворни запис функционише и овде: „да ли је овај запис већ обрађен?“ пре него што сачувате резултат. Провера спречава двоструко куцање.

Трећа тачка је да се стримови уживо преклапају са серијама. Неки послови имају и живу и скупну димензију: када корисник учита документ, ви му дајете брзи прелиминарни резиме (синхрони) и поново обрађујете исти документ за дубљу анализу ноћу (скупна). Свесно одвајање ова два режима оптимизује и корисничко искуство и цену.

Коначно, дозирање је такође начин да се носи са ограничењима брзине (јединица 8). Слање великог обима у живом синхроном току производи константно 429, док слање истог обима у пакет преноси гранични притисак на сопствени распоред провајдера и чини посао предвидљивијим.

Укратко

Пакетна обрада је генерално јефтинији и робуснији режим за радна оптерећења која су толерантна на кашњење и велики обим. Његова одлука је била "да ли корисник сада чека резултат?" одређује питање. Најкритичније техничко правило је да се сваком захтеву додели јединствени цустом_ид, да се резултати подударају по ИД-у, а не по локацији, и да се успех/неуспех сваког резултата третира засебно.

Задатак апликације

Изаберите посао великог обима (нпр. класификација архиве). (1) Одлучите да ли је ово дело живо или колективно и оправдајте га. (2) Дизајнирајте цустом_ид формат (укључите запис ресурса). (3) Попуните картицу скупног посла (модел, мак_токени, толеранција, политика грешака). (4) Напишите псеудокод за обраду резултата да бисте укључили неуспеле захтеве.

контролна листа

• [ ] Могу да разликујем синхрони, асинхрони и пакетни режим на оси цена/кашњење.
• [ ] Могу да одлучим да ли је посао погодан за групни рад или не постављањем правог питања.
• [ ] Сваком захтеву дајем јединствени цустом_ид и подударам резултате према ИД-у.
• [ ] Неуспеле/истекле резултате могу да обрадим одвојено.
• [ ] Знам предности избора брзог модела у једноставним групним пословима.