Posledních asi šest měsíců jsem vytvářel systém pro boj s podvody (podvodná činnost, podvody atd.), aniž bych k tomu měl počáteční infrastrukturu. Dnešní nápady, které jsme našli a implementovali do našeho systému, nám pomáhají odhalit a analyzovat mnoho podvodných aktivit. V tomto článku bych rád hovořil o principech, které jsme dodržovali a co jsme udělali pro dosažení současného stavu našeho systému, aniž bych se pouštěl do technické části.
Principy našeho systému
Když uslyšíte termíny jako „automatický“ a „podvod“, s největší pravděpodobností začnete přemýšlet o strojovém učení, Apache Spark, Hadoop, Python, Airflow a dalších technologiích v ekosystému Apache Foundation a v oblasti Data Science. Myslím, že existuje jeden aspekt používání těchto nástrojů, který se obvykle nezmiňuje: vyžadují určité předpoklady, aby byly ve vašem podnikovém systému zavedeny, než je budete moci používat. Stručně řečeno, potřebujete podnikovou datovou platformu, která zahrnuje datové jezero a úložiště. Co když ale takovou platformu nemáte a přesto potřebujete tuto praxi rozvíjet? Následující principy, které popisuji níže, nám pomohly dostat se do bodu, kdy se můžeme soustředit na zlepšování našich nápadů, spíše než na hledání fungujícího. Nejedná se však o „plató“ projektu. Z technologického i produktového hlediska je v plánu mnohem více věcí.
Zásada 1: Obchodní hodnota na prvním místě
Klademe „obchodní hodnotu“ do popředí veškerého našeho úsilí. Obecně platí, že jakýkoli automatický analytický systém patří do skupiny komplexních systémů s vysokou úrovní automatizace a technické složitosti. Vytvoření kompletního řešení zabere spoustu času, pokud jej vytvoříte od začátku. Rozhodli jsme se dát na první místo obchodní hodnotu a na druhé technologickou vyspělost. V reálném životě to znamená, že pokročilé technologie nepřijímáme jako dogma. Vybíráme technologii, která nám v tuto chvíli nejlépe vyhovuje. Postupem času se může zdát, že budeme muset některé moduly znovu implementovat. Toto je kompromis, který jsme přijali.
Princip 2: Rozšířená inteligence
Vsadím se, že většina lidí, kteří nejsou hluboce zapojeni do vývoje řešení strojového učení, si může myslet, že cílem je nahrazení člověka. Ve skutečnosti jsou řešení strojového učení daleko k dokonalosti a pouze v určitých oblastech je možná náhrada. Tuto myšlenku jsme opustili hned na začátku z několika důvodů: nevyvážená data o podvodných aktivitách a neschopnost poskytnout vyčerpávající seznam funkcí pro modely strojového učení. Naproti tomu jsme se rozhodli pro možnost rozšířené inteligence. Jedná se o alternativní koncept umělé inteligence, který se zaměřuje na podpůrnou roli AI a zdůrazňuje skutečnost, že kognitivní technologie jsou navrženy tak, aby posilovaly lidskou inteligenci, nikoli ji nahrazovaly. [1]
S ohledem na to by vývoj kompletního řešení strojového učení od začátku vyžadoval obrovské množství úsilí, které by zpozdilo vytváření hodnoty pro naše podnikání. Rozhodli jsme se vybudovat systém s iterativně rostoucím aspektem strojového učení pod vedením našich expertů na doménu. Ošemetná část vývoje takového systému spočívá v tom, že musí našim analytikům poskytnout případové studie nejen z hlediska toho, zda se jedná o podvodnou činnost či nikoli. Obecně platí, že jakákoliv anomálie v chování zákazníků je podezřelý případ, který musí specialisté prošetřit a nějak reagovat. Jen několik z těchto zaznamenaných případů lze skutečně klasifikovat jako podvod.
Princip 3: Platforma Rich Insights
Nejobtížnější částí našeho systému je end-to-end ověření pracovního postupu systému. Analytici a vývojáři by měli snadno získat historické datové sady se všemi metrikami, které byly použity pro analýzu. Kromě toho by datová platforma měla poskytovat snadný způsob, jak doplnit stávající soubor ukazatelů o nový. Procesy, které vytváříme, a nejedná se pouze o softwarové procesy, by měly usnadnit přepočítávání předchozích období, přidávání nových metrik a změnu prognózy dat. Toho bychom mohli dosáhnout shromažďováním všech dat, která náš produkční systém generuje. V takovém případě by se data postupně stala překážkou. Potřebovali bychom ukládat rostoucí množství dat, která nepoužíváme, a chránit je. V takovém scénáři budou data postupem času stále více irelevantní, ale stále vyžadují naši snahu je spravovat. Pro nás hromadění dat nedávalo smysl a rozhodli jsme se použít jiný přístup. Rozhodli jsme se uspořádat datové sklady v reálném čase kolem cílových entit, které chceme klasifikovat, a ukládat pouze data, která nám umožňují kontrolovat nejaktuálnější a nejaktuálnější období. Výzvou tohoto úsilí je, že náš systém je heterogenní s mnoha datovými úložišti a softwarovými moduly, které vyžadují pečlivé plánování, aby fungovaly konzistentním způsobem.
Koncepce designu našeho systému
V našem systému máme čtyři hlavní součásti: systém příjmu, výpočetní systém, analýzu BI a systém sledování. Slouží specifickým izolovaným účelům a my je udržujeme izolované dodržováním určitých vývojových přístupů.
Návrh na základě smlouvy
Nejprve jsme se shodli, že komponenty by se měly spoléhat pouze na určité datové struktury (kontrakty), které si mezi sebou předávají. To umožňuje snadnou integraci mezi nimi a nevynucování konkrétního složení (a pořadí) komponent. V některých případech nám to například umožňuje přímou integraci přijímacího systému se systémem sledování výstrah. V takovém případě se tak stane v souladu s dohodnutou oznamovací smlouvou. To znamená, že obě komponenty budou integrovány pomocí smlouvy, kterou může používat jakákoli jiná komponenta. Nebudeme přidávat další smlouvu na přidání upozornění do systému sledování ze vstupního systému. Tento přístup vyžaduje použití předem stanoveného minimálního počtu smluv a zjednodušuje systém a komunikaci. V zásadě používáme přístup nazvaný „Contract First Design“ a aplikujeme jej na smlouvy o streamování. [2]
Streamování všude
Ukládání a správa stavu v systému nevyhnutelně povede ke komplikacím při jeho zavádění. Obecně platí, že stav musí být přístupný z jakékoli komponenty, musí být konzistentní a poskytovat nejaktuálnější hodnotu napříč všemi komponentami a musí být spolehlivý se správnými hodnotami. Navíc volání do trvalého úložiště pro získání nejnovějšího stavu zvýší množství I/O a složitost algoritmů používaných v našich kanálech v reálném čase. Z tohoto důvodu jsme se rozhodli státní úložiště pokud možno úplně odstranit z našeho systému. Tento přístup vyžaduje, aby v přenášené datové jednotce (zprávě) byla zahrnuta všechna potřebná data. Potřebujeme-li například vypočítat celkový počet některých pozorování (počet operací nebo případů s určitými charakteristikami), spočítáme jej v paměti a vygenerujeme proud takových hodnot. Závislé moduly budou používat rozdělení a dávkování k rozdělení proudu podle entit a budou pracovat s nejnovějšími hodnotami. Tento přístup eliminoval potřebu mít trvalé diskové úložiště pro taková data. Náš systém používá Kafka jako zprostředkovatele zpráv a lze jej použít jako databázi s KSQL. [3] Ale jeho použití by naše řešení silně svázalo s Kafkou a rozhodli jsme se ho nepoužívat. Přístup, který jsme zvolili, nám umožňuje nahradit Kafku jiným zprostředkovatelem zpráv bez velkých vnitřních změn v systému.
Tento koncept neznamená, že nepoužíváme disková úložiště a databáze. Abychom mohli kontrolovat a analyzovat výkon systému, potřebujeme na disk uložit značné množství dat, která představují různé indikátory a stavy. Důležité je, že algoritmy v reálném čase na takových datech nezávisí. Ve většině případů používáme uložená data pro offline analýzu, ladění a sledování konkrétních případů a výsledků, které systém produkuje.
Problémy v našem systému
Jsou určité problémy, které jsme do určité míry vyřešili, ale vyžadují promyšlenější řešení. Prozatím bych je zde jen zmínil, protože každá položka stojí za svůj vlastní článek.
- Stále potřebujeme definovat procesy a zásady, které pomáhají generovat smysluplná a relevantní data pro naši automatizovanou analýzu, zjišťování a zkoumání dat.
- Zavedení výsledků analýzy osobou v procesu automatického ladění systému tak, aby byl aktualizován nejnovějšími daty. Nejedná se pouze o aktualizaci našeho modelu, ale také o aktualizaci našich procesů a lepší porozumění našim datům.
- Hledání rovnováhy mezi deterministickým přístupem IF-ELSE a ML. Někdo řekl: "ML je nástroj pro zoufalce." To znamená, že budete chtít používat ML, když už nebudete rozumět tomu, jak optimalizovat a zlepšovat své algoritmy. Na druhou stranu deterministický přístup neumožňuje odhalit anomálie, které nebyly předvídané.
- Potřebujeme snadný způsob, jak otestovat naše hypotézy nebo korelace mezi metrikami v datech.
- Systém musí mít více úrovní skutečně pozitivních výsledků. Případy podvodů jsou jen zlomkem všech případů, které lze považovat za pozitivní pro systém. Analytici chtějí například dostávat ke kontrole všechny podezřelé případy a jen malá část z nich je podvodná. Systém musí analytikům efektivně poskytovat všechny případy, ať už jde o skutečný podvod nebo jen o podezřelé chování.
- Datová platforma by měla být schopna získávat historické datové sady s výpočty vytvářenými a počítanými za běhu.
- Jednoduché a automatické nasazení kterékoli ze systémových komponent alespoň ve třech různých prostředích: produkční, experimentální (beta) a pro vývojáře.
- A v neposlední řadě. Potřebujeme vytvořit rozsáhlou srovnávací platformu, na které budeme moci analyzovat naše modely. [4]
reference
Zdroj: www.habr.com