Модельдің канарейлік шығарылымы: трафик, тоқтату метрикалары, кері қайтару

Неге жаңа релиз ойлағаннан да көп бұзады

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

100% трафикке өткенде көбіне көзге бірден түсе бермейтін нәрселер бұзылады. Чат сәл баяуырақ жауап береді, парсер дұрыс JSON алмайды, биллинг жоспардан асып кетеді. Пайдаланушы тек "біртүрлі жауап" көреді, ал команда содан кейін қай жерде ақау шыққанын сағаттап іздейді.

Көбіне проблемалар былай көрінеді:

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

Орташа метрика әсіресе қауіпті. Егер тек жалпы pass rate-ке немесе бір орташа бағаға қарасаңыз, жеке бір топ сұраудағы сәтсіздікті оңай өткізіп аласыз. Мысалы, диалогтардың 95%-ы жақсы өтеді, бірақ кестелері, мекенжайлары немесе заңдық тұжырымдары бар өтініштерді жаңа модель нашар өңдейді. Дашбордта бәрі жасыл, ал продакшнде бір, бірақ маңызды функция бойынша тикеттер жанып жатыр.

Жасырын сәтсіздік әдетте үш жақтан келеді: кідіріс, құн және жауап форматы. Текст жақсырақ болуы мүмкін, бірақ егер SLA төмендеп, бюджет өсіп, downstream-сервис жауап құрылымын түсінбей қалса, бизнеске пайдасы аз. Сұрауларды бір endpoint арқылы жіберетін командалар үшін, мысалы AI Router сияқты жүйеде, қауіп бір себеппен жоғары: модельді ауыстыру тым оңай. Бір base_url мен бір флаг нақты трафиктегі тексеруді алмастырмайды.

Тағы бір жиі қате — инцидент болып жатқан кезде-ақ кері қайтару туралы таласа бастау. Бір инженер сапаға қарайды, екіншісі құнға, үшіншісі "тағы 15 минут дерек" сұрайды. Команда таласып жатқанда, пайдаланушылар нашар жауап алады. Канарейлік шығарылым тек егер тоқтату ережелері алдын ала белгілі болса ғана жұмыс істейді: шешімді кім қабылдайды, қандай метрика релизді кідіртеді және қандай шекке жеткенде команда ескі модельге пікірталассыз қайтады.

Бірінші пайызға дейін не дайындау керек

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

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

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

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

Бірінші пайызға дейінгі ең аз тексеру мынадай:

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

Кері қайтарудың өзі жарты сағаттық қоңырауды қажет етпеуі керек. Егер сіз бір LLM-шлюзді қолданып, тек маршрутты немесе модель атын өзгертсеңіз, алдыңғы нұсқаға қайту минуттар алады. Егер кері қайтару үшін кодты түзету, сервисті қайта жинау және deploy күту керек болса, сіз әлі 1% трафикке дайын емессіз.

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

Трафик пайызын қалай көтеру керек

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

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

Келесі қадамда трафикті сатымен көтерген дұрыс: 1%, кейін 5%, 10%, 25%, 50% және содан кейін ғана 100%. Мұндай қарқын баяу көрінеді, бірақ асығыстықтан арзаныраққа түседі. Команда 1%-дан бірден 25%-ға секірсе, жиі сапа төмендеп кеткен сәтті өткізіп алады, ал мәселе әлі қатты естілмей тұрады.

Әр қадамда шамалас көлемдегі сұрауды күтіңіз. Егер алғашқы кезеңде шамамен 800 типтік өтініш жинасаңыз, 5% бен 10%-да соған жақын көлем мен құрамдағы үлгі күткен дұрыс. Әйтпесе сіз әртүрлі сағаттарды, әртүрлі аудиторияны және әртүрлі үлгі көлемін салыстырасыз.

Бір күнде аймақты, арнаны және модельді бірге өзгертпеңіз. Егер жаңа модельді тек бір аймақтағы веб-чатқа ғана қоссanız, команда тез қай нәрсе өзгергенін түсінеді. Егер сол күні мобильді арнаны, басқа аймақты және жаңа маршруттауды да қоссаңыз, ақаудың себебі ұсақ детальдар арасында жоғалады.

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

Қандай метрикалар релизді паузаға қояды

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

Бірінші белгі — қателер базадан жоғары. Тек 5xx пен таймауттарға емес, бос жауаптарға, себепсіз бас тартуларға, стримнің үзілуіне және жарамсыз tool call-дарға да қараңыз. Егер мұндай сәтсіздіктердің үлесі әдеттегі деңгейден анық жоғары болып, 10-15 минут сақталса, трафик пайызын арттырмайды.

Екінші белгі — кідіріс. LLM үшін бұл көбіне ойлағаннан ауыр: жауап техникалық тұрғыда келді, бірақ пайдаланушы кетіп қалған. Сондықтан орташа уақытқа емес, p95 немесе p99-ға қарайды. Егер сіздің жауапқа арналған SLO-ңыз 5 секунд болса, ал канарейка тұрақты түрде 7-8 секунд берсе, релизді бірден тоқтатқан дұрыс.

Үшінші белгі — жауап құны. Жаңа модель ұзақ жазады, құралдарды жиі шақырады немесе кешпен нашар жұмыс істеуі мүмкін. Аз трафикте бұл қалыпты көрінеді, ал 20% сұрауда бюджетке тиеді. Жауаптың орташа құнына немесе 1000 сұрауға шаққандағы құнға қатаң лимит ұстаған пайдалы.

Төртінші белгі — қажетті форматтың бұзылуы. Егер өнім JSON, өрістер кестесін немесе операторға арналған қатаң үлгіні күтсе, құрылымы жоқ жақсы текст те пайдасыз. Схемаға өтпейтін немесе қолмен түзетуге мұқтаж жауаптар үлесі өссе, канарейканы кеңейтпеген дұрыс.

Әдетте мына стоп-ережелер жеткілікті:

• қателер база деңгейінен 20-30% жоғары болып, 10-15 минут сақталады
• p95 кідірісі екі бақылау терезесі қатарынан SLO-дан асып кетеді
• жауаптың орташа құны команда лимитінен асады
• схемаға сай емес жауаптар үлесі қазіргі модельден айқын жоғары
• қолмен тексеру сезімтал сценарийлерде қауіп барын көрсетті

Қолмен тексеру қате қымбат немесе қауіпті жерде қажет. Мысалы, банктегі қолдауда карта бұғаттау, даулы шегерімдер және жеке деректер туралы жауаптарды бөлек қарап шыққан жөн. Автоматтандыру мұндай нәрселерді жиі өткізіп алады, ал адам оны он минутта байқайды.

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

Қадам бойынша релиз жоспары

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

Әдетте өсірудің қарапайым сатылары жеткілікті:

1. Ескі модель бойынша базаны түсіріңіз: қате үлесі, кідіріс, 1000 сұрауға шаққандағы құн, қолмен эскалация үлесі және сіз үшін маңызды өнім сигналы.
2. Жаңа модельге трафиктің 1%-ын қосыңыз да, салыстыру үшін тек бірдей сценарийлерді қалдырыңыз.
3. Метрикаларды алдын ала белгіленген терезе арқылы тексеріңіз, мысалы 30 немесе 60 минут, әрі шешімді тіркеңіз: өсеміз, үлесті ұстаймыз немесе кері қайтару.
4. Егер жаңа модель сапа, кідіріс және құн бойынша деңгейді ұстаса, үлесті 5%, кейін 10%-ға көтеріңіз.
5. Одан кейін 25% және 50% сияқты үлкен қадамдарға өтіңіз, бірақ соңғы екі терезе стоп-сигналсыз өтсе ғана.

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

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

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

Шешімді тез кері қайтару үшін есепті қалай жүргізу керек

Канарейка есебі архив үшін емес. Оның міндеті қарапайым: 2-3 минут ішінде релизді жалғастырасыз ба, әлде ескі модельге қайтарасыз ба — соны көрсету.

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

Есепте не болуы керек

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

Қатарға төрт нәрсені қойыңыз: қателер, кідіріс, құн және сапа. Егер оларды бөлек дашбордтарға шашсаңыз, команда шешімнің орнына таласқа кіріседі. Барлығы бір жолда тұрса, көрініс бірден түсінікті болады.

Кестеден кейін 3-5 сәтсіз сұрауды қосыңыз. Оларды жалпы сөзбен қайта айтып бермеңіз. Бір форматты қолданған дұрыс:

• кіріс сұрауы
• ескі модельдің жауабы
• жаңа модельдің жауабы
• нақты не дұрыс емес

Қысқа мысалдар жеткілікті. Бір сұрау себепсіз бас тартуға кетті, екіншісі қауіпті фактілік қате берді, үшіншісі шамадан тыс ұзақ жауап беріп, SLA-ны бұзды. Мұндай блок артық талқылаусыз шешім қабылдауға көмектеседі.

Есептің соңында бір ғана таңдау тұруы керек: "ары қарай барамыз", "ұстаймыз" немесе "кері қайтару". Қасында бір сөйлемдік себеп жазылады. Мысалы: "Кері қайтарамыз: 10% трафикте P95 лимиттен асты, ал қате үлесі дерлік екі есе өсті".

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

Мысал: банк қолдауының чаты

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

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

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

60 минуттан кейін жағдай жағымсыз, бірақ түсінікті болды. Бір диалогтың орташа құны 26%-ға өсті, өйткені модель ұзағырақ жауап беріп, жиірек нақтылау сұрады. Қабылданған шаблоннан тыс жауаптар үлесі 1,8%-дан 6,4%-ға көтерілді. Операторға ауысулар да көбейді: клиенттер бұлыңғыр жауаптардан кейін жиірек қайта сұрай бастады.

Команда не көрді

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

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

Есепке не кірді

Есепке бес нәрсе енді:

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

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

Канарейканы бұзатын қателер

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

Типтік сәтсіздіктер мыналар:

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

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

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

Егер кері қайтару 20 минутқа созылса, үш қоңырау қажет болса және бұрынғы конфигурацияны қолмен іздеу керек болса, бұл кері қайтару емес. Бұл — үміт.

Трафикті өсірер алдындағы қысқа чек-лист

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

Егер команда бірдей сандарға қарап, кім стоп басатынын түсінсе, қауіп бірден азаяды. Егер бір адам чаттағы шағыммен, екіншісі дашбордпен шешсе, мәселелер әдетте керек уақыттан ұзаққа созылады.

• Тоқтату шегі қазірдің өзінде жазылған және бәріне көрініп тұр. Бір инженердің басында емес, ортақ құжатта немесе арнада.
• Ескі модель дәл қазір қайтаруға дайын. Маршрут, нұсқа және баптаулар жаңа модельдің қасында, өткен тапсырмалар архивінде емес.
• Дашборд тек жалпы графиктерді емес, айырманы көрсетеді. Ескі және жаңа модель қатар тұруы керек.
• Қолмен тексеруге бөлек үлгі бар, әсіресе сезімтал сценарийлер үшін.
• Алдыңғы қадам бойынша есеп толтырылған.

Егер кемінде бір тармақ дайын болмаса, трафикті көтермеген дұрыс. Артық 30 минуттық тексеру әдетте шағымдардан кейін түнгі лог талдауымен кері қайтарудан әлдеқайда тыныш өтеді.

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

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

Шаблонда әдетте бірнеше өріс жеткілікті: ескі және жаңа модель нұсқасы, әр қадамдағы трафик үлесі, тоқтату шектері, шешім қабылдайтын адамның аты, тексеру уақыты және нәтиже. Бірнеше релизден кейін тарих команданың пайдасына жұмыс істей бастайды. Жазбалардан релиздің қай жерде бірқалыпты өткенін, қай жерде бұзылғанын көруге болады: 5% трафикте ме, кешкі шарықтаудан кейін бе, әлде ұзақ диалогтарда ма.

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

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

Егер команда бір OpenAI-үйлесімді шлюз арқылы жұмыс істесе, мұндай процесті бақылауда ұстау оңайырақ. Мысалы, AI Router-да airouter.kz арқылы base_url-ды api.airouter.kz-қа ауыстырып, бар SDK-лерді, кодты және промпттарды өзгертпей қалдыруға болады. Канарейка үшін бұл ыңғайлы: асығыста қателесетін орын азаяды және алдыңғы модельді сол тәсілмен қайтару жеңілдейді.

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