Erä- ja asynkroniset työmäärät

Voitot:

• Määrittää, mihin työkuormiin eräkäsittely sopii
• Ymmärtää kustannus/viive-korjauksen synkronisen, asynkronisen ja eräkäsittelyn välillä
• Suunnittelee vankan erätyönkulun, joka sovittaa custom_id:n tuloksiin

Useimmat LLM-integraatiot keskittyvät "eläviin" skenaarioihin, joissa käyttäjä odottaa vastausta näytön edessä. Mutta suurin osa ammatillisista työkuormista ei ole todellisuudessa reaaliajassa: tuhansien asiakirjojen merkitseminen yössä, yhteenveto koko tietojoukosta, kokonaisten puhelutallenteiden luokittelu arkistoon. Näissä asioissa kukaan ei odota välitöntä vastausta; Tärkeintä on saada työ valmiiksi halvalla ja luotettavasti. Erä on juuri näitä työkuormia varten. Tässä osiossa opit eron synkronisen, asynkronisen ja eräkäsittelyn välillä, kun erä on oikea valinta, ja vankan kulun, joka täsmää luotettavasti custom_id:n ja tulosten välillä.

Kolme työtilaa

-tilassa

Miten se toimii?

viive

Tyypillinen hinta

sopiva työ

synkroninen

Teet pyynnön ja odotat vastausta

sekuntia

Vakio

Live-chat, välitön avustaja

asynkroninen

Asetat työn jonoon ja saat ilmoituksen, kun se on valmis.

Sekunnit-minuutit

Vakio

Taustatehtävät, automatisoinnin vaiheet

Erä

Lähettää tuhansia pyyntöjä yhdessä paketissa ja saa sitten tulokset

Minuutit-tunnit

Yleensä alennettu

Suuren volyymin, viivettä sietävät työt

Eräkäsittely on seuraava: lähetät satoja/tuhansia pyyntöjä yhtenä "työnä" palveluntarjoajalle; Palveluntarjoaja käsittelee ne omaan tahtiinsa ja palauttaa kaikki tulokset joukkona, kun ne on suoritettu. Vastineeksi saat kaksi asiaa: (1) yleensä alhaisemmat yksikkökustannukset, (2) mahdollisuuden siirtää suuria volyymeja ilman, että joudut käsittelemään nopeusrajoituksia. Hinta on, että tulokset eivät tule heti, vaan jonkin ajan kuluttua.

Milloin erä, milloin ei?

Päätös perustuu yhteen kysymykseen: odottaako käyttäjä tulosta nyt?

• Ei, voin pitää sen → eräehdokas. Yökoodaus, erän yhteenveto, arkiston luokittelu, tietojen rikastaminen, arvioinnin (eval) suoritus.
• Kyllä, odottaa näyttöä → synkronointi. Live-chat, välitöntä neuvontaa, apua lomakkeiden täyttämisessä.

Vinkki: Samassa tuotteessa voi olla kaksi tilaa. Käyttäjä toimii synkronisesti live-chatissa; Yöllä annat kaikki kyseisen päivän keskustelut erälle laatuanalyysiä varten. "Elävän tarpeen" erottaminen "kollektiivisesta tarpeesta" on arkkitehtuurin ensimmäinen päätös.

Vankan erävirran anatomia

Eräkäsittelyn tärkein tekninen sääntö on tulosten täsmääminen.

1. Anna kullekin pyynnölle yksilöllinen "custom_id". Tämä on luomasi tunnuksesi, joka tunnistaa pyynnön (esim. lasku-2026-07-18-000431).
2. Lähetä työ. Kaikki pyynnöt menevät samaan pakettiin; jokaisella on oma custom_id.
3. Kysele tilanteesta. Pyydät tilaa aika ajoin, kunnes työ on "valmis".
4. Yhdistä tulokset mukautetun_id:n kanssa. Tulokset voidaan palauttaa eri järjestyksessä kuin lähetysjärjestyksessä; joten älä koskaan täsmää sijainnin mukaan vaan kunkin tuloksen sisältämän custom_id:n mukaan.
5. Tarkista kunkin tuloksen tyyppi. Yksi pyyntö voi onnistua, yksi voi epäonnistua, yksi voi vanhentua. Menestykseen/epäonnistumiseen perustuva prosessi.

{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Luokittele lasku. Palauta vain JSON.", "viestit": [{ "t"erro"," "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Luokittele lasku. Palauta vain JSON", "": "vain "userroges", " "sisältö": "{{invoice_text_2}}" }] } } ]}

Varoitus: Tulosten täsmääminen lähetysjärjestyksen perusteella on ykkösvirhe erässä. Jonoa ei säilytetä. Ilman custom_id:tä et voi varmuudella tietää, mikä tulos kuuluu mihinkin dokumenttiin – väärä vastaavuus johtaa hiljaa vääriin tietoihin.

Kopioitavat mallit

# custom_id:n luomissääntö (ainutlaatuinen ja jäljitettävissä) Muoto: <isture>-<päivämäärä>-<sekvenssi>. Esimerkki: request-20260718-000431Sääntö: älä koskaan toista työssä; Upota siihen resurssitietueen tunnus.

# Erätyökortti (aikataulumalli)Työn nimi: .............Tietueiden lukumäärä: .............Malli: ............. (yksinkertainen työ → nopea malli)Max_tokens per pyyntö: .............Odotettu toimitusaikatoleranssi: ......... tuntiaTuloksen täsmäytysavain: custom_idVirhetapauksessa: yritä uudelleen / jono / raportti

# Yhden pyynnön kehote eränä (lyhyt ja kaavamainen) Luokittele tämä asiakirja. Palauta tämä JSON kommentoimalla:{"luokka":"...","kiire":"low|medium|high"}Asiakirja: """"{{document}}"""

# Tuloksen käsittelyn pseudokoodi jokaiselle tulokselle: if result.status == "onnistuminen": tietue = find(custom_id) save(tietue, tulos.tulostus) muuten: add_to_fail(custom_id, result.error) # yritä sitten uudelleen

Heikko kehote / Vahva kehote (erätyön suunnittelu)

# HEIKKO (hauras muotoilu) Lähetä 10 000 asiakirjaa järjestyksessä vahvalla mallilla, tallenna palautetut tulokset saapumisjärjestyksessä.

# VAHVA (kestävä muotoilu) Lähetä 10 000 asiakirjaa yhdessä erässä nopealla mallilla. Anna kullekin asiakirjalle yksilöllinen custom_id, joka sisältää lähdetietueen tunnuksen. Yhdistä tulokset custom_id:n kanssa; aseta epäonnistuneet jonoon ja yritä uudelleen. Suorita yöikkunassa; Toimitustoleranssi 6 tuntia.

Tehokas versio; Se määrittää ennalta mallin valinnan, sovitusavaimen, virheiden käsittelyn ja ajoituksen. Tämä on ero kymmenien tuhansien tietueiden turvallisessa käsittelyssä.

Kolme minikoteloa

Tapaus 1 – Yömerkintä. Verkkokauppatiimi lajitteli 200 000 tuotearviota mielipidetunnisteiksi. Synkroniseen suoratoistoon kohdistui nopeusrajoituksia ja se oli kallista. He kantoivat työn yöhön eränä nopealla mallilla; Yksikköhinta laski, koko setti oli aamulla valmis, eikä nopeusrajoitusongelmia ollut.

Tapaus 2 – Sekaannukset. Tutkimusryhmä tiivisti 5 000 artikkelia, mutta kirjoitti tulokset tiedostoihin saapumisjärjestyksessä. Koska tulokset palautettiin eri järjestyksessä, noin 900 5000 abstraktista linkitettiin väärään artikkeliin. He yhdistävät sen uudelleen muotoon custom_id; ongelma ratkaistu ja tästä kokemuksesta tuli pysyvä sääntö: "Aina custom_id erässä."

Tapaus 3 — Suora valmiustila väärässä tilassa. Tukitiimi yritti antaa erässä reaaliaikaisia ​​vastauksia, joita käyttäjä odotti näytöllä. Käyttäjät hylkäsivät, koska tulokset saapuivat minuutteja myöhemmin. He siirsivät live-työn takaisin synkronointiin, jolloin erään jäi vain iltainen laatuanalyysi. Oppitunti: erä ei ole suorassa valmiustilassa.

Yleisiä virheitä

• Vastaavia tuloksia sijainnin mukaan: Järjestystä ei säilytetä; Käytä custom_id.
• Livetyön siirtäminen erälle: Käyttäjä ei voi odottaa minuutteja; erä on tarkoitettu viivettä kestäviin töihin.
• Ei käsittele virhetapauksia: Jotkut pyynnöt voivat palauttaa epäonnistuneen/vanhentuneen; Aseta se erilliseen jonoon ja yritä uudelleen.
• Vahva mallinkäyttörefleksi erässä: Nopea malli + erä on halvin yhdistelmä yksinkertaisissa töissä.
• Ei tehdä custom_id:tä jäljitettäväksi: Jos tunnukseen ei ole upotettu lähdetietuetta, tuloksen linkittäminen takaisin on vaikeaa.
• Unohdat tarkastella tilannetta: Odottaa tuloksia ennen kuin työ on valmis; Tarkista valmistumisen tila.

Deeper: Erän valvonta ja osittaisten virheiden hallinta

Eräkäsittelyn kypsin puoli on, että se vaatii erilaista ajattelutapaa kuin yksittäiset puhelut: erätyö on "prosessi", ei "tapahtuma". Olettaen, että kaikki kymmenet tuhannet pyynnöt onnistuvat, on hauras; Realistinen suunnittelu hyväksyy osittaisen epäonnistumisen alusta alkaen. Kunkin tuloksen tila voi olla erilainen: onnistunut, epäonnistunut (esim. virheellinen syöttö), peruutettu tai vanhentunut. Vankka vuo käsittelee kunkin tuloksen tilan erikseen kulkiessaan sen läpi, asettaa virheet erilliseen "uudelleenyritysjonoon" ja ajaa jonon erikseen.

Toinen käytäntö on suunnitella idempotenssia varten (että saman työn suorittaminen kahdesti ei aiheuta haittaa). Jos erä keskeytetään ja käynnistät sen uudelleen, sinun ei tule käsitellä uudelleen ja kirjoittaa kaksi kertaa jo käsiteltyjä tietueita. Custom_id:n sitominen lähdetietueeseen toimii myös tässä: "onko tämä tietue jo käsitelty?" ennen tuloksen tallentamista. Tarkistaminen estää kaksinkertaisen kirjoittamisen.

Kolmas kohta on porrastaa live-lähetyksiä erän kanssa. Joillakin töillä on sekä live- että erämitat: kun käyttäjä lataa asiakirjan, annat hänelle nopean alustavan yhteenvedon (synkroninen) ja käsittelet saman asiakirjan uudelleen syvempää analysointia varten yöllä (erä). Kahden tilan tietoinen erottaminen toisistaan ​​optimoi sekä käyttökokemuksen että kustannukset.

Lopuksi eräkäsittely on myös tapa käsitellä nopeusrajoituksia (yksikkö 8). Suuren volyymin lähettäminen live-synkronisessa virtauksessa tuottaa vakion 429:n, kun taas saman määrän lähettäminen eräsiirtoihin rajoittaa painetta palveluntarjoajan omaan aikatauluun ja tekee työstä ennakoitavamman.

Yhteenvetona

Eräkäsittely on yleensä halvempi ja kestävämpi tila latenssia sietäville ja suuren volyymin työkuormille. Hänen päätöksensä oli "odottaako käyttäjä nyt tulosta?" ratkaisee kysymyksen. Kriittisin tekninen sääntö on antaa kullekin pyynnölle yksilöllinen custom_id, sovittaa tulokset tunnuksen sijaan sijainnin perusteella ja käsitellä jokaista tulosta onnistuneen/epäonnistuneena erikseen.

Sovellustehtävä

Valitse suurimääräinen työ (esim. arkistoluokitus). (1) Päätä, onko tämä teos suoraa vai kollektiivista, ja perustele se. (2) Suunnittele custom_id-muoto (sisällytä resurssitietue). (3) Täytä erätyökortti (malli, max_tokens, toleranssi, virhepolitiikka). (4) Kirjoita tuloksenkäsittelyn pseudokoodi, joka sisältää epäonnistuneet pyynnöt.

tarkistuslista

• [ ] Pystyn erottamaan synkroniset, asynkroniset ja erämuodot kustannus/viive-akselilla.
• [ ] Pystyn oikean kysymyksen avulla päättämään, sopiiko työ joukkoon vai ei.
• [ ] Annan jokaiselle pyynnölle yksilöllisen custom_id-tunnuksen ja yhdistän tulokset tunnuksella.
• [ ] Pystyn käsittelemään epäonnistuneita/vanhentuneita tuloksia erikseen.
• [ ] Tiedän nopean mallin valitsemisen edut yksinkertaisissa erätöissä.