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

Č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: dopustite jednom sloju da preuzme ponovne pokušaje generiranja modela. U tipičnoj arhitekturi, AI API pristupnik je pravi 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 pretvoriti namjeravanu operaciju od pet sekundi u odgovor od petnaest sekundi, prije nego što se uključe odustajanje i provjera valjanosti.

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

preostalo = rok - trenutno_vrijeme
potrebno = dopuštenje_za povezivanje + dopuštenje_generacije + dopuštenje_validacije
ako je preostalo < potrebno:
    stop_without_launching_other_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.

Koristite ograničeno eksponencijalno odlaganje s podrhtavanjem za prolazne ponovne pokušaje:

odgoda = nasumično(0, min(cap, base * 2^retry_index))

Savjeti pružatelja usluga za ponovni pokušaj, kao što je vrijednost za ponovni pokušaj, trebali bi 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 pokušaj, s neobaveznim ponovnim pokušajem iste rute samo za ranu grešku veze koja nije mogla generirati naplativi izlaz.

Kompromis: 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 mogućnosti 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.

kandidati = rute
  .filter(podržava_potrebne_modalitete)
  .filter(context_limit >= procijenjena_veličina_unosa)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class u dozvoljenim_model_classes)
  .filter(procijenjeni_trošak <= preostali_trošak_proračun)
  .filter(not_temporarily_suppressed)
odabrano = rang(kandidati, zdravlje, latencija, trošak)

Podrška za strukturirani izlaz zaslužuje eksplicitno testiranje. Čak i kada dvije rute oglašavaju generiranje ograničeno shemom, mogu podržavati različite podskupove JSON sheme ili drugačije 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: promjena 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 šire, politike usmjeravanja proizvodnje će sve više koristiti profile mogućnosti s verzijama i testove prihvaćanja specifične za radno opterećenje umjesto statičnih popisa modela. Tretirajte ovo kao smjernice za dizajn, a ne kao 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 dovrš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 računa, 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. Nagađ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. Održavajte stanje izvršenja alata prema determinističkom ključu, kao što je:

ključ_za_izvršenje = ID_operacije + naziv_alata + hash_kanonskih_argumenata

Prije nego što pokrenete alat, 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, zahtijevajte 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 zdravstvena supresija sprječava svaki novi zahtjev da ponovno otkrije isti neuspjeli 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 i model, klasu kvara, statusni kod, latenciju, broj tokena, procijenjeni trošak, rezervni razlog, rezultat provjere, stanje kruga i konačni ishod. Uredite ili raspršite 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 stopa uspješnosti HTTP-a uz rastuću stopu odbijanja valjanosti upozorenje je da dostupnost prijenosa 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 trajnih, prolaznih, nekompatibilnih, nevažećih odgovora i dvosmislenih.
• Odaberite jednog vlasnika ponovnog pokušaja i ograničite ukupan broj pokušaja.
• Propagirajte apsolutni rok putem pristupnika, klijenta pružatelja usluga, provjere valjanosti i izvršavanja alata.
• Izgradite zamjenske grupe testirane na 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.
• Zabilježite 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 rezervna stopa. 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 bilješka o testiranju API-ja
• prethodni članak na engleskom jeziku