Адам қатысатын бақылау: сенім шектері және қолмен тексерудің артық жүгінсіз

Қай жерде тұрақты қолмен тексеру процесті бұзады

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

Жүктеме қалыпты болса да кезек ұлғая береді. Күніне 600 сұрауы бар қолдауды елестетіңіз. Бір қызметкер сағатына 25 жауапты мұқият тексере алса, 8 сағатта шамамен 200 тексеру болады. Екі адам шамамен 400-ге жетеді. Қалған 200 алғашқы күннің өзінде кейінге қалады.

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

Мәселе тек уақытта емес. Шығын да трафикпен бірге шамамен сызықты өседі: сұрау көп болса — ауысым көп, тексеруші көп, үстеме шығын да көп. Соның өзінде қате жоғалмайды. Шаршаған қызметкер де оғаш жауапты өткізіп жіберуі немесе оны үйреншікті түрде мақұлдап қоюы мүмкін. Ақырында LLM автоматтандыру болудан қалып, қымбат қара нұсқаға айналады.

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

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

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

Қандай сұрауларды бірден адамға беру керек

Адам қатысатын бақылау схемасын бастаудың ең жақсы жолы — рутинаны клиентке немесе компанияға қате қымбатқа түсетін жағдайлардан бөлу. Мұнда күрделі математика қажет емес. Көп жағдайда сұраудың түрінің өзі-ақ оператор керек пе, соны көрсетіп тұрады.

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

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

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

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

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

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

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

Сенім шектерін күрделі математикасыз қалай қоюға болады

LLM сенім шектерін баптау үшін жеке data science жобасы керек емес. 100-200 соңғы сұрауды тірі ағыннан алып, жауаптарды қарапайым схема бойынша белгілеу жеткілікті: "жіберуге болады", "түзету керек", "жіберуге болмайды". Осындай таңдаманың өзінде-ақ модель қай жерде жиі қателесетінін және қолмен тексеру қай жерде пайдалы емес екенін көруге болады.

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

Одан кейін команда күнде шынымен қарайтын 2-3 сигналды ғана қалдырыңыз.

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

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

Бір жалпы шектің орнына бірден үш аймақ қойған дұрыс:

• автоматты жауап;
• таңдамалы тексеріс;
• адамға міндетті беру.

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

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

Қарапайым маршруттау тәртібі қадам-қадамымен

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

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

Негізгі схема мынадай көрінеді:

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

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

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

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

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

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

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

Сенімнен бөлек қандай тәуекел сигналдарын қарау керек

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

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

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

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

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

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

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

Қолдау ағынындағы мысал сценарий

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

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

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

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

Іс жүзінде маршрутты төрт ережеге жинауға болады:

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

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

Қай қателер қайтадан қолмен тексерудің азабына әкеледі

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

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

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

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

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

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

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

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

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

Іске қоспас бұрынғы жылдам чек-лист

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

Мына нәрселерді тексеріңіз.

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

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

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

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

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

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

Пилот кезінде төрт метрика жеткілікті:

1. адамның қолына өткен сұраулар үлесі;
2. автоматты жауаптан кейінгі қателер үлесі;
3. оператор түзеткен жауаптар үлесі;
4. клиентке жауап беру орташа уақыты.

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

Содан кейін осы схеманың айналасына қорғаныс контурын құрыңыз. Алдымен аудит-логтарды қосыңыз, сонда қай сұрау автоматты өткенін, қайсысы адамға кеткенін және не себеп болғанын көресіз. Сосын PII маскалауын қосыңыз, ИИН, телефондар, карта нөмірлері мен мекенжайлар промпттар мен журналдарға ашық түрде түспесін. Одан кейін бір кілт деңгейінде лимит қойыңыз, бір сервис бүкіл бюджетті жеп қойып, жалпы ағынды бітемесін.

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

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