Жұмыс тапсырмаларында кіші модель үлкен модельден қашан жақсырақ

Неліктен командалар тым үлкен модель таңдайды

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

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

Егер сізде already бір OpenAI-үйлесімді эндпоинт болса, азғыру тіпті күшейеді. base_url-ды ауыстырдыңыз, бәрі жұмыс істеп кетті, енді схеманы қозғамаған дұрыс сияқты. Іске қосу үшін бұл ыңғайлы. Нақты жүктеме үшін - әрдайым емес.

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

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

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

Қандай тапсырмаларды кіші модель шығынсыз жабады

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

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

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

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

Кіші модель әдетте мынадай жағдайда қолайлы:

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

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

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

Әдетте пайда үш жерде бірден көрінеді: құны төмендейді, кідіріс азаяды және жауап форматы тұрақтырақ болады. Егер тапсырма «оқы, белгіле, шығар, JSON қайтар» дегенге келсе, үлкен модель көбіне артық болып қалады.

Үлкен модель қашан бәрібір қажет

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

Бұл әсіресе бірнеше типтік жағдайда анық байқалады:

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

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

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

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

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

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

Мұны өз тапсырмаңызда қалай тексеруге болады

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

100-300 нақты мысалдан тұратын жиыннан бастаңыз. Тек таза кейстерді алмаңыз. Шуды қосыңыз: қысқа хабарламалар, орфографиялық қателер, аралас тіл, толық емес формалар, даулы өтінімдер. Егер сіз LLM мәтіндерін классификациялауды немесе LLM арқылы өрістерді шығаруды тексеріп жатсаңыз, продакшенді көбіне дәл осындай мысалдар бұзады.

Содан кейін барлық модельге бір жауап форматын бекітіңіз. Қолдау өтінімі үшін бұл category, priority, language, need_human_review өрістері бар JSON болуы мүмкін. Формат бірдей болуы тиіс, әйтпесе сіз модельдерді емес, жауап берудің әртүрлі тәсілдерін салыстырып шығасыз.

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

Тек сапаны қарау жеткіліксіз. Әдетте төрт метрика жеткілікті:

• өз жиыныңыздағы дәлдік
• бір сұранысқа және 1000 сұранысқа шаққандағы LLM инференс құны
• тек орташа уақыт емес, p95 кідіріс
• модель жауап форматын бұзатын жағдайлардың үлесі

Кейде қорытынды бірден көрінеді. Үлкен модель сәл сирегірек қателеседі, бірақ 3-5 есе баяуырақ жауап береді және едәуір қымбат тұрады. Қысқа тапсырма үшін бұл жаман айырбас.

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

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

Мысал: қолдау өтінімдерін талдау

Қолдауға келетін қарапайым хат ағынын елестетіңіз. Клиент: «458731 келісімшарты бойынша ақша ұстай алмай тұр, шотта қаражат бар» деп жазады. Командаға хатты кеңінен талдау қажет емес. Оларға өтінім тақырыбын тез анықтап, келісімшарт нөмірін CRM-ге шығару керек.

Осындай міндетте кіші модель неге жиі тиімді екенін жақсы көруге болады. Үлкен reasoning-модель ой қорыту барысын түсіндіріп, мүмкін себептерді санамалап, операторға қадамдар ұсынғанды ұнатады. Бұл сенімді естіледі, бірақ өтінімдер кезегіне ол артық. Әр ұзақ түсіндірме уақыт пен ақша алады, ал операторға бәрібір қысқа нәтиже керек: «тақырып - төлем», «келісімшарт - 458731».

Кіші модель мұны әдетте жылдамырақ орындайды. Промпт тар болса, жауап форматы қатаң болса, ол хаттың тақырыбын және қажет өрістерді тұрақты қайтарады. CRM үшін осы жеткілікті. Өтінім көп болғанда, бір хатқа 1-2 секунд үнемнің өзі аптасына сағаттарға айналады.

Мұнда жұмыс схемасы қарапайым:

• кіші модель хатты оқып, өтінім тақырыбы мен келісімшарт нөмірін қайтарады
• жауап толық әрі форматы дұрыс болса, жүйе өрістерді бірден CRM-ге жазады
• күрделі хаттар тек айқын ереже бойынша үлкен модельге жіберіледі
• оператор модельдің ұзақ мәтінін емес, дайын карточканы көреді

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

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

Жауап сапасынан бөлек нені есептеу керек

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

Алдымен бір шақырудың бағасын емес, бүкіл ағынның құнын есептеңіз. Егер өтінім классификациядан, өріс шығарудан және қысқа тексеруден өтсе, құнын бүкіл тізбекке көбейтіңіз. Содан кейін оны 1000 сұраныстың бағасына және нақты көлеміңіздегі айлық шотқа айналдырыңыз. 50 000 сұраныста айырмашылық майда көрінуі мүмкін. Миллиондаған сұраныста ол сервистің экономикасын өзгертеді.

Орташа жауап уақыты да көп нәрсе айтпайды. Пайдаланушы орташа мәнді емес, жүйе жүктелген кездегі ұзақ кідірістерді сезеді. Сондықтан p95 пен p99-ды ең жоғары жүктеме кезінде қараған пайдалырақ: таңертең, жаппай тарату хабарламасынан кейін, жұмыс күнінің соңында. Әдетте 1,2 секундта жауап беретін, бірақ жиі 8-10 секундқа созылып кететін модель сәл азырақ дәл, бірақ бірқалыптырақ модельден де көбірек кедергі жасайды.

Тағы бір жиі мәселе - жауап форматы. Егер модель он жауаптың бірінде JSON-ды бұзып, өріс атауын өзгертіп немесе нәтиженің айналасына артық мәтін қосса, сіз екі есе төлейсіз: бір рет шақырғаныңыз үшін және қайта сұратқаныңыз үшін. Өрістерді шығару үшін бұл тест жиынындағы қосымша 1-2% сападан да маңыздырақ болуы мүмкін.

Әр модель бойынша бірдей метрикалар жинаған пайдалы:

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

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

Көбіне қай жерде қателеседі

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

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

Жақсы тест жиынына мыналарды қосқан дұрыс:

• орфографиялық қателері мен сленгі бар хабарламалар
• бос немесе жартылай бос өрістер
• қысқартылып қалған мәтіндер
• артық деталдары бар ұзын өтінімдер
• қате құны жоғары сирек жағдайлар

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

Орташа балл да оңай ұйықтатып жібереді. Айталық, модель келісімшарт нөмірі өрісін 97% жағдайда дұрыс шығарады. Жақсы сияқты. Бірақ қалған 3% ұзын хаттардан немесе ірі клиенттерден келсе, орташа сан көп нәрсе айтпайды. Тек орташаға емес, қателердің құйрығына да қараңыз: модель қай жерде үнсіз қалады, өрістерді шатастырады немесе сенімді, бірақ қате жауап береді.

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

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

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

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

Алдымен жауаптың қатаң формасын бекітіңіз. «Қалай болса солай жауап бер» емес, нақты JSON немесе міндетті өрістері бар кесте. Егер өріс табылмаса, модель null немесе алдын ала келісілген белгі жазсын. Сонда сіз мәтіннің әдемілігін емес, нәтижесінің жүйеге жарамдылығын бірден көресіз.

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

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

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

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

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

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

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

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

Жұмыс схемасы мынадай:

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

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

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

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