ПОЛНЫЙ ПРОЕКТ НАУКИ О ДАННЫХ
Завершить проект Data Science: понимание данных
Проект прогнозирования количества заказов в производственной компании, котирующейся на бирже, на основе Global Management Challenge.
Это первая статья из серии Проект по науке о данных. Я хотел бы представить путеводитель по миру машинного обучения. Я опишу основные теоретические предположения, а также практические решения. Являетесь ли вы новичком и только интересуетесь темой искусственного интеллекта или уже работаете Data Scientist, я думаю, что моя статья дойдет до каждого из вас и мотивирует продолжать вашу работу. Каждая статья была разделена на этапы процесса Data Science в соответствии с методологией Общеотраслевого стандартного процесса интеллектуального анализа данных:
1. Бизнес-понимание
2. Данные Понимание— вы здесь
3. Подготовка данных
4. Моделирование
5. Оценка
6. Развертывание
Весь проект вы найдете на GitHub.
Наша цель бизнес-задачи — правильно спрогнозировать количество заказов на продукцию, поэтому имеющиеся у нас данные — это материал, из которого будет создано решение нашей задачи. На этом этапе нам нужно получить данные, а затем оценить их полезность.
Мы должны понимать их преимущества и ограничения, поскольку согласно принципу GIGO (Garbage In Garbage Out) с использованием плохой модели данных результаты также будут низкого качества. Данные должны быть репрезентативными, а также полезными для решения нашей проблемы.
Получить данные
В предыдущей статье я упомянул, что отчеты в электронных таблицах. Мы выбрали переменные, которые, согласно бизнес-анализу, влияют на количество заказываемых товаров. Несколько раз случалось, что данные приходили из предыдущих отчетов. Это, очевидно, логично, потому что прошлое влияет на будущее, а не только на нашу текущую деятельность. Более того, как вы можете видеть, переменные различаются между рынками. Мы использовали рекламу продукта и рекламу имиджа (корпоративную), комиссию и поддержку агентов и дистрибьюторов и их количество. Далее для интернета процент неудачных посещений сайта и развитие сайта. Вопросы работы компании, такие как количество учебных дней для сотрудников. Бюджет на управление или время сборки продукта. Более того, отставание по заказам, такое появлялось в ситуации, когда заказов было больше, чем реально было в наличии, оценка товара нашими покупателями и цена, по которой мы хотели продать товар. Мы заметили, что в ходе конкурса прокручивалось 4 разных истории, которые мы также приняли в качестве переменной и цикла принятия решений, чтобы иметь информацию о сезонности. Выбирая переменные, мы имели в виду, чтобы предотвратить явление просмотра вперед. Это данные, которые известны после получения нашей цели, поэтому они выглядят очень ценными (сильная корреляция с прогнозируемой переменной), но на самом деле бесполезны. Мы указали, в какой строке они находятся в отчете и откуда взяты данные из последнего отчета (с) или предыдущего (р).
У нас есть 417 отчетов, 20 из которых — это истории, с которых команды начинают, потому что, как я упоминал ранее, было 4 сценария, а в истории было 5 отчетов. Мы написали скрипт и собрали все отчеты в файлы с переменными по продуктам и направлениям продаж.
Я не решился создать единую модель, и это потому, что между областями иногда на количество заказов влияли другие переменные. В итоге было создано 3 набора данных в зависимости от того, к какой области относились продажи. Благодаря такому подходу у нас было больше данных, чем количество отчетов.
Исследование
Давайте посмотрим на наши данные и посмотрим на первые пять строк каждого набора данных.
Давайте проверим количество строк в каждом из наборов данных, какие типы переменных есть и все ли значения не равны нулю.
RangeIndex: 1190 entries, 0 to 1189 Data columns (total 17 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 NumOrders 1190 non-null int64 1 History 1190 non-null category 2 Cycle 1190 non-null category 3 DirAdv 1190 non-null float64 4 CorpAdv 1190 non-null float64 5 Commission 1190 non-null float64 6 AgentsDistr 1190 non-null int64 7 Training 1190 non-null float64 8 ManagBudget 1190 non-null float64 9 BacklogOrders 1190 non-null int64 10 RandD 1190 non-null float64 11 Price 1190 non-null float64 12 AssemblyTime 1190 non-null float64 13 MarketShares_p 1190 non-null float64 14 MeanPrice 1190 non-null float64 15 NumSales_p 1190 non-null int64 16 Product 1190 non-null category dtypes: category(3), float64(10), int64(4) memory usage: 134.3 KB
RangeIndex: 1191 entries, 0 to 1190 Data columns (total 17 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 NumOrders 1191 non-null int64 1 History 1191 non-null category 2 Cycle 1191 non-null category 3 DirAdv 1191 non-null float64 4 CorpAdv 1191 non-null float64 5 Commission 1191 non-null float64 6 AgentsDistr 1191 non-null int64 7 Training 1191 non-null float64 8 ManagBudget 1191 non-null float64 9 BacklogOrders 1191 non-null int64 10 RandD 1191 non-null float64 11 Price 1191 non-null float64 12 AssemblyTime 1191 non-null float64 13 MarketShares_p 1191 non-null float64 14 MeanPrice 1191 non-null float64 15 NumSales_p 1191 non-null int64 16 Product 1191 non-null category dtypes: category(3), float64(10), int64(4) memory usage: 134.4 KB
RangeIndex: 1187 entries, 0 to 1186 Data columns (total 18 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 NumOrders 1187 non-null int64 1 History 1187 non-null category 2 Cycle 1187 non-null category 3 DirAdv 1187 non-null float64 4 CorpAdv 1187 non-null float64 5 Support 1187 non-null float64 6 FailedVisits 1187 non-null float64 7 Training 1187 non-null float64 8 ManagBudget 1187 non-null float64 9 WebDev 1187 non-null float64 10 BacklogOrders 1187 non-null int64 11 RandD 1187 non-null float64 12 Price 1187 non-null float64 13 AssemblyTime 1187 non-null float64 14 MarketShares_p 1187 non-null float64 15 MeanPrice 1187 non-null float64 16 NumSales_p 1187 non-null int64 17 Product 1187 non-null category dtypes: category(3), float64(12), int64(3) memory usage: 143.2 KB
Разница в количестве строк для каждого набора данных связана с тем, что некоторые команды не решили продавать товары на определенной территории. Для каждого набора данных почти 1120 примеров, что означает, что это довольно маленький набор с таким количеством переменных. В целом, чем больше выборка, тем лучше репрезентативность генеральной совокупности при условии, что выборка не является предвзятой. Нет ненулевого значения, но это не означает, что все данные верны. В данных могут быть ошибки. В следующих анализах мы это проверим. Переменные History, Cycle и Product являются категориальными. Остальные переменные являются числовыми, и мы представим наиболее важные показатели для числовых переменных.
Большинство заказов было в Европе, а меньше всего в районе Нафты. Мы можем сделать аналогичные выводы из данных по каждой области. 75-й процентиль значительно меньше максимального значения, здесь можно ожидать выбросов — вероятно, такая ситуация была, когда очень хорошая команда играла в Global Management Challenge или команда давала высокие рекламные значения и/или низкие цены. В рекламе также показаны выбросы, близкие к максимальным. У половины команд не было BacklogOrders, а у других было очень мало, но были и крайности. Самая большая проблема связана с MarketShares_p, где много нулевых значений. Это невозможная ситуация, потому что если команда продавала продукты, у нее должны быть доли рынка. Отсутствие данных связано с тем, что команде пришлось купить такую услугу, чтобы получить эту информацию. Многие команды не решились на это, несмотря на то, что это ценная информация. На этапе подготовки данных нам придется разобраться с этой проблемой.
Посмотрите, какой процент составляют значения, равные 0, которые мы считаем ложными.
In Europe dataset is 50.59 of values equal to 0. In Nafta dataset is 50.63 of values equal to 0. In Internet dataset is 50.8 of values equal to 0.
Незначительные различия возникают из-за различий в количестве рядов. Половина данных отсутствует, а данные очень ценны, поскольку показывают положение компании на рынке.
Сгруппируйте данные по продуктам.
набор данных ➜ data_Europe| данные_Нафта | данные_Интернет
Продукт 1 — самый продаваемый, а Продукт 3 — самый редкий. Район Нафты — это район, где на рекламу тратится меньше всего денег. Это потому, что когда мы начинаем игру в каждом сценарии, это развивающаяся область, где бизнес недавно начался. Некоторые переменные одинаковы, и это потому, что они не различаются с точки зрения продуктов и областей. Также следует отметить, что средняя цена продукции команд из группы самая высокая в Интернете.
Номер цикла и история являются переменными, которые, по-видимому, хорошо отражают сезонность. При этом с каждым последующим циклом количество заказов увеличивается (расширение компании), хотя бывают и отклонения от этого правила (обвалы рынка и т.п.).
Блочная диаграмма — это другой вид блочной диаграммы, это удобная и наглядная форма представления основных статистических данных. Он состоит из коробки и усов. Границы ящика определяются по нижнему и верхнему квартилю, поэтому значение не менее 25% и одновременно не более 75% наблюдений. Таким образом, ширина поля представлена IQR = Q3 — Q1 (межквартильный диапазон). Внутри коробки всегда есть медиана. Длина усов составляет 1,5 IQR. Более высокие или более низкие значения называются выбросами. Конечно, может случиться так, что таких выбросов в выборке нет, тогда длины усов равны минимальному и максимальному элементу выборки соответственно.
Хорошо, мы видим, что данные между областями очень похожи, самые важные различия связаны с другими переменными и разным спросом. Далее анализ будет касаться только европейской области, в этом наборе мы также будем заниматься подготовкой данных, моделированием и реализацией. Если результаты будут правильными, можно будет реализовать это решение в других областях. Давайте посмотрим, как часто появляются категориальные данные.
Данные не сбалансированы по истории, поэтому большинство отчетов из истории 2 и меньше всего из истории 1. С каждым последующим циклом у нас меньше отчетов, потому что некоторые команды не сохранили последние отчеты.
Парная диаграмма – это точечная диаграмма для всех комбинаций числовых переменных в парах. В отношении переменной product мы разделили наблюдения на подгруппы. При этом для каждой переменной были построены гистограммы с оценкой плотности, то есть эмпирического распределения анализируемой количественной переменной.
Представлена тепловая карта с линейной корреляцией Пирсона для Европы. 1 означает, что баллы указывают на сильную положительную линейную корреляцию, а -1 — на сильную отрицательную корреляцию. 0 означает отсутствие линейной корреляции, что не означает, что нет другой нелинейной корреляции. Мы можем оценить количество тесно связанных переменных.
PCA используется для уменьшения размеров. Избавляемся от ненужных данных, поэтому убираем шум. Мы группируем функции, которые представляют одну и ту же информацию. Я показал, какому количеству измерений соответствует процент дисперсии. 90% дисперсии/информации можно описать с половиной числа переменных.
У нас уже есть представление о переменных. Если вы считаете, что я мог бы сделать что-то лучше или добавить что-то к этому — напишите, пожалуйста.
Увидимся в следующем посте!
