Я не вижу ваш код. Но я получил ваши данные.
Я думаю PRIORITY
и SCHEDQT
являются y
данными.
И я использую LEADTIME
, BOMINV
, BOMINFSW
, SKUINV
, SKUINFSW
и COQTY
в качестве x
данных. Вы должны знать, что данные нормализуются просто между 0 ~ 1.
Это лучше, чем раньше.
Но, это не предсказано хорошо. Пожалуйста, ознакомьтесь с результатом, как показано ниже:
[`LEADTIME`, `BOMINV`, `BOMINFSW`, `SKUINV`, `SKUINFSW`, `COQTY`] [Pre. PRIORITY] [Real PRIORITY]
[0.03333333 0.33333333 0. 0. 0. 0.05666667] [8.221004] [18.]
[0.03333333 0.33333333 0. 0. 0. 0.26666667] [8.221004] [19.]
[0.03333333 0.33333333 0. 0. 0. 0.16666667] [8.221004] [20.]
[1. 0. 1. 0. 0. 0.16666667] [8.221004] [1.]
[1. 0. 1. 0. 0. 0.26666667] [8.221004] [2.]
Я думаю, что каждое значение поля не может иметь достаточной разницы с PRIORITY
результатом.
Из приведенного выше примера LEADTIME
, BOMINV
, BOMINFSW
, SKUINV
и SKUINFSW
одинаковы.
Затем я попытался удалить некоторые записи, если LEADTIME
или BOMINV
или SKUINV
равно 0
.
[0.2 0.33333333 0. 0.66666667 0. 0.33333333] [20.035915] [36.]
[0.2 0.33333333 0. 0.66666667 0. 0.46666667] [20.035915] [38.]
[0.2 0.33333333 0. 0.66666667 0. 0.6 ] [20.0352] [40.]
[0.2 0.33333333 0. 0.33333333 0. 0.16666667] [11.69006] [1.]
[0.2 0.33333333 0. 0.33333333 0. 0.26666667] [11.5476885] [2.]
Но, вы можете видеть, что результат также очень похож на реальный, потому что x
данные не показывают достаточную разницу.
Теперь я могу просто сказать, что вам нужно больше возможностей данных, чтобы получить достаточное обучение.