月落庭柯
TA的个人档案
个人介绍
好好学习，天天向上。
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2020-04-30
机器学习领域技术大图：硬件算力
AI 集群旨在获得更高的 AI 集成算力，扮演着“承上启下“的角色，“承上”是指向 AI 应用提供的有效集成算力，高集成算力是支撑 AI 大模型和海量数据量的使能能力。而“启下”是指通过集群的计算、网络、存储平衡设计来充分发挥 AI 计算芯片能力，例如访存或网络瓶颈都会导致较低的 AI 芯片效率。AI 集群设计的关键在于：1）单机：计算优化，软硬件协同优化发挥 AI 加速器有效算力。2）多机：通信优化，最小化多机数据交换引入的计算效率损耗。我们将从单机加速和集群加速（多机）两个方面介绍相关技术和系统。 首先，我们将从计算和互联两个技术点对阿里现有的技术栈进行全面的阐述。 计算技术 神龙服务器和神龙虚拟化技术 在阿里云神龙硬件平台下，虚拟化架构也做了相应的升级，使计算虚拟化部分的架构更加清晰简洁，让虚拟机能提供接近物理机的性能。如图所示，神龙服务器架构的主要特点是：I/O 链路从传统的软件实现转变为硬件和直通设备来实现，存储虚拟化、网络虚拟化都在 MOC 卡上来实现；同时将管控系统、监控程序等都下沉到 MOC 卡上。在提供计算服务的物理机上，只运行阿里云自己裁剪的 Linux 操作系统和轻量化的虚拟机监控器。总的来说，神龙硬件平台的底座，加上轻量化的宿主机 OS，再加上轻量化的虚拟机监控器，就组成了神龙架构下的轻薄且高效的新一代虚拟化平台。 GPU CPU 执行 AI 计算往往并不能达到最优的性价比，因此，具有海量并行计算能力、能够加速 AI 计算的 AI 芯片应运而生。当前最具代表的是 GPU、FPGA 和 AI ASIC 芯片。GPU 仍然是当前最成熟也是最广泛使用的加速器，阿里巴巴上层框架针对 GPU 做了大量的编译优化工作。GPU 在阿里巴巴得到了广泛的部署，也是云上 AI 算力售卖的主力，我们已经能做到基于 GPU 的云产品与最新一代 GPU 同步发布。在云上 GPU 的安全性，可运维性，用户体验上我们都走在业界的前列。在于通用计算可运维性在 GPU 虚拟化场景下的热升级能力，居于业界第一；是业界首个发布基于 SRIOV 的 GPU 热迁移技术预研的云厂商。在业界首个实现基于 GRID 的 vGPU 技术在云上输出，引导了 vGPU 云化的技术趋势，并且为 5G 时代的云游戏铺垫了 GPU 计算基础设施。 GPU 的训练芯片一直引领着 GPU 技术发展的趋势，除了基础 FP32 算力的高速增长之外，通过精度的变化大幅度提高算力，比如 Tensorcore 是另外一个算力提升趋势；另外，由于多卡，多机的通信的需求，GPU 的通信经历了 PCIE P2P 技术，基于 NVLink 的高速通信技术，以及通过 RDMA 网络的 GPUDirect RDMA 技术。而在阿里云上，由于多租户之间需要进行算力共享，在不同的通信模式下，如何进行算力分割和通信的隔离，是一个阿里云一直研究的技术，包括最新的基于 NVSwitch 的 NVLink 全连接场景下的可编程拓扑分割技术等。 FPGA FPGA 器件自诞生之初，就以高度灵活的可编程性提供类 ASIC 的性能和能效比而广泛应用于有线和无线通信、航空航天、医疗电子和汽车电子等领域。但是，相比 CPU 和 GPU，FPGA 的开发周期较长（尽管只有 ASIC 开发周期的一半乃至三分之一）、开发和使用门槛较高，使得 FPGA 的开发人员远远少于 CPU 和 GPU 的开发人员，同时应用范围和知名度也受到了很大的限制。在 FPGA 上，我们具备了有更高的定制和自研能力，阿里云与 AIS 联合研发的业界第一款单卡双芯片的 Xilinx FPGA 板卡，在板卡和 HDK 层面实现了技术自主创新的能力。 舜天平台：FPGA 即服务 (FaaS) 云上的 FPGA 实例做了丰富的功能输出，阿里云 FaaS（FPGA as a Service）舜天平台在云端提供统一硬件平台与中间件，可大大降低加速器的开发与部署成本。第三方 ISV 加速器 IP 可以迅速形成服务提供给用户，消除加速技术与最终用户的硬件壁垒。用户则能够在无需了解底层硬件的情况下，直接按需使用加速服务。为了给加速器提供方和使用方提供更加高效、统一的开发及部署平台，FaaS 舜天平台提供两大开发套件：HDK 和 SDK。FaaS 的逻辑架构图如下图所示： FaaS FPGA 逻辑架构图 阿里云 FaaS 舜天平台支持最全面的 DMA 技术，包括：DMA、XDMA 和 QDMA；同一架构支持 RTL 和 HLS 开发、验证与测试；全球唯一的同一软件架构同时支持两大 FPGA 厂商 Xilinx 和 Intel 的云厂商。全面、过硬、兼容性好，并且能够利用 PR 技术进行动态热升级的Shell技术使得 FaaS 舜天平台成为阿里集团 FPGA 异构加速业务的基础设施，完全适配了集团的所有已经引入的 FPGA 器件，已经成功服务手淘、优酷、蚂蚁和云安全几大业务板块。 阿里云 FaaS 平台架构图 AliDNN 与 GPU 环境下，单向的软件适配硬件不同，FPGA 和阿里自研 NPU 给了我们定义硬件的机会，可以根据业务特征进行深度的软硬件优化。AliDNN 是一款基于 FPGA 的指令集、加速器、SDK 和编译器全栈自研的深度学习加速引擎。指令集加编译器设计为 AliDNN 提供了充分的灵活性。深度学习框架 (TensorFlow，Caffe 等)可以直接调用 AliDNN 引擎，编译器(震旦)将深度学习模型编译成加速器指令进行计算。算法， runtime，编译器和加速器的全栈软硬件协调优化，使得 AliDNN 拥有极致的效率和性能。AliDNN 提供了高吞吐、低延迟的深度学习推理服务。 NPU AliNPU（含光 800）更是分析阿里集团内部的人工智能应用场景需求，确定了以 CNN 模型为主做了深度的优化，同时支持一些通用模型，比如 RNN 类模型等。这是针对特定深度学习算法领域做特别的优化，把相关应用的性价比提高到极致，正式如此，含光 800 性价比远超竞品，成为全球最强 AI 推理芯片。 互联技术 RDMA RDMA 是目前业界最受欢迎的高性能网络技术，能大大节约数据传输时间及 CPU 开销，被公认为是提升人工智能、科学计算、分布式存储性能的关键技术。阿里巴巴基于全新的 HAIL 网络架构并结合自研交换机，打造了从主机网络、消息中间件、盘古分布式存储、网络运营到产品运营的完整技术体系，实现了数十个数据中心的全球最大规模 RDMA 网络部署，远超亚马逊、微软等主要云厂商。这张全球最大规模的数据中心“高速网”使得集群极大地突破了传输速度瓶颈，有效地支撑了云盘 ESSD、云超算 SCC、机器学习 PAI、 云原生数据库 POLARDB 这些广受欢迎的创新产品，并助力电商数据库从容应对双十一峰值流量考验。同时，可以跨 POD 的 lossy RDMA 技术已经在阿里巴巴进入实验测试阶段，届时将进一步扩大 RDMA 的适应范围。 EXSPARCL通信库 自研的EXSPARCL（Extremely Scalable and high Performance Alibaba gRoup Communication Library）集合通信库提供通用的集合通信功能，同时兼容 NVIDIA 的 NCCL。ExSparcl 专门优化支持大规模 AI 集群的高速互联架构和多网卡特性, 充分利用设备之间的互联带宽，保证通信和业务性能的线性扩展。通过对集群/主机物理互联的拓扑感知，和网络路由的最优选择，实现创新的无拥塞算法，确保节点内和节点间的高速通信。例如针对 SCC 训练集群架构，实现的Rank重映射 Havling-Doubling 算法，可以保障集合通信过程中没有因为路径冲突而产生的拥塞排队，在大规模环境中对比 NVDIA 公司的 NCCL 通信库，实现集合通信性能 (AllReduce/AllGather) 的数倍提升，对业务性能的提升也非常明显。此外，拓扑感知的特性可以用于故障规避，大大增强网络的可用性，详见：https://www.qbitai.com/2020/03/11987.html。 飞天AI加速工具（AIACC） 飞天 AI 加速工具通过统一的框架同时支持了 Tensorflow，PyTorch，MXNET，Caffe 这 4 种主流的 AI 计算框架的分布式性能加速，并且针对 VPC 网络和 RDMA 网络都做了很深入的性能优化，在不同场景不同训练规模下可以提升 1～10 倍的训练性能。同时， AIACC 和各 AI 计算框架是解耦的，一方面可以轻松支持各 AI 计算框架社区版本的向前迭代，另一方面，用户使用各 AI 计算框架实现的模型、算法代码基本上不用修改，就可以很轻松的获得性能加速。 FaaS 舜天可以支持 FPGA 芯片高速互联 (最高可达 600G) 阿里云与 AIS 联合研发的业界第一款单卡双芯片的 FPGA 板卡，AliFPGAx2，两块 FPGA 之间的 Serdes 的带宽可以高达 600G，在一台服务器上的两块 AliFPGAx2 的板卡，还可以通过光缆互联与高速 Serdes 互联。于此同时 FaaS F3 提供给用户强大的互联拓扑结构，方便用户搭建 FPGA 集群，实现 FPGA 互联，并且通过 FaaS 舜天的 Shell 提供高速 DMA 的软硬件支持。可以支持单卡 2 芯片互联，双卡 4 芯片互联和 8 卡 16 芯片互联，并且互联的通道可以通过软件灵活配置硬件的隔离分割，在云用户不同的拓扑需求之间进行互联和隔离。下图是典型的 2 卡 4 芯片互联拓扑结构。 在此基础上，阿里巴巴开发了适合不同应用场景的异构超算集群。 SCC：通用和异构超算集群 高性能计算是采用低延迟高带宽的计算节点构成并行计算集群，通过并行计算（Parallel computing）实现对浮点密集型科学和工程模型包括AI深度模型的求解。作为计算节点的神龙裸金属服务器通过 RoCE 网卡实现节点间计算的高速 MPI 通信，通过神龙 MOC 卡实现和 VPC，IO 和网络，云盘的互联。从而在输出超算水平的超级算力的同时，保持所有节点的“云原生”的弹性和统一运维。我们还开发了弹性高性能计算 E-HPC PaaS 平台，作为高性能计算软件栈创建和管理 SCC 集群，同时对有能力自建 HPC 平台的客户直接输出 SCC 集群。 SCC-训练集群：大规模AI训练集群 针对 AI 大规模训练的算力需求，阿里巴巴开展了从硬件到算法的一体化设计。从性能角度，集群设计的核心之一就是通过提升加速器间数据交互的能力，降低非计算开销占比，进而实现算力的规模线性扩展。因此，异构集群系统以优化通信为突破口，对服务器和整机网络架构进行重新定义，先从硬件上解除通信瓶颈，再通过软硬件协同，将增强的通信能力发挥出来，该部分的工作内部代号 EFlops，实现了 AI 训练的线性加速，相关成果在顶级学术会议 HPCA2020 上发布（https://www.csdn.net/article/a/2020-03-03/15988517），目前建设的系统单集群 AI 算力可达 500 PFlops（FP16 性能）。 此外，液冷是推动AI集群架构演进的另一股力量。由于功耗限制，当前一个机柜仅能容纳两台或四台 8 卡服务器，计算密度难以提升，而液冷则可以打破这个限制，一个 Tank 即可容纳 100 多块 GPU 卡，省电省地省光纤，提升稳定性。相应地，集群架构根据浸没式液冷 Tank 的尺寸和出线特点进行了重新设计，这一工作已进入实验阶段。 再次，在获得极致性能的同时，我们也兼顾在计算成本方面的优化，以及通用与异构算力解耦之后的灵活性。 异构硬件层虚拟化 阿里 IaaS 的 GPU 虚拟化技术是 AI 计算力上云的基础。阿里 IaaS 在对现有开源 GPU 虚拟化技术之上进行了二次开发，使得现有 GPU 虚拟化方案可以适合公有云对安全性，高可靠性与可监控等关键功能的提升。 在公有云 GPU 服务器的安全隔离方面，阿里云异构 IaaS 层完成了从实例内部的驱动的初步安全过滤，宿主机虚拟化层对 GPU 特权指令的过滤拦截，宿主机 PCIe 协议成的容错处理等三层立体防护体系，确保客户实例不受攻击，也没有可能攻击其他客户。 当前主流异构虚拟化还是以设备直通的方式存在，并在基础之上逐渐演化出 SRIOV， vGPU 分片虚拟化等最新技术。阿里 IaaS 依托现有 GPU 虚拟化技术完成了 AI 集群 (GPU/FPGA) 的云上规模化和产品输出。GPU 虚拟化走过了漫长的发展路程；经历了直通虚拟化，SRIOV 与 vGPU 的分片虚拟化，Intel 的 GVT-G 技术等等。 在通用计算时代，虚拟化的引入主要是为了提高 CPU 利用率，但是随着热升级，热迁移技术的引入，把计算资源的安全性，可靠性推到新的高度。在 GPU 资源利用率提升，计算资源碎片整理上，GPU 虚拟化技术也扮演着重要的角色。 在公有云 GPU 服务器的监控方面，阿里云异构 IaaS 层做了 GPU 相关的云监控方案，可以实时取得当前 GPU 的运行状态与温度，显存用量等信息，并可以自定义多种监控模式。GPU 自定义监控与 GPU 云监控插件。 在公有云 GPU 服务器的高可用性方面，阿里云异构 IaaS 层开发并部署了特有的 GPU 服务器热升级与热迁移功能。使得当实例所在宿主机需要系统软件更新/硬件维修等运维操作时，可以让客户无感的完成升级更新，从而保障了客户业务的稳定性与连续性。基于 SRIOV 和 GRID vGPU 的热迁移能力上，阿里云都作为业界第一梯队领先竞对。 异构 GPU 容器支持（cGPU 容器 AI 算力隔离技术） 云原生已经成为业内云服务的一个趋势，如何能够在云原生上支持异构计算，同时在单个 GPU 上可以运行多个容器并进行隔离，对此业界也做了很多探索。Nvidia vGPU, Nvidia MPS, 友商的 vCUDA 方案，都为用户更小颗粒度的使用 GPU 提供了可能。阿里云 GPU 团队推出了昊天 cGPU 方案，相比其他方案，这是一个颠覆性的创新。业内常用方案是通过替换 CUDA 库实现拦截，需要对静态链接的程序重新编译，同时 CUDA 升级时也需要适配新版本；而昊天 cGPU 在做到算力调度与显存隔离的同时，也做到了无需替换 CUDA 静态库，动态库，无需重新编译，CUDA，cuDNN 等版本随时升级无需适配。 cGPU 为自主研发的宿主机内核驱动。它的好处在于： 适配开源标准的 Kubernetes 和 NVidia Docker 方案用户侧透明。AI 应用无需重编译，执行无需 cuda 库替换针对 Nvidia 设备的底层操作更加稳定和收敛，而 CUDA 层的 API 变化多端，同时一些 Cudnn 非开放的 API 也不容易捕获。同时支持 GPU 的显存和算力隔离 现在基于阿里云 GPU 团队的 cGPU 昊天方案和容器服务的 GPU 共享调度双剑合璧, 可以打造低成本，可靠，用户友好的规模化 GPU 调度和隔离方案。 软件池化 EAIS.EI：资源调度层池化 EAIS 通过软件池化的方式将 CPU 核心数和后端异构加速设备解耦，前端的纯 CPU ECS可以动态挂载或者卸载后端异构加速设备，前端 ECS 和后端异构加速设备间通过加密的 gRPC 协议通信。后端加速设备可以包括 GPU，FPGA，NPU 等异构加速器，并且通过软件池化的方式进行统一调度和管理。 HARP：Runtime 层池化 做加速机群池化的主要目的，是想提高机群资源利用率。机群管理如 K8s 对加速资源管理手段非常有限，一般都是以直通（pass-through）的方式，以整卡的力度来分配。再者 CPU 和加速资源以整机形式，绑定资源分配，在实际应用中有很大资源浪费。而数据中心呈现去中心化发展趋势（disaggregation），从物理机到虚拟机，到虚拟网卡，到分布式存储，整机的各个部件逐渐以专用机柜的形式，以虚拟化，可配置（configurable）的方式通过网络组装。对比磁盘，加速资源跟通用计算之间联系更紧密，但是随着技术的进步，加速资源单独组机柜，通过网络或者其他互联（interconnect）的形式，对通用计算（CPU）加速，成为一个技术趋势。 Heterogenous accelerator resource pooling (HARP)，目前以 GPU 为主要加速资源，将来会扩展到 NPU 和其他加速硬件。通过在用户程序和 driver 之间，加一个中间层（目前为软件，将来可扩展为硬件），来实现加速资源的虚拟化，动态地为用户分配本地或者远程的加速资源，从而更好的管理和利用加速资源。 HARP 实现方式的优势为： 对上层应用透明，对运行环境无要求（物理机、容器、VM）均可 同时支持本地和远程的加速资源，本地模式下与直接使用 GPU 性能无差异 可以通过控制 API 来比较轻量化地在单卡复用情形下显存、计算资源控制 可以对上层应用隐藏底层硬件细节，自动化一些底层配置（本地物理 GPU／由 PCIE-switch 连接的另一台 host 上的物理机／vGPU／下一代 GPU 支持/Compute Instance) 可以实现一些额外的 profiling 功能，甚至生成一些可以 replay 的 trace HARP 资源池需要支持其他各种加速芯片，因此希望能建立统一的接口。支持该接口的芯片只需要花少量的工作，就能接入资源池调度系统。因此我们联合上海交大和清华大学，以及寒武纪等芯片厂商，建立中国异构资源池技术标准产业联盟。 硬件层池化 作为软件池化技术的升级，利用自研或者三方的硬件插卡，通过机架或小规模跨机架的高速总线互联技术，对通用计算器与多种加速器进行配比解耦，达到中等规模加速器池化和任意的加速器的灵活组合。同时在可靠性，可运维性，加速卡硬件故障处理 SLA 上提供更好的服务。 远程资源 - 本地访问 最后，基于在“核高基”领域的技术研发，奠定了今天阿里云的 IaaS 及 PaaS 服务具备了以下特点： 以产品多样性，打造性价比极致的算力供给的硬件算力基础设施为设计目标。 以软硬协同为主的技术研发和布局形成我们的差异化竞争力和技术抓手。 从单加速器分片算力共享到大规模集群算力的弹性算力能力的交付能力是一个核心需要打造的能力。 SLA 服务能力具备差异性，高可靠性。
-
发表了文章 2020-04-30
边缘端手势识别：AI 交互的正确打开方式
一、概述 “手势是人类沟通的最自然的方式。硬件限制是我们不能很好地控制我们的设备的唯一限制”，这里的硬件限制指的是传统的手势识别算法需要额外的深度传感器。感谢近十多年不断发展的可适应 AI 和边缘计算崛起，使得这一切逐渐变为可能。 我们或将在智能手机、平板电脑、台式电脑、笔记本电脑、智能手表和智能电视，IOT 设备中看到更多结合空中手势来操作的未来功能。 今年我们已经看到有这样的趋势，科技巨头都纷纷推出了自己的手势识别能力：谷歌在自己的手机和智能音箱上提供了手势交互的能力，华为在旗舰手机 Mate30 上推出了自己的手势操控等等，苹果也刚刚提交了手势在智能音箱上应用的相关专利，实际上，手势作为人机交互最自然的方式场景简直是不言自明，想像一下这些场景： 在看电视的时候想要换台，想要调整音量，找不到遥控器的时候，直接使用手势来操作，免去找不到遥控器的抓狂烦恼。 在驾驶汽车，如果你听到了一首很难听的歌，希望赶快切掉，如果需要与触摸屏显示器进行交互，驾驶员必须将视线从道路上移开，这样有潜在的危险，使用手势识别使得驾驶更安全。 在使用 iPad 看剧时，这个时候老板/老婆电话突然进来了，我们对着 iPad 使用静音手势操控设备静音，科技以人为本。 在智能家居场景，使用手势操作你的电灯，空调，甚至抽油烟机都是可以想象的场景 总结来说：“You are the only interface you need”。 二、我们现在的业务场景 我们所属天猫精灵 M 实验室，主要负责跟天猫精灵相关的视觉算法，我们的主要研究方向人机交互视觉算法，包括手势识别，肢体识别，还有多模态视觉语音交互等。 去年，我们推出了基于天猫精灵智能音箱的超轻量手势识别算法，今年我们更进一步，在技术，业务，算法上进行了更为深入的探索： 在天猫精灵大屏产品 CC, CCH, CCL 等上线了手势操控能力。 我们同优酷iPad客户端的小伙伴一起，在优酷 iPad 版也成功应用了我们的手势识别能力。 我们在教育领域，我们尝试了使用手指作为输入，实现了手指点读的相关能力，让小朋友“哪里不会点哪里”。 目前我们在跟电视厂商等 IOT 生态厂商合作，实现大屏手势交互第一步，未来丢掉遥控器将不是梦。 三、无处不在的单点（静态）手势 3.1 从天猫精灵到优酷 iPad 手势识别 去年，我们推出了基于天猫精灵智能音箱的超轻量手势识别算法，今年我们与优酷的小伙伴合作，把单点手势能力进一步移植到了优酷 iPad 场景中。 3.1.1 单点手势应用：优酷吃饭看剧神器 来自用户的声音：吃饭看剧神器 这是在优酷上线后用户自发介绍的使用视频，也非常符合我们的场景预期和用户痛点： 在看剧的时候，经常有需要跳过某一小段，快进或者快退的时刻，解决不便直接操作的时刻（例如吃饭，手里不方便等场景）。 在 iPad 场景：1）受设备体积和重量影响，很少手持设备；2）屏幕较大，用户距离设备通常有一定距离，手势识别带来了更为极致的体验提升。 3.2 走的更远：大屏远距手势交互 3.2.1 大屏交互场景 近年来，智能电视（智屏）正越来越多的进入千家万户。据工信部预测，到 2020 年，智能电视市场渗透率有望达到 90% 以上。除了数量优势，强大的交互能力是智慧家庭入口的必备特质。作为智慧家庭 IoT 的另一个重要入口，智能电视的大屏幕更易实现交互。 3.2.2 挑战 要走的更远，也常常伴随更大的挑战。和天猫精灵 CC 或 iPad 这种近身设备相比，在智能电视场景进行手势算法研发面临主要面临的挑战有： 更远的距离。智能电视有一块大屏幕，往往 3-5 米是一个对人较为舒适和健康的观看距离。在这样一个距离下，人手在画面占比非常小。 更多的人数。可能有多人同时在看电视，因此我们要能及时甄别和响应每一位观众的交互需求。 更复杂的背景。不同家庭不同电视的摆放位置千变万化，我们的算法要在变化中找不变（手势识别） 有限的算力。虽然智能电视越来越普及，但是它们配置的硬件性能依然非常有限。 3.2.3 大屏方案 针对以上挑战，经过我们算法研发探索，提出语义注意力机制导引的快速人手检测和分类方法（Contextual-attention-guided fast tiny hand detection and classification）。 大屏解决方案: Contextual-attention-guided fast tiny hand detection and classification 1）Lightweight hourglass-like backbone 轻量级类 hourglass 模块对输入进行下采样，在获取具有高层语义信息的特征图的同时，尽量保留细节性特征，有利于对 tiny hand 的检测。 2）Contextual attention 3-5 米场景下，人手在整个输入图像中占的像素比非常小。手虽然很小，但是手一般长“人”身上，而且距离人体特定的部位（如手腕、胳膊、人脸）较近，同时与这些部位可能会有相近的颜色。这些人体或人体部位往往较手要更大，为我们 tiny hand 的检测提供了额外的 clues，利用这些 clues，可以更好的对 tiny hand 进行检测。基于此，我们利用 Similarity Context 和 Semantics Context 来作为 Contextual attention ，从而指导网络获取手区域以外的语义信息，增强检测能力。 海尔电视手势 四、落地与优化闭环 相信任何一个做过 AI 算法落地的同学，都会遇到各种各样的实际算法问题，不管是科大讯飞的语音交互，到现在无处不在的人脸识别，甚至谷歌的搜索词排名算法，基于深度学习的AI算法的非常重要的一个特点就是越用越好，并渐渐形成数据相关壁垒。 我们在手势先后在天猫精灵和优酷上线后，我们同样也经历了这样的一个过程，为了让我们的算法“越用越好”： 提出了新的检测算法，应用了前沿的 Overflow-aware 量化方案，极致算法体验。 我们接入了 AutoML 助力 AI 应用快速落地，以动态闭环的形式优化我们的算法。 4.1 更快更强的端上检测算法 + overflow-aware 量化应用 4.1.1 更强的端上检测算法 基于 anchor-free 方案，更高效的算法框架，使用 heatmap 辅助 anchor 方案 基于天猫精灵音箱，IOT 视觉模组等不同设备算力的硬件条件，对端上的手势识别提出了更加高的要求，我们进一步提升手势识别算法能力框架：基于流行的 anchor-free centernet 算法，提出了 centernet-lite 的端上检测算法，不过在实际算法的落地的过程中，我们发现目前流行的 anchor-free 方案在小网络有一些天然劣势： 由于其天然基于 heatmap，最终精度与 heatmap 有很大关系，这对小型化不利。 同时，由于 heatmap 的原因，这种方案无法很好的解决同一类物体重叠的情况。 4.1.2 应用 Overflow-aware 低比特量化算法 端上量化 加速目前业界流行的方案为谷歌 8bit 量化算法，事实上，有更优秀的低比特量化算法：通过学习的方法，学习每一层的 min/max 范围，动态的调整每一层的量化方案，目前在推理引擎端加速比为 70%。 最终我们采用使用 heatmap 方案来辅助 anchor 检测方案且融合 Overflow，这取得了比较好的精度和效果的平衡，在天猫精灵硬件上。 4.2 优化闭环：AUTOAI 的手势线上识别优化框架 （让算法越用越好） 我们利用在 deep learning 中有类似模型蒸馏的思想，通过采用预先训练好的复杂模型（Teacher model）的输出作为监督信号去训练线上网络（student model）。我们可以在不直接接触业务数据的情况下，不断进行算法的优化。 使用围栏的优化结果： 五、产品级的序列（动态）手势 5.1 为什么要做动态手势识别 我们在单点手势已经做了非常多的尝试和应用落地，但是动态手势作为一种更自然更“爽”的交互方式，是我们一直在不断钻研的实际方向。 从产品的思路上来说，动态手势提供了更多的交互感和参与感，其应用的场景可能也是不一样的，比如单点手势可能应用与 IOT 设备等操控类型的算法场景，动态手势其独特的参与感让其更适用于教育，娱乐，线下运营等实际场景，这也是我们不断突破这个场景的原因。 5.2 基于 skeleton 的动态手势识别算法 去年，我们实现了基于 skeleton-based 的动态手势识别算法(相关工作已经投稿ISMAR2019,并成功发表，链接：https://ieeexplore.ieee.org/document/8951971)： 但是在实际的产品化过程中，我们发现对于通用的动态手势识别，纯粹的 skeleton-based 方案可能并不实用，主要原因有： 算力：完成 skeleton-based 的一系列操作：手势检测+指尖回归+时序网络等需要较高算力，在天猫精灵等 IOT 设备上无法达到产品级别的能力。 motion blur：由于手势运动较快的原因，大部分动态手势都有运动模糊的情况，对检测+关键点这类算法非常不友好。 因此，我们把目光投到了以动作识别为基础、指尖回归为辅助的时序推理方案。 5.3 基于视频理解的动态手势识别算法 时序推理 原理：图像关系的时序推理（temporal reasoning）能力，要让计算机认识这两个行为，需要两张及以上的帧图像来相互辅助识别。一个行为需要被多个帧协作来解释。这种方案很好的解决了 motion blur 的问题，且算力上更可控。 Our Temporal Generation Network_ 为解决运动模糊等问题，采用基于 RGB 时序序列为主框架的视频识别方案，提取连续采样帧的特征，并使用改良的高效快速的非退化 3D 卷积网络，对时序特征进行融合。 同时针对特定手势的识别，提出一种基于手指关键点的辅助分支，使用 heatmap 分支对指尖关键点进行多任务学习并回归，检测出手指的运动轨迹，与 RGB 分支进行特征融合，辅助动态手势识别。算法整体结合了基于 RGB 和关键点方案的优势，达到了速度与精度的平衡。 六、未来展望 我们已经在单点手势识别，序列手势识别在算法、业务都进行了较多的探索和尝试，关于手势识别的未来算法探索方向和业务发力点，我们也有一些自己的展望： 6.1 3D 手势崛起 3D 人手姿势估计是指基于输入的 RGB 或 RGB-D 图片进行人手建模并找到关键部件（如，骨节点）位置的过程。我们生活在三维世界，三维手势交互必然带来更自然更舒适的交互体验。我们也在 3D 人手交互方面正进行积极探索，未来在电商产品交互式展示、VR/AR、手语识别、在线教育等方面，我们会推出更多的交互性更强的产品，提供更人性化的交互体验和服务。 Oculus Quest 在今年推出的 3D 手势操控 6.2 手势在 IOT 场景的应用 手势控制能否超越语音控制成为智能家居设备最自然不过的设备呢？在 IOT 场景，如果可以使用手势控制电视，灯泡，空调等等。目前已经有一些 startup 开始了在这方面的探索。 比如 Bixi，Bixi 是一款手势小遥控器，感应你的空中手势，可以指挥你最喜欢的智能手机应用程序、LifX 或者 Hue 灯泡、互联网扬声器、GoPro 和许多其他 IoT 设备。 再比如如下图的 Bearbot 万用遥控器,除了萌系的外观以外,还可以支持自定义手势控制全屋家电,让你从此摆脱一堆遥控器的束缚。 Bearbot 手势遥控器，图片来源：https://www.indiegogo.com/projects/bearbot#/ 6.3 手势在教育场景的更多应用 除了手指点读，手势在教育行业其实应该有更多的应用，比如现在大火的在线教育，手势可以增加虚拟课堂的互动感和，同时对于小朋友来说，手势/视觉提供的有趣新奇的操控体验也是对幼儿提高课堂注意力非常重要的一环，例如，引导举手回答问题。再比如，我们需要做一些课堂小练习，普通的模式太枯燥，使用动态手势识别“画对勾”，“画叉叉”让小朋友以互动游戏的方式完成这些练习。
-
发表了文章 2020-04-30
飞猪的“猜你喜欢”如何排序？
引言 俗话说有多少米，就下多大锅。在特征体系构建上，我们已经准备了很多米了，并且在线性模型 FTRL 上拿到了一些甜头。下一阶段我们换了锅，对模型进行了升级，从线性模型转为 end-to-end 的深度模型，并进行了多个版本的迭代，包括 pure deep 模型（Pure Adaptive L2 Model，PALM），引入实时点击和实时未点击行为（FeedBack-PALM，FB-PALM），引入全网序列特征（Global Local Attention-PALM，GLA），并拿到了一些收益。下面对这个阶段的技术细节进行介绍。 问题分析 固定的特征体系下精巧的模型结构也能显著发挥现有特征的潜力。end-to-end 的深度模型一方面可以隐式和显示的进行特征交叉增加特征的表达能力。另一方面可以很 flexible 的引入真实行为序列特征等复杂结构特征。但是任何事情都有两面性，end-to-end 的深度模型相较于 FTRL 虽然对特征组合要求较少，但是对特征的筛选要求精细，数值型特征以及 id 类特征的选择和处理方法都会对最后的模型效果起决定性的作用。另外模型泛化性，训练过拟合问题以及模型复杂度和线上 rt 的关系也是需要关注的问题。经过多个版本的迭代，包括对现有的多种点击率深度积木模型的复现，引入用户实时点击和未点击 set 特征，引入用户全网序列特征，引入宝贝一阶近邻和预训练向量，加入 time-aware attention 等。下面分阶段进行介绍，包括面对的问题，模型结构，模型离线/在线效果，以及一些思考。 模型迭代 PALM (Pure Adaptive L2 Model) 模型 问题 在新的特征体系下，我们在 FTRL 上拿到不错的结果，很自然的想法是把 FTRL 上的特征复用到 Wide and deep 模型上，然后增加隐式高阶交叉的 deep 侧，来在原来的基础上增加模型表达能力。但是经过几轮的调试，离线指标一直和 FTRL 相比微正向，这不符合对 deep 模型的期望。后来发现把 wide 侧上的特征慢慢迁移到 deep 侧，包括 id 特征，数值特征，命中特征等，离线评测指标涨幅较大，后面也沿用这个思路，采用 pure deep 模型，将所有的特征都迁移到 deep 侧，并拿到了一些收益。但是 pure deep 模型和 wide and deep 模型相比，非常容易过拟合，并且对数值特征以及命中特征的处理方式有一定的要求。其中对离线指标提升较明显的几个点如下： 1）宝贝 id，用户 id，trigger id 等高维 id 类特征需要谨慎加入。航旅这种低频场景，这种高维 id 特征分布一般长尾较严重，大部分 id 的训练数据非常少，噪声较多，模型容易过拟合。在尝试中，正则以及 dropout 等常用抑制过拟合的方式一直没有较好的效果。后续借鉴 DIN 中介绍的 adaptive l2 regularization 的方式，挑选了一批类似用户id这种高维稀疏 id 类特征做动态正则。对正则系数做适当调整后，模型训练正常，全量数据过 5 个 epoch 也不会出现过拟合现象。 2）命中特征（lookup 特征）在目前的 rtp fg 过程中如果没有命中的话，是不存在这个特征结果的，也没有默认值。反映到模型中，如果没有命中，那么 dense 类型输出为 0，id 类型经过 embedding 操作之后输出全零的向量。在神经网络这种对数据分布敏感的模型中，我们考虑了两种使用方式。第一种是采用 dense 类型，命中之后有大于零的值，没有命中的话为零，符合正常数据分布。第二种是 id 类型，命中之后输出一个 id，经过 embedding 操作之后输出均值为零的向量，没有命中的话输出全零向量，也是符合正常数据分布的。经过试验第二种优于第一种，但是第二种方式 embedding 的维度不适合选择太大，因为命中特征本身较稀疏，输出全零向量的可能性较多，会影响模型训练过程。 3）Warm-up+Adam+learning rate decay 的方式相较于其他优化方法对离线指标的提升较大，非常值得一试。 4）batch normalization 在模型训练中起了非常大的作用。由于 deep 侧包括大量的高阶 look up 特征和归一化之后的数值型特征，离散化之后的数值型 id 特征以及普通 id 类特征的 embedding 结果，输入到网络中的数值非常不规范。后面发现 batch normalization 能有效规范这种多种来源的特征组合输入，保证网络的正常收敛。经过尝试在 embedding 层之后加前置 BN，后续接 fully_connected + BN + relu 的这种形式在离线指标上表现最好。 模型结构 最终的网络结构如图： 图中的模型细节就不累述了。该模型的 loss function 和后续的迭代版本都是采用 pointwise 的形式。离线评测都采用同样时间区间的训练数据的 T + 1 评测 AUC。 模型效果分析 同样的时间窗口，采用 30 天数据训练，T + 1 评测，离线指标如下，提升还是很明显的。 效果 上线实验观察 4 天，相较于新特征的 FTRL，uctr 平均提升 3.2%，pctr 平均提升 3.2%。 FB-PALM (FeedBack-PALM) 模型 问题 前一个版本在 pure deep 模型上拿到不错的收益。很自然的想法是尝试各种点击率深度积木模型，比如 DCN，DeepFM，XDeepFM，PNN，Autoint，FGCNN 等，但是经过几版实现以及调优，发现这些 model 结构和上一个版本相比提升微弱，如下图。本来以为是模型复杂度高了，于是对于 FGCNN 多训练了 20k 步，发现模型处于收敛状态。猜想原因为目前 pure deep 模型中已经包含了大量高阶特征，特征不变的情况下，特征的隐式高阶组合已经足够了，显示的高阶组合带来的收益较少。 但是模型还是要继续迭代的，于是切换了思路，通过引入原始特征体系中没有的更多复杂结构特征来实现模型的性能提升。这一版主要添加了用户短期全网实时宝贝点击序列以及用户短期场景内宝贝曝光未点击序列特征，序列中的宝贝考虑 Id，目的地，类目， Poi，Tag 以及行为类型和行为次数等属性。模型结构上没有太多的创新，对于两组序列特征，以待推荐宝贝的 Id，目的地，类目，Poi，Tag 综合起来作为 query，对两组序列进行 attention pooling。然后将 pooling 的结果加入 Pure deep 的输入层，其他结构不变。其中对离线指标提升较明显的几个点如下： 1）对于序列特征中的宝贝并不是考虑越多的属性效果会更好，选择的属性需要覆盖度高，不然序列中太多的属性默认值会导致模型训练不佳。 2）这里对于两组序列，因为同样采用宝贝 id 特征，所以为了防止过拟合，也加入了动态正则的技巧。但是这里需要注意的是虽然待推荐宝贝 id，点击宝贝 id 以及曝光未点击宝贝 id 都是宝贝 id，但是由于来源不同，id 出现的频次也会不同，因此这三类 id 都采用自己各自出现的频次分布进行动态正则。另外这三类宝贝 id 也都采用不同的 embedding matrix，避免正则之间的影响。 模型结构 最终的网络结构如图： 下面对模型的核心部分进行详细描述： 1）对于宝贝维度，模型存在三类信息，包括点击宝贝行为，曝光未点击的宝贝行为以及待推荐宝贝。除了宝贝id以外，我们将行为类型，目的地，类目，tag，poi 等 side information 加入模型中。这里融合采用 concat 的方式。令待推荐宝贝的多个特征经过 embedding 之后得到的向量分别为：，其中 L 为特征的类型数，则可以得到待推荐宝贝的表达为： 类似的可以得到点击宝贝行为以及曝光未点击宝贝行为的表达为 和 ，其中 M 和 N 分别为点击宝贝行为和曝光未点击宝贝行为的个数。 2）通过待推荐宝贝作为 query，对点击宝贝行为以及曝光未点击宝贝行为进行 attention pooling。这里由于维度不一致的原因，采用复杂度较高的加性 attention。attention 的过程如下，其中函数 H 为多层前馈神经网络。这里以点击宝贝行为为例，曝光未点击宝贝行为类似。需要注意的是由于这两类序列信息意义相差较大，所以两个 attention pooling 操作参数是不 sharing 的。 3）最后将点击宝贝行为以及曝光未点击宝贝行为的 pooling 结果 和 与 pure deep 模型的输入层特征进行 concat 一起送入到多层前馈神经网络，输出最后的打分 logit，并进行相应 loss 计算。 模型效果分析 同样的时间窗口，采用 30 天数据训练，T + 1 评测，离线指标如下，提升还是很明显的。 效果 上线实验观察7天，包括三天正向桶以及四天反向桶，相较于 pure deep 模型，uctr 平均提升 1.0%，pctr 平均提升 1.5%。 GLA(Global Local Attention-PALM) 模型 问题 上一个版本主要添加了用户短期全网实时宝贝点击序列以及用户短期场景内宝贝曝光未点击序列特征，并拿到了不错的效果。但是分析特征组成以及模型结构之后，发现还存在一些不足： 1）宝贝行为序列只能覆盖一部分航旅用户，另外一部分航旅用户没有宝贝相关行为，只有机票、火车票、酒店等行业下的行为，但是目前模型中考虑的序列还没有 cover 这部分用户。 2）上一版模型对宝贝点击序列以及宝贝曝光未点击序列只是做了加性 attention pooling 的操作，只考虑了 query（待推荐宝贝）和序列中的每一个元素的相关性。我们还应该考虑序列中每一个元素之间的相关性。 针对上述不足，在这一版本迭代过程中： 1）加入用户全网行为序列，包括机票，火车票，酒店，宝贝等行业。需要注意的是在实践过程中，发现全网行为序列中的 id 属性维度会造成模型的过拟合现象，加入动态正则之后还是没能缓解。分析原因有可能是 id 属性在机票、火车票、酒店以及宝贝的混合序列中分布太杂乱，因此去除 id 属性，只考虑覆盖度高的目的地、类目、Poi、Tag 以及行为类型等属性。用户全网行为序列的 pooling 方式采用在意图模型中积累的 Multi-CNN + attention 的方式，具体细节可参考飞猪用户旅行意图。 2）对宝贝点击序列以及宝贝曝光未点击序列的 pooling 方式，我们采用 transformer + attention 的形式，在原来加性 attention 的上一层，我们先通过 transformer 对序列中个体之间的相关性通过 self-attention 进行描述，然后再通过 attention 进行 pooling。当然和上一个版本一样宝贝点击序列以及宝贝曝光未点击序列的 pooling network 的参数是不 sharing 的。 模型结构 最终的网络结构如图： 下面对模型的核心部分进行详细描述，一些通用性的模块的细节不详细介绍。 1）对于用户全网行为序列，我们只考虑行为类型，目的地，类目，tag，poi 等覆盖度高的粗粒度属性，不考虑 id 这一维属性，防止过拟合。融合的方式采用 concat 的方式。 2）用户全网行为序列的 pooling 方式采用 Multi-CNN + attention 的方式。通过 Multi-CNN 抽取不同区间范围内的局部特征（units），同时考虑 local 和 global 信息。区间越小，更加关注于局部，区间越大，更加关注于全局。比如区间为 1 时，考虑的是 point level。unit 中包含多种目的地类型，包括酒店，宝贝，火车票，机票等。通过 d 个形状为 d ∗ h 的 filters 对输入 进行步长为1的卷积，卷积方式为 SAME。经过 m 次类似的操作，每一次操作filter的形状为 ，最后输出为 m 个和输入形状一致的序列向量，。因为混合序列的形式，序列长度过长，如果采用RNN的形式一方面计算量大，另一方面长时依赖较弱。然后复用上一版模型中的加性 attention 对 Multi-CNN 抽取出来的多组序列进行 attention pooling，并将 pooling 的结果和 pure deep 模型的输入层 concat。需要注意的是这里多组序列的 attention pooling 参数是共享的。 对于点击宝贝行为，曝光未点击的宝贝行为的 pooling 过程，在 attention 之前添加一层 transformer 操作，通过 self-attention 来捕获序列内个体之间的关系，然后再进行加性 attention pooling。其他的操作不变。 模型效果分析 同样的时间窗口，采用 30 天数据训练，T + 1 评测，离线指标如下，提升还是很明显的。这里和上一版模型的离线结果图在 AUC 范围上有所不同是因为切换了时间窗口。 效果 上线实验观察，相较于 FB-PALM 模型，uctr 平均提升 1.0%，pctr 平均提升 3.0%。 其他的尝试 宝贝的一阶近邻信息和宝贝 pretrain embedding 前面后两版模型是在用户侧增加了复杂序列特征，而宝贝侧一直很薄弱。因此考虑增加宝贝的一阶近邻信息和宝贝的 pretrain embedding 向量。一阶近邻通过统计历史一年用户 session 行为中宝贝的共现关系来获得。而宝贝的 pretrain embedding 向量包括文本向量，图像向量以及基于随机游走产出的 deepwalk 向量。实验下来单独增加这些 trick 和 pure deep 模型相比能拿到很大的提升，但是叠加到后续的模型版本上效果不明显。应该需要再探索更加精细的融合方式，而不是直接都 concat 到输入层。两次实验结果如下，确实很微弱，因此没有上线验证。 time-aware attention 前几个版本的模型中 time 的信息都是通过 side information 的方式加入，类似于 pos embedding。但是 time 的信息在行为序列刻画过程中十分重要。调研了一些方法，包括 time-LSTM 等，但是由于 RNN 的计算复杂度太高，也放弃了。后续尝试将 time 的信息后置，直接加到 attention 的过程中，在离线表现上有一些收益，但是也不明显，暂时没有上线，后续这个也是值得探索的。 未来展望 目前飞猪首页猜你喜欢数据来源非常多，如何在不同数据来源的混合数据集下学习出在多场景下都很 solid 的模型是值得探索的。 目前几版模型在特征显示交叉的模型结构上没有拿到多少收益，后续需要探索这个问题，从特征体系，到模型结构，到数据来源上一起分析这个问题。
-
发表了文章 2020-04-30
跑赢业务的同时如何实现技术成长？
很少有一家公司，会像阿里一样要求技术人员也要懂业务的。来阿里之前，我呆过不少公司，通常的做法是业务提需求，技术干活，这个时候，技术就是个资源。在阿里，我花了很长时间才适应过来，相信很多同学也和当初的我有同样的困惑：已经有产品经理的角色了，大家各司其职不就好了，为什么我一个做技术的，要狗拿耗子呢？答案很简单：只有了解业务，才能从技术的角度想到业务方不曾想到的地方；只有了解到业务背后的 Why ，才能从全局的视角去规划技术的未来。 从 0 和 1 说起 我的花名叫林异，那我就从 0 和 1 说起吧。于公司而言，业务是 1，其它都是 0；于技术团队而言，技术是 1，其它都是 0。只要这家公司还要从事商业活动，业务就是第一的，业务不行大家就得散伙，所以要业务先赢。技术团队核心要做的是支撑业务、促进业务、引领业务，层层递进。对于大多数技术团队来说，都是以支撑业务为主，少量的促进业务，而引领业务则是少之又少了。这样听起来是否大多数技术团队只需要认真做好技术就可以了呢，其实并不是这样，如果公司这个大 1 不存在了，技术这个小 1 还有什么意义呢？退一万步讲，即使我们只考虑技术，但如果我们不了解业务，我们又如何去规划技术支撑当下及未来的业务呢？ 以终为始 在做技术规划的时候，如果我们只看到当前存在的问题，就容易头痛医头脚痛医脚。我们需要结合未来几年业务上可能的变化以及技术的发展，来做出我们的技术规划。 毛主席教导我们： 不要只见树木，不见森林 ICBU 的前端掌门人耿霄常说： 要以终为始，看到我们的终局是什么 以 ICBU 无线前端的技术规划为例，我从业务趋势与技术趋势两个维度，来判断未来几年我们的技术上将发生什么变化。再结合当下的业务规划，来确定当前的技术重点。而当下的技术项目推进，又要为未来的技术规划埋下伏笔，这样在逐步的演进过程中，我们才能将点最终连成片，形成立体化的技术规划。 业务趋势 我认为，要看 ICBU 的业务趋势，就一定要看阿里巴巴是如何起来的。可以说，中国加入 WTO (主要是对美贸易) + 人口红利 + 信息不对称成就了阿里巴巴，C 类这一趴我们今天且按下不表，但就 B 类跨境电商而言，当前的内外部环境都已经发生很大的变化。 从外部环境看，世界格局走向两强对抗，修昔底德陷阱在所难免，贸易保护主义抬头，低端制造被迫向东南亚转移。从内部环境看，人口红利正在消失，中国是否能跳出中等收入陷阱仍然是个未知数。纵观世界历史，跳出中等收入陷阱主要有两个手段——对外输出或者技术革命，所以才会有“一带一路”和“中国制造 2025”。 由此可见，世界格局的变化 + 人口红利不再（成本上升）可能导致产业外移，原来我们依靠世界工厂地位而形成的垄断优势不再，所以我们就必须有更多的全球卖家加入进来。中美摩擦相当长一段时间内可能会成为常态，外贸企业势必寻找新的出路，例如向印度、东盟、非洲等国家和地区出口，所以我们需要由原来重点看美国买家转变为看全球买家。 过去国际站一直是一个黄页模式 (Souring)，有人戏称之为一夜情模式，这几年国际站开始由 Souring 转向 Trading。传统模式下，买家通过 Alibaba.com 找到卖家，以后他们发生什么事情可能就和阿里巴巴无关了。这种模式有几个弊端，第一，我们的营收模式有限，主要靠卖家会员费和广告费；第二，我们无法沉淀交易数据，提供的用户价值太薄，用户粘性不足。 我们更应该看到，B 类贸易形式正在发生巨大的变化，传统的分销模式正在分崩离析，千禧一代开始主导世界，他们更愿意跳过中间商直接从源头进货，当资金流（例如用区块链提升国际结算的速度）和物流（例如菜鸟的 72 小时全球物流网）等基础设施得到改善后，这个趋势会更明显。另一方面，新生代更加强调个性，传统的大规模生产将会被柔性生产代替。未来我们的客户主要分为两个部分，一种是传统的大贸，这类主要是以采购工业品、原料、OEM、ODM 为主，另一种是以轻订制或现货组成的快速交易市场。前者交易链路太长，与线下链路耦合太紧，后者可能会逐渐形成在线交易的主要来源。 传统跨境 B 类贸易的用户画像是朝九晚五的办公族，用手机去找商找品洽谈完全无法想像。但如果 B 类贸易的用户结构发生了变化呢，当便利店杂货店健身房的老板们逐渐变多，他们甚至可能没有电脑，忙时偷闲掏出手机就能完成一单交易。 诚然，这几年我们的 App 一直在强势增长，但与 C 类业务不同是，在相当长一段时间内，我们恐怕无法 All in 无线直接以 App 为主。B 类的操作非常复杂，PC 还是重要战场；但对于快速交易市场的用户，App 无疑是最好的触达方式；M 站仍然是我们重要的流量来源，欧美一些国家的用户习惯使用 M 站这种轻量的方式，第三世界国家的用户由于网络和设备较差，也会愿意选择直接使用 M 站。 技术趋势 技术上也在发生巨大的变化，5G 技术会加速地区的不平衡，新技术的出现必定带来新的交互形式，移动设备上的 VR/AR 等能力再结合 5G，未来人们的沟通交流将会有质的改变，我们正在下一场技术革命临界点。5G 技术还可能会让部分国家或地区跳过 PC 直接进入到高速的无线时代，例如印度和非洲，而这些国家或地区可能会是未来 B 类业务新的增长引擎。全球化走到后面就是本地化，再加上新技术的出现，就要求我们要有强大差异化的能力，包括内容、运营甚至交易流程等。 端的发展也值得关注，苹果已经发布了 iPadOS，未来 PC 将会成为专业人士的工具，有没有可能未来有很多小店主，直接使用平板在阿里巴巴就完成了整个采购交易。在多端多屏的问题上，Flutter 的出现让 iOS 和 Android 可以使用同一套代码开发，Flutter For Web 已经出现，未来是否有可能直接使用 Flutter 就能进行开发？随着基础技术与 Web 的发展，Weex 未来会否是一个比较尴尬的位置，是要拥抱 Web 还是继续走 Weex？ 小结 结合技术趋势及业务趋势，我认为“差异化”和“端技术融合”将可能会是我们未来发力的重点。但是否意味着我们现在就要全力 Focus 在这两件事情上呢？答案是否定的，我们还要结合当下的业务规划与问题，来判断最紧急最重要的事情是什么。但是，我们在解决当前问题的同时，也要花一小部分的精力为未来埋下伏笔。 立足当下，着眼未来 立足当下 业务上而言，当下的环境要求我们必须要走出去寻找突破口，而走出去一个很重要的点就是提升买家体验，国际 B 类市场总体上还是买方市场，对于一个买方市场来说，必须要有买家的繁荣才会带来双边的繁荣。要提升买家体验的手段有很多，而非前端莫属的则是性能这个突破口。 在无线前端团队，我进一步把性能优化的重点锁定在 App 内的 Weex 这个场景。虽然我们团队同时要兼顾 M 站和 App 两个端，但 App 端无论是业务转化还是用户留存都要比 M 站好太多。M 站虽然流量大但转化低，核心原因是由于链路断层及流量结构导致的，性能有影响但并非主因。 国际站的无线是一个全力奔跑的业务，在奔跑的过程中，自然而然选择了“短平快”这种方式来支撑业务。这种“短平快”的模式带来的弊端就是技术体系众多，技术体系众多又容易带来质量隐患，所以在去年我们还有两个重点是要解除稳定性的隐患及逐步做技术收敛。 着眼未来 资源永远是有限的，业务需要前行，技术需要成长，我们需要做出选择。我的选择就是以性能为核心突破口，在稳定性方面先保障卡得住、能发现、可灰度，逐步做好技术收敛。 有人戏言，做技术就像戴着镣铐跳舞，满足业务当下的需求可能就耗掉我们全部的精力了。但与此同时，我们又要考虑到未来的业务和技术发展趋势，布局整个技术产品。可以提前部署但不超前部署，可以分段布局但不盲目入局。 结语 作为技术方，我们不仅要了解业务策略与打法，也要去思考这些策略与打法背后的Why，这样我们才能从更全局的视角去思考与规划技术的未来。只看看清未来，我们才能清楚地知道当下我们要做什么。
-
发表了文章 2020-04-30
深度 ｜ 大数据算法应用的测试发展之路
一 前言 最近十年来，随着移动互联网和智能设备的兴起，越来越多的数据被沉淀到各大公司的应用平台之上，这些包含大量用户特征和行为日志的数据被海量地存储起来，先经过统计分析与特征样本提取，然后再经过训练就会产出相应的业务算法模型，这些模型就像智能的机器人，它可以精准地识别和预测用户的行为和意图。 如果把数据作为一种资源的话，互联网公司与传统公司有着本质的不同，它不是资源的消耗者，而是资源的生产者，在平台运营的过程中不停地在创造新的数据资源，并且随着平台的使用时长和频率的增加，这些资源也在指数级地增长。平台通过使用这些数据和模型，又反过来带来更好的用户体验和商业价值。2016 年，AlphaGo，一个基于深度神经网络的围棋人工智能程序，第一次战胜围棋世界冠军李世石。这个由谷歌（Google）旗下 DeepMind 公司开发的算法模型，背后使用的数据正是人类棋手所有的历史棋谱数据。 阿里的搜索、推荐和广告也是非常典型的大数据应用的场景（高维稀疏业务场景），在谈如何测试之前我们需要先了解一下平台处理数据的工程技术背景。搜索、推荐、广告系统在工程架构和数据处理流程上比较相近，一般分为离线系统和在线系统两部分，见下图 1（在线广告系统一般性架构，刘鹏《计算广告》）。离线系统负责数据处理与算法模型的建模与训练，而在线系统主要用以处理用户的实时请求。在线系统会使用离线系统训练产出的模型，用以实时的在线预测，例如预估点击率。 用户在访问手机淘宝或者其他 app 的时候会产生大量的行为数据，包括用户的浏览、搜索、点击、购买、评价、停留时长等，加上商家商品维度的各类数据（广告还需要增加广告主维度的数据），这些数据经过采集过滤处理之后再经过特征提取之后生成了模型所需的样本数据，样本数据在机器学习训练平台上经过离线训练之后就可以产生用以在线服务的各类算法模型（例如深度兴趣演化网络 DIEN、Tree-based Deep Model、大规模图表示学习、基于分类兴趣的动态相似用户向量召回模型、等等）。在线系统中最主要的功能是数据的检索和在线预测服务，一般使用信息检索的相关技术，例如数据的正倒排索引、时序存储等。 搜索推荐广告系统在使用了上述维度的大数据，经过深度学习之后，成为一个千人千面的个性化系统。对于不同的用户请求，每次展现的商品和推荐的自然结果和商业结果都不尽相同，即便是同一个用户在不同的时刻得到的结果也会随着用户的实时行为的不同而改变，这些背后都是数据和算法模型的魔力。 图1 在线广告系统一般性架构图 二 大数据应用测试质量域的六大挑战 在思考搜索推荐广告系统是如何测试的之前，我们首先要定义问题域，即要解决的测试问题是什么，我们的思路从以下几个方向展开。 1 功能性测试与验证 除了正常的请求与响应的检查之外，大数据的“大”主要体现在数据的完整性和丰富性。一个搜索推荐引擎的好坏很大程度上取决于其内容是否足够丰富，召回是否足够多样。另外，算法带来搜索推荐结果的不确性，但也给我们的测试验证工作造成了麻烦。所以，数据的完整性和不确定性校验也是功能测试的要点。 2 数据更新的实时性如何测试 总所周知，对于一个搜索或者广告的在线计算引擎，其内部的数据在不停地发生更新，或者出于商家在商品信息上的变更，也可能是因为广告主在创意甚至投放计划上的变化，这些更新需要实时反馈在投放引擎，否则会出现信息不一致甚至错误。如何测试和验证这些变更的及时性，即保证一定的并发带宽又保证更新链路的响应时间，这是需要测试重点关注的一个问题。 3 数据请求响应的及时性如何测试 在线服务都要求低延迟，每次 query 服务端需要在几十毫秒内给出响应结果，而整个服务端的拓扑会有大概 30 多个不同模块构成。如何测试后端服务的性能和容量就变得至关重要。 4 算法的效果如何验证 搜索推荐甚至广告的返回结果需要与用户的需求和兴趣匹配，这样才会保证更高的点击率与成交转化，但如何验证这种需求与结果的相关性，或者如何测试一个算法的效果，这是一个非常有趣且有挑战的话题。 5 AI 算法系统的线上稳定性如何保证 线下发布之前的测试是对代码的测试验收，并随着缺陷的发现与修复，提升的是代码质量。而线上的稳定性运营是为了提升系统运行的稳定性，解决的问题是：即便是一个代码质量一般的系统，如何通过技术运维的方法来提升系统的高可用性与鲁棒性，并降低线上故障的频次与影响，这一部分也被称为线上技术风险领域。 6 工程效率方向 这是对以上几个部分的补充，甚至是对整个工程研发体系在效率上的补充。质量与效率是一对孪生兄弟，也是同一个硬币的两面，如何平衡好两者之间的关系是一个难题，质量优先还是效率优先，不同的产品发展阶段有不同的侧重点。我们的工程效率，力在解决 DevOps 研发工具链路，用以提升研发的工程生产力。 自此，我们基本定义完毕大数据应用的测试问题的六大领域，有些领域已经超过了传统的测试与质量的范畴，但这也正是大数据应用给我们带来的独特质量挑战，下面我们围绕这六个问题展开讲一讲。 三 大数据应用测试六个问题的解法 1 AI 应用的功能性测试验证 功能测试主要分三块：端到端的用户交互测试、在线工程的功能测试、离线算法系统的功能测试。 1） 端到端的用户交互测试 这是涉及到搜索推荐广告系统的用户交互部分的测试验证，既包括买家端（手机淘宝、天猫 app 和优酷 app 等）的用户体验和逻辑功能的验证，也包括针对广告主和商家的客户管理平台（Business Platform）上业务流程逻辑的校验，涉及广告主在广告创意创作、投放计划设定、计费结算等方面的测试。端到端的测试保证了我们最终交付给用户和客户使用的产品质量。端上的测试技术和工具，主要涉及端到端（native/h5）app/web 上的 UI 自动化、安全、性能稳定性（monkey test/crash 率）、流量（弱网络）、耗电量、兼容性和适配，在集团其他团队的测试技术和开源技术体系的基础上我们做了一些改进和创新，例如将富媒体智能化验证引入客户端自动化测试，完成图像对比、文字 OCR、局部特征匹配、边缘检测、基于关键帧的视频验证（组件动画、贴片视频）等，解决了广告推荐在客户端上所有展现形式的验证问题。另外，针对 Java 接口和客户端 SDK 的测试，除了常规的 API Service 级别测试之外，在数据流量回放的基础上使用对比测试的方法，在接口对比、DB 对比、文件对比、流量对比的使用上有一些不错的质量效果。端到端的测试验证，由于 UI 的改版速度非常快，测试策略上我们把自动化的重点放在接口层面，UI 的 automation 只是简单的逻辑验证，全量的 UI 验证回归（功能逻辑和样式体验）还是通过手动测试，这里我们使用了不少的外包测试服务作为补充。 2） 在线工程系统的测试 这一部分是整个系统的功能测试的重点。搜索推荐广告系统，本质上是数据管理的系统，数据包括商品维度、用户维度、商家和广告主维度的数据。把大量的数据按照一定的数据结构存储在机器内存之中，提供召回、预估、融合等服务，这些都是在线工程要去解决的问题。这部分的功能测试，基本原理是通过发送 Request/Query 请求串、验证 Response 结果的模式，在此基础上使用了比较多提升测试用例生成效率和执行效率的技术。基于可视化、智能化等技术（智能用例生成、智能回归、失败智能归因、精准测试覆盖、功能 A/B 测试），把测试方法论融入其中，解决了大规模异构的在线工程功能测试 case 编写成本高、debug 难、回归效率低的问题。搜索推荐广告的在线服务工程基本上由 20 - 30 个不同的在线模块组成，测试这些在线服务模块极其消耗时间，用例的编写效率和回归运行效率是优化的主要目标，在这个方向上，我们在用例生成方面通过用例膨胀和推荐技术、基于遗传算法动态生成有效测试用例、在用例执行阶段使用动态编排的回归技术，通过这些技术极大地提升了在线模块的功能测试的覆盖率。 此外，我们比较多地使用线上的 Query 做对比测试的方法，用以验证功能变更的差异，分析即将发布的系统与实际线上系统之间的结果一致率和数据分布可以很好地找到系统的功能性问题。在线上测试领域，除了对比测试，我们把近期 Top-N 的 Query 在线上定时做巡检监察，一方面起到功能监控的作用，另一方面 Query 量级到一定程度（例如最近一周 80% 的长尾 Query），可以很轻松地验证引擎数据的完整性和多样性。最后，这一部分的测试策略也需要强调一下，由于算法的逻辑（例如召回和排序的业务逻辑）非常复杂，涉及不同的业务和分层模型，这些逻辑是算法工程师直接设计实现的，所以算法逻辑的测试用例的设计和执行也是由算法工程师来做，只有他们最清楚模型的功能逻辑和如何变化。结合着线上 debug 系统的使用，算法工程师可以很清楚目前线上运行的算法和线下即将上线的算法之间的逻辑差异，测试用例也就比较容易编写。测试工程师在其中主要负责整个测试框架和工具环境的搭建，以及基本测试用例的编写与运行。这个测试策略的调整，在本文最后关于测试未来的预判部分也有介绍。 3） 离线系统的测试，或者算法工程测试 从数据流程的角度看，算法工程包括算法模型的建模流程和模型训练上线两部分，从特征提取、样本生成、模型训练、在线预测，整个pipeline离线流程到在线的过程中如何验证特征样本的质量和模型的质量。所以算法测试的关键在于三个地方： 样本特征质量的评估 模型质量的评估 模型在线预估服务的质量保障 a 和 b 涉及数据质量与特征功效放在一起在第四部分介绍，主要使用数据质量的各种指标来评估质量。 这里重点说一下 c，算法在线预估服务上线前的测试，因为其涉及到模型最终服务的质量，比较重要。我们这里使用了一种小样本离线在线打分对比的方法，可以最终比较全面地验证模型上线质量的问题。详细过程是：在模型上线正式服务之前，需要对模型做测试验证，除了准备常规的 test 数据集，我们单独分离出一部分样本集，称之为小样本数据集，通过小样本数据集在线系统的得分与离线分数的对比的差异，验证模型的在线服务质量，这种小样本打分实际上也提供了类似于灰度验证的能力。流程见下图 2。 图2 小样本测试 关于离线系统的测试，我们同时在深度学习训练平台的质量保障上也做了一些探索，目前深度学习平台质量主要面临三大难点： 于种种复杂状况，在集群上训练的模型存在训练失败的风险，如何提前预警深度学习平台当前存在的潜在风险。 由于神经网络天然局部最优解基因和 Tensorflow Batch 的设计思路，每次训练的模型，如何保障它是否满足上线的质量要求。 如何验证在大规模数据集和分布式系统下深度学习平台提供的各种深度学习功能的准确性。 针对这三大问题，我们尝试了三个解法： 实验预跑法，设计特别的模型和训练数据，15 分钟内训练完毕。可以快速发现和定位训练平台的问题，在大规模的生产模型正式训练之前就发现问题。 Model on Model 的模型验证法，把模型生产的中间数据指标（除 auc 之外，还包括神经元激活率、梯度在各层传到均方差等）透传加工建模，监控生产模型的质量。 Model Based 功能校验法，针对性地设计样本格式和测试模型网络，使模型 variable 的理论值能够精确计算出，根据训练模型的结果验证平台的质量。 2 数据更新的实时性如何测试的问题 这一部分主要包含两个子问题： 1） 引擎数据的实时更新链路的测试 对于一个实时更新链路，从上游的数据源/数据表（TT/MetaQ/ODPS，阿里的消息中间件与离线数据表）读取数据，经过 Streaming 计算平台（Bayes 引擎、Blink 等，阿里的实时计算平台）的实时计算任务处理产出引擎可以接受的更新消息，引擎在收到此类消息之后再做数据的更新操作。这个链路主要验证的点在于： 数据的正确性验证 数据的一致性验证 数据的时效性验证 数据的并发性能测试 在这几个问题的解决上，我们使用了流式数据实时对比、全量对比可以解决数据的正确性和一致性验证的问题；数据的时效性更多地依赖计算平台底层的资源来保证毫秒级别的更新速度，我们这里通过记录更新时间戳来验证更新的时效性；性能测试通过伪造上游数据和流量复制来验证整个链路的响应时间和并发处理能力。 2） 模型的实时更新（Online Deep Learning）链路如何测试 为了拿到实时行为带来的算法收益，Online Deep Learning（ODL）最近两年兴起，用户实时行为特征数据也需要实时地训练到模型之中，在 10-15 分钟的时间间隔里，在线服务的模型会被更新替代，留给模型验证的时间最多只有 10 分钟的时间，这是 ODL 带来的质量挑战。解这个问题，我们有两个方法同时工作。 （1）最主要的方法是建立 ODL 全链路质量指标监控体系，这里的链路是指从样本构建到在线预测的全链路，包括样本域的指标校验和训练域指标校验。 指标选取上主要看是否跟效果相关联，例如对于 ctr 预估方向，可以计算测试集上的 auc、gauc（Group auc，分组后的 auc）、score_avg（模型打分均值）等指标，甚至计算train_auc & test_auc，pctr & actual_ctr 之间的差值（前者看是否过拟合，后者看打分准度）是不是在一个合理的范围内。这里也有一个关键的点在于测试集的选取，我们建议测试集除了取下一个时间窗口的数据（用未见的数据测试模型的泛化性能），还可以包含从过去一段时间（比如一周）的数据里面随机抽样的一部分数据（用已见但全面的数据测试模型是否跑偏）。同时，这也降低了局部的异常测试样本对评估指标带来的扰动影响。 （2）除了指标体系之外，我们设计了一个离线仿真的系统，在模型正式上线之前在仿真环境模拟打分校验。 简单来说就是把需要上线的模型，在线下测试环境利用线上流量通过在线服务的组件打分模块进行一个提前的预打分，在这个打分过程中出现任何错误都算校验不通过，打分正常的模型再对分数进行均值和分布的校验，打分校验不通过会直接拒绝上线。通过以上两种方案，结合样本与模型的监控与拦截，可以极大概率低降低 ODL 的质量风险。 3 性能压测 对于由离线、在线两部分构成的AI系统，在线是响应的是用户实时访问请求，对响应时间要求更高，在线系统的性能是这一部分的重点。离线的性能很大程度上取决于训练平台在计算资源方面的调度使用，我们一般通过简单的源头数据复制来做验证。对于在线系统，分为读场景和写场景的性能测试，写场景的性能在第二部分实时更新链路的时效性部分已有介绍，这里主要讲一下在线场景的读场景的性能容量测试。 在线系统一般由二三十个不同的引擎模块组成，引擎里的数据 Data 与测试 Query 的不同都会极大的影响性能测试结果，同时也由于维护线下的性能测试环境与线上环境的数据同步工作需要极大的代价，我们目前的策略都是选择在线上的某个生产集群里做性能容量测试。对于可以处理几十万 QPS（Query Per Second）的在线系统，难点在于如何精准控制产生如此量级的并发 Query，使用简单的多线程或多进程的控制已经无法解决，我们在这里使用了一个爬山算法（梯度多伦迭代爬山法）来做流量的精准控制，背后是上百台的压力测试机器递增式地探测系统性能水位。 另外一个建设的方向是整个压测流程的自动化以及执行上的无人值守，从基于场景的线上 Query 的自动选取、到压力生成、再到均值漂移算法的系统自动化校验工作，整个压测流程会如行云流水一般的按照预设自动完成。配合着集群之间的切流，可以做到白+黑（白天夜间）的日常压测，对线上水位和性能瓶颈的分析带来了极大的便利。 4 效果的测试与评估 这是大数据应用算法的重头戏，由于算法的效果涉及到搜索广告业务的直接受益（Revenue & GMV），我们在这个方向上也有比较大的投入，分为以下几个子方向。 1） 特征与样本的质量与功效评估 通过对特征质量（有无数据及分布问题），以及特征效用（对算法有无价值）两个角度出发，在特征指标计算上找到一些比较重要的指标：缺失率占比、高频取值、分布变化、取值相关性等。同时，在训练和评估过程中大量中间指标与模型效果能产生因果关系，通过系统的分析建模张量、梯度、权重和更新量，能够对算法调优、问题定位起到辅助决策作用。 而且，通过改进 AUC 算法，分析 ROC、PR、预估分布等更多评估指标，能够更全面的评估模型效果。随着数据量级的增加，最近两年我们在建模和训练过程中使用了千亿参数、万亿样本，Graph Deep Learning 也进入百亿点千亿边的阶段，在如此浩瀚的数据海洋里，如何可视化特征样本以及上述的各种指标成为一个难点，我们在 Google 开源的 Tensorboard 的基础上做了大量的优化与改进，帮助算法工程师在数据指标的可视化、训练过程的调试、深度模型的可解释性上给与了较好的支持。 2） 在线流量实验 算法项目在正式上线之前，模型需要在实验环境中引入真实的线上流量进行效果测试和调优，在第一代基于Google分层实验架构的在线分层实验（原理 Google 论文“Overlapping Experiment Infrastructure More, Better, Faster Experimentation”）的基础上，我们在并发实验、参数管理、参数间相互覆盖、实验质量缺乏保障、实验调试能力缺失、实验扩展能力不足等方面做了很多的改进，极大地提升了流量的并发复用与安全机制，达到真正的生产实验的目的。在效果上，通过在线实验平台引入的真实流量的验证，使得模型的效果质量得到极大的保障。 3） 数据效果评测 这里分两块：相关性评测与效果评测。相关性是相关性模型的一个很重要的评估指标，我们主要通过数据评测来解决，通过对搜索展示结果的指标评测，可以得到每次搜索结果的相关性分数，细分指标包括：经典衡量指标 CSAT (Customer Satisfaction，包括非常满意、满意、一般、不满意、非常不满意)、净推荐值 NPS (Net Promoter Score，由贝恩咨询企业客户忠诚度业务的创始人 Fred Reichheld 在 2003 年提出，它通过测量用户的推荐意愿，从而了解用户的忠诚度)、CES (Customer Effort Score，“客户费力度”是让用户评价使用某产品/服务来解决问题的困难程度)、HEART 框架（来源于 Google，从愉悦度 Happiness、Engagement 参与度、Adoption 接受度、Retention 留存率、Task success 任务完成度）。 效果评估方面，我们采用了数据统计与分析的方法。在一个算法模型真正全量投入服务之前，我们需要准确地验证这个模型的服务效果。除了第一部分介绍的离在线对比之外，我们需要更加客观的数据指标来加以佐证。这里我们采用了真实流量的 A/B 实验测试的方法，给即将发布的模型导入线上 5% 的流量，评估这 5% 流量和基准桶的效果对比，从用户体验（相关性）、平台收益、客户价值三个维度做各自实际指标的分析，根据用户的相关性评测结果、平台的收入或者 GMV、客户的 ROI 等几个方面来观测一个新模型对于买家、平台、卖家的潜在影响到底是什么，并给最终的业务决策提供必要的数据支撑。流量从 5% 到 10%，再到 20% 以及 50%，在这个灰度逐渐加大至全量的过程中，无论是功能问题、还是性能的问题，甚至效果的问题都会被探测到，这种方法进一步降低了重大风险的发生。这是一个数据统计分析与技术的融合的方案，与本文所介绍的其他技术方法不同，比较独特，但效果甚佳。 5 线上稳定性 与其他业务的稳定性建设类似，通过发布三板斧（灰度、监控、回滚）来解决发布过程的质量，通过线上的容灾演练、故障注入与演练（我们也是集团开源的混沌工程 Monkey King 的 C++ 版本的提供者）、安全红蓝对抗攻防来提升系统线上的稳定性和可用性。另外在 AI Ops 和 Service Mesh 为基础的运维管控方向上，我们正在向着智能运维、数据透视分析、自动切流、自动扩缩容等方向努力。我们预测结合 Service Mesh 技术理念在 C++ 在线服务的演进，系统会具备对业务应用无侵入的流量标定及变更标定的能力，也就能够实现流量调度能力和隔离的能力。另外，红蓝攻防也将进一步发展，自动化、流程化将逐步成为混沌工程实施的标准形式。由于这一部分尚处于起步阶段，这里不再过多介绍还没有实现的内容，但我们判定这个方向大有可为，与传统运维工作不同，更接近 Google 的 SRE（Site Reliability Engineering）理念。 6 AI 应用的工程效能 主要解决在测试阶段和研发阶段提升效率的问题，这个方向上我们以 DevOps 工具链建设为主，在开发、测试、工程发布、模型发布（模型 debug 定位）、客户反馈（体感评估、众测、客户问题 debug）整个研发闭环所使用到的工具方面的建设。在我们设想的 DevOps 的场景下，开发同学通过使用这些工具可以独立完成需求的开发测试发布及客户反馈的处理。鉴于这个方向与测试本身关系不大，篇幅原因，这里也略过。 四 大数据应用测试的未来 至此，关于大数据应用测试的几个主要问题的解法已经介绍完毕。关于大数据应用测试的未来，我也有一些自己初步的判断。 1 后端服务测试的工具化 这涉及到服务端的测试转型问题，我们的判断是后端服务类型的测试不再需要专职的测试人员，开发工程师在使用合理的测试工具的情况下可以更加高效地完成测试任务。专职的测试团队，未来会更多地专注于偏前端与用户交互方面产品质量的把控，跟产品经理一样，需要从用户的角度思考产品质量的问题，产品的交付与交互的验证是这个方向的重点。多数的服务端的测试工作都是可以自动化的，且很多 service 级别的验证也只有通过自动化这种方式才能验证。相比较测试同学，开发同学在 API 级别的自动化代码开发方面能力会更强，更重要的是开发同学自己做测试会减少测试同学与开发同学之间的大量往返沟通的成本，而这个成本是整个发布环节中占比较大的部分。再者，第一部分介绍过，算法工程师在业务逻辑的理解上更加清晰。 所以，我们更希望后端的测试工作由工程或者算法工程师独立完成，在这种新的生产关系模式下，测试同学更加专注于测试工具的研发，包括自动化测试框架、测试环境部署工具、测试数据构造与生成、发布冒烟测试工具、持续集成与部署等。这种模式也是目前 Google 一直在使用的测试模式，我们今年在这个方向下尝试了转型，在质量变化和效率提升方面这两方面效果还不错。作为国内互联网公司的率先进行的测试转型之路，相信可以给到各位同行一些借鉴。这里需要强调一点的是，虽然测试团队在这个方向上做了转型，但后端测试这个事情还是需要继续做，只是测试任务的执行主体变成了开发工程师，本文介绍的大量后端测试的技术和方向还会继续存在。后端服务类测试团队转型，除了效能工具之外，第五部分的线上稳定性的建设是一个非常好的方向。 2 测试的线上化，既 TIP（Test In Production） 这个概念大概十年前由微软的工程师提出。TIP 是未来测试方法上的一个方向，主要的考虑是以下三点。 1）一方面由于线下测试环境与真实线上环境总是存在一些差异，或者消除这种差异需要较大的持续成本，导致测试结论不够置信。使用最多的就是性能测试或容量测试，后端服务的拓扑非常复杂，且许多模块都有可扩展性，带有不同的数据对性能测试的结果也有很大的影响，测试环境与生产环境的这种不同会带来测试结果的巨大差异。另外，目前的生产集群都是异地多活，在夜里或者流量低谷的时候，单个集群就可以承担起所有流量请求，剩下的集群可以很方便地用来压测，这也给我们在线上做性能测试带来了可能性。最具典型的代表就是阿里的双十一全链路压测，今年基本上都是在白加黑的模式下完成的。 2）另外，许多真实的演练测试也只能在线上系统进行，例如安全攻防和故障注入与演练，在线下测试环境是无法做到的。 3）最后，从质量的最终结果上看，不管是发布前的线下测试，还是发布后的线上稳定性建设，其目的都是为了减少系统故障的发生，把这两部分融合在一起，针对最终的线上故障的减少去做目标优化工作，可以最大程度地节约和利用人力资源。我们判断，线下测试与线上稳定性的融合必将是一个历史趋势，这一领域统称为技术风险的防控。 3 测试技术的智能化 见图 3。类似对自动驾驶的分级，智能化测试也有不同的成熟度模型，从人工测试、自动化、辅助智能测试、高度智能测试。机器智能是一个工具，在测试的不同阶段都有其应用的场景，测试数据和用例设计阶段、测试用例回归执行阶段、测试结果的检验阶段、线上的指标异常检测诸多技术风险领域都可以用到不同的算法和模型。智能化测试是发展到一定阶段的产物，前提条件就是数字化，自动化测试是比较简单一种数字化。没有做到数字化或者自动化，其实是没有智能分析与优化的诉求的。 另外，在算法的使用上，一些简单算法的使用可能会有不错的效果，比较复杂的深度学习甚至强化学习算法的效果反而一般，原因或者难点在两个地方，一个是特征提取和建模比较困难，第二个原因是测试运行的样本与反馈的缺失。但无论如何，运用最新的算法技术去优化不同的测试阶段的效率问题，是未来的一个方向。但我们同时判断，完全的高度智能测试与无人驾驶一样，目前还不成熟，主要不在算法与模型，而是测试数据的不足。 图3 测试技术的智能化 阿里的搜索推荐与广告系统的质量建设之路，经过近 10 年的不断发展，在许多前辈的不断努力付出之下，才能在如此众多的细分领域方向上开花结果，本文所介绍的方法也都浓缩在内部的工具兵器之中，后面我们的想法还是逐渐开源，回馈社区。限于篇幅，内容又较杂多，很多技术细节这里并没有办法细细展开。如果想了解更多，后继可以关注即将由阿里经济体技术质量小组主导出版的测试书籍《阿里巴巴测试之道》（电子工业出版社，暂定书名），本文所介绍的大数据AI算法应用测试被收录在第六章。如果还是需要更加详尽的了解，也欢迎大家加入我们的团队或者开源社区，一起在以上的几个方向做更加深入的研究与建设。
滑动查看更多
2020年04月
-
04.23 10:19:30
发表了文章
2020-04-23 10:19:30
跟随弹幕停不下来？智慧文娱还有哪些新玩法
跟随弹幕停不下来？智慧文娱还有哪些新玩法
-
04.21 18:05:49发表了文章
2020-04-21 18:05:49
Java 正青春：现状与技术趋势报告
Java 正青春：现状与技术趋势报告
-
04.20 11:10:45发表了文章
2020-04-20 11:10:45
国内 Java 开发者必备的两个装备，你配置上了么？
国内 Java 开发者必备的两个装备，你配置上了么？
-
04.20 10:34:17发表了文章
2020-04-20 10:34:17
App 开发神仙工具：帮你抓 Bug
App 开发神仙工具：帮你抓 Bug
-
04.17 09:56:09发表了文章
2020-04-17 09:56:09
程序员：除了技术，还有什么更重要？
程序员：除了技术，还有什么更重要？
-
04.16 11:21:16发表了文章
2020-04-16 11:21:16
架构方法论：如何自底向上推导应用逻辑？
架构方法论：如何自底向上推导应用逻辑？
-
04.11 23:46:14发表了文章
2020-04-11 23:46:14
天猫精灵如何和我们聊天？
天猫精灵如何和我们聊天？
-
04.11 23:44:01发表了文章
2020-04-11 23:44:01
AutoML 应用探索：如何让 AR 扫福更顺滑？
AutoML 应用探索：如何让 AR 扫福更顺滑？
-
04.11 23:36:37发表了文章
2020-04-11 23:36:37
阿里巴巴首次揭秘电商知识图谱AliCoCo！淘宝搜索原来这样玩！
阿里巴巴首次揭秘电商知识图谱AliCoCo！淘宝搜索原来这样玩！
-
04.11 23:29:15发表了文章
2020-04-11 23:29:15
每天几十万条用户反馈，高德工程师如何提升处理效率？
每天几十万条用户反馈，高德工程师如何提升处理效率？
-
04.11 23:08:23发表了文章
2020-04-11 23:08:23
程序员修炼之路：你该知道的 7 个必经阶段
程序员修炼之路：你该知道的 7 个必经阶段
-
04.11 22:52:27发表了文章
2020-04-11 22:52:27
从方法到思维：什么是应用逻辑架构的正确姿势？（上）
从方法到思维：什么是应用逻辑架构的正确姿势？（上）
-
04.10 10:15:28发表了文章
2020-04-10 10:15:28
看完这一篇，再也不用担心 Git 的“黑魔法”
看完这一篇，再也不用担心 Git 的“黑魔法”
-
04.09 10:14:05发表了文章
2020-04-09 10:14:05
Serverless 的喧哗与骚动
Serverless 的喧哗与骚动
-
04.08 12:10:23发表了文章
2020-04-08 12:10:23
Serverless 领域近一年行业发展回顾
Serverless 领域近一年行业发展回顾
-
04.06 23:42:08发表了文章
2020-04-06 23:42:08
火了这么久的 AI，现在怎么样了？
火了这么久的 AI，现在怎么样了？
2020年03月
-
03.27 11:01:46发表了文章
2020-03-27 11:01:46
给 DSL 开个脑洞：无状态的状态机
给 DSL 开个脑洞：无状态的状态机
-
03.25 23:00:54发表了文章
2020-03-25 23:00:54
NLP如何突破深度学习的能力边界？
NLP如何突破深度学习的能力边界？
-
03.25 22:46:34发表了文章
2020-03-25 22:46:34
AI 训练数据不够用？支付宝 3D 合成数据方案揭秘
AI 训练数据不够用？支付宝 3D 合成数据方案揭秘
-
03.24 23:13:00发表了文章
2020-03-24 23:13:00
远程研发能有多高效？手淘新版本上线只用了5天！
远程研发能有多高效？手淘新版本上线只用了5天！
滑动查看更多
-
发表了文章
2020-04-30
机器学习领域技术大图：硬件算力
-
发表了文章
2020-04-30
边缘端手势识别：AI 交互的正确打开方式
-
发表了文章
2020-04-30
飞猪的“猜你喜欢”如何排序？
-
发表了文章
2020-04-30
跑赢业务的同时如何实现技术成长？
-
发表了文章
2020-04-30
深度 ｜ 大数据算法应用的测试发展之路
-
发表了文章
2020-04-30
如何轻松学习 Kubernetes？
-
发表了文章
2020-04-27
《Java 开发手册》的前世今生
-
发表了文章
2020-04-27
重启大法好！线上常见问题排查手册
-
发表了文章
2020-04-24
一个好的组件应该是什么样的？
-
发表了文章
2020-04-23
跟随弹幕停不下来？智慧文娱还有哪些新玩法
-
发表了文章
2020-04-21
Java 正青春：现状与技术趋势报告
-
发表了文章
2020-04-20
全本开放下载！史上最强《Java 开发手册》泰山版王者归来
-
发表了文章
2020-04-20
国内 Java 开发者必备的两个装备，你配置上了么？
-
发表了文章
2020-04-20
App 开发神仙工具：帮你抓 Bug
-
发表了文章
2020-04-17
程序员：除了技术，还有什么更重要？
-
发表了文章
2020-04-16
架构方法论：如何自底向上推导应用逻辑？
-
发表了文章
2020-04-15
从原生到黑科技：闲鱼 Flutter 图片优化经历了什么？
-
发表了文章
2020-04-14
Java 的这些坑，你踩到了吗？
-
发表了文章
2020-04-13
TeaDSL：支持任意 OpenAPI 网关的多语言 SDK 方案
-
发表了文章
2020-04-11
阿里巴巴开源 Graph-Learn：大家都能玩的 GNN
滑动查看更多
暂无更多信息