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

    Существующее определение 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 значениями в наших данных. А лучшее понимание данных всегда приведет к лучшим результатам, не правда ли?

    Комментарии 8

      0
      Ага, а есть ещё
      missing at random/not at random
        0

        Ага, отличное дополнение! Добавлю ссылку на этот МAR.

          0
          Заметка хорошая, но часто у нас нет возможности переполучить данные, и приходится как-то работать с пропущенными значениями на уровне построения и валидации моделей. И тут уже подходы могут быть довольно разные. Продвинутые пакеты вроде LightGBM сами пытаются подставить вместо NA разные варианты — ну там среднее по остальным значениям фичи, например (но не только) и смотрят, не улучшит ли это скор.
          Когда вы раскладываете NA на какие-то категории, пользуясь дополнительными знаниями о входящих данных — это уже скорее feature engineering начинается. Который часто улучшает модели и без наличия пропусков в данных.
            0

            Спасибо за поддержку,
            Именно! Получаются доп.фичи.
            Разные источники/причины NA могут быть определены в виде дополнительных фичь. Т.е. не просто заменой NA значения на что-то еще, а в виде доп.колонки с признаком. Из примера сверху это может быть — "не хватает текста".

              0

              Кстати,
              есть интересное дополнение.
              Часто случается, когда мы классикацию по нескольким классам заменяем на тэги. Т.е.несколько фич заменяем на фичу-list, в которой м.б. сколько угодно значений (тех же классов, к примеру). При использовании тэга может потеряться сематника пропущенных классов.
              Лучше на примере: есть значение Должность (Electrical Engineer, Mechanical Engineer). Мы работаем с фичами Индустрия и Роль, либо с тэгом. С двумя инженерами понятно. Что делать со названием работы "нужен помощник со знанием математики"? Т.е. Индустрия — "не хватает данных", Роль — "многозначная" или "другие". А с тэгом пролет, потому что натурально мы бы просто не задали никакого тэга. И тогда мы теряем семантику пропущенных двух классов одновременно. А если пытаться в тэги засунуть семантику нескльких NA значений, то будет проще опять заменить тэг на те же пару классов. (заранее извиняюсь за скомканное объяснение)

                0
                Честно говоря, я вас вообще в данном объяснении не понял, но просто конец рабочего дня, я попробую потом ещё раз :)
                  0

                  :)
                  Постараюсь с другой стороны. Если бы работали с тэгом, то были бы просто значение null или class1+class2. A c двумя классами будут null и другой null. Что совсем не один тэг null. С двумя классами все бохааче. М.б. class1_null+class2, class1+class2_null, class1_null+class2_null. А если null окрасим "разными причинами пропуска", то еще богаче, информативнее :)

                +1
                Но я повторюсь, что для этого вам нужно получить какие-то дополнительные данные откуда-то, чтобы получить эти дополнительные признаки, а зачастую такой возможности просто нет и надо уметь как-то работать с пропущенными данными и в этом случае тоже. Но в принципе идея посмотреть на всё это с другого ракурса — хорошая.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое