在科技进步带来巨变的时代，价值观的书写、思想的沉淀至关重要。
一年来，新零售业务快速发展。淘宝推出“平铺直达”战略，重塑家居行业电商模式。云原生浪潮兴起，核心交易系统100%云化。端侧AI实时智能决策，推理引擎MNN开源。音视频实时通讯引擎将直播时延降低至1秒以内。淘宝直播，创造了全球内容电商市场的技术巅峰……
新场景、新用户路线、新架构不断带来新挑战，新产品、新技术以及实时自我更新的淘宝技术人员通过反复思考和技术升级，不断接近最佳极限。
交易数字一次次吸引人们的眼球，我们相信，这些在背后默默耕耘、支撑，打造出全球领先的线上新零售技术平台的技术，不应该被埋没在历史的记忆中。
于是，我们就见面了。
这里汇集了2020年阿里巴巴淘宝技术的精华，涵盖了大前端、音视频、端智能、用户增长、客户端架构、服务端架构、云原生、技术质量、AI等多个技术领域，积累了618、双11大促、阿里拍卖、淘宝直播等多个业务的技术解决方案，更有淘宝工程师推荐书单、开源项目、顶级会议论文等多角度的知识价值输出。
本书有1500多页，总计近40万字，下面我们就来简单介绍一下全书的内容。
各技术栈最新前沿技术的技术讲解
前端、算法、后端、音视频、客户端等等，每个领域我们都精选了今年最新最热的技术文章，实时掌握技术前沿是每个技术人都不容错过的。
前端
在前端篇章中，在支撑淘宝、天猫等复杂多变的业务场景的过程中，淘宝前端建立了前端工程化、多端架构、Node架构、多媒体、交互、构建、智能等多个基础技术体系，并且还在不断演进升级。我们重点从前端与客户端结合突破多端体系、结合云原生面向体系、结合AI能力建立前端智能化应用场景三个维度来介绍我们的技术方案和背后的思考。比如我们以2020年淘宝、天猫双11的前端系统建设为例，给大家分享我们最新的双11前端建设技术方案，“必须”高效支撑，确保业务先赢，“必须”保证体验和稳定性，为用户带来极致的体验，“必须”追求创新，让前端不断演进，包括应用大量的优化手段和创新方案，带来业务转化的提升； 将FaaS、PHA、ESR等技术应用到更多的场景，进一步将前端的能力和边界拓展到服务端、客户端、CDN节点；应用可视化还原、一体化研发等提升研发效率并极大缓解资源瓶颈等，并与业界同仁分享我们的技术方案和思想沉淀。
算法
在算法部分，淘宝技术有着大量的算法应用场景，从这些场景中我们涵盖了内容与商品推荐、多模态内容理解、用户交互与工程等算法应用。例如在淘宝场景中，为了提升用户的浏览深度，我们从召回和CTR预估两个关键环节进行探索和创新：使用序列生成任务训练，提取其顶层输出向量进行内容召回，召回效果超过内容协同；将常规序列兴趣的直接表达转化为序列兴趣的匹配度，并基于此先验假设设计辅助loss，鼓励模型有重点地学习，最终在线上线下指标均取得增益，大幅提升了推荐效果，取得了显著的商业效益。淘宝技术工程师们正在用全新的人工智能方法重新定义和解决问题，突破原有的问题领域，实现更大的技术目标。这些解决问题的新方法、新思路，结合解决问题过程中的一手工作经验，理论与实践相结合，值得算法从业者和对算法感兴趣的读者借鉴。
模型架构
后端
在后端部分，随着我们淘宝服务体系的业务发展，技术进入深水区，驱动技术团队深入思考架构，形成一系列业务平台，推动领域架构设计进步，自下而上更高效地解决业务问题。例如我们自研的IETF QUIC标准协议库实现了XQUIC方案，证明了QUIC的核心优势在于用户态传输层实现（具备针对业务场景灵活调优的能力），而非单一针对弱网的优化。在业务场景拓展方面，除了RPC、短视频、直播等场景，XQUIC还可以针对上传链路等其他场景进行优化。针对5G下eMBB（）和URLLC（Ultra Low）带来的不同高带宽/低延迟业务场景，QUIC将能够更好地发挥优势，根据场景需求调整传输策略（拥塞控制算法、ACK/重传策略）。 这些内容从不同角度呈现了过去一年来在架构和基础技术的探索，对业界有很高的参考价值。
XQUIC端到端架构设计及内部分层模块
音频和视频
在今年大热的音视频领域，我们在2020年围绕淘宝直播、短视频等核心场景，在编解码、低延时直播、直播亮点等方面都取得了不错的成绩。比如2020年双11，我们集结了达摩院语音实验室、阿里云PAI团队、淘宝科技直播APP、终端智能MNN团队等全明星阵容，齐心协力实现了业界首个直播移动端语音识别。在这个项目上，我们选取了“基于SAN-M的离线端到端语音识别”方案，通过极限的模型压缩和性能优化，最终实现了模型大小小于15MB、内存占用小于60MB、1s语料识别速度快于50ms的高性能方案，解决了高精度高性能本地语音识别、语音模型和资源包规模大、终端资源有限、性能压力大三大核心技术难题。
此外，还有客户端、MNN、端智能技术、实践等多个技术栈领域的思考与分享，以及各技术领域常见问题、解决方案与技巧分享，还有专家对2020年技术资讯的解读，比如关于WWDC 2020的系列研究分享，都值得技术同学们阅读。
淘宝技术大牛工作学习心得问答记录
如何学习？如何评价？如何看待？
针对社区中热门的学习讨论问题，我们邀请了阿里部分工程师从个人角度分享实践经验，或针对某一技术话题发表感想，获得了大量点赞和认可。我们把这些精彩的问题和答案收集起来，一次性“喂饱”你的好奇心和学习热情。
例如：
Q：在开发推荐系统时，您遇到过什么陷阱？
A：数据错误、线上线下不一致、锦上添花却不能雪中送炭，是构建推荐系统的三大陷阱。
一、数据错误
推荐算法是最容易出现数据错误的算法领域，很多机器学习应用的数据来源于标注，数据错误很容易被发现，而推荐算法依赖的数据来源于用户行为反馈，极易出错，且极难发现。
当用户点击屏幕时，行为的上下文和推荐商品的上下文需要由客户端发送到服务器，服务器上报给日志系统，日志系统将数据导入大数据平台，算法才能开始工作。商品推荐上下文通过推荐接口传输到服务器，服务器带到前端，前端必须解析后才能使用。
这样的整个环节出现错误的可能性实在是太多了，当出现错误的时候很难意识到错误的存在，更别说排除错误了。
我给大家讲一个很愚蠢的错误。在刚上线的一个业务中，我根据几天的日志建立了一个排名模型。它也产生了收入，看上去没有任何问题。当时唯一奇怪的是，这个场景的 PV 是 UV 的 100 倍，也就是平均每个人的浏览量是 100。根据经验，这个数字比之前同类业务高出好几倍。这个数字曝光了一个星期，大家都只是好奇，没有人真正怀疑过。
从感觉到不对劲到检查确认原因再到解决问题大概用了一周的时间。之前服务端有一个链接把创作者的ID和用户的ID搞混了，所以每个人的浏览量是100个，实际的UV数才是创作者的数量。问题修复之后，推荐效果翻倍了！
二、线上不一致
在做排序模型的时候，我们针对离线某一个指标疯狂优化，然后想象上线之后这个指标会大幅度提升，其实这时候离成功还有一个巨大的坑——离线一致性。
离线和在线不一致可能来自于人为的错误。离线特征处理和在线特征处理自然是两个不同的过程，出现问题的可能性非常高，但可以通过一开始的仔细检查来避免。甚至可以用一套组件来抽象和处理关键的离线和在线过程，以减少出错的可能性。另一类离线和在线不一致来自于系统本身，在系统限制下是不可避免的。当然可以通过升级系统来缓解，但成本曲线也会变得非常陡峭。下面我们重点讨论这一点。
很多推荐系统的排序模型都是在系统升级前或者业务初期的T+1更新，离线的时候用Tn天到T-1天的数据训练模型，用T天的数据进行评估，这样离线指标会非常好，比如AUC可以达到0.72。但是在线服务的模型并不是这样理想的情况，每天都会重新训练一个模型，需要新的一天（T-1天）的日志。日志从数据队列传输到大数据平台，经过处理，计算新的一天的各项特征，整理训练样本，进行模型训练。之后还要从大数据平台将模型更新到在线服务器，整个过程需要一个小时左右（图中例子是11点10分）。所以在新的模型上线之前，也就是11点10分之前，在线服务是T-2天的模型，相当于离线用T-2天的模型来评估T天的样本，效果会大打折扣。 因此，全天在线的平均评价指数低于线下评价指数。
在某些业务和模型中，T-2 和 T-1 的差别可能没那么大，但推荐系统非常依赖 ID 型记忆特征，T-2 可能会导致效果非常差。这时候你的模型越早上线，效果就越好。有可能你增加了离线特征的处理流程，使用了复杂的特征和模型，AUC 提升了一个点，但模型晚上上线 3 个小时，上线效果可能就掉坑了。
升级到每小时模型更新，甚至流式更新，可以避免这个系统性问题。当然，成本也会增加，而且会有更多的新陷阱需要攀登。
再说一下特征的不一致问题，如果是日级计算的离线特征，也存在和上面讲的模型不一致类似的问题，而且使用实时特征也存在隐藏的不一致问题。
实时特征在线上使用时，客户端上报、流计算处理日志数据、进入在线数据源或者特征服务器需要几秒到几十秒的时间。也就是说，如果你刚点开鞋子，然后往下翻页，系统是拿不到鞋子的。如果离线模型训练使用带有鞋子的特征，由于近期行为的影响很大，与在线模型不一致的情况会非常严重。
为了离线获取实时特征，一种方法是通过离线日志复制实时特征，依靠日志记录的时间戳。如果只是样本的时间戳大于行为的时间戳，那么线上和线下就会出现不一致。比较明智的做法是留出时间间隙，让离线和线上尽可能一致。另外需要注意的是，样本的时间戳不是用户曝光行为的时间戳，而是推荐系统的时间戳，否则也会使用线上无法获取的交叉特征。
还有一种方法是通过日志系统直接记录线上使用的特征。如果线上时间差距在5~40秒，虽然线上线下整体一致，但对于某个样本，可能记录了最近的行为，而可能丢失了最近的行为。这比离线复制实时特征要好得多。唯一的问题可能是在初始模型上线前必须积累一定天数的实时特征日志，每次特征修改都要等待一段时间积累日志。
第三，你可以锦上添花，但无法在事情艰难时提供帮助。
很多产品经理把推荐算法当成产品最后的希望，把用户增长的希望寄托在推荐算法上，然而推荐系统只能起到锦上添花的作用，并不能起到雪中送炭的作用。
没有或者弱推荐系统，可以赚10亿，通过优化可以多赚3亿。推荐系统很有意义，如果一个产品用户少，靠输血才勉强维持体面的地位，单靠推荐算法做几倍增长真的无能为力，非傻推荐系统和优质推荐系统之间的差距，根本不可能做几倍增长。
那些增长案例，比如 Mail的5G空间突破性增长，发现用户关心的核心因素是房间的照片，并携带专业设备一张一张地拍照来实现增长。这些都是为了满足用户未被满足的需求，聚集大量用户。非傻瓜式的推荐系统没有门槛，升级到优质的推荐系统并不能满足任何新的需求。依靠推荐系统实现大规模的用户增长和产品成功是错误的努力方向。
清晰有力，一针见血。类似的问题和答案我们还有很多精彩的回答。欢迎下载整本书一起学习交流~
书中的一些问题如下：
入选高三技术人员必读书目
今年的书单由众多阿里工程师推荐，涵盖技术硬核参考、商业思维修炼、文化、科普、工具方法等多个类别，对技术人员的成长有很大的帮助，希望成为你2021年的精神食粮。
附上阿里巴巴淘宝技术部高级算法专家乐天的推荐，供大家参考。
算法导论
我遇到过计算机系的学生，他们喜欢讨论这本书的内容。为了建立共同语言，我读了这本书的大部分内容。我也做了里面的问题，包括数学证明。但后来我发现计算机系的学生不再讨论这个了。现在还有用的是DP，不动点。
“博弈论”
很cool，看了几篇老论文，学了一些拓扑，理解了不动点定理。博弈论是分析非完全合作智能体组成的系统的必备基础知识，包括这两年火起来的GAN，里面也有博弈论的思想。
“中心”
它探索中国是什么，从古到今，从国内到世界，从内部介绍中原、草原、高原、海洋的统一联系，从外部探讨中国作为连接海洋秩序和大陆秩序桥梁的可能性。
经典力学
从事机器学习的同学对最小化目标函数一定不陌生，高中时学过的牛顿定律也有类似的表达，即最小作用量原理，朗道的《经典力学》则提供了新的数学视角，美的理论应该尽量减少分类学的使用，用尽可能少的约束最小化目标函数来代替。
淘宝四大经典开源项目介绍
我们倡导通过开源项目和技术产品回馈社区，共同构建繁荣的技术生态。这里的11个经典淘宝开源项目也离不开你的参与和贡献，欢迎大家继续共建和探讨。
比如现在比较火的Rax，它是一个支持Web/Weex/小程序同时开发的框架，通过Rax可以实现一次开发，多端运行，摆脱重复劳动，专注于产品逻辑，提高开发效率。
在前端道路上，淘宝FED的使命一直是“用技术为体验提供无限可能”，而Rax自然也是在对体验的追求中诞生的。
从2014年开始，结合阿里巴巴双十一、双十二的数据变化，无论是从用户访问量还是最终的交易额，都可以清晰的看到：“移动端已经成为当下商业的主战场。”当商业重心转移到移动端时，技术也在悄然发生着变化，传统成熟的PC端技术方案似乎已经无法满足移动端对于体验性能、开发效率等多方面的要求。这也开启了我们在无线端的技术探索之路。
2014 年初，阿里巴巴的无线业务刚刚起步，那时的无线页面还叫 H5，Kissy 等库对于无线页面来说过于庞大、加载速度太慢。于是我们基于成熟社区 Zepto 迅速搭建了 kimi 核心库，随后围绕业务不断完善 kimi 组件生态以及包括工程、性能测试等一系列生态。这个生态陪伴我们已经快两年了，今天在一些页面上你仍然可以找到 kimi 的影子。
但 Kimi 始终是 Web 端的解决方案，即便有些方案可以调用原生的方法，但还是无法克服无线端的 Web 体验不如 Web 端的既定事实，因此如何让页面体验更好成为我们下一个探索点。
从体验上来说，最直观的解决办法就是直接写代码。然而开发模式中总会存在一些难以解决的问题：
因此我们需要一个基于 Web 开发模式，但又能生产页面，兼顾效率和体验的解决方案。阿里巴巴也基于这个想法做过一些尝试，但都没有形成最终的解决方案，这里就不多说了。直到 2015 年中旬，React（RN）才开源，虽然早期只有 iOS 版本，但并不影响它对整个无线开发解决方案带来的巨大影响。RN 基本完美解决了两端都需要写代码的问题，而且还有非常活跃和完善的 React 社区，所以这个方案也得到了很多开发者的青睐。
然后，我们很快在手机淘宝上尝试了 RN 的解决方案。由于 RN 的兼容性问题，以及用户可能会在浏览器端打开页面，所以整个页面必须能够降级到 Web 版本。这时候回想起 RN 的口号：learn once, write。但这对我们来说可能还不够，我们真正需要的是：write once, run。于是我们开始探索如何让 RN 的代码在 Web 端运行起来，也就是 react-web 的解决方案。
社区里很多人都关心 Rax 和 React 的优劣，以及互相替代的可能性。其实从上面的发展历史我们可以看出，Rax 只是无线方案，和 React 并无冲突。其实淘宝新开的 PC 项目还是以 React 为主，而我们也有基于 React 的解决方案叫 ICE，通过一系列工具帮助开发者提升效率。
当然，Rax 和类似的方案有着本质的区别，前者更偏向于解决多端问题，而后者更偏向于解决性能问题。我们 Rax 的特点是：
设计用于支持不同的容器
Rax 在设计上抽象出概念，以支持在不同容器中渲染，比如目前支持的：Web、Weex、。基于概念，即使未来出现更多的容器（比如 VR 等），Rax 也能从容应对。Rax 在设计上尽量抹平各端的差异，这也意味着开发者不再需要在差异和兼容上投入过多的精力。
足够小
上面提到了，Rax 是针对无线端的解决方案，因此它的大小对于性能来说非常重要。压缩 +gzip 之后 Rax 的大小为 8.0kb，相比 React 的 43.7kb，对无线端友好很多。
支持返回多个兄弟节点
使用过 React 的小伙伴大概都遇到过同样的坑：一个方法返回了多个同层级的节点，结果报错。React 设计上只能返回单个节点，所以页面上或多或少会存在冗余节点。这个在 PC 端问题不大，但在无线端，嵌套层级越多，应用的崩溃率就会越高，在低端机器上尤其明显。因此，Rax 支持返回多个同层级节点的功能，比如：
import {createElement, Component, render} from 'rax';class Test extends Component {render() {return [1, 2, 3].map((item) => {return <p>{item}p>;});}}
该功能可以有效减少页面的嵌套层数，从而减少因嵌套层数过多而导致的应用程序崩溃问题。
标准化
上面我们不断提到各个端的一致性，有一致性就一定有规范可循，Rax 遵循 W3C 标准，比如在 Weex 容器中，可以直接调用 W3C 标准 API 如： 、 、 alert 等。
当然，由于各端的差异性，标准化之路还很漫长，“更加标准化”也是Rax未来的重要目标之一。
“一次编写，即可运行”是口号，也是目标。未来 Rax 还会继续探索更多的终端，比如 VR/AR。甚至有同学在微博上提出要不要用 Rax 写微信小程序，这也是一个有意思的想法。对于开发者来说，当越来越多的终端不断出现在我们面前时，我们该如何应对？是要通过不断踩坑，整理出一个长长的清单，然后在做项目的时候一一对比？还是大家一起来探索 Rax？
多年来，阿里淘宝技术一直积极拥抱开源，无论是开源软件的应用、反馈还是自研技术的开源。近两年我们开源了MNN、ICE、3D-、3D-FRONT等项目，也得到了开源社区开发者的广泛支持和使用。欢迎大家多多讨论交流。
5 2020淘宝Top 大会论文全文
我们按照计算机协会定义的 CCF-A 级会议和期刊，遴选出了大数据与数据挖掘、移动计算、信息检索等 7 个领域 19 篇顶级会议论文，涵盖 KDD 2020、SIGIR 2020、AAAI 2020 等多个国际会议，对相关领域感兴趣的技术从业者或许可以从中一窥自身领域的下一步方向。
终于
这本书内容非常丰富，总页数超过1500页，总内容近40万字，我们以开放、自由的沟通心态，输出阿里巴巴淘宝工程师对技术和业务的理解，真诚希望在更丰富的场景中与大家交流，共同探索技术和商业的未来形态。
希望大家喜欢并且分享给有同样兴趣的同事、朋友，让我们互相学习，共同成长。