Runbook ukončení podpory modelu pro brány AI API: inventarizace, testování, migrace a vrácení zpět před koncem životnosti

Nejnovější vlajkový model není vždy tou nejlepší náhradou. Menší novější model může zachovat latenci a náklady pro velké objemy úloh. Pro složité pracovní postupy kódování, extrakce nebo uvažování může být nezbytný schopnější model. Runbook by to měl uvést explicitně, místo aby každé ukončení podpory ve výchozím nastavení převedl na upgrade.

Krok 6: Spusťte balíček pro vyhodnocení kompatibility

Před změnou produkčního směrování spusťte balíček hodnocení, který odráží skutečné riziko pracovní zátěže.

Minimální sada hodnocení

• Zlaté výzvy: stabilní příklady s očekávanými charakteristikami, ne nutně s jednou přesnou odpovědí.
• Testy platnosti schématu: Úspěšnost analýzy JSON, povinná pole, hodnoty výčtu, limity délky a kontroly vnořených objektů.
• Test volání nástroje: správný výběr nástroje, platné argumenty, žádné nebezpečné duplicitní vedlejší účinky.
• Bezpečnostní kontroly a kontroly odmítnutí: potvrzují, že legitimní obchodní požadavky jsou stále dokončeny.
• Porovnání nákladů: vstupní tokeny, výstupní tokeny, opakované pokusy a jakákoli duplicitní volání.
• Porovnání latence: p50, p95, p99, rychlost vypršení časového limitu a latence prvního tokenu streamování tam, kde je to relevantní.
• Kontrola člověkem: vyžaduje se u vysoce hodnotných nebo nejednoznačných pracovních postupů, kde automatické kontroly nestačí.

U strukturovaných pracovních postupů nestačí jediné skóre kvality v přirozeném jazyce. Nahrazení musí produkovat výstupy, které může následný kód analyzovat a důvěřovat jim.

Krok 7: Bezpečně stínujte provoz v produkci

Stínové testování znamená duplikování vzorku produkčních požadavků na kandidátský model, přičemž uživateli vrací pouze odpověď aktuálního modelu. Uložte kandidátní odpověď odděleně pro porovnání.

if route.shadow_enabled a request.is_safe_to_shadow:
    primární_odpověď = volání(aktuální_model, požadavek)
    enqueue_shadow_call(candidate_model, request, trace_id)
    return primary_response

Nezastiňujte vše. Vyhněte se duplikování požadavků, které obsahují volání nástrojů s vedlejšími efekty, pokud není vrstva provádění nástroje zakázána nebo zesměšňována. Buďte opatrní s citlivými údaji, pravidly uchovávání a nájemními smlouvami. Stínové testování zvyšuje dočasné výdaje na tokeny, ale poskytuje důkazy ze skutečných výzev, nikoli pouze z ručně vybraných testovacích případů.

Porovnejte výsledky stínování na:

• Platnost schématu
• Kompatibilita volání nástroje
• Výstupní délka
• Cena za úspěšný požadavek
• Rozložení latence
• Vzorce odmítnutí a chyb
• Výsledky kontroly konkrétních úkolů

Krok 8: Zavedení směrování na základě procent

Když kandidát projde hodnocením, zavádějte jej postupně. Upřednostněte směrování ovládacích prvků na bráně podle tenanta, klíče nebo logického modelu před přeinstalováním každé aplikace.

Konzervativní sekvence:

1. Pouze interní nájemci
2. 1 % způsobilé produkční návštěvnosti
3. 5 %
4. 25 %
5. 50 %
6. 100 %

Definujte prahové hodnoty vrácení před zahájením zavádění:

rollback_if:
  schema_failure_rate_increase: "> 1,0 procentního bodu"
  provider_5xx_rate: "> 2x základní"
  p95_latency_increase: "> 30 %"
  cost_per_successful_request: "> 25 % nad schválený rozpočet“
  tool_argument_validation_failures: "> 0,5 %"
  tenant_blocklist_hit: "jakýkoli kritický tenant"

Hranice by měly být vyladěny podle pracovní zátěže. Chatbot často toleruje více variací formulace než potrubí extrakce faktur. Úloha sumarizace na pozadí může tolerovat vyšší latenci než interaktivní asistent podpory.

Krok 9: Zachování atribuce fakturace během migrace

Migrace modelu může narušit analýzu využití, pokud brána zaznamenává pouze ID modelů poskytovatelů. Zachovat logické i fyzické rozměry modelu:

id_tenanta
api_key_id
název_logického_modelu
poskytovatel
provider_model_id
id migrace
vstupní_tokeny
výstupní_tokeny
provider_cost
customer_charge
latence_ms
stav
schema_valid

Na migration_id záleží. Umožňuje financím a podpoře porovnávat staré a nové chování během období zavádění. Pokud je náhradní model dražší, může se firma rozhodnout, zda rozdíl absorbuje, aktualizuje ceny, přesune některé nájemce na menší model nebo bude vyžadovat schválení zákazníkem.

Krok 10: Uchovávejte protokol auditu a plán vrácení

Každá migrace by měla zanechat záznam:

• Zastaralý model a náhradní model
• Dotčené názvy logických modelů
• Vlastník a schvalovatelé rozhodnutí
• Odkaz na zprávu o dopadu
• Výsledky hodnocení
• Přehled stínového provozu
• Časová razítka zavedení
• Hranice vrácení
• Oznámení pro zákazníky nebo partnery
• Konečný stav a získané poznatky

Plán návratu by měl být funkční, nikoli aspirační. Pokud bude starý model poskytovatele brzy ukončen, vrácení může znamenat přesměrování na druhého náhradního kandidáta, deaktivaci funkce, použití přísnější výzvy nebo dočasné omezení dotčených tenantů. Před odříznutím zdokumentujte dostupné možnosti.

Kompenzace ke správě

• Připnutá ID modelů zlepšují reprodukovatelnost, ale zvyšují riziko konce životnosti, když jsou snímky vyřazeny.
• Aliasy poskytovatelů snižují údržbu, ale mohou změnit chování pod aplikací, takže potřebují sledování regrese.
• Abstrakce na úrovni brány zjednodušuje migraci, ale může skrýt funkce specifické pro poskytovatele, pokud nejsou explicitní metadata schopností.
• Stínové testování zvyšuje spolehlivost, ale zvyšuje dočasné výdaje na token, protože požadavky jsou duplicitní.
• Automatická migrace snižuje riziko výpadku, ale může způsobit sémantické regrese, pokud jsou náhrady vybírány pouze podle ceny nebo generického srovnávacího skóre.
• Přepsání na nájemce chrání důležité zákazníky, ale zvyšuje provozní složitost a zátěž podpory.
• Přísné brány kompatibility chrání strukturované pracovní postupy, ale mohou zpomalit přijetí lepších modelů, které vyžadují rychlé změny nebo změny schématu.

Kontrolní seznam implementace

• Vytvořte centrální inventář modelů poskytovatelů a logických názvů modelů.
• Blokujte přímo ID modelů poskytovatelů z aplikačních týmů, kde je to možné.
• Přidejte sledování životního cyklu poskytovatele a ruční přepisování správcem.
• Generujte zprávy o dopadu pro každou událost ukončení podpory.
• Skóre nahrazování podle schopností, nákladů, latence, souladu a kompatibility.
• Spouštějte zlaté výzvy, kontroly schémat, kontroly volání nástrojů, kontroly bezpečnosti a porovnávání nákladů.
• Před vystavením náhrady zakryjte bezpečný produkční provoz.
• Zavádění podle tenanta, klíče nebo procenta s předdefinovanými prahovými hodnotami vrácení.
• Sledujte logický model, model poskytovatele a ID migrace v analýze využití.
• Zveřejněte metadata o ukončení podpory prostřednictvím rozhraní API pro partnery, pokud jsou ovlivněni následní zákazníci.

Akční závěr

Nejbezpečnější doba pro návrh procesu ukončení podpory je před dalším oznámením o vypnutí. Začněte s jedním pravidlem: aplikace vyžadují názvy logických modelů a brána vlastní mapování poskytovatele. Poté přidejte provozní vrstvu kolem tohoto pravidla: inventář, monitorování, zprávy o dopadu, hodnocení, stínový provoz, zavádění po etapách, vrácení zpět a protokoly auditu.

Tím se migrace modelu změní z nahrazení řetězce na poslední chvíli na pracovní postup spravovaných závislostí. Cílem není navždy zmrazit chování modelu. Cílem je záměrně měnit modely při zachování kvality, ceny, latence, strukturovaného výstupního chování a připisování fakturace.

Související informace

• ovládací prvky směrování a chování při vrácení pro LLM API
• partnersky orientovaný tenant a metadata využití