作者回复: 是的,大量特征还是从hdfs或者一些数据仓库中去取的。这些特征因为不用高频更新,我想通过分级存储供线上使用就好了,比如高频用户的年龄特征放到redis里面,这应该不会影响线上服务效率。
作者回复: 模型中加入曝光次数,或者根据曝光次数训练一个decay函数跟模型融合。
作者回复: 嗯嗯,再解释一下端到端。这里跟端上数据没关系,指的是训练完后,不用经过任何诸如拆分啊,提取特征和参数啊之类的特殊步骤,训练完直接部署,不用做什么改变。 这里的端到端是这个意思。
作者回复: 效率上讲肯定是1比较高效一些,但需要比较大的改动。2方便部署,确实比较浪费资源。如果可以投入比较多的时间精力,我建议去研究一下方法一,特别是在有大量embedding数据的时候,甚至可以把embedding从模型中单独提取出来,这样可以大幅减小模型大小,提高部署和serving的速度。
作者回复: 你的问题很好,但我觉得估计不好找到很高质量的资料,因为都是业界的一些工程手段。 我理解你说的流量控制应该是指对不同用户使用不同的模型或者策略生成推荐结果是吧?这是一个很好的降低复杂模型qps的角度,但我觉得更多是一个工程问题,需要你在实践中摸索总结。
作者回复: 我记得jpmml的官方文档上有描述相关的过程,基于我们的java server就可以实现这一过程。 我在我的项目 https://github.com/wzhe06/CTRmodel 中也有一些相关的部分,可以参考。
作者回复: 1.模型更新频率其实是根据你的观察确定的,比如有的公司模型可能一周才更新一次,因为发现提高更新频率也对效果没什么影响。 有的公司可能需要做实时训练,比如我知道国内某主流电商团队,更新的频率在20分钟级别。 所以根据你自己的测试结果调整,一般天级别的更新是可行的。 2. 是的。TensorFlow serving本身在高并发下有一定的性能问题,有一些坑,我知道各一线团队都在进行一些魔改。
作者回复: 一般来说原生的tfserving是肯定有延迟问题的。ps一般来说更轻量级,但很多模型也不好支持。总的来说serving是一个非常复杂的工程问题,没有银弹。
作者回复: 没有好的解决方法,tf-serving的效率问题是业界非常棘手的问题,建议持续关注业界公布的一些tf-serving优化方案,虽然非常少。。
作者回复: 不是特别理解这个需求。tensorflow是离线的,spark集群也是离线的,为什么要把tensorflow模型部署到spark集群呢?