Fraud Detection : EP 1 Feature Engineer สิ่งที่คนเห็นกับ Model เห็น

Feature Engineer เป็นขั้นตอนที่สำคัญและหลายๆครั้งมีผลกับผลลัพธ์มากกว่า model tuning

หลังจากที่เรา EDA ดูข้อมูลดิบคร่าวๆแล้ว ขั้นตอนต่อไปก่อนที่จะ train model ก็คือการจัดข้อมูลให้อยู่ในรูปแบบที่โมเดลรองรับ (Data Preprocessing) และ Feature Engineering นั่นเอง

เนื่องจาก Data Preprocessing นั้นส่วนใหญ่ทุกท่านน่าจะทำเป็นกันอยู่แล้ว ผมจึงขอมาอธิบายในเรื่องของ Feature Engineering เป็นหลักนะครับ

หลักการสำคัญในการทำ Feature Engineering คือการตั้งสมมุติฐานจากตัว Data ว่าทำให้ยังให้ Model เห็นในสิ่งที่เราเห็นเช่น ยอดเงินที่มากผิดปกติ การใช้งานที่ถี่เกินไป แต่คำว่า ‘ผิดปกติ’ เนี่ยล่ะเราจะแสดงให้ Model เห็นยังไงแล้วเราจะนิยามยังไงเป็นสิ่งที่ต้องมาคิดกัน

แต่ก่อนที่จะเริ่มทำการ Feature Engineer ผมขอเกริ่นให้เห็นภาพก่อนว่าสิ่งที่ Model เห็นนั้นต่างจากคนเรายังไง

ตัวอย่างการแบ่งของ Decision Tree http://statweb.stanford.edu/~jtaylo/courses/stats202/trees.html

จากรูปข้างบนถ้าเราทำ Model ที่มีแค่ 2 Features และมี 3 Target ตามสีจะเห็นว่า Model เราจะทำการตีเส้นตรง ๆ แบ่งเขตอย่างชัดเจนซึ่งเกิดการ Decision Tree ที่มีรูปร่างแบบนี้

http://statweb.stanford.edu/~jtaylo/courses/stats202/trees.html

ซึ่งในการทำงานของ Tree จะมีจุดน่าสนใจอยู่สองอย่างคือ

1. สามารถรับมือกับ Non-linear ได้ซึ่ง Data ในชีวิตจริงของเราส่วนใหญ่จะเป็นแบบนี้
2. สามารถรับมือกับ Outlier ได้ดี เพราะหลักการของ Tree จะไม่ได้ใช้ค่าของ Feature โดยตรง ถ้าเราสังเกตดี ๆ จุดแบ่งต่าง ๆ นั้นเกิดขึ้นจากลำดับของข้อมูลทั้งสิ้น โดยจุดแบ่งจะเกิดจากเอาค่าทั้งสองมาหารกัน ซึ่ง Outlier ก็มักจะเป็นค่าที่ไม่ต่ำสุดก็สูงสุดอยู่แล้วเลยสามารถรับมือได้ดี แต่ต้องระวังไว้ในกรณีที่หน้าตา Test กับ Train ไม่เหมือนกัน การ Remove Outlier และ Normalize จะช่วยให้ Model ทำงานดีขึ้น

จากข้อที่ 2 ทำให้เราพอจะเห็นภาพได้ว่าถ้าเราทำการ Feature Engineer ใด ๆ ที่ไม่ได้ทำให้ลำดับของข้อมูลเปลี่ยนเช่น การใส่ Log กับ Feature , บวก ลบ คูณ หาร ค่าคงที่เข้าไปใน Feature รวมไปถึงการ Normalize จะไม่ได้ช่วยให้ Model ประเภท Tree ทำงานได้ดีขึ้นเลย

พอเราเข้าใจแบบนี้ก็จะเริ่มมีกรอบคร่าวๆว่า การทำ Feature Engineer ต้องทำให้ลำดับเปลี่ยนซึ่งก็อาจจะทำได้จาก การนำ 2 Feature มาใช้ร่วมกัน เช่น บวก ลบ คูณ หาร เป็นต้น หรือการสร้างความสัมพันธ์ระหว่างแถว เช่น การทำ Rolling Mean,การหาความต่างระหว่างแถวเป็นต้น หรือ การการทำ Frequency encoding (นับว่าข้อมูลนี้ปรากฏบ่อยแค่ไหนสำหรับการ์ดใบนี้) ก็ช่วย Model ได้

ตัวอย่างการทำ Frequency encoding ของ Card 1 กับ TransactionAmt เช่น ยอด 49.0 ของ card 2755 เกิดขึ้น 2 ครั้ง

ที่นี้เราจะแสดงความ ‘ผิดปกติ’ ยังไงดีก็ง่าย ๆ ตรงไปตรงมา เช่น ถ้าเราพบว่า ยอดเงินนั้นจะมากผิดปกติเมื่อเทียบกับประเภทสินค้าเดียวกันเราก็แค่ใช้ค่า Mean ของสินค้าประเภทนั้น ๆ มาเทียบกับยอดโอนเงินก็จะรู้แล้วว่าผิดปกติ หรือ การทำ Frequency encoding ก็จะรู้ได้แล้วว่ายอดโอนเงินนี้แปลก ๆ หรือไม่ เกิดขึ้นบ่อยรึเปล่า และถ้าเราทำ Frequency encoding เทียบกับเวลาก็จะรู้อีกว่ายอดการใช้งานในวันนี้มากผิดปกติรึเปล่า เป็นต้น

ซึ่งในการแข่งนี้หลัก ๆ Frequency encoding ก็พอช่วยให้ Model ทำงานได้ดีขึ้นมากแล้ว ซึ่งสามารถศึกษาได้จากลิงค์ด้านล่าง

https://www.kaggle.com/c/ieee-fraud-detection/discussion/108575#latest-648185

แต่ถ้าจำกันได้ผู้จัดการแข่งขันไม่ได้ให้ข้อมูล User id มาตรงๆทำให้เราต้องเทียบกันตามประเภทบัตร ธนาคารที่ออกบัตร ที่อยู่ของ User มาทำ Frequency encoding แทนซึ่งผมติดอยู่กับขั้นตอนนี้นานมากแต่ก็ไม่สามารถทำให้ Model ทำงานได้ดีขึ้นจนกระทั่งผมพบวิธีที่จะทำให้เรา User id มาจากการนั่งทำความเข้าใจตัว Data โดยวิธีก็แค่นำประเภท Card มารวมกันและใส่วันที่เปิดบัตรเข้าไปก็สามารถได้ User id มา ผลคือ Model ทำงานได้ดีขึ้นอย่างมากเมื่อใช้ Frequency encoding บน User id แทน (รู้ว่าคนนี้จริง ๆ ใช้งานไปเท่าไหร่) ซึ่งการที่มี User id เนี่ยล่ะคือจุดที่จะแยกว่าใครจะติดอันดับต้น ๆ ในการแข่งนี้

User Id ในที่นี้หมายถึงข้อมูลที่บอกว่า Transaction นี้เกิดจากบัตรไหนนั่นเอง

ตัวอย่าง code ในการหา user id

IEEE - uid detection - v6

Fraud Detection: EP 2 เทคนิคการทำ Feature Selection