Tenantтер бойынша AI функцияларына арналған фичефлагтар: іске қосу сұлбасы

Неліктен жалпы релиз әр клиентке бірдей болмайды

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

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

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

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

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

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

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

Флагқа нені бекіту керек

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

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

Әдетте үш деңгей жеткілікті.

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

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

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

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

Tenantтер бойынша іске қосу сұлбасын қалай құру керек

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

Tenantті жүйе сұраудан көретін нақты tenant_id ретінде есептеген дұрыс, «шарт бойынша компания» ретінде емес. Сонда ереже автоматты түрде, қолмен жасалатын ерекше рұқсаттарсыз тексеріледі. Әйтпесе бір клиент тез арада тест кабинеттерге, еншілес командаларға және уақытша ортаға бытырап кетеді.

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

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

Әдетте осы үш күй жеткілікті. Егер бес-алтауға жеткізсеңіз, команда іске қосудың орнына атауларды талқылай бастайды.

Ережені CRM-дегі клиент атауына емес, дәл tenant_id-ге байлаған жөн. Ыңғайлы формат мынадай: tenant_id -> state -> model -> start_date -> owner. Мысалы, bank-17 tenantі қазіргі модельде қалады, ал retail-04 tenantі жаңа модельге пилот алады. Егер сіз бірыңғай LLM-шлюз қолдансаңыз, тексеруді сұранысты ары қарай маршрутқа жібермей тұрып жасау ыңғайлы. AI Router жағдайында қолданба бұрынғысынша бір OpenAI-үйлесімді эндпоинт арқылы жұмыс істей береді, ал кімге жаңа модельге кіруге болатынын өз жағыңызда tenant_id пен флаг арқылы шешесіз.

Әр ереженің бір ғана иесі болуы керек. Комитет те емес, ортақ чат та емес. Қосу, кідірту және откат үшін бір адам жауап береді. Иесінің қасына басталу күні мен қайта қарау күнін де қояды. Онсыз пилот айлап созылып, біртүрлі жартылай өндірістік схемаға айналып кетеді.

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

Жұмыс схемасы бес нәрсеге сүйенеді: tenantтердің нақты тізімі, үш анық күй, tenant_id бойынша ереже, тағайындалған иесі және алдын ала жазылған откат. Қалғанын кейін де толықтыруға болады.

Ережелерді қайда сақтау және оларды кім өзгертеді

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

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

Флагтың жанында нені сақтау керек

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

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

Флагты өзгерту құқығы мен код шығаруды бөлек ұстаған дұрыс. Tenant статусын көбіне продакт, клиент иесі, compliance немесе security өзгертеді. Кодты басқа команда шығарады. Егер бір адам бәрін қатар істесе, релиз кезіндегі қате модельді дұрыс емес клиенттерге ашып қоюы мүмкін.

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

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

Екі клиентпен сценарий

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

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

Логикасы қарапайым:

• сұраныс tenant_id-мен келеді;
• сервис осы tenant үшін model_v2_enabled флагын оқиды;
• А банкіне жаңа модельді таңдайды;
• Б ритейлеріне бұрынғы нұсқаны қалдырады;
• логтарда команда қай tenant қай жаққа жіберілгенін көреді.

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

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

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

Қосудан бұрын жылдам тексеріс

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

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

Бірнеше минутта не тексеру керек

• Қамтылатын сценарийлердің тізімін жасаңыз. Жалпы «чат» немесе «іздеу» емес, нақты ағындарды жазыңыз: қоңырауларды жинақтау, оператор жауабының жобасы, анкетаны тексеру, өтінішті жіктеу.
• Tenant үшін сұраныс лимитін бекітіңіз. Команда тәуліктік шекті ғана емес, қосқаннан кейінгі бірінші сағатта нені дабыл деп санайтынын да білуі керек.
• Жаңа және ескі ағынның логтарын бөлек жүргізіңіз. Кейін бұл сағаттарды үнемдейді: жауапты қай жерде жаңа модель бергенін, ал қай жерде ескі маршрут жұмыс істегенін бірден көресіз.
• Откатқа арналған түсінікті сигнал тағайындаңыз. Бұл қателердің өсуі, шығынның шарықтауы, кідірістің шектен асуы немесе бизнес-командадан нақты сценарийге қатысты шағым болуы мүмкін.
• Қолдау қызметіне қысқа жадынама беріңіз: қосылған күні, tenantтер тізімі, пайдаланушы үшін не өзгерді және ақау болса кімге жазу керек.

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

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

Егер сіз трафикті AI Router арқылы жүргізсеңіз, релизге дейін audit log-тарда tenant бойынша трафик көрінетінін және key деңгейіндегі rate limits клиентпен келіскеніңіздей бапталғанын тексеріңіз. Сонда алғашқы ауытқуларда сіз жай ғана «қателер өсті» дегенді емес, қай клиентте, қай ағынға және қандай қосудан кейін болғанын көресіз.

Іске қосуды бұзатын қателер

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

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

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

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

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

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

Қосудан бұрын төрт сұрақ қойып алған пайдалы:

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

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

Суета болмайтындай кері қайтару

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

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

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

Іске қосқаннан кейінгі алғашқы 10-15 минутта бірден үш метриканы қараңыз:

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

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

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

Откаттан кейін журналға жазба қалдырыңыз. Қысқа жол жеткілікті: кім ауыстырды, қай tenant қамтылды, қашан болды және нақты не дұрыс болмады. Себеп нақты болуы керек: «құны 1,8 есе өсті», «модель жауап форматынан жиі ауытқыды», «кідіріс SLA-дан асты».

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

Алғашқы іске қосудан кейін не істеу керек

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

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

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

Бір жерде мына нәрселерді ұстаған пайдалы: әр tenant бойынша модель маршруттары, қосу мен ережені ауыстырудың audit log-тары, API key және сценарий бойынша лимиттер, сондай-ақ клиент үшін міндетті болса, PII-ді маскировка жасау және деректерді сақтау ережелері.

Егер кейбір клиенттің деректерді Қазақстан ішінде сақтау талабы болса, AI Router сияқты бірыңғай шлюз схеманың бастапқы бөлігін жеңілдетеді: бір OpenAI-үйлесімді эндпоинт, audit log-тар, PII маскировкасы және ел ішіндегі инфрақұрылым. Бірақ қолжетімділік тәртібін бәрібір өзіңізде tenant_id, статустар және түсінікті откат ережелері арқылы ашық ұстаған дұрыс.

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

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