端计算 Walle:2235 亿次运算,为了无法计算的端智能价值(二)

阅读数:2 2020 年 1 月 7 日 18:05

端计算Walle:2235亿次运算,为了无法计算的端智能价值(二)

面临的挑战

今年我们加大投入,并联合了算法团队、搜索推荐工程团队、手淘基础链路团队,共建端计算的工程体系。随着端计算体系承载的业务数量与复杂度的快速增加,也对 DAI 等基础设施提出来了更多更严峻的挑战。

▐ 研发效率

初期的设计是算法同学通过控制台下发 TensorFlow 的 pb(protobuffer) 模型文件,所有的逻辑均在 pb 的网络结构中实现。这种模式下,存在如下一些不足的地方。

  • 由于端侧集成的为精简版 TF Mobile ,算法同学编写的 TF 代码在端侧可能存在缺少算子而跑失败的情况。
  • 新增或修改 Op 需要 Native 发版实现,周期长。
  • if、for 等流程控制在 TF 中难以处理。
  • TF 的端侧推理耗时较长,业务决策响应不及时。

▐ 稳定性

Android 出于包大小和动态性的考虑,采用了动态下发并加载动态库的模式。但是由于 Android 设备的碎片化,动态加载存在着诸多兼容性的问题,测试也不好验证。同时 JavaScriptCore 本身在 iOS 上是个黑盒,曾在 iOS9 上就出现过大量的 JavaScriptCore 的 Crash 问题。而端计算作为算法处理的基础设施,每日被调用的次数非常庞大。所以任何一个极小的不稳定因素,都有可能被放大。

并且端侧的故障,大部分是由于线上配置发布引起的。手淘对于线上变更有着严格的安全生产流程,涉及发布窗口、验证、灰度、观察等各个环节。而算法同学往往对端侧的指标不熟悉,一些潜在风险未必能及时发现。我们需要在各个环节加强完善设施能力,在风险发生前及时暴露,在发生中将影响减至最低。

▐ 任务治理

在年初的时候,我们进行了一次线上业务梳理。发现手淘环境中有 5+ 的特征提取任务、4+ 的曝光任务。很多基础的数据特征,在不同的业务场景下都需要使用到,且对于同一特征的加工方式往往相识。若所有的特征均由各业务方自行进行加工,难免会造成开发成本及端上计算成本的浪费。而且无法高效地将已有能力复用到更多业务和 App 上。

▐ 场景覆盖

在端计算模式快速发展中,我们关注到部分业务域虽然不具备算法资源,但是希望借鉴端计算的思路,在一些输入因素相对比较固定的场景下,对用户特定的行为进行快速的响应与干预。同时初期 DAI 的触达能力比较单一,仅将执行结果以广播的方式通知到业务方,由业务方自行实现通知后的触达响应逻辑。而一些常规的触达途径,在大部分业务域都是相识的。比如 Push、Poplayer(浮窗)、触发其他模型任务联动等。在这个环节需要有一套统一的多样的触达机制,满足不同场景不同定制。

本文转载自淘系技术公众号。

原文链接: https://mp.weixin.qq.com/s/V2QrhvW-F8asXvtyg7i0XA

评论

发布