Бизнес нашей во многом строится на взаимном доверии между Airbnb, владельцами жилья и путешественниками. Поэтому мы стараемся создать одно из самых доверенных сообществ. Одним из инструментов построение такого сообщества стала система обзоров, которая помогает пользователям найти участников, заслуживших высокую репутацию.
Все мы знаем, что в сети периодически попадаются пользователи, старающиеся обмануть других людей. Поэтому в Airbnb проблемой обеспечения безопасности занимается отдельная команда разработчиков. Создаваемые ими инструменты нацелены на защиту нашего сообщества пользователей от обманщиков, причём большое внимание уделяется механизмам «быстрого реагирования», чтобы эти люди не успели нанести вред сообществу.
Любой сетевой бизнес сталкивается с самыми разнообразными рисками. Очевидно, что них необходимо защищаться, иначе вы рискуете самим существованием своего бизнеса. Например, интернет-провайдеры прилагают немалые усилия для защиты пользователей от спама, а платёжные сервисы — от мошенников.
Мы также имеем ряд возможностей ограждать своих пользователей от злого умысла.
- Изменения в продукте. Некоторых проблем можно избежать, введя дополнительную верификацию пользователей. Например, требуя подтверждения почтового аккаунта или внедряя двухфакторную аутентификацию для предотвращения кражи аккаунтов.
- Обнаружение отклонений. Некоторые атаки зачастую можно обнаружить по изменению некоторых параметров в течение небольшого временного отрезка. Например, неожиданный 1000% рост объёмов бронирования может быть результатом либо превосходной маркетинговой кампании, либо мошенничества.
- Модель, построенная на базе эвристики и машинного обучения. Мошенники зачастую действуют по каким-то известным схемам. Зная какую-то схему, можно применить эвристический анализ для распознания подобных ситуаций и их предотвращения. В сложных и многоэтапных схемах эвристика становится слишком громоздкой и неэффективной, поэтому здесь необходимо задействовать машинное обучение.
Если вас интересует более глубокое рассмотрение управления онлайн-рисками, то можете обратиться к книге Охада Самета.
Архитектура машинного обучения
Разные векторы рисков могут потребовать применения разных архитектур. Скажем, для ряда ситуаций время не критично, но для обнаружения необходимо задействовать большие вычислительные ресурсы. В подобных случаях лучше всего подходит оффлайн-архитектура. Однако в рамках этого поста мы рассмотрим только системы, работающие в реальном времени и близко к нему. В целом, конвейер машинного обучения при подобных видах рисков зависит от двух условий:
- Фреймворк должен быть быстрым и надёжным. Необходимо свести к нулю возможное время простоя и неработоспособности, а сам фреймворк должен постоянно предоставлять обратную связь. Иначе мошенники могут воспользоваться недостаточной производительностью или глючностью фреймворка, запустив одновременно несколько атак или непрерывно атакуя каким-нибудь относительно простым способом, в ожидании неминуемой перегрузки или остановки системы. Поэтому фреймворк должен работать, в идеале, в режиме реального времени, а выбор модели не должен зависеть от скорости оценки или иных факторов.
- Фреймворк должен быть гибким. Поскольку векторы мошенничества постоянно видоизменяются, необходимо иметь возможность быстро тестировать и внедрять новые модели обнаружения и противодействия. Процесс построения моделей должен позволять инженерам беспрепятственно решать возникающие проблемы.
Оптимизация вычислений в реальном времени в ходе транзакций в первую очередь касается скорости и надёжности, тогда как оптимизация построения моделей и итерирования должна быть больше нацелена на гибкость. Наши команды инжиниринга и обработки данных совместно разработали фреймворк, который удовлетворяет вышеперечисленным требованиям: он быстр, надёжен при обнаружении атак и имеет гибкий конвейер построения моделей.
Выделение признаков
Ради сохранения нашей сервис-ориентированной архитектуры, мы создали отдельный сервис прогнозирования мошенничества, который выделяет все необходимые признаки для конкретной модели. Когда система регистрирует какое-либо критическое событие, например, резервируется жильё, на сервис прогнозирования мошенничества отправляется запрос на обработку. После этого тот выделяет в событии признаки в соответствии с моделью «бронирование жилья» и отправляет их на наш Openscoring-сервис. Тот выдаёт оценку и решение на основании заложенных критериев. Всю эту информацию может использовать сервис прогнозирования.
Данные процессы должны протекать быстро, чтобы успевать вовремя реагировать в случае опасности. Сервис прогнозирования написан на Java, как и многие другие наши бэкэнд-сервисы, для которых критична производительность. Запросы к базе данных распараллелены. В то же время, нам нужна свобода в случаях, когда производятся тяжёлые вычисления в процессе выделения признаков. Поэтому сервис прогнозирования исполняется асинхронно, чтобы не блокировать процедуры бронирования и т.д. Асинхронная модель хорошо работает в тех случаях, когда задержка в несколько секунд не играет особой роли. Однако бывают ситуации, когда необходимо моментально отреагировать и заблокировать транзакцию. В этих случаях применяются синхронные запросы и оценка заранее вычисленных признаков. Поэтому сервис прогнозирования состоит из различных модулей и внутреннего API, что позволяет легко добавлять новые события и модели.
Openscoring
Это Java-сервис, обеспечивающий интерфейс JSON REST для JPMML-Evaluator. JPMML и Openscoring являются открытыми проектами и распространяются под лицензией AGPL 3.0. JPMML-бэкэнд использует PMML, XML-язык, кодирующий несколько распространённых моделей машинного обучения, включая древовидные, логит-преобразования, SVM и нейронные сети. Мы внедрили Openscoring в нашу production-среду, добавив дополнительные возможности: логгирование Kafka, мониторинг statsd и т.д.
Каковы, с нашей точки зрения, преимущества Openscoring:
- Открытый проект. Это позволяет нам модифицировать его под свои требования.
- Поддерживает различные совокупности деревьев. Мы протестировали несколько методов обучения и выяснили, что случайные совокупности обеспечивают подходящий уровень точности.
- Высокая скорость и надёжность. В ходе нагрузочного тестирования большинство откликов были получены менее, чем через 10 мсек.
- Множественные модели. После нашей доработки, Openscoring позволяет одновременно запускать много различных моделей.
- Формат PMML. PMML позволяет нашим аналитикам и разработчикам использовать любые совместимые пакеты машинного обучения (R, Python, Java и т.д.). Те же PMML-файлы могут быть использованы с Cascading Pattern для выполнения оценки групп крупномасштабных распределённых моделей.
Но есть у Openscoring и недостатки:
- PMML не поддерживает некоторые виды моделей. Поддерживаются лишь относительно стандартные ML-модели, поэтому мы не можем запускать новые модели или существенно модифицировать стандартные.
- Нет нативной поддержки онлайн-обучения. Модели не могут тренировать сами себя на лету. Необходим дополнительный механизм для автоматического доступа к новым ситуациям.
- Зачаточная обработка ошибок. PMML трудно дебажить, ручное редактирование XML-файла представляет собой рискованное занятие. JPMML известен тем, что выдаёт загадочные сообщения об ошибках при возникновении проблем с PMML.
Конвейер построения модели
Выше представлена схема нашего конвейера построения модели с помощью PMML. Сначала из данных, хранящихся на сайте, выделяются признаки. Поскольку комбинации признаков, дающие оптимальный сигнал, постоянно меняются, то мы храним их в JSON-формате. Это позволяет обобщить процесс загрузки и трансформирования признаков, основанный на их именах и типах. Затем признаки группируются, а для улучшения сигнала вместо отсутствующих переменных вставляются подходящие. Статистически неважные признаки отбрасываются. Все эти операции занимают существенное время, поэтому приходится жертвовать многими деталями ради увеличения производительности. Затем трансформированные признаки используются для тренировки и перекрёстной проверки модели с помощью нашей любимой PMML-совместимой библиотеки машинного обучения. После этого полученная модель загружается в Openscoring. Финальный результат тестируется и используется для принятия решений, если он показывает наилучшие результаты.
Этап тренировки модели может проходить осуществляться на любом языке, в котором есть PMML-библиотека. Например, часто используется пакет R PMML. Она поддерживает многие виды трансформаций и способов манипулирования данными, однако её нельзя назвать универсальным решением. Мы разворачиваем модель отдельным этапом, после её тренировки, поэтому приходится проверять её вручную, что может занимать немало времени. Ещё одним недостатком R является низкая скорость внедрения PMML-экспортёра при большом количестве признаков и деревьев. Однако мы обнаружили, что простая перезапись экспорта функции в С++ снижает время выполнения примерно в 10 000 раз, с нескольких дней до нескольких секунд.
Нам вполне удаётся обходить недостатки R, в то же время используя его преимущества в построении конвейера на базе Python и scikit-learn. Scikit-learn представляет собой пакет, поддерживающий многие стандартные модели машинного обучения. Он также включает в себя полезные утилиты для проверки моделей и выполнения трансформаций признаков.
Для нас Python стал более подходящим языком, чем R, для ситуативного управления данными и извлечения признаков. Автоматизированный процесс извлечения опирается на набор правил, закодированных в именах и типах переменных в JSON, таким образом новые признаки могут быть внедрены в конвейер без изменения существующего кода. Развёртывание и тестирование также могут выполняться автоматически в Python с помощью стандартных сетевых библиотек для взаимодействия с Openscoring. Тесты производительности стандартной модели (precision-recall, кривые ROC и т.д.) выполняются с помощью sklearn. Он не поддерживает из коробки экспорт PMML, так что пришлось переписать внутренний механизм экспорта для определённых классификаторов. Когда PMML-файл загружен в Openscoring, он автоматически тестируется на соответствие представляемой им scikit-learn модели. Поскольку все этапы, — трансформирование признаков, построение модели и её проверка, развёртывание и тестирование, — выполняются в одном-единственном скрипте, разработчики могут быстро итерировать модель, основанную на новых признаках или более свежих данных, а потом быстро развёртывать её в production.
Основные этапы: ситуация —> признаки —> выбор алгоритма
Выстроенный нами процесс показал отличные результаты для некоторых моделей, но с остальными мы получили плохой уровень precision-recall. Сначала мы решили, что причина заключается в наличии погрешностей, и попробовали использовать больше данных и больше признаков. Однако улучшения не было. Мы глубже проанализировали данные и выяснили, что проблема была в том, что сами ситуации были некорректными.
Возьмём, для примера, случаи с требованиями возврата оплата. Причинами возвратов могут быть ситуации, когда продукт «не соответствует описанию» (Not As Described, NAD) или мошенничество. Но группировать обе эти причины в одной модели было ошибкой, поскольку добросовестные пользователи могут документально подтвердить правомерность NAD-возвратов. Эта проблема решается легко, как и ряд других. Однако во многих случаях довольно трудно отделить поведение мошенников от деятельности нормальных пользователей, приходится создавать дополнительные хранилища данных и конвейеры логгирования.
Для большинства специалистов, работающих в сфере машинного обучения, сочтут это очевидным, но мы всё же хотим ещё раз подчеркнуть: если ваши анализируемые ситуации будут не совсем корректными, то вы уже задали верхний предел точности точности и полноты классификации. Если же ситуации существенно ошибочны, то этот предел получается довольно низким.
Иногда бывает так, что, пока вы не столкнётесь с новым видом атаки, вы не знаете, какие данные вам нужны для её определения, особенно если раньше вы не работали в условиях возможности рисков. Или работали, но в другой сфере. В этом случае можно посоветовать логгировать всё, что только можно. В будущем эта информация может не просто пригодиться, но даже оказаться неоценимой для защиты от нового вектора атаки.
Будущие перспективы
Мы постоянно работаем над дальнейшим улучшением и развитием своей системы прогнозирования мошенничества. В текущей архитектуре нашли своё отражение нынешний этап развития компании и количество доступных ресурсов. Зачастую менее крупные компании могут позволить себе использовать в production лишь несколько ML-моделей и небольшую команду аналитиков, им приходится вручную обрабатывать данные и тренировать модели в нестандартных случаях. Более крупные фирмы могут позволить себе создавать многочисленные модели, широко автоматизировать процессы и получать существенную отдачу от тренировок моделей в онлайне. Работа в чрезвычайно быстро растущей компании даёт возможность поработать в условиях радикально меняющегося из года в года ландшафта, поэтому конвейеры обучения требуется постоянно модифицировать.
С развитием нашего инструментария и методик, инвестирование в дальнейшее улучшение алгоритмов обучения обретает всё бОльшую важность. Вероятно, наши усилия будут смещаться в сторону тестирования новых алгоритмов, более широкого внедрения онлайн-обучения моделей и модернизирования фреймворка, чтобы он мог работать с более объёмными наборами данных. Некоторые наиболее значительные возможности по улучшению моделей базируются на уникальности накапливаемой нами информации, наборов признаков и прочих аспектах, которые мы не можем озвучивать по понятным причинам. Тем не менее, мы заинтересованы в обмене опытом с другими командами разработчиков. Пишите нам!
Автор: AirbnbHabr
