Клиент шағымдарын жіктеу: ережелер мен LLM-ді қалай үйлестіруге болады

Неге қарапайым схема тез бұзылады

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

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

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

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

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

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

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

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

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

Жүйе әр өтініш бойынша нені шешеді

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

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

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

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

Сосын жүйе SLA қояды. Барлығына бір мерзім мұнда жүрмейді. Шұғылдық тәуекелге, сомаға, арнаға және клиент түріне байланысты. 500 теңгелік қосарланған есептен шығару туралы хабарлама мен 480 000 теңгелік операцияға шағым бірдей күтпеуі керек. Қоғамдық арнадан келген шағым немесе ірі B2B-клиенттің өтініші де көбіне тезірек жауапты талап етеді.

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

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

Қай жерде ережені қалдыру керек, қай жерде LLM-ге сөз беру керек

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

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

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

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

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

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

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

Схеманы қадамдап қалай жинау керек

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

Әуелі категорияларды тарылтыңыз

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

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

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

Сосын LLM қосыңыз

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

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

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

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

Сенімсіздікпен және жаңа тақырыптармен қалай жұмыс істеу керек

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

Бір шек емес, екі шек

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

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

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

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

Жаңа тақырыптарды қалай ұстап қалуға болады

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

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

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

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

Мысал: қосарланған есептен шығару туралы шағым

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

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

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

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

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

Мұндай маршрут «бір шағым — бір категория» схемасынан жақсы. Биллинг тобы өтінішті бірден алады, ал сервис жетекшісі клиенттің наразылыққа екінші себебі бар екенін көреді.

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

Дәл осындай шағымдарда ереже мен LLM байланысы ең жақсы жұмыс істейді: ереже ақшамен байланысты тәуекелді тез ұстайды, ал модель кезек пен SLA-ға әсер ететін екінші мәселе қабатын байқайды.

Қымбатқа түсетін қателер

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

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

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

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

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

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

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

Іске қосар алдында жылдам тексеру

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

SLA-ға да солай. «Тез жауап береміз» деген тұжырым жарамайды. Төлем бұғатталуына шағым үшін мерзім 15 минут болуы мүмкін, даулы қайтарым үшін — 2 сағат, сервис бойынша жалпы шағым үшін — бір жұмыс күні. Мерзімдер ашық көрсетілсе, жүйе кездейсоқтық болмай қалады.

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

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

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

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

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

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

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

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

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

Метрикаларды да бірден бөлек ұстаған жақсы. Кезектегі қате мен SLA-дағы қате — бір нәрсе емес. Егер алаяқтық туралы шағым «жалпы сұрақтар» бөліміне түссе, бұл бір проблема. Егер тақырып дұрыс танылса, бірақ өтініш шұғыл басымдық алмаса, бұл басқа мәселе. Осы промахтарды бөлек есептегенде, команда себепті тез табады: ережедегі ақау ма, SLA сипаттамасы әлсіз бе, әлде модель жауабы нашар ма.

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

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

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