การสร้างระบบอัตโนมัติเพื่อต่อสู้กับผู้บุกรุกบนไซต์ (การฉ้อโกง)

ในช่วงหกเดือนที่ผ่านมา ฉันได้สร้างระบบเพื่อต่อต้านการฉ้อโกง (กิจกรรมการฉ้อโกง การฉ้อโกง ฯลฯ) โดยไม่มีโครงสร้างพื้นฐานเริ่มต้นสำหรับสิ่งนี้ แนวคิดในปัจจุบันที่เราพบและนำไปใช้ในระบบของเราช่วยให้เราตรวจจับและวิเคราะห์กิจกรรมที่เป็นการฉ้อโกงมากมาย ในบทความนี้ ฉันอยากจะพูดถึงหลักการที่เราปฏิบัติตามและสิ่งที่เราทำเพื่อให้บรรลุสถานะปัจจุบันของระบบ โดยไม่ต้องเจาะลึกในส่วนทางเทคนิค

หลักการของระบบของเรา

เมื่อคุณได้ยินคำว่า "อัตโนมัติ" และ "การฉ้อโกง" คุณมักจะเริ่มคิดถึงการเรียนรู้ของเครื่อง, Apache Spark, Hadoop, Python, Airflow และเทคโนโลยีอื่นๆ ในระบบนิเวศของ Apache Foundation และสาขาวิทยาศาสตร์ข้อมูล ฉันคิดว่ามีแง่มุมหนึ่งของการใช้เครื่องมือเหล่านี้ที่มักไม่ได้กล่าวถึง: เครื่องมือเหล่านี้จำเป็นต้องมีข้อกำหนดเบื้องต้นบางอย่างในระบบองค์กรของคุณก่อนที่คุณจะสามารถใช้งานได้ กล่าวโดยสรุป คุณต้องมีแพลตฟอร์มข้อมูลระดับองค์กรที่มี Data Lake และพื้นที่เก็บข้อมูล แต่ถ้าคุณไม่มีแพลตฟอร์มดังกล่าวและยังจำเป็นต้องพัฒนาแนวทางปฏิบัตินี้อยู่ล่ะ หลักการต่อไปนี้ซึ่งฉันอธิบายไว้ด้านล่างนี้ช่วยให้เราไปถึงจุดที่เราจะมุ่งเน้นไปที่การปรับปรุงความคิดของเรา แทนที่จะค้นหาแนวคิดที่ใช้งานได้ อย่างไรก็ตาม นี่ไม่ใช่ "ที่ราบสูง" ของโครงการ มีอีกหลายสิ่งในแผนจากมุมมองด้านเทคโนโลยีและผลิตภัณฑ์

หลักการที่ 1: มูลค่าทางธุรกิจอันดับแรก

เราให้ความสำคัญกับ "คุณค่าทางธุรกิจ" ในระดับแนวหน้าของความพยายามทั้งหมดของเรา โดยทั่วไปแล้ว ระบบการวิเคราะห์อัตโนมัติใดๆ อยู่ในกลุ่มของระบบที่ซับซ้อนซึ่งมีระบบอัตโนมัติและความซับซ้อนทางเทคนิคในระดับสูง การสร้างโซลูชันที่สมบูรณ์จะใช้เวลามากหากคุณสร้างตั้งแต่เริ่มต้น เราตัดสินใจที่จะให้ความสำคัญกับมูลค่าทางธุรกิจเป็นอันดับแรกและการเติบโตทางเทคโนโลยีเป็นอันดับสอง ในชีวิตจริง นี่หมายความว่าเราไม่ยอมรับว่าเทคโนโลยีขั้นสูงเป็นความเชื่อ เราเลือกเทคโนโลยีที่เหมาะกับเราที่สุดในขณะนี้ เมื่อเวลาผ่านไป ดูเหมือนว่าเราจะต้องนำบางโมดูลกลับมาใช้ใหม่ นี่คือการประนีประนอมที่เรายอมรับ

หลักการที่ 2: ปัญญาเสริม

ฉันพนันได้เลยว่าคนส่วนใหญ่ที่ไม่ได้เกี่ยวข้องอย่างลึกซึ้งในการพัฒนาโซลูชันแมชชีนเลิร์นนิงอาจคิดว่าเป้าหมายคือการแทนที่มนุษย์ ในความเป็นจริง โซลูชันการเรียนรู้ด้วยเครื่องยังห่างไกลจากความสมบูรณ์แบบ และมีเพียงบางพื้นที่เท่านั้นที่สามารถทดแทนได้ เราละทิ้งแนวคิดนี้ตั้งแต่เริ่มต้นด้วยเหตุผลหลายประการ: ข้อมูลที่ไม่สมดุลเกี่ยวกับกิจกรรมการฉ้อโกงและการไม่สามารถให้รายการคุณสมบัติที่ครบถ้วนสมบูรณ์สำหรับโมเดลแมชชีนเลิร์นนิง ในทางตรงกันข้าม เราเลือกตัวเลือกปัญญาเสริม นี่คือแนวคิดทางเลือกของปัญญาประดิษฐ์ที่มุ่งเน้นไปที่บทบาทสนับสนุนของ AI โดยเน้นความจริงที่ว่าเทคโนโลยีการรับรู้ได้รับการออกแบบมาเพื่อเพิ่มพูนปัญญาของมนุษย์ ไม่ใช่แทนที่ [1]

ด้วยเหตุนี้ การพัฒนาโซลูชันแมชชีนเลิร์นนิงที่สมบูรณ์ตั้งแต่เริ่มต้นจึงต้องใช้ความพยายามอย่างมาก ซึ่งจะทำให้การสร้างมูลค่าให้กับธุรกิจของเราล่าช้าออกไป เราตัดสินใจสร้างระบบที่มีแง่มุมของแมชชีนเลิร์นนิงที่เติบโตขึ้นอย่างต่อเนื่องภายใต้การแนะนำของผู้เชี่ยวชาญด้านโดเมนของเรา ส่วนที่ยุ่งยากในการพัฒนาระบบดังกล่าวคือต้องจัดเตรียมกรณีศึกษาให้กับนักวิเคราะห์ของเรา ไม่เพียงแต่ในแง่ที่ว่านี่เป็นกิจกรรมที่เป็นการฉ้อโกงหรือไม่เท่านั้น โดยทั่วไป ความผิดปกติใดๆ ในพฤติกรรมของลูกค้าเป็นกรณีที่น่าสงสัยซึ่งผู้เชี่ยวชาญจำเป็นต้องตรวจสอบและตอบสนองในทางใดทางหนึ่ง มีเพียงไม่กี่กรณีที่บันทึกไว้เท่านั้นที่สามารถจำแนกได้ว่าเป็นการฉ้อโกง

หลักการที่ 3: แพลตฟอร์มการวิเคราะห์ที่สมบูรณ์

ส่วนที่ยากที่สุดในระบบของเราคือการตรวจสอบเวิร์กโฟลว์ของระบบตั้งแต่ต้นทางถึงปลายทาง นักวิเคราะห์และนักพัฒนาควรได้รับชุดข้อมูลย้อนหลังพร้อมเมตริกทั้งหมดที่ใช้สำหรับการวิเคราะห์ได้อย่างง่ายดาย นอกจากนี้ แพลตฟอร์มข้อมูลควรมีวิธีง่ายๆ ในการเสริมชุดตัวบ่งชี้ที่มีอยู่ด้วยชุดใหม่ กระบวนการที่เราสร้างขึ้น ซึ่งไม่ใช่แค่กระบวนการซอฟต์แวร์ ควรทำให้ง่ายต่อการคำนวณงวดก่อนหน้า เพิ่มเมตริกใหม่ และเปลี่ยนแปลงการคาดการณ์ข้อมูล เราสามารถบรรลุเป้าหมายนี้ได้โดยรวบรวมข้อมูลทั้งหมดที่ระบบการผลิตของเราสร้างขึ้น ในกรณีเช่นนี้ ข้อมูลจะค่อยๆ กลายเป็นอุปสรรค เราจำเป็นต้องจัดเก็บข้อมูลจำนวนมากขึ้นเรื่อยๆ ที่เราไม่ได้ใช้และปกป้องมัน ในสถานการณ์ดังกล่าว ข้อมูลจะไม่เกี่ยวข้องมากขึ้นเรื่อยๆ เมื่อเวลาผ่านไป แต่ก็ยังต้องใช้ความพยายามของเราในการจัดการ สำหรับเรา การกักตุนข้อมูลไม่สมเหตุสมผล และเราตัดสินใจใช้วิธีอื่น เราตัดสินใจจัดระเบียบคลังข้อมูลแบบเรียลไทม์รอบๆ เอนทิตีเป้าหมายที่เราต้องการจัดประเภท และจัดเก็บเฉพาะข้อมูลที่ช่วยให้เราตรวจสอบช่วงเวลาล่าสุดและล่าสุดได้ ความท้าทายของความพยายามนี้คือระบบของเรามีที่เก็บข้อมูลและโมดูลซอฟต์แวร์ที่แตกต่างกัน ซึ่งต้องมีการวางแผนอย่างรอบคอบเพื่อให้ทำงานในลักษณะที่สอดคล้องกัน

แนวคิดการออกแบบระบบของเรา

เรามีสี่องค์ประกอบหลักในระบบของเรา: ระบบการส่งผ่านข้อมูล ระบบคำนวณ การวิเคราะห์ BI และระบบการติดตาม พวกเขาให้บริการตามวัตถุประสงค์ที่แยกเฉพาะ และเราแยกพวกเขาโดยทำตามแนวทางการพัฒนาบางอย่าง

การออกแบบตามสัญญา

ก่อนอื่น เราตกลงกันว่าส่วนประกอบต่างๆ ควรอาศัยโครงสร้างข้อมูล (สัญญา) บางอย่างที่ส่งผ่านระหว่างกันเท่านั้น ทำให้ง่ายต่อการรวมเข้าด้วยกันและไม่กำหนดองค์ประกอบเฉพาะ (และลำดับ) ของส่วนประกอบ ตัวอย่างเช่น ในบางกรณี สิ่งนี้ช่วยให้เราสามารถรวมระบบรับเข้ากับระบบติดตามการแจ้งเตือนได้โดยตรง ในกรณีเช่นนี้จะดำเนินการตามสัญญาแจ้งที่ตกลงไว้ ซึ่งหมายความว่าส่วนประกอบทั้งสองจะถูกรวมเข้าด้วยกันโดยใช้สัญญาที่ส่วนประกอบอื่นๆ สามารถใช้ได้ เราจะไม่เพิ่มสัญญาเพิ่มเติมเพื่อเพิ่มการแจ้งเตือนไปยังระบบติดตามจากระบบอินพุต วิธีการนี้ต้องใช้จำนวนสัญญาขั้นต่ำที่กำหนดไว้ล่วงหน้า และทำให้ระบบและการสื่อสารง่ายขึ้น โดยพื้นฐานแล้ว เรากำลังใช้แนวทางที่เรียกว่า "การออกแบบสัญญาก่อน" และนำไปใช้กับสัญญาการสตรีม [2]

สตรีมมิ่งทุกที่

การบันทึกและการจัดการสถานะในระบบย่อมจะนำไปสู่ความยุ่งยากในการใช้งาน โดยทั่วไป สถานะต้องสามารถเข้าถึงได้จากคอมโพเนนต์ใดๆ ต้องสอดคล้องกันและให้ค่าล่าสุดในทุกคอมโพเนนต์ และต้องเชื่อถือได้ด้วยค่าที่ถูกต้อง นอกจากนี้ การเรียกใช้ที่เก็บข้อมูลถาวรเพื่อรับสถานะล่าสุดจะเพิ่มปริมาณของ I/O และความซับซ้อนของอัลกอริทึมที่ใช้ในไปป์ไลน์แบบเรียลไทม์ของเรา ด้วยเหตุนี้ เราจึงตัดสินใจลบที่เก็บข้อมูลสถานะออกจากระบบของเราทั้งหมด หากเป็นไปได้ วิธีการนี้กำหนดให้รวมข้อมูลที่จำเป็นทั้งหมดไว้ในหน่วยข้อมูลที่ส่ง (ข้อความ) ตัวอย่างเช่น หากเราจำเป็นต้องคำนวณจำนวนรวมของการสังเกตบางอย่าง (จำนวนการดำเนินการหรือกรณีที่มีลักษณะเฉพาะบางอย่าง) เราจะคำนวณในหน่วยความจำและสร้างสตรีมของค่าดังกล่าว โมดูลที่พึ่งพาจะใช้การแบ่งพาร์ติชันและการแบทช์เพื่อแบ่งสตรีมตามเอนทิตีและดำเนินการกับค่าล่าสุด วิธีการนี้ขจัดความจำเป็นในการจัดเก็บข้อมูลบนดิสก์แบบถาวรสำหรับข้อมูลดังกล่าว ระบบของเราใช้ Kafka เป็นนายหน้าข้อความและสามารถใช้เป็นฐานข้อมูลด้วย KSQL [3] แต่การใช้มันจะเชื่อมโยงวิธีแก้ปัญหาของเรากับคาฟคาอย่างมาก และเราตัดสินใจที่จะไม่ใช้มัน แนวทางที่เราเลือกช่วยให้เราสามารถแทนที่ Kafka ด้วยตัวกลางข้อความอื่นโดยไม่ต้องทำการเปลี่ยนแปลงระบบภายในที่สำคัญ

แนวคิดนี้ไม่ได้หมายความว่าเราไม่ได้ใช้ที่เก็บข้อมูลดิสก์และฐานข้อมูล ในการทดสอบและวิเคราะห์ประสิทธิภาพของระบบ เราจำเป็นต้องจัดเก็บข้อมูลจำนวนมากไว้บนดิสก์ ซึ่งแสดงถึงตัวบ่งชี้และสถานะต่างๆ จุดสำคัญที่นี่คืออัลกอริทึมตามเวลาจริงไม่ได้ขึ้นอยู่กับข้อมูลดังกล่าว ในกรณีส่วนใหญ่ เราใช้ข้อมูลที่บันทึกไว้สำหรับการวิเคราะห์แบบออฟไลน์ การดีบัก และการติดตามกรณีและผลลัพธ์เฉพาะที่ระบบสร้างขึ้น

ปัญหาในระบบของเรา

มีปัญหาบางอย่างที่เราแก้ไขได้ในระดับหนึ่ง แต่พวกเขาต้องการวิธีแก้ปัญหาที่รอบคอบมากขึ้น สำหรับตอนนี้ ฉันอยากจะพูดถึงที่นี่เพราะแต่ละรายการมีค่าในบทความของตัวเอง

• เรายังจำเป็นต้องกำหนดกระบวนการและนโยบายที่ช่วยสร้างข้อมูลที่มีความหมายและเกี่ยวข้องสำหรับการวิเคราะห์ การค้นพบ และการสำรวจข้อมูลโดยอัตโนมัติ
• การแนะนำผลการวิเคราะห์โดยบุคคลในกระบวนการปรับแต่งระบบโดยอัตโนมัติเพื่ออัปเดตด้วยข้อมูลล่าสุด นี่ไม่ใช่แค่การอัปเดตโมเดลของเราเท่านั้น แต่ยังเป็นการอัปเดตกระบวนการของเราและความเข้าใจที่ดีขึ้นเกี่ยวกับข้อมูลของเราด้วย
• การหาสมดุลระหว่างวิธีเชิงกำหนดของ IF-ELSE และ ML มีคนพูดว่า: "ML เป็นเครื่องมือสำหรับคนสิ้นหวัง" ซึ่งหมายความว่าคุณจะต้องการใช้ ML เมื่อคุณไม่เข้าใจวิธีการเพิ่มประสิทธิภาพและปรับปรุงอัลกอริทึมของคุณอีกต่อไป ในทางกลับกัน วิธีการเชิงกำหนดจะไม่อนุญาตให้ตรวจพบความผิดปกติที่ไม่ได้คาดการณ์ล่วงหน้า
• เราต้องการวิธีง่ายๆ ในการทดสอบสมมติฐานหรือความสัมพันธ์ระหว่างเมตริกในข้อมูล
• ระบบต้องมีผลบวกจริงหลายระดับ กรณีการฉ้อโกงเป็นเพียงเศษเสี้ยวของทุกกรณีที่สามารถพิจารณาได้ว่าเป็นผลดีต่อระบบ ตัวอย่างเช่น นักวิเคราะห์ต้องการรับกรณีที่น่าสงสัยทั้งหมดเพื่อการตรวจสอบ และมีเพียงส่วนน้อยเท่านั้นที่เป็นกรณีฉ้อฉล ระบบต้องให้บริการแก่นักวิเคราะห์อย่างมีประสิทธิภาพในทุกกรณี ไม่ว่าจะเป็นการฉ้อโกงจริงหรือพฤติกรรมที่น่าสงสัย
• แพลตฟอร์มข้อมูลควรสามารถดึงชุดข้อมูลในอดีตด้วยการคำนวณที่สร้างขึ้นและคำนวณได้ทันที
• การปรับใช้ส่วนประกอบใดๆ ของระบบอย่างง่ายและอัตโนมัติในสภาพแวดล้อมที่แตกต่างกันอย่างน้อยสามแบบ: การใช้งานจริง การทดลอง (เบต้า) และสำหรับนักพัฒนา
• และสุดท้าย แต่ไม่ท้ายสุด เราจำเป็นต้องสร้างแพลตฟอร์มการเปรียบเทียบที่ครอบคลุมซึ่งเราสามารถวิเคราะห์โมเดลของเราได้ [4]

การอ้างอิง

1. ปัญญาเสริมคืออะไร?
2. ใช้วิธีการออกแบบ API-First
3. Kafka เปลี่ยนเป็น "ฐานข้อมูลการสตรีมเหตุการณ์"
4. ทำความเข้าใจ AUC—ROC Curve

ที่มา: will.com