阿里前端智能化技术探索和未来思考

发布时间：2022-08-28 00:00

未来十年，智能化将不断渗入各领域，改变我们的生活和工作。本文将会分享阿里前端智能化技术的技术实践，探索未来UI智能化的发展方向。

最近看到一个研判：过去十年是智能化蓬勃发展的十年，但未来十年会是智能化渗入各领域不断改变我们生活和工作的十年。对此深以为然。

随着对神经网络加速的专用处理器成为硬件标配、DSP越来越多地从专业领域进入消费电子领域、CPU厂商收购FPGA公司、4nm工艺和3D堆叠工艺以及单周期多指令发射等处理器运算能力的机制提升让PPA不断突破极限，即将把围绕智能化的技术变革推向高潮。

作为立足于改变前端技术工程体系的一群阿里前端，我们期待走在最前沿。从谷歌 TensorFlow团队的合作，到顶会论文的发表、技术雷达收录，再到多项成果在集团乃至行业大范围推广和落地取得成果，阿里前端智能化小组始终在坚定前行。在这篇文章中，我们将从阿里前端智能化整体技术大图中挑选一些有实质突破的部分，分享我们的研究、实践过程。期待和更多前端同行一起参与到前端智能化方向的探索，把这个方向建设的更丰满、更实在、更普惠。

阿里前端智能化技术大图

文章框架（注：内容较多，可直接滑到感兴趣的部分阅读）

前端智能化技术基座：数据和算法技术工程能力是升级的基础
端智能：通过对端智能的介绍，帮助大家把数据能力和算法能力真正应用到前端技术场景
前端智能化技术应用
未来UI 智能化的发展趋势

前端智能化技术基座篇

2021~2022 年是PipCook项目明显变化的一年，在这之前，PipCook更多的是做一个JS社区易用的深度学习的工程框架，很多时候忽略了和业务的结合，也忽略了数据本身的价值。今年，PipCook重点依托于cloud云平台打通业务数据链路，赋能前端数据能力，同时基于datacook提供的分析建模能力深度剖析业务数据，在围绕消费者体验问题上紧扣业务，建立起数据指导迭代的链路，为业务提供价值。

▐ PipCook-Cloud 增强前端数据分析和智能化算法能力

在传统产研结构中：产品经理、设计师、运营、商务、服务端、客户端、前端、测试、BI 等诸多角色中，前端一直是职能角色间接参与业务，对业务的发展无直接影响。但是要为业务提供增长，前端作为将价值输送给用户的桥梁，必须要体系化且深入本质的理解商家与消费者的关系，在平台视角、生态视角之上叠加用户视角，建立起用户运营技术赋能的途径和手段，并将之与商家运营和平台运营、生态运营有机结合在一起。

在这种要求下，数据分析和基于数据的建模能力将会至关重要，我们希望可以通过Pipcook-Cloud这个项目增强前端数据分析和智能化算法能力，逐渐将技术产出、用户使用行为数据以及业务指标三者关联在一起。通过三者关联的指标，逐步系统化和逻辑严谨的描绘出一副从业务目标到产品设计再到技术交付和用户体验的完整图画，在这张图画上指标驱动和数据支撑让用户运营能力有了技术支撑，让产品交付价值有了用户体验指标度量，让前端在业务全生命周期中有了完整的用户价值和情感连接的桥梁。

而目前我们的大数据开发主要是围绕着DataWorks相关工具进行的，开发语言以ODPS SQL为主，同时也可以开发基于Python和 Java的UDF (用户自定义函数)。对于一些数据模型的开发需求，可能也会基于PAI平台进行。当前基于ODPS SQL、Python和Java的开发方式对于前端同学成本有点儿高，原因主要有两个，一方面是有一定的入门门槛，包括语言门槛，处理逻辑编排的门槛，以及对于数据本身理解的门槛，另一方面前端缺乏对于常见的业务数据分析经验(端上用户行为动线分析，人群分成行为分析，前端性能分析，用户点击热力图分析等等)的沉淀，导致很难直接复用一些常见的前端场景的数据分析能力。

同时，目前的报表和数据可视化工具主要面向的人群为BI、运营和数据PD，通过可视化配置数据源和拖拽图表组件的方式搭建报表。对于前端同学来说，一方面，这种方式缺乏灵活性，只能使用准备好的图表组件和能力，很难拓展和自定义跟适合自己业务的报表，而前端恰恰在可视化能力上有天然优势，另一方面，也很难通过模板等方式向用户提供我们沉淀的前端数据分析场景的可视化报表。

基于以上原因，PipCook-Cloud聚焦于前端数据能力和用户体验和用户增长分析能力，在今年主要解决了以下几个方面的问题：

让前端同学理解数据开发可以做什么，可以为业务带来哪些价值
想要前端同学可以入门数据开发，第一步需要先让前端同学明白数据开发可以做哪些事情，同时，能发现业务数据分析确实可以为业务带来价值，这样一来用户才有了入门和使用PipCook-Cloud的动力。
让前端同学清晰明确的编排自己数据开发的全流程，以完成开发目的
就如同在编程一个系统的时候，需要先对系统有一个设计，可以借助于流程图，ER图等工具来完成系统设计，同样地，在编写一个数据开发链路的时候，我们也需要先有一个设计，清楚的表达和编排出整个数据流。
让前端同学在编写数据处理的逻辑的时候，可以低门槛无成本的实现
一般大数据系统开发的语言都是SQL和Java，如果可以实现基于JS的数据处理系统，那么对于前端同学实现自己的处理逻辑的门槛将会大大降低。
让前端同学在需要一些必要的机器学习模型能力的时候，可以快速完成
在有些场景下，并不能通过确定性的逻辑实现自己的数据分析任务，有的时候需要借助于模型能力挖掘出数据中的模式。
让前端同学基于数据可以轻松开发出业务报表，以阐述自己的结论，帮助业务理解
数据分析的最后一步就是产出结论，很多时候需要业务报表和图表的方式来清楚的阐述数据分析的结论和后续action。

我们在1.0，一直努力将PipCook变成：让前端工程师也能开发靠谱的机器学习应用；而在2.0，我们对此做了稍微的变化：让前端工程师都能开发靠谱的机器学习应用。

在过去一年，我们继续深耕于PipCook提供的深度学习的CI/CD能力，提供模型训练和数据分析的可持续集成和交付，PipCook 1.0的版本让Web开发者能够以比较低的门槛开始深度学习之路。而在实践的过程中，我们也发现了一些问题，比如安装 PipCook比较困难，安装时长长，初次启动训练时PipCook会安装插件也会耗费大量时间，另一方面，也有配置难、不易上手等问题，基于这些问题的解决，我们推出了 PipCook 2.0，目前这块也已经开源 [08]。

▐ DataCook 提升数据分析和处理能力

如果说PipCook-Cloud打通了前端和业务数据的桥梁，通过平台化产品化的方式提供了数据加工和数据开发的工程能力，那么DataCook则是在底层供给PipCook平台的燃料。DataCook提供了JS生态下面向前端的数据科学和机器学习工具库，帮助前端同学轻松运用分析建模能力剖析自己的业务数据，产出具有价值的分析成果。

目前DataCook已经涵盖了包括数据预处理，数据统计分析，机器学习，可视化和跨平台流程部署等多项能力，提供了诸如线性回归，逻辑回归，决策树，PCA等多个模型，方便在各种场景下的建模分析，DataCook目前也已经开源 [09]。

端智能篇

去年，淘系开始发力消费者体验。基于个性化消费场景，构建探索性货品供给、智能化信息表达，是端智能发力的机会。端智能立足于实时性、隐私保护性的基础上提供智能化能力，让前端能够用这些技术手段不断优化消费体验。

过去三年，我们和Google的TensorFlow.js团队在推动前端智能化在端智能应用方向上达成战略合作。前端技术标准组织W3C也密集推出WebCL（见《OpenCL 2.0 异构计算》第三版）、WebGL、WebGPU、WebNN、WASM等前端端智能加速技术，尤其是2022年推出的Web Neural Network API，针对神经网络、张量和图计算加速。摘自：https://www.w3.org/TR/webnn/

比起客户端，前端算力并未被彻底释放。从CPU上来说，虽然WASM的支持率已经高于很多JavaScript的新特性了，但是SIMD指令的支持率仍然较低。WASM虽然比起JavaScript有优势，但是跟JavaScript+WebGL比起来，因为完全发挥不出CPU的优势，造成运算资源的浪费。WebGL仍然是十几年前的技术，跟OpenGL ES是同一个年代的技术，不支持GPGPU的操作。虽然有 WebGL2支持计算管线，但是因为苹果不支持这部分功能，导致无法使用。而 WebGPU可以从caniuse网站上看到，桌面上浏览器在2018-2020年都已经开始支持WebGPU，移动版浏览器也在跟进。

所以我们2021年选定了两个方向来优化我们的端上引擎：WASM+Rust+SIMD和WebGPU。TensorFlow.js虽然没有使用Rust，但是也在使用WASM+SIMD。

▐ WASM + RUST + SIMD

摆脱了Javascript，使用native语言编写WASM，首先的问题就是选择哪个语言。在2021年，Rust在Nightly版本实验性支持了SIMD，成为我们目前最好的选择。

▐ WebGL/WebGPU

下面我们用一个实际例子看看如何在浏览中，借助TensorFlow.js的技术生态把算法模型在纯W3C标准下跑起来，并且通过WebGL对模型预测进行加速。为了能够把神经网络在浏览器里跑起来，并让JavaScript可以调用，首先需要将神经网络存储成文件。

model.save('saved_model/w4model')

存储到目录后会得到两个文件：keras_metadata.pb和saved_model.pb以及两个目录：assets和variables。这里使用的是TensorFlow的tf_saved_model，下面转换模型给TensorFlow.js在浏览器使用的时候会用到这个参数。

为了能够让模型在浏览器运行，先安装pip install tensorflowjs用 tensorflowjs_converter命令行转换工具进行模型的转换：

tensorflowjs_converter --input_format=tf_saved_model \
--output_node_names="w4model" \
--saved_model_tags=serve ./saved_model/w4model ./web_model

这里--input_format参数tf_saved_model对应之前模型存储使用的方法，要注意不同方法保存的文件格式和结构的不同相互不兼容。--output_node_names是模型的名称，--saved_model_tags中tag是用来区别不同的MetaGraphDef，这是在加载模型所需要的参数其默认值是serve。

通过tensorflowjs_converter进行模型转换后，我们在web_model文件夹里会看到group1-shard1of1.bin以及model.json两个文件。这两个文件中，以.json后缀结尾的文件是模型定义文件，以.bin后缀结尾的文件是模型的权重文件。您可以把模型定义文件看做4PL和多项式的函数，把模型权重文件看做函数的参数。

通过npm初始化一个node.js项目，然后在package.json配置文件里加入：

"dependencies": {
    "@tensorflow/tfjs": "^3.18.0",
    "@tensorflow/tfjs-converter": "^3.18.0"
  },

这里的@tensorflow/tfjs是TensorFlow.js提供的运行时依赖，而@tensorflow/tfjs-converter则是加载我们转换的模型所需要的依赖。接下来，在EntryPoint的JavaScript程序文件里加入：

import * as tf from "@tensorflow/tfjs";
import { loadGraphModel } from "@tensorflow/tfjs-converter";

将依赖引入到程序文件中，这里要注意loadGraphModel是我们从@tensorflow/tfjs-converter依赖中导入的，虽然@tensorflow/tfjs提供 tf.loadGraphModel()方法加载模型，但是这个方法只适用于TensorFlow.js中保存的模型，我们通过Python里model.save()方法保存，并用Converter转换的模型，必须用tfjs-converter依赖包中提供的loadGraphModel方法进行加载。

接着是程序完整的代码：

import * as tf from "@tensorflow/tfjs";
import { loadGraphModel } from "@tensorflow/tfjs-converter";
window.onload = async () => {
  const resultElement = document.getElementById("result");
  const MODEL_URL = "model.json";
•
  console.time("Loading of model");
  const model = await loadGraphModel(MODEL_URL);
  console.timeEnd("Loading of model");
•
  const test_data = tf.tensor([
    [0.0],
    [500.0],
    [1000.0],
    [1500.0],
    [2500.0],
    [6000.0],
    [8000.0],
    [10000.0],
    [12000.0],
  ]);
  tf.print(test_data);
  console.time("Loading of model");
  let outputs = model.execute(test_data);
  console.timeEnd("execute：");
  tf.print(outputs);
  resultElement.innerText = outputs.toString();
};

这里需要注意的是，由于我们的模型在预测时使用的是张量作为输入，因此，需要用tf.tensor()方法来返回经过包装的张量作为模型的输入。运行程序后，我们可以从浏览器开发者工具的控制台看到打印的调试信息：

[Violation] 'load' handler took 340ms
index.js:12 Loading of model: 67.19482421875 ms
print.ts:34 Tensor
    [[0    ],
     [500  ],
     [1000 ],
     [1500 ],
     [2500 ],
     [6000 ],
     [8000 ],
     [10000],
     [12000]]
index.js:28 execute: 257.47607421875 ms
print.ts:34 Tensor
    [[-1.7345995 ],
     [90.0198822 ],
     [159.9183655],
     [210.0600586],
     [260.0179443],
     [347.4320068],
     [357.5788269],
     [367.5332947],
     [377.4856262]]

这里加载模型花费了 67ms，执行预测花费了 257ms，还是蛮长的。

import * as tf from "@tensorflow/tfjs";
import { loadGraphModel } from "@tensorflow/tfjs-converter";
window.onload = async () => {
  // 新加入 webgl 硬件加速能力
  tf.setBackend("webgl");
  console.log(tf.getBackend());
  // 打印当前后端信息
  const resultElement = document.getElementById("result");
  const MODEL_URL = "model.json";

我们会看到控制台输出webgl代表TensorFlow.js成功启用了WebGL的加速能力，在其加速之下，我们在预测的时候速度会从257ms大幅度提升到131ms，多次预测时间由于权重和计算图已经加载到显存中速度会更快，达到78ms左右。

放眼未来，不管多困难，我们会继续推进基于WASM+SIMD/WebGPU引擎的落地、投入支持WebXR尤其是AR。其实，AR本质上是个机器学习问题。改名Meta的Facebook公司正在训练比GPT-3还大的模型，用于理解AR情况下的文本、图像和语音。模型训练出来了，如何在手机上落地进行推理，将是对前端智能化的重大考验，也是我们研究和储备技术的重要方向。

前端智能化技术应用篇

▐ 应用1：代码推荐-sophon

2019年，学术界以深度学习为代表的机器智能技术在不断突破，在工程界又有TabNine, aiXCoder在内的优秀的代码推荐服务涌现，但开始它们还都依赖于云端服务，对于代码安全不太友好，所以我们基于智能化的实践和探索做了一版前端代码推荐插件Sophon Code IntelliSense [10]，期望通过代码补全代码的方式提升前端同学的研发效率。整个2021年，我们在C2C方向继续艰难爬坡。除了在深入优化模型，今年还花了很大气力完善整个工程基建、代码智能相关知识宣传和跟踪业界最新动态。

代码数据资产管理