Kako oblikovati nadomestne možnosti LLM brez prekinitve pogodbe o zakasnitvi, stroških ali izhodih

Nadomestni model ni le rezervni seznam modelov. Za inženirske ekipe, ki uporabljajo več ponudnikov LLM, je nadomestna politika usmerjanja, ki odloča, kdaj se lahko zahteva premakne od enega ponudnika ali modela k drugemu, kaj mora ostati nespremenjeno in kako sistem dokazuje, da je alternativna pot naredila aplikacijo bolj zanesljivo.

Težava z bralnikom je običajno preprosta: zmanjšajte število neuspešnih zahtev in zmanjšajte zakasnitev repa, ne da bi tiho spremenili kakovost izpisa, veljavnost sheme, varnostno obnašanje ali stroške. Rešitev je bolj specifična kot "poskusite drugega ponudnika". Zanesljiva nadomestna strategija LLM zahteva razvrstitev napak, roke za zahteve, pravila združljivosti modela, omejitve stroškov, odklopnike in opazljivost na ravni ponudnika in poti.

Začnite s pravilnikom o nadomestni uporabi, ne s ponovno kodo

Ponovni poskusi in nadomestna rešitev rešujejo različne težave. Ponovni poskus od istega ponudnika zahteva, da dokonča isto zahtevo po prehodni napaki. Nadomestna možnost zahteva drug model, ponudnika, regijo ali pot, da namesto tega dokonča delo. Mešanje teh pomislekov ustvarja sisteme, o katerih je med incidenti težko sklepati.

Dejstvo: Smernice za zanesljivost ponudnikov infrastrukture v oblaku običajno priporočajo omejeno eksponentno odmikanje, tresenje, največje omejitve ponovnih poskusov, preverjanja idempotence in izogibanje ponovnim poskusom na več ravneh, ker lahko nevihte pri ponovnih poskusih poslabšajo preobremenitev. Večji ponudniki LLM dokumentirajo tudi prehodne napake, omejitve hitrosti, odzive na preobremenitev, časovne omejitve in SDK vedenje pri ponovnem poskusu.

Priporočilo: implementirajte eno plast ponovnega poskusa za vsako pot zahteve. Če prehod aplikacije poskusi znova, storitve na nižji stopnji prav tako ne bi smele poskusiti znova neodvisno, razen če je lastništvo poskusa izrecno. Vsak ponovni poskus bi moral porabiti isti rok klicatelja, ne pa ustvariti nove odprte časovne omejitve.

Minimalni pravilnik bi moral odgovoriti na ta vprašanja, preden se napiše kakršna koli koda:

• Katere napake je mogoče znova poskusiti pri istem ponudniku?
• Katere napake omogočajo nadomestno uporabo k drugemu ponudniku oz. model?
• Katere napake ne smejo nikoli sprožiti nadomestne možnosti?
• Katera izhodna pogodba mora ostati enaka?
• Kakšno je največje dovoljeno zvišanje stroškov?
• Kolikšen del roka za zahtevo se lahko porabi, preden je nadomestna možnost onemogočena?
• Katera telemetrija dokazuje, ali je nadomestna pomoč pomagala oz. skril napako?

Razvrsti napake pred usmerjanjem okoli njih

Nadomestna rešitev je nevarna, če se vsak odgovor non-200 obravnava enako. Časovna omejitev ponudnika ni isto kot napačno oblikovana zahteva. Omejitev stopnje ni isto kot varnostna zavrnitev.Napaka preverjanja izhoda ni enaka napaki omrežja.

Praktična taksonomija bi morala vključevati vsaj te razrede:

• Ponovna napaka pri transportu: ponastavitev povezave, težava DNS, začasna okvara omrežja ali časovna omejitev prehoda.
• Preobremenitev ponudnika: dokumentirana preobremenitev ali prehod na strani strežnika napaka.
• Omejitev hitrosti: omejitev zahteve, žetona, pospeška ali kvote, še posebej, če je podana vrednost Poskusi znova.
• Časovna omejitev ponudnika: ponudnik je sprejel zahtevo, vendar je ni dokončal v svojem servisnem oknu.
• Neveljavno zahteva: napačno oblikovana koristna vsebina, nepodprt parameter, neveljavna shema ali možnost, nezdružljiva z modelom.
• Napaka pri preverjanju pristnosti ali konfiguraciji: napačen ključ, onemogočen račun, manjkajoče upravičenje ali izčrpana kvota na ravni računa.
• Varnostna zavrnitev ali blokada: ponudnik namenoma zavrne ali blokira vsebino na podlagi varnostnega pravilnika.
• Napaka pri preverjanju izhoda: model se je odzval, vendar odgovor ne izpolnjuje pogodbe o aplikaciji.

Priporočilo: poskusite znova samo ob prehodnih napakah znotraj klicateljevega proračuna zakasnitve. Dovoli nadomestno samo za razrede napak, ki so jih skupine izdelka in platforme izrecno odobrile. Ne zanašajte se na napake pri preverjanju pristnosti, napačno oblikovane zahteve, napake deterministične sheme ali varnostne zavrnitve, razen če izdelek definira specifično alternativno varno vedenje.

Ta razlika je pomembna, ker lahko nadomestna različica sicer skrije hrošče. Če je shema za primarnega ponudnika neveljavna in jo nadomestni ponudnik prezre, je lahko sistem videti bolj zdrav, medtem ko vrača manj omejen izhod. To ni zanesljivost; to je zamik pogodbe.

Uporabite roke, ne le časovne omejitve

Težave z zakasnitvijo repa pogosto izvirajo iz ponovnih poskusov, ki so tehnično omejeni, a praktično prepočasni. Zahteva s 15-sekundnim proračunom, namenjenim uporabniku, ne bi smela porabiti 14 sekund za neuspeh na primarni poti in nato začeti polnega nadomestnega poskusa, ki se ne more dokončati pravočasno.

Uporabite rok za zahtevo, ki se prenese skozi celoten sklad. Vsaka odločitev o usmerjanju mora preveriti preostali čas, preden poskusi znova ali se vrne. Na primer:

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Natančne številke so odvisne od delovne obremenitve. Pot zaključka klepeta lahko rezervira dovolj časa za en nadomestni model. Opravilo ekstrakcije v ozadju lahko dopušča več poskusov. Pot samodokončanja v realnem času bo morda dala prednost hitri napaki kot poznemu nadomestnemu odgovoru.

Priporočilo: določite proračune zakasnitev glede na razred poti, ne globalno. Pot uporabniškega vmesnika z nizko zakasnitvijo, pot paketne klasifikacije in pot analize dolgega konteksta ne bi smele imeti iste ovojnice za ponovne poskuse in nadomestne možnosti.

Definiraj razrede modela glede na delovno obremenitev

Imena prodajalcev so slaba abstrakcija za nadomestne možnosti. Aplikacija skrbi za lastnosti delovne obremenitve: dolžino konteksta, globino razmišljanja, podporo orodja, obnašanje strukturiranega izhoda, zakasnitev, omejitve pri ravnanju s podatki in stroške.Nadomestne poti bi morale biti organizirane okoli teh lastnosti.

Uporabni razredi modelov vključujejo:

• Hiter osnutek: kratki odzivi, nizka zakasnitev, zmerna toleranca kakovosti.
• Strukturirano pridobivanje: strogi JSON izhod, preverjanje sheme, nizka toleranca za format drift.
• Razlog: večstopenjska analiza, višje zahteve glede kakovosti, višja sprejemljiva zakasnitev.
• Dolg kontekst: veliki dokumenti, okna z velikim številom žetonov, skrbna pravila za prirezovanje.
• Nizkocenovni paket: asinhrona ali nenujna opravila, optimizirana za ekonomičnost enote.
• Premium eskalacija: dragi, vendar zmogljivi modeli, ki se uporabljajo samo, kadar pravilnik to dovoljuje.

Za vsak razred navedite dovoljene primarne modele, dovoljene rezervne modele in prepovedane poti za znižanje. Zahteva z dolgim ​​kontekstom se ne sme vrniti k modelu s kratkim kontekstom, ki tiho skrajša poziv. Naloga strukturiranega pridobivanja se ne sme vrniti k modelu, ki ne more zadostiti omejitvam sheme. Naloga premijskega razmišljanja lahko dovoli vrnitev na drug premijski model, ne pa v model hitrega osnutka, razen če uporabniška izkušnja izrecno podpira poslabšan odgovor.

Za ekipe, ki gradijo podjetniški LLM API, bi morali ti razredi živeti v podatkih o konfiguraciji ali pravilniku in ne razpršeni po aplikacijskih storitvah. To ohranja vedenje usmerjanja revizijsko in ga je lažje spremeniti med incidenti ponudnika.

Zaščitite pogodbe strukturiranih izhodov

Nadomestni strukturirani izhod je eno izmed najlažjih mest za ustvarjanje subtilnih produkcijskih napak. Ponudniki se razlikujejo glede na to, kako podpirajo način JSON, JSON shemo, klice orodij, zavrnitvena polja, varnostne povratne informacije, razloge za dokončanje in podnabore shem. Ni zajamčeno, da bo shema, ki deluje z enim modelom, prenosljiva na drugega.

Dejstvo: Nekatera dokumentacija ponudnika opisuje strogo upoštevanje sheme za podprte modele, medtem ko druga dokumentacija omenja podporo samo za podnabor JSON sheme. Odgovori ponudnika lahko vključujejo tudi zavrnitvena polja, takojšnje povratne informacije, ocene varnosti, razloge za dokončanje ali brez kandidatov, ko je poziv blokiran ali neveljaven.

Priporočilo: veljavnost izhoda obravnavajte kot del poti in ne kot neobvezno skrb klicatelja. Prehod mora potrditi končni odgovor, preden ga vrne aplikaciji. Če preverjanje ne uspe, mora pot razvrstiti napako in odločiti, ali je dovoljen nadomestni poskus.

Obstajata dva uporabna vzorca:

Uporabite prenosni podnabor shem

Ohranite sheme na presečišču funkcij, ki jih podpirajo odobreni nadomestni ponudniki. To izboljša prenosljivost in zmanjša kompleksnost delovanja. Kompromis je v tem, da lahko izgubite bogatejše omejitve, specifične za ponudnika.

Uporabite adapterje sheme, specifične za ponudnika

Vzdržujte adapterje, ki prevedejo pogodbo aplikacije v podprto obliko sheme vsakega ponudnika. To ohranja zmogljivost, vendar povečuje breme testiranja in vzdrževanja.Zahteva tudi matriko združljivosti, da inženirji vedo, katere poti se lahko varno vrnejo nazaj.

Osnovni zapis združljivosti je lahko videti takole:

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Priporočilo: nikoli ne vrni nadomestnega izhoda samo zato, ker je dobro oblikovano besedilo. Vrnite ga šele, ko izpolnjuje isto pogodbo na ravni aplikacije, ki se pričakuje od primarne poti.

Nadzirajte stroške, preden pride do incidentov

Nadomestni način pogosto preusmeri promet na dražje modele točno v trenutku, ko je promet povečan ali je ponudnik slabši. Brez nadzora stroškov lahko mehanizem zanesljivosti postane incident s porabo.

Nastavite nadomestna pravila, ki vključujejo:

• Največji množitelj nadomestne cene na pot.
• Dovoljene stopnje modela po organizaciji, delovnem prostoru ali okolju.
• Dnevna ali urna nadomestna poraba proračuni.
• Ločen pravilnik za interaktivne in paketne delovne obremenitve.
• Pravila o tem, ali lahko nadomestni način prestopa meje ponudnika, regije ali družine modelov.

Priporočilo: izmerite ceno na uspešen odgovor, ne le stroške neobdelane zahteve. Dražja nadomestna rešitev je lahko upravičena, če prepreči uporabniku vidno napako na kritični poti. Ista nadomestna rešitev je morda nesprejemljiva za paketno delo z nizko prioriteto.

Stroškovna politika mora biti vidna tudi organizacijam, ki uporabljajo platformo. Ekipe bodo morda želele dovoliti vrhunsko nadomestno različico za delovne tokove podpore strankam v proizvodnji, medtem ko jo bodo blokirale za razvoj, testiranje ali interno eksperimentiranje. To je odločitev o upravljanju, ne le odločitev o usmerjanju.

Dodajte odklopnike na ponudnika, model, regijo in razred napake

Naivna nadomestna rešitev lahko škodi slabšemu ponudniku. Vsaka neuspešna primarna zahteva sproži nov primarni poskus, nato še en nadomestni poskus, medtem ko druge storitve storijo enako. Odklopniki zmanjšajo ponavljajoče se pritiske in naredijo usmerjanje bolj predvidljivo.

Odklopnik mora biti dovolj specifičen, da prepreči pretiravanje. Ne označite celotnega ponudnika kot nezdravega, ker en model v eni regiji vrača strukturirane izhodne napake. Sledite zdravju glede na ponudnika, model, regijo, pot in razred napake, kjer je to mogoče.

Preprost avtomat stanja odklopnika je dovolj za številne ekipe:

• Zaprto: običajni promet poteka na poti.
• Odprto: pot se po napaki začasno izogne pragovi so preseženi.
• Napol odprto: omejen promet sonde testira obnovitev, preden se polni promet nadaljuje.

Pragovi morajo upoštevati količino. Deset napak v minuti je lahko smiselnih za pot z nizko količino, vendar nepomembnih za pot, ki obravnava na tisoče zahtevkov na minuto. Uporabite najmanjše velikosti vzorcev, vrtljiva okna in filtre za razrede napak.

Priporočilo: odklopniki ne smejo šteti samo HTTP napak. Prav tako morajo ločeno spremljati napake pri preverjanju izhoda, stopnje časovne omejitve, stopnje omejitve hitrosti in vzorce zavrnitve ali blokiranja. Ti razredi pomenijo različne operativne odzive.

Zabeležite odločitev o usmerjanju, ne samo končne napake

Nadomestna rešitev, ki izboljša uporabniško izkušnjo, lahko še vedno oteži diagnosticiranje incidentov.Če dnevniki prikazujejo le končnega uspešnega ponudnika, inženirji izgubijo dokaz, da je bil primarni ponudnik neuspešen.

Vsaka zahteva mora beležiti:

• Izvirni ponudnik, model in pot.
• Nadomestni ponudnik, model in pot, ko je bil uporabljen.
• Razred napake, ki je sprožil ponovni poskus ali nadomestni.
• ID-ji zahtev ponudnika, ko so na voljo.
• Število ponovnih poskusov in trajanje odloga.
• Porabljen rok pred vsakim poskusom.
• Rezultat preverjanja izhoda.
• Ocenjeni stroški za vsak poskus in končni stroški.
• Ali je prišel končni odgovor od primarnega ali nadomestnega.
• Metapodatki o organizaciji, delovnem prostoru, okolju in aplikaciji, kjer pravilnik to dovoljuje.

Ta telemetrija podpira inženirsko in komercialno upravljanje. Povezuje tudi nadomestno vedenje z AI API nadzorom stroškov, ko imajo različne ekipe, izdelki ali stranke različne politike glede zanesljivosti in proračuna.

Izmerite, ali je nadomestni način dejansko pomagal

Neobdelana stopnja uspešnosti ni dovolj. Nadomestna strategija lahko poveča končnih 200 odzivov, hkrati pa poslabša zakasnitev p99, podvoji stroške ali vrne manj veljaven strukturiran izhod.

Izmerite vsaj te meritve po poti:

• Primarna stopnja uspešnosti.
• Končna stopnja uspešnosti po ponovnem poskusu in rezervi.
• p50, zakasnitev p95 in p99 pred in po nadomestni stopnji.
• Stopnja nadomestnih klicev.
• Cena na uspešen odziv.
• Stopnja veljavnosti pogodbe.
• Stopnja varnostnih zavrnitev ali blokad s strani ponudnika.
• Signali regresije kakovosti iz specifičnih aplikacij ocena.

Napoved: ko bo vse več podjetij uporabljalo infrastrukturo LLM z več ponudniki, bodo nadomestne politike postale bolj podobne prometnemu inženiringu in manj podobne obravnavi ad hoc izjem.Ekipe bodo pričakovale nadzor pravilnika glede na delovni prostor, okolje in razred delovne obremenitve, z revizijskimi dnevniki, ki pojasnjujejo, zakaj je bil izbran model.

Kontrolni seznam za implementacijo

Uporabite ta kontrolni seznam, preden omogočite nadomestno možnost na produkcijski poti:

• Določite proračun zakasnitve poti in rok za zahtevo.
• Razvrstite napake ponudnika med poizkusne, primerni za nadomestne in terminalske razrede.
• Dokumentirajte, katere napake ne smejo sprožiti nadomestnih modelov.
• Navedite odobrene primarne in nadomestne modele glede na razred delovne obremenitve.
• Preverite dolžino konteksta, podporo orodja, podporo sheme in varnostno vedenje za vsako nadomestno možnost.
• Preverite vsak končni odziv glede na aplikacijo pogodba.
• Nastavite največje število ponovnih poskusov, odmik, tresenje in obdelavo Retry-After.
• Konfigurirajte odklopnike glede na ponudnika, model, regijo in razred napake.
• Nastavite množitelje stroškov in omejitve porabe za nadomestno porabo.
• ID-ji zahtev za beleženje, razredi napak, poskusi, rezultati preverjanja, zakasnitev in stroški.
• Preglejte zakasnitev p95 in p99 po uvedbi, ne le povprečne zakasnitve.
• Izpad ponudnika testov, omejitev stopnje, neveljavna shema, varnostna zavrnitev in scenariji neuspešnega preverjanja izhoda.

Uporabni sklep

Dobra nadomestna strategija LLM je urejena politika usmerjanja. Ločuje ponovni poskus od nadomestnega, natančno razvršča napake, ohranja izhodne pogodbe, spoštuje roke zakasnitve in naredi stroške vidne, preden pride do incidentov.

Ključno načelo načrtovanja je nespremenljivost. Odločite se, kaj mora ostati resnično, ko se promet premakne iz primarnega modela v nadomestni: veljavnost sheme, varnostno vedenje, ravnanje s kontekstom, podpora orodij, omejitve stroškov in opazljivost. Nato dovolite nadomestno samo, če je te invariante mogoče ohraniti.

Začnite z eno potjo visoke vrednosti in ne z globalnim nadomestnim stikalom. Določite njegovo taksonomijo napak, združljive nadomestne modele, pravila preverjanja, odklopnike in meritve. Izvedite vaje za napake na tej poti. Če se končna stopnja uspešnosti izboljša brez nesprejemljive zakasnitve p99, pogodbeno veljavne izgube odgovora ali povečanja stroškov, razširite pravilnik na naslednji razred delovne obremenitve.

Sorodno branje

• dodeljevanje porabe LLM po skupini in aplikaciji