🥇Създаване на автоматична система за борба с натрапници в сайта (измама)

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

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

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

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

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

Принцип 2: Увеличен интелект

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

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

Принцип 3: Богата платформа за анализ

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

Дизайнерски концепции на нашата система

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

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

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

Поточно предаване навсякъде

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

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

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

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

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

Позоваването

Източник: www.habr.com

Създаване на автоматична система за борба с натрапници в сайта (измама)