Модельдерге бір сұранысқа қатынау саясаты: артық тәуекелсіз

Неге бір сұранысты барлық модельге жібере беруге болмайды

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

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

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

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

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

Сұраныс жіберер алдында әдетте төрт нәрсені тексеру жеткілікті:

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

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

Әр шақыру алдында нені тексеру керек

Сұраныс маршрутын model өрісіне қарап емес, контекст бойынша таңдаған дұрыс. Бірдей промпт демо үшін қауіпсіз, ал prod-та тым тәуекелді болуы мүмкін.

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

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

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

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

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

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

Қолжетімділікті рөлдер бойынша қалай бөлуге болады

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

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

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

Базалық схема мынадай болуы мүмкін:

• кәдімгі рөлдер тек стандартты модельдер жиынын алады
• аналитикасы және күрделі мәтіндері бар рөлдер лимиттері бар 1-2 күштірек модельге қол жеткізеді
• сирек әрі қымбат тапсырмасы бар тар командалар қолжетімділікті келісіммен және мерзіммен алады
• сервис аккаунттар тек алдын ала белгіленген маршрутпен жұмыс істейді

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

Тәжірибеде рөл атауын сұраныста немесе қолданба профилінде тікелей сақтау пайдалы, мысалы support-agent, risk-analyst, ml-team. Сонда ереже бір секундта оқылады. Рөлдердің орнына жеке адамдардың тізімі қолданылса, жүйе ешкім өзгерткісі келмейтін ерекшеліктер кестесіне айналып кетеді.

Дерек түрі мен сақтау орнын қалай ескеру керек

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

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

Тәсіл мынадай болуы мүмкін:

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

Ең жиі қате қарапайым: өрістерді модель жауабынан кейін маскілейді. Бұл тым кеш. Егер промптқа ФИО, ИИН, мекенжай немесе есепшот нөмірі кетсе, мәселе жіберу сәтінде-ақ пайда болды. Ондай өрістерді модельге шақыру алдында маскілеу керек, сұраныс зиянсыз сияқты көрінсе де.

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

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

dev, stage және prod немен айырмашылануы керек

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

Әзірлеуде не қалдыруға болады

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

Тәжірибе қарапайым: әдепкіде черновая тексерістерге 1-2 арзан модельді қалдырып, қымбат және сыртқы нұсқаларды жапқан дұрыс. Командаға күшті модельге қолжетімділік керек болса, оны бөлек және қысқа мерзімге берген жөн.

Қолжетімділік кілттерін де орталар бойынша бөлек ұстаңыз. Тест сервисінде prod-тағыдай API key және сол құқықтар болмауы тиіс. Әйтпесе CI-дегі бір ескі secret немесе base_url-дағы бір қате тест трафигін басқа жерге жіберіп қоюы мүмкін.

Stage-та нені тексеру керек

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

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

Продакшенде нені қатаңдату керек

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

Әдеттегі жұмыс схемасы мынадай көрінеді:

• dev: арзан модельдер, қысқа лимиттер, қысқартылған контекст
• stage: prod-тағыдай маршруттар, бірақ тест деректермен және логтарды толық тексерумен
• prod: бекітілген модельдер тізімі, бөлек кілттер, рөлдер бойынша қатаң лимиттер
• авариялық режим: ақау немесе кідірістің күрт өсуі кезінде қолданылатын алдын ала келісілген ауыстыру

Резервтік маршрутты алдын ала дайындаған дұрыс. Негізгі модель қолжетімсіз болса, жүйе кез келген қолжетімді модельге емес, алдын ала рұқсат етілген алмастыруға ауысуы керек.

Бір сұранысқа арналған саясатты қалай жинауға болады

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

1. Әр сұраныс түрі үшін мақсатты белгілеңіз. Мұнда не маңыздырақ: төмен баға ма, жылдам жауап па, үлкен контекст пе, дәлдік пе, әлде деректің ел ішінде сақталуы ма?
2. Әр сценарий үшін рұқсат етілген модельдерді таңдаңыз. Көбіне негізгі модель, резервтік нұсқа және сезімтал дерекке арналған локальды вариант жеткілікті.
3. Қатты шектеулерді қойыңыз: бір шақыруға ең жоғары баға, максималды таймаут және контекст өлшемі. Бұларсыз тіпті жақсы саясат та нақты жүктемеде тез бұзылады.
4. Рөл, дерек және орта бойынша ережелер қосыңыз. Әзірлеуші dev-та анонимдендірілген деректермен сыртқы модельді сынай алады, бірақ дәл сол сұраныс prod-та жеке өрістермен тек рұқсат етілген маршрутпен өтуі немесе қабылданбауы тиіс.
5. Қабылдамауды түсіндірмесіз қалдырмаңыз. Жүйе нақты себепті қайтаруы керек: "бұл модель production-та қолжетімсіз", "сұраныс баға лимитінен асты", "PII бар деректер үшін тек локальды модельдер рұқсат етіледі".

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

Банк қолдау қызметіне арналған мысал

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

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

Мұндай сценарийде логика әдетте қарапайым:

• келісімшарт нөмірі, ФИО, телефон және басқа өрістер жібермей тұрып маскіленеді
• сұраныс PII және ішкі нұсқаулықтар бар деп белгіленеді
• мұндай сұраныс класына сыртқы модельдерге тыйым салынады
• жауап черновигін рұқсат етілген контур ішіндегі локальды модель жасайды

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

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

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

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

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

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

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

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

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

Егер саясат дайын сияқты көрінсе, өзіңізге үш қарапайым сұрақ қойыңыз:

• сұранысты кім жібереді және ол қай ортада жұмыс істеп тұр
• сұраныстың ішінде қандай дерек бар
• резервтік маршрутқа да сол шектеулер қолданыла ма

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

Іске қоспас бұрын нені тексеру керек

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

Кем дегенде мыналарды тексеріңіз:

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

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

Іске қосқаннан кейін не істеу керек

Іске қосқаннан кейін әдетте екі нәрсе шығады: тым көп қабылдамау және ережені үнсіз айналып өту. Команда бұған үнемі қарамаса, саясат тез арада формалдылыққа айналады. Адамдар бір реттік ерекшелік сұрай бастайды да, шығын қайта өседі.

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

Әр ай сайын бірнеше қырынан қарап отырған пайдалы:

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

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

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

Егер командада бірнеше провайдер және көп маршрут болса, бақылауды бір жерде ұстаған ыңғайлы. Мысалы, AI Router на airouter.kz бір OpenAI-үйлесімді API мекенжайын, аудит-логтарды, PII маскировкасын және Қазақстанда модельдерді локальды хостингтеуді береді. Бұл ережелерді, маршруттарды және шектеулерді бір қабатта ұстап тұруға көмектеседі, әсіресе кейбір сұранысты ел шекарасынан шығаруға болмайтын кезде.

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