Релизге дейінгі бағалау пайплайны: жинақтан регрессияларға дейін

Релиз неге кеше жұмыс істегенді бұзады

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

LLM өнімдерінде бұл әсіресе анық көрінеді. Интерфейс сол күйі қалады, API өзгермейді, ал мінез-құлық басқа болады. Пайдаланушыға бұл кездейсоқ тұрақсыздық сияқты көрінеді: кеше бот өтінімді дұрыс толтырса, бүгін өрістерді шатастырады немесе артық дерек сұрайды.

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

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

Пайдаланушы мұны бірден байқайды. Бот әдеттегіден ұзақ жауап береді, сұрақты қайталайды, тақырыптан шығып кетеді, бренд стилін сақтамайды немесе бұрын сұрамаған деректерді кенеттен сұрайды. Банк, ритейл немесе медицинада бұл тез арада шағымға, қайта хабарласуға және оператордың қолмен жұмысына айналады.

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

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

Қайдан бастау керек

Метрика мен кестеден бастамаңыз. Алдымен команда бір сөйлеммен нақты не өзгеретінін айтуы керек. Мысалы: "Банк қолдау чатының жауап моделін ауыстырамыз, интерфейс пен prompt-ты қозғамаймыз". Көп жағдайда осының өзі тексеруді тарылтып, артық дауды алып тастауға жеткілікті.

Мұндай тұжырым бірден шекара қояды. Сіз бүкіл өнімді бағаламайсыз. Нақты өзгеріс пен оның салдарын тексересіз.

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

Тексеруге кім жауап береді

Бірінші тексерістегі ең жиі мәселе біреу: бәрі қатысады, бірақ соңына дейін ешкім жауап бермейді. Рөлдерді алдын ала бекіткен дұрыс. Бір адам golden set-ті жүргізеді, бір адам тестті іске қосып, қайталанымдылықты бақылайды, тағы бір адам релиз туралы шешім қабылдайды. Кейде бұл екі адам ғана болады, үш адам емес. Бұл қалыпты. Жаман жағы — иесі соңғы сәтте мысалдарды өзгертіп, ал релиз шешімін егжей-тегжейін көрмеген команда қабылдауы.

Рөлдерден кейін тәуекелдерді жазыңыз. Он, жиырма емес. Бірінші өтім үшін релизді шынымен тоқтата алатын 3-5 тармақ жеткілікті. Әдетте тізім тез түсінікті болады: модель фактілерді шатастырады, банк стиліне тым еркін жазып, жауап форматын бұзады немесе рұқсат етілген уақыттан баяу жауап береді.

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

Релизді не тоқтатады

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

Әдетте бірнеше қарапайым ереже жетеді:

• маңызды фактілер бойынша кез келген нашарлау релизді тоқтатады;
• келісілген межеден жоғары формат қатесі релизді тоқтатады;
• latency лимиттен асса, релиз қайта қарауға кетеді;
• даулы жағдайлар сол күні финал шешім қабылдайтын адамға беріледі.

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

Golden set-ті қалай жинау керек

Golden set-ті ойдан шығарылған prompt-тардан емес, адамдар өнімде шынымен жазатын сұраныстардан жинаған дұрыс. Логтардан, қолдау хаттарынан және инцидент талдауларынан алыңыз. Дәл осындай мысалдар модельдің қай жерде шатасатынын, үндемей қалатынын немесе тым сенімді жауап беретінін тез көрсетеді.

Бірінші нұсқа үшін алып архив қажет емес. Көбіне 150-300 мысал жеткілікті, егер олар нақты сценарийлерді жақсы қамтыса. Егер сіз банк, телеком немесе healthcare саласында жұмыс істесеңіз, PII-ді бірден жасырыңыз: аттар, нөмірлер, мекенжайлар, шоттар, телефондар.

Содан кейін жинақты тазалау керек. Дубликаттарды, бір-біріне тым ұқсас формулировкаларды және ештеңені тексермейтін шуды алып тастаңыз. Егер он қолданушы бір сұрақты әртүрлі айтса, екі-үш нұсқаны қалдырыңыз. Бұл жеткілікті.

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

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

Әр мысалда тек "дұрыс жауап" өрісі ғана болмауы керек. Нені күтетінін бекітіп жазған әлдеқайда пайдалы. Бір тапсырма үшін нақты эталон мәтін керек. Екіншісі үшін бағалау ережелері маңыздырақ: модель факті ойдан шығармайды, дұрыс тонмен жауап береді, нақтылайтын сұрақ қояды, жеке деректерді ашпайды және қол жетпейтін әрекетке уәде бермейді.

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

Golden set-ке тірі жұмыс артефактісі сияқты қараңыз. Продакшендегі әр сәтсіздіктен кейін сол күні жаңа мысал қосыңыз, "кейін бір күні" деп қалдырмаңыз. Бірнеше релизден кейін мұндай жинақ пайдаланушылар байқамай тұрып-ақ мәселені ұстай бастайды.

Қандай метрика таңдау керек

Егер есепте 12 сан болса, команда біреуін де есте сақтамайды. Релиз үшін әдетте нәтиже туралы қарапайым сұрақтарға жауап беретін 2-4 метрика жеткілікті.

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

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

Шектерді екі қабатпен белгілеген дұрыс. Алдымен бүкіл golden set бойынша. Сосын қателігі қымбатырақ топтарда: ұзақ диалогтар, аралас тілдер, құқықтық формулировкалар, JSON жауаптар, PII бар сұраныстар. Жалпы өту баллы мынадай болуы мүмкін: дәлдік 92%-дан төмен емес, толықтық 90%-дан төмен емес, қауіпсіздік 99,5%, p95 4 секундтан аспау керек. Бірақ міндетті JSON тобы үшін форматқа түсу 99% болуы керек, жалпы нәтиже жоғары болса да.

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

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

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

Кандидатты қалай өткізу керек

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

Алдымен іске қосу шарттарын бекітіңіз. Мысалдар жинағын, генерация параметрлерін, кіріс форматын және post-processing-ті тексеру барысында өзгертуге болмайды. Егер трафик AI Router арқылы жүрсе, model id, system prompt, temperature, max tokens және нәтижеге әсер етуі мүмкін басқа баптауларды нақты сақтаған жөн. Тіпті тапсырма бірдей болса да.

Келесі процесс әдетте былай көрінеді:

1. Prod-тағы базалық нұсқаны және жаңа кандидатты алыңыз.
2. Екеуін де бірдей golden set-те, бірдей ретпен өткізіңіз.
3. Әр мысал үшін тек қорытынды бағасын ғана емес, жауаптың өзін, latency, тайм-ауттарды және егер шығын релиз үшін маңызды болса, сұраныс құнын да сақтаңыз.
4. Нәтижелерді бір кестеге жинаңыз: әр жол — бір тест, ал бағандар база, кандидат және айырманы көрсетеді.
5. Төмендеулерді түріне қарай белгілеңіз: фактілік қате, бас тарту, артық сөз, нашар формат, саясатты бұзу, жауап уақытының өсуі.

Орташа сан көбіне жағымсыз нәрсені жасырады. Жалпы score 2% өсіп кетуі мүмкін, өйткені FAQ тезірек жауап бере бастады, бірақ кредит өтінімдерінде модель мерзім мен ставканы жиі шатастырады. Формальды түрде орташа көрсеткіш жақсы. Ал банк үшін бұл бәрібір жаман релиз.

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

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

Қалыпты прогон қорытындысы "модель жақсы болды" деп емес, қысқа түйінмен жазылады: кандидат қай жерде ұтты, қай жерде ұтылды, бұл қанша тұрады және қазір қандай тесттер выкладканы бөгеп тұр.

Мысал: банк чат-ботын жаңарту

Банк қолдау чат-ботының system prompt-ын жаңартуды шешті. Мақсат айқын еді: жауаптарды қысқарту, тонды қатаңдату және клиентті тікелей жауаптың орнына жалпы кеңестерге жиі бұрмау.

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

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

Golden set не тапты

Жинақ тек қысқа әрі таза сұрақтардан тұрмады. Онда тірі чат стиліндегі ұзақ хабарламалар болды: клиент бірден карта, тариф, лимит туралы жазып, бір хабарламада екі жағдайды салыстыруды сұрайтын. Сондай-ақ қолдауда әлі де кездесетін ескі тарифтер жөніндегі сұрақтар да кірді.

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

Команда мұндай тексерудің не үшін керек екенін тез түсінді. Әдемі орташа сан үшін емес, өнімге ауыр соққы беретін тар жерлерді табу үшін. Есепте жүз жол жоқ еді. Онда қысқа қорытынды болды: ескі және жаңа нұсқаның жалпы нәтижесі, төмендеген сегменттер, 14 проблемалық мысал және шешім — релизді бөгей ме, әлде prompt-ты түзете ме.

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

Командалар көбіне қай жерде қателеседі

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

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

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

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

Тағы бір мәселе — белгілі ақауларды бөлек белгілемеу. Нәтижесінде ескі багтар әр прогонда қайта шығып, жаңа регрессиялармен араласып, басымдықтарды бұлыңғыр етеді. Оларға "белгілі", "релизге дейін рұқсат етілген" немесе "блокер" деген жеке тег ұстау әлдеқайда оңай.

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

Выкладка алдында жылдам чек

Выкладка алдында жаңа үлкен прогон қажет емес. Керегі — команда әр жолы бірдей жасайтын қысқа бақылау өтімі.

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

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

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

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

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

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

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

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

Бірінші бетте әдетте үш сан жеткілікті:

• бүкіл golden set бойынша жалпы нәтиже;
• модель жиі қателесетін күрделі топтар бойынша нәтиже;
• қазіргі нұсқамен салыстырғандағы регрессия саны.

Сандардың қасына қысқа түсініктеме беріңіз. Мысалы: "Жалпы score 1,8% өсті, бірақ ұзақ контексті бар сценарийлерде 12 жаңа қате табылды". Мұндай жол уақыт үнемдейді және жаман жаңалықты кестеде жасырып қалмайды.

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

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

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

Есептен кейін не істеу керек

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

Бір үйлесімді endpoint арқылы бірнеше модельді салыстыратын командалар үшін іске қосуды және логтарды бір жерде ұстау ыңғайлы. AI Router-де бір API мен аудит логтарына сүйеніп, кандидаттарды бірдей шартпен салыстыруға болады, ал есіңізге сүйеніп дауласпайсыз. Бұл әсіресе бір тест бірнеше провайдерде қатар жүргенде пайдалы.

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