Иван, добрый день. Благодарю за внимание к нашей статье. Про мишуру - это ваше оценочное суждение, а вот вопросы в конце, действительно конструктивные и я с радостью на них отвечу.
К сожалению, работая в банке, я очень ограничен в дискуссиях о цифрах. Скажу так, в онлайне это только десятки на розницу (не считая каких-то сервисных api), в батче это под сотню в одном только cvm направлении. Нагрузку, в принципе, можно как-то из этого прикинуть и без разглашения мной nda. Взять с банки ру объемы кредитования, и по статистике цб прикинуть объем одобрений и выдач. Плюс накинуть какой-то ctr. Тут же важен порядок цифр скорей вам для понимания.
Нейронок у нас в процессах, как раз, не так много. Значительно больше бустингов. Я в статье писал, зачем бизнесово мы калибруем модели… так вот веса калибровки большой базы какой-нибудь изотонической регрессией над бустингом весят за 100 мб. Конечно, можно и лог регом откалиброваться, но в конкретных сегментах мат ожидание может поехать. А 100 мб уже накладно каждый раз в чистом гите перезаписывать на большом скоупе моделей, и это пример только одного из кейсов. По накладным расходам чистый бустинг и лог рег (на структурированных данных) примерно равны. Но есть класс задач, например, NLP или сегментация изображений, где лог реги не справятся, вы это знаете лучше меня) тут это больше рнд, которое мы ранее окупили бустингами и лог регами.
Эффекты мы регулярно замеряем и подверждаем на пилотах (в форматах: старая VS новая модели или модель VS бизнес руллы), это хорошие деньги и команду с подобными проектами они окупают многократно, к тому же наши эффекты от моделей периодически аудируют;) Добавлю, что с резким ростом ставки, данная доработка была как никогда актуальна, поэтому главная метрика это ТТМ выкатки новых весов и скорость реакции на волатильность.
Насколько я понял проблема не в сложности системы и генерируемых ею данных, а в их бессистемности и даже противоречивости, но на бытовом уровне это назвали бы "кривыми" данными, и соответственно, система которая их генерирует тоже кривая.
Это отчасти так. Система отдает свои данные КХД. И тут как минимум на 3х этапах может что-то сломаться:
1) На самой системе источнике.
2) При переливке данных источника.
3) При их агрегации и обогащении в кхд.
Как я уже говорил, человеческий фактор, как одна из причин "кривизны" может произойти на любом этапе.
По сути вы описываете как выпрямлять кривые данные, не пытаясь исправить (или проанализировать) источник кривизны в системе.
К сожалению, в больших компаниях, я как конечный потребитель данных могу написать только тикет в систему источник. Но, если вы внимательно читали статью, то мы по значимости статистик уже можем подсветить в тикете, что именно произошло, тем самым ускорив процесс разбора инцидента.
у вас есть причины этим заниматься, например просто нет перспектив что вам за это заплатят, или просто кто то оценит.
Предлагаю продолжать дискуссию только в рамках материалов статьи, а не обсуждать субъективные оценки чьей-то работы.
Вы продвигаете методы улучшения качества данных, вам в принципе выгодно что бы данные были кривоватые, иначе ваша работа не будет востребована.
Мне выгодно, чтобы мои модели работали с заявленным качеством прогноза, а данное решение родилось просто как самостоятельный ресерч.
В этом смысле это такая сомнительная цель и технология, мне кажется.
Кажется, что мы просто смотрим на проблему с разных углов. Вы смотрите как системный архитектор систем, а не как аналитик данных.
К сожалению, реальность такова, что корпоративные хранилища данных в организациях развиваются уже на протяжении многих лет и без сложной логики в них в какой-то момент не обойтись. И тут вы либо делайте простые агрегаты и соответственно простые модели, либо более сложные и модель приносит больше эффекта в деньгах.
Плюсом ко всему, даже при самой простой архитектуре, никто не отменял ошибки, связанные, например, с человеческим фактором.
Таким образом, не важно, какая сложность у вас в системе, с качеством данных придется поработать...
Успешность кампании определяет разница между контрольной и тестовой группы. В зависимости от бизнес задачи мы замеряем ATE (average treatment effect) по отклику, оттоку, балансам и тд.
Почему решили, что «у клиентов подозрения на аномальность»? Регулярно проверяя данные ручками, находились различные коллизии... Например, ставка ЦБ не поменялась, но какой-то показатель по балансам резко скакнул раза в 2. Мы понимаем, что такого быть не может и проблема именно с качеством данных, а не в макроэкономике.
Не смотря на то, что были проблемы с качеством данных, модель по которой отбирались клиенты в тестовую группу оказалась эффективной и принесла доход (аномалии наблюдались лишь по некоторым переменным модели). Но если бы с витриной было все ок, то дохода было бы еще больше, так как аномалии повлияли на качество самой модели (gini, precision, recall и тд).
Конкретные примеры, что происходило с данными, на которых работала модель и отбирались клиенты в кампанию приведены в конце статьи.
С категориальными данными все просто, используется подход one hot encoding. Т.е. каждая категория рассматривается как отдельная фича (1 как вхождение или 0 как не вхождение в категорию). Тем самым алгоритм может отлавливать кейсы сильного изменения распределения категорий или когда просто целые категории выпадают.
Даты можно рассматривать в формате unixtime, т.е. как просто int значения.
Ответ
Иван, добрый день. Благодарю за внимание к нашей статье. Про мишуру - это ваше оценочное суждение, а вот вопросы в конце, действительно конструктивные и я с радостью на них отвечу.
К сожалению, работая в банке, я очень ограничен в дискуссиях о цифрах. Скажу так, в онлайне это только десятки на розницу (не считая каких-то сервисных api), в батче это под сотню в одном только cvm направлении. Нагрузку, в принципе, можно как-то из этого прикинуть и без разглашения мной nda. Взять с банки ру объемы кредитования, и по статистике цб прикинуть объем одобрений и выдач. Плюс накинуть какой-то ctr. Тут же важен порядок цифр скорей вам для понимания.
Нейронок у нас в процессах, как раз, не так много. Значительно больше бустингов. Я в статье писал, зачем бизнесово мы калибруем модели… так вот веса калибровки большой базы какой-нибудь изотонической регрессией над бустингом весят за 100 мб. Конечно, можно и лог регом откалиброваться, но в конкретных сегментах мат ожидание может поехать. А 100 мб уже накладно каждый раз в чистом гите перезаписывать на большом скоупе моделей, и это пример только одного из кейсов. По накладным расходам чистый бустинг и лог рег (на структурированных данных) примерно равны. Но есть класс задач, например, NLP или сегментация изображений, где лог реги не справятся, вы это знаете лучше меня) тут это больше рнд, которое мы ранее окупили бустингами и лог регами.
Эффекты мы регулярно замеряем и подверждаем на пилотах (в форматах: старая VS новая модели или модель VS бизнес руллы), это хорошие деньги и команду с подобными проектами они окупают многократно, к тому же наши эффекты от моделей периодически аудируют;) Добавлю, что с резким ростом ставки, данная доработка была как никогда актуальна, поэтому главная метрика это ТТМ выкатки новых весов и скорость реакции на волатильность.
Еще раз спасибо, ваши вопросы мне понравились.
Хорошая статья. Давно смотрю в сторону Байесовского подхода и его применения на боевых кейсах. На мой взгляд дополнительно можно подсветить:
Сейчас есть большое количество библиотек, предоставляющих различные инструменты для воплощения Байесовского подхода к анализу данных.
Реальные кейсы когда Байесовский подход оптимизировал проверку гипотезы.
Тоже любим Superset у себя в проектах для визуализации. Побольше бы кейсов с кодом и нетривиальных примеров построения графиков, диаграмм.
Хорошая возможность попиарить свой труд и поучаствовать в миниконтесте. Уже нашел ряд интересных работ достойных макбука.
Поставил)
И у меня был такой! Брал его вообще почти везде. С удовольствием прочитал статью.
С интересом прочитал. Хорошая публикация!
Это отчасти так. Система отдает свои данные КХД. И тут как минимум на 3х этапах может что-то сломаться:
1) На самой системе источнике.
2) При переливке данных источника.
3) При их агрегации и обогащении в кхд.
Как я уже говорил, человеческий фактор, как одна из причин "кривизны" может произойти на любом этапе.
К сожалению, в больших компаниях, я как конечный потребитель данных могу написать только тикет в систему источник. Но, если вы внимательно читали статью, то мы по значимости статистик уже можем подсветить в тикете, что именно произошло, тем самым ускорив процесс разбора инцидента.
Предлагаю продолжать дискуссию только в рамках материалов статьи, а не обсуждать субъективные оценки чьей-то работы.
Мне выгодно, чтобы мои модели работали с заявленным качеством прогноза, а данное решение родилось просто как самостоятельный ресерч.
Кажется, что мы просто смотрим на проблему с разных углов. Вы смотрите как системный архитектор систем, а не как аналитик данных.
К сожалению, реальность такова, что корпоративные хранилища данных в организациях развиваются уже на протяжении многих лет и без сложной логики в них в какой-то момент не обойтись. И тут вы либо делайте простые агрегаты и соответственно простые модели, либо более сложные и модель приносит больше эффекта в деньгах.
Плюсом ко всему, даже при самой простой архитектуре, никто не отменял ошибки, связанные, например, с человеческим фактором.
Таким образом, не важно, какая сложность у вас в системе, с качеством данных придется поработать...
Успешность кампании определяет разница между контрольной и тестовой группы. В зависимости от бизнес задачи мы замеряем ATE (average treatment effect) по отклику, оттоку, балансам и тд.
Почему решили, что «у клиентов подозрения на аномальность»? Регулярно проверяя данные ручками, находились различные коллизии... Например, ставка ЦБ не поменялась, но какой-то показатель по балансам резко скакнул раза в 2. Мы понимаем, что такого быть не может и проблема именно с качеством данных, а не в макроэкономике.
Не смотря на то, что были проблемы с качеством данных, модель по которой отбирались клиенты в тестовую группу оказалась эффективной и принесла доход (аномалии наблюдались лишь по некоторым переменным модели). Но если бы с витриной было все ок, то дохода было бы еще больше, так как аномалии повлияли на качество самой модели (gini, precision, recall и тд).
Конкретные примеры, что происходило с данными, на которых работала модель и отбирались клиенты в кампанию приведены в конце статьи.
С категориальными данными все просто, используется подход one hot encoding. Т.е. каждая категория рассматривается как отдельная фича (1 как вхождение или 0 как не вхождение в категорию). Тем самым алгоритм может отлавливать кейсы сильного изменения распределения категорий или когда просто целые категории выпадают.
Даты можно рассматривать в формате unixtime, т.е. как просто int значения.