Навчальний простір / Python
Основи штучного інтелекту

Validation, перенавчання та інженерія ознак

Узагальнення оцінюють процедурою, яка відповідає майбутньому використанню.

Зміст матеріалу

Що ви опануєте

Ви навчитеся організовувати cross-validation, розпізнавати перенавчання й створювати ознаки без витоку. Зможете пояснити, що саме оцінюють fold і чому фінальний test слід залишати незалежним. Завершимо оглядом кластеризації, ансамблів, нейронних мереж і відповідального використання результатів.

Узагальнення та перенавчання

Узагальнення — здатність моделі працювати на нових релевантних спостереженнях. Перенавчання виникає, коли модель підлаштовується під специфічні властивості train й втрачає якість поза ним. Висока train метрика разом із помітно нижчою validation є сигналом для дослідження. Причиною може бути надмірна складність, маленька вибірка, шум чи витік у способі поділу.

Недонавчання означає недостатню здатність описати потрібну структуру. Воно може давати низькі результати і на train, і на validation. Зміна моделі не завжди вирішує проблему: ціль або ознаки можуть бути непридатними. Аналіз починають із даних і baseline, потім оцінюють складність та регуляризацію.

Cross-validation

У k-fold дані розділяють на k частин. На кожному кроці одну частину використовують для перевірки, решту — для навчання. Отримують кілька оцінок. Для класифікації stratified fold підтримують пропорції класів. Усереднення дає орієнтир стабільності процедури, але стандартне відхилення fold саме по собі не є універсальним довірчим інтервалом.

Поділ повинен відповідати структурі. Для повторних вимірювань одного пристрою використовують груповий поділ, для прогнозу майбутнього — часовий. Випадковий shuffle може дати витік майбутнього або того самого об’єкта. Зручність API не визначає правильний спосіб оцінювання.

Pipeline усередині fold

python
from sklearn.datasets import load_wine
from sklearn.model_selection import StratifiedKFold, cross_validate
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

X, y = load_wine(return_X_y=True)
cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
model = make_pipeline(StandardScaler(), LogisticRegression(max_iter=2000))
result = cross_validate(model, X, y, cv=cv, scoring="f1_macro",
                        return_train_score=True)
print(result["train_score"])
print(result["test_score"]) # Тут test_score — validation fold.

Для кожного fold pipeline навчає scaler лише на його train. Назва ключа test_score в API означає перевірочну частину fold, а не ваш фінальний holdout. У реальному протоколі спочатку відокремте фінальний test, а cross-validation застосуйте тільки до development частини. Це запобігає плутанині назв і ролей.

Підбір гіперпараметрів

Порівняння кількох налаштувань використовує validation, тому найкраща оцінка може бути оптимістичною. За потреби точнішої оцінки процедури добору застосовують вкладену validation: внутрішній цикл обирає параметри, зовнішній перевіряє процедуру. Масштаб перевірки залежить від ризику й розміру набору.

Зберігайте число експериментів і причину вибору. Не підбирайте seed як гіперпараметр для красивого результату. Після остаточного вибору можна навчити pipeline на development даних і один раз оцінити на test. Подальші зміни за test потребують чесного визнання, що незалежність уже втрачена.

Feature engineering

Інженерія ознак створює представлення, корисне для моделі й доступне на момент прогнозу. Приклади: погоджене відношення вимірювань, частота події до поточного моменту, кодування категорії. Формула має предметну причину й перевірку знаменника. Нова ознака не гарантує покращення; її оцінюють у тій самій validation процедурі.

Статистичні перетворення, відбір ознак за ціллю й імпутація повинні навчатися всередині fold. Фіксована формула може застосовуватися до нового рядка незалежно, але також має перевіряти допустимі дані. Для часових агрегатів використовуйте тільки історію, доступну до моменту прогнозу.

Наступні напрями

Кластеризація групує об’єкти без заданої цілі; результати потребують предметної інтерпретації. Ансамблі поєднують моделі, наприклад дерева, щоб змінити компроміс помилок. Нейронні мережі навчають багатошарові представлення й потребують узгоджених даних, обчислень і оцінювання. Генеративні моделі створюють нові зразки й мають інші ризики перевірки правдивості та походження.

Жоден напрям не скасовує постановку, поділ і контроль витоку. Після використання модель може зіткнутися зі зміною розподілу. Моніторинг має спостерігати вхід, доступні результати та наслідки помилок. Потрібно визначити умови зупинки, перенавчання й ручного перегляду.

Типові помилки та практика

Помилки: scaler до cross-validation, різні поділи для порівнюваних моделей, надмірна кількість експериментів без журналу й feature з майбутньою інформацією. Різницю train/validation інтерпретують разом із розміром даних і структурою поділу. Маленький test може давати нестабільні цифри навіть за коректної процедури.

Практичний аналіз

Для даних кількох лабораторних пристроїв визначте груповий ключ і поясніть, чому випадковий поділ рядків може бути оптимістичним. Запропонуйте одну історичну ознаку й момент її обчислення. Які спостереження після deployment покажуть зміну умов? Опишіть наступний безпечний експеримент.

Вибір процедури за структурою спостережень

Для незалежних об’єктів зі схожим розподілом випадковий split може бути обґрунтованим. Якщо кілька рядків належать одній людині, потрібна перевірка перетину груп: модель може впізнавати людину замість узагальнення на нових. Group split відділяє цілі групи. Для прогнозу майбутнього time split зберігає порядок і не передає майбутні спостереження у training.

Feature engineering створює представлення ознак. Фіксований календарний sin/cos місяця не потребує цілі чи оцінки статистики. Масштабування за середнім, відбір ознак за зв’язком із y та target encoding потребують train-only процедури. Для target encoding важливо також уникнути передачі власної цілі рядка в його представлення під час навчання, використовуючи відповідну внутрішню перевірку.

Порівнюючи моделі, використовуйте однакові folds і метрику. Це зменшує вплив різного складу validation на різницю оцінок. Подайте окремі значення та розкид, а не лише найкращий запуск. Якщо виконано багато спроб, модель могла пристосуватися до validation; за потреби потрібні вкладена перевірка або новий фінальний набір.

Overfitting означає, що навчальна процедура відтворила особливості training, які слабко переносяться на нові дані. Регуляризація, обмеження складності й додаткові репрезентативні дані можуть допомогти, але не виправляють витік чи неправильну ціль. Для наступних напрямів — кластеризації, нейромереж і генеративних моделей — зберігаються вимоги до джерела, протоколу й оцінки. Спочатку поясніть, яке рішення має підтримати новий метод та як перевірятиметься його результат.

Схема процесу

Validation, перенавчання та інженерія ознакОберіть елемент, щоб побачити пояснення

Зберігаємо незалежний фінальний test.

Самоперевірка

Перевірте розуміння
Де scaler має навчатись під час cross-validation?
Як обґрунтувати відповідь своїми словами?
Pipeline навчає статистики тільки за навчальною частиною конкретного fold, захищаючи його validation від витоку.

Підсумок

Узагальнення оцінюють процедурою, яка відповідає майбутньому використанню. Pipeline, груповий або часовий поділ і незалежний test захищають від витоку. Інженерія ознак потребує предметної причини та чесної validation.

Джерела

Опрацювали матеріал?

Збережіть цей крок у своєму прогресі.

← Повернутися до дисципліни
© 2026 Анастасія Іскандарова-МалаЕлектронний навчальний посібник · ДДТУ

Пошук у посібнику

Спробуйте «C++», «RAII» або «бази даних».