Emeli in ML

Запись стрима с Эмели

В среду, 1 мая проведем стрим с Эмели Co-founder and CTO Evidently AI - и со-автором курсов по МЛ от Яндекса

Добавить в календарь

Ребят 👋
Мы с Валерой чуть меньше чем через час встречаемся онлайн на его канале. Вот такой вот short notice :)))) забейгайте, кому интересно, будем рады!

Недавно очень душевно пили кофе с ex-коллегой из Яндекса. Вспоминали как работали в одном департаменте, сравнивали с опытом построения стартапа (а вот стартапы у нас разные).

В процессе, коллега задал очень хороший вопрос: “А что у вас было, когда вас отобрали в YC?”

YC дал нам очень хороший буст, поэтому я решила тезисно поделиться и с вами.
Коротко, что было:
⁃ Команда: 2 человека, я (СТО) и моя Лена (CEO)
⁃ Бюджет: мы, готовые год жить без зарплаты (по факту оказалось почти 2🙈)
⁃ Идея: одна штука и стопроцентный комитмент ее перепридумать после тестирования об реальность (тут я про пользователей)
⁃ Скилы: на двоих мы могли закрыть всё по бизнесу и продукту. Местами великолепно, местами просто чтобы работало.

Как вы понимаете, я больше про продукт, и это тот случай, когда я могу не только рассказать, но и показать. Люблю open source за то, что GitHub помнит всё. Любой сегодня может зайти и посмотреть, как наш проект выглядел 3 года назад (вот так)
Какой код я тогда писала, простой и понятный! Ловите случайный PR из февраля счастливого 2021 года.

Никаких тебе датаклассов и пайдантика, нет CI/CD, нет линтеров, юнит тестов в прочем тоже нет (последним я не горжусь😳). Контрибьютеров нет, evidently даже еще нельзя поставить с помощью conda, а вся документация помещается в ридми.
Не все вышеперечисленное “OK”, но ребят, делала от души и как умела. Зато работало.

Появилась идея для вас: сходите и посмотрите в GitHub как начинались открытые проекты, которые сейчас выглядят для вас недостижимо классными! Правда, посмотрите. Это хороший синк с реальностью, особенно для самых сомневающихся🤍

Ребят, привет! Вы меня не просили, и я возвращаюсь 😊

Одним из нас на сальто в воздухе для перестроения примерно всей жизни нужно 2 дня, другим - 2 года. Где я на этой линейке мы поняли, а про себя, надеюсь, вы сами знаете)

Оглядываясь назад, сама не верю, что меняя страны чаще чем футболки, удалось сохранить порядок: пусть вещи разбросаны, зато мысли собраны; Документы теряла, своих- находила. С таким обменным курсом я согласна!

В этом году я снова работала не для того, чтобы убежать от реальности, а для того, чтобы ее создавать. Я собрала лучшую команду на свете, нашу библиотеку cкачали более 5млн раз; мы не только закрепились на первом месте среди oss инструментов для ml мониторинга, но и запустили открытый курс по ml observability! А в конце года ещё и открыли бету evidently cloud! Видеть как то, что ты делаешь, заходит - эмоции, от которых снова захотелось говорить. Накопилось очень много тепла и опыта, а значит пришло время делиться.

Что ж, уроки выучены, подорожник приложен☘️ 22й и 23й - вы меня не полюбили, а я в вас верила! 2024 - на тебя вся надежда!

Кстати, вы же знаете, что 1е января - это понедельник? Для всех, кто любит начинать большие проекты “с понедельника” - вот он, родненький, уже завтра! Кристально-чистый белый лист - первый день и первый понедельник нового года. Давайте, пожалуйста, в этот раз не будем ждать, когда праздники закончатся? Начнем завтра!

Если вы data scientist и занимаетесь ML - протестируйте наш опенсорс-продукт, инструмент для мониторинга и валидации ML моделей: https://github.com/evidentlyai/evidently (⭐️🙏) Я ещё нигде это не анонсировала, но мы выберем 1 или 2 кейса, которым я сама помогу настроить мониторинг и/или валидацию моделей с помощью Evidently. Вдруг, это вы? Тогда напишите мне про себя и задачу: [email protected]

Всем привет! Наверное, уже не ожидали пост?)

Начну с ответа на вопрос, куда же они пропали. Всё банально - у меня просто не хватило времени. Но произошло это по очень позитивной причине!
Наш стартап Evidently AI получил инвестиции от Y Combinator, лучшего стартап-акселератора в мире❤️

Скажу честно, я этого не ожидала. Мы с Леной не очень похожи на идеальный стартап из Силиконовой Долины (хотя бы потому, что мы не там)! Я не думала, что нас правда пригласят в YC и не рассчитала силы на то, чтобы всё успеть. Надеюсь, вы не очень сильно расстроились😒

Всё это время мы быстро росли: регистрировали компанию в Штатах, обновляли сайт, создавали документацию, занимались тех. поддержкой пользователей и параллельно выкатили около 20 обновлений библиотеки💪
В последнее тоже с трудом верится, ведь среди этих обновлений:
- полноценный рефакторинг проекта, с ускорением генерации репортов и сокращением объема кодовой базы;
- новые виды репортов, наряду с data drift теперь можно оценивать и target drift, а также performance моделей разного типа;
- добавились форматы: начинали мы с генерации репортов HTML, а теперь еще можем выдать JSON для интеграции в MLflow, Grafana, Zabbix и подобные инструменты;
- обновили набор стат. тестов;
- научились собирать очень минималистичную телеметрию, чтобы узнать, что из всего перечисленного выше реально полезно😅

Если мы мне выдали такой TODO лист на старте, я бы или посмеялась или посочувствовала. Но, видимо, при желании и не такое возможно.

Сегодня у нас важный день - мы запустились на Product Hunt и держимся в Top 5 Product of the Day! Очень захотелось рассказать об этом вам, чтобы вы за нас порадовались и тоже поддержали наш запуск здесь: https://www.producthunt.com/posts/evidently-ai
А может быть и сами вдохновились на новое начинание!

Переобучение на основе скорости деградации модели
В прошлом посте мы обсудили причины, почему модель стоит переобучать. Как часто это лучше делать?
Eсть подход, который как минимум позволит снизить неопределенность.

Я предлагаю ответить на 2 вопроса:
1️⃣Как быстро модель устраивает?
2️⃣Как много данных требуется для качественного улучшения модели?

В первом случае, мы хотим оценить потребность в переобучении. Во втором - возможность: принесет ли переобучение желаемый эффект.

Скорость устаревания📉
Её удобнее всего оценивать, когда есть фактические данные. Например, вы получаете обратную связь в процессе работы сервиса. Или если у вас есть массив исторических данных. В этом случае можно оценить performance модели: качество или ошибку.

Лучше всего начать с исторических данных. Можно обучить модель на более старых данных и последовательно применить к более новым периодам. Цель - определить, когда ошибка начинает значимо расти. Такой точечный замер уже сможет снизить неопределенность! Мы сможем грубо оценить, как быстро устаревает наша модель: за часы, дни, недели или месяцы.

Если исторических данных много, то замер можно сделать несколько раз подряд. Так мы получим более точную оценку скорости устаревания. Конечно, в таком случае я предполагаю, что метод обучения модели фиксирован. Если обучать модели по-разному, то параметры обучения могут влиять на устаревание больше, чем внешние условия.

Здесь, наверное, загрустили те, у кого исторических данных мало, а обратная связь поступает с солидной задержкой. I feel your pain😖! Предлагаю в этом случае замерять data drift. Идея простая: мы не можем оценить, устарела ли модель, но можем оценить, изменились ли данные, которые она получает на вход. Если внешняя среда изменилась (data drift detected) - то у модели был шанс устареть. Это можно оценить с помощью стат. теста.

Перспективы улучшения📈
Вы, наверняка, помните красивую идею подбора количества деревьев в ансамбле на этапе валидации? Например, Random Forest. Выбираем минимальное и максимальное количество деревьев, задаем шаг и строим график зависимости качества модели от количества деревьев (не забывая о кросс-валидации!). Такой график после некоторого порога по количеству деревьев выходит на плато. Таким образом, мы понимаем, в какой момент добавление новых деревьев перестает улучшать качество модели.

Аналогичную идею можно применить и для оценки перспектив улучшения качества модели от добавления новых данных. Фиксируем тест и начинаем с некоторым шагом наращивать обучающую выборку, обучать модель и делать замер качества. Для более точной оценки фиксируем несколько тестов, повторяем процедуру и усредняем результаты.

Такая оценка, конечно, имеет свои ограничения: не все данные одинаково полезны. Если модели не хватает данных, скажем, за конкретные часы или с определенными событиями, то они будут более полезны, чем остальные данные. Однако, мы можем предположить, что эти “ценные” события могут встречаться в данных с определенной частотой. Поэтому наша оценка все равно полезна! Можно прикинуть, например, перспективы ежедневного, еженедельного и ежеквартального переобучения.

Подводя итог - мы можем получить две оценки: скорости устаревания и перспектив улучшения модели от добавления новых данных. С их помощью можно подобрать оптимальную частоту переобучения. Мы сможем обновлять модель только тогда, когда, с одной стороны, действительно ожидается снижение качества, и хватает данных для обновления, с другой.

Так можно сэкономить ресурсы и не усложнять архитектуру сервиса ради необязательного ежедневного переобучения. Либо потратить время на создание такой надежной архитектуры, уже четко понимая, какой прирост к качеству вы за это получаете.

ML-модель в production: переобучать или нет?
Я часто сталкиваюсь с вопросами про необходимость переобучения моделей, дошедших до стадии production. Вопрос справедливый, потому что все мы знаем про особенность практически любых сервисов, основанных на данных - они устаревают и требуют то или иной правки на актуальные данные.

Вы удивитесь, если я скажу, что устаревание моделей - далеко не единственная причина для переобучения😎? Давайте рассмотрим несколько примеров:

1️⃣ Recommender systems - в таких сервисах, особенно если мы говорим про realtime рекомендации, например, музыки, часто требуется онлайн дообучение моделей. Это важно для того, чтобы успевать учитывать последнюю обратную связь от пользователей. Например, последние “дизлайки”, которые могли произойти несколько всего секунд назад! Согласитесь, если пользователю не понравились последние несколько треков, эту обратную связь надо учесть моментально и сразу перестроить последующие рекомендации. Интересно, что не всегда это требует переобучения моделей: модели не устарели, они всё еще актуальны! Но калибровка нужна, причем online.

2️⃣ Search engines - SEO оптимизация не прекращает попыток вмешаться в ранжирование поисковых систем для того, чтобы поднять повыше некоторые результаты в поисковой выдаче. Это нежелательное поведение, с которым требуется бороться на регулярной основе. По этой причине для поисковых сервисов переобучение позволяет не только регулярно улучшать качество ранжирования, но и бороться с нежелательной оптимизацией за счет обновления ранжирующих моделей: под них просто становится сложнее подстроиться. Получается, иногда выгодно обновить модель, даже если новая не отличается по качеству от старой!

3️⃣ Manufacturing (stable processes) - если сервис на основе данных описывает очень стабильный процесс, опирается на надежные датчики и замеры, то возможно такой сервис долго не потребует даже калибровки. В таких случаях обновление может происходить всего несколько раз в год и то, только по событию/запросу, например, в связи с ремонтом оборудования, сменой поставщиков сырья или продуктовой линейки.

4️⃣ Fraud detection - а в таких сервисах, напротив, без регулярных обновлений и переобучений совсем никак. Постоянно появляются новые виды fraud, которые надо учиться детектировать. Причем, делать это нужно очень оперативно.

И это всего несколько примеров! Из-за такого разнообразия не существует единого подхода для обновления сервисов на основе данных. Реализации очень различаются: от небольшой калибровки realtime, до полного перестроения всех моделей offline. В следующем посте (совсем скоро😳) расскажу непосредственно про подходы к переобучению моделей.

Service Health. Прежде всего речь идет о production сервисе, поэтому важно подключить ваш сервис к принятому в компании процессу мониторинга. Пожалуйста, не делайте исключений для ML-моделей! Их надо отправить в мониторинг по общему сценарию: собираем стандартные показатели здоровья сервиса, настраиваем систему оповещений о проблемах, назначаем ответственных лиц и прописываем сценарии реагирования для каждого из типов оповещений.

Data Quality & Integrity. В подавляющем большинстве случаев, если что-то не так с ML-моделью, то ответ найдется во входных данных. Поэтому для стабильной работы сервиса важно настроить валидацию входных данных по содержанию и диапазонам значений, структуре, типу, поведению (статистики, распределения, корреляции…). На этом уровне мониторинг поможет убедиться, что вы подаете на вход модели ровно то, с чем она может работать.

Model Performance. Наверное, если бы мне по какой-то причине нужно было выбрать только один раздел мониторинга, то я бы остановилась на этом, ведь если что-то пошло не так - мы увидим, как поползли вниз метрики качества. Здесь я крайне рекомендую обратить внимание на 3 момента:
⁃ оценка качества моделей в условиях отложенной обратной связи: например, из-за длительного горизонта прогнозирования или задержек в доставке данных.
⁃ однозначность трактовки метрик: ошибка выросла на всём потоке или было несколько выбросов?
⁃ связь метрик качества с бизнес-показателями: ошибка выросла, мы уже начали терять деньги?
Second thought: нет, я бы всё же остановилась на service health, без него вообще странно говорить про production.

Data & Target Drift. Практически любая модель машинного обучения, даже предназначенная для очень стабильного процесса, имеет неприятное свойство: устаревание. Мы обучаем модели на исторических данных, применяем модели к актуальным данным, а мир, как известно, не стоит на месте. По этой причине крайне полезно следить за тем, изменились ли свойства данных или целевой функции, которые использует ваша модель. Это своего рода ранний мониторинг, который способен дать вам сигнал о том, что данные начали меняться и пора адаптировать модель еще до того, как как качество модели значительно снизится.

Case-Specific Metrics. В зависимости от того, какую задачу решает ML-модель, к мониторингу стоит добавить дополнительные разделы. То есть те показатели, которые важны конкретно для вашего кейса. Это могут быть такие показатели, как:
⁃ Segments analysis: на каких группах объектов модель сильнее ошибается, а на каких, наоборот, работает точнее? Как это можно скомпенсировать (постобработка, бизнес-логика)?
⁃ Bias/Fairness: есть ли смещения в прогнозах модели, связанные со смещениями в выборке (гендер, возраст, редкий сорт металла)?
⁃ Outliers: как сервис обрабатывает выбросы, есть ли необходимость отправить их по специальному сценарию (система правил, ручная обработка)?

Ещё, совсем недавно опубликовала статью на towards data science How to break a model in 20 days [English, 15 min] https://towardsdatascience.com/how-to-break-a-model-in-20-days-a-tutorial-on-production-model-analytics-25497e2eab9c?source=social.tw - небольшой туториал на очень простом примере о том, как отловить drift с помощью несложного анализа. Загляните, кому актуально😊
А если у вас тоже нет подписки на Medium🤷‍♀️, то можно сэкономить лимит и забежать за статьёй к нам в блог Evidently AI: https://evidentlyai.com/blog/tutorial-1-model-analytics-in-production

Мониторинг ML-моделей: есть ли специфика?
Разработка сервиса на основе ML-модели сложная задача сама по себе: сбор и предобработка данных, feature engineering, серия экспериментов - и вот у нас в руках (вернее в репозитории😎) качественная модель. После получения модели требуется разработать сервис и интегрировать в него модель - в этом месте тоже задач хватает, ведь можно сразу позаботиться и об автоматизации переобучения, и о реализации fall-back системы…
Интересно, что и на этом работа не заканчивается😅 Когда мы публикуем production-сервис, автоматически встает вопрос о его стабильной работе. Это принципиальный момент, потому что production-решение уже завязано на процессы компании, и каждая ошибка имеет свою цену. Весь спектр от репутационных потерь из-за странных ответов развлекательных сервисов, до серьезных финансовых потерь в случае некорректных рекомендаций в дорогостоящем технологическом процессе.

Я вижу 2 принципиальных шага для снижения рисков, связных с эксплуатацией ML-моделей:
⁃ ✅Приемка (= тестирование + ревью) ML-модели перед выкладкой в prod
⁃ ✅Мониторинг в процессе эксплуатации сервиса

Сегодня говорим про мониторинг. Это актуально для всех, кто уже дошел до стадии production. Надеюсь, что ваша модель еще ни разу капитально не ломалась, и мой пост будет своевременным alarm’ ом👌

Что мониторим?👇

Реализация: Демо великолепно👏 выполнено студентом MADE Владимиром Назаровым в рамках задания по курсу ML.
Ловите ссылку на репозиторий https://github.com/GimmeDanger/mask-detector-bot. Обратите внимание на оформление репозитория 👍 и очень удачный выбор инструментов: для разработки бота была выбрана open source (MIT License) библиотека: https://pypi.org/project/telebot/, модель базируется на нейронной сети YOLOv4: https://github.com/AlexeyAB/darknet Как видите, использование готовых инструментов позволяет сделать хорошее решение за короткий срок.

Реализация демо-стенда с помощью telegram bot
В прошлый раз я поделилась идеей реализации демо-стенда на начальных этапах проекта для того, чтобы проработать требования к сервису, зафиксировать сценарий его использования и, тем самым, повысить шансы на успешную имплементацию решения в дальнейшем.

Сценарий демо != сценарий сервиса: часто сервис может быть задуман в виде десктопного или мобильного приложения, а может и вовсе не иметь визуального интерфейса и предоставлять API для взаимодействия. В таких случаях может показаться, что демо должно повторить дизайн сервиса. Но так ли это? Здесь важно вспомнить, для чего мы вообще беремся за разработку демо: дать возможность членам проектной команды протестировать draft решения, свериться с требованиями, уточнить сценарий. А значит, мы хотим, чтобы демо появилось рано, а тестировать его было легко и удобно. В этом смысле разрабатывать полноценное мобильное приложение и или сервис со сложным API может быть невыгодно сразу по двум причинам:
1. Потребуется большой ресурс на разработку, который может быть не адекватен ресурсам на проект в целом.
2. Сервис будет сложнее тестировать, потребуется генерировать более сложные запросы, чтобы использовать непростой API или разбираться с мобильным приложением с плохим дизайном (времени на разработку ведь было мало, хороший дизайн ни откуда не возьмется🤷‍♀️).

Предлагаю: выбрать самый простой сценарий для взаимодействия c демо и реализовать именно его. Давайте смотреть на пример👇

Детекция маски на лице 😷 (очень актуальный кейс на сегодняшний день, да?)
Обычно, такие сервисы реализуют в виде десктопного приложения с выводом результатов анализа на экран ответственного специалиста. При этом для демонстрации выбран телеграм-бот - и это очень правильно! Бот подходит для демо гораздо лучше приложения, не смотря на то что в итоге требуется разработать именно его.

В чем красота решения:
- Сценарий проще придумать сложно: всё что требуется - загрузить фото и посмотреть на результаты работы модели. Просто, понятно, быстро и очень визуально. Никакой специальной подготовки, установки софта и прочих усилий для тестирования не требуется.
- Отсутствуют специальные требования к исходным данным: практически нет ограничений на ракурс фото, расположение лиц, освещенность и пр. А значит, найти подходящие для тестирования данные будет очень просто, практически любое фото, где видно лицо человека, подойдет.
- Визуальность: результаты работы модели видно сразу, они понятны, а также сценарий содержит элемент геймификации: интересно же загрузить разные фото и посмотреть, что получится!

С осторожностью:
- Мы помним, что демо обычно разрабатываемся на ранней стадии проекта, а значит качественной модели еще может не быть. В данном кейсе некачественная модель могла бы привести к провалу демонстрации как таковой. Фокус был бы сильно смещен в сторону того, что КАК модель работает, а не в сторону того, ЧТО мы бы хотели получить от финального решения. А значит в кейсах, где качество работы модели может мешать анализу основного сценария и каждая ошибка сильно влияет на впечатление о решении, стоит сначала разработать качественную модель. Хотя бы для одного сегмента объектов - например, хорошо освещенные портретные фото с одним человеком.
- Как обычно, когда дело касается людей и их изображений, мы начинаем близко подходить к истории о персональных данных🤷‍♀️ Так что, стоит убедиться, что ничего лишнего сервис не собирает, не хранит и не обрабатывает😎

Подводя итог - хочу сказать DS-специалистам и менеджерам технических проектов, о том, что такая возможность есть. Не стоит ей пренебрегать, потому что работающее демо очень сильно повысит шанс на реализацию успешного кейса, как внутри, так и с внешним заказчиком. Если вы чувствуете, что полного понимания кейса в команде пока нет, у разных специалистов разное видение и ожидания - демо, это лучшее, что можно сделать. И это правда несложно. Если вы DS и освоили построение моделей - у вас точно получится🚀 И когда вы предложите и реализуете демо - коммуникация упростится в разы, а команда это очень оценит.

В прошлом семестре я дала задание разработать демо ML-модели студентам вводного курса по машинному обучению. Задание было дано в декабре приблизительно на 2 недели (как вы понимаете, ресурсы минимальные). Я получила много очень сильных работ, и, к счастью, многие ребята не против поделиться🥳! Так что следующий пост будет про то, какие стенды и какими инструментами можно построить.

Демо-стенд для ML моделей
Как часто проекты, связанные с ML/AI попадают в стол? На моей практике, такое происходит в компаниях регулярно, независимо от профиля и размеров. Сначала мучительно долго собираются данные, дальше следует итерационный процесс моделирования, который завершается замером качества модели (чтобы это ни значило), а в конце выясняется, что модель в таком виде просто невозможно использовать🤷‍♀️. Звучит знакомо?

У подобного много причин, поэтому обобщу: для многих участников проекта ML-модель - не очень понятная сущность, представления о которой могут быть довольно далеки от реальности. И дело здесь не в том, что не все могут строить модели. В зависимости от конкретной задачи, имеющихся данных, сценария применения, свойства и качество модели могут быть весьма своеобразными.

Поэтому хорошо скорректировать представление о том, какая модель может получиться в рамках имеющихся ограничений. И демо-стенд - прекрасное решение. Демо-стенд - минималистичный сервис с ML-моделью, поднятый независимо от остальной архитектуры. Такой сервис смогут потестировать все, кому это требуется в рамках проекта: это может быть html-страничка, мобильное приложение, чат-бот, ещё что-то очень простое.

Реализация 👩‍💻: в качестве backend выступает ML-модель, причем baseline версии вполне достаточно. Не нужно оптимизировать модель до финального состояния, можно остановиться на самой простой работающей версии. Для демо чаще всего нужен frontend. Здесь всё зависит от того, какую задачу вы решаете, и как вы видите сценарий взаимодействия пользователей с демо. Повторюсь, легковесной html-странички или телеграм-бота чаще всего достаточно - главное наличие готовых, простых шаблонов и минимальная разработка. На сегодняшний день, у нас есть огромное количество инструментов, позволяющих легко публиковать модели. Среди моих студентов этого года любимым инструментом стал Streamlit, и, конечно, ребята откопали ещё очень много всего, некоторые библиотеки меня приятно удивили :)

Ресурсы💰: минимальны, если знать правильные инструменты. Это не задача для разработчиков, это задача data scientist (DS), причем того, кто занимается разработкой модели. Без учета времени на сбор и предобработку данных (что справедливо, ведь это придется сделать независимо от того, захотите ли вы реализовать демо-стенд) разработка у middle DS займет в среднем не больше 1-2 рабочих дней. Junior DS в первые пару раз может провозиться неделю.

Плюсы 💪: возможность взаимодействия с сервисом на самых ранних стадиях проекта. Можно проводить тестирование, анализировать сценарии взаимодействия, прикидывать варианты интеграции, менять содержание и формат прогнозов/рекомендаций модели, играть с горизонтом прогнозирования и массой других свойств. Другими словами - получится содержательно собрать и скорректировать требования к модели для того, чтобы в дальнейшем использовать её в production. Или понять, что задача не летит, до того, как в неё были вложены месяц-другой работы.

Минусы 😓: на мой взгляд, основной минус всего один - не все кейсы можно продемонстрировать, не имея финальную модель. Например, если модель для сервиса определения возраста человека по фото пока с трудом определяет, где лицо - это почти гарантированный провал демонстрации. Получается, сначала надо добить модель по качеству, а значит, к моменту, когда вы сможете построить демо, довольно много ресурсов уже будет вложено в проект. Обидно будет отправить модель в стол в случае, если она не подойдет. Эту ситуацию решить тоже можно, но это уже другая история, так что просто имейте в виду.

Привет всем, кто подписался 👋

Я - Эмели Драль. Кто-то из вас может знать меня как своего преподавателя на курсе по ML, преподавателя на Coursera или соавтора Data Mining in Action.

Меня давно спрашивали, можно ли на меня где-то подписаться, чтобы узнавать что-нибудь интересное про ML. Теперь есть телеграм-канал! Я буду здесь делиться информацией про машинное обучение и анализ данных: интересные решения и технологии, удачные кейсы, новые библиотеки и стартапы, немного про образование.
Рассчитываю, что это будет интересно аналитикам, ML инженерам, менеджерам технических проектов и всем, кто так или иначе работает с темой Data Science или только её изучает.

Channel created