Zanesljivo usmerjanje API LLM: časovne omejitve, ponovni poskusi in nadomestni modeli brez semantične regresije

Nadomestna zahteva ni uspešna zgolj zato, ker je drug model vrnil HTTP 200. Zamenjava lahko preseže prvotni proračun zakasnitve, izpusti zahtevana polja JSON, pokliče drugo orodje ali ustvari odgovor z bistveno drugačno semantiko. Zanesljivo usmerjanje LLM API torej zahteva več kot le urejen seznam modelov: zahteva pogodbo, klasifikator napak, politiko omejenih poskusov in validacijo pred sprejemom.

Osrednje pravilo je preprosto: poskusite znova le, če je napaka verjetno začasna, in se vrnite šele, ko lahko naslednja pot še vedno zadosti prvotni pogodbi o zahtevi.

Določite pogodbo o usmerjanju, preden izberete modele

Začnite z opisom, kaj mora zagotoviti uspešen odgovor. Ta pogodba o usmerjanju mora biti strojno berljiva in priložena vsaki delovni obremenitvi ali razredu zahteve.

{
  "workload": "invoice_extraction",
  "modalities": ["text", "image"],
  "max_input_tokens": 50000,
  "requires_tools": false,
  "structured_output": {
    "required": true,
    "schema_id": "invoice-v3",
    "strict": true
  },
  "allowed_model_classes": ["document-extraction"],
  "max_cost_usd": 0.08,
  "deadline_ms": 8000
}

Pogodba mora zajemati zahtevane modalitete, zmogljivost konteksta, podporo orodij, vedenje strukturiranega izhoda, sprejemljive razrede modelov, najvišje stroške in rok od konca do konca. Po potrebi dodajte omejitve, specifične za aplikacijo, kot so dovoljene regije, najmanjša izhodna dolžina ali zahtevan razlog za zaključek.

Priporočilo: vzdržujte ločene, preizkušene skupine poti za golo besedilo, izpis, omejen s shemo, uporabo orodja, vizijo in zahteve z dolgim kontekstom. Model, ki je sprejemljiva nadomestna različica besedila, ni samodejno sprejemljiva nadomestna možnost za klic orodja ali vnos slike.

Razvrstite napako pred ukrepanjem

Napake pri preverjanju pristnosti, napačno oblikovane zahteve, omejitve hitrosti in napake strežnika zahtevajo različne odgovore. Obravnavanje vsakega neuspešnega odgovora kot ponovnega poskusa zapravlja zmogljivost in lahko prikrije napake.

Dejstvo: neuspešne zahteve z omejeno hitrostjo se lahko še vedno štejejo v omejitve ponudnika. Agresivni takojšnji ponovni poskusi lahko zato poglobijo dušenje, namesto da bi ga rešili. Ponovni poskusi prav tako porabijo dodatno zmogljivost med izpadom in pravilniki o ponovnih poskusih na več aplikacijskih ravneh lahko pomnožijo nastalo obremenitev.

Priporočilo: pustite, da ena plast lasti ponovne poskuse generiranja modela. V tipični arhitekturi je prehod AI API pravi lastnik, ker vidi stanje poti, zgodovino poskusov, zakasnitev in stroške. Onemogočite samodejne ponovne poskuse v odjemalcih na nižji ravni, kjer je to mogoče, ali jih izrecno vštejte v isti proračun za poskuse.

Porabite en proračun za zakasnitev od konca do konca

Časovne omejitve na poskus ne zadostujejo. Trije poskusi s petsekundno časovno omejitvijo lahko načrtovano petsekundno operacijo spremenijo v petnajstsekundni odgovor, preden sta vključena odlog in preverjanje.

Zabeležite absolutni rok, ko zahteva vstopi v prehod. Pred vsakim poskusom izračunajte preostali čas:

remaining = deadline - current_time
required  = connect_allowance + generation_allowance + validation_allowance

if remaining < required:
    stop_without_launching_another_attempt

Za osemsekundni rok lahko razumna začetna dodelitev rezervira 300 ms za delo na prehodu in končno validacijo, omogoči do 4,5 sekunde za primarno pot in obdrži približno 3,2 sekunde za eno rezervno pot. Te vrednosti so primer in ne merilo. Izpeljati jih je treba iz izmerjenih porazdelitev zakasnitev za dejanske ponudnike, modele, regije in izhodne velikosti.

Uporaba omejenega eksponentnega odmika s tresenjem za prehodne ponovne poskuse:

delay = random(0, min(cap, base * 2^retry_index))

Namigi ponudnika za ponovni poskus, kot je vrednost za ponovni poskus, bi morali imeti prednost, če ustrezajo preostalemu roku. Ustavite se po manjšem številu poskusov. Običajno pravilo je en primarni poskus plus en nadomestni poskus, z izbirnim ponovnim poskusom po isti poti samo za zgodnjo napako povezave, ki ni mogla ustvariti plačljivega izhoda.

Kompromis: zaporedna nadomestna rešitev izboljša razpoložljivost, vendar poveča zakasnitev repa. Vzporedne ali zaščitene zahteve lahko zmanjšajo zakasnitev med upočasnitvijo, vendar porabijo več zmogljivosti in lahko povzročijo stroške za več uspešnih generacij. Varovanje pred tveganjem mora biti omejeno na delovne obremenitve, ki so kritične do zakasnitve in brez stranskih učinkov, s preklicem in nadzorom stroškov.

Izberite nadomestne možnosti glede na zmogljivost, ne po rangu

Nadomestna tabela mora kodirati združljivost in ne globalnega prednostnega vrstnega reda. Filtrirajte kandidatne poti glede na pogodbo, preden upoštevate stanje, zakasnitev ali ceno.

candidates = routes
  .filter(supports_required_modalities)
  .filter(context_limit >= estimated_input_size)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class in allowed_model_classes)
  .filter(estimated_cost <= remaining_cost_budget)
  .filter(not_temporarily_suppressed)

selected = rank(candidates, health, latency, cost)

Podpora za strukturirane izhode si zasluži eksplicitno testiranje. Tudi če dve poti oglašujeta generiranje, omejeno s shemo, lahko podpirata različne podnabore JSON sheme ali drugače razlagata robne primere. Modeli, ki podpirajo orodja, se prav tako lahko razlikujejo po izbiri orodja, konstrukciji argumentov in vedenju vzporednega klica.

Dejstvo: zamenjava družine modelov lahko ohrani razpoložljivost prevoza, medtem ko spremeni slog, kakovost razmišljanja, varnostno vedenje, tokenizacijo in izbiro orodij. HTTP uspeh ni dokaz semantične enakovrednosti.

Predvidevanje: ko se katalogi modelov širijo, bodo politike usmerjanja proizvodnje vedno bolj uporabljale profile zmogljivosti z različicami in preizkuse sprejemljivosti, specifične za delovno obremenitev, namesto statičnih seznamov modelov. Obravnavajte to kot načrtovalsko usmeritev in ne kot jamstvo glede vedenja ponudnika.

Preverite odgovor, preden ga sprejmete

Poženite vsak odgovor, vključno s primarnim odgovorom, skozi isti sprejemni cevovod. Preverjanje veljavnosti mora potekati, preden se rezultat shrani v predpomnilnik, interno zaračuna kot uspešen ali posreduje izvajalcu orodja.

1. Potrdite, da je transport končan in da je mogoče razčleniti ovojnico odgovora.
2. Preverite razlog za dokončanje in zavrnite obrezovanje, ko je zahtevan popoln rezultat.
3. Preverite strukturirani izhod glede na izvirno shemo.
4. Preverite zahtevana polja, enum vrednosti in invariante aplikacije.
5. Dovoli le registrirana imena orodij in preveri argumente za vsako shemo orodja.
6. Uporabite semantična preverjanja, specifična za delovno obremenitev, kjer bi bil lažni sprejem drag.

Za ekstrakcijo računa semantična preverjanja morda zahtevajo nenegativno vsoto, podprto kodo valute in vsote vrstičnih postavk znotraj izrecno določene tolerance. Za razvrstitev zahtevajte oznako iz dovoljenega sklopa. Za ustvarjanje kode je lahko primerno razčlenjevanje ali prevajanje. Ta preverjanja ne dokazujejo kakovosti, vendar preprečujejo, da bi se predvidljive kršitve pogodbe obravnavale kot uspehi.

Ne popravite tiho vsakega napačno oblikovanega odgovora. Deterministična normalizacija, kot je odstranjevanje neškodljivega okoliškega praznega prostora, je lahko sprejemljiva. Ugibanje manjkajočih finančnih polj ali prepisovanje argumentov orodja spremeni pomen modela in bi moralo sprožiti zavrnitev ali človeški pregled.

Ločite poskuse generiranja od stranskih učinkov

Zahteve LLM običajno uporabljajo HTTP POST, ki ni sam po sebi idempotenten. Še pomembneje je, da lahko odziv modela sproži zunanje dejanje, kot je zaračunavanje plačilnega sredstva, pošiljanje sporočila, ustvarjanje vstopnice ali spreminjanje infrastrukture. Ponovni poskus ustvarjanja in ponovno predvajanje tega dejanja sta ločeni odločitvi.

Dodelite ID operacije na meji aplikacije in ID poskusa vsakemu klicu modela. Ohranite stanje izvajanja orodja glede na deterministični ključ, kot je:

execution_key = operation_id + tool_name + canonical_arguments_hash

Preden zaženete orodje, preverite, ali je ključ na čakanju, dokončan ali neuspešen. Vrnite shranjeni rezultat za dokončano izvedbo, namesto da bi ga ponovno zagnali. Za operacije, katerih argumenti se lahko zakonito spremenijo, zahtevajte odobritev na ravni aplikacije ali nov ID operacije.

Dvoumna časovna omejitev zahteva posebno obravnavo. Če povezava po prenosu zahteve ne uspe, prehod morda ne ve, ali je prišlo do generiranja. Ključ za idempotenco, ki ga podpira ponudnik, lahko pomaga, če je na voljo. V nasprotnem primeru zabeležite rezultat kot neznan in uporabite pravilnik o ponavljanju, ki je specifičen za delovno obremenitev, namesto da predvidevate, da se ni nič zgodilo.

Zatirajte nezdrave poti in razkrijte vsak poskus

Prekinjevalec tokokroga ali začasna izključitev zdravja preprečuje, da bi vsaka nova zahteva ponovno odkrila isto neuspešno pot. Odprite vezje po določeni stopnji napake ali pragu zaporednih okvar, nato dopustite omejene sonde v napol odprtem stanju. Prilagodite pragove glede na pot in razred napake, tako da napačno oblikovana zahteva odjemalca ne more povzročiti, da bi bil zdrav model videti nedosegljiv.

Zabeležite en dogodek na ravni zahteve in en dogodek na poskus. Uporabna polja vključujejo ID operacije, ID poskusa, izbranega ponudnika in model, razred napake, statusno kodo, zakasnitev, število žetonov, ocenjeno ceno, nadomestni razlog, rezultat preverjanja, stanje vezja in končni rezultat. Uredite ali zgostite pozive, izhode in argumente orodja v skladu z njihovimi zahtevami glede občutljivosti in hrambe.

Uporabne operativne metrike vključujejo nadomestno stopnjo, poskuse na dokončano zahtevo, stopnjo izčrpanosti rokov, stopnjo zavrnitve potrjevanja, dvoumne rezultate, ceno na sprejet odgovor in zakasnitev glede na končno pot. Naraščajoča stopnja uspešnosti HTTP skupaj z naraščajočo stopnjo zavrnitve validacije je opozorilo, da razpoložljivost prevoza prikriva neuspešne pogodbe.

Kontrolni seznam za uvedbo proizvodnje

• Definirajte pogodbo o usmerjanju z različicami za vsak razred delovne obremenitve.
• Preslikaj napake ponudnika v trajne, prehodne, nezdružljive, neveljavne odzive in dvoumne kategorije.
• Izberite enega lastnika ponovnega poskusa in omejite skupno število poskusov.
• Razširite absolutni rok prek prehoda, odjemalca ponudnika, preverjanja veljavnosti in izvajanja orodja.
• Izdelajte nadomestne skupine, preizkušene z zmogljivostmi, namesto ene globalne verige modelov.
• Preverjanje shem, klicev orodij, zaključnih razlogov in invariant domene.
• Odstranite podvojene stranske učinke z operacijskimi in izvršilnimi tipkami.
• Dodaj zatiranje poti z omejenimi napol odprtimi sondami.
• Zakasnitev na ravni poskusov, žetoni, stroški, napake in rezultati sprejema.
• Časovne omejitve vbrizgavanja, 429s, izbrane napake 5xx, napačno oblikovan JSON, prelivanje konteksta in počasni uspehi pri uprizarjanju.

Začnite s primarno potjo in eno združljivo nadomestno za eno samo obremenitev z nizkim tveganjem. Primerjajte kakovost sprejetih odgovorov, zakasnitev in stroške, preden razširite pravilnik. Cilj ni najvišja možna rezervna stopnja. To je omejen sistem, ki bodisi vrne odgovor, ki ustreza prvotni pogodbi, bodisi jasno odpove, preden povzroči podvojeno delo ali semantično škodo.

Sorodno branje

• prejšnja API opomba o testiranju
• prejšnja angleška različica člen