Данные машинного обучения AWS

Есть несколько проблем с тем, как вы настраиваете свою модель.

1) Время в том виде, в каком оно у вас есть, никогда не должно быть категоричным. В вашей модели время 12:29 и 12:30 рассматривается как два совершенно независимых атрибута. Таким образом, он никогда не будет использовать факты, полученные в 12:29, чтобы предсказать, что произойдет в 12:30. В вашем случае вы либо должны установить числовое время. Не уверен, что amazon ML может конвертировать его для вас автоматически. Если не просто умножить час на 60 и добавить к нему минуты. Еще одна интересная вещь, которую можно сделать, — это разделить свое время, выбрав получасовой или более широкий интервал. Вы делаете это, разделив (ч * 60 + м) на некоторое число в зависимости от того, сколько ведер вы хотите. Итак, попробуйте 120, чтобы получить 2-часовые интервалы. Как правило, чем больше данных у вас есть, тем меньшие интервалы вы можете иметь. Главное, чтобы в каждом ведре было много образцов.

2) Вы действительно должны подумать об удалении restaurantID из ваших входных данных. Наличие его там приведет к тому, что модель будет слишком подходить к нему. Таким образом, он не сможет делать прогнозы о ресторане с идентификатором: 5 на основе фактов, которые он узнает из ресторанов с идентификатором: 3 или идентификатором: 9. Иметь идентификатор ресторана может быть хорошо, если у вас есть много данных о каждом ресторане, и вы не заботитесь об экстраполяции своих прогнозов на рестораны, которых нет в тренировочном наборе.

3) Вы никогда не отправляете restaurantID, чтобы предсказать данные о нем. Как это обычно работает, вам нужно выбрать то, что вы пытаетесь предсказать. В вашем случае, вероятно, наиболее полезным атрибутом является «waitingTime». Итак, вам нужно отправить день недели, время и количество людей, и модель выведет время ожидания.

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

Например, время суток — это не просто число. Из-за моего ограниченного понимания ресторана я бы отказался от минут и сосредоточился только на часах.

Я бы, конечно, создал модель для каждого ресторана, так как популярность ресторана или тип блюд, которые в нем подают, влияют на время ожидания. С помощью Amazon ML легко создавать множество моделей, поскольку вы можете построить модель с помощью SDK и даже запланировать переобучение моделей с помощью AWS Lambda (это означает автоматически).

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

В отличие от некоторых ответов на этот пост, я думаю, что resturantID помогает и действительно дает ценную информацию. Если у вас есть значительный объем данных по каждому ресторану, вы можете обучить модель для каждого ресторана и получить хорошую точность, но если у вас недостаточно данных, то resturantID будет очень информативным.

1) Только представьте, что если бы в вашем наборе данных было всего два столбца: идентификатор ресторана и время ожидания. Тогда не думаете ли вы, что restaurantID из данных тестирования поможет вам определить примерное время ожидания? В простейшей реализации время ожидания для каждого идентификатора ресторана будет средним значением waitTime. Так что, безусловно, restaurantID — это ценная информация. Теперь, когда у вас есть больше функций в вашем наборе данных, вам нужно проверить, является ли restaurantID таким же эффективным, как и другие функции, или нет.

2) Если вы решите сохранить идентификатор ресторана, вы должны использовать его как категориальную строку. Это должна быть непараметрическая функция в вашем наборе данных, и, возможно, поэтому вы не получили надлежащего результата.

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