Spoľahlivé smerovanie LLM API: časové limity, opakované pokusy a výpadky modelu bez sémantických regresií
Praktická architektúra na klasifikáciu zlyhaní LLM API, vynútenie jedného rozpočtu latencie, výber kompatibilných záložných modelov, ochranu vedľajších účinkov a overenie každej prijatej odpovede.
Záložná žiadosť nie je úspešná len preto, že iný model vrátil HTTP 200. Náhrada môže prekročiť pôvodný rozpočet latencie, vynechať povinné polia JSON, zavolať iný nástroj alebo vytvoriť odpoveď s podstatne odlišnou sémantikou. Spoľahlivé smerovanie LLM API preto vyžaduje viac než len zoradený zoznam modelov: vyžaduje zmluvu, klasifikátor zlyhania, politiku ohraničeného pokusu a overenie pred prijatím.
Ústredné pravidlo je jednoduché: skúste to znova len vtedy, keď je zlyhanie vierohodne dočasné, a odstúpte iba vtedy, keď nasledujúca trasa stále spĺňa pôvodnú požiadavku.
Pred výberom modelov definujte zmluvu o smerovaní
Začnite popisom toho, čo musí poskytnúť úspešná odpoveď. Táto zmluva o smerovaní by mala byť strojovo čitateľná a pripojená ku každému pracovnému zaťaženiu alebo triede požiadaviek.
{
"workload": "extrakcia_faktur",
"modality": ["text", "image"],
"max_input_tokens": 50 000,
"requires_tools": nepravda,
"structured_output": {
"povinné": pravda,
"schema_id": "faktúra-v3",
"prísne": pravda
},
"allowed_model_classes": ["extrakcia dokumentu"],
"max_cost_usd": 0,08,
"deadline_ms": 8 000
}Zmluva by mala zahŕňať požadované modality, kapacitu kontextu, podporu nástrojov, správanie sa štruktúrovaného výstupu, prijateľné triedy modelov, maximálne náklady a konečný termín. V prípade potreby pridajte obmedzenia špecifické pre aplikáciu, ako sú povolené oblasti, minimálna výstupná dĺžka alebo požadovaný dôvod dokončenia.
Odporúčanie: udržiavajte samostatné, testované skupiny trás pre obyčajný text, výstup s obmedzením schémy, používanie nástrojov, víziu a požiadavky s dlhým kontextom. Model, ktorý je prijateľným záložným textom, nie je automaticky prijateľným záložným nástrojom na volanie nástroja alebo zadávanie obrázkov.
Pred vykonaním akcie klasifikujte poruchu
Chyby overovania, chybne vytvorené požiadavky, limity rýchlosti a zlyhania servera vyžadujú rôzne reakcie. Zaobchádzanie s každou neúspešnou odpoveďou ako s opakovaným plytvaním kapacitou a môže skryť chyby.
Fakt: neúspešné žiadosti s obmedzenou sadzbou sa môžu stále započítavať do limitov poskytovateľa. Agresívne okamžité opakovania môžu preto prehĺbiť škrtenie namiesto jeho vyriešenia. Opakované pokusy tiež spotrebúvajú dodatočnú kapacitu počas výpadku a zásady opakovania na niekoľkých aplikačných vrstvách môžu výsledné zaťaženie znásobiť.
Odporúčanie: nechajte jednu vrstvu vlastniť opakovanie generovania modelu. V typickej architektúre je brána AI API tým správnym vlastníkom, pretože vidí stav trasy, históriu pokusov, latenciu a náklady. Ak je to možné, zakážte automatické opakovania v klientoch nižšej úrovne alebo ich explicitne započítajte do rozpočtu na rovnaký pokus.
Miňte jeden komplexný rozpočet na latenciu
Časové limity na jeden pokus sú nedostatočné. Tri pokusy s päťsekundovým časovým limitom môžu premeniť zamýšľanú päťsekundovú operáciu na pätnásťsekundovú odozvu, kým sa nezapočítava stiahnutie a overenie.
Zaznamenajte absolútny termín, keď požiadavka vstúpi do brány. Pred každým pokusom vypočítajte zostávajúci čas:
zostávajúci = termín - aktuálny_čas
požadované = pripojenie_prídavok + generačný_príspevok + validačný_príspevok
ak zostáva < povinné:
stop_without_launching_another_attemptPri 8-sekundovom termíne môže primeraná počiatočná alokácia vyhradiť 300 ms na prácu brány a záverečnú validáciu, ponechať až 4,5 sekundy pre primárnu cestu a ponechať približne 3,2 sekundy pre jednu núdzovú operáciu. Tieto hodnoty sú príkladom, nie benchmarkom. Musia byť odvodené z nameraných distribúcií latencie pre skutočných poskytovateľov, modely, regióny a veľkosti výstupov.
Použite obmedzené exponenciálne stiahnutie s chvením na prechodné opakované pokusy:
oneskorenie = náhodné(0, min(limit, základ * 2^index_opakovania))Rady poskytovateľa na opätovný pokus, ako napríklad hodnota opätovného pokusu po, by mali mať prednosť, keď sa zmestia do zostávajúceho termínu. Po malom počte pokusov zastavte. Spoločnou politikou je jeden primárny pokus plus jeden záložný s voliteľným opakovaným pokusom o rovnakú cestu iba v prípade skorého zlyhania pripojenia, ktoré nemohlo vygenerovať účtovateľný výstup.
Trade-off: sekvenčné záložné riešenie zlepšuje dostupnosť, ale zvyšuje latenciu. Paralelné alebo zaistené požiadavky môžu znížiť latenciu počas spomalení, ale spotrebúvajú viac kapacity a môžu spôsobiť poplatky za niekoľko úspešných generácií. Hedging by sa mal obmedziť na záťaže kritické z hľadiska latencie a bez vedľajších účinkov so zrušením a kontrolou nákladov.
Vyberajte záložné reklamy podľa schopnosti, nie podľa hodnotenia
Záložná tabuľka by mala kódovať skôr kompatibilitu než globálne poradie preferencií. Pred zvážením zdravia, latencie alebo ceny filtrujte kandidátske trasy podľa zmluvy.
kandidáti = trasy
.filter(supports_required_modalities)
.filter(context_limit >= odhadovaná_veľkosť_vstupu)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(trieda_modelu v triedach povolených_modelov)
.filter(odhadované_náklady <= zostávajúce_náklady_rozpočet)
.filter(not_temporarily_suppressed)
vybraté = poradie (kandidáti, zdravie, latencia, náklady)Podpora štruktúrovaného výstupu si zaslúži explicitné testovanie. Aj keď dve cesty inzerujú generovanie s obmedzením schémy, môžu podporovať rôzne podmnožiny schémy JSON alebo odlišne interpretovať okrajové prípady. Modely s nástrojmi sa môžu líšiť aj výberom nástrojov, konštrukciou argumentov a správaním paralelného volania.
Fakt: rodiny modelov prepínania môžu zachovať dostupnosť dopravy a zároveň zmeniť štýl, kvalitu uvažovania, bezpečnostné správanie, tokenizáciu a výber nástrojov. Úspech HTTP nie je dôkazom sémantickej ekvivalencie.
Predpoveď: ako sa katalógy modelov rozširujú, budú politiky smerovania výroby čoraz viac využívať profily verzií schopností a akceptačné testy špecifické pre pracovné zaťaženie namiesto zoznamov statických modelov. Berte to ako smer návrhu, nie záruku správania poskytovateľa.
Overte odpoveď pred jej prijatím
Spustite každú odpoveď, vrátane primárnej odpovede, cez rovnaký kanál prijatia. Overenie by malo prebehnúť skôr, ako sa výsledok uloží do vyrovnávacej pamäte, interne sa zaúčtuje ako úspešný alebo sa odošle vykonávateľovi nástroja.
- Potvrďte, že prenos bol dokončený a obálka odpovede môže byť analyzovaná.
- Skontrolujte dôvod dokončenia a odmietnite skrátenie, keď sa vyžaduje úplný výstup.
- Overte štruktúrovaný výstup oproti pôvodnej schéme.
- Overte povinné polia, enum hodnoty a invarianty aplikácie.
- Povoliť iba registrované názvy nástrojov a overiť argumenty proti každej schéme nástroja.
- Aplikujte sémantické kontroly špecifické pre pracovné zaťaženie tam, kde by nesprávne prijatie bolo nákladné.
Na extrakciu faktúr môžu sémantické kontroly vyžadovať nezáporný súčet, podporovaný kód meny a súčty riadkových položiek v rámci explicitne definovanej tolerancie. Pre klasifikáciu si vyžiadajte štítok z povolenej sady. Na generovanie kódu môže byť vhodná analýza alebo kompilácia. Tieto kontroly nedokazujú kvalitu, ale bránia tomu, aby sa predvídateľné porušenia zmluvy považovali za úspechy.
Neopravujte potichu každú chybnú odpoveď. Deterministická normalizácia, ako je odstránenie neškodných okolitých bielych miest, môže byť prijateľná. Hádanie chýbajúcich finančných polí alebo prepisovanie argumentov nástroja mení význam modelu a malo by vyvolať odmietnutie alebo kontrolu človekom.
Oddelené generovanie opakovaní od vedľajších účinkov
Žiadosti LLM bežne používajú HTTP POST, ktorý vo svojej podstate nie je idempotentný. Ešte dôležitejšie je, že odpoveď modelu môže spustiť externú akciu, ako je spoplatnenie spôsobu platby, odoslanie správy, vytvorenie lístka alebo úprava infraštruktúry. Opätovný pokus o generovanie a prehratie tejto akcie sú samostatné rozhodnutia.
Každému volaniu modelu priraďte ID operácie na hranici aplikácie a ID pokusu. Pretrvávať stav vykonávania nástroja proti deterministickému kľúču, ako napríklad:
execution_key = operation_id + tool_name + canonical_arguments_hashPred spustením nástroja skontrolujte, či daný kľúč nie je čakajúci, dokončený alebo zlyhal. Namiesto opätovného spustenia vráťte uložený výsledok na dokončené vykonanie. Pre operácie, ktorých argumenty sa môžu legitímne zmeniť, vyžadujú schválenie na úrovni aplikácie alebo nové ID operácie.
Nejednoznačný časový limit si vyžaduje špeciálne zaobchádzanie. Ak spojenie zlyhá po odoslaní požiadavky, brána nemusí vedieť, či došlo ku generovaniu. Kľúč idempotencie podporovaný poskytovateľom môže pomôcť, ak je k dispozícii. V opačnom prípade zapíšte výsledok ako neznámy a namiesto toho, aby ste predpokladali, že sa nič nestalo, použite politiku opakovania špecifickú pre pracovné zaťaženie.
Potláčajte nezdravé trasy a odhaľte každý pokus
Istič alebo dočasné obmedzenie zdravotného stavu bráni každej novej požiadavke znovu nájsť tú istú neúspešnú cestu. Otvorte okruh po definovanej chybovosti alebo prahovej hodnote po sebe idúcich poruchách, potom pripustite obmedzené sondy v polootvorenom stave. Vylaďte prahové hodnoty podľa trasy a triedy zlyhania, aby chybná požiadavka klienta nemohla spôsobiť, že zdravý model bude nedostupný.
Zaznamenajte jednu udalosť na úrovni požiadavky a jednu udalosť na pokus. Užitočné polia zahŕňajú ID operácie, ID pokusu, vybraného poskytovateľa a model, triedu zlyhania, kód stavu, latenciu, počet tokenov, odhadované náklady, dôvod núdzového riešenia, výsledok overenia, stav okruhu a konečný výsledok. Upravte alebo hashujte výzvy, výstupy a argumenty nástrojov podľa ich požiadaviek na citlivosť a uchovávanie.
Užitočné prevádzkové metriky zahŕňajú záložnú mieru, počet pokusov na dokončenú požiadavku, mieru vyčerpania termínu, mieru odmietnutia overenia, nejednoznačné výsledky, cenu za prijatú odpoveď a latenciu podľa konečnej cesty. Rastúca miera úspešnosti HTTP spolu s rastúcou mierou odmietnutia overenia je varovaním, že dostupnosť prenosu maskuje zlyhania zmluvy.
Kontrolný zoznam zavádzania produkcie
- Definujte verzovanú zmluvu o smerovaní pre každú triedu pracovného zaťaženia.
- Zmapujte chyby poskytovateľa do trvalých, prechodných, nekompatibilných, neplatných odpovedí a nejednoznačných kategórií.
- Vyberte jedného vlastníka opätovného pokusu a obmedzte celkový počet pokusov.
- Propagujte absolútny termín prostredníctvom brány, klienta poskytovateľa, overenia a spustenia nástroja.
- Namiesto jedného globálneho modelového reťazca vytvorte záložné skupiny s testovanými schopnosťami.
- Overujte schémy, volania nástrojov, dôvody dokončenia a invarianty domény.
- Odstraňujte duplicitné vedľajšie efekty pomocou prevádzkových a spúšťacích kláves.
- Pridajte potlačenie trasy pomocou ohraničených polootvorených sond.
- latencia, tokeny, cena, zlyhania a výsledky prijatia na úrovni pokusov o protokolovanie.
- Časové limity vloženia, 429 s, vybraté chyby 5xx, chybný formát JSON, pretečenie kontextu a pomalé úspechy pri príprave.
Začnite s primárnou cestou a jedným kompatibilným záložným riešením pre jedno nízkorizikové pracovné zaťaženie. Pred rozšírením pravidiel porovnajte kvalitu prijatej odozvy, latenciu a cenu. Cieľom nie je čo najvyššia miera záložných práv. Ide o ohraničený systém, ktorý buď vráti odpoveď spĺňajúcu pôvodný kontrakt, alebo jednoznačne zlyhá skôr, než spôsobí duplicitnú prácu alebo sémantické poškodenie.