JSON-схеманың фолбэгі: модельді ауыстырғанда tool-режімді қалай бұзбау керек

Фолбэк кезінде схема қай жерде бұзылады

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

Ең жиі кездесетіні — міндетті өрістің түсіп қалуы. Бірінші модель customer_id, topic және priority береді, ал резервтік модель priority-ды алып тастауға болады деп ойлайды, өйткені ол мәтіннен онсыз да түсінікті. Адам үшін бұл қалыпты. Ал код үшін — қате: құрал толық объект күтеді де, жарты JSON-мен не істерін білмейді.

Өрістің типі де жиі бұзылады. Бір модель өтінім нөмірін "10452" деген жол ретінде қайтарады, екіншісі 10452 деген сан ретінде. Көзге айырмашылық аз. Бірақ ары қарай жүйе ID-ді жол ретінде салыстырса, оны CRM-ге жазса немесе қатаң схемаға ие tool-ға жіберсе, сұрау бірден құлайды. Бұл әсіресе жағымсыз қате: жауап дерлік дұрыс көрінеді, ал пайплайн бәрібір шашырап кетеді.

Үнсіз проблема да бар — артық өрістер. Айталық, схема тек name, phone және city өрістеріне рұқсат етеді, ал резервтік модель comment, confidence немесе provider_note қосады. Кейбір парсерлер мұны жұтып қояды, басқалары бүтін объектіні кері қайтарады. Ең жаманы — артық өрістер әрдайым емес, тек сұраулардың бір бөлігінде ғана пайда болады. Сондықтан команда себепті ұзақ уақыт басқа жақтан іздейді.

Тағы бір мәселе — JSON айналасындағы мәтін. Бір модель таза объект қайтарады, екіншісі мынадай бірдеңе жазады:

{"name":"Алия","phone":"+77010000000"}

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

Әдетте төрт нәрсе бұзылады:

• міндетті өріс түсіп қалады
• өрістің типі өзгереді
• артық өрістер пайда болады
• JSON айналасында кәдімгі мәтін шығады

Сондықтан мәтін сапасының ұқсастығы әлі ештеңе білдірмейді. Tool-режимде әдемі жауап емес, әр қадамда бірдей құрылым маңызды.

Үйлесімді жауап деп нені есептейміз

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

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

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

Минималды келісім

Алдымен келесі қадам жұмыс істеуі үшін қандай өрістердің керек екенін бекітіңіз. Егер құрал customer_id-ді жол ретінде, ал amount-ты сан ретінде күтсе, онда "123" мен 123 — бір нәрсе емес. Мұндайды модельдің еркіне қалдыруға болмайды.

Бос мәндерді де бөлек сипаттаңыз. null, бос жол, бос массив және өрістің мүлде болмауы — әртүрлі нәрсе. Мысалы, email: null «почта жоқ» дегенді білдіруі мүмкін, ал email өрісінің жоқ болуы — модель оны мүлде толтырмағанын және жауапты қате деп санау керегін білдіреді.

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

Минималды келісім төрт сұраққа жауап беруі керек:

• қандай өрістер әрдайым міндетті
• әр өрістің типі қандай
• қандай бос мәндерге рұқсат
• қандай қосымша өрістер өңдеуді бұзбайды

Жиі сәтсіздікке апаратын тағы бір себеп — мәндердің пішімі. Күнді бір форматта ұстаған дұрыс, мысалы YYYY-MM-DD. Ақшаны не кіші бірліктермен, не дөңгелектеудің нақты ережесі бар сан ретінде берген дұрыс. Идентификаторларды араластырмаңыз: егер сізде request_id жол болса, модель кейде сан, кейде UUID бермеуі керек.

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

Негізгі және резервтік модельді қалай таңдау керек

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

Барлық кандидат үшін бірдей тексерулер жиыны болуы керек. Оған қарапайым шақырулар, ұзын схемалар, enum өрістері, ішкі объектілер, бос мәндер және тұжырымы шуылға толы сұраулар кіруі тиіс. Бір промпт, бір tool келісімі, бір валидатор. Әйтпесе сіз модельдерді емес, кездейсоқтықты салыстырасыз.

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

Ұзын схемалар күшті модельдерді де шатастырады. Бір модель 8 өрісті жақсы ұстайды, бірақ 20 өрісте шатасып, ішкі массивтерді бұза бастайды. Екіншісі міндетті өрістерді жақсы толтырады, бірақ enum-ға келгенде сүрініп, рұқсат етілген мәннің орнына мағынасы ұқсас нәрсе қайтарады. Мұны тек нақты tool-шақыруларда көруге болады.

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

Резерв әдетте 2-3 дана жеткілікті. Бір-біріне тым ұқсас үш модельді алуға болмайды. Жақсырақ әртүрлі мінезі бар жинақ құрыңыз: бір резерв дәлдігі жағынан негізгіге жақын, екіншісі жылдамырақ әрі арзанырақ, үшіншісі data residency мен схема тұрақтылығы маңызды сценарийлерге ыңғайлы.

Егер сіз тесттерді OpenAI-үйлесімді шлюз арқылы жүргізсеңіз, іріктеу тезірек болады, өйткені әр провайдер үшін SDK-ны, кодты және промптты ауыстырудың қажеті жоқ. AI Router-де дәл солай: base_url-ды api.airouter.kz-ке ауыстырып, бірдей тексеру топтамасын бірнеше модельге жүргізсеңіз жеткілікті. Бірақ өлшем сол күйі қалады — демода әдемі жауап берген модель емес, сіздің келісімді апталап тосынсыйсыз ұстайтын модель жеңеді.

Tool-режим үшін келісімді қалай беру керек

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

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

Enum-да қатаң болған дұрыс. 3-5 мәннен тұратын тізім әдетте ұзын әрі ұқсас нұсқалардан жақсы жұмыс істейді. Егер кодта бәрібір тек new, pending және closed қалса, waiting, in_progress және on_hold қоспаңыз. Ұқсас мәндер күшті модельдерді де шатастырады.

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

Бөлек түрде код, ID немесе күн күткен жерде еркін мәтінді тыйыңыз. order_id өрісі order_78421 қабылдауы керек, ал «өткен аптадағы клиенттің тапсырысы» дегенді емес. delivery_date бір форматтағы күн болуы керек, «ертең түстен кейін» деген емес.

Практикада қарапайым шектеулер көмектеседі:

• идентификаторлар үшін pattern, minLength және maxLength орнатыңыз
• күндер мен мәртебелер үшін бір формат пен бір мәндер тізімін қалдырыңыз
• сандар үшін шекара белгілі болса, оны көрсетіңіз
• егер код керек болса, жолдарда артық мәтінді тыйыңыз

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

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

Фолбэкті қадам-қадаммен қалай баптау керек

Фолбэкті кез келген қолжетімді модельге ауыстырып жіберетін қарапайым тетік ретінде емес, тексерулер тізбегі ретінде баптаған дұрыс. Егер резервтік модель тез жауап берсе де, өріс құрылымын немесе аргумент пішімін өзгертсе, tool-режим толық істен шыққандағыдай бұзылады.

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

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

Жұмыс тәртібі әдетте мынадай:

1. Базалық модельді эталон кейстерде тексеріп, жарамды жауап пайызын бекітіңіз.
2. Бір резервтік модель қосып, мәтін стилін емес, схема өтуі мен құрал шақыруын салыстырыңыз.
3. Retry-ді тек тайм-аут, желілік қате немесе валидацияның анық сәтсіздігі болғанда қолданыңыз.
4. Келесі резервті бір-бірлеп қосыңыз, сонда қай модель ақау енгізгені көрінеді.
5. Әр ауысудың себебін логқа жазыңыз: тайм-аут, 5xx, жарамсыз JSON, схема бұзылуы, құрал аргументтерінің бос болуы.

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

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

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

Қандай валидаторларды қою керек

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

Сондықтан бірнеше тексеру қабатын қойған сенімдірек. Сонда фолбэк лотереяға айналмайды, ал резервтік модельдерді әр жауапты қолмен тазаламай-ақ ауыстыруға болады.

Минималды тексерулер жиыны

Алдымен парсер таза JSON синтаксисін тексереді. Жауап талданбаса, ары қарай жүруге болмайды. Сосын валидатор схемаға қарайды: типтер, міндетті өрістер, enum-ның рұқсат етілген мәндері. Одан кейін нормализатор даулы өрістерді бір қалыпқа келтіреді. Күндер бір форматқа түседі, сандар санға айналады, ал "" немесе "N/A" сияқты бос жолдар, егер келісім рұқсат етсе, null болады.

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

Мұндай реттеу «бәрі дұрыс па» деген бір жалпы тексеруден жақсы. Ол бірден ақау орнын көрсетеді. Егер модель "amount": "15000" қайтарса, парсер өтеді, схема құлауы мүмкін, ал нормализатор кей жағдайда жауапты сыпайы түзетеді. Ал JSON-ның алдында Дайын, нәтиже міне: тұрса, жауапты бірден кері қайтарған дұрыс, модельдің не айтқысы келгенін жорамалдамай.

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

Тіпті сұрауларды бір API шлюзі арқылы бағыттасаңыз да, валидаторлар бәрібір керек. Шлюз провайдер ауыстыруды жеңілдетеді, бірақ модельдердің схемаға қаншалық дәл бағынатынын жоймайды.

Клиент өтінімі мысалы

Банк бот картаны қайта шығаруға өтінім қабылдайды. Қысқа диалогтан кейін ол backend-ке тек төрт өріс беруі керек: reason, city, contact_time, consent. Мұндай сценарийде tool-режим тек жауап схемаға дәл сәйкескенде ғана өмір сүреді.

Схема қарапайым: reason, city, contact_time — жолдар, consent — boolean. Қалыпты режимде негізгі модель былай жауап береді:

{
  "reason": "карта повреждена",
  "city": "Алматы",
  "contact_time": "после 18:00",
  "consent": true
}

Backend өтінімді бірден жасайды. Болжаудың қажеті жоқ.

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

Резервтік модель мағынаны дұрыс түсінуі мүмкін, бірақ бәрібір келісімді бұзады:

{
  "reason": "карта повреждена",
  "city": "Алматы",
  "contact_time": "после 18:00",
  "consent": "Да"
}

Адам үшін жауап қалыпты көрінеді. Схема үшін — жоқ. consent өрісі boolean болуы керек, ал "Да" жолы типті бұзады.

Мұнда валидаторға қарапайым тәртіп керек:

1. Егер мағына өзгермесе, ұсақ түзетуді қабылдайды. Мысалы, JSON айналасындағы артық мәтінді алып тастайды немесе "true" мәнін true-ге келтіреді.
2. Мән екіұшты болса не бизнес-логика қатаң болса, ол жорамал жасамайды.
3. Егер тип қатесі көрінсе, сол модельден жауапты бір рет дәл сол схема бойынша қайта сұрайды.
4. Егер қайталау да өтпесе, ол шақыруды schema_error деп белгілеп, басқаруды маршрутизаторға береді.

"Да"-ны тек бір жағдайда ғана түзетуге болады: өнімде пайдаланушының келісімі trusted source арқылы онсыз да белгілі болса, ал модель тек осы фактіні сөзбен қайталап тұрса. Ондай дерек көзі болмаса, қайта сұраған дұрыс. Әйтпесе бот өзі келісім жасап алады, ал оны ешкім бермеген.

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

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

Көбіне мәселе фолбэктің өзінде емес, оны қалай қосатынында. Команда арзанырақ модельді көреді, резервке қояды да, міндет шешілді деп ойлайды. Сосын tool-режим көзге дұрыс көрінетін, бірақ схемаға өтпейтін жауаптар бере бастайды.

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

Екінші қате провайдер ауысқанда пайда болады. Командалар API OpenAI-ға ұқсас болса, tool шақыруы да солай жұмыс істейді деп ойлайды. Іс жүзінде ұсақ айырмашылықтар болады: модель аргументтерді қайда қояды, сандарды қалай сериализациялайды, бос өрістермен не істейді, tool call-мен бірге мәтінді қайтара ма. Дәл осы ұсақ нәрселер парсерді бұзады.

Үшінші қате схеманың өзінде жатады. Өріс сипаттамаларын тым жалпы қылады: comment, result, status. Модель көмескі өрісті көріп, пішімді өзі ойлап таба бастайды. Бір провайдер қысқа жол береді, екіншісі объект, үшіншісі бір элементтен тұратын массив қайтарады.

Тағы бір жиі қателік — схемаға тым көп еркіндік беру. Қосымша өрістерге рұқсат қалдырсаңыз, басында бұл ыңғайлы сияқты көрінеді. Шын мәнінде парсердің шекарасы босаңсиды: бүгін модель harmless_note қосады, ертең provider_meta, ал арғы күні кодыңыз күтпеген ішкі объект пайда болады. Tool-режим үшін қатаң келісім көбіне жақсырақ.

Тағы да үш түрлі механизмді шатастырады:

1. Retry керек, егер сол модель сол келісіммен екінші талпыныста дұрыс жауап бере алса.
2. Repair керек, егер жауап дерлік сай келіп, оны қауіпсіз түрде схемаға келтіруге болса.
3. Фолбэк керек, егер қазіргі модель не провайдер бұл сценарийді жалпы нашар ұстаса.

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

Қалыпты тексеріс жалықтырарлық көрінеді, бірақ жұмыс істейді. Негізгі және резервтік модель үшін бөлек жарамды JSON үлесі, дұрыс tool call үлесі, артық өрістер саны, орташа кідіріс және сәтті жауап құны өлшенеді. Егер резерв мәтін бойынша тесттен өтсе де, схемаға келгенде құласа — бұл резерв емес. Бұл тек басқа мінезі бар басқа модель.

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

Релиз алдында модельдің tool шақыра алатынын ғана емес, әр резервтік маршрутта оны бірдей істейтінін де тексеріңіз. Песочницадағы бір сәтті жауап ештеңені дәлелдемейді. Қайталаным керек.

Әр құрал үшін эталон JSON жауабын сақтап жүріңіз. Бұл жай ғана құжаттамадан алынған мысал емес, сіздің схемаңыздан өтетін, барлық міндетті өрістерді қамтитын және даулы жерлерге — күндерге, null-ге, enum-ға, массивтерге, ішкі объектілерге — формат беретін үлгі. Егер құралдың үш типтік сценарийі болса, үш эталон ұстаған дұрыс.

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

Валидаторды бөлек тексеріңіз. Ол қабылдамау себебін инженер 10 секундта логтан түсінетіндей жазуы керек. invalid output емес, нақты не бұзылғаны: customer_id өрісі жоқ, status enum-ға кірмейді, items[2].price number болуы тиіс, string келді.

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

Іске қоспас бұрын әдетте мына тізім жеткілікті:

• әр құралда эталон JSON және схема нұсқасы бар
• негізгі және резервтік модельдер бірдей тест жинағынан өтті
• валидатор нақты қабылдамау себебін қайтарады
• retry және switch ережелері сезімге емес, ашық жазылған
• логтар модельді, провайдерді, құрал атауын және схема нұсқасын сақтайды

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

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

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

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

Бұл кесте әлсіз жерлерді тез көрсетеді. Егер бір құралда үш резерв болса, бірақ тек біреуі enum тексеруінен өтсе, мәселе фолбэктің өзінде емес, нақты «модель + схема» жұбында.

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

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

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

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