Продакшнде промпттарды кім өзгерте алады: схема

Ереже жоқ болса, мәселе неде

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

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

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

Әдетте мұндай схемада бір нәрсе қайталана береді. Команда сөзге таласады, бірақ метрикаларға әсерін тексермейді. Продқа тек барлық тәуекелді көтеретін адамдар көрмеген нұсқа кетеді. Ал релизден кейін бірдеңе бұзылса, бұрынғы нұсқа қол астында тұрмағандықтан, тез кері қайтару мүмкін болмай қалады.

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

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

Командаға қандай рөлдер керек

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

Продакшн үшін әдетте төрт рөл жеткілікті.

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

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

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

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

Кіші командада бір адам екі рөлді қатар атқара алады. Бірақ түзетудің авторы оны өзі тексеріп, өзі продқа шығара алмайды. Әйтпесе команда қайтадан «ауызша келісімге» оралады.

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

Қол жеткізудің қарапайым моделі

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

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

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

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

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

Өзгеріс қадамдары қалай өтеді

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

Жұмыс процесі әдетте бес қадамға сыйып кетеді.

1. Автор өзгерістің қысқа сипаттамасын жазады. Артық сөзсіз бір абзац: қазір не дұрыс жұмыс істемейді, команда қандай мінез-құлық күтеді және жаңа нұсқа жақсы екенін қандай белгіден көруге болады.
2. Команда ескі және жаңа нұсқаларды бірдей мысалдарда салыстырады. Мұнда тек қалыпты сұраныстар емес, дау туғызатындары да керек: толық емес деректер, қатқыл формулировкалар, ережені айналып өту әрекеттері, тым ұзын енгізу.
3. Ревьюер тәуекелдерді тексереді. Ол әлсіз жерлерді іздейді: артық уәделер, жеке деректердің сыртқа шығуы, дұрыс емес тон, жауап форматының бұзылуы, құнның немесе кідірістің өсуі.
4. Сервис иесі шығаруды бекітеді. Ол нұсқаны, релиз күнін, уақытын, бақылау терезесін және релизден кейін метрикаларды кім қадағалайтынын тіркейді.
5. Егер метрикалар төмендесе, команда бірден бұрынғы нұсқаға қайтарады. Откат шегі алдын ала анықталады: эскалация үлесі өсті, бақылау кейстеріндегі дәлдік түсті немесе жауаптар нормадағы ұзындықтан асып кетті.

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

Кәдімгі мысал: қолдау қызметі бот тапсырыс туралы детальдарды өз бетінше толықтырмасын деп промптты өзгертеді. Автор мақсатты бір абзацта сипаттайды, команда 15 диалогты өткізеді, ревьюер қайтарым уәделерімен байланысты тәуекелді байқайды, иесі релизді 16:00-ге қояды да, күн соңына дейін метрикаларды қарайды. Кешке бот жиі қателесе бастаса, ескі нұсқа бірнеше минутта қайтарылады.

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

Өзгерістер журналында не жазу керек

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

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

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

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

Жақсы жазба адамша естіледі: «Сценарий: кіріс өтініштерін жіктеу. Иесі: қолдау жетекшісі. 1.8 -> 1.9 нұсқа. Ереже қостық: егер мәтінде екі тақырып болса, модель негізгісін таңдайды да, екіншісін комментарийге жазады. Себебі: өтініштер жиі қате кезекке түсетін. Маршрутизация қателерінің төмендеуін күтеміз. Релизден кейін 200 диалогты тексереміз. Автор: Алия. Бекітті: Тимур. Күні: 14 мамыр».

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

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

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

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

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

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

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

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

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

Кәдімгі жұмыс жағдайынан мысал

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

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

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

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

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

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

Релиз алдындағы жедел тексеріс

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

Бес нәрсені тексеріңіз:

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

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

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

Осы аптада не істеу керек

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

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

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

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

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

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