Какие именно виды фрода попадают в обучающую выборку при разметке? И уточню первый вопрос из предыдущего комментария: допустим, мерчант регулярно предоставляет для обучения системы выборку транзакций с разметкой «фрод/не фрод» (ну или эксперт сам делает эту разметку, неважно); собственно вопрос в том, откуда именно берутся данные по каждой транзакции, фродовая она была или нет?
Упомянутое правило «0.35 — 0.85» — эмпирическое, или основано на каком-то отдельном статистическом исследовании фрода?
Можно чуть подробнее о том, как эта статистика собирается на работающей системе?
Кто классифицирует исторические данные и проставляет метки для обучающей выборки? Для начального цикла обучения модели (до начала предполагаемой эксплуатации системы) клиент должен сначала предоставить свою выборку, я так понимаю?
За какой период берётся обучающая выборка, какого объёма?
Как обращаетесь с большой несбалансированностью обучающей/тестовой выборки (фродовых платежей обычно на порядок-два меньше, чем «хороших»), в каких пропорциях разделяете?
Как часто предполагается запускать процесс переобучения модели на новых данных?
Дмитрий, вы используете модели из категории supervised learning, но из описания в 3 и 4 частях не очень понятно, откуда эти модели берут обучающие данные с уже имеющейся разметкой «фрод/не фрод»? Я правильно понимаю, что в таблице TransactionsInfo как раз собраны исторические данные о платежах, уже размеченные соответствующим образом? Если это так, то откуда именно эта разметка берётся?
Сергей, я разумеется не имел в виду, что датасет 100.000 x 50 у меня в памяти сам по себе не поместился. Но несколько преобразований атрибутов (например, если выбранный алгоритм работает только с биноминальными атрибутами, а у меня в столбцах строки) — раз, и уже вместо 50 атрибутов их 5000. Условный пример, конечно, но думаю идея понятна — страшны не сами исходные данные, а их возможные преобразования и вынужденное повышение размерности, например.
Но в целом сравнивать RM и Python/R/gcc/etc я честно говоря смысла не вижу. Это ведь изначально совершенно разные инструменты и разные среды, хоть и могут использоваться для сходных задач машинлёрнинга и датамайнинга. Мне в RM лично очень удобна скорость и визуальная простота построения моделей, наглядность и вообще возможность сосредоточиться исключительно на концептуальном понимании модели, а не на написании кода (честно признаюсь, код писать не слишком люблю, и стесняться тут нечего). Но есть же и другие задачи, где мне например R удобнее, например проще какие-то интерактивные дашборды сделать в Shiny, или использовать в R Studio какой-то специфический package для поиска аномалий — всё зависит.
Да, а ещё, отвлекаясь от этих сравнений, хочу заметить, что сам RM позиционирует себя в первую очередь (ну, в одну из самых первых) как платформу для бизнес-аналитики — а это большой плюс для тысяч бизнес-аналитиков, которых кодить вообще не умеют, а им собственно и не надо, благодаря в том числе и визуальным инструментам как RapidMiner и другим подобным.
Уважаемые коллеги vitaly_KF, selenite и BelBES, насколько я могу судить сам по своему опыту работы с RapidMiner разных версий, бесплатная community edition 5.3 имеет те же ограничения по памяти, что и бесплатная 6.x (1 Гб). Там всё-таки есть некая внутренняя хитрость для соблюдения баланса между open-source и business-source моделями, но я не в курсе подробностей про техническую сторону этих ограничений, может быть уважаемый автор пояснит более подробно.
И опять же, влияние этих ограничений очень сильно зависит от рода решаемых задач, от данных, от подхода. Да, когда я только познакомился с бесплатной версией RapidMiner и радостно скормил туда датасет из ~ 100.000 строк * 50 атрибутов (половина из которых были далеко не бинарными) для дальнейшего моделирования «чего-нибудь эдакого», разумеется сразу же больно налетел (и не раз) на ограничение по памяти. Очень помогло дальнейшее осмысление того, что же я делаю, предварительная аккуратная подготовка данных и разумный подход к использованию разных алгоритмов. Могу сказать, что даже с минимальным опытом работы в бесплатной версии я достаточно быстро ушёл от постоянной нехватки памяти и она потом возникала уж совсем по серьёзным поводам, когда данные действительно ну никак не умещались. Для ознакомления, обучения и прогона тренировочных моделей и так далее — в самый раз. Да, изначально тренировался на не очень больших датасетах. Да, в продакшене и на реальных больших данных конечно скорее всего нужна будет лицензионная версия. Ну так и продукт-то в конечном итоге коммерческий.
Если серьёзно, то (см. п. 3 «Важных фич») — есть R extension, с помощью которого можно создать кастомный элемент процесса с произвольным кодом/скриптом на R внутри, это если чего-то не хватает и есть необходимость какой-то кусок алгоритма написать руками.
Ещё есть вопрос по таблице TransactionsStatistics: как и кем определяется, какие именно данные туда записываются? Понятно, что разных статистических данных и параметров транзакций можно записывать десятки, если не сотни, так вот интересует минимально необходимый набор, который сохраняется, и как он формируется. Спасибо.
Дмитрий, получившееся решение тестировалось под нагрузкой? Какие в итоге получились показатели производительности в продакшене? Очень интересует среднее время ответа антифрод-системы, запас по объёму транзакций (сколько транзакций в секунду/минуту могут быть обработаны без ухудшения общей производительности). Какие показатели при этом устанавливаются как целевые?
Михаил, мне кажется, тут довольно существенная разница. Клиенты банка это всё таки клиенты банка. А между покупателем и мерчантом чаще всего вообще никаких отношений нет (и даже после совершения покупки зачастую не возникает). И я как онлайновый покупатель в случае проблем с оплатой в одном магазине вероятнее всего не буду тратить время на разборки с техподдержкой, а просто пойду в другой магазин. Ну разве что я постоянный клиент магазина — а здесь уже их забота сделать так, чтобы постоянных клиентов узнавали и не усложняли им жизнь антифрод-политиками.
Я не сомневаюсь в надёжности и отказоустойчивости современных облачных сервисов. Но всё равно, к первому предложению хорошо бы добавить «как правило» :)
Ну в итоге я правильно понял, что вы это облако используете полностью как публичный бесплатный сервис? Или всё таки у вас с провайдером облака какие-то договорные отношения есть?
Ну отчего же… сами по себе нейросети на таких задачах очень неплохо работают :)
А вот с вытекающей проблемой согласен — они как «чёрные ящики» при этом.
Я имел в виду получение ответа на вопрос «Почему/по каким признакам была запрещена конкретная транзакция?» (в случае, если алгоритм принципиально позволяет получить такие данные). Понятно, спасибо.
Так-то оно так, но это свойства алгоритмов :)
А вопрос был в реализации вашей системы — будут ли в ней механизмы для получения статистики по запретам транзакций?
Да-да, в первую очередь это нужно как раз для спасения клиентов (не говорю уже про аналитику работы системы в целом).
Ну тогда я надеюсь, что автор в следующих двух частях этот механизм опишет.
Но в целом сравнивать RM и Python/R/gcc/etc я честно говоря смысла не вижу. Это ведь изначально совершенно разные инструменты и разные среды, хоть и могут использоваться для сходных задач машинлёрнинга и датамайнинга. Мне в RM лично очень удобна скорость и визуальная простота построения моделей, наглядность и вообще возможность сосредоточиться исключительно на концептуальном понимании модели, а не на написании кода (честно признаюсь, код писать не слишком люблю, и стесняться тут нечего). Но есть же и другие задачи, где мне например R удобнее, например проще какие-то интерактивные дашборды сделать в Shiny, или использовать в R Studio какой-то специфический package для поиска аномалий — всё зависит.
Да, а ещё, отвлекаясь от этих сравнений, хочу заметить, что сам RM позиционирует себя в первую очередь (ну, в одну из самых первых) как платформу для бизнес-аналитики — а это большой плюс для тысяч бизнес-аналитиков, которых кодить вообще не умеют, а им собственно и не надо, благодаря в том числе и визуальным инструментам как RapidMiner и другим подобным.
И опять же, влияние этих ограничений очень сильно зависит от рода решаемых задач, от данных, от подхода. Да, когда я только познакомился с бесплатной версией RapidMiner и радостно скормил туда датасет из ~ 100.000 строк * 50 атрибутов (половина из которых были далеко не бинарными) для дальнейшего моделирования «чего-нибудь эдакого», разумеется сразу же больно налетел (и не раз) на ограничение по памяти. Очень помогло дальнейшее осмысление того, что же я делаю, предварительная аккуратная подготовка данных и разумный подход к использованию разных алгоритмов. Могу сказать, что даже с минимальным опытом работы в бесплатной версии я достаточно быстро ушёл от постоянной нехватки памяти и она потом возникала уж совсем по серьёзным поводам, когда данные действительно ну никак не умещались. Для ознакомления, обучения и прогона тренировочных моделей и так далее — в самый раз. Да, изначально тренировался на не очень больших датасетах. Да, в продакшене и на реальных больших данных конечно скорее всего нужна будет лицензионная версия. Ну так и продукт-то в конечном итоге коммерческий.
Ну в итоге я правильно понял, что вы это облако используете полностью как публичный бесплатный сервис? Или всё таки у вас с провайдером облака какие-то договорные отношения есть?
А вот с вытекающей проблемой согласен — они как «чёрные ящики» при этом.
А вопрос был в реализации вашей системы — будут ли в ней механизмы для получения статистики по запретам транзакций?
Ну тогда я надеюсь, что автор в следующих двух частях этот механизм опишет.