در حدود شش ماه گذشته سیستمی برای مبارزه با تقلب (فعالیت متقلبانه، کلاهبرداری و ...) بدون زیرساخت اولیه برای این کار ایجاد کردم. ایده های امروزی که ما پیدا کردیم و در سیستم خود پیاده سازی کردیم به ما کمک می کند بسیاری از فعالیت های تقلبی را شناسایی و تجزیه و تحلیل کنیم. در این مقاله می خواهم در مورد اصولی که رعایت کردیم و کارهایی که برای رسیدن به وضعیت فعلی سیستم خود انجام دادیم، بدون پرداختن به قسمت فنی صحبت کنم.
اصول سیستم ما
هنگامی که عباراتی مانند "خودکار" و "تقلب" را می شنوید، به احتمال زیاد به یادگیری ماشین، Apache Spark، Hadoop، Python، Airflow و سایر فناوری ها در اکوسیستم بنیاد آپاچی و حوزه علم داده فکر می کنید. من فکر می کنم یک جنبه از استفاده از این ابزارها وجود دارد که معمولاً ذکر نشده است: آنها نیاز به پیش نیازهای خاصی دارند که در سیستم سازمانی شما قبل از شروع استفاده از آنها وجود داشته باشد. به طور خلاصه، شما به یک پلت فرم داده سازمانی نیاز دارید که شامل دریاچه داده و ذخیره سازی باشد. اما اگر چنین پلتفرمی ندارید و همچنان نیاز به توسعه این روش دارید، چه؟ اصول زیر که در زیر توضیح می‌دهم، به ما کمک کرده‌اند تا به نقطه‌ای برسیم که بتوانیم به جای یافتن ایده مؤثر، بر بهبود ایده‌هایمان تمرکز کنیم. با این حال، این یک "فلات" پروژه نیست. از نظر فناوری و محصول، موارد بسیار بیشتری در این طرح وجود دارد.
اصل 1: اول ارزش تجاری
ما "ارزش تجاری" را سرلوحه همه تلاش های خود قرار می دهیم. به طور کلی هر سیستم آنالیز خودکار در گروه سیستم های پیچیده با سطح اتوماسیون و پیچیدگی فنی بالا قرار می گیرد. ایجاد یک راه حل کامل، اگر آن را از ابتدا ایجاد کنید، زمان زیادی را می طلبد. ما تصمیم گرفتیم ارزش کسب و کار را در درجه اول قرار دهیم و بلوغ فناوری را در مرحله دوم قرار دهیم. در زندگی واقعی، این بدان معنی است که ما فناوری پیشرفته را به عنوان یک جزم نمی پذیریم. ما فناوری را انتخاب می کنیم که در حال حاضر بهترین کار را برای ما دارد. با گذشت زمان، ممکن است به نظر برسد که ما مجبور به پیاده سازی مجدد برخی از ماژول ها خواهیم بود. این سازشی است که ما پذیرفتیم.
اصل 2: هوش افزوده
شرط می‌بندم اکثر افرادی که عمیقاً درگیر توسعه راه‌حل‌های یادگیری ماشین نیستند، ممکن است فکر کنند که جایگزینی انسانی هدف است. در واقع، راه‌حل‌های یادگیری ماشینی بسیار عالی هستند و تنها در بخش‌های خاصی امکان جایگزینی وجود دارد. ما از همان ابتدا این ایده را به دلایل مختلفی کنار گذاشتیم: داده های نامتعادل در مورد فعالیت های تقلبی و ناتوانی در ارائه لیست جامعی از ویژگی ها برای مدل های یادگیری ماشین. در مقابل، ما گزینه هوش افزوده را انتخاب کردیم. این یک مفهوم جایگزین از هوش مصنوعی است که بر نقش پشتیبانی هوش مصنوعی تمرکز دارد و بر این واقعیت تأکید دارد که فناوری‌های شناختی برای تقویت هوش انسان طراحی شده‌اند، نه جایگزین آن. [1]
با در نظر گرفتن این موضوع، توسعه یک راه حل کامل یادگیری ماشینی از همان ابتدا به تلاش زیادی نیاز دارد که ایجاد ارزش برای کسب و کار ما را به تاخیر می اندازد. ما تصمیم گرفتیم تحت راهنمایی کارشناسان حوزه خود، سیستمی با جنبه‌ای رو به رشد مکرر از یادگیری ماشین بسازیم. بخش دشوار توسعه چنین سیستمی این است که باید مطالعات موردی را در اختیار تحلیلگران ما قرار دهد نه تنها از نظر اینکه آیا این یک فعالیت متقلبانه است یا خیر. به طور کلی هرگونه ناهنجاری در رفتار مشتریان یک مورد مشکوک است که متخصصان باید آن را بررسی کرده و به نحوی پاسخ دهند. فقط تعداد کمی از این موارد ثبت شده واقعاً می توانند به عنوان کلاهبرداری طبقه بندی شوند.
اصل 3: پلتفرم Rich Insights
دشوارترین بخش سیستم ما تأیید سرتاسر گردش کار سیستم است. تحلیلگران و توسعه دهندگان باید به راحتی مجموعه داده های تاریخی را با تمام معیارهایی که برای تجزیه و تحلیل استفاده شده است به دست آورند. علاوه بر این، پلت فرم داده باید راهی آسان برای تکمیل مجموعه ای از شاخص های موجود با یک شاخص جدید ارائه دهد. فرآیندهایی که ایجاد می کنیم، و اینها فقط فرآیندهای نرم افزاری نیستند، باید محاسبه مجدد دوره های قبلی، اضافه کردن معیارهای جدید و تغییر پیش بینی داده ها را آسان کند. ما می‌توانیم با جمع‌آوری تمام داده‌هایی که سیستم تولید ما تولید می‌کند به این مهم دست پیدا کنیم. در چنین حالتی، داده ها به تدریج به یک مانع تبدیل می شوند. ما باید حجم فزاینده ای از داده هایی را که استفاده نمی کنیم ذخیره کنیم و از آنها محافظت کنیم. در چنین سناریویی، داده ها به مرور زمان بی ربط تر می شوند، اما همچنان نیازمند تلاش ما برای مدیریت آن است. برای ما، احتکار داده ها معنی نداشت و تصمیم گرفتیم از روشی متفاوت استفاده کنیم. ما تصمیم گرفتیم انبارهای داده بلادرنگ را در اطراف نهادهای هدفی که می‌خواهیم طبقه‌بندی کنیم، سازماندهی کنیم و فقط داده‌هایی را ذخیره کنیم که به ما امکان می‌دهد جدیدترین و به‌روزترین دوره‌ها را بررسی کنیم. چالش این تلاش این است که سیستم ما با چندین فروشگاه داده و ماژول‌های نرم‌افزاری ناهمگن است که نیاز به برنامه‌ریزی دقیق برای کار کردن به شیوه‌ای ثابت دارد.
مفاهیم طراحی سیستم ما
ما چهار جزء اصلی در سیستم خود داریم: یک سیستم جذب، یک سیستم محاسباتی، یک تجزیه و تحلیل BI و یک سیستم ردیابی. آنها اهداف جداگانه ای را دنبال می کنند و ما با پیروی از رویکردهای توسعه خاصی آنها را منزوی نگه می داریم.
طراحی بر اساس قرارداد
اول از همه، ما توافق کردیم که مؤلفه‌ها فقط باید بر ساختارهای داده خاصی (قراردادها) متکی باشند که بین آنها منتقل می‌شود. این باعث می شود که ادغام بین آنها آسان شود و ترکیب (و ترتیب) خاصی از اجزاء تحمیل نشود. به عنوان مثال، در برخی موارد این امکان را به ما می دهد که مستقیماً سیستم دریافت کننده را با سیستم ردیابی هشدار یکپارچه کنیم. در چنین شرایطی، این امر طبق قرارداد ابلاغی توافق شده انجام خواهد شد. این بدان معنی است که هر دو مؤلفه با استفاده از قراردادی که هر مؤلفه دیگری می تواند از آن استفاده کند، یکپارچه می شود. ما قرارداد اضافی برای افزودن هشدار به سیستم ردیابی از سیستم ورودی اضافه نمی کنیم. این رویکرد مستلزم استفاده از حداقل تعداد قراردادهای از پیش تعیین شده است و سیستم و ارتباطات را ساده می کند. اساساً، ما رویکردی به نام "طراحی اول قرارداد" را در پیش گرفته و آن را در قراردادهای پخش جریانی به کار می بریم. [2]
پخش جریانی در همه جا
صرفه جویی و مدیریت وضعیت در سیستم به ناچار عوارضی را در اجرای آن به دنبال خواهد داشت. به طور کلی، وضعیت باید از هر مؤلفه قابل دسترسی باشد، باید سازگار باشد و به روزترین مقدار را در همه مؤلفه ها ارائه دهد، و باید با مقادیر صحیح قابل اعتماد باشد. علاوه بر این، داشتن تماس با ذخیره‌سازی دائمی برای دریافت آخرین وضعیت، میزان I/O و پیچیدگی الگوریتم‌های مورد استفاده در خطوط لوله بلادرنگ ما را افزایش می‌دهد. به همین دلیل، ما تصمیم گرفتیم که ذخیره سازی حالت را، در صورت امکان، به طور کامل از سیستم خود حذف کنیم. این رویکرد مستلزم آن است که تمام داده های لازم در واحد داده ارسالی (پیام) گنجانده شود. به عنوان مثال، اگر ما نیاز به محاسبه تعداد کل برخی از مشاهدات (تعداد عملیات یا موارد با ویژگی های خاص) داشته باشیم، آن را در حافظه محاسبه کرده و جریانی از چنین مقادیری را تولید می کنیم. ماژول‌های وابسته از پارتیشن‌بندی و دسته‌بندی برای تقسیم جریان بر اساس موجودیت‌ها و عملکرد بر روی آخرین مقادیر استفاده می‌کنند. این رویکرد نیاز به ذخیره سازی دائمی دیسک برای چنین داده هایی را از بین برد. سیستم ما از Kafka به عنوان واسطه پیام استفاده می کند و می تواند به عنوان پایگاه داده با KSQL استفاده شود. [3] اما استفاده از آن راه حل ما را به شدت به کافکا گره می زد و ما تصمیم گرفتیم از آن استفاده نکنیم. رویکردی که انتخاب کرده‌ایم به ما این امکان را می‌دهد که کافکا را با یک واسطه پیام دیگر بدون تغییرات داخلی عمده در سیستم جایگزین کنیم.
این مفهوم به این معنی نیست که ما از ذخیره سازی دیسک و پایگاه داده استفاده نمی کنیم. برای بررسی و تجزیه و تحلیل عملکرد سیستم، باید مقدار قابل توجهی از داده ها را روی دیسک ذخیره کنیم که نشان دهنده شاخص ها و حالت های مختلف است. نکته مهم در اینجا این است که الگوریتم های بلادرنگ به چنین داده هایی وابسته نیستند. در بیشتر موارد، ما از داده های ذخیره شده برای تجزیه و تحلیل آفلاین، اشکال زدایی و ردیابی موارد خاص و نتایجی که سیستم تولید می کند استفاده می کنیم.
مشکلات سیستم ما
مشکلات خاصی وجود دارد که ما آنها را تا حدی حل کرده ایم، اما آنها نیاز به راه حل های متفکرانه تری دارند. در حال حاضر، من فقط می خواهم آنها را در اینجا ذکر کنم، زیرا هر مورد ارزش مقاله خود را دارد.
- ما هنوز باید فرآیندها و سیاست هایی را تعریف کنیم که به تولید داده های معنادار و مرتبط برای تجزیه و تحلیل خودکار، کشف و اکتشاف داده ها کمک کند.
- معرفی نتایج تجزیه و تحلیل توسط یک فرد در فرآیند تنظیم خودکار سیستم برای به روز رسانی آن با آخرین داده ها. این نه تنها به‌روزرسانی مدل ما است، بلکه به‌روزرسانی فرآیندهای ما و درک بهتر داده‌هایمان است.
- یافتن تعادل بین رویکرد قطعی IF-ELSE و ML. شخصی گفت: ام ال وسیله ای است برای مستأصلان. این بدان معناست که وقتی دیگر نمی‌دانید چگونه الگوریتم‌های خود را بهینه کنید و بهبود دهید، می‌خواهید از ML استفاده کنید. از سوی دیگر، رویکرد جبرگرایانه امکان تشخیص ناهنجاری هایی را که پیش بینی نشده بود را نمی دهد.
- ما به یک راه آسان برای آزمایش فرضیه ها یا همبستگی بین معیارها در داده ها نیاز داریم.
- سیستم باید چندین سطح از نتایج مثبت واقعی داشته باشد. موارد کلاهبرداری تنها کسری از تمام مواردی است که می تواند برای سیستم مثبت تلقی شود. به عنوان مثال، تحلیلگران می خواهند تمام موارد مشکوک را برای بررسی دریافت کنند و تنها بخش کوچکی از آنها تقلبی هستند. سیستم باید به طور موثر همه موارد را در اختیار تحلیلگران قرار دهد، خواه کلاهبرداری واقعی باشد یا فقط رفتار مشکوک.
- پلت فرم داده باید بتواند مجموعه داده های تاریخی را با محاسبات ایجاد شده و محاسبه شده در پرواز بازیابی کند.
- استقرار ساده و خودکار هر یک از اجزای سیستم در حداقل سه محیط مختلف: تولیدی، آزمایشی (بتا) و برای توسعه دهندگان.
- و آخرین اما نه کم اهمیت ترین. ما باید یک پلتفرم معیار گسترده ایجاد کنیم که بتوانیم بر اساس آن مدل های خود را تجزیه و تحلیل کنیم. [4]
مراجع
منبع: www.habr.com