做网站站长一年能赚多少钱,办个网站需要多少钱,手机版网页游戏在线玩,wordpress七牛云插件目录一、算法计算逻辑举个直观的例子销量预测二、项目背景三、算法与业务的关系四、关于业务人员对未来外部变量“打标签”#xff1a;五、关于预测颗粒度#xff1a;六、关于预测准确率和影响准确率的因素#xff1a;一、算法计算逻辑
销量预测算法建模要用到的数据#…
目录一、算法计算逻辑举个直观的例子销量预测二、项目背景三、算法与业务的关系四、关于业务人员对未来外部变量“打标签”五、关于预测颗粒度六、关于预测准确率和影响准确率的因素一、算法计算逻辑
销量预测算法建模要用到的数据
观测变量Y某个产品的销量数据 外部变量X促销活动、以旧换新活动、节假日、疫情影响可以是任何影响产品销量的变量但是前提是可以持续被量化
算法就是要根据这些数据去建模建立一个模型。不管是统计学模型、机器学习模型或是人工神经网络模型。通俗来讲建模的原理可以概括为
历史数据去拟合一个函数式Y F(X)用历史数据输入模型去拟合找到最优参数使得将所有数据代入到这个函数式计算出来的误差最小。
举个直观的例子
为了方便直观理解举一个机器学习里面最简单的例子线性回归。预测某城市的房价不是预测房价走势影响房价的因素有距离市中心的距离是否学区房周边配套情况房子面积等等。我们只考虑最简单的情况假设我们不考虑时间因素房价走势只考虑 “面积” 这一个因素。
房价YF(面积X)房价Y F(面积X) 房价YF(面积X) 并且假设房价与面积是线性关系得到 YkXbY kX bYkXb 接下来我们就要用我们已有的数据面积——房价 我们的算法模型Y kX b 但是k和b是未知的如何确定k和b呢
答案就是用我们已有的所有数据去试不断尝试不同的k和b的值并不是“瞎试”是通过一种最优化的寻找方式使得找到的k和b代入公式能让所有数据拟合的平均误差最小。这个过程也成为模型训练直观来讲就是我们把数据X与Y的关系画一个散点图Y kX b是一条直线k和b可以唯一确定一条直线。模型训练的过程就是找到一条对所有数据拟合最好的直线。
注理解了这个过程就能很好的理解为什么我们用的电脑被叫做“计算机”它最初就是为了帮人类解决复杂计算的而诞生的。一些复杂的关系靠人工写不出表达式的关系都可以借助计算机算出来供人类直接使用。 当训练完成后我们得到了一个确定模型Y kX bk和b是已知的我们要预测房价只需要输入
面积——X就可以计算出对应的房价——Y。
销量预测
刚才举的例子是算法建模中最简单的。实际业务中要复杂得多。考虑的变量需要拟合的参数也更为复杂并且它也不可能是简单的线性关系。下面我们回到我们要做的产品销量预测中
观测变量Y某个产品的销量数据 外部变量X促销活动、以旧换新活动、节假日、疫情影响可以是任何影响产品销量的变量但是前提是可以持续被量化
对于我们的销量预测来讲要用历史销量订单数据去拟合一个函数式F(变量)找到未来销量、历史销量、外部变量之间的关系它的函数式长这样
Y(ti)FY(t−i)X(ti)i1,2,3.....Y(ti) FY(t-i)X(ti) i 1,2,3..... Y(ti)FY(t−i)X(ti)i1,2,3.....
未来的销量Y(ti)F(历史一段时间的销量Y(t−i)未来一段时间外部变量X(ti))未来的销量Y(ti) F(历史一段时间的销量Y(t-i)未来一段时间外部变量X(ti)) 未来的销量Y(ti)F(历史一段时间的销量Y(t−i)未来一段时间外部变量X(ti))
同样当我们的建立的算法模型训练完毕后就相当于得到了一个确定的关系式。接下来计算未来的销量Y(ti)只需要输入
历史一段时间的销量Y(t-i)未来一段时间外部变量X(ti)
就可以计算出未来一段时间的销量。
根据不同产品的数据特点采用了以下算法模型
Arima可以拟合趋势、季节可以输出预测区间估计ExponentialSmoothing可以拟合趋势、季节模型稳定性强Coston专门用于间歇性需求预测。Prophet可以拟合趋势、季节同时还能考虑多个外部变量的影响可以输出预测区间估计。
二、项目背景
供应链管理是所有跟实体经济相关的企业遇到最具有挑战的问题之一。公司现有供应链计划有待优化。 引入算法预测终极目标代替业务人员预测为业务解决库存短缺和过剩的问题。当然这不是一蹴而就的需要数据、算法和IT流程不断完善以及业务人员的建议和反馈。
现阶段算法预测作为只能作为辅助为业务人员提供数据参考。并且需要业务人员的反馈和建议反过来去完善算法。
现阶段引入算法预测的目的是为人工决策提供一个参考并不是直接立马取代人工预测并不是直接按照算法预测值做生产计划。
现阶段做供应链计划的总的思路“从数据开始由判断结束”。尽可能减少数据与业务之间的信息不对称。
算法工程师距离数据最近具备数据分析和挖掘能力可提供相对客观数据分析但是拿到的只有数据不懂业务和市场销售负责人距离市场近懂业务但是容易受到市场波动和业务业绩指标压力的影响层层批报充满博弈容易加剧“牛鞭效应”。简而言之就是公司大了有数据的没判断有判断的没数据。目前算法预测的数据是根据历史销量历史需求量预测的输出的预测数是未来的需求量不能直接用于生产计划参考。需要减去现有库存加上安全库存才是理论上生产的数量最后还需要参考最小生产批量才能最终确定生产多少。需求预测的完整流程算法根据历史数据建模得到一个预测数给到销售负责人然后销售负责人根据自己多年业务和市场经验给出自己的判断即在算法给出的预测数的基础上进行一定的调整。
打个比方算法预测某个产品下个月的需求量大概是1000台但是销售的负责人知道上个月这个产品只卖几天就卖断货了没库存了导致上个月卖得少还有好几个客户想买在等库存。所以上个月的销量并不能真实的反应市场实际需求。预计下个月销量会有50%的提升所以最后调整下个月的需求量为1500。现有库存是0安全库存是500所以理论上需要生产1000150%- 0 500 2000台。但是这个产品的最小生产批量是2200所以最终确定生产2200台。 三、算法与业务的关系
算法永远是为公司业务服务的。现有“从数据开始由判断结束”思路是为了减少数据与业务之间的信息不对称。 关于算法预测值为2000人工预测为3000这是很正常的。算法预测的目的并不是要往人工预测方向靠拢毕竟人工预测如果足够准确那么公司也不会增加算法预测。衡量算法预测值是否准确的并不是人工预测值而是实际需求值。这并不意味着算法与业务是对立关系恰恰相反在“需求预测”不断完善的过程中二者是相互合作相互依赖的关系最终还是服务于业务优化公司供应链计划。
四、关于业务人员对未来外部变量“打标签”
只需要打未来人工已知可以确定的变量。比如促销活动这种对应的业务人员是知道未来一段时间内是否有促销计划。对于节假日这种标签是不需要打标签的算法建模前可以直接从万年历获取。 需要主要的是外部变量并不是却多越好这可能听起来跟人的常识相违背。原因如下
建模用到的外部变量要准确对应历史数据并且是对历史事件的客观反应。数据量不够大的情况下过多的外部变量。反而会降低模型的泛化能力导致模型“过拟合”考虑的外部变量要能持续被量化。
比如疫情这个外部变量对经济影响很大对产品销量同样很大。但是如何量化一个销售区域的疫情严重程度。人工可能觉得很简单觉得网络信息这么发达网上一查就知道。但是实际上人能看得到的文字视频计算机并不认识。说到这里你可能会觉得那也简单现在网上可以查到每个省份每天的新增、治愈、死亡病例。用这些数据计算机不就能看懂了吗其实不然一个销售区域包含多个省份每个省份人口基数人口密度经济实力医疗条件都不一样每个省份对我司产品的贡献值也是不一样的并且疫情从爆发到现在我国防疫能力防疫政策都是一个动态变化的过程像国外的疫情已经是躺平政策官方已经不在统计疫情相关数据。
所以战争因素、政治因素、疫情因素它本质上是通过影响经济因素去产品销量的。这个东西是很难被量化的。退一步来讲即便我们找到了最客观最合理的手段去量化它也很难提升预测的准确率甚至有可能降低准确率。因为我们是预测未来的销量我们用考虑这个外部变量就要知道未来几个月这个变量的值。如果我们强行考虑这个外部变量那就需要自己去预测这个外部变量它在未来几个月的值是多少这就意味着又回到了人工预测未来了。
五、关于预测颗粒度
现有的颗粒度如下
产品颗粒度同一个A箱。区域颗粒度所有区域总量不单独预测渠道。时间颗粒度按照月份聚合数据。
算法在销量预测开始前首先需要考虑的就是在合适的颗粒度上做预测。通常要考虑的颗粒度有时间颗粒度产品颗粒度区域颗粒度……
一般来说会优先考虑在颗粒度大的地方做预测其背后逻辑是颗粒度越大需求聚合效应越明显从数理统计来讲可预见性就越强数据模型就越可靠。公司销量数据特点表现为类似与“长尾商品”销售数据的特点即为间歇性需求大多数商品一年当中有需求的月份不到6个月。之前区域颗粒度细分到销售小区每月需求量为0的比例高达70%以上 对于区域A、B、C、D这种需求过于稀疏序列是几乎不具备可预测性的。必须进一步加大预测的颗粒度聚合数据。
当然这并不是越大越好。具体在哪个颗粒度上面做预测是由业务决定的一般来讲是业务能接受的最大颗粒度。对于一个实际项目来讲颗粒度不是越大好的原因如下
不同性质的产品是不能聚合在一起的。如果一个产品在不同渠道的销售策略促销活动相差很大是不能聚合在一起的做预测的。否则外部变量量化难度大。颗粒度越大对于业务人员来讲参考性越弱。对于某一个销售大区区域的负责人如果给到所有销售区域的预测总数那么这个总数对这个销售大区区域的负责人的参考意义是不大的。时间颗粒度越大数据量越小。如果按照季度或者每年的数据去聚合那么得到的数据量会大大减小。
六、关于预测准确率和影响准确率的因素
所有算法从业者都知道算法行业里有一句很经典的话数据和特征决定了机器学习的上限而模型和算法只是逼近这个上限。
如果把数据建模的过程比作烧饭做菜的过程。那么算法工程师扮演的就是厨师算法服务的业务扮演的角色就是订餐的顾客。产品经理则是负责登记顾客需求和传达需求的中间人相当于店小二提供相关数据的数仓人员就相当于提供食材的采购。一个完整的项目大概需要经历以下过程:
首先第一步要做的就是要确定做什么菜店小二拿登记顾客需求后。登记顾客要吃哪些菜每个菜在口味上有什么要求整理成需求清单后然后给到厨师。产品经理将需求文档给到算法厨师根据店小二的需求清单确定需要哪些食材列一个清单给到采购。算法根据需求文档输出一个设计文档其中包括了需要获取哪些数据给到数据组采购将食材给到厨师厨师开始烧饭做菜。算法拿到数据后开始建模烹饪完毕后店小二将做好的饭菜给到顾客。开发完毕后给到业务验收
单从预测准确率上来讲
首先是要有数据不然“巧妇难为无米之炊”。其次是拿到的数据质量要高。如果ERP系统中存在大量的错误记录、对应关系、脏数据以及业务人员不规范操作。数据建模注定是“垃圾进垃圾出”。最后是算法工程师的专业能力和对业务的了解程度。
