Sa nakalipas na humigit-kumulang anim na buwan, gumagawa ako ng isang sistema para labanan ang pandaraya (aktibidad ng panloloko, pandaraya, atbp.) nang walang anumang paunang imprastraktura para dito. Ang mga ideya ngayon na nakita at ipinatupad namin sa aming system ay nakakatulong sa amin na makita at masuri ang maraming mapanlinlang na aktibidad. Sa artikulong ito, nais kong pag-usapan ang tungkol sa mga prinsipyong sinusunod namin at kung ano ang ginawa namin upang makamit ang kasalukuyang estado ng aming system, nang hindi napupunta nang malalim sa teknikal na bahagi.
Mga prinsipyo ng ating sistema
Kapag nakarinig ka ng mga termino tulad ng "awtomatiko" at "panloloko," malamang na magsisimula kang mag-isip tungkol sa machine learning, Apache Spark, Hadoop, Python, Airflow, at iba pang mga teknolohiya mula sa Apache Foundation ecosystem at sa field ng Data Science. Sa tingin ko mayroong isang aspeto ng paggamit ng mga tool na ito na hindi karaniwang nababanggit: nangangailangan ang mga ito ng ilang partikular na kinakailangan sa iyong enterprise system bago mo masimulang gamitin ang mga ito. Sa madaling salita, kailangan mo ng enterprise data platform na may kasamang data lake at warehouse. Ngunit paano kung wala kang ganoong plataporma at kailangan mo pa ring bumuo ng kasanayang ito? Ang mga sumusunod na prinsipyo na ibinabahagi ko sa ibaba ay nakatulong sa amin na maabot ang punto kung saan maaari kaming tumuon sa pagpapabuti ng aming mga ideya sa halip na maghanap ng isa na gumagana. Gayunpaman, hindi ito isang talampas ng proyekto. Marami pa ring bagay sa plano mula sa teknolohikal at pananaw ng produkto.
Prinsipyo 1: Halaga ng Negosyo Una
Inilalagay namin ang "halaga sa negosyo" sa unahan ng lahat ng aming mga pagsisikap. Sa pangkalahatan, ang anumang awtomatikong sistema ng pagsusuri ay kabilang sa pangkat ng mga kumplikadong sistema na may mataas na antas ng automation at teknikal na kumplikado. Ang paggawa ng kumpletong solusyon ay aabutin ng maraming oras kung gagawin mo ito mula sa simula. Nagpasya kaming unahin ang halaga ng negosyo at pangalawa ang pagkakumpleto ng teknolohiya. Sa totoong buhay, nangangahulugan ito na hindi natin tinatanggap ang advanced na teknolohiya bilang dogma. Pinipili namin ang teknolohiyang pinakamahusay na gumagana para sa amin sa ngayon. Sa paglipas ng panahon, tila kailangan nating muling ipatupad ang ilang mga module. Ito ang kompromiso na tinanggap namin.
Prinsipyo 2: Pinahusay na katalinuhan
Pustahan ako na ang karamihan sa mga tao na hindi gaanong kasangkot sa pagbuo ng mga solusyon sa pag-aaral ng machine ay maaaring isipin na ang pagpapalit ng mga tao ay ang layunin. Sa katunayan, ang mga solusyon sa pag-aaral ng machine ay malayo sa perpekto at sa ilang partikular na lugar lamang posible ang pagpapalit. Tinanggihan namin ang ideyang ito sa simula dahil sa ilang kadahilanan: hindi balanseng data sa mapanlinlang na aktibidad at kawalan ng kakayahang magbigay ng komprehensibong listahan ng mga feature para sa mga modelo ng machine learning. Sa kabaligtaran, pinili namin ang pinahusay na opsyon sa katalinuhan. Ito ay isang alternatibong konsepto ng artificial intelligence na nakatutok sa pagsuporta sa papel ng AI, na nagbibigay-diin sa katotohanan na ang mga teknolohiyang nagbibigay-malay ay nilayon upang pahusayin ang katalinuhan ng tao sa halip na palitan ito. [1]
Dahil dito, ang pagbuo ng kumpletong solusyon sa pag-aaral ng makina mula sa simula ay mangangailangan ng malaking pagsisikap, na maaantala ang paglikha ng halaga para sa ating negosyo. Nagpasya kaming bumuo ng system na may umuulit na lumalagong aspeto ng machine learning sa ilalim ng gabay ng aming mga eksperto sa domain. Ang mapaghamong bahagi ng pagbuo ng naturang sistema ay kailangan nitong bigyan ang aming mga analyst ng mga kaso hindi lamang kung ito ay mapanlinlang na aktibidad o hindi. Sa pangkalahatan, ang anumang anomalya sa gawi ng customer ay isang kahina-hinalang kaso na kailangang imbestigahan at tumugon ng mga espesyalista kahit papaano. Isang bahagi lamang ng mga naiulat na kaso na ito ang tunay na mauuri bilang pandaraya.
Prinsipyo 3: Rich Analytics Platform
Ang pinakamahirap na bahagi ng aming system ay ang end-to-end na pag-verify ng workflow ng system. Ang mga analyst at developer ay dapat madaling makakuha ng mga makasaysayang set ng data kasama ang lahat ng sukatan na ginagamit para sa pagsusuri. Bukod pa rito, ang platform ng data ay dapat magbigay ng isang madaling paraan upang umakma sa isang umiiral nang hanay ng mga sukatan ng mga bago. Ang mga prosesong ginagawa namin, at ang mga ito ay hindi lamang mga proseso ng software, ay dapat magbigay-daan sa aming madaling muling kalkulahin ang mga nakaraang panahon, magdagdag ng mga bagong sukatan at baguhin ang pagtataya ng data. Maaabot namin ito sa pamamagitan ng pag-iipon ng lahat ng data na nabubuo ng aming production system. Sa kasong ito, unti-unting magiging istorbo ang data. Kakailanganin naming mag-imbak ng dumaraming data na hindi namin ginagamit at protektahan ito. Sa ganitong sitwasyon, ang data ay magiging higit na walang kaugnayan sa paglipas ng panahon, ngunit nangangailangan pa rin ng aming mga pagsisikap na pamahalaan ito. Para sa amin, walang saysay ang pag-imbak ng data, kaya nagpasya kaming gumawa ng ibang paraan. Napagpasyahan naming ayusin ang mga real-time na data store sa paligid ng mga target na entity na gusto naming pag-uri-uriin, at iimbak lamang ang data na nagbibigay-daan sa aming suriin ang mga pinakabago at nauugnay na mga panahon. Ang hamon sa pagsisikap na ito ay ang aming system ay heterogenous, na may maraming data store at software module na nangangailangan ng maingat na pagpaplano upang gumana sa isang pare-parehong paraan.
Mga konsepto ng disenyo ng aming system
Mayroon kaming apat na pangunahing bahagi sa aming system: ingestion system, computational, BI analysis at tracking system. Naghahatid ang mga ito ng mga partikular at nakahiwalay na layunin, at pinapanatili namin silang nakahiwalay sa pamamagitan ng pagsunod sa mga partikular na diskarte sa disenyo.
Disenyong nakabatay sa kontrata
Una sa lahat, sumang-ayon kami na ang mga bahagi ay dapat umasa lamang sa ilang partikular na istruktura ng data (mga kontrata) na ipinapasa sa pagitan ng mga ito. Ginagawa nitong madali ang pagsasama sa pagitan ng mga ito at hindi magpataw ng isang partikular na komposisyon (at pagkakasunud-sunod) ng mga bahagi. Halimbawa, sa ilang mga kaso, nagbibigay-daan ito sa amin na direktang isama ang sistema ng paggamit sa sistema ng pagsubaybay sa alerto. Sa ganitong kaso, ito ay gagawin alinsunod sa napagkasunduang kontrata ng alerto. Nangangahulugan ito na ang parehong mga bahagi ay isasama gamit ang isang kontrata na magagamit ng anumang iba pang bahagi. Hindi kami magdadagdag ng karagdagang kontrata para magdagdag ng mga alerto sa tracking system mula sa input system. Ang diskarte na ito ay nangangailangan ng paggamit ng isang paunang natukoy na minimum na bilang ng mga kontrata at pinapasimple ang sistema at mga komunikasyon. Sa totoo lang, nagsasagawa kami ng diskarte na tinatawag na "Contract First Design" at inilalapat ito sa mga streaming na kontrata. [2]
Streaming kahit saan
Ang pag-save at pamamahala ng estado sa isang sistema ay tiyak na hahantong sa mga komplikasyon sa pagpapatupad nito. Sa pangkalahatan, ang estado ay dapat na naa-access mula sa anumang bahagi, dapat itong pare-pareho at nagbibigay ng pinakabagong halaga sa lahat ng mga bahagi, at dapat itong mapagkakatiwalaan sa mga tamang halaga. Bukod pa rito, ang pagkakaroon ng mga tawag sa paulit-ulit na storage upang mabawi ang pinakabagong estado ay magpapataas sa bilang ng mga operasyon ng I/O at pagiging kumplikado ng mga algorithm na ginagamit sa aming mga real-time na pipeline. Dahil dito, nagpasya kaming ganap na alisin ang imbakan ng estado, kung maaari, sa aming system. Ang diskarte na ito ay nangangailangan na ang lahat ng kinakailangang data ay isama sa ipinadalang data block (mensahe). Halimbawa, kung kailangan naming kalkulahin ang kabuuang bilang ng ilang mga obserbasyon (ang bilang ng mga operasyon o mga kaso na may ilang mga katangian), kinakalkula namin ito sa memorya at bumubuo ng isang stream ng mga naturang halaga. Ang mga nakadependeng module ay gagamit ng partition at batching para hatiin ang stream sa mga entity at gumana sa mga pinakabagong value. Inalis ng diskarteng ito ang pangangailangan na magkaroon ng patuloy na imbakan ng disk para sa naturang data. Ginagamit ng aming system ang Kafka bilang isang broker ng mensahe at maaari itong magamit bilang isang database na may KSQL. [3] Ngunit ang paggamit nito ay lubos na maiugnay ang aming solusyon sa Kafka, at nagpasya kaming huwag gamitin ito. Ang diskarte na pinili namin ay nagpapahintulot sa amin na palitan ang Kafka ng isa pang broker ng mensahe nang walang malalaking panloob na pagbabago sa system.
Ang konseptong ito ay hindi nangangahulugan na hindi kami gumagamit ng disk storage at mga database. Upang subukan at pag-aralan ang pagganap ng system, kailangan naming mag-imbak ng malaking halaga ng data sa disk na kumakatawan sa iba't ibang sukatan at estado. Ang mahalagang punto dito ay ang mga real-time na algorithm ay hindi nakadepende sa naturang data. Sa karamihan ng mga kaso, ginagamit namin ang nakaimbak na data para sa offline na pagsusuri, pag-debug at pagsubaybay sa mga partikular na kaso at resulta na ginagawa ng system.
Mga problema ng ating sistema
Mayroong ilang mga problema na nalutas namin sa isang tiyak na antas, ngunit nangangailangan sila ng mas maalalahanin na mga solusyon. Ngayon gusto ko lang banggitin ang mga ito dito dahil ang bawat punto ay nagkakahalaga ng sarili nitong artikulo.
- Kailangan pa rin naming tukuyin ang mga proseso at patakaran na sumusuporta sa akumulasyon ng makabuluhan at may-katuturang data para sa aming awtomatikong pagsusuri, pagtuklas, at paggalugad ng data.
- Ang pagsasama ng pagsusuri ng tao ay nagreresulta sa proseso ng awtomatikong pag-set up ng system upang i-update ito sa pinakabagong data. Hindi lamang nito ina-update ang aming modelo, ngunit ang pag-update din ng aming mga proseso at pagpapabuti ng aming pag-unawa sa aming data.
- Paghahanap ng balanse sa pagitan ng deterministikong diskarte ng IF-ELSE at ML. May nagsabi, "Ang ML ay isang tool para sa mga desperado." Nangangahulugan ito na gugustuhin mong gumamit ng ML kapag hindi mo na naiintindihan kung paano i-optimize at pagbutihin ang iyong mga algorithm. Sa kabilang banda, hindi pinapayagan ng deterministikong diskarte ang pagtuklas ng mga anomalya na hindi inaasahan.
- Kailangan namin ng simpleng paraan upang subukan ang aming mga hypotheses o ugnayan sa pagitan ng mga sukatan sa data.
- Ang sistema ay dapat magkaroon ng ilang antas ng tunay na positibong resulta. Ang mga kaso ng pandaraya ay bahagi lamang ng lahat ng mga kaso na maaaring ituring na positibo para sa system. Halimbawa, gustong matanggap ng mga analyst ang lahat ng mga kahina-hinalang kaso para sa pag-verify, at maliit na bahagi lang ng mga ito ang mga panloloko. Dapat na mahusay na ipakita ng system ang lahat ng kaso sa mga analyst, hindi alintana kung ito ay aktwal na panloloko o kahina-hinalang pag-uugali lamang.
- Ang platform ng data ay dapat na makuha ang mga makasaysayang set ng data na may mga kalkulasyon na nabuo at nakalkula sa mabilisang.
- Madali at awtomatikong i-deploy ang alinman sa mga bahagi ng system sa hindi bababa sa tatlong magkakaibang kapaligiran: produksyon, eksperimental (beta) at para sa mga developer.
- At huling ngunit hindi bababa sa. Kailangan nating bumuo ng isang rich performance testing platform kung saan masusuri natin ang ating mga modelo. [4]
sanggunian
Pinagmulan: www.habr.com