Null проблема в Data Science и Machine Learning +9


Существующее определение 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.


Вот здесь представлен хороший обзор текущего состояния дел с missed data (спасибо AlkanSte !)


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


Нет данных


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


Не уверены


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

Повреждение


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

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


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


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


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


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


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

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


Во многих случаях такой фича-инжиниринг может существенно повысить качество классификации.


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


Мы, по сути, добавляем новые классы в нашу систему классификации, что не намного усложняет обработку.


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




К сожалению, не доступен сервер mySQL