Метод опорних векторів: у пошуках ідеальної межі (SVM)

[0:00]Вітаю. Сьогодні маємо детальну інструкцію до лабораторної роботи з машинного навчання. Присвячена вона алгоритму Support Vector Machines, або ж методу опорних векторів. Наше завдання - розібрати цей алгоритм крок за кроком, для цього використаємо чотири класичні датасети для бінарної класифікації з платформи Kaggle. Це Heart Disease, Pima Indians Diabetes, Breast Cancer Wisconsin та Banknote Authentication. Ми пройдемося по кожному із семи пунктів інструкції. І для кожного кроку визначимо, що робимо, навіщо, як контролюємо результат, що може піти не так. І розберемо це на прикладі. Отже, перший етап - завантаження даних. Що ми робимо? Завантажуємо датасет і перевіряємо, чи підходить він для SVM взагалі. Тому що алгоритм вимагає виключно числових ознак. І бінарної цільової змінної, інакше він просто не спрацює. Як ми це контролюємо? Зазвичай викликаємо базові методи Shape, Info та Describe. Вони одразу показують усю структуру. А от що може піти не так? Тут якраз часто ховаються перші пастки, наприклад, незакодовані текстові категорії. Або ж шалений дисбаланс класів, коли співвідношення стає, ну, 80 на 20, чи навіть гірше. Стовідсотково. Тому гарним прикладом ідеального старту є датасет Heart Disease. Там співвідношення класів дуже зручне, десь 54 на 46. Переконавшись, що дані підходять, переходимо до другого етапу підготовки. Що робимо тут? Обов'язково застосовуємо масштабування. Використовуємо StandardScaler або MinMaxScaler. Зрозуміло, навіщо, адже SVM критично чутливий до масштабу ознак, бо шукає відстані між точками у просторі. Як ми контролюємо цей процес? Після перетворення перевіряємо, чи середнє значення стало близько нуля. А стандартне відхилення близько одиниці. Типова проблема тут виникає, коли залишається величезний розкид значень. Це просто діагноз: масштабування забули зробити. Для прикладу у Pima Diabetes у всі вісім ознак є числовими, тому там одразу застосовується Standard Scaler. Йдемо далі. Третій крок - розбиття даних. Що робимо? Ділимо їх на тренувальну та тестову вибірки через Train Test Split. З обов'язковою стратифікацією. Навіщо? Щоб коректно оцінити узагальнюючу здатність моделі. Контролюємо це так: пропорції класів у обох вибірках мають збігатися з похибкою не більше 2-3%. А що може піти не так? Якщо проігнорувати стратифікацію, тестова вибірка стає нерепрезентативною. І перевірка моделі втрачає будь-який сенс. Правильний підхід добровидно на датасеті Breast Cancer. Так, там алгоритм надійно зберігає десь 37% злоякісних випадків, як у тренувальному, так і в тестовому наборах. Четвертий крок - побудова базової моделі та візуалізація. Що робимо? Запускаємо класифікатор із радіально-базисним, тобто RBF ядром, і будуємо функцію рішення у двовимірному просторі. Щоб просто на власні очі побачити це просторове розділення, контролюємо через візуальну перевірку складності межі. І тут отримані результати можуть насторожити. Якщо видно хаотичну, дуже складну межу, скажімо, при параметрі C від 100 і вище, це перенавчання. Пряма вказівка на нього. А протилежний успішний приклад - це Banknote Authentication. Там на двох ознаках RBF ядро малює надзвичайно чітку і логічну межу. Переходимо до п'ятого кроку: прогноз та оцінка якості базової моделі. Що робимо? Викликаємо predict та accuracy score. Щоб зафіксувати початковий рівень якості до серйозних налаштувань. Як контролюємо? Перевіряємо загальну точність та чутливість. Проблема, яку тут часто видно - це, коли точність на тренуванні сягає 100%, а на тесті падає до 75%. Знову ж таки, перенавчання. Нормальний результат для базової моделі з RBF ядром, і C рівнем одиниці можна побачити на Heart Disease. Там на тесті стабільні 83-87%. Шостий крок - підбір оптимальних параметрів. Запускаємо GridSearchCV для перебору значень C, типу ядра та параметра гамма. Щоб знайти баланс між жорсткістю межі рішення та здатністю до узагальнення. Контролюємо, орієнтуючись на найкращий бал під час крос-валідації, і аналізуючи результати можна багато чого зрозуміти. Так, якщо оптимізатор зупиняється на дуже високому C, модель просто тупо запам'ятовує дані. Нормальний приклад на Pima Diabetes показує, що оптимально працює RBF ядро зі значенням C від 1 до 10 та гамма від 1 сотої до 1 десятої. Сьомий і фінальний крок - порівняння параметрів. Що робимо? Порівнюємо оптимальну та базову модель. Навіщо? Щоб чітко розуміти причини приросту якості. Оцінюємо зміну точності та перевіряємо зменшення розриву між тренуванням і тестом. І пояснення цих змін має бути логічним. Зменшення параметра C робить межу м'якою, що рятує від перенавчання. А якщо обчислення показують перевагу лінійного ядра, значить дані були простішими, ніж здавалося. Скажімо, у Breast Cancer завдяки правильним налаштуванням якість зростає з 91 до 97%. Підсумовуючи цей розбір, успішна робота алгоритму SVM - це не магія. Це результат чіткого дотримання інструкції. Тільки правильне масштабування, стратифікація та збалансоване налаштування гарантують надійну роботу. А наостанок, маємо думку для роздумів. Можна уявити ідеально підготовлений датасет. І раптом у ньому з'являється один потужний екстремальний викид. Наскільки сильно зміниться форма межі рішення алгоритму SVM? І чи взагалі можливо повністю нівелювати вплив цієї єдиної аномалії, просто змінюючи параметр C? Це залишається для самостійного аналізу.