ЖИ-пилоттарының 88%-ы продакшенге жетпейді. Модельдің «қолы» пайда болғанда нағыз мәселе басталады

RD media дайындаған

ЖИ-агент үшін қарапайым тапсырманы елестетейік: корпоративтік қосымшадағы қатені түзету. Агент қажетті файлды табады, түзету жазады, тесттерді іске қосады — қате шығады. Тағы бір рет байқайды. Қайтадан қате. Тәсілін өзгертеді. Тесттерді қайта іске қосады. Тағы бір әрекет. Шектеу болмаса, агент итерацияларды шексіз жалғастыра береді. Дүйсенбіде әзірлеуші түзетілмеген қатені ғана емес, токендерге арналған шотты да көреді.

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

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

Prompt engineering-нен agent engineering-ге қарай

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

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

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


Harness дегеніміз не

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

Ыңғайлы метафора: модель — қозғалтқыш, harness — көлік. Қозғалтқыш қуат тудырады. Бірақ қозғалтқыштың өзінде тежегіш, руль, қауіпсіздік белдігі және жылдамдық шектеуіші жоқ. LLM-мен де жағдай осыған ұқсас.

Модель файлды жою командасын тамаша генерациялай алады. Бірақ «агенттің оны орындауға құқығы бар ма?» деген сұрақты жүйенің басқа деңгейі шешуі керек.

88% қайдан пайда болды

Мұнда маңызды жайт бар. 88% көрсеткіші жасанды интеллект (ЖИ) агенттеріне емес, корпоративтік ЖИ-пилоттарға қатысты айтылады. IDC мен Lenovo 2025 жылғы зерттеуінде 33 ЖИ proof-of-concept жобасының ішінен орта есеппен тек төртеуі ғана production кезеңіне жетеді деген бағаны келтірді. Басқаша айтқанда, шамамен 88% пилоттан нақты енгізуге көшпейді.

Авторлар мұны дәл тұжырымдаған: мәселе тек capability — технологияның мүмкіндігінде емес. Ол readiness — ұйымның дайындығында жатыр. Бұл агенттер үшін ерекше маңызды. Себебі «модель мұны жасай алады» мен «модельге мұны жасауға рұқсат беруге болады» дегеннің арасында тұтас инженерлік қабат бар.

Production алдында агентке қоятын жеті сұрақ

Мұны ресми «жеті қабатты стандарт» деп санаудың қажеті жоқ. Бұл практикалық тексеру: осы сұрақтарға жауап болмаса, агентке нақты құқық беру әлі ерте.

1. Агентке нені істеуге рұқсат етілген?

Құжатты оқу мен құжатты жою — екі бөлек әрекет. Баланс көру мен төлем жасау арасындағы айырмашылық одан да үлкен. Әрекеттердің рұқсат деңгейлері әртүрлі болуы керек: толық автоматтыдан бастап адам растауын талап ететінге дейін. Мұнда least privilege принципі модель ақылдылығынан маңызды: агент нақты тапсырма үшін қажетті ең аз құқық жинағын ғана алуы тиіс.

2. Нәтижені кім тексереді?

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

Себебі қарапайым: LLM-as-a-judge де қателесуі және жүйелі bias көрсетуі мүмкін. 2026 жылы жарияланған JudgeBiasBench зерттеуі LLM бағалауларының жауаптың релевантты емес сипаттамаларына — мысалы, ұзындығына, орналасуына немесе стиліне — тәуелді болатынын көрсетті. Сондықтан «агент өзін-өзі тексерді» дегені тәуелсіз верификациямен бірдей емес.

3. Агент нені есте сақтайды?

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

Мыналарды түсіну қажет: қазіргі контекстте не бар, қадамдар аралығында не сақталады, сессиялар аралығында не сақталады, нені жоюға болады, нені жоғалтуға болмайды.

4. Агентке нені істеуге тыйым салынған?

Тыйым «production-ды жоймау» деген сөз тіркесіне сыймауы керек. Техникалық саясат қажет: қандай файлдарға тыйым салынған, қандай API-лар қолжетімсіз, қандай дерекқорлар тек оқуға арналған, қандай командаларды автоматты түрде ешқашан орындауға болмайды. Тыйым жүйе деңгейінде болуы тиіс, тек промпт мәтінінде емес. Себебі мәтінде prompt injection болуы мүмкін.

5. Агенттің әрекеттерін қалпына келтіруге бола ма?

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

6. Нақты тапсырма үшін қандай модель қажет?

Әрбір операцияны ең қымбат әрі қуатты модельге беру қажет емес. Тикетті классификациялау, құжаттан өріс алу және архитектуралық шешім қабылдау — мүлдем әртүрлі деңгейдегі тапсырмалар. Сондықтан production-агент экономикалық жүйе де болып табылады.

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

7. Жүйе өз қателерінен үйрене ме?

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

Claude Code мәселені іс жүзінде көрсетті

Бұл тек теориялық құрылым емес. 2026 жылдың сәуірінде Anthropic компаниясы Claude Code сапасына қатысты мәселелердің постмортемін жариялады. Мұнда модельдің өзі жалғыз себеп болған жоқ.

Бірнеше апта бойы сапа модельдің айналасындағы қабатта болған өзгерістер салдарынан төмендеп келді. 4-ші наурызда команда интерфейс кідірісін азайту үшін reasoning деңгейін high-тен medium-ге дейін түсірді. 26-наурызда кэшті тазарту механизміндегі қате көзделген сирек интервалдың орнына пайымдау тарихын әр қадамда жойып отырды. 16-сәуірде жауаптардың артық егжей-тегжейлілігін азайтуға бағытталған жүйелік промпт өзгерісі де тапсырманы орындау сапасына әсер етті. Мәселелер 20-сәуірге дейін түзетілді.

Модель жалғыз айнымалы болған жоқ. Harness-тегі өзгерістер соңғы жасанды интеллект (ЖИ) өнімінің тәртібін өзгертіп отырды. Бұл, сірә, ең маңызды сабақ. Claude Code, ChatGPT немесе корпоративтік агентпен жұмыс істегенде пайдаланушы «таза модельмен» емес, жүйемен әрекеттеседі.

Реттеуші — harness құрудың басты себебі емес

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

Мысалы, Колорадода бастапқы AI Act күшіне енбей жатып күшін жойды және 2027 жылы қолданысқа енетін жаңа реттеумен ауыстырылды. ЕО-да да жағдай презентацияларда жиі жазылғаннан күрделірек: AI Act-тың әртүрлі талаптары әртүрлі мерзімдерде қолданысқа енеді, ал high-risk жүйелер үшін жекелеген міндеттемелер 2027 және 2028 жылдарға жатады.

«Жақындап келе жатқан реттеу салдарынан harness құру керек» деген тезис тым жеңілдетілген. Одан әлдеқайда қарапайым себеп бар. Егер агенттің банктік деректерге, дербес деректерге немесе production инфрақұрылымына қолжетімділігі болса, бақылау келесі regulatory deadline күніне қарамастан қажет. Реттеуші мерзімді өзгерте алады. Бірақ агенттің дерекқорыңызды жою құқығы бұдан қауіпсіз бола қоймайды.

Бірақ harness-ті де артық инженерлеуге болады

Керісінше мәселе де бар. Егер ішкі хакатон үшін банктік шоттармен жұмыс істейтін агентке арналғандай harness құрылса, эксперимент эксперимент болудан қалады. Әр қадам растауды талап етеді. Әр әрекет — қосымша тексеруді. Әр құрал — жеке келісуді.

Қауіпсіздік тәуекелге сай болуы керек. Ішкі құжаттарды сұрыптайтын агент пен production-дағы деректерді өзгертетін агентке бірдей деңгейдегі бақылау қажет емес.

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

Міне, осы жерде басты сұрақ өзгереді

Чат-боттар дәуірінде біз: «Қай модель ақылдырақ?» деп сұрайтынбыз.

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

Модель маңызды, бірақ ол жүйенің бәрі емес. Harness дегеніміз — сенімді мүмкін ететін дәл сол нәрсе. Сондықтан ЖИ-пилоттан production-ға өту ақылдырақ модель таңдау емес. Бұл model engineering-тен system engineering-ке өту. Себебі агентке корпоративтік базаға қолжетімділік беру техникалық тұрғыда қарапайым. Оған осы қолжетімділікті шынымен сеніп тапсыруға болатынын дәлелдеу қиынырақ.

Дереккөздер:

• IDC / Lenovo — корпоративтік AI adoption зерттеуі және production-ға жетпейтін AI proof-of-concepts көрсеткішінің 88% болуы.

• Anthropic — Claude Code сапасына қатысты мәселелердің постмортемі, 2026 жылдың сәуірі.

• Zhou et al. — JudgeBiasBench, LLM-as-a-judge жүйелік bias-ын зерттеу, 2026.

• Colorado SB 26-189 — бастапқы Colorado AI Act заңының күшін жойып, оның орнына қабылданды.

• European Commission — EU AI Act қолданысқа енетін мерзімдерді жаңартты.

REAL DIGITAL

#ЖИ #AIAgents #Киберқауіпсіздік #ЦифрлықҚазақстан