Spolehlivé směrování LLM API: Časové limity, opakování a výpadky modelu bez sémantických regresí
Praktická architektura pro klasifikaci selhání LLM API, vynucení jednoho rozpočtu na latenci, výběr kompatibilních záložních modelů, ochranu vedlejších účinků a ověření každé přijaté odpovědi.
Záložní požadavek není úspěšný pouze proto, že jiný model vrátil HTTP 200. Náhrada může překročit původní rozpočet latence, vynechat povinná pole JSON, zavolat jiný nástroj nebo vytvořit odpověď s podstatně odlišnou sémantikou. Spolehlivé směrování LLM API proto vyžaduje více než jen uspořádaný seznam modelů: vyžaduje smlouvu, klasifikátor selhání, zásady omezeného pokusu a ověření před přijetím.
Ústřední pravidlo je jednoduché: opakujte akci pouze v případě, že je selhání věrohodně dočasné, a ustupte pouze v případě, že další trasa stále může splnit původní požadavek smlouvy.
Před výběrem modelů definujte smlouvu o směrování
Začněte popisem toho, co musí poskytnout úspěšná odpověď. Tato smlouva o směrování by měla být strojově čitelná a připojená ke každé pracovní zátěži nebo třídě požadavku.
{
"workload": "extrakce_faktury",
"modality": ["text", "image"],
"max_input_tokens": 50 000,
"requires_tools": nepravda,
"strukturovaný_výstup": {
"povinné": pravda,
"schema_id": "faktura-v3",
"přísný": pravda
},
"allowed_model_classes": ["extrakce-dokumentu"],
"max_cost_usd": 0,08,
"deadline_ms": 8000
}Smlouva by měla zahrnovat požadované modality, kapacitu kontextu, podporu nástrojů, chování strukturovaného výstupu, přijatelné třídy modelů, maximální náklady a konečný termín. V případě potřeby přidejte omezení specifická pro aplikaci, jako jsou povolené oblasti, minimální délka výstupu nebo požadovaný důvod dokončení.
Doporučení: udržujte samostatné, otestované skupiny tras pro prostý text, výstup s omezeným schématem, použití nástrojů, vizi a požadavky s dlouhým kontextem. Model, který je přijatelným záložním textem, není automaticky přijatelným záložním nástrojem pro volání nástroje nebo vkládání obrázků.
Než provedete akci, klasifikujte chybu
Chyby ověřování, chybně vytvořené požadavky, limity rychlosti a selhání serveru vyžadují různé reakce. Zacházení s každou neúspěšnou odpovědí jako s opakovaným plýtváním kapacity a může skrýt vady.
Fakt: neúspěšné požadavky s omezenou sazbou se mohou stále započítávat do limitů poskytovatele. Agresivní okamžité opakování proto může prohloubit omezení namísto jeho vyřešení. Opakované pokusy také spotřebují další kapacitu během výpadku a zásady opakování na několika aplikačních vrstvách mohou výslednou zátěž znásobit.
Doporučení: nechte jednu vrstvu vlastní opakování generování modelu. V typické architektuře je brána AI API tím správným vlastníkem, protože vidí stav trasy, historii pokusů, latenci a náklady. Pokud je to možné, zakažte automatické opakování u klientů nižší úrovně nebo je explicitně započítejte ve stejném rozpočtu na pokus.
Utraťte jeden konečný rozpočet na latenci
Časové limity na jeden pokus jsou nedostatečné. Tři pokusy s pětisekundovým časovým limitem mohou změnit zamýšlenou pětisekundovou operaci na patnáctisekundovou odezvu, než bude zahrnuto couvání a ověření.
Zaznamenejte absolutní termín, kdy požadavek vstoupí do brány. Před každým pokusem vypočítejte zbývající čas:
zbývající = termín - aktuální_čas
požadované = connect_allowance + generation_allowance + validation_allowance
pokud zbývá < povinné:
stop_without_launching_another_attemptPro osmisekundovou lhůtu může přiměřená počáteční alokace vyhradit 300 ms pro práci s bránou a závěrečné ověření, ponechat až 4,5 sekundy pro primární cestu a ponechat přibližně 3,2 sekundy pro jednu zálohu. Tyto hodnoty jsou příkladem, nikoli měřítkem. Musí být odvozeny z naměřených distribucí latence pro skutečné poskytovatele, modely, regiony a velikosti výstupu.
Použijte omezené exponenciální couvání s jitterem pro přechodné opakování:
zpoždění = náhodné(0, min(cap, základ * 2^retry_index))Nápovědy poskytovatele pro opakování, jako je hodnota opakování po, by měly mít přednost, pokud se vejdou do zbývajícího termínu. Zastavte po malém počtu pokusů. Společnou zásadou je jeden primární pokus plus jeden záložní, s volitelným opakováním stejnou cestou pouze pro brzké selhání připojení, které nemohlo vygenerovat účtovatelný výstup.
Trade-off: sekvenční záložní řešení zlepšuje dostupnost, ale zvyšuje latenci na konci. Paralelní nebo zajištěné požadavky mohou snížit latenci během zpomalení, ale spotřebovávají více kapacity a mohou být zpoplatněny za několik úspěšných generací. Hedging by měl být omezen na zátěže kritické z hlediska latence a bez vedlejších efektů se zrušením a kontrolou nákladů.
Vybírejte záložní reklamy podle schopností, nikoli podle hodnocení
Záložní tabulka by měla kódovat spíše kompatibilitu než globální pořadí preferencí. Před zvážením stavu, latence nebo ceny filtrujte kandidátské trasy podle smlouvy.
kandidáti = trasy
.filter(supports_required_modalities)
.filter(context_limit >= odhadovaná_velikost_vstupu)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(třída_modelu v povolených_třídách_modelů)
.filter(odhadované_náklady <= zbývající_náklady_rozpočet)
.filter(not_temporarily_suppressed)
vybraný = rank(candidates, health, latence, cost)Podpora strukturovaného výstupu si zaslouží explicitní testování. I když dvě cesty inzerují generování s omezením schématu, mohou podporovat různé podmnožiny schématu JSON nebo interpretovat okrajové případy odlišně. Modely s nástroji se mohou rovněž lišit ve výběru nástroje, konstrukci argumentů a chování paralelního volání.
Fakt: rodiny přepínacích modelů mohou zachovat dostupnost dopravy a zároveň změnit styl, kvalitu uvažování, bezpečnostní chování, tokenizaci a výběr nástrojů. Úspěch HTTP není důkazem sémantické ekvivalence.
Předpověď: Jak se katalogy modelů rozšiřují, zásady produkčního směrování budou stále více používat verzované profily schopností a akceptační testy specifické pro pracovní zátěž namísto statických seznamů modelů. Považujte to za směr návrhu, nikoli jako záruku chování poskytovatele.
Před přijetím odpověď ověřte
Spustit každou odpověď, včetně primární odpovědi, prostřednictvím stejného kanálu přijímání. Ověření by mělo proběhnout předtím, než je výsledek uložen do mezipaměti, interně účtován jako úspěšný nebo předán exekutorovi nástroje.
- Potvrďte, že přenos byl dokončen a že lze analyzovat obálku odpovědi.
- Zkontrolujte důvod dokončení a odmítněte zkrácení, když je vyžadován úplný výstup.
- Ověřte strukturovaný výstup oproti původnímu schématu.
- Ověřte povinná pole, hodnoty výčtu a invarianty aplikace.
- Povolit pouze registrované názvy nástrojů a ověřovat argumenty proti každému schématu nástroje.
- Aplikujte sémantické kontroly specifické pro pracovní zátěž tam, kde by falešné přijetí bylo nákladné.
Pro extrakci faktur mohou sémantické kontroly vyžadovat nezáporný součet, podporovaný kód měny a součty řádkových položek v rámci explicitně definované tolerance. Pro klasifikaci vyžadujte štítek z povolené sady. Pro generování kódu může být vhodná analýza nebo kompilace. Tyto kontroly neprokazují kvalitu, ale zabraňují tomu, aby předvídatelná porušení smlouvy byla považována za úspěch.
Neopravujte potichu každou chybnou odpověď. Deterministická normalizace, jako je odstranění neškodných okolních bílých míst, může být přijatelná. Odhadování chybějících finančních polí nebo přepisování argumentů nástroje mění význam modelu a mělo by vyvolat odmítnutí nebo kontrolu člověkem.
Oddělte opakované generování od vedlejších účinků
Požadavky LLM běžně používají HTTP POST, který není ze své podstaty idempotentní. Ještě důležitější je, že odpověď modelu může iniciovat externí akci, jako je zpoplatnění platební metody, odeslání zprávy, vytvoření tiketu nebo úprava infrastruktury. Opakování generování a přehrání této akce jsou samostatná rozhodnutí.
Přiřaďte ID operace na hranici aplikace a ID pokusu ke každému volání modelu. Přetrvávat stav provádění nástroje proti deterministickému klíči, jako je:
execution_key = operation_id + tool_name + canonical_arguments_hashPřed spuštěním nástroje zkontrolujte, zda tento klíč nevyřízen, dokončen nebo selhal. Vraťte uložený výsledek pro dokončené provedení a nespouštějte jej znovu. Operace, jejichž argumenty se mohou legitimně změnit, vyžadují schválení na úrovni aplikace nebo nové ID operace.
Nejednoznačný časový limit vyžaduje zvláštní zacházení. Pokud se připojení po odeslání požadavku nezdaří, brána nemusí vědět, zda došlo ke generování. Klíč idempotency podporovaný poskytovatelem může pomoci, je-li k dispozici. V opačném případě zaprotokolujte výsledek jako neznámý a místo toho, abyste předpokládali, že se nic nestalo, použijte politiku přehrávání specifickou pro pracovní zátěž.
Potlačit nezdravé trasy a odhalit každý pokus
Jistič nebo dočasné potlačení stavu zabrání každému novému požadavku znovu nalézt stejnou neúspěšnou cestu. Otevřete obvod po definovaném prahu chybovosti nebo po sobě jdoucích poruch a poté povolte omezené sondy v polootevřeném stavu. Vylaďte prahové hodnoty podle trasy a třídy selhání, aby chybný požadavek klienta nemohl způsobit, že se zdravý model jeví jako nedostupný.
Zaznamenejte jednu událost na úrovni požadavku a jednu událost na pokus. Užitečná pole zahrnují ID operace, ID pokusu, vybraného poskytovatele a model, třídu selhání, kód stavu, latenci, počty tokenů, odhadované náklady, důvod nouzové situace, výsledek ověření, stav okruhu a konečný výsledek. Upravte nebo hashujte výzvy, výstupy a argumenty nástrojů podle jejich požadavků na citlivost a zachování.
Užitečné provozní metriky zahrnují míru záložních řešení, počet pokusů na dokončený požadavek, míru vyčerpání termínu, míru odmítnutí ověření, nejednoznačné výsledky, cenu za přijatou odpověď a latenci podle konečné cesty. Rostoucí míra úspěšnosti HTTP spolu s rostoucí mírou odmítnutí ověření je varováním, že dostupnost přenosu maskuje selhání smlouvy.
Kontrolní seznam zavádění výroby
- Definujte verzovanou směrovací smlouvu pro každou třídu zátěže.
- Mapujte chyby poskytovatele do kategorií trvalé, přechodné, nekompatibilní, neplatná odezva a nejednoznačné kategorie.
- Vyberte jednoho vlastníka opakování a omezte celkový počet pokusů.
- Propagujte absolutní termín prostřednictvím brány, klienta poskytovatele, ověření a spuštění nástroje.
- Spíše než jeden globální modelový řetězec vytvářejte záložní skupiny otestované schopnostmi.
- Ověřte schémata, volání nástrojů, důvody dokončení a invarianty domény.
- Deduplikujte vedlejší efekty pomocí ovládacích a spouštěcích kláves.
- Přidejte potlačení trasy pomocí ohraničených polootevřených sond.
- Latence na úrovni pokusů o protokol, tokeny, náklady, selhání a výsledky přijetí.
- Časové limity injektování, 429 s, vybrané chyby 5xx, chybně vytvořený JSON, přetečení kontextu a pomalé úspěchy při vytváření.
Začněte s primární cestou a jedním kompatibilním záložním řešením pro jednu pracovní zátěž s nízkým rizikem. Před rozšířením zásad porovnejte kvalitu přijaté odezvy, latenci a náklady. Cílem není co nejvyšší míra záložních řešení. Jedná se o ohraničený systém, který buď vrátí odpověď vyhovující původní smlouvě, nebo jasně selže dříve, než způsobí duplicitní práci nebo sémantické poškození.