Огляд
*Коли востаннє ви позичали гроші другові, але вони вам ніколи не повернули, тож ви вирішили просто віддати їм гроші?*
З іншого боку, банки не можуть просто позичити гроші й забути про це. Звідки банки знають, чи повернуть готівку, яку вони видають клієнтам? Насправді вони не знають, але можуть спробувати передбачити результат на основі минулих особливостей поведінки клієнта. Але на які функції вони повинні зосередитися?
У цьому проекті аналізується вищезазначена проблема, зосереджуючись на якій моделі та функціях слід віддати пріоритет, щоб передбачити, чи клієнт кредитної картки не виконає зобов’язань (не погасить) чи ні. Цей підхід використовує *розробку функцій*, яка передбачає обробку та перетворення вихідних даних у 12 відповідних функцій. Потім ці функції використовуються в різних моделях для визначення найбільш надійного методу для банкірів.
Проект робить висновок, що математичний метод `SHAP` є ефективною моделлю для визначення відповідних характеристик у вибраному наборі даних. Хоча модель перевершує інші методи, вона не ідеальна. Таким чином, подальше проектування може допомогти уникнути узагальнення характеристик. Зрештою, цей висновок є хорошою основою для банкірів, щоб побудувати модель, яка могла б передбачити, чи не буде клієнта дефолт, і зменшити потенційні фінансові ризики.
Фон проекту
Вибраний набір даних для цього проекту називається Набір даних клієнтів кредитних карток за замовчуванням (DCC), імпортований з Kaggle.
Підсумок набору даних
"Цей набір даних містить інформацію про платежі за замовчуванням, демографічні фактори, кредитні дані, історію платежів і виписки з рахунків клієнтів кредитних карток у Тайвані з квітня 2005 року по вересень 2005 року."
Початкова думка
Надані функції є демографічними показниками та моделями платежів користувачів кредитних карток, а отже, мають відношення до мети цього проекту. Однак, наскільки достовірним буде прогноз, залежить від моделі та функцій, які використовуються.
Підходи до проекту
Робота з відсутніми даними
Уявіть собі, як розчарувалися б банкіри, якби час для обіду відсутній у їхньому робочому графіку. Подібним чином ми, як правило, також не хочемо, щоб у нашому наборі даних були відсутні дані. На щастя, набір даних DCC не містить пропущених значень.
Попередня обробка даних
Тепер уявіть, як розчарувалися б банкіри, якби кур'єр навмання роздав їм обід. Деякі можуть бути вегетаріанцями, тоді як інші, ймовірно, мають інші дієтичні обмеження. Це також стосується нашого набору даних, який складається з різних типів даних. Щоб розробити функції, ми хочемо згрупувати їх у відповідні типи, наприклад «числові», «двійкові» та «категорійні».
Базова модель
Щоб визначити, наскільки надійними є прогнози, ми обчислюємо прогнозний бал на основі середніх загальних характеристик. Ми сподіваємося використовувати моделі з балами, вищими за 0,777.
Реалізація
Щоб визначити найефективнішу модель, ми запускаємо набір даних через різні моделі, щоб обчислити та порівняти важливість кожної функції. Ці моделі включають:
- Логістична регресія: часто використовується для двійкових значень. Ми використовуємо його тут, оскільки відповідь на те, чи будуть клієнти за замовчуванням чи ні, є «так» чи «ні». Ми також використовуємо цю модель для визначення ймовірності результату, а потім повторюємо процес кілька разів, щоб зафіксувати середнє значення та стандартне відхилення цієї ймовірності для всіх клієнтів.
- На малюнку 1 показано, що прогнозована точність для цієї моделі становить 0,777. Тому, можливо, перевірка набору даних через більш складні моделі може покращити оцінку.
2. Інші моделі. Деякі інші складні моделі, які можна використовувати, це `RandomForestClassifier`, `Gradient Boost` і `LightGBM`. `Рисунок 1.` - це підсумок усіх балів для кожної моделі.
- Оцінка навчання показує, наскільки добре модель відповідає набору даних, який було навчено моделлю. Водночас оцінка перевірки оцінює надійність прогнозів.
Серед усіх LightGBM має найвищий бал, але він може бути трохи *переобладнаним*. Це визначається на основі того, наскільки близько або далеко один від одного знаходяться потяг і результати перевірки.
*Наприклад, якщо банкіри очікували обіду опівдні, а їжу доставили в точний час, вони не можуть припустити, що вона завжди прибуде в точний момент для наступного замовлення. Ми називаємо цю надто оптимістичну ситуацію «недостатнім». Тим часом, якщо їжу було доставлено набагато раніше або пізніше, ніж очікувалося, ми вважаємо це «переобладнанням»*
Інтерпретація даних
Після вибору моделі LightGBM ми визначаємо найбільш відповідні характеристики для прогнозу. Для цього ми використовуємо примусовий графік під назвою SHAP, щоб допомогти візуалізувати важливість функцій. `Рисунок 2.` показує, що червоні елементи відводять прогноз до 1 (за замовчуванням = так), а сині — від 1.
Підсумовуючи, можна сказати, що сума у виписках за рахунками (у серпні 2005 року) та суми в попередніх виписках, ймовірно, призведуть до високого прогнозу «так». Тим часом лімітний баланс і деякі суми рахунків призведуть до нижчого прогнозу.
Обмеження та недоліки
Пам'ятайте, що обрана модель не ідеальна. Характеристика 3 — це матриця, яка показує кількість правильних передбачень (6702 і 428) проти помилкових передбачень (350 і 1520). Велика кількість помилкових прогнозів свідчить про те, що нашу модель ще можна вдосконалити.
Хоча поточна модель стане хорошою основою, її можна вдосконалити, якщо дати час і ресурси, наприклад кращу машину для запуску коду. Комплексний метод розробки функцій може допомогти нам вивчити різні комбінації функцій. Наприклад, ми можемо розглянути `female_divorce`, а не `sex` і `marriage`. Такий підхід дозволить нам розподілити важливість функцій на основі їхніх характеристик, а не об’єднувати їх усі в одну й припускати, що вага однакова. Таким чином, допоможіть зменшити помилкові передбачення.
Остаточні висновки
Проект робить висновок, що метод `SHAP` і LightBGM є ефективними моделями для визначення відповідних характеристик для вибраного набору даних. Це свідчить про те, що сума в рахунках і попередніх виписках, імовірно, допоможе визначити, чи не буде клієнта.
Оскільки його було побудовано на відносно простій техніці розробки функцій, подальша обробка могла б допомогти класифікувати клієнтів на підтипи, як-от `married_female` або `university_male`. Зрештою, SHAP є моделлю, яку можна інтерпретувати, оскільки вона значно полегшує порівняння важливості кожної функції.
