LLM қосымшалары үшін SLO: бизнес мақсаттарына сай қалай есептеу керек

Метрикалар қай жерде өтірік айта бастайды

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

Бірінші тұзақ өте қарапайым: команда жүйеге ыңғайлы нәрсені өлшейді, ал сервисте маңыздысын емес. Жауап уақытының графигі бот сұрақты түсінді ме, керек форматты берді ме және адамды қайта-қайта айналдырып жібермеді ме — соны көрсетпейді. Егер 100 жауаптың 92-сі тез келіп, 8-і төлемді не өтінім беруді бұзса, дашборд тыныш көрінсе де, сервис бизнеске зиян келтіріп жатыр.

Көбіне өтірік айтатыны — орташа кідіріс. 200 мс-та бір жауап және 20 секундтық бір таймаут орташа мәнді «жаман емес» қылып көрсетеді. Тірі сервис үшін құйрық маңызды: қанша сұраныс 2 секундқа сыйды, қаншасы таймаутқа кетті, қаншасы қайта жіберуді талап етті. Пайдаланушы орташа мәнді емес, чат қатып қалып, бәрін қайта жазуға тура келген сәтті есте сақтайды.

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

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

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

Бизнес модель жауапынан не күтеді

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

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

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

Келесі қадам — «жарайды» мен «жарамсыз» арасындағы қарапайым шекара. Мінсіз жауап іздемеңіз. Адам бәрін нөлден қайта істемейтін жауапты іздеңіз. Әдетте команда нормалы нәтижеге 3-4 белгі жазып алса, дау жоғалады: формат дұрыс, ойдан шығарылған факт жоқ, керек өрістер бар, жауап сұранысқа сай.

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

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

Қалыпты күту былай естіледі: жүйе 5 секунд ішінде құжат бойынша жауап черновигін дайындайды, 90% жағдайда заңгер тек ұсақ түзетулер енгізеді, бір тексерудің орташа бағасы бюджетке сыяды. Осындай сипаттамамен бизнесті әдемі кідіріс графигімен алмастырып жіберу қиын.

SLO-ға қандай метрикалар кіреді

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

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

Валидті жауап үлесін де «көзбен» өлшеуге болмайды. Алдымен нақты ережелерді бекітіңіз: жауап тақырыпқа сай, керек форматта, ойдан шығарылған фактісіз, тыйым салынған контентсіз және егер бұл JSON не форма болса, міндетті өрістер толтырылған болсын. Сонда сапа жөніндегі дау пікір алмасу емес, чек-лист бойынша тексеруге айналады.

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

Әртүрлі тапсырма түрлерін араластырмаңыз

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

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

SLO-ны қадамдап қалай жинау керек

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

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

Әр сценарий үшін нені қалыпты нәтиже деп есептейтініңізді жазыңыз. «Модель жауап берді» емес, «клиент керек уақытта және қолайлы бағамен жарамды жауап алды». Содан кейін үш шек қойыңыз: жауап уақыты, валидті жауап үлесі және баға. Уақытты орташа мәнмен емес, мысалы p95-пен санаған дұрыс. Баға пайдалы әрекетке байлануы керек: диалог үшін, өтінім үшін немесе 1000 сәтті жауап үшін.

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

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

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

Қысқа мысал. Егер чат-бот бірінші желі уақытын үнемдеуі керек болса, мақсатты былай жазуға болады: p95 6 секундтан аспайды, валидті жауаптар 92%-дан төмен емес, сәтті диалог құны 18 теңгеден аспайды. Команда компромисті бірден көреді. Модель тезірек жауап беруі мүмкін, бірақ жиі қателесуі мүмкін. Немесе жақсырақ жауап беріп, бюджетті көбірек жеуі мүмкін.

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

Валидті жауап үлесін қалай есептеу керек

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

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

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

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

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

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

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

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

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

Қолдау қызметіне арналған мысал

Банк операторы үшін мінсіз мәтін керек емес. Оған тез келетін, артық нәрсе ойлап таппайтын және шынымен уақыт үнемдейтін черновик керек. Сондықтан қолдаудағы LLM қосымшалары үшін SLO-ны әдемі орташа кідіріске емес, жарамды жауапқа қарап есептеген дұрыс.

Қарапайым сценарийді елестетейік. Клиент чатқа картадағы даулы операция бойынша жазады. Модель операторға арналған жауап черновигін дайындайды. Егер черновик 4 секундтан кеш келсе, оператор әдетте күтпейді де, өзі жазады. Мұнда орташа кідіріс дерлік пайдасыз: ол 1,8 секунд болса да, ұзын құйрық бәрін бұзады. Команда үшін маңызды ереже басқа: 95% жағдайда жауап 4 секундтан кешікпеуі керек.

Сапа жағында да солай. Валидті деп «жалпы жаман емес» мәтінді емес, ойдан шығарылған шарттары жоқ және керек өрістері бар жауапты айтады. Мысалы, черновикте жауап себебі, клиентке келесі қадам және өтініш бойынша қажет нақтылау болуы тиіс. Егер модель тариф бойынша жоқ ережені қосса немесе міндетті өрістердің бірін түсіріп тастаса, мұндай жауап бракқа кетеді.

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

Осындай кейсте SLO-ны төрт ережемен сипаттауға болады: жауаптардың 95%-ы 4 секунд немесе одан тез келеді, валидті жауапта ойдан шығарылған шарттар жоқ, барлық міндетті өрістер бар, ал баға қате не таймауттан кейінгі қайталама сұранысты да есептейді.

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

Айталық, 1000 өтініштің 950 жауабы уақытында келді. Олардың 890-ы валидтілік тексеруінен өтті. Тағы 80 жағдайда оператор екі фрагменттен көп түзетті. Демек, жарамды черновик саны 810 болды. Егер осы кезде жүйе таймаут пен қателерден кейін 60 рет қайта сұрау жасаған болса, бизнес 810 пайдалы нәтиженің бағасына қарайды, ал «сәтті» 1000 сұраныс туралы есепке емес.

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

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

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

Бірінші қате — орташа кідіріске қарау. Орташа мән әрдайым тыныштандырады. Егер жеті жауап 2 секундта келіп, үшеуі 18 секундқа созылса, цифр жаман көрінбейді. Пайдаланушы мен оператор үшін бұл әлдеқашан нашар тәжірибе: диалог үзіледі, адам тағы да «жіберу» басады, ал құн мен қате саны өседі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тек ірі провайдерлерді ғана емес, open-weight модельдерді де қарау орынды. Кейде олар жалпы күш жағынан ұтылса да, баға, кідіріс немесе деректерге талап жағынан ұтады. Қазақстандағы командалар үшін мұндай салыстыруды AI Router арқылы ыңғайлы жасауға болады: base_url-ды api.airouter.kz-ке ауыстырып, SDK-ны, кодты және промпттарды өзгертпей-ақ бірдей сұраныстарды әртүрлі модельдер мен провайдерлер арқылы өткізуге болады. Бұл экспериментті жеңілдетеді, бірақ SLO шектерін бәрібір тірі трафикте тексеру керек.

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