Жоспарлаушы агент пе, әлде сценарий бойынша ма: қалай таңдау керек

Неге бір тәсіл барлық міндетке сай келмейді

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

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

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

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

Жоспарлау жауапқа апарар жолдың өзі белгісіз болғанда көмектеседі. Мысалы, қызметкер CRM, ERP және білім базасындағы шарт мәтіні арасындағы айырмашылықтың себебін табуды сұрайды. Мұнда агентке міндетті қадамдарға бөлу, дереккөздерді таңдау, нұсқаларды салыстыру және керек болса, нақтылау сұрағын қою қажет. LLM көмегімен құжаттардан іздеу дәл осындай жағдайда жиі ұтады.

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

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

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

Қолдау: сценарий қашан жақсырақ

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

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

Қатаң сценарий агентке ережелер алдын ала белгілі болған жерде жақсы жұмыс істейді. Клиент: «Тапсырысым қайда?» — деп сұрайды. Бот нөмірді сұрайды, статус жүйесіне өтеді, рұқсат етілген жауаптардың бірін ғана қайтарады, ал дерек табылмаса, әңгімені адамға береді. Мұндай жол жалықтырғыш көрінуі мүмкін, бірақ қолдауда бұл артықшылық.

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

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

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

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

Іздеу: агентке өз жоспары керек болатын жер

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

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

Басқа көрініс мынадай сұрақта туады: «клиент деректерін пилот үшін сыртқы LLM-ге жіберуге бола ма?» Мұнда сөз бойынша іздеу аздық етеді. Агентке сұрақты бөліктерге бөлу керек: қандай деректер айтылып тұр, PII бойынша ішкі ереже бар ма, қауіпсіздік саясатында не жазылған, деректерді ел ішінде сақтау талабына шектеу бар ма. Қазақстан мен Орталық Азиядағы командалар үшін бұл жиі кездесетін мысал: білім базасын ғана емес, data residency, логтар және деректерді маскалау жөніндегі ішкі талаптарды да тексеру керек.

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

Сценарий жеткілікті болатын кез

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

Жауаптан нені тексеру керек

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

Ішкі процестер: орта жол керек жер

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

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

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

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

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

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

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

Қадам-қадаммен қалай таңдау керек

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

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

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

Әдетте көрініс тез айқындалады. Егер сұраулардың 80%-ы бір схема бойынша өтсе, күрделі агент құрудың қажеті жоқ. Сценарий бірқалыпты нәтиже береді, оны тексеру оңайырақ, ал қатені табу жеңілірек.

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

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

Бір сұрау, екі жұмыс тәсілі

Бір клиент сұрауы екі түрлі жолмен өтуі мүмкін. «Менің қайтарымым қайда және неге сома басқа?» деген хабарлама мұны жақсы көрсетеді, өйткені мұнда бірден екі міндет бар: статусты табу және ақша айырмасын түсіндіру.

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

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

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

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

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

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

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

Командалар жиі қай жерде қателеседі

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

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

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

Тағы бір жиі қате — агентке тым көп құрал ашу. Ол білім базасын, CRM-ді, поштаны, файлдардан іздеуді және ішкі API-лерді бірден көреді, ал тапсырма үшін екі-ақ қадам жеткілікті. Сонда ол уақыт пен токенді артық әрекеттерге жұмсайды.

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

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

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

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

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

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

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

Іске қоспай тұрып бес нәрсені тексерген пайдалы. Агент қашан өзі жауап бере алатынын, ал қашан диалогты қызметкерге беру керегін болжап алмауы тиіс. Команда алдын ала рұқсат етілген деректер мен әрекеттер тізімін анықтайды. Әр сұрау бойынша түсінікті із қалуы керек: агент қандай қадамдар жасады, қандай дереккөздерге жүгінді және пайдаланушыға қандай жауап көрсетті. Қате деректерді бұзбауы тиіс, сондықтан CRM-дегі, клиент карточкасындағы немесе өтінім статусындағы кез келген өзгерісті қолмен растаған дұрыс. Ал іске қосар алдында бір типтік сұраудың бағасын да есептеп шыққан жөн: база іздеуі, қайталама шақырулар, ұзын контекст және ретрайлар соның ішінде.

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

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

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

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

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

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

Екі тәсілді бірдей таңдамада тексеру ең ыңғайлы:

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

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

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

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