AI-агенттерге арналған қадам лимиттері және продакшндағы шығынды бақылау

Неге шығын көзге түспей өседі

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

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

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

Әдетте шығынды төрт нәрсе үдетеді:

• таймауттан кейінгі қайталау шақыруы
• бірдей параметрлері бар сол бір tool call
• хабарламалар тарихы мен құрал нәтижелері өскен контекст
• агенттің тағы да көруге себеп деп қабылдайтын құрал қатесі

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

Құрал қатесі көбіне дәл осындай циклді іске қосады. Айталық, CRM 500 қайтарды, ал агент техникалық мәтін алып, түсінікті статус көрмеді. Ол сұранысты қайта құрып, сол бір құралды тағы шақырады да, қайтадан қате алады. Пайдаланушыға бұл бір тапсырма сияқты көрінеді, ал биллингте шақырулар сериясы жиналып қалады.

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

Релизге дейін нені шектеу керек

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

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

Бастағанда мына бес нәрсені шектеу орынды:

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

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

Қолдау сценарийлері үшін көбіне мынадай бастама жеткілікті: бір диалогқа 8 қадамға дейін, база бойынша іздеуге 2 шақырудан артық емес, бір тапсырмаға 1 CRM шақыруы, қадам таймауты 15 секунд, сессия таймауты 2 минут және желілік қате үшін 2 қайталаудан артық емес. Егер агент шекке сыймаса, ол тоқтап, түсінікті статус қайтаруы керек: оператор керек, дерек жетіспейді немесе құрал қолжетімсіз.

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

Сессия бюджеті және қадам лимиттері

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

Тіпті күрделі тапсырмалар үшін де қатаң шек керек. Көптеген жұмыс сценарийлері үшін 6–8 қадам жетеді: қысқа жоспар, бірнеше құрал шақыруы, жауапты тексеру және финал хабарлама. Егер агент лимитке тірелсе, ол ойдан құрап, тағы тырыспауы керек. Ол анық статуспен аяқталсын: не табылды, не жетіспейді және пайдаланушыдан нені нақтылаған дұрыс.

Соңғы жауапқа орын қалдырыңыз. Жақсы ереже — сессияның соңына дейін бюджеттің 15–20%-ын қозғамай сақтау. Әйтпесе агент барын іздеу мен аралық әрекеттерге жұмсап, пайдаланушыға үзік немесе бос жауап беруі мүмкін.

Тәжірибеде бюджетті бөліктерге бөлген ыңғайлы. Аз бөлігі жоспарлауға кетеді, негізгі бөлігі құралдарды шақыруға жұмсалады, тағы бір бөлігі финал жауап пен бір қауіпсіз қайталау әрекетіне резерв болып қалады. 20% жоспарлауға, 60% құралдарға және 20% резервке бөлу сияқты қарапайым схема да жақсы жұмыс істейді.

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

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

Ойланбай орындалатын тоқтау ережелері

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

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

Жұмысқа жарайтын минимум мынадай:

• екі бірдей қате қатарынан — стоп
• бірдей аргументтермен сол бір құралды қайта шақыру — стоп
• бюджеттің қалдығы тағы бір қалыпты қадамға жетпейді — стоп
• құрал лимиттен ұзақ үнсіз қалды — қауіпсіз жауап қайтару
• бос нәтиже бірнеше рет қайталанды — сессияны аяқтау

Бюджетке қатысты ереже жиі ұмытылады. Команда қадам лимитін қояды, бірақ тағы бір шақыруға ақша жете ме, тексермейді. Егер қолыңызда 5 цент қалса, ал осы модель мен құралмен орташа қадам 7 цент тұрса, жаңа сұраныс жіберудің қажеті жоқ. Сессия соған дейін аяқталуы керек.

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

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

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

Қайталауды артық дубликатсыз қалай баптау керек

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

Әдетте қарапайым ереже жеткілікті: тек қысқа инфрақұрылымдық ақауға ұқсас қателерді қайталаңыз. Бұлар — 429, 5xx жауаптар және таймаут немесе байланыстың үзілуі сияқты қысқа желілік мәселелер. Қалған жағдайларда бірден тоқтап, қатені логқа немесе операторға жіберген дұрыс.

Егер мәселе деректердің өзінде болса, сұранысты қайталамаңыз. Бұрыс JSON, қате схема, жоқ өріс, 401, 403, 404, құралдың қате аргументтері — мұның бәрі екінші әрекетпен түзелмейді. Мұнда қайталау тек сессия бюджетін үлкейтеді.

Қалыпты баптау көбіне мынадай: бір сұранысқа 2–3 әрекеттен артық емес, олардың арасындағы кідіріс 1, 2 және 4 секунд схемасы бойынша өседі, ал кідіріске аздап кездейсоқ ауытқу қосылады. Соңғы сәтсіздіктен кейін агент қадамды аяқтайды, шеңбермен айналмайды.

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

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

Қолдаудан мысал

Клиент чатқа: "Тапсырысым қайда?" деп жазады. Бот үш нәрсе істеуі керек: тапсырысты табу, статусты CRM-де тексеру және адамға түсінікті мәтінмен жауап беру. Қағаз жүзінде бұл 5–6 қадам, әрі сценарий арзан сияқты көрінеді.

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

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

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

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

Іске қосар алдында нені тексеру керек

Релиз алдында сценарийді орташа жауап бағасына ғана қарамай, чек-лист сияқты тексеріп шыққан пайдалы.

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

Одан кейін төрт нәрсені тексеріңіз:

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

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

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

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

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

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

Бастапқы жинақ әдетте қарапайым: бір сессияға 4–6 қадам, тек желілік ақаулар үшін 1–2 рет қайталау, ақшада немесе токенде бекітілген бюджет, сол бір құралды қайта шақырғаннан кейін тоқтау және соңғы 2 қадамда агент жауапқа жақындай алмаса, тоқтау.

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

Әрі қарай орташа көрсеткішке емес, нақты сессиялардың логтарына қараңыз. Егер сұраныстардың 90%-ы 3 қадамға сыятын болса, лимитті себепсіз 10 етпеңіз. Ондай артық қор әдетте қымбат ілмектерге айналады. Алдымен рамканы тартыңыз, кейін шынымен керек жерінде ғана кеңейтіңіз.