Ühtsed paketttööd AI API lüüsi kaudu: vastupidavad järjekorrad, pakkujaadapterid ja rentniku tasemel arveldamine

Komplekitöötlust ei tohiks käsitleda AI API lüüsi ümbritseva küljeuksena. Kui hindamised, dokumentide rikastamine, ekstraktimine, modereerimise pühkimine või manustamine lahkuvad sünkroonse päringu teelt, vajavad nad endiselt rentnike juhtelemente, kulude omistamist, korduskatsetusi, auditeeritavust ja kasutusanalüüsi.

Rakendusmuster on muuta partii täitmine esmaklassiliseks lüüsi alamsüsteemiks. Lüüs peaks paljastama ühe pakkuja-neutraalse töölepingu, kohanedes samal ajal OpenAI, Anthropic, Gemini ja tulevaste pakkujate pakett-API-dega.

Lugeja probleem: pakett-API-d on eesmärgi poolest sarnased, erinevad toimimisviisilt

Laitentsust taluvad töökoormused sobivad komplekti täitmiseks loomulikult. Raske osa ei ole otsustamine, kas töö võib oodata. Raske osa on paketttöö järjepidev kasutamine kõigi pakkujate vahel.

Kinnitatud faktid: OpenAI Batch API on asünkroonne, loeb üleslaaditud failist päringuid, kirjutab vastuseid väljundfaili ja kasutab praegu 24-tunnist töötlemisakent. OpenAI loetleb sellised olekud nagu validating, ebaõnnestunud, in_progress, finalising, lõpetatud, aegunud, tühista ja tühista. Anthropicu Message Batches API töötleb paljusid sõnumite taotlusi asünkroonselt, käsitleb iga päringut iseseisvalt, nõuab küsitlust ja tagastab tulemused pärast töötlemise lõppemist. Anthropic soovitab ka tähenduslikke custom_id väärtusi, kuna tulemuste järjekord pole garanteeritud. Gemini Batch API paljastab pikaajalised toimimisstiilis meetodid, nagu loendi-, tühistamis-, kustutamis- ja värskendamismeetodid, ning selle tühistamise toimingut kirjeldatakse kui parimat.

Need erinevused on olulised, kui lisate tegelikud ärinõuded.

• Milline üürnik, klient, projekti või API võti omab iga üksust >< reserveeris iga üksuse?
• Kuidas eelarve lõpetati?
• Milline oli eelarve lõpetamine? üksused on arveldatavad, kui partii aegub või tühistatakse?
• Kuidas osaliste tõrgete korral uuesti proovitakse ilma edukat tööd dubleerimata?
• Kui kaua saab tulemusfaile alla laadida ja mida peaks lüüsi salvestama?
• Kas partner saab luua kliendi ulatusega paketttöötlust ilma, et see avaldaks ülesvoolu pakkujat hiilge>

  Soovitatud avalik API: eraldage paketttööd sünkroonsetest lõpetamistest

  Soovitus: eksponeerige paketttööd oma API-pinnal, mitte spetsiaalse lipuna. Sünkroonsel päringul ja asünkroonsel pakktööl on erinev olelustsükkel, arveldamine, uuesti proovimine ja tulemuste otsimise semantika.

  Praktiline lüüsileping sisaldab järgmisi toiminguid:

  • create_job: looge üürnikule, projektile, võtmele või partnerkliendile kuuluv töö mustand.or
  . upload_manifest: lisage individuaalseid taotlusi stabiilsete üksuste identifikaatoritega.
  • submit: kinnitage, reserveerige eelarve, valige pakkuja, saatke ja lukustage esitatud manifest.
  • get_status: tagastage normaliseeritud töö ja üksuste loendused.
  • lehekülgedels on normaled, item_re: pagess list, itre: pagess kasutamine.
  • tühista: taotlege tühistamist, lubamata kohest lõpetamist.
  • export_usage: ekspordi töö- ja kaubataseme kulukirjed analüüsi- või arveldussüsteemide jaoks.

  Avaliku tööobjekti näide:

  {
    "job_id": "job_01j7...",
    "rentant_id": "rentant_acme",
    "customer_id": "cust_123",
    "endpoint": "chat.completions",
    "mudel": "analüüs-suur",
    "status": "töötab",
    "loeb": {
      "esitatud": 50000,
      "lõpetatud": 31240,
      "ebaõnnestus": 180,
      "aegunud": 0
    },
    "kulu": {
      "estimated": "184.20",
      "reserveeritud": "205.00",
      "arveldatud": "117.43",
      "valuuta": "USD"
    },
    "created_at": "2026-08-19T10:00:00Z",
    "submitted_at": "2026-08-19T10:05:00Z",
    "retrieval_deadline": "2026-09-17T10:00:00Z"
  }

  Avalik objekt ei tohiks vaikimisi paljastada pakkuja faili ID-sid, toimingute nimesid ega töötlemata ülesvoolu vigu. Need kuuluvad operaatorile suunatud metaandmete hulka.

  Kasutage tõe allikana püsivaid töökirjeid

  Lüüsile kuuluv partiikiht vajab püsivat olekut, enne kui midagi ülesvoolu edastatakse. Ärge lootke pakkuja partiikirjetele kui oma ainsale osariigi poele. Pakkuja kirjed on vajalikud, kuid nad ei tea teie rentnike hierarhiat, eelarvereservatsioone, sisemudelite varjunimesid, partnerkliente ega analüüsinõudeid.

  Andmebaasi miinimummudel

  Kasulikul skeemil on kolm taset:

  1. Paketttöö

  pakendatud_tööd
  - töö_id
  - üürniku_id
  - projekti_id
  - kliendi_id on tühine- api_key_id
  - lõpp-punkt
  - taotletud_mudel
  - lahendatud_pakkuja
  - lahendatud_pakkuja_mudel
  - staatus
  - üksuste_arv
  - hinnangulised_sisendmärgid
  - hinnangulised_väljundi_märgid
  - reserveeritud_summa
  - arveldatud_summa
  - loodud_at
  - esitatud_at
  - lõpetatud_kell
  - aegub_kell
  - otsingu_tähtaeg
  - tühistamine_taotletud_at

  2. Partii üksus

  partii_üksused
  - töö_id
  - üksuse_id
  - kohandatud_id
  - idempotentsuse_võti
  - request_hash
  - staatus
  - pakkuja_taotluse_indeks on tühine
  - hinnangulised_märgid
  - tegelik_sisend_tokenid on tühised
  - tegelik_väljundi_tokenid on tühised
  - arveldatud_summa nullable
  - result_pointer nullable
  - vea_kood on tühine
  - üksuse_id uuesti proovimine on tühine
  - loodud_at
  - arveldatud_at

  3. Pakkuja metaandmed

  batch_provider_metadata
  - töö_id
  - pakkuja
  - pakkuja_partii_id on tühine
  - sisendfaili_id on tühine
  - väljundi_faili_id on tühine
  - error_file_id on tühine
  - operatsiooni_nimi on tühine
  - lõpp-punkt
  - piirkond on tühine
  - native_status
  - native_request_counts jsonb
  - viimane_küsitlus_kell
  - raw_error_pointer nullable

  Pakkuja metaandmete eraldamine avalikust töölepingust võimaldab lüüsil arendada pakkuja adaptereid ilma rentnikule suunatud API-sid rikkumata.

  Enne saatmist on vaja stabiilseid üksuse identifikaatoreid

  soovitus generation: üksuse kohta custom_id või idempotentsuse võti enne saatmist. Ärge kunagi viige tulemusi järjestuse järgi.

  Anthropic hoiatab selgesõnaliselt, et tulemuste järjekord ei ole garanteeritud, ja soovitab sisukaid custom_id väärtusi. Isegi kui näib, et teenusepakkuja hoiab korda, ei tohiks värav sellest sõltuda. Tööd tükeldatakse, proovitakse uuesti, tühistatakse, täidetakse osaliselt ja võetakse uuesti sisse. Eelduse tellimine ebaõnnestub lõpuks.

  Turvaline üksuse identifikaatori vorming on kirjeldav, kuid mitte tundlik:

  tenantA.invoice_extraction.2026-08-19.row_000381

  Vältige toormeilide, nimede, kliendi salajaste dokumentide pealkirjade või . Salvestage tundlikud korrelatsiooniandmed oma rentnike andmebaasis, mitte pakkujale nähtavates ID-des.

  Olekute normaliseerimine ilma pakkuja üksikasju kustutamata

  Pakkuja pakett-API-d paljastavad erinevad elutsüklid. Lüüs peaks normaliseerima need väikeseks sisemiseks olekumasinaks, mida armatuurlauad, arveldamine ja automatiseerimine mõistavad.

  Soovitatav normaliseeritud elutsükkel:

  • mustand: töö on olemas, kuid seda saab veel redigeerida.
  • kinnitamine: >< kood ei tööta,: kood:
  validation ei ole aktsepteeritud. veel töötleb.
  • töötab: pakkuja töötleb üksusi.
  • finalising: pakkuja on arvutuse lõpetanud ja valmistab ette tulemuste artefakte.
  • lõpetatud: kõik aktsepteeritud üksused jõudsid terminali eduni.
  • completed_with_errors: mõned elemendid on ebaõnnestunud: mõned elemendid on õnnestunud: mõned elemendid õnnestusid lõppes enne kõigi tööde lõpetamist.
  • tühista_taotletud: üürnikul paluti tühistada, kuid lõplikku arveldatavat tööd ei tasutud.
  • tühistatud: tühistamine lahendatud.
  • ebaõnnestunud: töötaseme tõrge takistas kasulikku täitmist.

  D generic not errors avardab liiga varakult. Silumisel vajavad operaatorid endiselt juurdepääsu algolekutele, valideerimisvigadele, taotluste loenditele, faili ID-dele ja toimingute nimedele.

  Kinnitage enne esitamist võimemaatriksi alusel

  Soovitus: käivitage enne eelarve broneerimist ja teenusepakkuja väljasaatmist lennueelne valideerimine. Pakettrežiim ei ole lihtsalt viivitusega sünkroonrežiim. Teatud mudeleid, lõpp-punkte, päringu funktsioone, piirkondi ja tööriista konfiguratsioone ei pruugi teenusepakkuja pakett-API toetada.

  Teie sisemine võimete maatriks peaks kontrollima järgmist:

  • toetatud lõpp-punkt: vestlus, sõnumid, manustused, modereerimine või genereerimine.
  • mudeli sobivus pakettrežiimi jaoks, faili maksimaalne suurus ja üleslaadimise suurus.
  >
  • suurus.
  • Kas voogesitus on keelatud.
  • Tööriistade kasutamise ja funktsioonide kutsumise tugi.
  • Struktureeritud väljundi või JSON-skeemi tugi.
  • Pildi-, heli- või multimodaalse sisendi tugi.
  • Piirangud piirkonnas ja asukohas.
  • Pakkuja säilitamise ja tulemuste määramise limiit. piirangud.
  • Tühistamise semantika.

  Hea lennueelne vastus on spetsiifiline:

  {
    "error": "batch_capability_not_supported",
    "message": "Valitud pakkuja pakkadapter ei toeta voogesituse vastuseid. Eemaldage stream=true või valige sünkroonne lõpp-punkt.",
    "väli": "üksused[*].request.stream"}

  See on kasulikum kui töö vastuvõtmine ja ebaõnnestumine pärast ülesvoolu kinnitamise läbimist.

  Reserveerige üürniku eelarve, seejärel arveldage tegelik kasutus

  Pakkide täitmine muudab arveldamise keerulisemaks, kuna lüüs võib kaotada sünkroonse juurdepääsu täpsele kasutamisele, kuni tulemuste failid on saadaval. Ohutu muster on pakkumine, reserveerimine, esitamine, allaneelamine, arveldamine ja vastavusse viimine.

  Kinnitatud faktid: OpenAI väidab, et API partii hinda pakutakse sünkroonsete API-dega võrreldes allahindlusega ning aegunud või tühistatud partiid võivad siiski tagastada lõpetatud tööd, mille eest tuleb tasuda. Anthropic märgib, et suure läbilaskevõimega paketttöötlus võib veidi ületada tööruumi kululimiiti, muutes lüüsipoolse broneerimise ja arveldamise oluliseks.

  Soovitus: reserveerige üürniku eelarve enne esitamist, kasutades hinnangulisi märke, valitud pakkuja hinnareegleid ja turvavaru. Pärast tulemuste allaneelamist määrake tegelik kasutus üksuse tasemel. Kui hinnang oli liiga kõrge, vabastage kasutamata broneering. Kui see oli liiga madal, rakendage üürniku konfigureeritud ülejäägipoliitikat.

  Praktilised pearaamatu sündmused:

  batch.estimated
  partii.reserveeritud
  partii.esitatud
  partii.kaup.arveldatud
  partii.kaup.tagastatud
  batch.cancel_requested
  partii.aegunudbatch.reconciled

  Kaubataseme pearaamat on hädavajalik. Kui 45 000 üksust on valmis ja 5000 aeguvad, tuleks rentnikule esitada arve lõpetatud teenusepakkuja töö eest, mitte algse manifesti kui ühe eristamata blobina.

  Ehitage teenusepakkuja adaptereid tõlkijatena, mitte äriloogika omanikena

  Iga pakkuja adapter peaks teadma, kuidas teisendada pakkuja itrie gateway oleku, retrie gateway polli vormingu, retrie gateway oleku või allalaadimise vorminguks. tulemused ja vastendada natiivsed tulemused tagasi normaliseeritud kirjeteks.

  Hoidke rentniku poliitika väljaspool adapterit. Adapter ei tohiks otsustada, kas kliendil on piisavalt eelarvet, kas partnerklient on peatatud või kas viipasid saab salvestada. Need on lüüsiotsused.

  Adapteri kohustused

  • Renderdage pakkujapõhiseid päringu manifeste.
  • Laadige üles sisendfailid või looge teenusepakkuja toiminguid.
  • Salvestage pakkuja identifikaatorid metaandmetes.
  • Kaardage oma olek ja väljundis normaliseeritud olekuga.
  artefaktid.
  • Parsige üksuse tasemel tulemusi.
  • Tagastage oma kasutuskirjed, kui need on saadaval.
  • Pinnal uuesti proovitavad versus terminali vead.

  Lüüsi kohustused

  • Autentige rentnik ja kliendi võti,
  • varjunimed ja pakkuja marsruutimise poliitika.
  • Kontrollige komplekti.
  • Reserveerige ja arveldage eelarve.
  • Säilitage töö ja üksuse olek.
  • Jõustage säilitamispoliitika.
  • Avaldage analüüs ja eksport.

  See eraldamine muudab teenusepakkuja lisamise või eraldamiseta lihtsamaks, uue arve koostamiseta. haldamine.

  Tulemuste sisemine impotentsus

  Tulemuste allaneelamine on koht, kus paljud partiisüsteemid dubleerivad kogemata tasusid või kaotavad osalise töö. Käsitlege allaneelamist korratava protsessina. Sama väljundfaili kaks korda allalaadimine, sama pakkuja toimingu kaks korda töötlemine või sama veebihaagi sündmuse kaks korda esitamine peaks olema ohutu.

  Soovitus: kasutage üksusetaseme idempotentsusvõtmeid ja pearaamatu unikaalsuspiiranguid. Funktsiooni job_id + custom_id tulemus peaks lahenema täpselt üks kord, isegi kui allaneelamist proovitakse uuesti.

  Tõhus sisestusvoog:

  1. hankige töö või tulemuse artefakti jaoks lühiajaline lukk.
  2. Tooge pakkuja väljund ja veaartefaktid normaliseerituna.
  Parseda tulemused. sündmused.
  3. Sobitage iga kirje custom_id või lüüsi üksuse ID järgi.
  4. Kirjutage tulemuste metaandmed ja kasutus tehingus.
  5. Looge pearaamatu arveldussündmus ainult siis, kui seda veel ei ole.
  6. Uuendage tööde loendeid üksuse olekutest, mitte lähtudes, kui kõik on terminali reserveerimise eeldused. teada.

  Kui veebihaagid on saadaval, kontrollige allkirju ja kaitske taasesitamise eest. Kui küsimine on nõutav, kasutage adaptiivset küsitlust: küsitlege sageli eeldatava lõppemise lähedal, loobuge pikkade perioodide ajal ja lõpetage pärast terminali arveldamist.

  Proovige üksusi uuesti, mitte terveid töid.

  Soovitus: proovige võimaluse korral üksuse tasemel uuesti. Kogu töö korduskatsed on lihtsad, kuid suurendavad dubleeritud töö riski ja muudavad arveldamise raskemaks.

  Enne uuesti proovimist klassifitseerige ebaõnnestumised:

  • Kinnitusvead: tavaliselt lõpetatakse, kuni taotlus on parandatud.
  • Pakkuja 5xx vead:sageli proovitakse uuestitagamissagedusegaQitli:li backoff. proovige uuesti alles siis, kui maht on saadaval.
  • Ohutusplokid: ärge proovige pimesi uuesti; tee poliitika käsitlemiseni.
  • Aegunud üksused: võidakse uuesti proovida uues töökohas, kui üürnik soovib endiselt tööd ja eelarve seda lubab.

  Uue katse peaks looma uue üksuse, mis on lingitud originaaliga:

  {
    "item_id": "item_retry_002",
    "retry_of_item_id": "item_001",
    "custom_id": "rentantA.eval.row_901.retry_1"
  }

  Ärge esitage lõpetatud üksusi uuesti ainult seetõttu, et need olid osa tööst, mis lõppes kui completed_with_errors või aegunud.

  Otsustage, mida salvestada: töötlemata tulemused, osutid või räsid

  Pakisüsteemid on ahvatlevad kohad viipade ja väljundi kogumiseks. See võib olla kasulik ekspordiks ja silumiseks, kuid suurendab vastutust andmete säilitamise eest.

  Soovitus: muutke salvestuspoliitika rentniku jaoks konfigureeritavaks. Tundlike töökoormuste jaoks salvestage metaandmed, räsid, kasutus- ja tulemusnäitajad, mitte toorviibad ja -väljundid.Vähem tundlike töökoormuste puhul võib normaliseeritud tulemuste salvestamine olla vastuvõetav, kui säilitusaknad, juurdepääsu juhtelemendid ja kustutamise töövood on selged.

  Jälgige vähemalt järgmist:

  • kas töötlemata sisend on salvestatud.
  • kas toorväljund salvestati.
  • Kus pakkuja tulemuste artefaktid on reaalajas.Proviid.
  • Audititaotluse ja vastuse räsi ilma sisu eksponeerimiseta.

  Kinnitatud fakt: Antroopsete olekute partii tulemused on saadaval 29 päeva pärast loomist ja tööruumis isoleeritud. Selline pakkuja-spetsiifiline otsinguaken peaks kajastuma lüüsi metaandmetes ja rentnikele suunatud ekspordis.

  Avaldage analüüs, mis ühtib tiimide toimimisega

  Pakianalüüs peaks olemas olema nii töö kui ka üksuse tasemel. Tooteomanik soovib teada, kas igaöine rikastamine on lõppenud. Finantsadministraator soovib kulusid üürniku, mudeli ja kliendi järgi. Insener soovib teada, millist tõrkeklassi uuesti proovida.

  Kasulikud mõõdikud on järgmised:

  • esitatud, lõpetatud, ebaõnnestunud, aegunud ja tühistatud üksuste arv.
  • prognoositav versus arveldatud kulu.
  • Reserveeritud eelarve on endiselt alles.
  • Sisend ja väljund
  • sisend ja väljund) pakkujad avalikustavad need.
  • Uuesti proovide loendamine ja korduskatsete õnnestumise määr.
  • Keskmine aeg järjekorras, töötamise ja lõpetamise olekus.
  • Peamised valideerimisvead lõpp-punkti ja mudeli järgi.
  • Partnerkliendi omistamine.

  Partner API kasutajate jaoks kuvage klientide paketttööd. See võimaldab agentuuridel ja SaaS-i koostajatel pakkuda võrguühenduseta tehisintellekti töötlemist, säilitades samal ajal ülesvoolu pakkuja mandaadid, arvelduste vastavusse viimise ja tariifide piirangute haldamise lüüsis.

  Mööndused selgesõnaliseks muutmiseks

  Lüüsi abstraktsioon versus teenusepakkuja-spetsiifiline võimalus: ei saa muuta iga teenusepakkuja ühtseks integreerimiseks. Hoidke suutlikkuse vead selged.

  Eelarve reserveerimine versus prognoosi täpsus: reserveerimine kaitseb üürnikke jooksvate tööde eest, kuid prognoosid võivad olla valed. Pearaamat peab toetama kohandusi, tagasimakseid ja ülemäärast käsitlemist.

  Küsitlus versus veebihaagid: küsitlus on lihtne ja usaldusväärne, kuid võib raisata API-kutseid ja viivitada lõpetamist. Veebihaagid on kiiremad, kuid nõuavad allkirja kinnitamist, taasesituse kaitset ja jälgimist.

  Toortulemuste salvestamine versus säilitamise minimeerimine: normaliseeritud tulemuste salvestamine parandab eksporti ja analüüsi, kuid suurendab vastavuskoormust. Tundlikud üürnikud võivad eelistada viiteid ja räsi.

  Suured partiid versus tükeldatud partiid: suured partiid võivad parandada teenusepakkujapoolset tõhusust, kuid väiksemad tükid vähendavad plahvatusraadiust ja muudavad korduskatsetused lihtsamaks.

  Rakendamise kontroll-loend

  • Looge enne eraldi paketttöö pakkuja API-platvormi pind.
  esitamine.
  • Nõuge lüüsi töö ID-sid ja üksusepõhiseid kohandatud ID-sid.
  • Olekute normaliseerimine omapakkuja metaandmete salvestamise ajal.
  • Koostage iga pakkuja pakettadapteri jaoks võimete maatriks.
  • Kinnitage manifestid enne tegeliku eelarve broneerimist.
  • Reserveerige üürniku eelarve tasemel enne itemiliuse taset.
  • Reserveerige üürniku eelarve tase. allaneelamine.
  • Muutke tulemuste sisestamine idempotentseks.
  • Proovige ebaõnnestunud üksusi valikuliselt uuesti, mitte pimesi terveid töid.
  • Jälgige teenusepakkuja otsingutähtaegu ja lüüsi säilitamise poliitikat.
  • Avatage üürnikele ja üksuste analüüs üürnikele ja üksustele, kus see muster on .
  . rubriik

  Ennetus: pakettkäivitusest saab AI automatiseerimise infrastruktuuri tavaline osa, mitte ainult allahindlusmehhanism. Kuna meeskonnad viivad läbi rohkem hindamisi, andmete puhastamise ülesandeid, ohutusülevaateid ja rikastuskonveierid, eeldavad nad, et asünkroonsetel töökoormustel on samasugune juhtimine kui sünkroonsetel API-kõnedel.

  Prognoos: pakkujate pakett-API-d lahknevad jätkuvalt kasulikul viisil. Mõned optimeerivad failide jaoks, teised pikaajaliste toimingute jaoks ja teised hallatud andmekogumite või sündmuste tagasikutsumise jaoks. Lüüsiadapteri kiht muutub väärtuslikumaks, mitte vähem väärtuslikuks, kuna adapterite kohal olev tööleping võib jääda stabiilseks.

  Teetav järeldus

  Ärge ühendage paketttöötlust AI API lüüsiga teenusepakkujapõhise evakuatsiooniluugina. Looge see vastupidava alamsüsteemina, millel on oma töökirjed, üksuse identifikaatorid, olekumudel, pakkuja adapterid, eelarve reserveerimine, idempotentne sisestus ja analüüs.

  Kõige olulisem kujundusvalik on kaubataseme arvestus. Kui igal partiisisesel päringul on stabiilne identiteet, saab lüüs sobitada järjestamata tulemusi, proovida uuesti ainult ebaõnnestunud tööd, esitada arve ainult lõpetatud teenusepakkuja töö eest ja näidata üürnikele juhtunut.See on vahe teenusepakkujale failide saatmise ja asünkroonsete töökoormuste jaoks töökindla mitme mudeli API kasutamise vahel.

  Seotud lugemine

  • quote, reservconcile-14/"> muster
  • lüüsitaseme kasutusanalüütika ja lubade pearaamatu kujundus
  • kui latentsust taluvad töökoormused sobivad paketttöötlusega