LLM-ассистенттің экономикалық тиімділігі: қалай есептеу керек

Нені және не үшін есептейміз

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

Басшылыққа әдетте оңай жауаптар қажет:

• Қашан енгізу өз шығынын ақтайды (горизонт: 3, 6, 12 ай).\
• Тек іске қосу емес, эксплуатация қанша шығын әкелетінін.\
• Қай көрсеткіштер жақсарады: жылдамдық, сапа, команданың жүктемесі, қателер саны.\
• Пилоттың сәттілігі және тоқтатуға себеп болатын жағдайлар.

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

Әсерді ыңғайлы түрде төрт топ метрикаға бөліп қарастырған жөн. Олар көпшілік жағдайда жеткілікті: ішкі қолдау, клиенттік сервис, құжаттармен жұмыс, сатып алулар, HR.

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

Бұл метрикаларды ақшаға аударып, шығындармен (инфрақұрылым, қолдау, жаңартулар) салыстырғанда шынайы ROI пайда болады, «жақсарды» деген сезім ғана емес.

Қайдан бастау: процес таңдау және бастапқы деректер жинау

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

Процесті таңдап, оны нақты жұмыс ағынына тарылтыңыз. Мысалы: ішкі IT‑қолдау (парольді қалпына келтіру, рұқсаттар, типтік ПО қателері), HR (анықтамалар, демалыстар, бейімдеу), бухгалтерия (төлем сауалдары), сатып алулар (жұмыс өтініштері статусы), клиенттерді қолдау.

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

Келесіде «қазір қалай» деректерін сандармен сипаттаңыз. Маңыздысы — тек іс саны емес, кім қатысады (1‑ші линия, 2‑ші линия, менеджер), өңдеуге қанша уақыт кетеді және өтініш қалай аяқталады (шешілді, эскалацияланды, қайталанған сұрақ).

Пилотқа дейін базалық линияне бекітіңіз: бірдей кезеңді алыңыз (мысалы, соңғы 4–8 апта), дереккөздерді анықтаңыз және метрика иесін тағайындаңыз, ол сандарды растайды. Олай болмаған жағдайда кез келген ROI «көзбен бағалау» сияқты көрінеді.

Бастапқы үшін минималды деректер жиынтығы:

• Көлем: аптасына өтініштер және типтік жағдайлардың үлесі.\
• Уақыт: орташа жауап уақыты және шешімге дейінгі толық уақыт.\
• Сапа: қайталанатын өтініштер мен эскалациялардың үлесі.\
• Құн: процестің қатысушыларының сағаттық құны.\
• Дереккөз және деректер иесі: қайдан санаймыз және кім растайды.

Егер деректер аз болса, 100–200 кейстен тұратын шағын таңдау бойынша қолмен есептеуден бастаңыз. Бұл дәлдік туралы әңгімеге қарағанда жылдамырақ және «до/кейін» салыстыруға негіз болады.

Уақыт метрикалары: сағат үнемін қалай есептеу

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

Бастапқы бірліктен бастаңыз: «тапсырмаға кеткен минуттар». Мысалы, ішкі қолдау операторы типтік жауапқа 12 минут жұмсайды, ассистентпен — 8 минут. Үнемдеу — 4 минут. Оны «ай сайын қызметкерге шаққандағы минуттар» деп есептеп, мұндай тапсырмалар нақты санына көбейтіңіз.

Дұрыс өлшеу үшін қалай жүргізу керек

Қысқа өлшеу циклін жасаңыз:

• 2–3 типтік тапсырманы таңдаңыз (нұсқаулық іздеу, хат дайындау, өтініш рәсімдеу).\
• «Қазір қалай» 20–30 орындауды өлшеңіз (таймер, логтар, бақылау таңбалары).\
• Сол сияқты «ассистентпен» сонша орындауды өлшеңіз, сол шарттарда.\
• Ассистент жауабын тексеруге кеткен уақытты бөлек шегеріңіз.\
• Бір ғана сан емес, диапазон ретінде бекітіңіз (мысалы, 3–5 минут).

Уақытты ақшамен есептеу

Ақшалай баға = (үнемделген сағаттар) × (сағаттық құн) × (нағыз босап қалған уақыттың үлесі).

Сағаттық құнды тек жалақыдан емес, салықтар мен үстеме шығындарды қосып алыңыз. Ал босап қалған уақыттың үлесі әдетте 100% болмайды: егер қызметкер айына 10 сағат үнемдесе, оның тек 30–60% ақшалай үнемге айналуы мүмкін. Қалғаны басқа тапсырмаларға жұмсалады.

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

Сапа метрикалары: қалай өлшеу және ақшалай аудару

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

Бастау үшін басшылыққа түсінікті екі көрсеткіш жеткілікті:

• Бір ретте шешілген тапсырмалардың үлесі (қайталанусыз).\
• Соңғы нәтижеға дейінгі орташа түзетулер немесе нақтылау саны.

Қиын аналитикасыз сапаны қалай өлшеу

Қысқа циклдарда және шағын таңдауда деректер жинаңыз, бірақ жүйелі түрде. Қолданылатын әдістер: апта сайын жауаптардың 50–100 таңдамалы тексерісі жауапты қызметкер тарапынан, қосарлы разметка (екі тексеруші тәуелсіз бағалап, айырмашылықтарын салыстыру), регламенттер мен қауіпсіздік үшін эталон сұрақтар.

Пайдаланушы бағасын қосыңыз: CSAT немесе жауаптан кейін бір сұрақ («пайдалы / пайдалы емес»), сонымен қатар ай сайынғы NPS — егер компанияда ол бар болса.

Сапаны ақшалай қалай есептеу

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

(қайта өңделген тапсырмалардың саны) × (қайта өңдеуге кеткен орташа уақыт) × (қатысушының сағаттық құны).

Мысалы, 1 000 өтініштен 300 қайта өңдеуді талап етсе, әрқайсысы орташа 6 минут алса, бұл айына 30 сағат шығынды береді.

Одан әрі сервис нашарлау құнын қосуға болады: шешім қабылдау уақыттарының өсуі, CSAT төмендеуі, эскалациялардың көбеюі. SLA және айыппұлдар болса, сапа метрикаларын оларға байлаңыз. Тіпті формальды айыппұл болмаса да, инцидент бірнеше рөлдің уақытын талап етеді: орындаушы, тексеруші, басшы және пайдаланушының тоқтап қалуы — бұлардың бәрін есептеңіз.

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

Өтініштер саны: жүктеме және самообслуживание әсері

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

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

Минималды метрикалар жиынтығы:

• Тақырыптар бойынша өтініштер (апта/ай бойынша штук).\
• Өзін‑өзі қызмет көрсету үлесі: ассистент адам қатыссыз қанша сұрақты жауып тастады.\
• Эскалация үлесі: қанша диалог адамға берілді.\
• Қайталанған өтініштер: сол пайдаланушы сол тақырып бойынша, мысалы, 7 күн ішінде қайта хабарласты ма.\
• Эскалация қажет болған жағдайда адам тарапынан бірінші жауапқа дейінгі орташа уақыт.

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

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

Салыстыру әділ болу үшін контекстке түзетулер енгізіңіз: маусымдық факторлар (демалыстар, есеп беру кезеңдері), өнім немесе регламент өзгерістері, ірі релиздер мен инциденттер, штат немесе клиент базасының өсуі.

Мысал: GSE.kz тәрізді IT‑қызметте ассистент рұқсаттар мен жұмыс станциялары туралы типтік сұрақтарды жауып, 1‑ші линияның жүктемесін азайтады. Сол уақытта инфраструктура тобына түскен «дұрыс» эскалациялар артуы мүмкін, себебі пайдаланушылар мәселені нақтырақ сипаттай бастайды.

Қателерді азайту: үнем және тәуекелдер есептеу

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

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

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

Негізгі формула:

Үнем = (қате жиілігі_before − қате жиілігі_after) × операциялар саны × бір қателіктің құны.

Мысал: жүйелік интегратордың IT‑қызметінде жабдыққа өтініштер дайындалады. Егер ассистент 2 000 өтініште қате деректер үлесін 6%-дан 3%-ға дейін төмендетсе, ал бір түзетудің орташа бағасы 8 000 теңге болса, айлық үнем:

(0,06 − 0,03) × 2 000 × 8 000 = 480 000 теңге/ай.

Тәуекелдерді: комплаенс пен деректердің ағуына қатысты шығындарды бөлек бағалаңыз. Мұнда консервативті болу жақсы: күтілетін шығынды инциденттің ықтималдығы × шығын мөлшері ретінде есептеп, тек фактілермен дәлелденетінін қосыңыз (инцидент тарихы, аудит талаптары, құқықтық шығындар). Деректер аз болса, тәуекелді неэкономикалық метрика ретінде бекітіп, қорғаныс шараларының (фильтрлер, қолжетімділікті бақылау, тексерулер) құнын шығындарға қосыңыз.

Шығындар: GPU, қолдау, жаңартулар және эксплуатация

Әсерді адал есептеу үшін шығындарды бір‑реттік (внедрение) пен тұрақты (операциялық) деп бөліңіз. Осылай бастапқы және ай сайын қай жерде «пайда жеп тұрғанын» көресіз.

Бір‑реттік шығындар бір жолы пайда болады, бірақ оларды шешімнің өмір сүру кезеңіне (мысалы, 12–24 ай) амортизациялау маңызды — әйтпесе ROI тым нашар көрінуі мүмкін.

Бір‑реттікке әдетте келесілер жатады: интеграциялар (чат, Service Desk, CRM/ERP), рөлдер мен рұқсаттарды баптау; база жинау (тасымалдау, тазалау, разметка), алғашқы промпттар мен сценарийлер; пилоттау және сапа тесттері (қауіпсіздікпен қоса); қызметкерлерді оқыту және пайдалану ережелері.

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

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

Есепке мына заттар кіргеніне көз жеткізіңіз:

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

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

ROI есептеу: қарапайым схема

LLM‑ассистенттің ROI‑ын есептеу үшін нақты сценарийлер жиынтығынан бастаңыз: қай жерде көмектеседі және нені өзгертуі тиіс. Бір сценарий — бір өлшенетін нәтиже. Осылай есеп дау‑дамайға айналмайды.

Көбіне жеткілікті 5 қадам

1. 3–5 қолдану сценариін сипаттаңыз және әрқайсысы бойынша күтілетін өзгерістерді анықтаңыз: уақыт, сапа, өтініштер, қателер. Мысалы: бірінші линия жауаптары, ішкі регламенттер бойынша іздеу, операторға кеңестер.\

2. Базаны бекітіп, пилот бастаңыз: бақылау тобы (ассистентсіз команда бөлімі) немесе бірдей типтік тапсырмаларда до/кейін салыстыру. Өлшеу кезеңін (2–4 апта) және дереккөздерді алдын ала келісіңіз.\

3. Метрикалар бойынша эффектіні есептеп, қосарлауды алып тастаңыз. Егер өтініштер саны азайған болса, уақыт үнемінің бір бөлігі сол азайған көлемде жасырулуы мүмкін. Ыңғайлы логика: алдымен жұмыс көлеміндегі өзгерістерді есептеу (өтініштер), содан кейін қалған өтініштерге кеткен уақытты бағалау.\

4. Барлық шығындарды қосып, ROI, қайтарым мерзімі және үш сценарийді есептеңіз (пессимистік, базалық, оптимистік).

• ROI = (Пайда − Шығындар) / Шығындар\
• Қайтарым мерзімі = Шығындар / Айлық пайда\

5. Тұрақты метрикалар мен иелерін бекітіңіз: аптасына кім мәлімет жинайды, ауытқуларды кім түсіндіреді, сапа үшін кім жауапты.

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

Шығындар тек модель емес екенін ұмытпаңыз: GPU немесе бұлт токендері, қолдау мен жаңартулар, база разметкасы мен тексеру, қауіпсіздік пен мониторинг. Егер шешімді on‑prem орналастырсаңыз, темірдің амортизациясын және эксплуатация командасының жұмыс уақытын бөлек көрсетіңіз.

Сандардың «үйініп кетпеуі» үшін алдын ала қай метрикалар тұрақты болатынын бекітіңіз: 1–2 бизнес‑негізгі және 1–2 операциялық (мысалы, өзгеріссіз қабылданған жауаптар үлесі және эскалациялар деңгейі).

Есепте жиі кездесетін қателер мен тұзақтар

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

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

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

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

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

Қорытынды санды бекітер алдында қысқа тексеру:

• Уақыттың шынымен босап қалғаны расталды ма (жоғалған жоқ па)?\
• Ассистентсіз кезеңмен немесе бақылау тобымен салыстыру бар ма?\
• Жауаптарды тексеру, модерация және база жаңарту шығындары есептелді ме?\
• Қолданудың жеңілдігі салдарынан өтініштер саны өскені тексерілді ме?\
• Жергілікті метрикалармен (команда) компания деңгейіндегі нәтиже сай келе ме?

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

Түйінді тексеру тізімі — есепті басшылыққа беру алдында

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

Тексеру қажет заттар:

• Салыстыру базасы дайын: кезең бекітілген (мысалы, 4–8 апта), дереккөз анық (тикеттер, телефония, CRM, кестелер), және деректердің иесі белгілі.\
• 3–5 негізгі сценарий анықталған және әрқайсысы үшін мақсатты метрикалар бар: уақыт, сапа, самообслуживание үлесі, эскалациялар саны.\
• Шығындар толық есептелген: бір‑реттік (интеграция, баптау, оқыту, іске қосу) және тұрақты (GPU/бұлт, лицензиялар, қолдау, жаңартулар, сапа бақылау, қауіпсіздік).\
• Сапа бақылау ережелері бар: кім тексереді, қаншалықты жиі, қандай қате шегі қабылданады және инцидент болғанда не істеледі. Жеңіл репорт: апта сайын 1–2 көрсеткіш пен бір есеп иесі.\
• Үш сценарий бойынша эффект және окупаемость дайын: пессимистік, базалық, оптимистік. Әрқайсысы үшін негізгі драйверлер анық (минут үнемі, қайталанатын өтініштердің азаюы, қателер төмендеуі) және окупа мерзімі көрсетілген.

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

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

Шынайы мысал: ішкі қолдау үшін ассистент

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

База (пилотқа дейін): айына 1 200 тикет, инженердің тикетке орташа жұмысы 12 минут, 18% қайталанатын өтініштер. Қателер мен қайта өңдеулер шамамен 2% жағдайда кездеседі және кейде параметрлерді қалпына келтіруді талап етеді.

Пилотқа ассистентке қауіпсіз және стандарттауға болатын функциялар ғана берілді:

• Базадан жауаптар және қадамдық нұсқаулар.\
• Жетіспейтін деректерді жинау (ОЖ, клиент нұсқасы, скриншот, қате коды).\
• Күрделі жағдайларда инженерге арналған жауаптың жобасын жасау.\
• Өзгерістер жасаусыз типтік шешімдер бойынша кеңес беру.

Нәтижелерді өлшеу: инженердің тикетке кететін уақыты (до/кейін), адамдарсыз жабылған тикеттер үлесі, қайталанулардың саны және қайта өңдеуге кеткен қателер саны.

4 аптадан кейін: 25% тикет адамның қатысуынсыз жабылды, қалғандарында ассистент орташа 3 минут үнемдеді (деректер жинау мен жобалар арқасында). Қайталанулар 18%‑дан 12%‑ға түсті, ал қайта өңдеуге кететін қателер 2%‑дан 1,2%‑ға дейін төмендеді.

Ақшаға аудару:

Адам қалған тармақта үнемделген уақыт: 900 тикет × 3 минут = 2 700 минут (45 сағат)/ай.

Өзін‑өзі қызмет көрсету: 300 тикет × 12 минут = 3 600 минут (60 сағат)/ай.

Барлығы 105 сағат. Егер инженердің толық сағаты 7 000 теңге болса, бұл 735 000 теңге/ай. Қайталанулар мен қателерді азайту әсерін бөлек қосуға болады, бірақ екі рет есептемеу маңызды.

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

Келесі қадамдар: есептен пилотқа көшу

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

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

Пилот ережесін 4–8 аптаға бекітіңіз: қандай метрикалар жиналады, кім растайды және қаншалықты жиі есеп беріледі. Апталық формат жеткілікті: әр өтініште үнемделген минуттар, бірінші жауаппен шешу үлесі, самообслуживание үлесі, эскалациялар деңгейі және ассистенттің типтік қателері.

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

Инфрақұрылым мәселесін бөлек шешіңіз. Егер локал контур қажет болса, жүктемені бағалаңыз: қанша бір уақытта қолданушы, қандай сұраныстар түрі, GPU қажет пе және өсімге запас керек пе. Мұндай жобаларда жүйелік интегратор мен өндірушінің тәжірибесіне сүйену ыңғайлы: мысалы GSE.kz‑тің сервер инфрақұрылымы мен қолдауы пилот талаптарын нақты техникалық қуаттармен байланыстырады.

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