🥇Създаване на автоматизирана система за защита от злонамерени действия на сайта (измами)

През последните около шест месеца работих по създаването на система за борба с фродове (злоупотреби, измами и др.) без никаква начална инфраструктура за това. Идеите, които открихме и реализирахме в нашата система, ни помагат да откриваме множество измамни действия и да ги анализираме. В тази статия бих искал да споделя принципите, които следвахме, и какво направихме, за да достигнем сегашното състояние на нашата система, без да задълбочаваме техническата част.

Принципи на нашата система

Когато чуете термини като "автоматичен" и "фрод", вероятно започвате да мислите за машинно обучение, Apache Spark, Hadoop, Python, Airflow и други технологии от екосистемата на Apache Foundation и областта на Data Science. Смятам, че съществува един аспект за използването на тези инструменти, който обикновено не се споменава: те изискват наличието на определени предварителни условия във вашата корпоративна система, преди да започнете да ги използвате. По-просто казано, имате нужда от корпоративна данъчна платформа, която включва данни от езеро и хранилище. Но какво, ако нямате такава платформа и все пак трябва да развивате тази практика? Следващите принципи, които споделям по-долу, ни помогнаха да достигнем момент, в който можем да се фокусираме върху усъвършенстването на нашите идеи, вместо да търсим работеща. Въпреки това, това не е "плато" на проекта. Все още има много неща, които трябва да се решат, както от технологична, така и от продуктова гледна точка.

Принцип 1: стойност за бизнеса на първо място

В основата на всичките ни усилия поставихме "стойност за бизнеса". В общи линии, всяка система за автоматизирано анализиране е сложна система с висок достъп до автоматизация и техническа сложност. Създаването на завършено решение би отнело много време, ако го изградите от нулата. Решихме да поставим стойността за бизнеса на първо място, а технологичната завършеност на второ. В реалния свят това означава, че не приемаме авангардни технологии като догма. Избираме технологията, която работи най-добре за нас в момента. С времето може да се окаже, че трябва да пренаписваме някои модули. Този компромис, който направихме.

Принцип 2: Разширен интелект на човека (augmented intelligence)

Сигурно повечето хора, които не са дълбоко ангажирани в разработването на решения за машинно обучение, могат да си помислят, че целта е да се заменят хората. Всъщност, решенията за машинно обучение са далеч от съвършенство и само в определени области може да се направи замяна. Отказахме се от тази идея от самото начало по няколко причини: несбалансирани данни за измамна дейност и невъзможността да се предостави изчерпателен списък с характеристики за моделите на машинно обучение. Вместо това избрахме варианта с разширен интелект. Това е алтернативна концепция за изкуствен интелект, която акцентира на помощната роля на ИИ, подчертавайки факта, че когнитивните технологии са предназначени за подобряване на човешкия интелект, а не за неговата замяна. [1]

Вземайки това предвид, разработването на пълно решение за машинно обучение от самото начало би изисквало огромни усилия, които биха забавили създаването на стойност за нашия бизнес. Решихме да изградим система с итеративно растящ аспект на машинното обучение, ръководена от нашите експерти в предметната област. Сложната част от разработването на такава система е, че тя трябва да предоставя на нашите анализатори случаи не само от гледна точка на това дали това е измамна дейност, или не. По принцип всяка аномалия в поведението на клиентите е подозрителен случай, който специалистите трябва да разследват и някак си да реагират. Само част от тези регистрирани случаи наистина могат да бъдат отнесени към категорията измами.

Принцип 3: платформа за обширни аналитични данни

Най-трудната част от нашата система е проверката на работния поток в системата. Анализаторите и разработчиците трябва да имат лесен достъп до набори данни за предишни периоди, с всички метрики, използвани за анализ. Освен това, платформата за данни трябва да предоставя лесен начин за допълване на съществуващия набор от показатели с нови. Процесите, които създаваме, а това не са само софтуерни процеси, трябва да позволяват лесно преизчисляване на предишни периоди, добавяне на нови метрики и променяне на данните за прогнозиране. Можехме да постигнем това, натрупвайки всички данни, генерирани от нашата производствена система. В такъв случай данните постепенно биха станали пречка. Трябваше да съхраняваме нарастващия обем от данни, които не използваме, и да ги защитаваме. В такъв сценарий данните с времето стават все по-нерелевантни, но все пак изискват усилия за управление. За нас натрупването на данни нямаше смисъл, затова решихме да използваме друг подход. Решихме да организираме хранилища на данни в реално време около целевите единици, които искаме да класифицираме, и да съхраняваме само тези данни, които позволяват проверка на най-новите и актуални периоди. Сложността на тези усилия се състои в това, че нашата система е хетерогенна с няколко хранилища на данни и софтуерни модули, които изискват внимателно планиране за последователна работа.

Конструктивни концепции на нашата система

Имаме четири основни компонента в нашата система: система за приемане, изчислителна система, анализна система и система за проследяване. Те служат за конкретни изолирани цели, и ние ги държим изолирани, следвайки определени подходи в разработката.

Дизайн, основан на договори

Първо и основно, се споразумяхме, че компонентите трябва да разчитат само на определени структури от данни (контракти), които се предават между тях. Това позволява лесна интеграция и не налага конкретен състав (и ред) на компонентите. Например, в някои случаи това ни позволява да интегрираме директно системата за обработка с системата за проследяване на предупреждения. В такъв случай това ще бъде направено в съответствие със споразумения контракт за предупреждения. Това означава, че и двата компонента ще бъдат интегрирани с използване на контракт, който може да бъде използван и от всеки друг компонент. Няма да добавяме допълнителен контракт за добавяне на предупреждения в системата за проследяване от системата за вход. Този подход изисква използването на предварително определено минимално количество контракти и улеснява системата и комуникацията. По същество, ние използваме подход, наречен „Дизайн с контракти на първо място“, и го прилагаме към контрактите за поток на данни. [2]

Стрийминг навсякъде

Запазването и управлението на състоянието в системата неизбежно ще доведе до усложнения в реализирането й. В общия случай, състоянието трябва да бъде достъпно от всеки компонент, да е консистентно и да предоставя най-актуалната стойност за всички компоненти, а също така да бъде надеждно с правилните стойности. Освен това, наличието на извиквания към постоянно хранилище за получаване на последното състояние увеличава броя на операциите на вход/изход и сложността на алгоритмите, използвани в нашите потоци в реално време. Поради това решихме да премахнем съхраняването на състоянието, доколкото е възможно, от нашата система. Този подход изисква включване на всички необходими данни в предаваното блокче (съобщение). Например, ако трябва да изчислим общото количество на определени наблюдения (броя на операциите или случаите с определени характеристики), го изчисляваме в паметта и генерираме поток от такива стойности. Зависимите модули ще използват разделяне (partition) и пакетиране (batch) за разчупване на потока по единици и работа с последните стойности. Този подход елиминира необходимостта от постоянно дисково хранилище за такива данни. Нашата система използва Kafka като брокер за съобщения и може да се използва като база данни с KSQL. [3] Но използването му би свързало нашето решение с Kafka, и решихме да не го използваме. Избраният от нас подход позволява замяна на Kafka с друг брокер за съобщения без сериозни вътрешни промени в системата.

Тази концепция не означава, че не използваме дискови хранилища и бази данни. За проверка и анализ на производителността на системата е необходимо да съхраняваме на диска значителна част от данните, които представляват различни показатели и състояния. Важен момент тук е, че алгоритмите в реално време не зависят от такива данни. В повечето случаи използваме съхранените данни за автономен анализ, дебъгване и проследяване на конкретни случаи и резултати, които системата издава.

Проблеми на нашата система

Съществуват определени проблеми, които решихме до известна степен, но те изискват по-добри решения. Сега просто бих искал да ги спомена тук, защото всяка точка заслужава отделна статия.

Все още трябва да определим процесите и политиките, които подпомагат натрупването на значими и актуални данни за нашия автоматичен анализ, откриване и изследване на данни.
Внедряването на резултатите от анализа, извършен от човек, в процеса на автоматична настройка на системата за обновление с последните данни. Това не само обновява нашия модел, но също така обновява процесите и подобрява разбирането на нашите данни.
Намирането на баланс между детерминирания подход IF-ELSE и ML. Някой е казал: "ML е инструмент за отчаяните". Това означава, че ще искате да използвате ML, когато вече не разбирате как да оптимизирате и подобрите алгоритмите си. От друга страна, детерминираният подход не позволява откриването на аномалии, които не са предвидени.
Нуждаем се от лесен начин да проверим нашите хипотези или корелации между метриките в данните.
Системата трябва да има няколко нива на истински положителни (true positive) резултати. Случаите на измама са само част от всички случаи, които могат да се считат за положителни за системата. Например, анализаторите искат да получават всички подозрителни случаи за проверка, и едва част от тях - измама. Системата трябва да предоставя ефективно на анализаторите всички случаи, независимо дали това е реална измама или просто подозително поведение.
Платформата за данни трябва да позволява получаване на набори от данни за предишни периоди с изчисления, създадени и изчислени в реално време.
Просто и автоматично разгръщане на всеки от компонентите на системата в най-малко три различни среди: производствена, експериментална (бета) и за разработчици.
И накрая, но не на последно място. Трябва да създадем обширна платформа за тестване на производителността, на която да можем да анализираме нашите модели. [4]