Вы пишете банальный df.dropna().fillna(0), скармливаете это в fit-predict и считаете, что подготовили датасет. Или собираете пайплайн, где пропущенные значения датчиков забиваются средним по больнице, а выбросы сглаживаются скользящим окном. Это не подготовка данных. Это самоубийство проекта еще на этапе задумки.
Абсолютное большинство команд путает техническую чистоту таблиц с готовностью к машинному обучению. Отсюда и берется главная боль индустрии. Если вас спросят про аудит данных перед ML-проектом: почему 80% времени уходит на данные, а не на нейросеть, смело отвечайте — потому что бизнес-логика сложнее математики. Нейросеть стерпит любой мусор, сойдется к локальному минимуму и выдаст вам красивые 95% точности на валидации. А в проде вы получите генератор убытков.
Аудит пайплайна данных: Data Readiness вместо Data Quality
Забудьте термин data quality. Качество данных — это абстракция из мира классического хранилища. Дата-инженер скажет, что таблица качественная, если в ней нет нулей в primary keys и типы колонок совпадают со схемой. Для ML это вообще ничего не значит. Нам нужна data readiness — степень готовности конкретного датасета отвечать на конкретный бизнес-вопрос в условиях реального времени. Это кардинально разные метрики.
Датасет может быть кривым, с пропусками и дублями, но обладать высочайшей data readiness, потому что он отражает суровую правду того, как сырые логи потекут на инференс. Если вы вычистите все аномалии на этапе подготовки, модель научится работать в стерильной лаборатории. Как только она столкнется с реальным датчиком, который искрит и шлет мусор каждую третью секунду, ваш MLOps-пайплайн сложится пополам. Алгоритм должен уметь работать с той грязью, которая ждет его в бою.
Шесть проверок, на которых ломается production-ML
Любой аудит датасета сводится к шести жестким проверкам, которые нужно прогнать до того, как вы импортируете фреймворки. Первая проверка — полнота. И речь не про отсутствие пустых ячеек, а про наличие всех факторов, влияющих на целевую переменную. Если вы предсказываете брак детали, но у вас нет данных о температуре в цеху, хотя она критична для техпроцесса, никакая магия архитектур эту дыру не закроет.
Вторая и третья проверки идут рука об руку — это консистентность и адекватность разметки. Данные с разных систем часто противоречат друг другу: в CRM клиент еще активен, а в биллинге уже отключен. Разметка при этом может быть сделана тремя разными асессорами в разном настроении с противоречивыми критериями. Если консенсуса нет на уровне сырой базы, алгоритм просто выучит шум разметчиков.
Четвертая проблема — объем исторической выборки, и тут же рядом пятая, самая страшная — утечка таргета. Когда мы в MoranaLabs катили предиктивный мейнтенанс для прокатного стана, заказчик гордо выкатил архив за пять лет. Выглядело роскошно, пока мы не начали профилировать временные метки. Оказалось, что статус поломки записывался в базу в конце смены задним числом, но с таймстемпом начала смены. Модель видела будущее. Это классический target leakage. Если бы мы не поймали это на аудите, мы бы получили идеальную метрику на тестах и абсолютно бесполезный кусок кода на заводе.
Шестая проверка звучит скучно, но может похоронить бизнес: право использовать эти данные. Особенно когда речь идет о персональных данных, логах камер или закрытых коммерческих тайнах. Вытащить модель в прод и узнать, что безопасники запрещают выносить этот срез данных за периметр — классика жанра. Всегда уточняйте легальный статус до того, как начнете жжечь вычислительные мощности.
Профилирование за неделю: иллюзии и реальность
Понять, хватит ли вам данных, можно за пять рабочих дней. Не нужно строить монументальные дашборды. Соберите черновой пайплайн: загрузка, базовые статистики по распределениям, корреляционная матрица и простейшая baseline-модель, вроде случайного леса или логистической регрессии. Если baseline показывает метрику на уровне броска монетки, у вас проблемы с признаками или таргетом. Нейросеть здесь не поможет.
Кстати, о нейросетях. Удивительно, как часто команды тащат в проект тяжелые трансформеры, когда у них банально разъезжается временной ряд из-за перехода на летнее время. Люди готовы тратить тысячи долларов на аренду GPU, чтобы математикой компенсировать баг в функции конвертации часовых поясов. Возвращаясь к профилированию: минимальные объемы под типовые задачи давно известны. Для табличных данных с вменяемым сигналом нужно хотя бы десять тысяч строк репрезентативной истории. Для дообучения компьютерного зрения — от тысячи примеров на класс с хорошей вариативностью освещения и ракурсов. Меньше этого порога вы занимаетесь не машинным обучением, а подгонкой под тестовую выборку.
Синтетика, дозбор и когда выгоднее убить легаси
Довольно часто аудит показывает, что данных мало или они намертво закрыты строгими политиками безопасности и физически не могут покинуть изолированный контур клиента. В edge-вычислениях это обычное дело. Сидеть и жаловаться на жизнь бессмысленно — здесь спасает синтетика. Генерация синтетических данных позволяет создать математически точную копию датасета, которая сохраняет все статистические свойства оригинала, но не содержит ни одной реальной записи. Вы обучаете модель на синтетике в облаке, а потом приносите готовые веса в закрытый контур для инференса.
И здесь мы подходим к главному трейд-оффу инженерии данных. Чистка данных — это не разовый акт перед стартом проекта. Это непрерывный процесс, зашитый в саму архитектуру системы. Но иногда чистить исторический мусор просто экономически нецелесообразно. Если переписывание легаси-парсеров и выравнивание форматов за три года займет полгода работы сеньор-инженеров, дешевле выбросить этот лог. Поставьте нормальные датчики, настройте жесткие контракты на схемы данных и соберите новый, чистый датасет за два месяца. Индустрия боится удалять данные, считая их новой нефтью. Но нефть бывает пролита в болото, и отделить ее от грязи стоит дороже, чем пробурить новую скважину.