ML-решения в проде — батчи, NRT, RT, что выбрать и какие подводные камни? / Георгий Кокорин

В финале у нас будет, конечно же, то, без чего эта конференция не могла обойтись, а именно без современных тенденций, без машиннинга и, конечно же, без того, как всё это дело крутить в проде. Об этом нам расскажет Георгий Кокорин из МВС. Прошу. — Всем привет. Меня зовут Георгий Кокорин. Я работаю в МТС веб-сервисах и занима Угу. а MLE. Вот. А начнём с рассказа немного о себе. А я работаю в отделе бегдаты. В рекомендательных системах мы пилим рекомендации для а всей экосистемы МТС, то есть для строк, для океона, для музыки, для всех продуктов. Все ходят к нам. Вот отвечаю я за а доставку ML-моделей в Proт, а также за их отказоустойчивость, мониторинг и настройку. О чём сегодня будет доклад? А на самом деле реконательный сервис - это такая специфика, где не всегда понятно, а что пользователю может понравиться лишь по его действиям. То есть нажал он лайк, скипнул, посмотрел, либо у него сегодня такое настроение, либо это просто ему не нравится. И для того, чтобы, а, выдавать ему качественные рекомендации, мы обсудим сегодня три подхода. Аа это бачи, а Real Time и Real Time. Вот что нас сегодня ждёт. Сначала обсудим, кто же такой MLE, чем он занимается, что он делает. А, посмотрим, чем он отличается от своих близких коллег, датасаентистов и датааналитиков, потому что, на самом деле, очень часто их путают. А то, чем они занимаются, мы это рассмотрим. А далее поговорим про бачпроцессинг, бачевую обработку. Для чего она нужна, где её лучше использовать, какие у неё плюсы, какие минусы, а почему вообще бач до сих пор жив и зачем, а и почему он имеет немалое значение даже сейчас в продемоль. А далее поговорим про золотую середину. Это neral time. Это уже побыстрее, чем бач, но ещё недостаточно. Оно не дотягивает до нашего реалтайма. А звёздочка нашей программы сегодня очень актуальная тема. Аа практически все компании сейчас а воюют за в этой сфере. И закончим, а платформными решениями я расскажу, как у нас что работает, а про аб-тесты, про мониторинг, какие инструменты лучше использовать. А сегодняшний кейс мы рассмотрим это. А вводные данные держит 600 RPS. А, SL 160 мсекунд, тысячи автополлок. А, немножко скажу про что такое полки. Полки - это, а, раздел, например, специально для вас, новинки, а, либо же, а, баннерная полка, вот, как мы можем видеть, а, самом верху. А, и на самом деле их очень много. Есть для сериалов, есть для фильмов, есть на главной странице. И редакция очень долго бы это всё обновляла без, а, помощи бача. Вот про него и будет мой рассказ. Ой, про сначала про MLE. А кто что-то такие, да, датасаентист может обучить мотель, а, написать какой-нибудь код в Юпитере, а, провести тесты, подобрать фичить: "Вот, всё классно работает, можем ехать в прот". А, но внедрение этой модели в прот - это не такое уж и простое дело. А на экране основные их различия, чем они отличаются, это дата scienтист. Он, а, выкатывает модель, создаёт её и отдаёт уже далее мэльчику. Чем занимается? а разрабатывает пайплайн, в котором эта будет, а, мониториться, в котором будет раскатываться и, а, ну, будет следить за отказостойчивостью. А дата инженер, он же собирает данные для, а, ML, ну, для модельки, чтобы она могла обучаться. То есть, а, они должны быть валидны, то есть они должны правильно считаться, потому что фичи в ML - это очень важно. А, ну и, соответственно, фокусирует с каждой своей задаче. Вот. И результатом работы data scientist отдаёт обученную модель, датаинженер настраивает pipeline данных, а инженер собирает это всё в одну цепочку. А чем же занимается конкретно Lчик? MLE? А сначала resarch он, а смотрит, выбирает технологии, выбирает pipeline, думает, что же нужно: бач, neural time или real time, потому что это очень важно, у каждого свои задачи. После этого, как, а, архитектура определена

мы, а, начинаем выстраивать, а, pйплаine в, ну, в ветке, а, начинаем собирать код, начинаем собирать всё по кусочкам. А после этого настраиваем деплой, отказыва устойчивость. мониторинги, а и проверяем все наши SL выполняет ли наш пайплаine требованиям заказчика. Вот. И после этого сидим, смотрим метрики. Если всё хорошо, радуемся. Если нет, то придётся полезть разобраться, в чём же дело. А почему MLE занимается и деплоем, итом, и ресерчем? Потому что, если просто кинуть а модельку девопсом и сказать: "Ну вот, задеплойте её, сделайте что-нибудь". Да, они, конечно, это всё сделают тебе. Возможно, не так, как было в вашей архитектуре, но это будет. И проблема в том, что если это упадёт, то будет тяжело найти концы и понять, что не так, почему тайминги плохие, почему не прокрашиваются аб-тесты. Хотя ожидаемо всё должно было быть хорошо. Для этого и нужен MLE. А сразу разберём несколько плохих паттернов в работе MLE, которые на самом деле очень часто встречаются даже опытных разработчиков. То есть первый из них - это вот так называемый золотой молоток. Это выбирать инструмент не по нужде, а по его популярности, по тому, что вот он сейчас востребован, либо его использует другая компания. Это плохо. Так не нужно делать. Нужно всегда, э, смотреть на архитектуру и выбирать соответствующиеся инструменты. Потом большая проблема - это преждевременная оптимизация. То есть ещё модельку не вкатили в прот, не накатили тесты, не было замеров, но уже мы начинаем, а, что-то оптимизировать, улучшать, ускорять, что-то делать лучше. Это возможно ваша эмэлька даже и в протто не попадёт, она не доедет дотуда. И все эти оптимизации - это была пустая трата времени. А модель вакууме это когда датасатист довольный обучает модель на каких-то данных. Всё хорошо, тесты, всё прошло, всё отлично, но, например, не учли сезонность, то есть, а, лето и зима, не учли, а пол мужской, женский, не учли, возраст слушателей, вот, ну, всё, из чего составляются фичинеса моделей. Далее, а, забываем про бизнес-правила. Это тоже большая проблема, потому что, например, мы вряд ли будем рекомендовать мужчинам больше Аннуасти, чем женщинам. Но иногда происходят и такие ситуации. Либо же взрослым людям мы рекомендуем очень много мультиков. А всё потому, что нету фильтров ни по возрасту, ни по полу, ни по региону. А поэтому нужно всегда следить за бизнес-ограничениями и с самого начала, а складывать йлайн так, чтобы они соблюдались. А сейчас мы поговорим про бач. Это неотъемлемая часть ML-системы. А оченьочень много полок собирается. В нём очень много рекомендаций крутится на регламенте. А и из чего же он состоит? Это сначала нам нужны исторические данные. Это просмотры, поиск пользователя. логи, клики, лайки, дизлайки, всё, что пользователь нажимает в приложении, мы за этим следим. Мы, а, всё это логаем и смотри и анализируем. После этого мы, а, с этими с этой информацией пересчитываем ему рекомендации, то есть обновляем фичи. Для этого мы используем сегодня будем расматривать Airflow и ML Flow, так как они самые простые для входа. А, и как итог, у нас обновляются витрины. У нас нету мигания. Мигание - это когда ты обновляешь страничку и у тебя неожиданно обновляются все полки. А многие пользователи такого не любят, потому что ты приходишь вечером домой, открываешь сайт, смотришь: "Ага, посмотрю этот сериал, мне он понравился, рекомендации сработали хорошо". Потом отходишь куда-нибудь, возвращаешься, страница обновилась, его уже нет. Это неприятная ситуация. Вот. И ещё раз повторюсь, что редакторы не могут так много обрабатывать полок, как бачпроцессинг. самых больше тысячи в кионе. А рассмотрим бач рекомендации, из чего же он состоит, чуть поподробнее, что происходит. А, и в чём же потом на вот этих табличках будем сравнивать, в чём разница междуal и real time, ну, и почём, соответственно, вот. А какое-то приложение абстрактное складывает куда-то логи в какое-то датахранилище, в какой-то датахаус. И потом ночью аа наш бачпроцесинг, он идёт и начинает забирать эти данные. Он их очищает, агрегирует, валидирует, подстраивает их под нужный формат и потом формирует из них фичи. Фичи нужны для того, чтобы у тебя правильно заинферилась моделька. Аа

фечи включаются, например, количество кликов, а количество лайков, количество дизлайков, отношение лайкам к дизлайкам. Там их на самом деле может быть больше тысячи. Это всё очень важные показатели. А без них просто невозможно построить нормальные рекомендации. Далее это офлайн infence модель. Мы, а, наши фичи применяем и отдаём модельке на сиденья. Она же выдаёт, она же ранжирует нам, а, наши результаты и отдаёт в витрины. После этого у нас обновляются витрины. То есть, например, пользователь, а, вечером засыпает по, ну, он посмотрел сериал, ему всё понравилось, засыпает, а, просыпается, а витрины уже обновлены. Вот. Рассмотрим в конкретном кейсе в Кионе. Это, например, топ сериалов за месяц, новые сериалы и лучшие сериалы XXI века. Аа именно конкретно эти полки, они собираются батч процесссингом. А таких полок можно выдумать очень много. И, а-а, без бача их пересчитывать никак. Ну и не требуется, на самом деле, пересчитывать их, а, каждый час, либо реагировать на каждый игрик пользователя, потому что если у тебя топ сериалов за месяц, то вряд ли он будет меняться при каждом обновлении страницы. Вот. И этим очень удобен батч, что ты его один раз настроил и потом он у тебя стабильно работает и а очень предсказуемо. В этом его главная а фишка, что он очень предсказуемый с ним. не так много проблем возникает, как с последующими нашими кандидатами. Аа если говорить просто, то а мы хотим использовать бач, когда нам нужна стабиль стабильность. У нас а много данных, которые лежат в каком-то месте, и нам просто нужно их взять, посчитать, приложить. У нас есть а время это сделать, и у нас есть ресурсы на массовое вычисления. Вот. Ну, потому что мы пересчитываем для всех пользователей сразу. И это происходит незаметно. Там достаточно такие низкая нагрузка на сервера, потому что опять же это всё ожидаемое, и мы закладываем эту нагрузку. И поэтому не будет такого, что у нас из-за того, что у нас съело всю память или ЦПУ, просто что-то упадёт ночью, какой-то дак. Нет, такого не будет. А, но когда нам нужна свежесть данных, когда нам нужно сразу реагировать на нажатие пользователя, когда мы хотим показывать пользователю какой-то контент, который обновляется, бач уже нам не подходит, потому что это очень долго. Пользователь каждый раз будет видеть вчерашние новинки, а не сегодняшние. Например, вышла какая-то серия Новая сериала, но он узнает о ней только завтра. А, и, конечно же, нас это не устраивает. Поэтому мы будем сейчас разговаривать о нереалтайме. Это золотая середина между бач бачом и реалтаймом, потому что он и не такой сложный и трудозатратный, как realтайм, но и в нём, но и намного быстрее бача. А пример полок - это популярно сейчас. И новинки, они вот пересчитываются как раз такими бочами. А популярно сейчас аа пересчитываются каждые 2 часа. В среднем пересчёт уреal тайма происходит от 15 минут до 2 часов. Вот. А также новинки, опять же повторюсь, если вышла новая серия, вы о ней сразу же узнаете, ну, в течение 2 часов. А давайте поподробнее разберём Томе, что у него внутри, что происходит, а, и в чём разница с бачом. А к нам прилетают сырые события. То есть главная разница в том, что мы не сами ходим Дагом, а и собираем данные. Они к нам уже прилетают. Мы их подбираем кавкой- это брокер сообщений, и отдаём на стриминг. А стриминг - это непрерывная обработка данных, которая постоянно крутится и ждёт сообщения в кафке и потом их обрабатывает. А дальше появляется такая сущность, как Feature Store. Fatch Store - это хранилище всех наших фичей, а как оффлайн фичей, которые нужны для обучения моделей, для того, чтобы просматривать их конверсию, динамику, следить за ними, но также для онлайнфичей. Онлайнфичи - это фичи, которые нужны нам в очень быстром доступе для того, чтобы, а, просто взять и посчитать аа наш поплайн. Дальше офлайн inference модели. Аа здесь опять же офлайн inference, не онлайн, потому что это вызывается, а каким-то процессом, а не нажатием пользователя, ну либо на запрос пользователя мы не отвечаем. Ну и, соответственно, обновление рекомендаций, всё выгружается в витрины. А проблемы, с которыми мы сталкиваемся - это бизнес-правила. В кионе их больше птидесяти, как валидация по полу, по

возрасту, по а повторам. Ты же не хочешь, чтобы у тебя в нескольких полах были а одинаковые фильмы. Этого нужно максимально избегать. И главная сложность в том, что есть, а, например, триллеры драмы. А есть полка триллеры и драмы. Ну, есть фильм триллер драмы в одном. Есть полка триллер драмы. И вот как раз-таки Блендер - это сервис, который у нас отвечает за бизнес-правила. Он, а, не даёт этим рекомендациям быть на главном экране вместе. То есть у тебя не будет а драмы и триллера, ну, одного фильма на главном экране полки. Она у тебя, этот фильм может быть дальше, но никак не близко. А, ну и, соответственно, сравнительная таблица, цена компромисса. Что, в чём всё-таки разница? А, частоте обновлений бач считается раз в день, ночью. А time намного чаще это делает. А, но time он сложнее, потому что там уже появляется стриминг данных, там появляется аа кавка брокер сообщений, и поэтому там нужен большей технологический бэкграунд, нужно больше мониторинга, больше мощностей. И наша звёздочка - это real time. Мы говорим про него, что он из себя представляет. А здесь уже схема намного сложнее, намного больше, намного интереснее. И здесь мы немножко глубже копнём. Если там мы рассматривали в бачей, в нарелтайме какие-то базовые процессы, которые в среднем происходят у всех, тут мы больше копнём к нам в нашу инфру. Вот к нам прилетает запрос пользователя и а кандидаты. Мы сначала идём за кандидатами для этого пользоваться. Кто такие кандидаты? кандидаты - это айтемы, это может быть там музыка, какие-то песни, если да, мы запрашиваем реклаци для музыки, либо фильмы для киона. А кандидаты, которые мы будем выбирать, которые мы будем смотреть, насколько нам подходит. А потом мы забираем следующий шаг - это история пользователя. Нам очень важна в реалтайме история пользователя, потому что мы, а, хотим отслеживать каждый его клик и каждый его свайп, каждое нажатие. А если в баче история хранится где-то на стороне обслуживающего сервиса, например, там бэкэнда киона или музыки, не рекомендаций, то здесь всё сразу же летит к нам, опять же, через кавку и стриминг. А дальше мы идём в F Store, а высчитываем для наших кандидатов и для аа истории и исходя из событий, историй пользователя нашей фичи, а мы забираем не только онлайн фичи, но ещё и вычитываем некоторые фичи на льту, потому что а мы хотим прямо сейчас на свежие события реагировать. А далее идём инфринсим в модельку. Это уже онлайн influence модель, потому что мы сами вызываем, а-а, ну, сам пользователь инициирует этот запрос. Дальше у нас есть сервис такой, как постпросинг. Он, соответственно, применяет фильтры, бизнес-правила и, например, что у тебя в одном баче не может быть одного и того же артиста. Вот. Далее мы, а, логируем Фичи, логируем кандидатов в Кавке и отдаём пользователю. Для чего же? А вот и полка специально для вас. Это вот пример как разтаки полки, в которой работает real time. И что может пойти не так? Для чего же нам, первое, о чём мы поговорим, это для чего мы логируем фичи, а кандидатов, которые мы отдаём пользованию? Потому что некоторые пользо мы храним историю пользователя у себя на стороне 24 часа. И, например, бывают пользователи, которые совершают, ну, редко заходят в приложение. И вот пользователь заходит, совершает запрос, а про неё просто ничего нету. Мы о нём ничего не знаем, мы не можем быстро посчитать, отдать ему запрос. Поэтому мы логируем все фечи. И если находится такой пользователь, про которого у нас ничего нету, мы просто берём и считаем среднее от логированных фичей. А на самом деле относительно просто. Дальше очень важно это не забывать про Fullback. Fallback - это сервис, который отдаёт какие-то холодные базовые дефолт рекомендации, если на каком-то из этапов что-то происходит не так. А если какой-то сервис пятисотит, мы не оставим нашего пользователя без рекомендаций. Мы обязательно ему что-то отдадим. Да, возможно, не такое персонализированно, как хотелось бы, но это всё-таки временная мера. И иногда бывает, э, так, что ты делаешь нагрузчное тестирование и тайминги очень высокие. Ты не понимаешь, какой сервис у тебя тормозит, в каком месте. Это могут быть как расчёт онлайн фичей, так может быть какая-то квэшка тебе долго отвечает. Очень важно настраивать треacнг, а смотреть анализировать

все сервисы. Поговорим также про метрики. На самом деле метрики - это очень важно. Без метрик мы буквально слепы. Мы не можем, а, понять конверсию, отследить, посмотреть, как работают наши сервисы, всё с ними хорошо, не всё. А это очень важная часть в работе MLE и выкадки моделею, потому что а модель, которая работает надёжно, она лучше, чем модель, которая точечно отвечает, но редко. Аа поэтому я всем рекомендую настраивать метрики. Да, это бывает, а не хочется, больно, неудобно, мощности, но без этого никак. вы не сможете отслеживать свою прогрессию. И самое главное, как мы понимаем, хороша моделька или всё-таки что-то не так? Если, например, MLE выполнил всё, что от него требовалось, моделька в проде, моделька отвечает за нужное время, всё хорошо. А как понять, справились ли остальные? Существуют А-тесты, как они работают? берётся какой-то процент рандомный, 10% пользователей и делится на две группы: группа А и группа Б. А-а им выдаются разные, либо бывает так, что это может быть старая и новая моделька, либо две новые модельки. А в Кионе было такое, что даже там шесть моделек соревновались за место быть под солнцем. А и смотрим конверсию, учитываем, смотрим, а клики, сколько человек находился на сайте, сколько смотрел, аа удерживало ли это его внимание. И уже, соответственно, из этого мы, а, определяем, успешно либо неуспешно наша моделька в проде. Аа я оставил вам чек-лист для выбора. Тут довольно-таки всё просто. А если вы не понимаете, вы на в начале своего пути и не знаете, что же вам выбрать, либо вы хотите просто потренироваться, посидеть, посравнивать, понять, разобраться, можете использовать этот чек-лист для выбора. Он, а, поможет вам для того, чтобы сделать, а, принять решение. А что бы я посоветовал сделать завтра утром тем, кому понравилось, кому интересно, кто хочет этим заниматься, а, попробуйте разобраться сfow и SML Flow. Они не нужно делать какие-то невероятные runтайм истории. Достаточно просто установить локально, посмотреть, как это работает, покликать там аа с документацией относительно всё просто. То есть сначала мы изучаем инструменты, потом я бы рекомендовал начать с бачобработки, потому что она самая простая в свении, её очень легко, а отслеживать а все детали в ней. Так, пробуйте создать простой дак и настройте логирование, чтобы смотреть, а как работает ваша моделька. А, посмотрите результат после этого и отслеживайте, меняйте пайплайны, отслеживайте время выполнения, оптимизируйте, улучшайте и не забываем про метрики. Определите метрики и смотрите за прогрессом. У меня всё. — Да, спасибо. Здесь QR-код. Проходите, оставляйте свои отзывы, обратную связь по докладу и также заходите в чат. Там можно, соответственно, задать вопросы, на которые и будут даны ответы. Так вот, а у меня тоже есть несколько вопросов. То есть, а я понимаю, что, ну, МТС, МВС - это достаточно такая большая компания, скажем, очень большая. И, а, во всякой корпоративной среде есть, ну, достаточно дроблёное такое распределение ролей, чёткое очень. Как бы это выглядело в компаниях поменьше? А в компаниях поменьше бывают такие случаи, что один сотрудник занимается и обязанностями дата саентиста, дата аналитика и вот. Но всё же, а, при трудоустройстве, при нами ты пытаешься, а, договориться с руководителем, чем ты будешь знать т, чем тебе интересно заниматься. — И у всех по-разному, но в МТС достаточно строго определены рамки. — Угу. Что каждый что должен делать? — О'кей. А из кого вообще вырастает вот в MLE? — А может быть как эмщик, может быть датасатист. А я, например, был разработчиком изначально. Просто кэнд разраб на Питоне. — Угу. — Вот. И мне стало интересно, как это всё работает, как выкатываются модельки. Поэтому у меня есть такой небольшой бэкграунд в бэкэнде. Но ты, получается, интересовался именно в том числе разработкой

— в качестве, ну, в качестве датасатиста, в качестве ML инженера там, вот, ну, вот всю эту штуку ты понимаешь, получается, вот начало и до конца. — Ну, можно сказать, да, я могу и микросервис написать, который будет собирать user history, так и модельку довести до прода. Мм, то есть - это, по сути, ну, люди, которые понимают весь пайплайн и работу с данными и всёвсёвсёвсёвсё-всё, но при этом занимаются вот чем-то — одной из частей всего этого пайплайна. — А, ну, они занимаются, они смотрят на пайплайн, в общем. — Угу. То есть их задача широко смотреть на не какую-то конкретность, то есть не просто он должен отвечать за мониторинг, например, что вот мониторинги настроен, всё корректно работает. А это больше история про то, что ты должен, а заранее посмотреть, подсветить риски, посмотреть, что может пойти не так, что вы можете прийти по SALA. То есть это немного другое, не как вот в разработке DevOps. То есть у девопсов меньше, на самом деле, я так понимаю, обязанность. - это что-то типа смеси, э, девопса для эмля и архитектора, — можно сказать. Так, да, есть ещё профессия OBS. Вот она больше похожа для девопсов, которые катят в ML-модельки, но там всё же есть разница. — Нормально, нормально. то ещё упоминал, что м вот мне лично не очень была понятна разница между realта и бачами, то есть почему не сделать нер аа тоже бачами на том же самом пайтплайне ровно то точно так же, но просто запускать чаще, а потому что ты в бочах обрабатываешь очень большое количество данных сразу по всем пользователям. А здесь у тебя накапливается, а, пул событий какого-то определённого пользователя, и конкретно эти события мы пересчитываем, и для этих событий, для этих пользовате мы обновляем. То есть батч он обновляет вообще для всех, но не все же одноментно пользуются сервисом и просто нету нужды обновлять всех пользователей в каждые 2 часа. — М, да, я понял. Но там получается, что чем он отличается там у тебя, а, — был стриминг в NRT, бочах не было. То есть бачи, я так понимаю, выбирают уже из готового какого-то хранилища, — да? Они регламент находят в хранилище через Даге. То есть они ты его настроил и всё, он постоянно что-то делает циклично и стабильно. — Понял, понял. Интересно. Слушай, и ещё одно. А вот бачи, ты говорил, они выполняются ночью. у нас же очень много часовых поясов. — А — как с этим боретесь? — Мы знаем регионы пользователей. — А то есть берёте и просто — можно настроить, да, для каждого региона. — То есть это некрон, это какой-то скидулер, — да? — Для каждого пользователя, в общем-то, свой. Интересно. Там нет пользователи делятся на секции. — А, то есть выполняется бач там для всех пользователей, допустим, дальневосточного региона и для всех обновляется сразу. Угу. Неплохо, неплохо. Так, хорошо. А какие бы ты рекомендации дал, а тем, кто хочет войти в вот в эту вот профессию MLE, — бегдату или в MLE конкретно? — А, в MLE конкретно. — А практика, много практики очень нужно много трогать. А тебе должно быть интересно, ты должен как отработала твоя моделька, всё хорошо, не хорошо, дошла ли она до продали, всё ли хорошо не так. И тебе должно быть интересно именно копаться в этом. Угу. — Потому что покопаться там приходится достаточно часто. Понять, почему тайминги плохие, либо почему она в принципе не запускается. Часто бывает так, что у тебя просто моделька в продепуре в ноутбуке у тебя всё хорошо. — Угу. — Всё отлично, но вот ты построил пайплайн, делаешь как будто то же самое, но нет, мы не поднимаемся, мы сидим, ждём чего-то. — Да, нормально, понял. Так, хорошо. А вообще, а-а, лучше начинать с больших каких-то вот корпораций, там, компаний или всё-таки с небольших, где у тебя, ну, больше свободы, больше ответственности и ты как бы один делаешь всё? Я думаю, что это больше зависит от человека, если, ну, бывают люди, например, которых нужно направлять, которым нужно подсказывать, и бывают люди, которые приходят дома и ночами сидят, не спят, пока не разберутся в какой-то технологии. — Да, это разные ребята. — То есть, ну, вот люди, которые действительно интересны, они могут и

сами разобраться. Но всё равно, когда у тебя есть наставник, команда налаженные процессы, когда у тебя есть мощности, когда ты можешь поэкспериментировать, это намного интереснее и лучше. Моё мнение, — да, это, ну, из моего опыта, в принципе, бывает и в маленьких компаниях, и в больших корпорациях, то есть вот наставники. И главное не работать на начальных этапах одному. — Это выходит оченьочень очень долго. — А, хорошо. Спасибо огромное за контент, за доклад. А на этом мы подходим к завершению нашего дня. Большое спасибо нашему спонсору, это Т- образобразование, и они занимаются, а бесплатными программами, в которых ведут, э, вас от стажировок и вплоть до роли Темледа. А не, а убегайте очень далеко. Приходите на конференции, заходите в чаты, в чаты Онтика, в чаты Хайлоуда. А пишите свои вопросы, если мы что-то не разобрали. Вы всегда можете найти там наших докладчиков и очень хорошо с ними пообщаться. Ну и, конечно же, аа на оффлайн-конференциях это можно сделать в ещё более, а такой приятной обстановке, а которую мы для вас создаём. А там можно пообщаться на совсем такие интересные, острые темы, которые волнуют вас именно на ваших проектах. Ждём вас и до новых встреч. M.