Существующее определение Null в Data Science сильно ограничено. Приложив немножко усилий? мы значительно улучшим обработку данных, ранее попадаемых в Null.

Старая проблема — "Null" проблема. Она была сформулированна в статье Кодда в отношении семантики баз данных.

Программисты должны прикладывать много усилий, чтобы обрабатывать Null значения. Наверное, поэтому они не любят Null и даже продвигали идею, что без Null можно обойтись. Популярно высказывание о том, что включение Null в SQL было ошибкой.

Есть следующие определения Null:

• Not Available
• Not Applicable
• missed
• unknown

Последнее определение — самое часто используемое в БД.

В Data Science распросранено определение Null, как пропущенное (missed) значение.
Здесь Jake VanderPlas обсуждает использование и трактовки Null, NaN, NA, None значений в python, Pandas, numpy.

Ниже я покажу, что существующий подход лишь частично отражает реальность и во многих случаях может быть расширен именно для использования в Data Science.

Рассмотрим типичные случаи, когда в примере (sample), представлющем набор значений, отсутствуют некоторые значения.

Нет данных

Пример: датчик, снимающий значение, не выдал его. Датчик может быть поврежден. Или канал считывания данных может работать нестабильно с пропажей части данных.

Не уверены

• Конкурирующие значения: алгоритм классифицировал значение как А и Б с одинаковой вероятностью. По имеющемуся правилу мы не записываем одновременно два значения, а записываем его как Null.
• Малая Вероятность: алгоритм классифицировал значение как А, но с очень маленькой вероятностью. По имеющемуся правилу мы не можем принять значение А.
• Большая Погрешность: значение считывается с датчика. Значение получено с погрешностью, превышающей допустимую, и мы не можем с нужной достоверностью определить значение. Но при этом мы видим, что значение с датчика получено.

Повреждение

• outlier: Поле "возраст человека" содержит значение 1000 лет. На этапе проверки мы обнаружили эту ошибку и заменили значение на 1000 на Null.

Можно детализировать и другие случаи, но мы остановимся только на перечисленных.

Разные Null могут привести к различным последствиям. В вышеприведенных примерах, если Null означает "нет данных", то запустится процедура проверки датчика и канала предачи даннах. Если Null означает "Малая Вероятность", то мы придем к необходимости изменения расчетной формулы, чтобы она могла обрабатывать очень маленькие исходные значения. "Значение повреждено" может привести нас к решению поменять методики получения данных (например методику опроса).

Если мы используем данные для тренировки ML модели, то разделив Null на несколько более конкретных значений, мы извлечем больше информации из входных данных и в результате получим более точную модель.

Замена Null на классы

Рассмотрим типовую в МЛ задачу классифиции документов. Наша цель — разложить документы по нескольким классам. Но некоторые документы не могут быть классифицированны. Причина этому:

1. Текст слишком короткий, чтобы понять, какого он класса. Получаем случай Данных не хватает.
2. Документ содержит несклько частей, относящихся к разным классам. Случай Конкурирующие значения.
3. Имеем полноценный документ. Текста у нас достаточно, текст не поврежден и не многозначен. Но несмотря на это, мы не можем отнести документ к имеющимся типам. Текст документа указывает на класс, который у нас не определен. Этот класс можно определить как Другие.
4. Документ совсем без текста. Но при этом у него есть остальные признаки документа, как то: заголовок, автор, дата создания и т.п. Случай Нет данных.
5. Файл поврежден и несколько документов оборваны в разных местах. Случай Значение повреждено.

В всех этих случаях мы обычно определям класс документа как Null. Но все эти случаи будут лучше обрабатываться, если мы включим в нашу систему классификации все значения, которые часто встречаются и которые имеют смысл: "Данных не хватает", "Конкурирующие значения", "Нет данных", "Другие", "Значение повреждено". Обычно все вышеперечисленные значения будут отмечены как Null и будут удалены из тренировочных наборов данных. Но мы используем нашу модель в реальной жизни, а в ней нам будут попадаться все эти вышеперечисленные значения. И нам совсем не будет лишнее научиться распознавать и поврежденные, и многозначные, и другие подобные значения.

Все вышеизложенное было моей гипотезой. Недавно я проверил ее на классификации документов и гипотеза стала теорией. Качество моей модели ощутимо улучшилось после добавления пяти вышеперечисленных типов классов.

Есть и минус в замене Null на несколько более детальных классов. Null — это абстракция на уровне типов данных, на уровне языка, что дает нам много встроенных функций и методов в обработке данных.

С другой сторны мы по сути добавляем новые классы в нашу систему классификации, что не намного усложняет обработку.
И, как минимум, нам надо явно понимать, что понимается под Null значениями в наших данных. А лучшее понимание данных всегда приведет к лучшим результатам, не правда ли?

Автор: Leo_Gan

Источник