На этой неделе случилась накладка с темой, а потом еще одна накладка с запасной темой, а потом … Ну вы поняли) Поэтому придется импровизировать

Недавно натыкался на такой текст
AI For Business: Myths And Realities
и возникла мысль устроить завтра обсуждение на тему мифы и реальность в ML/DS проектах.

На мой внезапный призыв любезно откликнулся Максим Гончаров (руководитель направления прогнозной и оптимизационной аналитики, GlowByte AA), так что нас уже двое и дискуссии быть)

А с какими мифами ML/DS сталкивались вы?
Пишите в чат и приходите завтра (8 июля) дискутировать, как обычно в 21:00 МСК в голосовом чате.

В этот четверг, 15 июля, в 21:00 МСК нас ждет эпичная битва за Царство ML/DS: R vs. Python💥

В повестке встречи:
🔥 Стоит ли изучать R для DS/ML в 2021?
🔥 Известен такой тезис: “Если ML и AI то Python, если статистика и анализ данных то R”. Попробуем разобраться поподробнее что лучше в каких задачах.
🔥 Действительно ли вопрос стоит как R vs. Python? Или оптимальным вариантом является построение гетерогенной среды, в которой для решения одной задачи используется и Python, и R и даже Julia?
🔥 Какие организационные и технические вызовы возникают в связи с предыдущим пунктом? Как достичь воспроизводимости результатов внутри команды DS и выстроить унифицированные MLOps процессы совместно с IT в условиях такой гетерогенной среды моделирования?

Учатсники дискуссии:
🥷Андрей Макеев, бизнес-архитектор по аналитике, Комус;
🥷Максим Гончаров, руководитель направления прогнозной и оптимизационной аналитики, GlowByte Advanced Analytics;
🥷🥷🥷А также все желающие

Встречаемся, как обычно, здесь в голосовом чате.

Продублирую статью от Ирины в канал
Совмещение R и Python: зачем, когда и как?

Data Warehouse, Data Lake, Data Vault, Data Lakehouse, Data Fabric, Data Mesh, Data Lab, Data Hub, DataOps, Data Governance ... ну и конечно же Big Data=)

В следующий четверг, 22 июля в 21:00 МСК совместно с авторами канала Клуб CDO будем разбираться, что означают все эти слова, и как заложить крепкий фундамент для успешных ML/DS проектов в виде современной Data Management платформы. В повестке встречи следующее:
📌 Эволюция подходов в технологиях построения Data Management систем и методологиях Data Governance.
📌 Плюсы и минус централизации и децентрализации управления корпоративными данными, как обычно будем искать истину где-то посередине)
📌 Технологические аспекты и грани децентрализованной обработки и хранения данных, вспомним про Data Federation и обсудим новомодный Data Fabric.
📌 Как Ops добрался до данных и аналитики: процессы, роли и инструменты DataOps.
📌 Без качественных данных качественную ML модель не построить. Как решается задачи Data Quality с точки зрения современных технологий и методологий.

Наши эксперты-спикеры:
😎 Денис Афанасьев, Head of TechPlatforms в SberDevices, основатель CleverDATA
😎 Дмитрий Инокентьев, Архитектор Data платформ, GlowByte Consulting
😎 Сергей Абрамов, Head of Feature&ML Engineering, GlowByte Advanced Analytics
😎 Дмитрий Бутаков, Архитектор Data&ML платформ GlowByte Advanced Analytics

Встречаемся как всегда в голосовом чате нашего сообщества.

небольшая обхорная статья по теме Federated Learning, не менее популярная сейчас тема чем Data Mesh

https://towardsdatascience.com/federated-learning-a-new-ai-business-model-ec6b4141b1bf

Подборка статей из блога GlowByte от команд практики Data Management

📌 Про кейс DWH в Газпромбанке: Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop
📌 Про гибкие хранилища, а именно, про подходы Data Vault и Anchor Model: Обзор гибких методологий проектирования DWH
📌 Про стриминг на Kafka: Почему стриминг на KSQL и Kafka Streams - это непросто

И еще немного про Data Mesh

Немного мыслей тут родилось про Data Mesh. Тема популярная, все начинают вокруг говорить о том, что они применяют этот подход, реализуют проекты и тд. Тем не менее все время не могу уловить какую “суть” этого подхода, какую то формулировку, которая в простой форме объяснит основное отличие от предыдущих концепций, типа Data Lake и тп. Читаешь статьи, вроде много букв везде, а вот понимание не складывается. И вот проштудировал еще раз основной источник на сайте Мартина Фаулера (см ниже) и вот родилось такое понимание:

Data Mesh в первую очередь это организационная концепция, а не техническая. Она говорит о том, что мы децентрализуем ОТВЕТСТВЕННОСТЬ за данные между разными командами, обеспечивая их нужным (даже централизованным) техническим инструментарием, для того, что бы они эту ответственность могли осуществлять.

Вот в чем суть - основные проблемы во всех больших проектах DHW/DL это больше организационные проблемы взаимодействия разных команд, а не техническое проблемы обработки данных, и Data Mesh предлагает нам концепцию, по которой каждая команда, которая производит данные, должна быть ответственной за переиспользование этих данных другими командами, что бы катализировать использования данных в организации.

Реализации этой концепции требует:
⁃ В первую очередь организации изменения - изменения культуры, формирования новых KPI, поддержки со стороны руководства и тд.
⁃ Во вторую очередь процессные изменения - процессы Data Goverence, обеспечивающие “правила игры” общие для всех команд
⁃ В третью очередь технические изменения - нужно эти команды обеспечить технической возможностью выполнять новую функцию (хранить данные обрабатывать), а так же поддержать технически функции типа Data Discovery и прочие из пункта 2. И это очень важно сделать при реализации данного подхода.

И еще раз подчеркну, что технические решения из третьего пункта могут быть вполне себе централизованными Data Lake, если это экономически и технически обосновано.

Вот такие у меня сложились персональные выводы на текущий момент.

https://martinfowler.com/articles/data-monolith-to-mesh.html

В прошлый четверг в экспертной комнате упоминали про Data Mesh в Леруа Мерлен. Небольшая подборка по этой теме.

Про опыт построения Data платформы и путь к Data Mesh - интервью с CDO Леруа Мерлен Дмитрием Шостко:
📌 Data Mesh в «Леруа Мерлен»: DIY в работе с данными

Доклад Дмитрия Шостко на Data Fest 2020:
📺 Как построить Data Mesh в организации

Про архитектурный стек платформы данных в Леруа Мерлен:
1️⃣ Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей
2️⃣ Платформа данных в Леруа Мерлен. Part 2. Обновления 2021 года: Flink и Superset



P.S.: А еще про путь к Data Mesh в Dodo Pizza:
🍕 Data Mesh: как работать с данными без монолита

В этот четверг продолжим обсуждать тему управления данными, но в более узком смысле, а именно, поговорим про платформы данных непосредственно для ML/DS и такую тему как Feature Store.

В повестке обсуждения следующие вопросы
❓ Feature Store определяют как интерфейс между моделями и данными. Почему бурный рост интереса к теме наблюдается именно сейчас?
❓ Почему Feature Store - необходимая часть современной ML/MLOps платформы, и как технологии и подходы Feature Store позволяют ускорить продуктивизацию ML/AI решений?
❓ Каталогизация переменных, управление производными переменными, консистентность данных разработки и применения, версионирование датасетов и переменных, операционализация переменных… Какие еще задачи должен решать идеальный Feature Store?
❓ Как выглядит типовая архитектура Feature Store и его место в ML & Data платформе?
❓ Снова про качество данных, как организовать мониторинг переменных и пайплайнов данных для ML?
❓ Рынок решений Feature Store 2021: какие есть инструменты от вендоров и с открытым исходным кодом?

Участники дискуссии:
Команда GlowByte Advanced Analytics
😎 Сергей Абрамов
😎 Михаил Зайцев
😎 Павел Снурницын
И все, кто захочет присоединиться
🧐🧐🧐

Встречаемся 29 июля в 21:00 МСК в голосовом чате сообщества.

Отличная статья от tecton.ai с описанием типового, если так уже можно говорить, Feature Store: What is a Feature Store?

Небольшая выжимка про основные 5 компонентов FS с мыслями и дополнениями:

Storage - компонент отвечающий за управление хранением, я бы добавил что именно управление, потому что хочется иметь возможность гибко хранить датасеты и фичи в различных СХД (в том числе в нескольких одновременно). Одна из самых важных фишек FS - версионировании не только на уровне датасетов, но и на уровне индивидуальных переменных, чтобы когда мы корректировали расчет какого-то атрибута, не приходилось сразу переобучать все десятки моделей в проде которые на него завязаны, это можно делать постепенно.

Transform - расчет производных атрибутов, концепция отлично описана, но интересно, что среди всех увиденных на текущий момент FS почти нигде нет полноценной реализации этого компонента, а именно гибкой и удобной библиотеки трансформов, которую можно сравнительно просто пополнять новыми функциями. Все мы наверняка сталкивались с такой историей, что обычно при построении витрины для моделирования у нас есть на вход сотни уникальных по смыслу переменных, которые мы превращаем в тысячи и десятки тысяч фич через агрегации по различным временным срезам, категориям и т.д. А еще есть типовые агрегаты над не классическими данными - графы, временные ряды, гео, текст, звук, изображения, … вполне себе можно хотеть управлять всеми трансформами над всеми типами данных в одном месте.

Serving - собственно публикация и внедрение переменных. Важная функция этого компонента: сохранение консистентности переменных между данными обучения и применения моделей, это достигается как раз за счет введения уровня абстракций для алгоритмов формирования фич на уровне FS.
Единственно что, как и со Storage, не очень соглашусь с предлагаемой концепцией о том, что FS именно сёрвит хранящиеся внутри него фичи. С одной стороны это хороший тренд, как раз та самая микросервисная архитектура данных о которой говорили в прошлый четверг, за счет которой достигается консистентность данных. С другой стороны всегда будет возникать потребность именно раскатать расчет фич в отдельно стоящую систему применения, например, в случаях IoT и Edge, а от FS хочется возможности управлять этим процессом для различных систем применения и иметь возможно сравнительно просто добавлять новые адаптеры для новых систем.

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

Registry - каталогизация переменных и датасетов с их метаданными с возможностью делать различные представления по доменам, одна из основных фишек - дать возможность удобного поиска и exploration переменных в этом репозитории. Ну и в целом registry - это центральная часть FS, которая хранит всю информацию обо всем связанном с данными для ML.
Важное требование, которое не особо отмечено в статье: разграничение доступов для различных ролей и пользователей и на уровне Registry и на уровне Storage, все таки не всем можно видеть абсолютно все домены данных.


Вообще про Feature Store и его место в платформе данных видится некий локально-глобальный принцип: по сути Feature Store решает задачу Data Governance локально для данных для ML, есть и lineage, и каталог, и качество данных. Также есть и децентрализации управления этими данными, опять же на локальном уровне, участники команды готовят, публикуют и поддерживают фичи каждый в своем домене и сравнительно независимо друг от друга. И тут возникает такая мысль: все таки и задачу DG очень тяжело решить глобально на уровне большой организации, также тяжело реализовать глобально подходы децентрализации, такие как Data Mesh, но эти задачи выглядят вполне обозримо и решаемо в концепции Feature Store, то есть только в части данных для ML/DS, может быть эта та часть платформы данных с которой можно начать этот путь.

Решения класса Feature Store, за которыми мы в команде GlowByte Advanced Analytics активно следим:
🔸 Feast
🔸 Tecton
🔸 Hopsworks
🔸 Rasgo
🔸 Iguazio
🔸 Kaskada
🔸 Amazon SageMaker Feature Store
🔸 dotData, правда в какой-то момент они переобулись в термин AutoFE - Automated Feature Engineering
🔸 Butterfree - фреймворк для разработки FS

11 августа намечается митап по теме ML Data Engineering: apply(meetup), организованный Tecton.ai. Заявленные темы выглядят интересно.

Недавно сходили на конференцию Scoring Case Forum. И наслушались про тенденции в скоринге, и сами сделали доклад про тренды анализа данных и моделирования в кредитных рисках. Продолжим рассуждать на эти темы в нашей экспертной комнате.

Собираемся в четверг, 5 августа в 21:00 МСК в голосовом чате и обсуждаем:
📌 Новое в скоринговых моделях: применяются все более сложные методы, адаптируются методы интерпретируемости и объяснимости, осваивается применение новых направлений: контролируемые эксперименты, causal inference, опережающие метрики, методы оптимизации, и в целом наблюдается переход от дескриптивной и прогнозной аналитики к прескриптивной.
📌 Новое в работе с данными для скоринга: новые источники данных и подходы по их анализу; преодоление барьера связанного с ограничениями структурированных данных.
📌 Опыт коронакризиса для стабильности скоринговых моделей: как поменялись подходы к валидации, оценке стабильности и калибровке? Как изменился ландшафт данных и ключевых источников данных? Как обучать модели в период неопределенности и изменяющемся пространстве целевых переменных?
📌 Проникновение методов моделирования кредитных рисков как в другие направления финансовых рисков, так и вообще из финансового сектора в другие индустрии: промышленность, телеком, ритейл.
⏳ А если останется время, поговорим еще на такие темы как управление модельным риском, валидация моделей и MLOps в контексте скоринга.

Участники дискуссии:
😎 Юлия Чехлова, Управляющий директор службы кредитных процедур КИБ и СБМ, ВТБ
😎 Дмитрий Сергиенко, Заместитель начальника Управления анализа розничных кредитных рисков, Банк России
😎 Алиса Пугачева, Бизнес-аналитик, эксперт по моделированию кредитных рисков, GlowByte Advanced Analytics
😎 Александр Бородин, Руководитель направления аналитики и моделирования в финансах и рисках, GlowByte Advanced Analytics

Записи докладов коллег из GlowByte Advanced Analytics на Scoring Case Forum:
📺 Александр Бородин и Алиса Пугачева - ML/DS тренды в скоринге
📺 Бонус: Александр Кухтинов и Владислав Даниленко - Мастер класс про 5 столпов платформы ML/MLOps=)

📌 Свежая статья от коллег из GlowByte Advanced Analytics про валидацию моделей.
📌 Также дублирую в канал статью из блога ВТБ про Model Performance Predictor. Спасибо @vkost за наводку=)

Отчёт от Deloitte, на который ссылался @alexander_borodin ближе к концу нашей дискуссии в прошедший четверг:
📄 Credit risk modeling during the COVID-19 pandemic: Why models malfunctioned and the need for challenger models

В отчёте речь про США и больший фокус все таки на CECL, но в целом есть что почерпнуть и для IFRS9. Рассмотрены и систематизированы ряд вызовов для моделей CECL и IFRS9, связанные с COVID-19: резкий экономический спад в ряде отраслей и рост безработицы, гос. поддержка ЮЛ и ФЛ и всплеск выплат, а также на порядок увеличивающаяся доля договоров, по которым происходит отсрочка платежа. Все это влияет на учет макроэкономических факторов и оценку рисков в парадигме CECL и IFRS9.

Во второй части отчёта рассмотрен кейс построения альтернативной модели (модели претендента) с подходом, который позволяет сгладить описанные эффекты и не отбрасывать модели в крайние/экстремальные прогнозы и за пределы их примости.


P.S.: Отчёт типа такого адресован скорее специалистам, уже работающим в теме рисков. Для тех, кто столкнется в тексте с не очень знакомыми терминами и кто хочет погрузиться в тему моделирования кредитных рисков, напоминаем про пару книг, которые рекомендовали когда-то ранее в канале:

📕 Введение в тему: Bart Baesens, Daniel Roesch, Harald Scheule. Credit Risk Analytics (2016) + дополнение на R: Credit Risk Analytics: The R Companion
📗 Дальнейшее погружение, как раз в IFRS9 и CECL: Bellini Tiziano. IFRS 9 and CECL Credit Risk Modelling and Validation (2019)

В этот четверг (12 августа) поговорим про методы оптимизации.

❗️ Внимание ❗️ обсуждение состоится в другое время, чем обычно, а именно в 15:00 МСК.

Теме оптимизационных методов уделяется как-то недостаточно внимания в современных приложениях наук о данных. При текущих тенденциях роста количества моделей, а также усложнения самих моделей и архитектур решения бизнес задач с применением ML можно ожидать, что методы оптимизации будут выходить на первый план. Мы уже писали не раз, что в нашей практике мы пропагандируем подход, согласно которому бизнес задачи в проектах ML/DS можно изначально сводить к задачам оптимизации, то есть декомпозировать рассматриваемый процесс принятия решений на отдельные компоненты, далее понимать в каких компонентах применимы прогнозные модели, а в каких - бизнес правила, какие есть управляющие воздействия и ограничения. А финальное принятие решения (на самом деле серия связанных решений) делается на основе оптимизационной модели, которая работает поверх этих компонент.

Темы, про которые хотим рассказать:

🟧 Бизнес-кейсы, в которых чаще всего возникают оптимизационные задачи. Особенности постановки оптимизационных задач для:
🔸 целевого маркетинга;
🔸 ценообразования, планирования промо, ассортиментного планирования;
🔸 транспорта, логистики и управления запасами;
🔸 графикования и составления сложных расписаний.

🟧 Как оптимизаторы работают с прогнозными моделями? Когда лучше иметь заранее рассчитанные отклики среды, а когда необходим интерактивный вызов прогнозной модели? Как работать с моделями "черными ящиками"?

🟧 Классификация оптимизационных солверов по задачам:
🔸 смешанно целочисленные линейные;
🔸 комбинаторные;
🔸 непрерывно-нелинейные;
🔸 смешанно-целочисленные нелинейные;
🔸 невыпуклые и недифференцируемые;
🔸 а также глобальная оптимизация с помощью генетических методов и методов колонии активных агентов

🟧 Использование методов оптимизация в Reinforcement Learning для непрерывного расчета оптимальных воздействий

🟧 Оригинальные идеи и наработки направления прогнозной и оптимизационной аналитики GlowByte AA в области MINLP и комбинаторной “black box” - оптимизации

В эфире:
😎 Максим Гончаров, самый главный за прогнозную и оптимизационную аналитику в GlowByte Advanced Analytics

Встречаемся как обычно в голосовом чате.