Годовой путь к разработке одной из лучших систем предотвращения мошенничества на рынке

Согласно исследованию, опубликованному в марте 2019 года, которое я специально искал, чтобы найти интересное введение для этой статьи, 40% самостоятельных стартапов в области ИИ в Европе на самом деле не используют ИИ. Я вижу, что они там делают, используя редко встречающееся знакомство обычных людей (и инвесторов) с этой областью, чтобы позиционировать себя на рынке как крутых экспертов по черной магии. Я не работаю в AI-стартапе (я имею в виду, что мы не продаем напрямую услуги на базе AI), но пару дней назад мы наконец опубликовали обширный пост, который знакомит публику с нашим первым продукт. Я подумал, что было бы довольно интересно поделиться всеми шагами, которые мы прошли, чтобы развернуть его, и почему мы решили сделать это именно так.

Без повторений, но просто в качестве вводного глоссария: Пенелопа - это наш внутренний инструмент для обнаружения мошенничества. Каждое новое объявление, опубликованное на нашей платформе (HousingAnywhere, рынок жилья со списками в более чем 400 городах по всему миру), классифицируется как мошенничество или не мошенничество, а в некоторых случаях отмечается для ручной проверки нашими решениями для клиентов (CS) отдел. Он был обучен на данных, собранных за последние три года, и реализован как ансамбль, где каждая модель независимо фокусируется на разных функциях или на другом хронологическом подмножестве набора данных.

Предотвращение мошенничества до Пенелопы

HousingAnywhere не был рожден Пенелопой, и обеспечение доверия и безопасного рынка всегда было первоочередной задачей компании. В течение многих лет система предотвращения мошенничества хорошо работала без какого-либо ИИ (невероятно, не правда ли?) И почти полностью полагалась на систему триггеров, составленную из некоторых статических правил SQL. Некоторые из запрашиваемых структур данных и сами запросы вовсе не были тривиальными, но часто простая система, хорошо спроектированная и поддерживаемая, может превзойти очень сложные решения. Проблема в том, что это было не совсем так. Когда компания начинает быстро масштабироваться и должна быстро решать проблемы, она может упускать из виду некоторые передовые методы.

Исходная система состояла из ~ 50 правил, без надлежащей документации и с частично совпадающими областями применения. Мы не собирали никакой статистики об их выступлениях, и мы не знали, почему первоначальные дизайнеры вообще создали эти правила. У нас было ощущение, что некоторые триггеры не приводили к какому-либо обнаружению в течение нескольких месяцев, в результате чего было потрачено много времени на бесполезные проверки, но у нас не было никакой метрики для доказательства гипотезы, и мы закончили, не удалив ничего, добавив новые правила поверх существующих, потому что система работала - ни один мошенник не добился успеха за 3 года! - и мы очень боялись что-либо трогать. Сама по себе разработка новых правил была сложной задачей. Иногда нелегко описать подозрительное поведение, и что-то, что может быть тривиальным для человека, может потребовать сотни строк SQL, объединяющих таблицы, которые, возможно, могут храниться в разных местах. Именно тогда мы начали думать об использовании машинного обучения для замены системы правил: прекратить явно определять все правила и позволить алгоритму изучать их непосредственно из наших данных.

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

Мы не просто начали подбрасывать случайные данные в алгоритмы обучения, чтобы посмотреть, что из этого получится.

Много усилий, которые мы потратили на проект «Пенелопа», вначале было направлено на рационализацию и улучшение предыдущей системы правил, прямо перед тем, как ее навсегда уничтожить. Мы разработали и внедрили инфраструктуру мониторинга, способную отслеживать производительность каждого триггера (в основном, точность), а также начали собирать некоторые метрики для отдела решений для клиентов, чтобы проверить, где были наши узкие места, и нужно ли нам улучшить наши внутренние процессы на верх технической инфраструктуры. В итоге мы сделали и то, и другое: нет смысла улучшать техническую инфраструктуру, используемую людьми, если процесс, которому они следуют, изначально неэффективен. Искусственный интеллект - это инструмент для улучшения чего-либо, но это всего лишь часть головоломки. Его полезность не в том, что он используется сам по себе, а в том, чтобы использовать его для улучшения целых процессов. Внедрение машинного обучения - не самое простое занятие и, прежде всего, работа с очень непредсказуемыми результатами. Начните сначала с простых вещей.

Нет смысла улучшать техническую инфраструктуру, используемую людьми, если процесс, которому они следуют, изначально неэффективен.

Пенелопа, на самом деле

Как только у нас появилась надежная инфраструктура предотвращения мошенничества (примерно месяц работы), мы начали создавать альтернативу, чтобы избавиться от нее. С самого начала мы никогда не думали о полной замене модераторов-людей и никогда не гонялись за академическими статьями. Мы всегда смотрели на точность не как на число, а как на объем бесполезной работы, которую CS потратил бы впустую на проверку помеченных списков, и вспоминаем, как на количество мошеннических списков, оставшихся без внимания. Система правил также помогла нам предоставить начальный набор функций для работы. Вдобавок к этому мы исследовали некоторые другие, в основном благодаря отзывам людей, которые ежедневно сталкиваются с мошенниками. Тем не менее, мы не теряли время зря, исследуя функции, которые не были бы доступны в первые 5 минут, и создается список, и, опять же, наличие видения продукта на ранних этапах очень помогло в этом.

Настоящая проблема, с которой мы столкнулись при обучении модели, заключалась в эволюционной природе платформы, которая генерирует данные. Мы закончили ансамбль 5 LightGBM (сопоставимые характеристики, но более короткое время обучения, чем XGBoost), каждый из которых обучался с разным набором данных либо в вертикальном (количество выборок), либо в горизонтальном (количество функций) размерах. Каждая модель оценивается так, чтобы иметь максимальную производительность на новых данных (проверка 90–10, упорядочение выборок в хронологическом порядке; байесовская оптимизация для исследования пространства весов).

Затем окончательная модель была развернута как веб-API (Flask), питающий экземпляр Celery, который асинхронно планирует задачи прогнозирования. Результат каждого задания отправляется по разным каналам, и развертывание не знает клиентов, которые его используют. Каждый новый листинг, опубликованный на платформе (за исключением тех, которые созданы надежными рекламодателями), отправляется Пенелопе для проверки. И либо принимается, либо помечается как мошенничество, либо отправляется на ручную модерацию. Каждое задание по прогнозированию длится 3-4 секунды, но часть этого времени требуется для сбора некоторых данных из сторонних источников.

После первого успешного развертывания (более или менее в январе 2019 года) нам нужно было решить, что делать с процессом переподготовки системы и с эволюционным характером наших данных. Мы провели несколько автономных симуляций и сравнили различные сценарии переподготовки, обнаружив, что для нашей конкретной области переподготовка Пенелопы каждые 2 недели привела бы к значительному увеличению производительности (в основном, больше мошенников). Неудивительно, что важность модели, обученной всем последним функциям ансамбля, каждый раз становится все более актуальной для классификации новых списков. В будущем мы планируем избавиться от некоторых моделей и, возможно, добавить новые. На данном этапе мы вполне уверены в том, что это делаем, и у нас есть надежный конвейер для открытия новых функций переключения для обучения наших моделей.

Выступления и следующие шаги

До Пенелопы отдел информационных технологий тратил 80 часов в неделю на ручную модерацию подозрительных объявлений, в настоящее время это около 15 часов (улучшение на 80%). Большинство правил не вступили в силу немедленно, и на выявление мошенничества требовалось от 1 до 6 часов. Это ограничение подвергало посетителей риску, так как список был доступен для связи в течение нескольких часов. Возможность Penelope классифицировать списки сразу после их публикации уменьшила это окно почти до 0 и фактически дает CS очень удобную метрику для оценки их результатов. Качество нашей системы предотвращения мошенничества (как компании) теперь во многом зависит от того, насколько быстро отдел по работе с клиентами проверяет списки, отмеченные Пенелопой. Mes2Det - это наша внутренняя метрика для измерения этого показателя, которая рассчитывается как количество часов, необходимых для сообщения о мошеннике после того, как он был уведомлен в наших системах. Как это легко заметить, Mes2Det значительно улучшился с тех пор, как Penelope начала работать (с 10 часов до 2), и теперь она стабильна в течение нескольких месяцев.

В настоящее время мы постоянно работаем над «Пенелопой», пытаясь улучшить ее, насколько это возможно. Некоторые уроки, которые мы уже усвоили, заключаются в том, что направление исследований - это сокращение объема моделей, возможно, объединение более простых компонентов, обученных с меньшими наборами данных, чем попытки построить большую архитектуру с сотнями сложных функций. В июне мы уже развернули вторую версию Penelope, точность которой увеличилась на ~ 10%, даже если она обучается с набором данных, который почти вдвое меньше исходного.