Инжиниринг признаков - это замаскированное бизнес-решение
Переменные, которые вы подаёте в модель машинного обучения - не чисто технический выбор. Они кодируют допущения о вашем бизнесе, которые заслуживают явной проверки.
Когда специалист по данным говорит об инжиниринге признаков, он обычно имеет в виду процесс выбора переменных для включения в модель и трансформацию сырых данных в эти переменные. Звучит технически. На практике это одно из мест, где бизнес-логика входит в систему машинного обучения наиболее тихо - и поэтому наиболее опасно.
Я видел, как это вызывало реальные проблемы. Модель, построенная для предсказания оттока клиентов, использовала «количество обращений в поддержку» как признак. Вшитое допущение: больше обращений означает менее довольного клиента с более высоким риском оттока. Это правдоподобно. Это также означает, что модель оценивала клиентов, никогда не обращавшихся в поддержку, как низкорисковых по оттоку - независимо от того, были ли они удовлетворены или просто не могли дозвониться до живого человека. Признак кодировал сбой бизнес-процесса как сигнал качества.
Что на самом деле кодируют признаки
Каждый признак - это гипотеза о связи между какой-то измеримой величиной и результатом, который вы пытаетесь предсказать. Эта гипотеза откуда-то берётся. В большинстве реальных проектов она исходит из:
- Экспертизы предметной области («опытные операторы знают, что X коррелирует с Y»)
- Исторических паттернов в данных («когда мы смотрим на ушедших клиентов, у них, как правило, было Z»)
- Упрощений и прокси («мы не можем измерить то, что действительно хотим, поэтому используем W как заменитель»)
Каждое из них - бизнес-суждение, а не математическое. Специалист по данным может реализовать гипотезу. Он не может проверить, обоснована ли она, без участия того, кто глубоко понимает бизнес.
Проблема прокси
Прокси-признаки особенно заслуживают проверки. Прокси - это измеримая переменная, замещающая то, что нельзя измерить напрямую. «Время с последней покупки» - прокси для вовлечённости. «Дни с последнего входа» - прокси для интереса. Эти прокси обычно разумны, но могут ломаться в конкретных условиях, с которыми модель столкнётся в продакшне.
Прежде чем принять прокси-признак, нужно задать вопрос: при каких обстоятельствах этот прокси станет вводящим в заблуждение сигналом? Если можно представить правдоподобный сценарий, где незаинтересованный клиент выглядит заинтересованным по этой мере - или наоборот - признак требует более тщательной обработки.
Где вписывается бизнес-проверка
Я не утверждаю, что каждый признак требует утверждения на уровне совета директоров. Я утверждаю, что выбор признаков должен включать структурированную проверку человеком со знанием бизнеса до выхода модели в продакшн.
Проверка не обязана быть исчерпывающей. Вопросы такие:
- Имеет ли этот признак интуитивный смысл как предиктор результата?
- Можно ли его использовать в своих интересах или манипулировать им после того, как модель запущена?
- Кодирует ли он какое-то допущение о наших клиентах или операциях, которое мы, возможно, захотим пересмотреть?
- Стабильно ли определение этого признака со временем, или оно изменится по мере изменения бизнес-процессов?
Практическое замечание
Документация признаков стоит того, чтобы рассматривать её как бизнес-документ, а не только технический. Для каждого признака в модели фиксируйте, что он измеряет, какое допущение кодирует и что сделало бы его недействительным. Этот документ позволяет поддерживать, аудировать и обновлять модель тому, кто не был в комнате при её построении.
Это менее эффектно, чем настройка гиперпараметров. И важнее.