Компания ішіндегі модельдер каталогы: статустар мен ережелер

Неге командалар модельді көз жұмып таңдайды

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

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

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

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

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

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

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

Модель карточкасында не болуы керек

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

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

Карточкада бес міндетті блок болғаны дұрыс.

Біріншісі — түсінікті атау және бір ғана мақсат. Техникалық идентификаторды ғана қалдырғаннан гөрі, "Qwen 3 қолдау жауаптарының қарамалары үшін" деп жазған жақсы. Егер мақсат бірнешеу болса, қызметкерлер карточканы әртүрлі түсінеді.

Екіншісі — иесі және тірі байланыс. Бір адамның орнына команда не рөлді көрсеткен дұрыс. Мысалы, "ML платформасы, #llm-help арнасы" деген формат демалысты, жұмыстан кетуді және жобаның ауысуын көтереді.

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

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

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

Қысқа мысал қосқан пайдалы. Мысалы: "Клиент өтініштерін жіктеуге сай. Медициналық кеңес үшін жарамайды. Орташа кідіріс — 1,8 секунд. ИИН енгізу маскалаусыз тыйым салынады". Осындай формат пилотқа дейін сұрақтардың жартысын алып тастайды.

Егер компания бір шлюз арқылы жұмыс істесе, кей өрістерді автоматты түрде тартуға болады. AI Router жағдайында бұл аудит-логтар, кілт деңгейіндегі rate limits, PII маскировка ережелері және дерек ел ішінде қалуы тиіс сценарийлер болуы мүмкін. Бірақ карточка есеп үшін емес. Ол адамдар модельді болжаусыз таңдау үшін керек.

Қандай статустар қажет

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

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

Көп компанияға бес статус жеткілікті:

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

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

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

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

Модельдерге қолжетімділікті қалай бөлуге болады

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

Толық шолу әдетте платформалық командаға, архитекторларға, ИБ-ға және сатып алу мен тәуекелге жауаптыларға керек. Қалғандарына өз класына арналған мақұлданған модельдер витринасы жетеді: чат, жіктеу, іздеу, қысқаша мазмұндау, код.

Практикада рөлдер көп емес. Платформалық команда бүкіл каталогты көреді, статустар мен лимиттерді өзгертеді. Өнім командалары мен ML-инженерлер рұқсат етілген модельдерді көреді және өз жобаларында пилот аша алады. ИБ мен дерек иесі жеке, қаржылық және медициналық деректермен жұмысты келіседі. Сервис иесі немесе CTO баға, сапа және тәуекел тексерілгеннен кейін өндірістік қолжетімділікті ашады.

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

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

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

Егер модельдерге қолжетімділік бір API-шлюз арқылы жүрсе, мұндай ережелерді техникалық тұрғыдан бекіту жеңілірек. AI Router-да бұл үшін әртүрлі кілттер, rate limits, аудит-логтар, PII маскировкасы және дерек ел ішінде қалуы тиіс кезде жергілікті орналастырылған модельдерге бөлек саясаттарды қолдануға болады.

Модельді өмірлік цикл бойынша қалай жүргізу керек

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

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

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

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

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

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

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

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

Каталогты қадамдап қалай іске қосуға болады

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

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

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

Кейін қысқа цикл керек:

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

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

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

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

Бір жұмыс тапсырмасына мысал

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

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

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

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

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

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

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

Жиі жіберілетін қателер

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

Ең жиі мәселе — артық күрделілік. Егер модельде жеті-сегіз статус болса, қызметкерлер оларды ажыратпай қалады. Өмірде әдетте түсінікті күйлер жеткілікті: черновик, пилот, рұқсат етілген, под наблюдением және на выводе.

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

Көбіне каталогты бірдей қателер бұзады:

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

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

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

Қысқа тексеру тізімі

Модельді каталогқа жариялар алдында бес тармақты жылдам тексеру жеткілікті:

• модельдің иесі және келесі қайта қарау күні бар;
• статус қосымша түсіндірмесіз-ақ түсінікті;
• дерек бойынша ережелер бірден көрінеді;
• бюджет пен күтілетін кідіріс ашық жазылған;
• ерекшелік жолы түсінікті және тек хат алмасуда ғана өмір сүрмейді.

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

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

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

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

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

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

Жақсы алғашқы қадам былай көрінеді: 2-3 жиі сценарийге арналған шағын модельдер жиынын таңдау, каталог иесін және бағыттар бойынша иелерді белгілеу, қолжетімділік, аудит және лимиттерді бір контурда жинау, ал 30 күннен кейін қысқа ревизия өткізу. Бір айдың ішінде әдетте қай карточканы ешкім ашпайтыны, қай статустар шатастыратыны және қай жерде командалар бәрібір каталогты айналып өтетіні көрінеді.

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

Дереккөздер көп болса, бірыңғай шлюз шынымен көмектеседі. Мысалы, airouter.kz сайтындағы AI Router бір OpenAI-үйлесімді endpoint арқылы әртүрлі модельдерге қол жеткізуге мүмкіндік береді, әрі аудит-логтарды, кілт деңгейіндегі rate limits, PII маскировкасын және деректерді Қазақстан ішінде сақтау сценарийлерін ұстауға көмектеседі. Каталог үшін бұл өзінше ғана емес, ережелерді құжатта емес, инфрақұрылымның өзінде де бекітуге болатыны үшін ыңғайлы.

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