Апошнія прыкладна паўгода я займаўся стварэннем сістэмы дужання з фродам (fraudulent activity, fraud, etc.) без якой-небудзь пачатковай інфраструктуры для гэтага. Сённяшнія ідэі, якія мы знайшлі і рэалізавалі ў нашай сістэме, дапамагаюць нам выяўляць мноства ашуканскіх дзеянняў і аналізаваць іх. У гэтым артыкуле я хацеў бы расказаць пра прынцыпы, якія мы прытрымліваліся, і пра тое, што мы зрабілі для дасягнення бягучага стану нашай сістэмы, не паглыбляючыся ў тэхнічную частку.
Прынцыпы нашай сістэмы
Калі вы чуеце такія тэрміны, як "automatic" і "fraud", вы, хутчэй за ўсё, пачынаеце думаць аб машынным навучанні, Apache Spark, Hadoop, Python, Airflow і іншых тэхналогіях экасістэмы Apache Foundation і вобласці Data Science. Я думаю, што ёсць адзін аспект выкарыстання гэтых інструментаў, які, як правіла, не згадваецца: яны патрабуюць наяўнасці пэўных папярэдніх умоў у вашай карпаратыўнай сістэме, перш чым пачаць іх выкарыстоўваць. Карацей кажучы, вам патрэбна карпаратыўная платформа даных, якая ўключае возера даных і сховішча. Але што, калі ў вас няма такой платформы і вам усё яшчэ трэба развіваць гэтую практыку? Наступныя прынцыпы, пра якія я расказваю ніжэй, дапамаглі нам дасягнуць моманту, калі мы можам засяродзіцца на паляпшэнні нашых ідэй, а не на пошуку працуючай. Тым не менш, гэта не "плато" праекта. У плане яшчэ шмат рэчаў з тэхналагічнага і прадуктовага пунктаў гледжання.
Прынцып 1: каштоўнасць для бізнесу ў першую чаргу
На чале ўсіх нашых намаганняў мы паставілі "каштоўнасць для бізнесу". У цэлым, любая сістэма аўтаматычнага аналізу адносіцца да групы складаных сістэм з высокім узроўнем аўтаматызацыі і тэхнічнай складанасцю. Стварэнне скончанага рашэння зойме плойму часу, калі вы створыце яго з нуля. Мы вырашылі паставіць на першае месца каштоўнасць бізнесу, а на другое - тэхналагічную завершанасць. У рэальным жыцці гэта азначае, што мы не прымаем перадавыя тэхналогіі, як догму. Мы выбіраем тэхналогію, якая лепш за ўсё працуе для нас на дадзены момант. З часам можа здацца, што нам давядзецца зноўку рэалізаваць некаторыя модулі. Гэты кампраміс, які мы прынялі.
Прынцып 2: Пашыраны інтэлект чалавека (augmented intelligence)
Б'юся аб заклад, большасць людзей, якія не ўцягнутыя глыбока ў распрацоўку рашэнняў машыннага навучання, могуць падумаць, што замена людзей - гэта мэта. Насамрэч, рашэнні машыннага навучання далёкія ад дасканаласці і толькі ў вызначаных абласцях магчымая замена. Мы адмовіліся ад гэтай ідэі з самага пачатку па некалькіх прычынах: незбалансаваныя дадзеныя аб ашуканскай дзейнасці і немагчымасць падаць вычарпальны спіс функцый для мадэляў машыннага навучання. У адрозненне ад гэтага, мы выбралі варыянт з пашыраным інтэлектам. Гэта альтэрнатыўная канцэпцыя штучнага інтэлекту, якая факусуецца на дапаможнай ролі ІІ, падкрэсліваючы той факт, што кагнітыўныя тэхналогіі прызначаны для паляпшэння чалавечага інтэлекту, а не для яго замены. [1]
Улічваючы гэта, распрацоўка поўнага рашэння машыннага навучання з самага пачатку запатрабавала б вялізных намаганняў, якія затрымалі б стварэнне каштоўнасці для нашага бізнесу. Мы вырашылі пабудаваць сістэму з ітэратыўна расце аспектам машыннага навучання пад кіраўніцтвам нашых экспертаў у прадметнай вобласці. Складаная частка распрацоўкі такой сістэмы складаецца ў тым, што яна павінна падаваць нашым аналітыкам кейсы не толькі з пункта гледжання таго, ці з'яўляецца гэта ашуканскай дзейнасцю ці не. Увогуле, любая анамалія ў паводзінах кліентаў - гэта падазроны выпадак, які спецыялістам неабходна расследаваць і неяк рэагаваць. Толькі некаторая частка гэтых зафіксаваных выпадкаў сапраўды можа быць аднесена да катэгорыі махлярства.
Прынцып 3: платформа шырокіх аналітычных дадзеных
Самая складаная частка нашай сістэмы - гэта скразная праверка працоўнага працэсу сістэмы. Аналітыкі і распрацоўшчыкі павінны лёгка атрымліваць наборы дадзеных за мінулыя перыяды з усімі метрыкамі, якія выкарыстоўваліся для аналізу. Акрамя таго, платформа даных павінна прадастаўляць просты спосаб дапоўніць існуючы набор паказчыкаў новым. Працэсы, якія мы ствараем, а гэта не толькі праграмныя працэсы, павінны дазваляць лёгка пералічваць папярэднія перыяды, дадаваць новыя метрыкі і змяняць прагноз даных. Мы маглі б дабіцца гэтага, назапашваючы ўсе дадзеныя, якія генеруе наша вытворчая сістэма. У такім выпадку дадзеныя паступова сталі б перашкодай. Нам трэба было б захоўваць які расце аб'ём дадзеных, якія мы не выкарыстоўваем, і абараняць іх. У такім сцэнары з часам дадзеныя будуць станавіцца ўсё больш і больш нерэлевантнымі, але па-ранейшаму патрабуюць нашых намаганняў для кіравання імі. Для нас назапашванне дадзеных (data hoarding) не мела сэнсу, і мы вырашылі выкарыстоўваць іншы падыход. Мы вырашылі арганізаваць сховішчы дадзеных у рэальным часе вакол мэтавых сутнасцяў, якія мы жадаем класіфікаваць, і захоўваць толькі тыя дадзеныя, якія дазваляюць правяраць самыя апошнія і актуальныя перыяды. Складанасць гэтых намаганняў заключаецца ў тым, што наша сістэма з'яўляецца неаднароднай з некалькімі сховішчамі дадзеных і праграмнымі модулямі, якія патрабуюць ўважлівага планавання для ўзгодненай працы.
Канструктыўныя канцэпцыі нашай сістэмы
У нас ёсць чатыры асноўныя кампаненты ў нашай сістэме: сістэма прыёму (ingestion system), вылічэнні (computational), аналіз (BI analysis) і сістэма адсочвання (tracking system). Яны служаць для канкрэтных ізаляваных мэт, і мы трымаем іх ізаляванымі, прытрымліваючыся пэўным падыходам у распрацоўцы.
Дызайн на аснове кантрактаў
Перш за ўсё мы дамовіліся, што кампаненты павінны спадзявацца толькі на пэўныя структуры дадзеных (кантракты), якія перадаюцца паміж імі. Гэта дазваляе лёгка інтэграваць паміж імі і не навязваць пэўны склад (і парадак) кампанентаў. Напрыклад, у некаторых выпадках гэта дазваляе нам наўпрост інтэграваць сістэму прыёму з сістэмай адсочвання папярэджанняў. У такім выпадку гэта будзе зроблена ў адпаведнасці з узгодненым кантрактам на абвесткі. Гэта азначае, што абодва кампаненты будуць інтэграваныя з выкарыстаннем кантракта, які можа выкарыстоўваць любы іншы кампанент. Мы не будзем дадаваць дадатковы кантракт на даданне папярэджанняў у сістэму адсочвання з сістэмы ўводу. Такі падыход патрабуе выкарыстання загадзя вызначанай мінімальнай колькасці кантрактаў і спрашчае сістэму і камунікацыі. Па сутнасці, мы выкарыстоўваем падыход, які называецца "Contract First Design", і ўжываем яго да кантрактаў струменевай перадачы дадзеных. [2]
Стрымінг усюды
Захаванне і кіраванне станам у сістэме непазбежна прывядзе да ўскладненняў у яе рэалізацыі. У агульным выпадку, стан павінен быць даступным з любога кампанента, яно павінна быць узгодненым і падаваць найболей актуальнае значэнне для ўсіх кампанентаў, і яно павінна быць надзейным з правільнымі значэннямі. Акрамя таго, наяўнасць выклікаў да пастаяннага сховішча для атрымання апошняга стану павялічыць колькасць аперацый уводу-вываду і складанасць алгарытмаў, якія выкарыстоўваюцца ў нашых канвеерах рэальнага часу. З-за гэтага мы вырашылі прыбрацца захоўванне стану, па магчымасці, цалкам з нашай сістэмы. Гэты падыход патрабуе ўключэння ўсіх неабходных дадзеных у перадаваны блок дадзеных (паведамленне). Напрыклад, калі нам трэба вылічыць агульную колькасць некаторых назіранняў (колькасць аперацый або выпадкаў з пэўнымі характарыстыкамі), мы вылічаем яго ў памяці і генеруем паток такіх значэнняў. Залежныя модулі будуць выкарыстоўваць разбіццё (partition) і пакетаванне (batch) для драбнення струменя па сутнасцях і аперавання апошнімі значэннямі. Гэты падыход ухіліў неабходнасць мець сталае дыскавае сховішча для такіх дадзеных. Наша сістэма выкарыстоўвае Kafka ў якасці брокера паведамленняў, і яго можна выкарыстоўваць як базу даных з KSQL. [3] Але яго выкарыстанне моцна звязала б наша рашэнне з Kafka, і мы вырашылі не выкарыстоўваць яго. Абраны намі падыход дазваляе замяніць Kafka іншым брокерам паведамленняў без сур'ёзных унутраных змен сістэмы.
Гэтая канцэпцыя не азначае, што мы не выкарыстоўваем дыскавыя сховішчы і базы дадзеных. Для праверкі і аналізу прадукцыйнасці сістэмы нам неабходна захоўваць на дыску значную частку дадзеных, якія прадстаўляюць розныя паказчыкі і станы. Важным момантам тут з'яўляецца тое, што алгарытмы рэальнага часу не залежаць ад такіх даных. У большасці выпадкаў мы выкарыстоўваем захаваныя дадзеныя для аўтаномнага аналізу, адладкі і адсочванні пэўных выпадкаў і вынікаў, якія выдае сістэма.
Праблемы нашай сістэмы
Ёсьць пэўныя праблемы, якія мы вырашылі да пэўнага ўзроўню, але яны патрабуюць больш прадуманых рашэньняў. Цяпер я проста хацеў бы згадаць іх тут, таму што кожны пункт стаіць асобнага артыкула.
- Нам усё яшчэ неабходна вызначыць працэсы і палітыкі, якія садзейнічаюць назапашванню значных і актуальных дадзеных для нашага аўтаматычнага аналізу, выяўлення і даследавання дадзеных.
- Укараненне вынікаў аналізу чалавекам у працэс аўтаматычнай наладкі сістэмы для яе абнаўлення на апошніх дадзеных. Гэта не толькі абнаўленне нашай мадэлі, але таксама абнаўленне працэсаў і паляпшэнне разумення нашых дадзеных.
- Знаходжанне балансу паміж дэтэрмініраваным падыходам IF-ELSE і ML. Хтосьці сказаў: «ML - гэта прылада для якіх у роспачы». Гэта азначае, што вы захочаце выкарыстоўваць ML, калі больш не разумееце, як аптымізаваць і палепшыць свае алгарытмы. З іншага боку, дэтэрмінаваны падыход не дазваляе выяўленне анамалій, якія не былі прадугледжаны.
- Нам патрэбен просты спосаб праверыць нашы гіпотэзы ці каарэляцыі паміж метрыкамі ў дадзеных.
- Сістэма павінна мець некалькі ўзроўняў сапраўды дадатных (true positive) вынікаў. Выпадкі махлярства - гэта толькі частка ўсіх выпадкаў, якія можна лічыць станоўчымі для сістэмы. Напрыклад, аналітыкі хочуць атрымліваць усе падазроныя выпадкі для праверкі, і толькі невялікая частка з іх - махлярства. Сістэма павінна эфектыўна падаваць аналітыкам усе выпадкі, незалежна ад таго, ці з'яўляецца гэта рэальным махлярствам ці проста падазронымі паводзінамі.
- Платформа даных павінна дазваляць атрымліваць наборы даных за мінулыя перыяды з вылічэннямі, створанымі і разлічанымі на лета.
- Простае і аўтаматычнае разгортванне любога з кампанентаў сістэмы прынамсі ў трох розных асяроддзях: вытворчай, эксперыментальнай (бэта) і для распрацоўнікаў.
- І апошняе, але не менш важнае. Нам неабходна стварыць шырокую платформу праверкі прадукцыйнасці, на якой мы зможам аналізаваць нашы мадэлі. [4]
Спасылкі
Крыніца: habr.com