Կայքում ներխուժողների դեմ պայքարի ավտոմատ համակարգի ստեղծում (խարդախություն)

Վերջին մոտ վեց ամիսների ընթացքում ես ստեղծել եմ խարդախության դեմ պայքարի համակարգ (խարդախություն, խարդախություն և այլն), առանց դրա համար նախնական ենթակառուցվածքի: Այսօրվա գաղափարները, որոնք մենք գտել և ներդրել ենք մեր համակարգում, օգնում են մեզ բացահայտել և վերլուծել բազմաթիվ խարդախ գործողություններ: Այս հոդվածում կուզենայի խոսել այն սկզբունքների մասին, որոնց հետևում էինք և ինչ արեցինք մեր համակարգի ներկայիս վիճակին հասնելու համար՝ չխորանալով տեխնիկական մասի մեջ։

Մեր համակարգի սկզբունքները

Երբ լսում եք «ավտոմատ» և «խարդախություն» տերմիններ, ամենայն հավանականությամբ սկսում եք մտածել մեքենայական ուսուցման, Apache Spark-ի, Hadoop-ի, Python-ի, Airflow-ի և այլ տեխնոլոգիաների մասին Apache Foundation-ի էկոհամակարգից և Data Science դաշտից: Կարծում եմ, որ այս գործիքների օգտագործման մի ասպեկտ կա, որը սովորաբար չի նշվում. դրանք պահանջում են որոշակի նախադրյալներ ձեր ձեռնարկության համակարգում, նախքան դուք կարող եք դրանք օգտագործել: Մի խոսքով, ձեզ անհրաժեշտ է ձեռնարկության տվյալների հարթակ, որը ներառում է տվյալների լիճ և պահեստ: Բայց ինչ անել, եթե դուք չունեք նման հարթակ և դեռ պետք է զարգացնեք այս պրակտիկան: Հետևյալ սկզբունքները, որոնք ես կիսում եմ ստորև, օգնել են մեզ հասնել մի կետի, որտեղ մենք կարող ենք կենտրոնանալ մեր գաղափարների բարելավման վրա, այլ ոչ թե գտնել այն, որն աշխատում է: Այնուամենայնիվ, սա նախագծի բարձրավանդակ չէ: Ծրագրում դեռ շատ բաներ կան տեխնոլոգիական և ապրանքային տեսակետից։

Սկզբունք 1. Բիզնեսի արժեքը նախ

Մենք «բիզնեսի արժեքը» դնում ենք մեր բոլոր ջանքերի առաջնագծում: Ընդհանուր առմամբ, ցանկացած ավտոմատ վերլուծության համակարգ պատկանում է ավտոմատացման և տեխնիկական բարդության բարձր մակարդակ ունեցող համալիր համակարգերի խմբին։ Ամբողջական լուծում ստեղծելը շատ ժամանակ կպահանջի, եթե այն զրոյից ստեղծեք: Մենք որոշեցինք առաջին տեղում դնել բիզնեսի արժեքը, երկրորդում՝ տեխնոլոգիական ամբողջականությունը: Իրական կյանքում դա նշանակում է, որ մենք չենք ընդունում առաջադեմ տեխնոլոգիաները որպես դոգմա: Մենք ընտրում ենք այն տեխնոլոգիան, որն այս պահին մեզ համար լավագույնս է աշխատում: Ժամանակի ընթացքում կարող է թվալ, որ մենք ստիպված կլինենք նորից ներդնել որոշ մոդուլներ։ Սա այն փոխզիջումն է, որը մենք ընդունեցինք։

Սկզբունք 2. Ընդլայնված ինտելեկտ

Գրազ եմ գալիս, որ մարդկանց մեծ մասը, ովքեր խորապես ներգրավված չեն մեքենայական ուսուցման լուծումների մշակման մեջ, կարող են մտածել, որ մարդկանց փոխարինելը նպատակն է: Իրականում, մեքենայական ուսուցման լուծումները հեռու են կատարյալ լինելուց և միայն որոշակի ոլորտներում է հնարավոր փոխարինումը: Մենք ի սկզբանե մերժեցինք այս գաղափարը մի քանի պատճառներով՝ խարդախության անհավասարակշռված տվյալներ և մեքենայական ուսուցման մոդելների գործառույթների համապարփակ ցանկ տրամադրելու անկարողություն: Ի հակադրություն, մենք ընտրեցինք ուժեղացված ինտելեկտի տարբերակը: Սա արհեստական ​​ինտելեկտի այլընտրանքային հայեցակարգ է, որը կենտրոնանում է AI-ի օժանդակ դերի վրա՝ ընդգծելով այն փաստը, որ ճանաչողական տեխնոլոգիաները կոչված են զարգացնել մարդկային ինտելեկտը, այլ ոչ թե փոխարինել այն: [1]

Հաշվի առնելով դա, ի սկզբանե մեքենայական ուսուցման ամբողջական լուծում մշակելը հսկայական ջանքեր կպահանջի, ինչը կհետաձգի մեր բիզնեսի համար արժեքի ստեղծումը: Մենք որոշեցինք կառուցել մեքենայական ուսուցման անընդհատ աճող համակարգ՝ մեր տիրույթի փորձագետների ղեկավարությամբ: Նման համակարգի մշակման մարտահրավերն այն է, որ այն պետք է մեր վերլուծաբաններին տրամադրի դեպքեր ոչ միայն այն առումով, թե դա խարդախ գործունեություն է, թե ոչ: Ընդհանուր առմամբ, հաճախորդի վարքագծի ցանկացած անոմալիա կասկածելի դեպք է, որը մասնագետները պետք է հետաքննեն և ինչ-որ կերպ արձագանքեն: Այս հաղորդված դեպքերի միայն մի մասը կարող է իսկապես դասակարգվել որպես խարդախություն:

Սկզբունք 3. Rich Analytics հարթակ

Մեր համակարգի ամենադժվար մասը համակարգի աշխատանքի հոսքի վերջնական ստուգումն է: Վերլուծաբաններն ու մշակողները պետք է հեշտությամբ ստանան պատմական տվյալների հավաքածուներ՝ վերլուծության համար օգտագործվող բոլոր չափանիշներով: Բացի այդ, տվյալների պլատֆորմը պետք է ապահովի գոյություն ունեցող չափորոշիչները նորերով համալրելու հեշտ ճանապարհ: Գործընթացները, որոնք մենք ստեղծում ենք, և դրանք պարզապես ծրագրային գործընթացներ չեն, պետք է թույլ տան մեզ հեշտությամբ վերահաշվարկել նախորդ ժամանակաշրջանները, ավելացնել նոր չափումներ և փոխել տվյալների կանխատեսումը: Մենք կարող էինք հասնել դրան՝ կուտակելով բոլոր տվյալները, որոնք ստեղծում է մեր արտադրական համակարգը: Այս դեպքում տվյալները կամաց-կամաց կդառնան անհանգստություն։ Մենք պետք է պահենք աճող քանակությամբ տվյալներ, որոնք մենք չենք օգտագործում և պաշտպանենք դրանք: Նման սցենարի դեպքում տվյալները ժամանակի ընթացքում ավելի ու ավելի անտեղի կդառնան, բայց դեռ պահանջում են մեր ջանքերը՝ դրանք կառավարելու համար: Մեզ համար տվյալների կուտակումն իմաստ չուներ, ուստի մենք որոշեցինք այլ մոտեցում ցուցաբերել: Մենք որոշեցինք իրական ժամանակի տվյալների պահեստներ կազմակերպել թիրախային միավորների շուրջ, որոնք ցանկանում ենք դասակարգել, և պահպանել միայն այն տվյալները, որոնք թույլ են տալիս ստուգել ամենավերջին և համապատասխան ժամանակաշրջանները: Այս ջանքերի մարտահրավերն այն է, որ մեր համակարգը տարասեռ է, ունի բազմաթիվ տվյալների պահեստներ և ծրագրային մոդուլներ, որոնք պահանջում են մանրակրկիտ պլանավորում՝ հետևողական կերպով աշխատելու համար:

Մեր համակարգի նախագծման գաղափարները

Մենք ունենք չորս հիմնական բաղադրիչ մեր համակարգում՝ ներթափանցման համակարգ, հաշվողական, BI վերլուծություն և հետևելու համակարգ: Դրանք ծառայում են կոնկրետ, մեկուսացված նպատակների, և մենք դրանք մեկուսացված ենք պահում՝ հետևելով հատուկ դիզայնի մոտեցումներին:

Պայմանագրի վրա հիմնված դիզայն

Նախ, մենք համաձայնեցինք, որ բաղադրիչները պետք է հիմնվեն միայն որոշակի տվյալների կառուցվածքների (պայմանագրերի) վրա, որոնք փոխանցվում են նրանց միջև: Սա հեշտացնում է դրանց միջև ինտեգրումը և բաղադրիչների հատուկ կազմը (և կարգը) չպարտադրելը: Օրինակ, որոշ դեպքերում դա մեզ թույլ է տալիս ուղղակիորեն ինտեգրել ընդունման համակարգը զգուշացման հետագծման համակարգի հետ: Նման դեպքում դա արվելու է համաձայնեցված ահազանգման պայմանագրին համապատասխան: Սա նշանակում է, որ երկու բաղադրիչներն էլ ինտեգրվելու են պայմանագրի միջոցով, որը կարող է օգտագործել ցանկացած այլ բաղադրիչ: Մենք լրացուցիչ պայմանագիր չենք ավելացնի մուտքագրման համակարգից հետևելու համակարգին ծանուցումներ ավելացնելու համար: Այս մոտեցումը պահանջում է կանխորոշված ​​նվազագույն թվով պայմանագրերի օգտագործում և հեշտացնում է համակարգը և հաղորդակցությունը: Ըստ էության, մենք ընդունում ենք մի մոտեցում, որը կոչվում է «Պայմանագրի առաջին ձևավորում» և կիրառում այն ​​հոսքային պայմանագրերի համար: [2]

Ամենուր հոսք

Համակարգում վիճակի պահպանումն ու կառավարումն անխուսափելիորեն բարդությունների կհանգեցնի դրա իրականացմանը։ Ընդհանուր առմամբ, վիճակը պետք է հասանելի լինի ցանկացած բաղադրիչից, այն պետք է լինի հետևողական և ապահովի ամենաարդիական արժեքը բոլոր բաղադրիչների համար, և այն պետք է հուսալի լինի ճիշտ արժեքներով: Բացի այդ, վերջին վիճակն առբերելու համար մշտական ​​պահեստի զանգեր կատարելը կավելացնի I/O գործառնությունների քանակը և մեր իրական ժամանակի խողովակաշարերում օգտագործվող ալգորիթմների բարդությունը: Դրա պատճառով մենք որոշեցինք հնարավորության դեպքում ամբողջությամբ հեռացնել պետական ​​պահեստը մեր համակարգից: Այս մոտեցումը պահանջում է, որ բոլոր անհրաժեշտ տվյալները ներառվեն փոխանցված տվյալների բլոկում (հաղորդագրություն): Օրինակ, եթե մեզ անհրաժեշտ է հաշվարկել որոշ դիտարկումների ընդհանուր թիվը (գործողությունների թիվը կամ դեպքերը որոշակի բնութագրերով), մենք այն հաշվում ենք հիշողության մեջ և ստեղծում նման արժեքների հոսք։ Կախված մոդուլները կօգտագործեն բաժանումը և փաթեթավորումը՝ հոսքը միավորների բաժանելու և վերջին արժեքների վրա գործելու համար: Այս մոտեցումը վերացրեց նման տվյալների համար մշտական ​​սկավառակի պահպանման անհրաժեշտությունը: Մեր համակարգը օգտագործում է Kafka-ն որպես հաղորդագրության բրոքեր և այն կարող է օգտագործվել որպես տվյալների բազա KSQL-ով: [3] Բայց դրա օգտագործումը մեր լուծումը մեծապես կկապեր Կաֆկայի հետ, և մենք որոշեցինք չօգտագործել այն: Մեր ընտրած մոտեցումը թույլ է տալիս փոխարինել Կաֆկային մեկ այլ հաղորդագրության բրոքերով՝ առանց համակարգի ներքին լուրջ փոփոխությունների:

Այս հայեցակարգը չի նշանակում, որ մենք չենք օգտագործում սկավառակի պահեստավորում և տվյալների բազաներ: Համակարգի աշխատանքը ստուգելու և վերլուծելու համար մենք պետք է սկավառակի վրա պահենք զգալի քանակությամբ տվյալներ, որոնք ներկայացնում են տարբեր չափումներ և վիճակներ: Այստեղ կարևոր կետն այն է, որ իրական ժամանակի ալգորիթմները կախված չեն նման տվյալներից: Շատ դեպքերում մենք օգտագործում ենք պահված տվյալները անցանց վերլուծության, վրիպազերծման և հետևելու կոնկրետ դեպքերի և արդյունքների, որոնք համակարգը արտադրում է:

Մեր համակարգի խնդիրները

Կան որոշակի խնդիրներ, որոնք մենք որոշակի մակարդակով լուծել ենք, բայց դրանք ավելի մտածված լուծումներ են պահանջում։ Այժմ ես պարզապես կցանկանայի նշել դրանք այստեղ, քանի որ յուրաքանչյուր կետ արժե իր հոդվածը:

• Մենք դեռ պետք է սահմանենք գործընթացներ և քաղաքականություններ, որոնք աջակցում են բովանդակալից և համապատասխան տվյալների կուտակմանը մեր ավտոմատացված տվյալների վերլուծության, հայտնաբերման և որոնման համար:
• Մարդկային վերլուծության ընդգրկումը հանգեցնում է համակարգի ավտոմատ ստեղծման գործընթացին՝ այն թարմացնելու վերջին տվյալներով: Սա ոչ միայն թարմացնում է մեր մոդելը, այլ նաև մեր գործընթացները և բարելավում է մեր տվյալների ընկալումը:
• Գտնելով հավասարակշռություն IF-ELSE-ի և ML-ի դետերմինիստական ​​մոտեցման միջև: Ինչ-որ մեկն ասաց. «ML-ը գործիք է հուսահատների համար»: Սա նշանակում է, որ դուք կցանկանաք օգտագործել ML, երբ այլևս չեք հասկանում, թե ինչպես օպտիմալացնել և բարելավել ձեր ալգորիթմները: Մյուս կողմից, դետերմինիստական ​​մոտեցումը թույլ չի տալիս հայտնաբերել այնպիսի անոմալիաներ, որոնք չէին ակնկալվում։
• Մեզ անհրաժեշտ է պարզ միջոց՝ ստուգելու մեր վարկածները կամ տվյալների չափումների միջև հարաբերակցությունը:
• Համակարգը պետք է ունենա իրական դրական արդյունքների մի քանի մակարդակ: Խարդախության դեպքերը բոլոր դեպքերի միայն մի մասն են, որոնք կարելի է դրական համարել համակարգի համար: Օրինակ, վերլուծաբանները ցանկանում են ստուգման համար ստանալ բոլոր կասկածելի դեպքերը, և դրանց միայն մի փոքր մասն է խարդախություն։ Համակարգը պետք է արդյունավետ կերպով ներկայացնի բոլոր դեպքերը վերլուծաբաններին՝ անկախ նրանից՝ դա իրական խարդախություն է, թե պարզապես կասկածելի վարքագիծ։
• Տվյալների հարթակը պետք է հնարավորություն ունենա առբերել պատմական տվյալների հավաքածուներ՝ անմիջապես ստեղծվող և հաշվարկված հաշվարկներով:
• Հեշտությամբ և ավտոմատ կերպով տեղակայեք համակարգի բաղադրիչներից որևէ մեկը առնվազն երեք տարբեր միջավայրերում՝ արտադրական, փորձնական (բետա) և մշակողների համար:
• Եվ վերջին, բայց ոչ պակաս կարևորը. Մենք պետք է կառուցենք արդյունավետության փորձարկման հարուստ հարթակ, որի վրա մենք կարող ենք վերլուծել մեր մոդելները: [4]

Սայլակ

1. Ի՞նչ է ընդլայնված ինտելեկտը:
2. API-First Design Methodology-ի ներդրում
3. Կաֆկան վերածվում է «Իրադարձությունների հոսքային տվյալների բազայի»
4. Հասկանալով AUC - ROC կորը

Source: www.habr.com