1. Как работать с выбросами: когда удалять, а когда оставлять и почему?
Важно разделять выбросы и аномалии.
Выброс— это значение, резко отличающееся от остальных данных в наборе, обычно возникшее из‑за ошибки (например, при вводе, измерении или передаче данных).
Аномалия— продолжительная нетипичная динамика, может быть реальным явлением. Отличить их можно по контексту и происхождению: если значение явно нелогично — скорее выброс.
Выбросы чаще всего нужно удалять, так как они искажают статистику и смещают модель (например, влияют на среднее и дисперсию, ухудшают качество регрессии).
Аномалии удалять не следует, поскольку они могут быть информативны (например, сигнализировать о мошенничестве, редких событиях, новых трендах). Их нужно анализировать и обрабатывать.
2. Как оценить модель для мультиклассовой классификации?
В большинстве случаев классы несбалансированы и редкие классы важны, как например в классификаторах обращений и заявок, поэтому условный Accuracy в данном случае не подойдет. Для оценки таких моделей хорошо подойдут метрики F1/Precision/Recall в формате per‑class, или взвешенные по частоте.
Когда важно отделять каждый класс от остальных, можно воспользоваться PR‑AUC one‑vs‑re — часто при редких классах PR‑AUC информативнее других метрик.
3. Как ускорить обучение модели?
Классические алгоритмы (линейные модели, градиентный бустинг) обычно обучаются быстро. Если же нужна нейросеть, ключевые рычаги скорости — это железо и настройки обучения.
Перенос вычислений на GPU обычно даёт кратный прирост. Также нужно настроить размер батча, чтобы лучше загрузить GPU. Отдельно важен learning rate: корректно подобранный LR ускоряет сходимость и позволяет достичь нужной метрики за меньшее число эпох.
На скорость напрямую влияет размер датасета: чем больше данных, тем дольше одна эпоха и тем выше общая стоимость обучения. Поэтому имеет смысл начинать с подвыборки для быстрых экспериментов, убирать дубликаты и шум, а при необходимости — сокращать размер входных признаков, если это не приводит к потере качества.
4. Как документировать ML‑проект?
Должно быть ясно, что это за модель, на каких данных она обучалась, как измеряется качество и в каких условиях её можно безопасно применять. Обычно начинают с цели: бизнес‑контекст, формулировка ML‑задачи, целевая метрика и критерии успеха, а также ограничения вроде задержки, стоимости инференса и требований к интерпретируемости.
Дальше описываются этапы обучения и эксплуатации в продакшене — обработка данных, feature engineering, архитектура модели и необходимое окружение, схема деплоя и мониторинги. Лучше всего ссылаться на версионированные артефакты (датасеты, модели, логи, дешборды), чтобы документация не устаревала.
курс по Data Science для middle: senior-навыки за 6 недель
Best practices по внедрению моделей в продакшн на примере реальных задач из BigTech. Без «красивых» ML и базовых методов — только грязные данные, real-time ML и ежедневные проблемы DS на работе