Comments 11
А можно для таких тупых, как я, пояснить, в «Иногда после успешно проведённой рекламной кампании приходит много клиентов с подозрением на аномальность, объединённых каким-то общим признаком, и стандартная проверка считывает это как ошибку в данных, хотя это не так. Как с этим работать вручную, уже непонятно. » — почему решили, что «компания успешная», почему решили, что «у клиентов подозрения на аномальность», почему «это не так»? Ну хотя бы на примере?
вызывает ассоциации с известным анекдотом про «папа играет на пианино в борделе».
Где я в роли того 7-летнего пацана…
Успешность кампании определяет разница между контрольной и тестовой группы. В зависимости от бизнес задачи мы замеряем ATE (average treatment effect) по отклику, оттоку, балансам и тд.
Почему решили, что «у клиентов подозрения на аномальность»? Регулярно проверяя данные ручками, находились различные коллизии... Например, ставка ЦБ не поменялась, но какой-то показатель по балансам резко скакнул раза в 2. Мы понимаем, что такого быть не может и проблема именно с качеством данных, а не в макроэкономике.
Не смотря на то, что были проблемы с качеством данных, модель по которой отбирались клиенты в тестовую группу оказалась эффективной и принесла доход (аномалии наблюдались лишь по некоторым переменным модели). Но если бы с витриной было все ок, то дохода было бы еще больше, так как аномалии повлияли на качество самой модели (gini, precision, recall и тд).
Конкретные примеры, что происходило с данными, на которых работала модель и отбирались клиенты в кампанию приведены в конце статьи.
Классный подход, с огромным интересом прочитал.
Подскажите, как вы эту методику применяете к категориальным признакам? Там, из упомянутых вами статистик, можно посчитать только наны и количество уникальных значений. Можно, конечно, долю категорий в общей массе считать, но это очень неочевидно, так как предполагает постоянное их количество.
Интересно также, как признаки date-time оцениваете.
С категориальными данными все просто, используется подход one hot encoding. Т.е. каждая категория рассматривается как отдельная фича (1 как вхождение или 0 как не вхождение в категорию). Тем самым алгоритм может отлавливать кейсы сильного изменения распределения категорий или когда просто целые категории выпадают.
Даты можно рассматривать в формате unixtime, т.е. как просто int значения.
Настроить мониторинги на все эти этапы несложно, но как за всем этим следить? Гораздо проще мониторить финальный набор атрибутов во времени.
Мне кажется при проектировании системы надо было думать о том как "за этим следить", а не лепить франкинштейна у которого лицо находится примерно сзади между ног.
Тогда бы не пришлось разрабатывать методы анализа функционирования франкинштейна.
При такой анатомии любое действие - воплощенная боль и никуда вы от этого не денетесь, монстр вас задавит!
"Сон разума рождает чудовищ" Франсиско Гойя.
К сожалению, реальность такова, что корпоративные хранилища данных в организациях развиваются уже на протяжении многих лет и без сложной логики в них в какой-то момент не обойтись. И тут вы либо делайте простые агрегаты и соответственно простые модели, либо более сложные и модель приносит больше эффекта в деньгах.
Плюсом ко всему, даже при самой простой архитектуре, никто не отменял ошибки, связанные, например, с человеческим фактором.
Таким образом, не важно, какая сложность у вас в системе, с качеством данных придется поработать...
Таким образом, не важно, какая сложность у вас в системе, с качеством данных придется поработать...
Я к тому что, например, в этой фразе префикс "Таким образом, " выглядит совершенно не нужным. Утверждение не надо обосновывать оно очевидно!
Насколько я понял проблема не в сложности системы и генерируемых ею данных, а в их бессистемности и даже противоречивости, но на бытовом уровне это назвали бы "кривыми" данными, и соответственно, система которая их генерирует тоже кривая.
По сути вы описываете как выпрямлять кривые данные, не пытаясь исправить (или проанализировать) источник кривизны в системе.
Я вполне допускаю что у вас нет возможности (полномочий) исправлять систему генерирующую данные, но косвенный анализ по данным провести обычно можно, но у вас есть причины этим заниматься, например просто нет перспектив что вам за это заплатят, или просто кто то оценит.
Вы продвигаете методы улучшения качества данных, вам в принципе выгодно что бы данные были кривоватые, иначе ваша работа не будет востребована. В этом смысле это такая сомнительная цель и технология, мне кажется.
Насколько я понял проблема не в сложности системы и генерируемых ею данных, а в их бессистемности и даже противоречивости, но на бытовом уровне это назвали бы "кривыми" данными, и соответственно, система которая их генерирует тоже кривая.
Это отчасти так. Система отдает свои данные КХД. И тут как минимум на 3х этапах может что-то сломаться:
1) На самой системе источнике.
2) При переливке данных источника.
3) При их агрегации и обогащении в кхд.
Как я уже говорил, человеческий фактор, как одна из причин "кривизны" может произойти на любом этапе.
По сути вы описываете как выпрямлять кривые данные, не пытаясь исправить (или проанализировать) источник кривизны в системе.
К сожалению, в больших компаниях, я как конечный потребитель данных могу написать только тикет в систему источник. Но, если вы внимательно читали статью, то мы по значимости статистик уже можем подсветить в тикете, что именно произошло, тем самым ускорив процесс разбора инцидента.
у вас есть причины этим заниматься, например просто нет перспектив что вам за это заплатят, или просто кто то оценит.
Предлагаю продолжать дискуссию только в рамках материалов статьи, а не обсуждать субъективные оценки чьей-то работы.
Вы продвигаете методы улучшения качества данных, вам в принципе выгодно что бы данные были кривоватые, иначе ваша работа не будет востребована.
Мне выгодно, чтобы мои модели работали с заявленным качеством прогноза, а данное решение родилось просто как самостоятельный ресерч.
В этом смысле это такая сомнительная цель и технология, мне кажется.
Кажется, что мы просто смотрим на проблему с разных углов. Вы смотрите как системный архитектор систем, а не как аналитик данных.
Аналитические хранилища в принципе часто грешат наличием сложной бизнес-логики и зависимостями между витринами. О мониторинге качества данных обычно задумываются в последнюю очередь, тогда, кажется, настраивать мониторинг на каждом этапе дело неблагодарное, поэтому описанный подход выглядит интересным. Спасибо, ждем продолжения.
Хороший разбор и статья!
Страдающее ML: как мы автоматизировали проверку данных, чтобы не было мучительно больно