Қай кезде қайта оқыту қажет емес: дерек пе, промпт па, әлде роутинг пе

Неге қайта оқытуды тым ерте таңдайды

Қайта оқыту көбіне метрика төмендегенде ең тура жауап сияқты көрінеді. Команда дәлдік 8-10%-ға түскенін көріп, бірден жаңа оқу циклін талқылай бастайды. Логикасы түсінікті: мәселе қаншалықты күрделі болса, шешімі де соншалықты күрделі болуы керек сияқты. Бірақ практикада оқу көбіне себепті емес, белгісін ғана емдейді.

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

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

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

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

Ескерту белгілері әдетте мынадай болып көрінеді:

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

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

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

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

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

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

Деректер нәтижені қай жерде бұзады

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

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

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

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

Қашан промпттың өзі жеткілікті

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

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

Ұзақ ережелер сирек көмектеседі. Әдетте 3-5 тірі мысал жақсырақ жұмыс істейді: әдеттегі жағдай, даулы жағдай, қысқа кіріс, шулы кіріс және бос дерек. Мысалдар «дәл бол» деген бір абзац нұсқаулықтан әлдеқайда жақсы рамка береді. Егер модель өрістерді шатастырса, оған тағы он тыйым емес, екі жақсы жауап көрсетіңіз.

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

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

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

Қашан роутинг жақсырақ көмектеседі

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

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

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

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

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

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

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

Бір спринтте қалай шешім қабылдауға болады

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

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

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

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

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

Әр нұсқа бойынша төрт нәрсені жазып отырған пайдалы:

• таңдалған метрика бойынша нәтиже
• 100 немесе 1000 сұрауға кететін құн
• әдеттегі жүктемедегі кідіріс
• қайталанатын қателер түрі

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

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

Мысал: орыс және қазақ тіліндегі банк өтініштері

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

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

Промпт та тым көп міндетті бірден көтеріп тұрды. Команда модельден бір өтуде өтінішті жіктеуді, келісімшарт нөмірін шығаруды, тілді табуды, шұғылдықты анықтауды және клиентке жауап жазуды сұрады. Қысқа хабарламаларда бұл кейде жұмыс істеді. Ұзын хаттарда нәтиже әр іске қосқанда әртүрлі болды.

Одан кейін тапсырманы үш қарапайым қадамға бөлді. Алдымен модель өтініш түрін анықтады. Содан кейін бөлек шақыру сумма, күн, карта нөмірі, өтініш арнасы сияқты өрістерді шығарды. Ал соңында басқа модель операторға немесе клиентке арналған жауап дайындады.

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

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

Артық оқу цикліне әкелетін қателер

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

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

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

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

Алаңдататын жинақ әдетте былай көрінеді:

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

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

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

Бастамас бұрынғы қысқа чек-лист

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

Бастамас бұрын мына тізімді өтіңіз:

1. Жойғыңыз келетін бір ғана қатені нақтылаңыз. «Модель нашар жауап береді» демей, «өтініш түрін шатастырады» немесе «JSON-ды 18% жағдайда бұзады» деңіз.
2. Бағалау үшін таза жиын жинаңыз. 100-300 мысалдың өзі жетеді, егер олар бірдей белгіленіп, нақты ағынды көрсетсе.
3. Модельге жақсы сүйеніш беріңіз: мықты жүйелік промпт, бірнеше жақсы мысал және жауап форматына қатаң талап.
4. Бірдей жиында кемінде 2-3 модельді салыстырыңыз. Кейде тапсырмаға қайта оқыту керек емес, басқа модель немесе қарапайым роутинг керек болады.
5. Шешімнің құнын есептеңіз. Егер оқу командаға екі апта кетіріп, ал өсім бірнеше ғана пункт болса, айырбас әлсіз.

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

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

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

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

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

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

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

Егер провайдерлер мен модельдерді кодты қайта жазбай-ақ тез салыстыру керек болса, сол тест жиынын AI Router арқылы өткізуге болады. Бұл - OpenAI API-мен үйлесімді бірыңғай шлюз: тек base_url өзгереді, ал SDK, код және промпттарды өзгертпей қалдыруға болады. Қазақстан мен Орталық Азиядағы командалар үшін бұл деректерді ел ішінде сақтау, PII-ді бүркеу, аудит логтары және қажет болса жергілікті орналастырылған open-weight модельдерді тексерудің де ыңғайлы жолы.

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