Vấn đề của feature importance mặc định (impurity-based, feature_importances_):
- Thiên vị feature có nhiều giá trị (high cardinality). Cột customer_id hay cột liên tục có nhiều điểm cắt sẽ được điểm cao chỉ vì cây có nhiều cơ hội tách theo nó — kể cả khi nó không có sức dự đoán thật.
- Tính trên dữ liệu train nên phản ánh cả phần mô hình đã overfit, không phải khả năng khái quát.
- Feature tương quan chia nhau tầm quan trọng, khiến cả hai trông đều yếu.
Thay bằng:
- Permutation importance trên tập validation/test: xáo trộn ngẫu nhiên một cột rồi đo mức tụt của metric. Đo đúng thứ mô hình thực sự dựa vào để khái quát. Vẫn cần lưu ý: với hai feature tương quan mạnh, xáo một cột thì cột kia bù vào nên cả hai đều ra "không quan trọng" — nên gộp nhóm tương quan lại khi diễn giải.
- SHAP khi cần giải thích từng dự đoán ("hồ sơ này bị từ chối chủ yếu vì thu nhập thấp và lịch sử trả chậm"), có tính cộng tính nên tổng đóng góp cộng lại đúng bằng chênh lệch so với giá trị nền.
- Partial dependence / ICE để trả lời "feature này tăng thì dự đoán đổi theo hướng nào".
Trình bày cho người không kỹ thuật:
- Nói bằng kết quả nghiệp vụ, không nói bằng metric: "trong 100 hồ sơ mô hình gắn cờ, khoảng 32 là rủi ro thật, so với 12 của quy trình hiện tại".
- Đưa vài ca cụ thể kèm giải thích SHAP thay vì biểu đồ tổng hợp — người nghiệp vụ đối chiếu được với kinh nghiệm của họ.
- Nói rõ mô hình chỉ cho tương quan, không phải nhân quả. "Feature quan trọng" không có nghĩa là "can thiệp vào feature đó sẽ đổi kết quả".
- Nêu giới hạn: mô hình học từ dữ liệu khoảng thời gian nào, kém tin cậy với nhóm nào (mẫu ít).