Az elmúlt körülbelül hat hónapban létrehoztam egy rendszert a csalás (csalás, csalás stb.) leküzdésére, ehhez kezdeti infrastruktúra nélkül. A rendszerünkben talált és megvalósított mai ötleteink segítenek felderíteni és elemezni számos csaló tevékenységet. Ebben a cikkben azokról az elvekről szeretnék beszélni, amelyeket követtünk, és arról, hogy mit tettünk rendszerünk jelenlegi állapotának elérése érdekében, anélkül, hogy belemennék a technikai részbe.
Rendszerünk alapelvei
Amikor olyan kifejezéseket hall, mint az „automatikus” és a „csalás”, valószínűleg a gépi tanulásra, az Apache Sparkra, a Hadoopra, a Pythonra, az Airflow-ra és az Apache Foundation ökoszisztéma és a Data Science terület más technológiáira gondol. Úgy gondolom, hogy ezen eszközök használatának van egy olyan aspektusa, amelyet általában nem említenek: bizonyos előfeltételeket igényelnek a vállalati rendszerben, mielőtt elkezdené használni őket. Röviden: szüksége van egy vállalati adatplatformra, amely magában foglal egy adattót és raktárt. De mi van akkor, ha nem rendelkezik ilyen platformmal, és továbbra is fejlesztenie kell ezt a gyakorlatot? Az alábbi alapelvek, amelyeket az alábbiakban osztok meg, segítettek elérni azt a pontot, ahol ahelyett, hogy egy működőképes megoldást találnánk, ötleteink fejlesztésére összpontosíthatunk. Ez azonban nem egy projektplató. Technológiai és termékszempontból még sok minden szerepel a tervben.
1. alapelv: Először az üzleti érték
Minden erőfeszítésünkben az „üzleti értéket” helyezzük előtérbe. Általánosságban elmondható, hogy minden automatikus elemző rendszer a magas szintű automatizálással és műszaki összetettséggel rendelkező komplex rendszerek csoportjába tartozik. A teljes megoldás létrehozása sok időt vesz igénybe, ha a semmiből hozza létre. Úgy döntöttünk, hogy az üzleti értéket helyezzük előtérbe, a technológiai teljességet pedig a második helyre. A való életben ez azt jelenti, hogy nem fogadjuk el dogmaként a fejlett technológiát. Azt a technológiát választjuk, amely pillanatnyilag a számunkra legmegfelelőbb. Idővel úgy tűnhet, hogy néhány modult újra kell implementálnunk. Ez az a kompromisszum, amelyet elfogadtunk.
2. alapelv: Kiterjesztett intelligencia
Lefogadom, hogy a legtöbb ember, aki nem foglalkozik mélyen a gépi tanulási megoldások fejlesztésével, azt gondolhatja, hogy az emberek leváltása a cél. Valójában a gépi tanulási megoldások messze nem tökéletesek, és csak bizonyos területeken lehetséges a csere. Ezt az ötletet kezdettől fogva elutasítottuk több okból is: a csalárd tevékenységekre vonatkozó kiegyensúlyozatlan adatok és a gépi tanulási modellek funkcióinak átfogó listájának hiánya miatt. Ezzel szemben mi a továbbfejlesztett intelligencia opciót választottuk. Ez a mesterséges intelligencia egy alternatív koncepciója, amely az AI támogató szerepére összpontosít, hangsúlyozva azt a tényt, hogy a kognitív technológiák célja az emberi intelligencia javítása, nem pedig helyettesítése. [1]
Ennek ismeretében egy komplett gépi tanulási megoldás kidolgozása a kezdetektől hatalmas erőfeszítést igényelne, ami késlelteti vállalkozásunk értékteremtését. Úgy döntöttünk, hogy tartományszakértőink irányításával egy iteratívan növekvő gépi tanulási szempontú rendszert építünk. Egy ilyen rendszer fejlesztésének kihívást jelentő része az, hogy elemzőinket nem csak arról kell tájékoztatnia, hogy csaló tevékenységről van-e szó vagy sem. Általánosságban elmondható, hogy a vásárlói magatartás bármely rendellenessége gyanús eset, amelyet a szakembereknek ki kell vizsgálniuk, és valamilyen módon reagálniuk kell. A bejelentett eseteknek csak egy része minősíthető valóban csalásnak.
3. alapelv: Rich Analytics Platform
Rendszerünk legnagyobb kihívást jelentő része a rendszer munkafolyamatának végpontok közötti ellenőrzése. Az elemzőknek és fejlesztőknek könnyen be kell szerezniük a történeti adatkészleteket az elemzéshez használt összes mérőszámmal. Ezenkívül az adatplatformnak egyszerű módot kell kínálnia arra, hogy a meglévő mérőszámokat újakkal egészítse ki. Az általunk létrehozott folyamatoknak – és ezek nem csak szoftveres folyamatok – lehetővé kell tenni számunkra a korábbi időszakok egyszerű újraszámítását, új mérőszámok hozzáadását és az előrejelzések adatainak módosítását. Ezt úgy érhetjük el, hogy felhalmozzuk az összes adatot, amelyet a termelési rendszerünk generál. Ebben az esetben az adatok fokozatosan kellemetlenné válnának. Egyre több olyan adatot kellene tárolnunk, amelyet nem használunk, és védenünk kell azokat. Ilyen forgatókönyv esetén az adatok idővel egyre irrelevánsabbá válnak, de továbbra is erőfeszítéseket igényel a kezelésük. Számunkra az adathalmozásnak nem volt értelme, ezért úgy döntöttünk, hogy más megközelítést alkalmazunk. Úgy döntöttünk, hogy valós idejű adattárakat szervezünk a besorolni kívánt cél entitások köré, és csak azokat az adatokat tároljuk, amelyek lehetővé teszik a legfrissebb és releváns időszakok ellenőrzését. Ennek az erőfeszítésnek az a kihívása, hogy rendszerünk heterogén, több adattárral és szoftvermodullal, amelyek gondos tervezést igényelnek a következetes működéshez.
Rendszerünk tervezési koncepciói
Rendszerünkben négy fő összetevő található: feldolgozási rendszer, számítási, BI-elemző és nyomkövető rendszer. Meghatározott, elszigetelt célokat szolgálnak, és egyedi tervezési megközelítések követésével elkülönítve tartjuk őket.
Szerződés alapú tervezés
Először is megállapodtunk abban, hogy a komponensek csak bizonyos adatstruktúrákra (szerződésekre) támaszkodhatnak, amelyeket átadnak közöttük. Ez megkönnyíti a köztük lévő integrációt, és nem szabja meg az összetevők meghatározott összetételét (és sorrendjét). Például bizonyos esetekben ez lehetővé teszi számunkra, hogy közvetlenül integráljuk a szívórendszert a riasztási nyomkövető rendszerrel. Ebben az esetben ez a megállapodás szerinti riasztási szerződésnek megfelelően történik. Ez azt jelenti, hogy mindkét komponens olyan szerződés alapján lesz integrálva, amelyet bármely más összetevő használhat. Nem adunk hozzá további szerződést arra, hogy riasztásokat adjunk a nyomkövető rendszerhez a beviteli rendszerből. Ez a megközelítés előre meghatározott minimális számú szerződést igényel, és leegyszerűsíti a rendszert és a kommunikációt. Lényegében a "Contract First Design" elnevezésű megközelítést alkalmazzuk, és ezt alkalmazzuk a streaming szerződésekre. [2]
Streaming mindenhol
Az állapot mentése és kezelése egy rendszerben elkerülhetetlenül bonyodalmakhoz vezet a megvalósítás során. Általánosságban elmondható, hogy az állapotnak bármely komponensről elérhetőnek kell lennie, konzisztensnek kell lennie, és a legaktuálisabb értéket kell biztosítania az összes összetevő között, valamint megbízhatónak kell lennie a megfelelő értékekkel. Ezenkívül a perzisztens tároló hívásai a legújabb állapot lekéréséhez növelik az I/O műveletek számát és a valós idejű folyamatainkban használt algoritmusok összetettségét. Emiatt úgy döntöttünk, hogy lehetőség szerint teljesen eltávolítjuk rendszerünkből az állapottárolót. Ez a megközelítés megköveteli, hogy minden szükséges adat szerepeljen a továbbított adatblokkban (üzenetben). Például, ha ki kell számolnunk egyes megfigyelések teljes számát (bizonyos jellemzőkkel rendelkező műveletek vagy esetek számát), akkor azt kiszámoljuk a memóriában, és az ilyen értékekből egy folyamot generálunk. A függő modulok partíciót és kötegelést használnak az adatfolyam entitásokra való felosztásához, és a legújabb értékeken történő működéshez. Ez a megközelítés megszüntette az ilyen adatok állandó lemeztárának szükségességét. Rendszerünk a Kafkát használja üzenetközvetítőként, és adatbázisként használható KSQL-lel. [3] De ennek használata a megoldásunkat erősen Kafkához kötötte volna, és úgy döntöttünk, hogy nem használjuk. Az általunk választott megközelítés lehetővé teszi, hogy a Kafkát egy másik üzenetközvetítővel cseréljük le anélkül, hogy a rendszerben jelentős belső változtatásokat kellene végrehajtani.
Ez a fogalom nem jelenti azt, hogy nem használunk lemeztárakat és adatbázisokat. A rendszer teljesítményének teszteléséhez és elemzéséhez jelentős mennyiségű adatot kell tárolnunk a lemezen, amely különféle mutatókat és állapotokat képvisel. Itt az a fontos, hogy a valós idejű algoritmusok nem függenek az ilyen adatoktól. A legtöbb esetben a tárolt adatokat offline elemzésre, hibakeresésre és a rendszer által előállított konkrét esetek és eredmények nyomon követésére használjuk.
Rendszerünk problémái
Vannak bizonyos problémák, amelyeket bizonyos szintig megoldottunk, de ezek átgondoltabb megoldást igényelnek. Most csak ezeket szeretném itt megemlíteni, mert minden pont megéri a saját cikket.
- Továbbra is meg kell határoznunk azokat a folyamatokat és irányelveket, amelyek támogatják az értelmes és releváns adatok felhalmozását automatizált adatelemzésünk, -feltárásunk és -feltárásunkhoz.
- Az emberi elemzés eredményeinek beépítése a rendszer automatikus beállítási folyamatába, hogy frissítse a legfrissebb adatokat. Ez nem csak a modellünk frissítését jelenti, hanem a folyamataink frissítését és az adataink jobb megértését is.
- Az IF-ELSE és az ML determinisztikus megközelítése közötti egyensúly megtalálása. Valaki azt mondta: "Az ML a kétségbeesettek eszköze." Ez azt jelenti, hogy akkor érdemes használnia az ML-t, ha már nem tudja, hogyan optimalizálja és javítsa az algoritmusait. Másrészt a determinisztikus megközelítés nem teszi lehetővé olyan anomáliák kimutatását, amelyekre nem számítottak.
- Egy egyszerű módszerre van szükségünk hipotéziseink vagy az adatokban szereplő metrikák közötti összefüggések tesztelésére.
- A rendszernek többszintű valódi pozitív eredménnyel kell rendelkeznie. A rendszer szempontjából pozitívnak tekinthető csalási esetek csak töredékét teszik ki. Például az elemzők minden gyanús esetet szeretnének ellenőrzésre megkapni, és ezeknek csak kis része csalás. A rendszernek minden esetet hatékonyan kell bemutatnia az elemzőknek, függetlenül attól, hogy tényleges csalásról vagy csak gyanús viselkedésről van szó.
- Az adatplatformnak képesnek kell lennie előzményadatkészletek lekérésére a menet közben generált és kiszámított számításokkal.
- Könnyen és automatikusan telepítheti a rendszerkomponensek bármelyikét legalább három különböző környezetben: éles, kísérleti (béta) és fejlesztői környezetben.
- És végül de nem utolsó sorban. Ki kell építenünk egy gazdag teljesítménytesztelési platformot, amelyen elemezhetjük modelljeinket. [4]
referenciák
Forrás: will.com