Существует общая пропасть, с которой мы, практики Data Science, работающие с компаниями, сталкиваемся практически в каждом проекте; как перейти от бизнес-задачи к решению для науки о данных или к продукту для науки о данных. Этот пробел в некоторой степени очевиден, но неуловим и его легко не заметить, и кажется, что эта двойственность проистекает из того, как мы начинаем изучать DS. Глядя на большинство руководств, у нас есть исходный набор данных и конкретная цель с этим набором данных. Данные и определение проблемы герметичны. Например, в знаменитых регрессионных данных о ценах на недвижимость у нас есть задача прогнозировать цену дома на основе множества атрибутов, и успех нашей модели будет оцениваться по некоторой метрике ошибок, например, по лог-потерям или чему-то в этом роде. С этого момента мы можем использовать наш опыт в области машинного обучения для решения этих проблем.

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

Устранение пропасти между бизнес-целями и задачами науки о данных отмечает разницу между проектами, которые заканчиваются хорошо, и проектами, которые не заканчиваются. Причина в том, что решение DS, которое не соответствует бизнес-целям и не атакует напрямую проблему, имеющуюся у бизнеса, обречено быть не более чем провальным проектом DS, независимо от того, насколько хороши наука о данных / машинное обучение. развитие есть.

Цель этой небольшой серии статей - дать практический взгляд на науку о данных в рамках бизнес-сценария использования. Мы хотим вместе с вами изучить, как перейти от бизнес-задачи к продукту для обработки данных и какие соображения необходимо учитывать. Этот случай адаптирован и основан на данных, предоставленных Эдгаром Алонсо Лопес-Рохасом, Ахмадом Эльмиром и Стефаном Аксельссоном в их статье Paysim: симулятор финансовых мобильных денег для обнаружения мошенничества ¹. данные можно скачать напрямую через Kaggle.

История начинается так ...

Наш клиент - широко известная компания по производству мобильных кошельков из неизвестной африканской страны. Эта компания обрабатывает около 6 миллионов транзакций в месяц и серьезно относится к защите активов клиентов, хранящихся в их виртуальных кошельках, поэтому мошеннические транзакции являются серьезной проблемой для нашего клиента. По оценке нашего клиента, предлагаемый способ действий злоумышленника прост: злоумышленник захватывает контроль над кошельком жертвы и переводит деньги в другой кошелек, в серии из одной или нескольких мошеннических транзакций деньги в конечном итоге выводятся, и фактически украденный. Такая ситуация возникает достаточно часто, чтобы за один месяц ошеломляющая сумма в 1200 миллионов была потеряна из-за мошенничества.

Помня об этой проблеме, клиент обратился к нам с двумя основными проблемами.

  • Они хотят автоматизировать процесс выявления мошенничества, поскольку у клиента его пока нет. В их статус-кво о мошенничестве сообщается после того, как оно было совершено, и через некоторое время отчеты анализируются, чтобы определить, было ли претензия настоящим мошенничеством, и этот процесс борется с текущим количеством мошеннических претензий. Основываясь на автоматической пометке мошенничества, клиент хочет реализовать процесс, который позволил бы ему быстро анализировать возможные случаи мошенничества, в то же время удерживая транзакцию, в то время как эксперт решает, одобрить или отменить ожидающую транзакцию. Помня о том, что экспертов, которые рассматривают дела, мало, крайне важно, чтобы система не помечала слишком много законных транзакций как мошенничество.
  • С аналогичной целью их отдел анализа мошенничества хочет, чтобы мы помогли им понять, какие факторы характеризуют мошенническую транзакцию, факторы, которые помогли бы им разработать различные меры или политики для упреждающего сокращения мошенничества.

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

Эта серия разделена (ориентировочно) на три разных статьи, каждая из которых посвящена определенной цели в рамках общего экономического обоснования.

  1. Назовите мне причины (ссылка здесь), где мы представляем решение, которое мы получили в решении задач клиента. Это означает разработку модели для автоматизации обнаружения мошенничества и объяснение того, что может характеризовать мошенническую или немошенническую транзакцию. Кроме того, мы описываем, какие практические идеи или политики могут быть извлечены из анализа с точки зрения их цели, и наряду с этими выводами мы оцениваем, насколько сложно злоумышленнику уклониться от этих новых мер. Также предоставляется подробная информация о различных используемых моделях и методах. Мы также подчеркиваем причины, по которым следует учитывать цели клиента и бизнес-контекст при разработке моделей.
  2. Предвидение мошенников (ссылка здесь) следует истории из первой главы и начинается с представления о том, что мошенники отреагируют на внедрение модели, и такое новое поведение повлияет на производительность модель. Итак, как мы можем разработать более надежную модель?
  3. Что делать с моделью? (в процессе), где мы обсуждаем различные способы развертывания моделей, разработанных в первой главе, в зависимости от требований клиента и существующей технологической инфраструктуры.

Несмотря на то, что эти статьи ни в коем случае не представляют собой исчерпывающую картину всех проблем, с которыми может столкнуться реальный случай обнаружения мобильного мошенничества, они охватывают значительную часть проблем и могут оказаться полезными для тех, кто хочет объединить бизнес и технические аспекты в своей работе. набор инструментов для решения проблем.

В качестве заключительного примечания к введению, эта работа является результатом сотрудничества Хуана Диего Бермео и меня, поэтому некоторые статьи будут публиковаться из его аккаунта, а некоторые - из моего. Тем не менее, вы можете найти в этой статье ссылки на остальные.

Немного контекста данных

Для тех из вас, кто не знаком с данными, мы хотели бы сначала представить контекст и данные, которые мы используем в этом случае. Набор данных представляет транзакции в течение одного месяца службы мобильных денег или электронного кошелька в нераскрытой африканской стране. Мы говорим «представляет», потому что на самом деле набор данных является результатом моделирования, называемого Paysim, которое, тем не менее, имеет намерение представлять реальные транзакции. В дополнение к статье, упомянутой несколькими абзацами назад, мы также использовали диссертацию Эдгара на магистерскую диссертацию². Мы будем использовать информацию из этого документа как показатель знаний предметной области в нормальном бизнес-контексте, что важно для понимания уместности и эффективности созданных продуктов данных.

Для нашей практической цели мы примем данные как реальные и попытаемся установить настройки, максимально приближенные к реальной мировой практике.

Теперь что касается данных, у нас есть файл с примерно 6 миллионами записей, соответствующими месяцу сбора данных. Каждая запись характеризует отдельную транзакцию, включая сведения из счетов происхождения и назначения, а также их соответствующие балансы. Все записи помечаются как мошенничество или законная транзакция. Кроме того, эти транзакции могут происходить между двумя типами ролей в системе: клиентами и продавцами, считая клиентов обычными людьми, использующими платформу, а продавцов - банкоматами, которые позволяют вносить или снимать деньги. Опишем кратко каждое из полей, с которыми мы встретимся в основном файле данных.

step описывает час месяца, начинается с 1 и увеличивается до 720, что соответствует 30 дням.

тип обозначает пять разновидностей транзакций, которые происходят на мобильной платформе, это CASH_OUT, CASH_IN, DEBIT, PAYMENT, TRANSFER. Каждый из этих типов требует своего объяснения с прямой ссылкой на автора данных:

  • CASH-IN - это процесс увеличения баланса счета за счет оплаты наличными продавцу, как при внесении депозита на счет.
  • CASH-OUT - это процесс, противоположный CASH-IN, он означает снятие наличных у продавца, что уменьшает баланс счета.
  • ДЕБЕТ похож на CASH-OUT и включает в себя отправку денег из службы мобильных денег на банковский счет.
  • ОПЛАТА - это процесс оплаты товаров или услуг продавцам, который уменьшает баланс счета и увеличивает баланс получателя.
  • ПЕРЕВОД - это процесс отправки денег другому пользователю услуги через платформу мобильных денег.

сумма - это деньги, переведенные в рамках транзакции, сумма переходит из исходного аккаунта в целевой.

nameOrig определяет учетную запись, в которой была совершена транзакция. Идентификаторы имеют префикс C или M для покупателей и продавцов соответственно.

oldbalanceOrg - баланс исходной учетной записи до транзакции.

newbalanceOrig - это баланс исходной учетной записи после транзакции.

В той же строке данные также содержат поля nameDest, oldbalanceDest и newbalanceDest.

isFraud - это индикатор незаконной деятельности, 1 - для мошенничества и 0 - для законной транзакции. Только 0,12%, или 1 из 833 транзакций, идентифицируются как мошенничество, что делает этот случай еще более сложным.

isFlaggedFraud отмечает, пытается ли транзакция переместить сумму, превышающую 200 000, что является политикой, реализуемой клиентом для выявления и предотвращения мошенничества. Однако нет никакой гарантии, что такая пометка транзакции работает.

[1] Лопес-Рохас, Эдгар Алонсо и Эльмир, Ахмад и Аксельссон, Стефан. (2016). PAYSIM: СИМУЛЯТОР ФИНАНСОВЫХ МОБИЛЬНЫХ ДЕНЕГ ДЛЯ ОБНАРУЖЕНИЯ МОШЕННИЧЕСТВА. Ссылка здесь

[2] Лопес-Рохас, Э. А. (2016). Применение моделирования к проблеме выявления финансового мошенничества (кандидатская диссертация). Карлскруна. Получено с http://urn.kb.se/resolve?urn=urn:nbn:se:bth-12932