[Kalapa Credit Challenge] #79 (top 5 đồng đội)

machine-learning
kalapa

#1

Mở bài: Đầu tiên cám ơn BTC Kalapa, cũng như AIviVN đã tổ chức 1 cuộc thi hữu ích cho các ae làm về data có cơ hội được trải nghiêm cũng như chia sẻ những kiến thức và kinh nghiệm khi làm predictive modeling. Team mình tham gia cũng với tinh thần như trên, vui là chính, có giải thưởng càng tốt, nhưng đến thời điểm hiện tại thì cũng chưa “xơi múi” đc ít tiền mặt nào từ BTC cả :smile: Hiện tại team 3 người khả năng sẽ phải cắt áo phông làm 3 mảnh chia nhau, ko biết ae BTC có thừa áo ko thì linh động phát thêm, cho ae trong team đỡ “xứt mẻ” tình cảm :smile:

Thân bài: Phần này các ae sẽ quan tâm nhiều hơn. Mình sẽ chia sẻ với ae cách team mình tiếp cận, tìm hiểu & giải quyết bài toán của Kalapa.

Đầu tiên mình có 1 số gạch đầu dòng về data như sau:

  • “Đơn giản” vì tập dữ liệu nhỏ: ít dòng, ít cột.
  • “Khoai”! Vì: o Hầu hết các biến đều ko hiểu ý nghĩa -> cái này dẫn đến việc xử lý data & feature engineering hoàn toàn sẽ dựa vào phán đoán & may mắn, ko dùng được business knowledge ở đây. o Encoding nhiều -> ae ko biết đằng nào mà lần & mò :smile:
  • Imbalanced data: % minority class là 1.6% -> theo mình đây chưa phải vấn đề, vì với những thuật toán cao cấp thuộc dòng “tree-based” hoàn toàn vẫn có thể dự báo không tồi đối với tỷ lệ trên. Trong những bài toán thực tế mà team mình đã làm, % minority class còn nhỏ hơn rất nhiều, những dùng những thuật toán “tree-based” vẫn OK. Đối với vấn đề này, cũng chia sẻ để có thể ae nào mà chưa biết thì có thể kham khảo. Về cơ bản có 3 cách để xử lý imbalanced data:
  1. Tăng số quan sát thuộc minority class lên đến 1 mức % nào đó mà ae cảm thấy chất lượng dự báo ok nhất.
  2. Giảm số quan sát thuộc majority class xuống.
  3. Kết hợp cả 2 cách trên: Tăng số quan sát thuộc minority class & giảm số quan sát thuộc majority class.
  • Training data “hơi ít” 30K quan sát, trong khi test là 20K

Cách team mình làm – Ae tham thảo chi tiết ở phần source code nhé. https://www.kaggle.com/truongnh3/kalapa-credit-scoring-challenge-code

Còn phần chia sẻ mình nói 1 số ý chính quan trọng thôi.

  • Tập trung vào clean data + feature engineering – Theo mình đây là key có thể áp dụng với mọi competition, vì thuật toán cũng chỉ 1 phần thôi, khi mà ae thông thường cũng chỉ quanh đi quẩn lại dùng những thuật toán của “tree-based”: RF, GBM, XGB,LGB, thì tuning hết cỡ thì chắc lên đc tí xíu performance, vậy nên ăn nhau sẽ ở chỗ ông nào xử lý data được “clean” nhất và tạo được những biến mới hay ho nhất, nhưng ở đây như trên mình có đề cập – hầu hết các biến đều ko biết ý nghĩa, nên làm mò là chính. Đây đúng là cuộc thi “Machine” Learning theo đúng nghĩa đen, ko dùng đc yếu tố human :smile: Chỉ có tay cho cho máy chạy. Team mình chia các biến sẽ xử lý làm 3 nhóm: o Numeric: Phần lớn giữ nguyên, có xử lý kỹ biến tuổi (kết hợp từ 2 biến tuổi mà BTC cung cấp, sau đó những giá trị NA hoặc < 18 hoặc > 65 thay bằng median). Đây là biến mà chúng ta có thể sử dụng business knowledge ở đây. Vì theo như các TCTD độ tuổi được vay thường khoảng từ 18 đến 65 tuổi. Feature thêm 1 số biến như: field11/field51, field21/field16, average(field54,55,57) – làm bừa thôi, vì có biết mấy biến này là biến gì đâu :smile:

o Tạm gọi là các biến “Indicator”: những biến mà mang giá trị 0-1 hoặc TRUE/FALSE (mình convert về dạng 0-1). Có feature thêm 1 biến mới tính tổng các biến này theo dòng, vì mình tạm đoán các biến này được hiểu là KH có nắm giữ hoặc dùng cái gì đó (có thể là sản phẩm – yes/no) nên mình feature thêm 1 biến tạm gọi là tổng các thứ (sản phẩm) mà KH nắm giữ hoặc dùng.

o Categical: Nhóm biến này team mình cố gắng sao cho các giá trị của các biến này ở cả tập train và test sao cho đồng nhất. Vì thế những giá trị của các biến mà bad rate = 0% mình gom thành 1 giá trị là “others’. Ngoài ra có xử lý field_7: Loại bỏ hết các giá trị bị lặp lại trong mỗi dòng, ví dụ: dn,dn,gd thì sẽ thành dn,gd. Và có feature thêm biến mới tính tổng các giá trị có trong mỗi dòng, ví dụ như trường hợp trên là 2.

  • Team mình cũng có tham khảo bài chia sẻ trước (https://rpubs.com/chidungkt): Có dùng WOE transform, sau đó lựa chọn những biến mà IV > 0.04 (cái này team mình thử thấy ok nhất nên chọn mốc IV này, còn thông thường theo lý thuyết thì từ 0.02 có thể lấy rồi)

  • Thuật toán thì team mình dùng RF, cũng có thử GBM, XGB, nhưng thấy public score thấp quá nên ko dám dùng, nên quay lại dùng RF -> Mình cho đây là bước đi “chưa đúng”, do ae cũng hơi bị cuốn vào public LB =)) thấy gini top đầu toàn 0.3-0.4 nên cũng thấy “tức tiếng gáy” :smile: . Sau đó team mình có sử dụng việc combine các kết quả có public score cao, sử dụng min hoặc average để làm tăng điểm public score lên.

Kết bài: Public LB của team mình (Unknown-T) là 0.31, còn Private LB 0.24 => overfit! :smile: . Đương nhiên là ko nặng như mấy ông thần top 5 public LB, mình xem private score mà giật hết cả mình, ko thấy tung tích của các đội top public score luôn… Kinh nghiệm mình rút ra cho những competition kiểu này là:

  • Ko nên đua Public score, mặc dù nếu điểm của mình có 0.25 mà nhìn mấy thằng top toàn 0.35-0.4 thì cũng ngứa mắt thật, nên dễ bị cuốn theo.
  • Khi submit kết quả cuối cùng nên “rải” các submission có public score khác nhau (ở đây là gini), chứ ko chỉ submit những kết quả cao nhất để tránh overfitting.

Chúc các ae cuối tuần vui vẻ!