Pouzdano LLM API usmjeravanje: istek vremena, ponovni pokušaji i zamjenski modeli bez semantičke regresije

Zamjenski zahtjev nije uspješan samo zato što je drugi model vratio HTTP 200. Zamjena može premašiti izvorni proračun kašnjenja, izostaviti obavezna JSON polja, pozvati drugi alat ili proizvesti odgovor s materijalno drugačijom semantikom. Pouzdano LLM API usmjeravanje stoga zahtijeva više od uređenog popisa modela: ono zahtijeva ugovor, klasifikator neuspjeha, politiku ograničenog pokušaja i provjeru valjanosti prije prihvaćanja.

Središnje pravilo je jednostavno: pokušajte ponovno samo kada je neuspjeh vjerojatno privremen, i vratite se samo kada sljedeća ruta još uvijek može zadovoljiti izvorni ugovor zahtjeva.

Definirajte ugovor o usmjeravanju prije odabira modela

Počnite opisivanjem onoga što mora pružiti uspješan odgovor. Ovaj ugovor o usmjeravanju trebao bi biti strojno čitljiv i priložen svakom radnom opterećenju ili klasi zahtjeva.

{
  "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
}

Ugovor bi trebao pokrivati tražene modalitete, kapacitet konteksta, podršku alata, ponašanje strukturiranog izlaza, prihvatljive klase modela, maksimalnu cijenu i krajnji rok. Dodajte ograničenja specifična za aplikaciju gdje je to potrebno, kao što su dopuštena područja, minimalna izlazna duljina ili potreban razlog završetka.

Preporuka: održavajte odvojene, testirane grupe ruta za običan tekst, izlaz ograničen shemom, upotrebu alata, viziju i zahtjeve dugog konteksta. Model koji je prihvatljiva zamjena teksta nije automatski prihvatljiva zamjena za pozivanje alata ili unos slike.

Klasificirajte neuspjeh prije poduzimanja radnje

Pogreške pri autentifikaciji, neispravni zahtjevi, ograničenja brzine i kvarovi poslužitelja zahtijevaju različite odgovore. Tretiranje svakog neuspješnog odgovora kao odgovora koji se može ponovno pokušati troši kapacitet i može sakriti nedostatke.

Činjenica: neuspješni zahtjevi s ograničenjem brzine i dalje se mogu uračunati u ograničenja pružatelja usluga. Agresivni trenutni ponovni pokušaji stoga mogu produbiti prigušivanje umjesto da ga riješe. Ponovni pokušaji također troše dodatni kapacitet tijekom prekida rada, a pravila ponovnih pokušaja na nekoliko aplikacijskih slojeva mogu višestruko povećati rezultirajuće opterećenje.

Preporuka: neka jedan sloj posjeduje ponovne pokušaje generiranja modela. U tipičnoj arhitekturi, pristupnik AI API pravi je vlasnik jer vidi stanje rute, povijest pokušaja, latenciju i trošak. Onemogućite automatske ponovne pokušaje u klijentima niže razine gdje je to moguće ili ih izričito uračunajte u isti proračun za pokušaje.

Potrošite jedan proračun latencije s kraja na kraj

Istek vremena po pokušaju nije dovoljan. Tri pokušaja s vremenskim ograničenjem od pet sekundi mogu planiranu operaciju od pet sekundi pretvoriti u odgovor od petnaest sekundi, prije nego što se uključi odustanak i provjera valjanosti.

Zabilježite apsolutni rok kada zahtjev uđe u pristupnik. Prije svakog pokušaja izračunajte preostalo vrijeme:

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

if remaining < required:
    stop_without_launching_another_attempt

Za rok od osam sekundi, razumna početna dodjela može rezervirati 300 ms za rad pristupnika i konačnu provjeru valjanosti, dopustiti do 4,5 sekunde za primarnu rutu i zadržati približno 3,2 sekunde za jednu zamjenu. Ove vrijednosti su primjer, a ne mjerilo. Moraju se izvesti iz izmjerene distribucije latencije za stvarne pružatelje usluga, modele, regije i izlazne veličine.

Upotreba ograničenog eksponencijalnog odstupanja s podrhtavanjem za prolazne ponovne pokušaje:

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

Savjeti pružatelja usluga za ponovni pokušaj, kao što je vrijednost za ponovni pokušaj, trebaju imati prednost kada se uklope u preostali rok. Zaustavite nakon malog broja pokušaja. Uobičajeno pravilo je jedan primarni pokušaj plus jedan zamjenski, s neobaveznim ponovnim pokušajem iste rute samo za ranu grešku veze koja nije mogla generirati naplativi izlaz.

Razvoj: sekvencijalna zamjena poboljšava dostupnost, ali povećava latenciju repa. Paralelni ili zaštićeni zahtjevi mogu smanjiti kašnjenje tijekom usporavanja, ali troše više kapaciteta i mogu izazvati troškove za više uspješnih generacija. Zaštita bi trebala biti ograničena na radna opterećenja kritična za kašnjenje, bez nuspojava s otkazivanjem i kontrolom troškova.

Odaberite zamjenske opcije prema mogućnostima, a ne prema rangu

Zamjenska tablica trebala bi kodirati kompatibilnost, a ne globalni redoslijed preferencija. Filtrirajte rute kandidata prema ugovoru prije razmatranja stanja, kašnjenja ili cijene.

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)

Podrška za strukturirani izlaz zaslužuje eksplicitno testiranje. Čak i kada dvije rute oglašavaju generiranje ograničeno shemom, mogu podržati različite JSON podskupove sheme ili različito tumačiti rubne slučajeve. Modeli s mogućnostima alata također se mogu razlikovati u odabiru alata, konstrukciji argumenata i ponašanju paralelnog poziva.

Činjenica: zamjena obitelji modela može sačuvati dostupnost prijevoza uz promjenu stila, kvalitete razmišljanja, sigurnosnog ponašanja, tokenizacije i odabira alata. HTTP uspjeh nije dokaz semantičke jednakosti.

Predviđanje: kako se katalozi modela budu širili, politike usmjeravanja proizvodnje će sve više koristiti profile sposobnosti s verzijama i testove prihvaćanja specifične za radno opterećenje umjesto statičnih popisa modela. Tretirajte ovo kao smjernicu za dizajn, a ne jamstvo o ponašanju pružatelja usluga.

Potvrdite odgovor prije prihvaćanja

Provedite svaki odgovor, uključujući primarni odgovor, kroz isti cjevovod prihvaćanja. Validacija bi se trebala dogoditi prije nego što se rezultat pohrani u predmemoriju, interno naplati kao uspješan ili proslijedi izvršitelju alata.

1. Potvrdite da je transport završen i da se omotnica odgovora može analizirati.
2. Provjerite razlog završetka i odbijte skraćivanje kada je potreban potpuni izlaz.
3. Provjerite strukturirani izlaz u odnosu na izvornu shemu.
4. Provjerite obavezna polja, enum vrijednosti i invarijante aplikacije.
5. Dopusti samo registrirane nazive alata i potvrdi argumente protiv svake sheme alata.
6. Primijenite semantičke provjere specifične za radno opterećenje gdje bi lažno prihvaćanje bilo skupo.

Za izdvajanje faktura, semantičke provjere mogu zahtijevati nenegativan ukupni iznos, podržanu šifru valute i ukupne iznose stavki unutar eksplicitno definirane tolerancije. Za razvrstavanje zahtijevati oznaku iz dopuštenog skupa. Za generiranje koda, raščlanjivanje ili kompilacija može biti prikladno. Ove provjere ne dokazuju kvalitetu, ali sprječavaju da se predvidljiva kršenja ugovora tretiraju kao uspjesi.

Nemojte tiho popravljati svaki neispravan odgovor. Deterministička normalizacija, kao što je uklanjanje bezopasnih okolnih bjelina, može biti prihvatljiva. Pogađanje nedostajućih financijskih polja ili ponovno pisanje argumenata alata mijenja značenje modela i trebalo bi pokrenuti odbijanje ili ljudski pregled.

Odvojite ponovne pokušaje generiranja od nuspojava

LLM zahtjevi obično koriste HTTP POST, koji nije inherentno idempotentan. Što je još važnije, odgovor modela može pokrenuti vanjsku akciju kao što je naplata načina plaćanja, slanje poruke, stvaranje karte ili izmjena infrastrukture. Ponovni pokušaj generiranja i ponavljanje te radnje odvojene su odluke.

Dodijelite ID operacije na granici aplikacije i ID pokušaja svakom pozivu modela. Zadrži stanje izvršenja alata prema determinističkom ključu, kao što je:

execution_key = operation_id + tool_name + canonical_arguments_hash

Prije pokretanja alata, provjerite je li taj ključ na čekanju, dovršen ili nije uspio. Vrati pohranjeni rezultat za dovršeno izvođenje umjesto ponovnog pokretanja. Za operacije čiji se argumenti mogu legitimno promijeniti, potrebno je odobrenje na razini aplikacije ili novi ID operacije.

Dvosmisleno vremensko ograničenje zahtijeva posebno rukovanje. Ako veza ne uspije nakon što je zahtjev poslan, pristupnik možda neće znati je li došlo do generiranja. Ključ idempotencije koji podržava pružatelj usluga može pomoći kada je dostupan. U suprotnom, zabilježite ishod kao nepoznat i primijenite pravila ponavljanja specifična za radno opterećenje umjesto da pretpostavite da se ništa nije dogodilo.

Suzbiti nezdrave rute i razotkriti svaki pokušaj

Prekidač strujnog kruga ili privremena obustava ispravnosti sprječava svaki novi zahtjev da ponovno otkrije isti neispravni put. Otvorite strujni krug nakon definirane stope pogreške ili praga uzastopnih kvarova, zatim pustite ograničene sonde u poluotvorenom stanju. Podesite pragove prema ruti i klasi kvara tako da neispravan zahtjev klijenta ne može učiniti da zdravi model izgleda nedostupan.

Zabilježite jedan događaj na razini zahtjeva i jedan događaj po pokušaju. Korisna polja uključuju ID operacije, ID pokušaja, odabranog pružatelja usluga i model, klasu kvara, statusni kod, latenciju, broj tokena, procijenjeni trošak, rezervni razlog, rezultat provjere, stanje kruga i konačni ishod. Uredite ili hashirajte upite, izlaze i argumente alata u skladu s njihovim zahtjevima za osjetljivost i zadržavanje.

Korisne operativne metrike uključuju povratnu stopu, pokušaje po dovršenom zahtjevu, stopu iscrpljenosti roka, stopu odbijanja provjere valjanosti, dvosmislene ishode, cijenu po prihvaćenom odgovoru i kašnjenje po konačnoj ruti. Rastuća HTTP stopa uspjeha uz rastuću stopu odbijanja valjanosti upozorenje je da dostupnost prijevoza prikriva neuspjehe ugovora.

Kontrolni popis za uvođenje proizvodnje

• Definirajte verzionirani ugovor o usmjeravanju za svaku klasu radnog opterećenja.
• Mapira pogreške pružatelja usluga u kategorije trajne, prolazne, nekompatibilne, nevažećih odgovora i dvosmislene kategorije.
• Odaberite jednog vlasnika ponovnog pokušaja i ograničite ukupan broj pokušaja.
• Proširite apsolutni rok putem pristupnika, klijenta pružatelja usluga, provjere valjanosti i izvršavanja alata.
• Izradite zamjenske grupe provjerene sposobnosti umjesto jednog globalnog lanca modela.
• Provjerite sheme, pozive alata, razloge završetka i invarijante domene.
• Deduplicirajte nuspojave pomoću tipki za rad i izvršavanje.
• Dodajte potiskivanje rute s ograničenim poluotvorenim sondama.
• Biljite kašnjenje na razini pokušaja, tokene, troškove, neuspjehe i rezultate prihvaćanja.
• Istek vremena ubrizgavanja, 429s, odabrane 5xx pogreške, neispravan JSON, prekoračenje konteksta i spori uspjesi u postavljanju.

Započnite s primarnom rutom i jednom kompatibilnom rezervnom za jedno radno opterećenje niskog rizika. Usporedite kvalitetu prihvaćenog odgovora, latenciju i cijenu prije proširenja pravila. Cilj nije najveća moguća stopa povrata. To je ograničeni sustav koji ili vraća odgovor koji zadovoljava izvorni ugovor ili jasno pada prije nego što uzrokuje dupli rad ili semantičku štetu.

Povezano čitanje

• ranija API bilješka o testiranju
• prethodna na engleskom jeziku članak