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

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 pa jih izrecno vštejte v isti proračun za poskuse.

Porabite en proračun za zakasnitev od konca do konca

Časovne omejitve na poskus niso zadostne. 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:

preostalo = rok - trenutni_čas
zahtevano = dovoljenje za povezovanje + dovoljenje za generacijo + dovoljenje za validacijo
če ostane < zahtevano:
    stop_without_launching_another_attempt

Za osemsekundni rok bi razumna začetna dodelitev lahko rezervirala 300 ms za delo na prehodu in končno validacijo, omogočila do 4,5 sekunde za primarno pot in obdržala 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.

Uporabi omejeno eksponentno odmikanje 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 zakasnitev in brez stranskih učinkov, s preklicem in nadzorom stroškov.

Izberite nadomestne možnosti po zmogljivosti, ne po rangu

Nadomestna tabela mora kodirati združljivost in ne globalni prednostni vrstni red. Filtrirajte kandidatne poti glede na pogodbo, preden upoštevate stanje, zakasnitev ali ceno.

kandidati = poti
  .filter(podpira_potrebne_modalnosti)
  .filter(kontekstna_omejitev >= ocenjena_vhodna_velikost)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class v dovoljenih_model_classes)
  .filter(ocenjeni_strošek <= preostali_strošek_proračun)
  .filter(not_temporarily_suppressed)
izbrano = uvrstitev (kandidati, zdravje, zakasnitev, stroški)

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

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

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

Potrdite odgovor, preden ga sprejmete

Poženite vsak odgovor, vključno s primarnim odgovorom, skozi isti sprejemni cevovod. Preverjanje 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 celoten izpis.
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 lahko semantična preverjanja 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.

Ponovne poskuse generiranja ločite 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:

izvedbeni_ključ = ID_operacije + ime_orodja + kanonični_argumenti_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čna 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, rezultate in argumente orodij v skladu z njihovimi zahtevami glede občutljivosti in hrambe.

Uporabne operativne metrike vključujejo nadomestno stopnjo, število poskusov na dokončano zahtevo, stopnjo izčrpanosti rokov, stopnjo zavrnitve preverjanja, 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 prenosa prikriva neuspešne pogodbe.

Kontrolni seznam za uvedbo proizvodnje

• Definirajte verzionirano usmerjevalno pogodbo za vsak razred delovne obremenitve.
• Map provider errors into permanent, transient, incompatible, invalid-response, and ambiguous categories.
• Izberite enega lastnika za ponovni poskus 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.
• Preverite sheme, klice orodij, zaključne razloge in invariante domene.
• Odstranite podvojene stranske učinke s tipkami za upravljanje in izvajanje.
• Dodajte 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 potjo 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 opomba o testiranju API-ja
• prejšnji članek v angleškem jeziku