Промпттар мен модельдерді нұсқалау: өзгерістерді код ретінде басқару, тосын сыйларсыз

Неліктен жаңартулар жауаптарды байқатпай өзгертеді

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

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

Мәселе тек сапаның нашарлауында емес. Қауіп — бұл өзгерісті кеш және дұрыс емес адамдар байқайды. Қолдау қызметі үшін бұл «алдыңғыдай түсінікті еді» сияқты жалпақ шағымдар санының өсуін білдіреді. Сату бойынша — тым ұзын немесе сенімсіз жауаптардан конверсия төмендеуі мүмкін. Комплаенс пен мемлекеттік органдар үшін — ассистент ресми хаттарда немесе сатып алу құжаттарында қолдануға болмайтын формулировкаларды бере бастау қаупі бар.

Ескерту белгілері әдетте:

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

Промпттар мен модельдердің нұсқасын басқару — бұл бюрократия емес, сақтандыру. Өзгерістер көрініп, тексеріліп және оңай қайтарылатын болуы тиіс. Әйтпесе сапа «тыншып» үздіксіз төмендей береді.

Нені нұсқалау керек

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

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

Екіншісі — генерация параметрлері мен шектеулер. Температура, top_p, максималды ұзындық, стоп-сөздер, шығу форматы (мысалы, қатаң JSON) және қауіпсіздік ережелері жиі бірнеше сөзді өзгертуге қарағанда әсері үлкен. Оларды промптпен бірге конфигурация ретінде сақтаңыз.

Үшінші — модель ортасы: нұсқа, провайдер, регион, режимдер (функциялар, құралдар, кэш) және мінез-құлықты өзгертетін кез келген флагтар. Тіпті «сол» модель әр провайдерде басқа жауап беруі мүмкін.

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

Ақырында, тесттер. Кейстер жиынтығы мен эталон жауаптарды бөлек артефакт ретінде сақтау ыңғайлы. Практикалық минимум:

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

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

Репозиторийді қалай ұйымдастыру керек

Жақсы LLM репозиториі папкалардан гөрі әдеттен басталады: промпт, баптаулар немесе модельге жасалған кез келген түзету тарихта көрініп, талқыланып және тексеріліп отыруы керек. Сол кезде «тыншық» ақаулар жай ғана өзгертулерге айналып, оларды табу, түсіндіру және қажет болғанда қайтару оңай болады.

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

Кем дегенде ыңғайлы құрылым

Сценарий ішінде артефакттарды түрі бойынша бөлу жақсы көмектеседі: prompts, configs, evals, docs және changelog. prompts ішінде жүйелік және пайдаланушы шаблондары, сондай-ақ few-shot мысалдар (қолдансаңыз) болады. configs — модель және рантайм параметрлері: модель, температура, құралдарға шектеулер, шығу форматы. evals — тексерістер жиынтығы және «алтын» мысалдар, олар кез келген өзгерістен кейін өтуі тиіс. docs — «неге осылай?» деген түсініктеме, changelog — жауап мінезіндегі маңызды өзгерістерді қарапайым тілде тіркеу.

Нұсқалар мен тегі мағыналы атаумен жақсы. Датадан гөрі «support-tone-clarified» немесе «citations-required» сияқты атаулар пайдалырақ: атынан не тексеру керектігі көрінеді.

«Мінез-құлық келісімі» — құтқарушы файл

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

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

Өзгеріс процесі: тармақтар, ревью және айқын ережелер

Егер промпттар мен модельдер жөніндегі түзетулер чаттарда талқыланса, шешім тарихы болмайды. Хабарламалар жоғалады, контекст адаммен бірге кетеді, «неге осылай шештік?» деген сұрақ догадкаға айналады. "Өзгерістер — код" тәсілі бір орталық орынды береді: не өзгертілгені, кім мақұлдағаны, қандай тесттер өткендігі және қалай откат жасау керектігі көрінеді.

Ветка схемасы қарапайым болу керек, әйтпесе қолданылмайды. Көбінесе жеткілікті жиын:

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

Маңызды ереже: кез келген өзгеріс pull request арқылы өтуі тиіс. Бұл бір ғана кіру нүктесі, онда мақсат көрсетіледі, diff көрсетіледі, тест нәтижелері тіркеледі және ескертулер жиналады.

Ревью жылдам әрі бірдей болу үшін PR сипаттамасының қысқа шаблоны пайдалы. Ол көріктілік үшін емес, тәуекелдерді жабу үшін қажет:

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

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

Іс-жүзіндегі цикл: түзетуден религке дейін

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

Алдымен сценарий иесін тағайындаңыз (бір адам немесе шағын топ) және қабылдау талаптарын қарапайым сөйлемдермен жазыңыз. Мысалы: «фактілерді ойдан шығармау», «қысқа жауапты бірінші абзацта беру», «тыйым салынған әрекеттерді ұсынбау». Бұл талаптар қабылдау ережелеріне айналады.

Одан кейін golden set жинаңыз — нақты қолданушы сұрақтарынан 20–200 мысал. Қарапайым сұрақтармен қатар қиын жағдайларды да қосыңыз: анық емес формулировкалар, қайшы талаптар, жасырын деректер сұраулары. Әр мысал үшін жақсы жауап не екенін алдын ала сипаттаңыз.

Репозиториде орындау қадамдары

Жұмыс істейтін негізгі схема:

• бастапқы нұсқаны бекітіңіз: тег, параметрлер (температура, шекті мәндер), жүйелік нұсқаулар және орта
• бөлек тармақ жасап, промпт немесе конфигті өзгертіңіз
• golden set бойынша тесттерді іске қосып, базаға қарсы салыстырыңыз: не жақсарды, не нашарлады
• PR жасаңыз: өзгеріс мақсатын қысқаша сипаттап, салыстыру нәтижелерін тіркеңіз
• чек-лист бойынша ревью жасаңыз: талаптар, қауіпсіздік, стиль, жауаптардың тұрақтылығы

Тосын сыйсыз релиз

Релизді басқарылатын эксперимент ретінде жасаған жөн: алдымен аз пайыз трафик немесе шағын қолданушы тобы, содан кейін ұлғайту. Сапа метрикаларын (шағымдар, операторға эскалация пайызы, бас тарту жиілігі, жауап уақыты) және golden set-тен бақылау мысалдарын қадағалаңыз.

Регрессия байқалса, откат оңай болуы керек: промпт тегі мен модель параметрлеріне қайту. Базаның дәл белгiленiлгендiгi себептерді талдауды тездетеді.

Регрессияны пайдаланушыларға дейін қалай ұстау керек

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

Негізгі тест жиынтығы

Golden set-тен бастау: 30–200 сұрақ, оларды әр іске қосу сайын жаңа нұсқамен салыстырыңыз.

Төрт қабатты қамтыңыз:

• фактілер және дереккөздерге сүйену: білім базасы бар болса, жауаптар оған қайшы келмеуі керек және ойдан шығармау тексерілсін; мүмкін болған жағдайда үзінді цитаталар немесе фактілер тізімі талабын қойыңыз
• стиль және формат: тіл, тон, ұзындық, құрылым (қысқа абзацтар, сілтемесіз, чек-лист беру) — мұндай ережелерді автоматты ережелермен тексеру жеңіл
• қауіпсіздік: персоналды ақпарат, қауіпті нұсқаулар, ішкі ережелерді айналып өтуге талпынулар — провокациялық сұраулар қосыңыз
• сапа регрессиясы: алдыңғы нұсқамен салыстыру бойынша метрикалар (эксперт бағасы, автоскоаринг, «сенімді емес» жауаптардың үлесі)

Қабылдау шегі

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

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

Сапа мониторингі: релизден кейін не өлшеу керек

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

Жинақтауға лайық метрикалар

Минимум келесі метрикаларды қадағалаңыз:

• эскалациялар үлесі: диалог қаншалықты жиі операторға өтеді немесе тикетке түседі
• шағымдар және төмен бағалар: «жауап көмектеспеді» сияқты бөлек маркер
• шешімге дейінгі уақыт: мәселені жабуға қанша хабарлама кетеді
• жауап уақыты: медиана және 95-перцентиль
• жауап құны: сұрауға және сәтті шешімге кеткен токендер

Логтар да қажет, бірақ жеке деректерсіз. Қай нұсқаның іске қосылғанын, модель нұсқасын, тапсырма типін, тілді, контекст ұзындығын және финалдық мәртебені (сәтті, бас тарту, эскалация) сақтаңыз. Сұрау мәтінін жасырын немесе жартылай маскамен сақтау талдауды қауіпсіз жүргізуге мүмкіндік береді.

Алерттер және апта сайынғы тексеріс

Шұғыл өзгерістерге аларт орнатыңыз:

• бас тартулар немесе «білмеймін» жауаптарының өсуі
• токен шығынының өсуі әрі тиімділіктің төмендеуі
• эскалациялардың көбеюі
• жаңа тақырыптардың пайда болуы
• соңғы N сағаттағы баға төмендеуі

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

Екі дашбордты бөлек ұстаңыз: сапа (бағалар, эскалациялар, сәттілік) және шығын (токендер, кешігулер). Осылай не бұзылғанын — логика ма, әлде экономиканың ма — тез түсінуге болады.

Практикалық мысал: промптты жаңарттық — жанама әсер пайда болды

Үлкен ұйымның 24/7 қолдау боты бар деп ойлаңыз. Мысалы, жүйе интеграторы мен өндірушіде мемлекеттік тапсырыс берушілер, мектептер мен банктерден сұраулар келеді: «ПК қосылмайды», «сервер дискіні көрмейді», «гарантия талап ету қалай». Бот тез бастапқы ақпарат жинап, инженерге өтініш береді.

Команда промптты өзгертуді шешті: аз жалған жауап, көбірек пайда. Ереже: 2–3 нақтылау сұрағын қою және қысқа диагностикалық жоспар беру (қуат, кабельдер, индикаторлар, модель нөмірі, серия нөмірі). Қағаздағыдай бәрі дұрыс көрінді.

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

Егер нұсқалау қолданылған болса, оқиға басқаша өтеді. Промпт репозиториде код сияқты сақталады: өзгеріс бөлек тармақта жасалып, PR және ревью өтеді. Слияниге дейін тест жиынтығы (жинақталған, маскаланған мысалдар) және «бұрын/кейін» салыстыру жүргізіледі: жауап ұзындығы, сұрақ саны, уәделер үлесі, дұрыс эскалация пайызы сияқты метрикалар салыстырылады.

PR кейін жартылай шығару (мысалы, 10% трафик) жасалады. Өзгерістердің есебі әдетте мыналарды қамтиды:

• не жақсарды (азайған «білмедім», көбірек дұрыс сұрақтар)
• не нашарлады (ұзақ жауаптар, орынсыз уәделер)
• 3–5 диалог мысалы
• шешім: промптты түзету және тесттерді қайталау немесе шығару шектеуі мен мониторингпен релиз

Осылайша жанама эффект релизге дейін ұсталып, шешім мысалдарға негізделеді.

Откат және инцидентпен жұмыс

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

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

Техникалық және өнімдік откат

Техникалық откат — промпт пен модель конфигурациясының соңғы «жасыл» тегіне қайтуы. Бұл минуттарда орындалатын және продта қолмен түзетулер талап етпейтін әрекет болуы тиіс.

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

Инциденттің алғашқы 30–60 минутында істелетіндер:

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

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

Версиолдаудың жиі кездесетін қателері

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

Қауіпті әдет — промптты тікелей продта өзгерту. PR, ревью және тарихсыз сіз контекст пен салыстыру қабілетін жоғалтасыз.

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

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

Типтік «тармақтар», процесс бұзатын:

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

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

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

Қысқа чек-лист және келесі қадамдар

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

• біріккен репозиторий және анық құрылым: prompts, configs, тест жиынтықтары мен есептер орталықтандырылған
• кез келген түзету PR арқылы өтеді: мазмұн бойынша ревью (жауап сапасы) және тәуекелдер бойынша ревью (қауіпсіздік, саясат), сондай-ақ минимум автоматты тесттер
• нұсқалар бекітілген: модель, параметрлер (temperature, top_p және т.б.), жүйелік нұсқаулар, шаблондар және орта
• регрессиялық кейстер жиынтығы бар: типтік сұрақтар, қиын сұрақтар, шет жағдайлар және қабылдау шегі (факттік дәлдік, формат, тон, тыйымдар)
• біртіндеп шығару мен бақылау қосылған: канареечный процент, сапа метрикалары, аларттар және минуттар ішінде откат жасау процесі

1–2 спринт ішінде іске қосу үшін келесі қадамдар:

1. Бір мәні жоғары сценарийді таңдаңыз (мысалы, қолдау жауаптары немесе коммерциялық хаттарды генерациялау) және 15–30 мысал арқылы «қандай жауап жақсы» екенін сипаттаңыз.

2. Сценарийді «өзгерістер — код» форматына көшіріңіз: промпт, модель параметрлері және тесттер бір жерде болсын, чаттар мен кестелерде жоқ.

3. PR-ге базалық тексеруді қосыңыз: регрессиялық кейстерді іске қосып, «бұрын/кейін» қысқа есеп беретін механизм, дауды пікірлерге емес мысалдарға негіздеуге.

4. Қауіпсіз релиз орнатыңыз: алдымен аз пайыз трафик, кейін кеңейту және алдын ала дайындалған откат жоспары.

Егер тесттер, мониторинг және өндірістік сапа бақылауы үшін инфрақұрылым қажет болса, жүйелі интеграторлар бұл жұмысты жасайды. Қазақстанда мұндай процестерді GSE.kz (gse.kz) арқылы — серверлік және дата-орталықтан бастап 24/7 қолдау және өндірісте өзгерістерді бақылауға дейін бірге құруға болады.