Logistic Regression trong phân tích dữ liệu

Logistic regression là một trong những mô hình được dạy rất nhiều, dùng rất nhiều, đặc biệt các bài toán trong mảng tài chính vẫn ưa chuộng sử dụng. Tôi không liệt kê lại lý thuyết trong sách hay các công thức hàn lâm mà đơn giản là note lại các vấn đề liên quan tới các bài toán phân loại trong ngách tín dụng. Nó phổ biến nhưng để phỏng vấn thể hiện được hiểu biết rõ ràng về mô hình này cũng không đơn giản.

1.Logistic regression là gì và khi nào dùng nó

Ví dụ rất đơn giản về rủi ro tín dụng sử dụng hồi quy Logistic: ngân hàng có dữ liệu của 1.000 khách hàng đã vay, trong đó 800 người đã có kết quả rõ ràng: người trả được nợ, người thì nợ xấu. 

Câu hỏi của rất cụ thể: với một khách hàng mới, dựa trên thu nhập – tuổi – nghề nghiệp – lịch sử tín dụng, khả năng người này nợ xấu là bao nhiêu?

Mục tiêu của logistic regression giống mọi mô hình hồi quy: tìm mô hình tối ưu mô tả quan hệ giữa y và tập biến x, để dự báo hoặc phân loại trong tương lai. Điều quyết định ta nên chọn phương pháp hồi quy nào lại nằm ở bản chất của biến mục tiêu.

• Khi y là biến định lượng liên tục (doanh thu, nhiệt độ, giá trị khoản vay), ta dùng hồi quy tuyến tính và các biến thể của nó.

• Khi y là biến định tính / nhị phân (có – không, trả được nợ – không trả được, rời dịch vụ – ở lại), phương pháp chủ đạo, và thường là duy nhất, chính là logistic regression.

Điểm khác biệt mấu chốt so với hồi quy tuyến tính nằm ở đầu ra. 

• Hồi quy tuyến tính cho ra một con số. 

• Logistic regression cho ra một xác suất nằm trong khoảng (0; 1), và xác suất ấy mới là cơ sở để ta đi đến kết luận phân loại cuối cùng cho y. Gắn nhãn y = 1 cho sự kiện mình quan tâm (thường là kết quả "tích cực" hoặc đáng chú ý: khách hàng nợ xấu, khách hàng rời dịch vụ, khối u ác tính) và y = 0 cho phần còn lại. Cần nhớ rằng 0 và 1 ở đây không phải số thực, mà chỉ là mã đánh dấu.

2. Tỷ số Odds: key chính của việc chuyển đổi ra xác suất

Ví dụ p là xác suất vỡ nợ, chúng ta muốn xây dựng mô hình hồi quy dự đoán xác suất vỡ nợ của từng khách hàng. p phải bị "nhốt" trong đoạn [0; 1]

Nhưng dữ liệu gốc nó chỉ có nhãn 0-1 và có các biến nếu hồi quy dạng β₀ + β₁x.. để như hồi quy tuyến tính thì nó nhận giá trị từ −∞ đến +∞

Tưởng tượng như có 1 sợi dây đang thẳng tưng, ta ép nó vào trong 1 chiếc hộp nhỏ giới hạn (0; 1), sợi dây đó bị uốn cong thành hình chữ S để vừa cái hộp đấy :v 

Bản chất toàn bộ quá trình chuyển đổi từ p của hồi quy tuyến tính sang p của hồi quy logistic là nới dần thang đo của p ra cho đến khi nó khớp với thang vô hạn của phần hồi quy tuyến tính.

Ta cần một hàm "ép" mọi giá trị thực về khoảng (0; 1). Để nhìn thấy rõ hơn bước chuyển đổi từ dữ liệu gốc sang làm logistic thì qua 3 bước:

Bước 1: Từ xác suất p chuyển sang Odds

Odds thể hiện khả năng một sự kiện xảy ra, bằng tỷ lệ xác suất xảy ra chia cho xác suất không xảy ra:

Odds này cũng có thể hiểu là %Good/%Bad trong nhãn mô hình.

Xác suất p đang chạy từ −∞ đến +∞, khi chuyển đổi về Odds 1 cái sẽ chạy từ 0 đến +∞

Đã được 50% công việc, cần loại bỏ nốt cái chặn 0

Bước 2: Từ Odds chuyển sang Log-odds

Để loại bỏ nốt cái sàn 0, sẽ Logarit tỷ số Odds tạo ra hàm Logit : logit = ln(odds) 

• Khi odds < 1 (tức p < 0,5) → ln âm

• Khi odds = 1 (p = 0,5) → ln = 0

• Khi odds > 1 (p > 0,5) → ln dương

Giờ log-odds chạy từ −∞ đến +∞. Đúng bằng miền của phần tuyến tính. Đến đây có thể đặt phương trình

Đây chính là phần lõi của logistic regression — gọi là dạng logit. 

Nó giữ nguyên các đặc trưng yêu cầu  "tuyến tính" các biến đầu vào như hồi quy tuyến tính. Logistic không "phi tuyến" như nhiều người tưởng — nó chỉ tuyến tính trên một thang đo khác. 

Bước 3: Đảo ngược hàm Logit để lấy ra p

Mục đích cuối cùng vẫn là lấy ra xác suất vỡ nợ p , phương trình bên trên nó chỉ đang giữ nguyên lý tuyến tính các biến, trả ra 1 con số log-odds.

Để convert cái Log-odds trên sẽ phải sử dụng 1 bước chuyển đổi, sử dụng hàm gọi là hàm Sigmoid:

Đường cong chữ S xuất hiện một cách tự nhiên khi đảo ngược logit. Đây là lý do lúc đầu học về hồi quy Logistic sẽ thấy khá rối, tự nhiên gặp cái hàm Sigmoid trước, trong khi thật ra nó là điểm cuối của chuỗi, không phải điểm đầu.

Tóm lại phần hồi quy Logistic này sẽ có 2 vấn đề cần làm :

• Chiều diễn giải để code và ra phương trình (chiều xuôi): p → odds → logit. Dùng khi ta muốn hiểu và mô hình hóa — đưa xác suất lên thang vô hạn để gắn với phương trình tuyến tính.

• Chiều dự báo và báo cáo (chiều ngược): logit → odds → p (qua sigmoid). Dùng khi ta đã có phương trình và hệ số, muốn tính ra xác suất cho một khách hàng cụ thể.

1 điểm lưu ý quan trọng khi xây dựng mô hình chấm điểm XHTD đó là mô hình hồi quy Logistic sẽ không đưa biến gốc thô như trên vào mà biến đổi nó qua WoE (Weight of Evidence) thông qua các ngưỡng binning xử lý trước.

Đây là điểm key sự khác biệt khi làm mô hình Scorecard. "Dữ liệu gốc" được xử lý binning + WoE trước khi vào hồi quy Logistic, chứ không phải con số thô ban đầu. Cũng có thể hiểu đây là 1 bước feature engineering.

Việc xử lý này nó cũng sẽ có ưu và nhược điểm (viết tóm tắt ở đây đúng là nó hơi khó hình dung khi bạn chưa thực sự làm Scorecard bao giờ, tôi sẽ viết rõ hơn trong phần riêng khi mô tả các bước xử lý của CreditScore)

Ưu điểm:

• WoE chạy qua các bin giá trị nó giúp xử lý tốt các biến không phải tuyến tính. 

• Auto xử lý luôn missing và outlier

• Dễ dàng nhìn và giải thích kết quả khi tất cả các biến khác nhau đều được Scale về chung 1 thang đo

Nhược điểm:

• Việc phân chia, cắt ngưỡng và đánh giá WoE khá cảm tính theo kinh nghiệm chuyên gia chứ không tối ưu cụ thể theo máy móc.

• Khi các biến bị binning thành các khoảng nó làm giảm khả năng dự đoán của mô hình và gây mất mát nhiều thông tin.

• Khó khăn khi muốn sử dụng các biến định tính : tỉnh thành, ngành nghề,... mà sẽ phải chia nhỏ ra các mô hình khác nhau

Khi học Hồi quy Logistic hay các lại mô hình hồi quy khác thì trong các giáo trình hàn lâm sẽ bắt gặp rất nhiều loại kiểm định, tối ưu tham số kết quả.

Ví dụ trong phần Hồi quy Logistic này có nhiều lý thuyết về 1 số phần:

• Ước lượng hệ số: Maximum Likelihood Estimation (MLE)

• Các loại test: Wald test, Likelihood Ratio test, AIC, BIC,...

• Ước lượng khoảng tin cậy,...

Tuy nhiên trên thực tế đi làm lại không bao giờ sử dụng mà chủ yếu sử dụng trong nghiên cứu thống kê. Không phải vì nó sai mà là mục đích sử dụng và mẫu dữ liệu nó khác nhau. 

Các phần tối ưu và test trong sách thống kê nó xử lý trên 1 mẫu rất nhỏ và ít biến kèm nhiều giả định. Test chính là công cụ đo xem "kết quả này có đáng tin hay chỉ là tình cờ". Nghiên cứu khoa học họ tìm kiếm 1 định luật gì đó đúng đại diện cho toàn bộ tổng thể nên sẽ phải đoán nhiều, còn việc xây mô hình trong Data Science chủ yếu cần tính dự đoán ổn định và giải thích.

Mô hình tín dụng chạy trên hàng chục, hàng trăm nghìn khách hàng. Khi mẫu rất lớn, sự may rủi gần như mất, biến nào đo lên cũng có ý nghĩa thống kê hết (P-value < 0.05) 

Một vấn đề nữa không đề cập đó là trong các thư viện, việc fit.model() nó đã tích hợp sẵn việc tối ưu tìm ra hệ số β cho phương trình nên việc tự tính toán tay tối ưu về mặt toán không còn là quan trọng ưu tiên. Việc ưu tiên đó là chọn biến có ý nghĩa tốt cả về mặt thống kê và nghiệp vụ, còn việc tối ưu tìm ra tham số cho mô hình đã có máy và thư viện train.

Dù thời đại AI và Machine Learning bùng nổ với các thuật toán thời thượng như Neural Networks, Random Forest hay Gradient Boosting, mô hình Logistic Regression vẫn là ưu tiên số 1 và là tiêu chuẩn ngành trong các hệ thống đánh giá rủi ro tín dụng (Credit Scoring) của ngân hàng, cái này không phải ngẫu nhiên mà do chủ yếu nặng tính tuân thủ.

Ngân hàng là đơn vị được quyền huy động vốn từ xã hội, không hẳn là đơn vị kinh doanh vì lợi nhuận. Ngân hàng được yêu cầu cung cấp lý do từ chối cho vay với khách hàng và với đơn vị kiểm toán. Các tiêu chuẩn quốc tế như Basel quy định các mô hình xếp hạng nội bộ IRB yêu cầu rất rõ về tiêu chuẩn, tính tuân thủ, giải thích. Chỉ có mô hình hồi quy Logistic có thể lượng hóa sự tác động của từng đặc điểm khách hàng một cách rõ ràng – điều mà các mô hình ML, DL không thể làm tốt hơn được (chấp luôn mấy cái Shap, lime ,XAI)

Mô hình Logistic nó chỉ kém tính dự đoán hơn 1 chút và yêu cầu xử lý đầu vào chuẩn hơn các mô hình hiện đại chứ không phải thua kém quá xa, các bài toán phân loại quan trọng trong mảng tài chính sẵn sàng đánh đổi 1 chút tính dự đoán này để có khả năng phân biệt và thuyết phục rõ ràng.

Vấn đề nữa đó là Mô hình logistic rất nhẹ dễ dàng khi đã có phương trình cuối, cài đặt lên các hệ thống Core, LOS khởi tạo khoản vay cực kỳ dễ dàng dưới dạng rule base thẻ điểm, rất chủ động trong việc cài đặt điều chỉnh, không yêu cầu hệ thống mỗi lần call api qua các model phức tạp và không cần triển khai hạ tầng quá nhiều.