🔎 Есть ли особенности подбора гиперпараметров для параметрических и непараметрических моделей, кроме стандартной кросс-валидации

Обе группы моделей требуют внимательного подхода к гиперпараметрам, но непараметрические методы часто более чувствительны к их выбору и могут потребовать продвинутых стратегий поиска.

🧮 Параметрические модели:
— Настраиваются регуляризация (например, λ в Ridge/Lasso), архитектура нейросетей, степень полинома и т.д.
— Важно учитывать взаимодействие гиперпараметров: глубина сети, learning rate, регуляризация.
— Обычно меньше гиперпараметров, чем у сложных непараметрических методов, но у глубоких сетей их может быть много.

🌲 Непараметрические модели:
— Настройка может включать: размер соседства в kNN, ширину ядра в KDE, глубину дерева в Random Forest и др.
— Каждый гиперпараметр сильно влияет на комплексность модели и баланс bias/variance.
— Иногда требуется grid search или Bayesian optimization, особенно при большом гиперпараметрическом пространстве.

➡️ На больших датасетах кросс-валидация может быть слишком дорогой — используют приближённые или онлайн методы.
➡️ Риск переобучения на валидационном наборе при переборе множества конфигураций особенно актуален для гибких непараметрических моделей.

🐸 Библиотека собеса по Data Science

☁️ Как наличие label noise (шум в разметке) влияет на форму ROC-кривой и надёжность AUC

Если положительные объекты иногда промаркированы как отрицательные (и наоборот), это снижает видимую производительность модели:
▶️ ROC-кривая становится менее отчётливой: даже идеальный классификатор «ошибается» на перевёрнутых метках.
▶️ Кривая смещается вниз (снижается TPR) или вправо (растёт FPR), что уменьшает AUC.
▶️ При сильном шуме в положительном классе растёт число ложных отрицаний, а в отрицательном — ложных срабатываний, что может создавать «провалы» на кривой.

Если интересно глубже разобраться, как метрики ведут себя при шумных данных и как строить более надёжные модели:
— AI-агенты для DS-специалистов
— ML для старта в Data Science

🐸 Библиотека собеса по Data Science

💱 Что делать, если основной бизнес-метрик не совпадает со стандартными ML-метриками, из-за чего модель в проде кажется «недоработанной»

Частая ошибка — оптимизировать модель по ML-метрикам (AUC, accuracy) на этапе разработки, а в продакшене обнаружить, что реальный успех измеряется бизнес-KPI (конверсия, доход, удержание пользователей). В итоге модель может показывать отличные офлайн-результаты, но не влиять на бизнес.

Как решать:
✅ С самого начала синхронизировать ML-метрики с бизнес-целями.
✅ Если бизнес-метрика сложная, разложить её на проксими-триггеры, которые можно оптимизировать офлайн.
✅ Проверять корреляцию ML-метрик с бизнес-результатами через A/B-тесты.
✅ Учитывать внешние факторы: маркетинговые кампании, сезонность, изменения интерфейса — они могут «перекрывать» эффект модели.

Если хочется научиться строить ML-модели так, чтобы они работали не только «в тетрадке», но и в бизнесе:
— AI-агенты для DS-специалистов
— ML для старта в Data Science

🐸 Библиотека собеса по Data Science

💬 Можно ли делать отбор признаков на всём датасете до разделения на train и test

Нет, так делать не рекомендуется. Если отбор признаков выполняется на всём датасете, информация из теста «просачивается» в обучение → возникает data leakage, а итоговые метрики оказываются слишком оптимистичными.

Правильный подход:
➡️ Сначала разделяем данные на train / test (и при необходимости на фолды для кросс-валидации).
➡️ На train выполняем отбор признаков (RFE, фильтры, встроенные методы).
➡️ Обучаем модель на этих же данных.
➡️ Валидируем на validation/test, где признаки выбираются так же через пайплайн.

👌 После кросс-валидации фиксируем пайплайн и переобучаем на всём train, затем оцениваем на hold-out test.

🐸 Библиотека собеса по Data Science