Service Desk шақырыстарын LLM арқылы сұрыптау

Неліктен тикеттер дұрыс жіктелмейді және LLM не береді

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

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

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

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

LLM қайда көмектеседі, қайда — жоқ

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

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

Типтік жағдай: пайдаланушы «Басып шығармайды, шұғыл, 3-қабатта» деп жазады да құрылғы мен кабинет көрсетпейді. Оператор «Принтерлер» бөліміне жібереді, кейін мәселе желілік байланыста екені анықталып, тикет «Желі» бөліміне өтеді. LLM алдымен ықтимал санатты ұсына алады және қандай мәлімет жетіспейтінін (мысалы, принтер моделі, ПК атауы, кабинет нөмірі) айта алады. Бұл жіберулер санын азайтады және жұмысты бастау жылдамдығын арттырады, әсіресе үлкен жұмыс станциялары, серверлер мен филиалдар паркын қолдайтын жағдайда.

Санаттар мен ішкі санаттар: жұмыс схемасын қалай жинау керек

Жақсы жіктеу «қолайлы белгілерден» емес, жауапкершіліктен басталады. Санат қарапайым сұраққа жауап беруі тиіс: нақты қай команда тикетті қабылдап, қай процесс бойынша шешеді. Сондықтан схеманы қызметтер каталогына (қайсысын қолдаймыз) және жауапкершілік аймақтарына (кім қолдайды) байлау әлдеқайда тиімді. Әйтпесе автоматты маршрутизация үнемі қателеседі.

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

• Тип: инцидент немесе сұраныс.
• Қызмет: мысалы, «Жұмыс орны», «Почта», «Желі», «Серверлер», «Service Desk қолжетімділіктері».
• Компонент: қызмет ішіндегі нақты анықтама (VPN, принтер, есептік жазба, монитор, RAID және т.б.).
• Басымдық: бизнес ережелері бойынша (әсер мен шұғылдық), «көзіне қарап» емес.

Жиі қателік — ағашты тым терең жасау: 6–8 деңгей, ондаған ұқсас тармақ және бірдей нәрсенің әртүрлі атаулары. Бұл аналитиканы және оқыту деректерін бұзады: әр тармаққа аз мысал түседі, модель шатаса бастайды. Практикалық бағдар — 2–3 деңгей. Әр деңгейдегі атаулар өзара бір-бірін қамтымауы және ішкі жаргонсыз түсінікті болуы керек.

Атау мен ережелер туралы келісімге келу үшін оларды абстракт түрде талқыламаңыз. Әр болашақ санатқа 10–20 нақты тикет алып, оларды бірге талдаңыз: «бұлты қалай атайсыз» және «неге дәл осында орналасады». Сосын ережелерді жаңадан келген адам да түсінетіндей тұжырымдаңыз:

• Санаттың қысқа атауы және оған не кіреді деген бір сөйлем.
• «Кіреді» және «кіремейді» деген бірнеше мысал.
• Белгіленген команда-ұстаушы және резервтік маршрут (егер иесі қолжетімсіз болса).
• Ұқсас санаттар арасында таңдау ережесі: бір шешуші белгі.

«Басқа» санатына қатысты қатаң болыңыз. Уақытша «бос қалта» ретінде «басқа» қалдыруға болады, бірақ «басқа» әдеттегі таңдауға айналмасын. Егер «басқа» үлесі екі апта бойы 3–5%-дан жоғары ұсталса, жаңа санат қосу немесе ережелерді нақтылау керек деген қарапайым қағида ұстаңыз.

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

Service Desk деректері: алдын ала не дайындау керек

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

Әр тикет үшін минималды «шақыру паспорты» пайдалы. Әдетте жеткілікті:

• Тақырып және толық сипаттама (пайдаланушы қалай жазғаны).
• Қосымшалар бойынша қысқа шығару (файл атауы, түрі, 1–2 жол, мазмұнсыз).
• Өтініш беруші (жақсырақ рөл немесе пайдаланушы түрі, ФИО емес).
• Бөлім және орналасқан жер (маршрутизацияға әсер етсе).
• CI немесе сервис (не бұзылды: сервер, жұмыс станциясы, пошта, ВКС және т.б.).
• Байланыс арнасы (портал, пошта, телефон, мессенджер).

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

Алдын ала тазалау және маскирлеу бөлек қадам. Мұнда қатаң болыңыз:

• Жеке деректер (ФИО, телефондар, мекенжайлар, e-mail) маркерлерге ауыстырылсын.
• Құжат, келісімшарт, шот нөмірлері, ИИН/БИН, банктік реквизиттер толығымен жойылсын.
• Құпия мәліметтер (құпиясөздер, кілттер, ішкі IP, жабық жобалардың атаулары) алынып тасталсын немесе жалпылансын.
• Ұзын логтар мен дамптар 3–5 жолға қысқартылады («қандай қате» туралы).
• Көшірмелер мен «бос» шақырыстар (мәтін жоқ) бөлек белгіленсін.

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

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

LLM санатты және «сенімділік» мәнін қалай береді

Автоматты маршрутизация үшін модельден әдетте «ақылды мәтін» емес, Service Desk үшін түсінікті сигналдар қажет. Практикада LLM-ден үш нәрсе қайтаруды сұрау ыңғайлы: санат (қажет болса астысанат), сенімділік бағасы және оператор тез тексере алатын қысқа негіздеу.

Санат маршрут үшін, сенімділік — өңдеу ережелерін таңдау үшін, ал негіздеу — адамға жүйе неге дәл осылай шешім қабылдағанын түсінікті ету үшін керек. Мысалы: «Санат: Қолжетімділіктер -> VPN. Себеп: пайдаланушы "VPN қосылмайды", "аутентификация қатесі" деп жазады».

«Сенімділік» не және оны қалай оқу керек

Сенімділікті әртүрлі көрсетуге болады. Ең бастысы — формат пен мағына туралы алдын ала келісу:

• Кластар бойынша ықтималдық (мысалы, таңдалған санат үшін 0.72).
• Нормаланған 0–1 диапазонында балл, қатты статистикалық интерпретациясыз.
• Деңгейлер: жоғары, орташа, төмен.
• Жиі шатасатын санаттар үшін топ-2 немесе топ-3 нұсқасы мен баллдары.

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

Қашан нақтылау сұрағын қою тиімді

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

• Хабарламада мәселенің нысаны көрсетілмеген (не істемей жатыр: пошта, VPN, принтер).
• Қарама-қайшы белгілер бар (бірден бірнеше жүйе аталған).
• Тикетте тек «жұмыс істемейді», «шұғыл», «көмектесіңіз» деп жазылған.

Мысал: пайдаланушы «Кіру мүмкін емес, қате» деп жазады. Модель «Қолжетімділіктер -> AD» тағайындаудан бұрын сұрауы мүмкін: «Windows-қа, поштаға немесе корпоративтік порталға кіре алмайсыз ба? Қате мәтінін жіберіңіз».

Аудит және қателерді талдау үшін не логтау керек

Service Desk шақырыстарын LLM-пен жіктеуді жақсарту үшін тек соңғы санатты ғана емес, басқа деректерді сақтау маңызды. Трассировкалау үшін минималды жиынтыққа мыналар кіреді: бастапқы мәтін (обезличивание ескеріліп), промпт нұсқасы, сұрау уақыты, модель жауабы (санат, сенімділік, негіздеу), және оператор жұмыстан кейінгі «шындық» (ол не таңдаған және неге). Осылай модель қай жерде астысанаттарды шатастыратынын, қай жерде сенімділік артық екенін және қандай сөздер модельді қате бағыттайтынын табу оңай болады.

Эскалация және маршрутизация ережелері: сенімділік порогтары бойынша шешімдер

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

Сенімділік порогтары: қарапайым «шамшырақ»

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

• Жоғары сенімділік (мысалы, 0.85–1.00): команда мен кезекке автотағайындау, санатты қою, стандартты жауап шаблонын іске қосу.
• Орташа сенімділік (0.60–0.84): санат операторға ұсынылатын әдепкі нұсқа ретінде, бірақ растау немесе басқа таңдау талап етіледі.
• Төмен сенімділік (0.60-тан төмен): тикет бастапқы желінің жалпы дереу қарауына жіберіледі, адам мәліметтерді нақтылап, санатты қолмен таңдайды.

SLA бұзбау үшін тек «алғашқы қадамды» (тикет қайда түседі) өзгертіңіз, мерзімдер мен басымдықтарды өзгертпеңіз. Егер қазір бәрі 1-ші желіден басталса, солай қалсын, бірақ LLM-нен кеңес және автотағайындау тек қауіпсіз сыныптар үшін болсын.

Қауіп бойынша эскалация: бәрін автоматтандыруға болмайды

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

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

Фолбек-сценарийлер тосын жағдайдан сақтайды және пайдаланушылардың ашуын азайтады:

• Модель қолжетімсіз: тикет бұрынғы ережелер бойынша жүреді.
• Бос немесе тым қысқа сипаттама: автоматты жауаппен нақтылау сұралады (не істемей жатыр, қай жерде, қашан), содан кейін қолмен жіктеу.
• Қолайлы санат жоқ: «Басқа» белгіленіп бастапқы талдауға түседі.
• Қатар бірнеше санатта сенімділік жақын: операторға топ-2 көрсетіп, автотағайындамау.
• Бір санатта қателер күрт өссе: сол санатқа автотағайындау уақытша өшіріледі.

Мысал: пайдаланушы «поштаға кіре алмаймын, код сұрайды, код келмейді» деп жазады. Модель «Қолжетімділіктер -> MFA» үшін 0.92 береді. Қауіп ережесі бойынша тикет автоматты түрде орындалмай, 1-ші желіге растама үшін барады, бірақ LLM-ден берілген подсказка және чек-лист көрсетіледі. Бұл қауіпсіздікті сақтай отырып өңдеуді жеделдетеді.

Қадамдық енгізу сценарийі: пилоттан өнімге дейін

Service Desk шақырыстарын LLM-пен жіктеу пайдалы болсын десеңіз, кішкентай, өлшенетін пилотпен бастаңыз. Мақсат — операторларды алмастыру емес, санаттардың сапасын, модель сенімділігінің түсініктілігін және эскалация механизмдерінің жұмысын қауіпсіз тексеру.

Пилот: 2–4 апта, тар периметр

Алдымен не сәттілік екенін келісіңіз: бастапқы өңдеу уақытының қысқаруы, қате тағайындаулар санының азаюы, тикеттің дұрыс топқа тез жетуі. Пилотты бір–екі қызметке немесе кезекке шектеу керек — онда өтініштер типтік және иелері айқын (мысалы, қолжетімділіктер, жұмыс орындары, басып шығару).

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

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

Практикалық маршрут келесідей:

• Пилот мақсатын, шекараны (1–2 қызмет немесе кезек), метрикаларды және мерзімді келісу.
• Санаттар, мысалдар және сенімділік порогтары бойынша эскалация ережелерін дайындау.
• Интеграцияны (API немесе шина) орнату, сұрау форматын және деректер сүзгілерін анықтау.
• Операторға тек кеңес режимін іске қосу, автотағайындаусыз.
• Кейбір тикеттер үшін автотағайындауды қосып, жамылғыны кеңейту.

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

Өнімге шығару: кеңейту және қателерден қорғау

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

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

Іске қосқаннан кейін сапаны бақылау: тексерістер және мониторинг

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

Күнделікті тексерулер: дағдыға айналдыру

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

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

Сапа көрсеткіштері және дрейф белгілері

Метрикаларды SLA сияқты жиі қадағалау керек. 3–5 көрсеткіш жеткілікті, бірақ олар оператор мен басшы үшін түсінікті болуы керек:

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

Дрейфты бөлек бақылаңыз: жаңа шақырыс түрлері пайда болады, қызметтер каталогы өзгереді, маусымдық шыңдар келеді (мысалы, оқу жылының басында парольдер мен қолжетімділіктер бойынша сұраныстар көп). Дрейф көбіне қайта жіберулер мен төмен сенімділіктің өсуі арқылы көрінеді.

Human-in-the-loop-ты байқалмайтындай етуге болады: «Санат қате» батырмасын 1 шертуге ыңғайлы етіңіз, дұрыс нұсқаны таңдап, қысқа «неге» өрісін қосыңыз. Бұл кері байланысты жинауды жеңілдетеді.

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

• порогтарды қайта қарау керек, егер қайта жіберулер өссе, бірақ тексеру таңдама дәлдігі тұрақты болса;
• промптты өзгерту керек, егер бірдей жазылулар бойынша үнемі қателіктер қайталанса;
• санаттарды өзгерту керек, егер жаңа қызмет пайда болса немесе жаңа қолдау командасы құрылса;
• қайта оқыту немесе мысалдарды кеңейту керек, егер дрейф 2–3 аптадан артық жалғасса.

Осылай сапаны басқарылатын процесске айналдырасыз, біржолғы баптаудан айырмай.

Жылдамдыққа әсерін бағалау: «бұрын/кейін» метрикалары

Service Desk шақырыстарын LLM-пен жіктеу көмектесті ме деп түсіну үшін нақты жылдамдық көрсеткіштері керек, тек автокатегория мөлшері емес. Ең адал әдіс — бірдей шарттарда «бұрын/кейін» салыстыру.

Қандай метрикаларды қарау керек

Уақыт көрсеткіштері ең маңызды және көбіне кез келген Service Desk-та бар:

• Тикет жасалғаннан бастап орындаушыға тағайындалғанға дейінгі уақыт (time to assignment)
• Пайдаланушыға алғашқы жауапқа дейінгі уақыт (time to first response)
• Шешімге дейінгі уақыт (time to resolution)
• SLA шеңберінде жабылған тикеттердің үлесі
• Кезектер бойынша таратылым: медиана және 90-процентиль ("құйрықты" көру үшін)

Сосын жүктеме метрикаларын қосыңыз. Олар бірінші желінің жұмысын қаншалықты жеңілдеткенін көрсетеді:

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

Әділ салыстыру және әсерді есептеу

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

Қарапайым үнемдеу формуласы:

«Тикетке үнемделген минут» = (қолмен жіктеу алдындағы орташа уақыт) - (енгізгеннен кейінгі орташа уақыт, тексеру мен түзетулер ескерілген)

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

Мысал: бұрын оператор сұрыптау мен кезек таңдау үшін 2 минут жұмсаса, енгізуден кейін тек 30 секунд растау қалса, үнемдеу — 1,5 минут. Айына 4000 тикет болса, бұл шамамен 100 сағат.

Жанама әсерлерді тіркеу

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

Нақты мысал: тикеттер ағымында қалай жұмыс істейді

Ұйымда бірнеше қолдау желісі бар деп ойлаңыз. Бірінші желі барлық шақырыстарды қабылдап, қарапайым сұрақтарды жабады. Екінші желі сервис бойынша эксперттерді ұстайды, тағы бөлек командалар — жұмыс орындары, желі, бизнес жүйелері (мысалы, 1С/ERP) және ВКС. Бұрын кейбір тикеттер дұрыс емес жерге кетіп жүрді: сұраушы «Басқа» таңдап, оператор асығып жіберіп, тикет топтар арасында жүрді.

Типтік шақырыстар ағыны: қолжетімділіктер (пароль қалпына келтіру, құқық беру, VPN), пошта (хат келмейді, жәшік толған), жұмыс орындары (ПК қосылмайды, принтер, ПО орнату), 1С/ERP (кіру қатесі, "құжат өтпейді") және желі/ВКС (интернет жоқ, баяу, камера/дыбыс істемейді).

Енді LLM-пен жіктеуді қосамыз. Өтініш әдеттегідей келеді: тақырып, сипаттама, кейде қосымша немесе таңдалған сервис. Модель мәтінді оқып, санатты, ішкі санатты және сандық сенімділікті (мысалы, 0.92) ұсынады. Бір уақытта қай командаға тағайындау керек екенін де көрсетеді.

Тикет жолы қалай өтеді

Шешім қабылдау үшін негізгі фактор — сенімділік порогтары:

• 0.85 және жоғары: командаға автотағайындау, оператор тек таңдамалы қарайды
• 0.60–0.85: операторға ұсынылатын подсказка, ол растайды немесе түзетеді
• 0.60-тан төмен: қолмен жіктеу және «қиын» ретінде оқу үшін белгілеу

Практикада қалай көрінеді. Пайдаланушы: «Жаңартудан кейін 1С ашылмайды, "ақпараттық базаға қолжетім жоқ" деп шығады». Модель «Бизнес-жүйелер -> 1С -> Қолжетім қатесі» таңдап, сенімділік 0.88 көрсетеді. Тикет бірден 1С командасына түседі, бірінші желі санатты іздеуге уақыт жұмсамайды.

Басқа мысал: «Кеңсе бөлмесіндегі микрофон істемейді, ертең клиентпен кездесу бар» деп жазылады. Модель «ВКС -> Аудио» ұсынады, бірақ сенімділік 0.72 — мәлімет аз. Операторға подсказка мен қысқа нақтылау сұрақтары көрсетіледі (қай бөлме, қандай қосымша). Ол маршрутизацияны растайды, және тикет «Шиеленіссіз» кезекте тұрып қалмайды.

Тез әсер байқалады: топтар арасындағы қайта жіберулер азаяды, бастапқы тағайындау жылдамдайды, есептерде нақты санаттар көріне бастайды. «90% — Басқа» орнына нақты проблемалар — қолжетімділіктер, пошта немесе 1С модулі деп шығады. Қызмет иелерімен әңгіме де оңайланады: «желі бойынша қайта жіберулер көбейді және сенімділік төмендеді, санаттарды және эскалация ережелерін нақтылайық» деп айтуға болады.

Чек-лист және келесі қадамдар: нәтижені қалай бекіту керек

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

Іске қоспас бұрын автоматты жіктеуді жиі бұзатын нәрселерді тексеріңіз:

• Санаттар мен ішкі санаттар келтірілген, әрқайсысының иесі бар (кім ережені өзгертіп, сапа үшін жауапты).
• Модель сенімділік порогтары бекітілген және мақұлданған: қайсысы автотағайындауға, қайсысы қолмен тексеруге кетеді.
• Фолбек орнатылған: сенімділік төмен немесе тақырып дау тудырса, тикет жалпы бастапқы талдауға түседі және түсінікті SLA болады.
• Шешім логтары қосылған (санат, сенімділік, промпт/модель нұсқасы) және «оператордың араласуы» маркері бар.
• Сапа үшін жауапты адам тағайындалған және қателерді қайта қарау кестесі бар (мысалы, бірінші айда аптасына 2 рет).

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

• LLM-ге жібермес бұрын тикет мәтініндегі жеке деректерді маскировка ету (ФИО, телефондар, ИИН, мекенжайлар, карта нөмірлері).
• Қол жетімділік рөлдері: кім бастапқы мәтінді, кім тек соңғы санатты және сенімділікті көреді.
• Логтарды қанша уақыт сақтау, кім жояды және қай жерде бекіту жүзеге асады.
• Сезімтал тақырыптар үшін ережелер (қаржы, медицина, кадрлар): автоәрекетке тыйым, тек маршрутизация және қолмен тексеру.
• Периодтық таңдамалы тексеру: аптасына 20–30 тикетті тексеріп, саясат пен дұрыстықты бағалау.

30 күндік жоспар алдын ала жазылса тиімді. Күн 1–7: 1–2 танымал санатта пилот және оператордан кері байланыс жинау. Күн 8–14: санат схемасын түзету, порогтарды нақтылау, «қалай емес» мысалдар қосу. Күн 15–30: кезектер бойынша қамтуды кеңейту, команда үйреніп, бақылауды сақтауы үшін.

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

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