Когда аналитик впервые сталкивается с реальными корпоративными данными компании, у него почти всегда включается желание довести таблицу до идеального состояния: убрать все пропуски в столбцах, исправить все опечатки в тексте, выровнять справочники иными словами, неплохо так повысить качество данных. Но в компании идеальные данные почти всегда либо слишком дороги в реализации, либо вообще недостижимы, потому что данные - это побочный продукт процесса, в котором участвуют люди, системы, ручные правки, смены регламентов и исторические хвосты. Если пытаться вычистить всё, ты очень быстро превращаешь аналитику в ремонт, и это ремонт без конца, потому что процесс продолжает жить и порождать новые артефакты в данных.
Поэтому у аналитика должна быть другая цель: данные должны быть достаточно чистыми для решения. Логичен следующий вопрос, как быстро понять, где некачественные данные уже ломают выводы, а где этими данными можно пренебречь и это ни на что не повлияет практически.
В одной из прошлых статей я разбирался, почему на очистку данных уходит большая часть работы аналитика, в этой же статья я предлагаю разобраться с тем, а какой есть механизм проверки этих данных.
Регрессия
Самый полезный трюк в таких задачах - строить простую регрессию не ради прогнозов, а ради диагностики. Ты берёшь метрику, которую хочешь объяснить (например, time-to-fill), добавляешь несколько признаков, которые должны быть связаны с результатом по смыслу (скорость фидбека, число этапов, тип подбора, грейд позиции и т.п.).
Мысль тут вот в чем: регрессия не доказывает истину, но она очень быстро подсвечивает, где в данных нарушена логика. Если коэффициенты и остатки выглядят странно, это может быть сигнал, что ты смешал разные режимы процесса, дал модели поля, которые содержат ответ постфактум, или просто считаешь метрику так, что она не сравнима между сегментами.
Что именно можно сделать за 30-60 минут
Можем разобрать такой пример: для HR-кейса можно собрать датасет на уровне одна строка - одна вакансия и положить туда несколько колонок, которые обычно есть почти в любой ATS:
- ttf_days - time-to-fill в днях (по методологии, которая зафиксирована у вас в компании);
- type - тип подбора (ИТ подбор, массовый, технический, общекорпоративный);
- grade - уровень роли, если есть;
- feedback_hours - сколько часов рекрутер ждал фидбек после интервью или после отправки резюме нанимающему менеджеру;
- n_interviews - количество интервью/этапов;
- offer_approval_days - сколько длилось согласование оффера;
- month_opened - месяц открытия, как прокси сезонности.
Дальше наводим обычный порядок в данных и запускаем простую модель.
Под обычным порядком я подразумеваю то, чтобы метрика и признаки имели смысл. То есть проверка, что ttf_days не отрицательный, что даты идут в правильном порядке, что нет дублей вакансий после переоткрытий, что feedback_hours не заполнен постфактум и не равен нулю по умолчанию у половины записей, что n_interviews не содержит странных значений типа 0 или 25, если это не прописано в регламентах процесса.
А дальше можно взять самую простую линейную регрессию. Мы пытаемся объяснить ttf_days через набор факторов, где категориальные признаки (например, type) превращаем в dummy-переменные, а числовые оставляем как есть. Если хочется сделать чуть устойчивее к хвостам, можно сделать лог-трансформацию log(ttf_days + 1) или вместо линейной регрессии попробовать Huber/Quantile, но даже базовый вариант уже даёт полезные сигналы.
На что смотреть в регрессии
Попробую не превращать статью в лекцию. Если кратко, то для диагностики качества данных чаще всего достаточно трёх вещей.
Первая - знаки и порядок величин. Если модель говорит, что увеличение feedback_hours уменьшает time-to-fill, это не интересная находка, это чаще всего красный флаг. Потому что здравый смысл здесь иной, чем дольше ждём фидбек, тем дольше закрываем. Если знак обратный, значит либо поле криво заполнено, либо измеряется не то, либо выборка не та: например, в быстрых кейсах фидбек фиксируется хуже, а в медленных фиксируется лучше, и модель начинает объяснять качество заполнения вместо процесса.
Вторая - утечки (leakage). Это когда в признаки попадает информация из будущего, которую в момент принятия решения знать нельзя. В HR это встречается постоянно. Например, статус "причина отказа кандидата" или "итог интервью" может быть заполнен только после исхода, но если ты включишь это в модель, она станет идеальной, потому что ты буквально дал ей ответ. Технически это выглядит так: метрика качества резко взлетает, а важнейшим признаком становится поле, которое бизнес не может использовать заранее. Поэтому простое правило: в модели должны быть только те признаки, которые доступны до события, иначе это не прогноз и не диагностика, а самообман.
Третья - остатки и выбросы. После модели ты смотришь, какие вакансии не объясняются. И вот именно там часто живут либо реальные особые кейсы (редкие профили, топы, позиции в резерве), либо ошибки данных (переоткрытия, неверные даты и т.п.). И вот это суперполезно, потому что ты перестаёшь чистить наугад и начинаешь чистить точечно: конкретные типы аномалий, конкретные сегменты, конкретные поля.
Как из этой диагностики рождается стратегия
После такой простой регрессии обычно становится видно, что именно нужно чистить в первую очередь, потому что оно ломает смысл.
Если у тебя проблемы со знаками, то ты идёшь в определение метрики и в качество ключевых признаков, а не в косметические правки. Если у тебя утечки, ты строишь более корректный срез по времени и выбрасываешь поля, которые появляются только постфактум. Если у тебя странные выбросы, ты не выкидываешь их, а разделяешь реальность на слои: базовый сегмент для сравнимого управления и отдельный сегмент для выяснения ошибок.
Вывод 🎯
Очистка данных без фанатизма - это не компромисс с качеством, а правильная постановка цели. Критично чистить то, что меняет смысл метрики и сравнимость, потому что именно это ломает решения, а всё остальное можно оставлять, если ты обозначаешь допущения. А простая регрессия в этой логике становится не сложной моделью, а быстрым техническим тестом на здравый смысл: если коэффициенты, знаки и остатки выглядят абсурдно, то абсурд, скорее всего, сидит в данных, и это отличный повод чистить точечно, а не бесконечно.
Я регулярно разбираю такие темы в своём Telegram-канале, если вам интересно глубже понимать аналитику и работать с данными, там регулярно выходят короткие заметки и практические примеры.