Өнімді бұзбай модельді пайдаланудан шығару

Модельді өнімді бұзбай пайдаланудан шығару

Модельді тым ерте алып тастаса не бұзылады

Модельді пайдаланудан шығарғанда ақау сирек бір үлкен инцидент сияқты көрінеді. Әдетте өнім бөлшектеп бұзылады: бір жол бірден құлайды, екіншісі мінез-құлқын байқатпай өзгертеді, үшіншісі тек бірнеше сағаттан кейін білінеді.

Көбіне команда ең басты сценарийді емес, тыныш жанама сценарийді ұмытады. Сайттағы ботты жаңа модельге ауыстырғанымен, ескі промпт түнгі есепте, модерацияда, тикет классификациясында немесе операторларға арналған ішкі көмекшіде қалып қояды. Сол жол іске қосылғанша, бәріне ауысу сәтті өтті сияқты көрінеді.

Тіпті сұраулар бір OpenAI-үйлесімді шлюз арқылы жүрсе де, мәселе жоғалып кетпейді. Кодта жиі кезекке, cron-тапсырмаға немесе ескі fallback ережесіне бекітілген model қалып қояды. Негізгі трафик жаңа модельде жүріп жатады, ал фондық тапсырмалар ескі модельге сұрау жібере береді.

Тағы бір бөлек мәселе — ескі промпттар. Жаңа модель мәні жағынан дұрыс жауап беруі мүмкін, бірақ форматы басқаша болады. Адам үшін бұл ұсақ нәрсе, өнім үшін — ақау. Егер downstream-сервис intent және priority өрістері бар JSON күтсе, ал қарапайым мәтін алса, тикет маршруты бұзылады, CRM-дегі карточка бос қалады, автоматты жауап жіберілмейді.

Әдетте бұл былай көрінеді:

• чат жауап береді, бірақ келесі қадам батырмалары шықпайды
• batch өңдеу ретрай жинап, кезекті үлкейтеді
• түнгі есептер бос немесе қоқыс дерекпен келеді
• support алерттен бұрын шағым алады

Support көбіне мәселені бірінші болып байқайды. Пайдаланушы: «model id 404 беріп тұр» деп жазбайды. Ол: «бот біртүрлі жауап беріп тұр», «өтінім жоғалып кетті», «экспорт нәтижесі басқа» дейді. Егер мониторинг тек жауап статусын және орташа кідірісті ғана тексерсе, инженерлер жауап форматының әлдеқашан бұзылғанын ұзақ уақыт байқамайды.

Ең нашар жағдай — ескі модель асинхронды контурда қалып қоюы. Кезектер, batch jobs және retry интерфейстен ұзақ өмір сүреді. Команда миграция аяқталды деп шешкеннен кейін де сұраулар тағы бір тәулік бойы кете беруі мүмкін. Ақау уақыт бойына жайылып кетеді: күндіз тыныш, түнде backlog жиналады, таңертең шағымдар түседі.

Проблеманың ерте белгісі қарапайым: пайдаланушылар оғаш мінез-құлықты көріп отыр, ал дашборд әлі жасыл. Бұл әдетте модельді барлық тәуелділіктер табылып, ескі промпттардағы жауап форматы тексерілмей тұрып алып тастағаныңызды білдіреді.

Жұмыс басталар алдында кімдерді ескерту керек

Бірінші хабарламаны ауысу күні емес, алдын ала жіберген дұрыс. Командаларға жалпы хабарландыру емес, үш датасы бар түсінікті кесте керек, сонда ешкім ескі модельдің өшірілгенін қателер көбейгенде ғана білмейді.

Ашық жазыңыз:

• freeze күні — осы күннен бастап команда ескі модельге жаңа промпттар, функциялар және тесттер қоспайды
• switch күні — осы күннен бастап негізгі трафик жаңа модельге өтеді
• shutdown күні — осы күннен бастап ескі модельге сұраулар бұғатталады немесе запас маршрутқа жіберіледі

Әр датаға уақыт белдеуін, жауаптыны және rollback шартын қосыңыз. Егер дата бар да, rollback шешімін ешкім қабылдамаса, жоспардың пайдасы аз.

Төрт топты бөлек ескертіңіз. Product пайдаланушы сценарийлерінде не өзгеретінін және сапаның уақытша төмендеуі қай жерде рұқсат екенін түсінуі керек. Support жауап үлгілерін, шағымдарға арналған шаблондарды және шағымдар енді инцидент саналатын күнді білуі тиіс. Analytics ауысу терезесін алдын ала белгілеп, жаңа модель әсерін әдеттегі метрика түсуімен шатастырмауы керек. Security логтарды, PII маскалауды, AI-content белгілерін және қолжетімділік ережелерін тексереді.

Зақымданатын аймақтардың бір тізімін жинаған пайдалы. Тек алып тастайтын модельді емес, оған байланғанның бәрін көрсетіңіз: өнім функциялары, клиенттер, арналар, ішкі құралдар және сыртқы интеграциялар. Мұндай тізім бастапқыда-ақ даудың жартысын азайтады.

Егер трафик AI Router сияқты шлюз арқылы өтсе, бұл картаны API кілттері, model ID және бір OpenAI-үйлесімді endpoint қолданатын сервистер бойынша жинау ыңғайлы. Бұл product командасы білмейтін жасырын тәуелділіктерді тез табуға көмектеседі.

Сұрақтар үшін бір арна керек: чат немесе трекердегі кезек. Шешім үшін бір жауапты керек. Әдетте бұл ауыстыруды жүргізетін инженерлік менеджер немесе сервис техлиді болады; ол: жалғастырамыз, rollback жасаймыз немесе қосарлы қолдау терезесін ұзартамыз деп айта алуы тиіс. Арна екеу, жауапты үшеу болса, командалар модельді пайдаланудан шығарудан да ұзақ дауласады.

Тәуелділіктер картасын қалай жасау керек

Модельді пайдаланудан шығару кезінде команда көбіне тек негізгі сервиске қарайды да, жанында өмір сүріп жатқанның бәрін өткізіп алады. Сосын ескі модель жоғалады, ал бұзылатыны бүкіл өнім емес, ондаған ұсақ сценарий болады: түнгі экспорт, операторларға арналған бот, аналитиктің қолмен жазған скрипті, CRM-дегі жауап парсері.

Соңғы 30–60 күндегі шақыру логтарынан бастаңыз. Егер сізде апта сайынғы және ай сайынғы тапсырмалар болса, бір ай аздық етуі мүмкін. Тек сұрау жиілігін емес, сонымен бірге дереккөзді, параметрлерді, іске қосылу уақытын және шақыру жолын қараңыз. Айдың соңындағы сирек сұрау есепті кезеңді жабу үшін міндетті болуы мүмкін.

Содан кейін модель мүлде қатысатын барлық нүктелердің толық тізімін жинаңыз. Әдетте API сервисі мен чат-бот тез табылады, бірақ көзге түсе бермейтін нәрселер ұмытылады: кесте бойынша жұмыс істейтін batch тапсырмалар, support пен аналитиктерге арналған ішкі утилиталар, админка немесе ноутбук арқылы қолмен орындалатын операциялар, модельге тікелей сұрайтын серіктестер мен клиенттер интеграциялары.

Келесі қадам — тек model-дің өзін емес, жауап пішінін де тексеру. Егер команда бір кезде промптты ескі модельге бейімдесе, жаңа модель басқа JSON, басқа өріс тәртібі немесе сәл бөлек мәтін стилін қайтаруы мүмкін. Адам үшін бұл ұсақ нәрсе. Парсер үшін — бәрі құлап қалатындай жеткілікті. Сондықтан әр сценарийдің қасына промпттарды, post-processing-ті, regex-ті, JSON schema-ны және ескі форматты күтетін тексерістерді белгілеңіз.

Операциялық тәуелділіктерді де бөлек қараңыз. Көбіне alert-тер, dashboard-тар, rate limit-тер және бюджеттер ескі модель атына байланады. Ауыстырғаннан кейін графиктер босап, alert-тер үнсіз қалады да, команда бәрі тыныш деп ойлайды. Шын мәнінде олар жай ғана соқыр болып қалды.

Ең жағымсыз жағдай — негізгі API-ды айналып өту. Егер трафиктің бір бөлігі бір шлюз арқылы өтсе, ал клиенттердің бір бөлігі ескі base_url-ды, бөлек кілтті немесе провайдерге тікелей шақыруды сақтап отырса, толық сурет болмайды. AI Router сияқты ортада мұны тексеру өте ыңғайлы: кім ортақ OpenAI-үйлесімді endpoint қолданады, ал кім ескі маршрутта қалды.

Жақсы тәуелділік картасы үш сұраққа жауап береді: модельді кім шақырады, одан нақты нені күтеді және істен шығуды кім бірінші байқайды. Егер әр сценарийдің айқын иесі болса, өшіру әлдеқайда тыныш өтеді.

Қосарлы қолдау терезесін қалай ашу керек

Қосарлы қолдау терезесі сақтық үшін емес, әділ тексеріс үшін керек. Жаңа модель қазірдің өзінде жүктеменің бір бөлігін қабылдайды, ал ескі модель әлі қызметте қалады. Әдетте командаға 7–14 күн жеткілікті, бірақ мерзімді алдын ала белгілеген дұрыс. Егер аяқталу күнін қоймасаңыз, уақытша схема тез арада тұрақтыға айналады.

Ескі және жаңа модель бір сценарийде қатар ұсталады. Команда қай сұрауларды екі жаққа да жіберетінін алдын ала шешеді. Әдетте қайталанатын ағындар алынады: support сұраулары, қысқа жауап генерациясы, классификация, құжаттардан өріс шығару. Пик сағаттарды, әртүрлі пайдаланушы түрлерін және сирек, бірақ қымбат қателерді қамтыса, кездейсоқ таңдау да жарайды.

Егер AI Router сияқты шлюзбен жұмыс істесеңіз, мұндай трафикті маршрутизация деңгейінде бөліп, SDK-ны, кодты немесе қолданбадағы base_url-ды өзгертпей жүргізу оңайырақ. Бұл тәуекелді азайтады: өнім бұрынғы схема бойынша өмір сүреді, ал салыстыру инфрақұрылым ішінде жүреді, асығыс қайта жазылған бизнес-логикада емес.

Күн сайын нені салыстыру керек

Тек мәтін сапасына қарау аздық етеді. Екі модель бір-біріне ұқсап жауап беруі мүмкін, бірақ өнімді әртүрлі жолмен бұзады.

• жауап форматы қолданба күткен пішінге сай ма
• типтік сұрауларда кідіріс өсіп жатыр ма
• мың сұрауға немесе бір сценарийге кететін құн өзгерді ме
• қате, бос жауап және timeout үлесі артты ма
• ұзын немесе сирек промпттарда жаңа сәтсіздіктер пайда болды ма

Мұндай сұрауларды бірдей тегтермен белгілеп, екі модельдің нәтижесін қатар сақтаған дұрыс. Сонда команда орташа бір санды емес, нақты айырмашылықтарды көреді: жаңа модель қай жерде баяу, қай жерде JSON-ды жиірек бұзады, қай жерде айқын пайдасыз қымбат жауап береді.

Басталар алдында-ақ rollback батырмасын ұзақ келісімсіз баса алатын адамды белгілеңіз. Шек те алдын ала қажет: мысалы, егер қателер үлесі келісілген деңгейден асып кетсе немесе кідіріс екі сағат қатарынан нормадан жоғары тұрса, трафик қайтадан ескі модельге қайтады.

Терезе кезінде промпттарды, жауап шаблондарын және бизнес ережелерді өзгертпеңіз. Әйтпесе сіз екі модельді емес, өнімнің екі түрлі нұсқасын салыстырасыз. Модельді пайдаланудан шығару үшін бұл жаман тест: ол анық сигналдың орнына шу береді де, ескі модельді өшіруді тек соза түседі.

Трафикті кезең-кезеңімен қалай ауыстыру керек

Кенет ауыстыру көп жағдайда модельдің өзін емес, оның айналасындағы өнімді ұрады. Сондықтан трафикті бір батырмамен емес, бөліп ауыстырады.

Алдымен жаңа модельді ұсақ қателер бизнестің өзіне зиян келтірмейтін пайдаланушыларға беріңіз. Әдетте бұл ішкі қолданушылар, тест жобалар, қызметтік сценарийлер немесе төмен тәуекелді сұраулар. Егер бот қызметкерлерге регламент іздеуге көмектессе, бұл жақсы бастапқы кандидат. Егер ол клиенттерге төлем туралы жауап берсе, мұндай ағынды кейінге қалдырған дұрыс.

Жұмыс ырғағы көбіне былай көрінеді: 5% трафик жаңа модельге, кейін 20%, содан соң 50%, және бірнеше тексеру циклі өткеннен кейін ғана 100%.

Егер трафик біркелкі болмаса, кезеңдер арасында бір күнде ауыса салмаңыз. Жұмыс күні таңертең және кешке жүйе әртүрлі әрекет етуі мүмкін. Күтетін уақытты тыныш сағаттарға емес, қалыпты пиктер көрінетін кезеңге таңдаған дұрыс.

Тек жауап мәтінін ғана емес, бәрін қадағалаңыз. Командалар көбіне мағынаны және тонды тексереді, бірақ пайдаланушы тәжірибесін одан бұрын бұзатын нәрселерді өткізіп алады: timeout, retry өсуі, бос жауаптар, кідірістің секіруі, формат қатесі және құралдардағы күтпеген бас тартулар. Егер жаңа модель сәл жақсырақ жауап берсе де, бірақ екі есе жиірек қайталап сұрауға кетсе, өнім әлдеқашан нашарлады.

Әр кезеңде жедел rollback керек. Өтініш арқылы емес және түнгі релиз арқылы емес, қарапайым routing ережесі арқылы. Егер метрика 20% төмендесе, бұрынғы маршрутты бірнеше минутта қайтара алуыңыз керек. AI Router арқылы мұны трафик үлесі, кілт немесе жеке пайдаланушы тобы бойынша оңай жасауға болады, клиенттік кодты өзгертпей.

Стоп-сигналдарды алдын ала келіскен пайдалы: бос жауаптардың әдеттегі деңгейден жоғарылауы, белгіленген шектен ұзақ кідіріс немесе support-тен қолмен шағымдардың көбеюі. Сонда дауласудың қажеті болмайды. Команда жай ғана қадамды rollback жасап, себебін талдайды.

Мұндай тәсіл баяу көрінеді, бірақ іс жүзінде күндерді үнемдейді. 5%, 20% және 50% арқылы жасалған бір ұқыпты ауысу ескі модельді кенет өшіргеннен кейінгі шұғыл талдаудан әлдеқайда арзан.

Support ботымен мысал

Интернет-дүкеннің support боты жиі қойылатын сұрақтарға жауап береді: тапсырыс қайда, қайтаруды қалай жасауға болады және жеткізу қашан келеді. Ескі модель мұны қысқа жауап береді, бірақ CRM қателіксіз оқитын тұрақты JSON қайтарады. Жаңа модель жақсырақ жазады әрі тірілеу естіледі, бірақ кейде жауап форматын бұзады.

Мәселе мәтінде емес, құрылымда болды. Бір жауапта модель өріс атын өзгертті, екіншісінде order_id-ді ұмытты, ал кейде массивтің орнына жол қайтарды. Клиент қалыпты жауапты көрді, ал CRM карточка аша алмады немесе тапсырыс статусын тарта алмады. Мұндай ақаулардың қауіптілігі — қолмен тексергенде оларды оңай өткізіп жібересіз.

Сондықтан команда ескі модельді бірден өшірмеді. Екі нұсқаны екі апта қатар ұстап, бірдей сұраулардан өткізді. Тек формулировка сапасын емес, тізбектің келесі бөлігіне керек өрістерді де салыстырды: intent, order_id, delivery_status, refund_reason, confidence.

Бірнеше күннен кейін жаңа модель жеткізу статусында жақсы жұмыс істейтіні, бірақ CRM қатаң формат күтетін қайтарым сценарийлерінде жиі қателесетіні көрінді. Команда парсингті түзеп, схема валидациясын қатайтты. Егер сұраулар AI Router сияқты бір шлюз арқылы өтсе, мұндай режимді бір API-де ұстау және интеграцияны қайта жазбай-ақ модельді ауыстыру оңайырақ.

Осыдан кейін трафик бірден түгел ауыспады, сұрау түрлері бойынша кезең-кезеңімен берілді. Алдымен жаңа модельге жеткізу туралы сұраулар жіберілді, кейін тапсырыс туралы сұрақтар, ең соңында — қайтарымдар. Осылай команда қай жерде қате үлесі өсетінін тез көріп, бүкіл ботты емес, бір ғана сценарийді rollback жасай алды.

Ескі модель тек логтарда құйрық жоғалғанда ғана өшірілді. Фондық тапсырмалар, сирек интенттер және әлі де ескі тармаққа кетіп жатқан қайталама сұраулар қалмады. Бұл скучный соңғы қадам сияқты көрінеді, бірақ дәл осы қадам модель өшірілді деп ойлаған кезде өнімнің үнсіз түрде 2% сұраныста бұзылуын тоқтатады.

Командалар қай жерде жиі қателеседі

Көбіне мәселе өшірудің өзінде емес, трафикке тым тар көзқараста болады. Команда өнімнен келетін нақты уақыттағы сұрауларды қарап, жаңа модель қалыпты жауап беріп тұр деп шешеді де, ауысу аяқталды деп ойлайды. Сосын түнде batch өңдеу құлайды: хаттарды талдау, есеп жасау, өтінімдерді қайта бағалау немесе кез келген басқа фондық тапсырма.

Жасырын тәуелділіктер күткеннен ұзағырақ өмір сүреді. Ескі модельді негізгі сервистен алып тастайды, бірақ кезектер, cron, retry және фондық worker-лер ұмытылады. Нәтижесінде код таза көрінеді, ал сұраулар әлі де жеке consumer немесе ескі конфигурация арқылы ескі endpoint-ке кетіп жатады. Тіпті команда AI Router сияқты бір шлюзбен жұмыс істесе де, бұл пакет қызметіндегі ұмыт қалған орта айнымалысын құтқармайды.

Орташа метрикалар да жиі ұйқыға жіберіп жібереді. Егер тек жалпы қате үлесін, орташа кідірісті және орташа құнды қарасаңыз, сирек, бірақ қымбат ақауларды өткізіп аласыз. Олар әдетте графикте көрінбейтін сценарийлерде шығады: ұзын диалогтар, сирек тілдер мен аралас сұраулар, контекст лимитіне тірелетін үлкен құжаттар, келесі сервистер үшін қатаң JSON форматындағы жауаптар.

Осындай қателердің бір пайызы орташа мәнде оңай жоғалады. Support үшін бұл ондаған қолмен тексеру, кері қайтқан тикеттер және ашулы пайдаланушылар.

Тағы бір жиі қате — ешкімді алдын ала ескертпеу. Егер support, account manager-лер және кезекші инженерлер модельді пайдаланудан шығару туралы білмесе, олар сағаттарын «кездейсоқ» сапа төмендеуін іздеуге жұмсайды. Қысқа ескерту көп уақыт үнемдейді: не өзгереді, ауысу қашан басталады және қандай симптомды инцидент деп санау керек.

Көп команда rollback-ты тым ерте жабады. Бір тыныш күн ештеңе дәлелдемейді. Өнімде апталық циклдер, ай соңы, таңғы пиктер және ауыр түнгі терезелер бар. Егер ескі модельді бірінші тыныш кезеңнен кейін бірден алып тастасаңыз, тәуекел жойылмайды. Ол кейін, ыңғайсыздау сәтте ғана білінеді.

Ескі модельді тек толық тексеру циклынан кейін ғана өшіру керек: online трафик, фондық процестер, кезектер, cron және support. Осы қабаттардың біреуі де тексерілмесе, ауысу әлі аяқталмаған.

Өшіру алдында жылдам тексеріс

Ескі модельді күнтізбеге қарап емес, фактілер бойынша өшіреді. Егер бір жерде ескі API-ға тыныш шақыру қалып қойса, ақау миграция күнінде емес, бір аптадан кейін, біреу сирек сценарийді іске қосқанда пайда болады.

Соңғы өшіру алдында қысқа бақылау тізімінен өтіп шығу пайдалы. Ол көп уақыт алмайды, бірақ жиі түнгі rollback-тан құтқарады.

• Логтарды түсінікті кезең үшін тексеріңіз, мысалы 7–14 күнге. Онда ескі API адресіне, ескі model id-ге немесе ескі route-қа жаңа сұраулар болмауы керек. Тек prod емес, фондық jobs, cron, admin панельдер, тест стендтері және ескі нұсқадағы мобильді клиенттерді де қараңыз.
• Барлық командалар мен сыртқы клиенттер өшіру күнін алғанына көз жеткізіңіз. Бір хат жеткіліксіз. Нақты растаулар керек: чаттағы жауап, done мәртебесі бар тикет немесе change calendar-дағы белгі.
• Ескі және жаңа модельдің мониторингін бөлек жүргізіңіз. Қате, timeout, құнның өсуі және сапаның түсуі бөлек көрінуі керек, әйтпесе жаңа мәселе жалпы көріністе жасырынып қалады.
• Rollback-ты қосатын адамды белгілеңіз және rollback қадамын жорамалсыз сипаттаңыз. Маршрутты кім өзгертеді, конфиг қайда жатыр, кері қайтуға қанша минут кетеді, кім рұқсат береді.
• Тек техниканы емес, операциялық талаптарды да жабыңыз. Егер бюджет лимиттері, invoicing, лог сақтау, data residency немесе PII маскалау талаптары болса, олар жаңа схемаға да жұмыс істеуі тиіс.

Осы кезеңде әдетте жағымсыз ұсақ-түйек шығады. Мысалы, prod әлдеқашан жаңа модельге өткен, бірақ ескі endpoint-ты әлі де түнгі batch-процесс есептер үшін түртеді. Күндіз бәрі таза көрінеді, түнде жүйе сіз өшірмек болған жерге қайта трафик жібереді.

Қазақстандағы командалар үшін бұл деректерге қойылатын талаптар үшін модель ауысқанда тіпті маңызды. Егер трафик AI Router-ға ауысса, аудит-логтарды, AI-content белгілерін, PII маскалауды, rate limit ережелерін және теңгемен биллингтің қалай өтетінін бөлек тексерген жөн. Мұндай нәрселер модельдің жауабын бірден бұзбайды, бірақ оның айналасындағы процесті бұзады.

Егер бір пункт те күмәнді болып тұрса, өшіруді кейінге қалдырған дұрыс. Модельді пайдаланудан шығару тек ескі жол бос, жаңа жол бақыланатын және rollback бірнеше минутта қосылатын кезде ғана тыныш өтеді.

Әрі қарай не істеу керек

Модельді пайдаланудан шығарғаннан кейін жұмыс бір күнде жабылмайды. 2–3 күннен соң командаға қысқа талдау керек: модель не үшін алынды, ауысу кезінде не болды, қай шешімдер жұмыс істеді, қайсысы істемеді. Бұлай жазылмаса, бір айдан кейін ешкім неге дәл осындай ауысу тәртібі таңдалғанын есіне түсірмейді.

Жалпы қорытынды емес, сандарды жазған дұрыс. Ауысуға дейінгі және кейінгі қателерді, p50 мен p95 кідірісті, fallback үлесін, 1000 сұрауға немесе миллион токенге шаққандағы құнды салыстырыңыз. Тіпті «қателер 1,7%-дан 0,8%-ға түсті, p95 120 мс-қа өсті, шығын 11%-ға азайды» деген жазбаның өзі метрикасы жоқ ұзақ есептен пайдалырақ.

Сосын өнімді артқа тартатынның бәрін тазалаңыз. Ескі промпттар, тесттер, alert-тер және уақытша ережелер көбіне модельдің өзінен ұзақ өмір сүреді. Соның кесірінен жаңа команда ескі маршрутты байқамай қайта қосуы мүмкін, ал мониторинг тағы бір ай бойы жоқ endpoint үшін шу шығарады.

Өшіруден кейін әдетте төрт қадам жеткілікті:

• енді шақырылмайтын ескі промпттар мен шаблондарды жою
• ескі модель жауабына байланған тесттерді алып тастау
• осы модельді ғана бақылайтын alert-тер мен dashboard-тарды сөндіру
• runbook пен rollback ережесін жаңа схемаға бейімдеу

Бұл тазалауды бөлек PR арқылы жүргізген жақсы. Сонда репозиторийде миграциядан аман қалған жасырын тәуелділіктер мен уақытша костыльдер жоқ па, соны тексеру оңайырақ.

Қаржыны да қайта есептеу керек. Ауыстырғаннан кейін команда көбіне тек модель бағасын қарайды, бірақ промпт ұзындығының өсуін, қайталама сұраулар санын немесе cache hit rate төмендеуін байқамайды. Кейде модель token бойынша арзан, бірақ ай соңындағы жалпы есеп бойынша қымбатырақ шығады. Кідіріс те дәл солай: орташа жауап уақыты төмендегенімен, p95-тағы ұзын құйрық пайдаланушы тәжірибесін нашарлатады.

Егер сіз бірнеше модельді AI Router немесе api.airouter.kz арқылы жүргізсеңіз, келесі инцидентті күтпеңіз. Келесі ауыстыру үшін маршрутты бірден дайындаңыз, аудит-логтарды қосыңыз және кілттерге лимит қойыңыз. Сонда жаңа ауысу кезінде қай сервис әлі де ескі модельді шақырып тұрғанын тез көріп, бүкіл өнімге қауіп төндірмей, трафикті нүктелі түрде шектей аласыз.