AI-процестегі қаралама мен әрекет: қалай шекара қою керек

Неліктен модельге жазбаларды өзі өзгертуге болмайды

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

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

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

Сандарда қауіп бұдан да жоғары. Егер модель клиенттің лимитін өзі өзгертсе, бір сандағы қате ақшаға немесе қызметке қолжетімділікке тікелей әсер етеді. 100 000 бен 10 000-ды шатастыру ойлағаннан оңай. Әсіресе деректің бір бөлігі хат алмасудан, бір бөлігі CRM-нен келіп, сұрау асығыс жазылған кезде.

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

Сондықтан модельге қолдануға емес, ұсынуға құқық берген дұрыс. Мұндай шекара жұмысты ойлағандай тежемейді. Керісінше, ол қымбат қателерді олар өтінім статусына, клиент лимитіне немесе операциялар тарихына жетпей тұрып тоқтатады.

Команда AI Router сияқты бірыңғай LLM-шлюз арқылы жұмыс істесе де, ереже өзгермейді. Модельдерге ыңғайлы қолжетімділік өндірісте жазбаны өзгертуге де ыңғайлы қолжетімділік дегенді білдірмеуі керек.

Қаралама қай жерде аяқталып, әрекет қай жерде басталады

Шекара модель "бір нәрсені түсінген" жерде емес, жүйе бір нәрсені жазуға дайындалған жерде өтеді. AI хатты, чатты немесе өтінімді оқып, жауап, статус немесе лимит нұсқасын ұсынғанша, бұл — қаралама. Деректер CRM, ERP, биллингке немесе ішкі реестрге жіберілген сәттен бастап, бұл — әрекет.

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

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

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

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

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

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

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

Потокты екі қадаммен қалай құруға болады

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

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

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

Мұндай экран жиі болатын қателікті азайтады: қызметкер айырманы қойындылар арқылы іздемейді және әрекетті көз жұмып растамайды. Ол бірден не өзгеретінін және не үшін өзгеретінін көреді.

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

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

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

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

Қандай әрекеттерді модельге тікелей беруге болмайды

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

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

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

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

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

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

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

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

Өтінім статусымен мысал

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

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

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

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

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

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

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

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

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

Командалар көбіне қай жерде қателеседі

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

Бірінші жиі қате — растауды ұзын формаға жасыру. Оператор экранды сырғытып, таныс өрістерді көреді де, төмендегі бір батырманы баса салады. Ресми түрде адам қадамды растады. Іс жүзінде ол AI статусты, соманы немесе алушыны өзгертуді ұсынғанын байқамай қалуы мүмкін.

Екінші қате одан да қауіпті: модельге жауаптан кейін бірден жүйеде әдіс шақыруға құқық беріледі. Егер құрал шақыруы update_status, change_limit немесе create_record-ты бөлек тексеру экранысыз іске қоссса, қаралама әлдеқашан әрекетке айналып кетеді. Онда prompt-тегі кез келген дәлсіздік базаға жазба болып түседі.

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

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

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

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

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

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

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

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

Іске қоспас бұрын қысқа тізімді қарап шығу пайдалы:

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

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

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

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

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

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

Кімді растатады және журналда нені сақтау керек

Өзгерісті промпт жазған адам емес, операциялық шешім қабылдауға құқығы бар рөл растауы керек. Қарапайым процесте бұл оператор болуы мүмкін. Ал сезімталырақ жерде — тимлид, risk-менеджер немесе бэк-офис қызметкері. Модель қаралама дайындайды, адам оны жүйеге жіберу-жібермеуін шешеді.

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

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

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

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

Растау белгісін адамға немесе рөлі түсінікті сервиске байлаған жөн. "Өзгеріс қолданылды" деген жазба іс жүзінде пайдасыз. Оның орнына: "расталды: қызметкер id 4821, рөл: екінші деңгей оператор" сияқты жазба керек.

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

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

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

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

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

Келесі қадам — модель жауабы мен жүйедегі өзгеріс арасына қарапайым шекара қою. Модель тек әрекеттің қараламасын және қысқа түсіндірмені дайындасын. Модель жауабына автожіберу емес, бөлек "Растау" батырмасын қосыңыз. Практикаңыздағы бірнеше нақты кейсті қолмен өткізіңіз. Содан кейін журналдың әр өзгерісті ешбір үзіліссіз жазатынын тексеріңіз. Тек содан кейін ғана сценарийді тірі ағынға қосыңыз.

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

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

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

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