Мы изучили способы преобразования необработанных данных в подходящие векторы признаков, но это только часть работы. Теперь мы должны изучить, какие значения на самом деле создают хорошие признаки в этих векторах признаков.
Избегайте редко используемых значений дискретных функций.
Хорошие значения признаков должны появляться в наборе данных более 5 раз или около того. Это позволит модели узнать, как значение этого признака связано с меткой. То есть наличие множества примеров с одним и тем же дискретным значением дает модели возможность увидеть функцию в разных настройках и, в свою очередь, определить, когда она является хорошим предиктором для метки. Например, функция house_type , скорее всего, будет содержать множество примеров, в которых ее значение будет victorian :
✔This is a good example:house_type: victorian
И наоборот, если значение признака появляется только один раз или очень редко, модель не сможет делать прогнозы на основе этого признака. Например, unique_house_id — плохая функция, поскольку каждое значение будет использоваться только один раз, поэтому модель не сможет ничему научиться из него:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Предпочитаете ясные и очевидные значения
Каждая функция должна иметь четкое и очевидное значение для всех участников проекта. Например, следующая хорошая функция четко названа, и ее значение имеет смысл в зависимости от имени:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
И наоборот, значение следующего значения функции практически непонятно никому, кроме инженера, который его создал:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
В некоторых случаях зашумленные данные (а не неправильный инженерный выбор) приводят к неясным значениям. Например, следующие значения user_age_years получены из источника, который не проверял соответствующие значения:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Не смешивайте «магические» значения с реальными данными.
Хорошие функции с плавающей запятой не содержат необычных разрывов или «магических» значений. Например, предположим, что объект содержит значение с плавающей запятой от 0 до 1. Итак, допустимы следующие значения:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Однако, если пользователь не ввел quality_rating , возможно, набор данных представляет его отсутствие с помощью магического значения, подобного следующему:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Чтобы явно отметить магические значения, создайте логическую функцию, которая указывает, был ли предоставлен quality_rating . Дайте этой логической функции имя, например is_quality_rating_defined .
В исходной функции замените магические значения следующим образом:
- Для переменных, которые принимают конечный набор значений (дискретные переменные), добавьте новое значение в набор и используйте его, чтобы указать, что значение функции отсутствует.
- Для непрерывных переменных убедитесь, что отсутствующие значения не влияют на модель, используя среднее значение данных объекта.
Учет нестабильности в восходящем направлении
Определение функции не должно меняться со временем. Например, следующее значение полезно, поскольку название города, скорее всего, не изменится. (Обратите внимание, что нам все равно нужно будет преобразовать строку типа «br/sao_paulo» в вектор one-hot.)
✔This is a good example:city_id: "br/sao_paulo"
Но сбор значения, полученного с помощью другой модели, требует дополнительных затрат. Возможно, значение «219» в настоящее время представляет Сан-Паулу, но это представление может легко измениться при следующем запуске другой модели:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"