На этой неделе случилась накладка с темой, а потом еще одна накладка с запасной темой, а потом … Ну вы поняли) Поэтому придется импровизировать
Недавно натыкался на такой текст
AI For Business: Myths And Realities
и возникла мысль устроить завтра обсуждение на тему мифы и реальность в ML/DS проектах.
На мой внезапный призыв любезно откликнулся Максим Гончаров (руководитель направления прогнозной и оптимизационной аналитики, GlowByte AA), так что нас уже двое и дискуссии быть)
А с какими мифами ML/DS сталкивались вы?
Пишите в чат и приходите завтра (8 июля) дискутировать, как обычно в 21:00 МСК в голосовом чате.
Недавно натыкался на такой текст
AI For Business: Myths And Realities
и возникла мысль устроить завтра обсуждение на тему мифы и реальность в ML/DS проектах.
На мой внезапный призыв любезно откликнулся Максим Гончаров (руководитель направления прогнозной и оптимизационной аналитики, GlowByte AA), так что нас уже двое и дискуссии быть)
А с какими мифами ML/DS сталкивались вы?
Пишите в чат и приходите завтра (8 июля) дискутировать, как обычно в 21:00 МСК в голосовом чате.
Forbes
AI For Business: Myths And Realities
There is a lot of hype around AI, but for a business new to AI, there is little information about how to get started and how to generate the first dollar of ROI from an AI project. We share common myths, practical realities, and how to get started.
В этот четверг, 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 для DS/ML в 2021?
🔥 Известен такой тезис: “Если ML и AI то Python, если статистика и анализ данных то R”. Попробуем разобраться поподробнее что лучше в каких задачах.
🔥 Действительно ли вопрос стоит как R vs. Python? Или оптимальным вариантом является построение гетерогенной среды, в которой для решения одной задачи используется и Python, и R и даже Julia?
🔥 Какие организационные и технические вызовы возникают в связи с предыдущим пунктом? Как достичь воспроизводимости результатов внутри команды DS и выстроить унифицированные MLOps процессы совместно с IT в условиях такой гетерогенной среды моделирования?
Учатсники дискуссии:
🥷Андрей Макеев, бизнес-архитектор по аналитике, Комус;
🥷Максим Гончаров, руководитель направления прогнозной и оптимизационной аналитики, GlowByte Advanced Analytics;
🥷🥷🥷А также все желающие
Встречаемся, как обычно, здесь в голосовом чате.
С чем из перечисленного приходилось сталкиваться в контексте задач DS/ML?
Anonymous Poll
89%
Python
43%
R
18%
C/C++
11%
Java
16%
Scala
3%
Julia
19%
MATLAB
32%
SAS
16%
SPSS
6%
Другое
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
Встречаемся как всегда в голосовом чате нашего сообщества.
В следующий четверг, 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
Встречаемся как всегда в голосовом чате нашего сообщества.
Forwarded from Клуб CDO (Denis Afanasev)
небольшая обхорная статья по теме Federated Learning, не менее популярная сейчас тема чем Data Mesh
https://towardsdatascience.com/federated-learning-a-new-ai-business-model-ec6b4141b1bf
https://towardsdatascience.com/federated-learning-a-new-ai-business-model-ec6b4141b1bf
Medium
Federated Learning: A New AI Business Model
Federated learning is not only a promising technology but also a possible brand new AI business model. Indeed, as a consultant, I have…
Подборка статей из блога GlowByte от команд практики Data Management
📌 Про кейс DWH в Газпромбанке: Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop
📌 Про гибкие хранилища, а именно, про подходы Data Vault и Anchor Model: Обзор гибких методологий проектирования DWH
📌 Про стриминг на Kafka: Почему стриминг на KSQL и Kafka Streams - это непросто
📌 Про кейс DWH в Газпромбанке: Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop
📌 Про гибкие хранилища, а именно, про подходы Data Vault и Anchor Model: Обзор гибких методологий проектирования DWH
📌 Про стриминг на Kafka: Почему стриминг на KSQL и Kafka Streams - это непросто
Forwarded from Клуб CDO (Denis Afanasev)
И еще немного про 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 Lake и тп. Читаешь статьи, вроде много букв везде, а вот понимание не складывается. И вот проштудировал еще раз основной источник на сайте Мартина Фаулера (см ниже) и вот родилось такое понимание:
Data Mesh в первую очередь это организационная концепция, а не техническая. Она говорит о том, что мы децентрализуем ОТВЕТСТВЕННОСТЬ за данные между разными командами, обеспечивая их нужным (даже централизованным) техническим инструментарием, для того, что бы они эту ответственность могли осуществлять.
Вот в чем суть - основные проблемы во всех больших проектах DHW/DL это больше организационные проблемы взаимодействия разных команд, а не техническое проблемы обработки данных, и Data Mesh предлагает нам концепцию, по которой каждая команда, которая производит данные, должна быть ответственной за переиспользование этих данных другими командами, что бы катализировать использования данных в организации.
Реализации этой концепции требует:
⁃ В первую очередь организации изменения - изменения культуры, формирования новых KPI, поддержки со стороны руководства и тд.
⁃ Во вторую очередь процессные изменения - процессы Data Goverence, обеспечивающие “правила игры” общие для всех команд
⁃ В третью очередь технические изменения - нужно эти команды обеспечить технической возможностью выполнять новую функцию (хранить данные обрабатывать), а так же поддержать технически функции типа Data Discovery и прочие из пункта 2. И это очень важно сделать при реализации данного подхода.
И еще раз подчеркну, что технические решения из третьего пункта могут быть вполне себе централизованными Data Lake, если это экономически и технически обосновано.
Вот такие у меня сложились персональные выводы на текущий момент.
https://martinfowler.com/articles/data-monolith-to-mesh.html
martinfowler.com
How to Move Beyond a Monolithic Data Lake to a Distributed Data
Mesh
Mesh
There are problems with the centralized data lake. A future data mesh needs domains, self-service platforms, and product thinking.
В прошлый четверг в экспертной комнате упоминали про 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: как работать с данными без монолита
Про опыт построения 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 МСК в голосовом чате сообщества.
В повестке обсуждения следующие вопросы
❓ 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, может быть эта та часть платформы данных с которой можно начать этот путь.
Небольшая выжимка про основные 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
🔸 Feast
🔸 Tecton
🔸 Hopsworks
🔸 Rasgo
🔸 Iguazio
🔸 Kaskada
🔸 Amazon SageMaker Feature Store
🔸 dotData, правда в какой-то момент они переобулись в термин AutoFE - Automated Feature Engineering
🔸 Butterfree - фреймворк для разработки FS
А с чем вам приходилось сталкиваться, если работали с FS?
Anonymous Poll
47%
Feast
10%
Tecton
20%
Hopsworks
3%
Rasgo
7%
Iguazio
3%
Kaskada
17%
SageMaker FS
3%
dotData
0%
Butterfree
47%
Другое
11 августа намечается митап по теме ML Data Engineering: apply(meetup), организованный Tecton.ai. Заявленные темы выглядят интересно.
Tecton
apply() | Tecton
The Machine Learning Virtual Conference Series
Недавно сходили на конференцию Scoring Case Forum. И наслушались про тенденции в скоринге, и сами сделали доклад про тренды анализа данных и моделирования в кредитных рисках. Продолжим рассуждать на эти темы в нашей экспертной комнате.
Собираемся в четверг, 5 августа в 21:00 МСК в голосовом чате и обсуждаем:
📌 Новое в скоринговых моделях: применяются все более сложные методы, адаптируются методы интерпретируемости и объяснимости, осваивается применение новых направлений: контролируемые эксперименты, causal inference, опережающие метрики, методы оптимизации, и в целом наблюдается переход от дескриптивной и прогнозной аналитики к прескриптивной.
📌 Новое в работе с данными для скоринга: новые источники данных и подходы по их анализу; преодоление барьера связанного с ограничениями структурированных данных.
📌 Опыт коронакризиса для стабильности скоринговых моделей: как поменялись подходы к валидации, оценке стабильности и калибровке? Как изменился ландшафт данных и ключевых источников данных? Как обучать модели в период неопределенности и изменяющемся пространстве целевых переменных?
📌 Проникновение методов моделирования кредитных рисков как в другие направления финансовых рисков, так и вообще из финансового сектора в другие индустрии: промышленность, телеком, ритейл.
⏳ А если останется время, поговорим еще на такие темы как управление модельным риском, валидация моделей и MLOps в контексте скоринга.
Участники дискуссии:
😎 Юлия Чехлова, Управляющий директор службы кредитных процедур КИБ и СБМ, ВТБ
😎 Дмитрий Сергиенко, Заместитель начальника Управления анализа розничных кредитных рисков, Банк России
😎 Алиса Пугачева, Бизнес-аналитик, эксперт по моделированию кредитных рисков, GlowByte Advanced Analytics
😎 Александр Бородин, Руководитель направления аналитики и моделирования в финансах и рисках, GlowByte Advanced Analytics
Собираемся в четверг, 5 августа в 21:00 МСК в голосовом чате и обсуждаем:
📌 Новое в скоринговых моделях: применяются все более сложные методы, адаптируются методы интерпретируемости и объяснимости, осваивается применение новых направлений: контролируемые эксперименты, causal inference, опережающие метрики, методы оптимизации, и в целом наблюдается переход от дескриптивной и прогнозной аналитики к прескриптивной.
📌 Новое в работе с данными для скоринга: новые источники данных и подходы по их анализу; преодоление барьера связанного с ограничениями структурированных данных.
📌 Опыт коронакризиса для стабильности скоринговых моделей: как поменялись подходы к валидации, оценке стабильности и калибровке? Как изменился ландшафт данных и ключевых источников данных? Как обучать модели в период неопределенности и изменяющемся пространстве целевых переменных?
📌 Проникновение методов моделирования кредитных рисков как в другие направления финансовых рисков, так и вообще из финансового сектора в другие индустрии: промышленность, телеком, ритейл.
⏳ А если останется время, поговорим еще на такие темы как управление модельным риском, валидация моделей и MLOps в контексте скоринга.
Участники дискуссии:
😎 Юлия Чехлова, Управляющий директор службы кредитных процедур КИБ и СБМ, ВТБ
😎 Дмитрий Сергиенко, Заместитель начальника Управления анализа розничных кредитных рисков, Банк России
😎 Алиса Пугачева, Бизнес-аналитик, эксперт по моделированию кредитных рисков, GlowByte Advanced Analytics
😎 Александр Бородин, Руководитель направления аналитики и моделирования в финансах и рисках, GlowByte Advanced Analytics
Записи докладов коллег из GlowByte Advanced Analytics на Scoring Case Forum:
📺 Александр Бородин и Алиса Пугачева - ML/DS тренды в скоринге
📺 Бонус: Александр Кухтинов и Владислав Даниленко - Мастер класс про 5 столпов платформы ML/MLOps=)
📺 Александр Бородин и Алиса Пугачева - ML/DS тренды в скоринге
📺 Бонус: Александр Кухтинов и Владислав Даниленко - Мастер класс про 5 столпов платформы ML/MLOps=)
📌 Свежая статья от коллег из GlowByte Advanced Analytics про валидацию моделей.
📌 Также дублирую в канал статью из блога ВТБ про Model Performance Predictor. Спасибо @vkost за наводку=)
📌 Также дублирую в канал статью из блога ВТБ про 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)
📄 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)