学习积分/结营测试成绩/学习之星/邀请数据/论坛获奖等数据已公布在活动帖留言区（置顶），点击链接查看https://bbs.huaweicloud.com/forum/thread-101458-1-1.html

Uniform convergence may be unable to explain generalization in deep learning收敛一致性可能解释不了深度学习中的泛化现象推荐理由：为了探究深度学习泛化能力背后的原理，学术界提出了泛化边界的概念，然后尝试用「收敛一致性」理论推导、设计出了各种各样的泛化边界描述方法，似乎已经取得了不少成果。但这篇论文中作者们通过大量实验发现，虽然其中的许多泛化边界从数值角度看起来挺大，但随着训练数据集大小变大，这些泛化边界也会跟着变大。在此基础上，作者们用过参数化的线性分类器和梯度下降训练的神经网络为例，证明了收敛一致性并不能解释模型的泛化性，即便完全考虑了梯度下降可能带来的隐式偏倚也解释不了。更严谨地说，作者们实验表明，根据收敛一致性得到的泛化边界要比根据梯度下降得到的泛化边界大得多。根据这一系列结果，作者们对「用基于收敛的方法解释泛化能力」的做法提出严重的质疑。虽然这篇论文并没能解决（也没打算解决）深度神经网络中的泛化性问题，但它显然为整个领域指出「此路不通，考虑重来」。这篇论文获得 NeurIPS 2019 杰出新方向论文奖。论文地址：https://papers.nips.cc/paper/9336-uniform-convergence-may-be-unable-to-explain-generalization-in-deep-learning    转自，杨晓凡，https://www.leiphone.com/news/201912/TK9EEFIUdjdbAC4J.html

机器学习和深度学习的未来蕴含着无穷的可能！越来越多的机器人不仅用在制造业，而且在一些其他方面可以改善我们的日常生活方式。医疗行业也可能会发生变化，因为深度学习有助于医生更早地预测或发现癌症，从而挽救生命。在金融领域，机器学习和深度学习可以帮助公司甚至个人节省资金，更聪明地投资，更有效地分配资源。而这三个领域仅仅是机器学习和深度学习未来趋势的开始。许多需要改进的领域，现在仍然只是我们想象中的一个火花。

机器学习利用 机器学习技术， 计算机 可学会分析数据，识别 隐藏的模式，进行分类，并预测未来的结果。我们的调查 显示，67 的受访者目前正在使用 机器学习，且有 97% 正在 使用或计划在明年使用机器学习 。深度学习深度学习是机器学习的一个子集，它基于一 个名为“神经网络” 的人脑概念 模型。之所以被 称为深度 学习，是因为这种神经网络 有多个相互连接的层 。我们 的受访者中 ，有 54% 表示他们使用了深度学习技术， 95 正在 使用或计划在明年使用 。自然语言处理自然语言处理是 一种从可读的、风格自然的、语法正确的文本中提取或生成意义和意图的 能力 。 58 的全球受访者已采用 自然语言处理技术，有 94%正在 或计划在明年使用自然语言处理技术。计算机视觉是 一种从视觉元素中提取意义和意图的能力，包括字符识别（针对数字化文档）和图像（如人脸、物体、场景和活动）内容分类。 在 我们的受访者中有 56% 声称他们使用了计算机视觉 94表示正在 使用或计划在明年 使用。

4、对话 AI 和图好了，硬核的机器学习算法讲得差不多了，下面我们看点轻松的，比如NLP应用。和NeurIPS正会一起开的workshop里有很多有趣的对话AI+图的论文。论文12：Multi-domain Dialogue State Tracking as Dynamic Knowledge Graph Enhanced Question Answering链接：http://alborz-geramifard.com/workshops/neurips19-Conversational-AI/Papers/51.pdf这篇论文提出了一个通过问答追踪对话进度（Dialogue State Tracking via Question Answering (DSTQA)）的模型，用来在MultiWOZ环境中实现任务导向的对话系统，更具体地，就是通过对话帮助用户完成某个任务，任务一共分为5个大类、30个模版和超过4500个值。它基于的是问答（Question Answering ）这个大的框架，系统问的每个问题都要先有一个预设模版和一组预设的值，用户通过回答问题确认或者更改模版中的预设值。有个相关的假说提出，同一段对话中的多个模版、多组值之间并不是完全独立的，比如，你刚刚订好五星级酒店的房间，然后你紧接着问附近有什么餐馆，那很有可能你想找的餐馆也是中高档的。论文中设计的整个架构流程很繁琐，我们就只讲讲他们的核心创新点吧：首先，作者们把对话状态建模为一个根据对话内容逐渐扩充的动态知识图。图中的节点由大类、模版和值构成，建立节点之间关系的过程也利用了上面那个假说，就是因为不同的模版之间有一些值可以是相同的、部分重叠或者是有关联的。其次，用一个图注意力网络（Graph Attention Net）学习为图中的节点分配权重，网络的输出也会被送入一个门机制，用来决定要在问题文本中表现出图的多大的一部分。作者们也使用了角色嵌入，这样模型可以由系统的话语和用户的话语共同训练  最后，作者们同时使用了CharCNN和ELMO嵌入来做对话文本内容的编码   转自，杨晓凡，https://www.leiphone.com/news/201912/GsRSElsUReef0z7o.html

来源：隐私计算联盟成员-中国工商银行软件开发中心作者：强锋，张闯一、背景近年来，数字经济蓬勃发展，已经成为带动中国经济增长的核心动力。2020年4月9日，**国务院发布了《关于构建更加完善的要素市场化配置体制机制的意见》（以下简称《完善意见》），首次将数据与土地、劳动力、资本、技术等传统要素并列为生产要素，这表明数字经济时代，数据成为新的关键生产要素，已成为社会基础性战略资源，蕴藏着巨大潜力和能量，必将成为提升金融行业赋能实体经济的有力抓手。随着大数据技术的快速发展，人们每天的活动产生了大量的数据，这些数据被众多的企业收集和使用，数据在空间和时间里面流动产生了价值。在价值产生的过程中，需要对数据进行保护。但是数据往往分布在不同的企业、机构，形成了如图1所示的一个个数据“孤岛”。例如，在机构间，尤其政府部门，很多数据没有充分共享。又比如银行和税务，希望通过银税合作来获取客户的风险评估信息。在企业内部也是如此，集团化的企业公司越来越大，子公司、分公司，就连部门内部的系统都可能是自己分别开发的，数据之间完全孤立。为了挖掘数据中蕴藏的巨大价值，消除行业数据孤岛现象，让数据相互之间协作起来，必然是未来发展趋势。数据在为人们的生活带来了种种便利的同时，也使得大家对于个人的数据隐私和安全带来了担忧，这俨然已经成为世界性的问题。各国针对这个情况，纷纷立法进行规范，例如：欧盟提出了《通用数据保护条例》(General Data Protection Regulation, GDPR)，该法案已于2018年起正式生效；中国也在制定《个人信息保护法》，用以加强监管。可见，对用户数据隐私和安全管理的日渐收紧已经成为了必然的趋势。这就对企业利用数据开展业务提出了一个挑战。如何才能在遵循法规的要求下，即充分发挥数据的价值，同时又不会影响到用户的数据隐私和安全？尤其是对于依赖外部数据的企业，如何能够利用合作伙伴的数据价值，又不会见到原始数据，造成数据泄露的问题？针对这一情况，近年来，学术界和工业界都已经开始在数据安全和隐私保护方向的探索，尤其是在大数据、人工智能和密码学等领域。如何在满足数据隐私、安全和监管的前提下，设计一个机器学习框架，让人工智能能够更高效、更准确的共同使用各方数据成为了研究的核心，联邦学习应运而生。图1. “数据孤岛“现象普遍存在二、联邦学习(一) 什么是联邦学习1、联邦学习的内涵联邦学习，是一个机器学习框架，能有效帮助多个机构在满足用户隐私保护、数据安全和政府法规的要求下，进行数据使用和机器学习建模，能够有效的解决数据孤岛、数据合规性以及两者的冲突，进而达到“数据可用不可见”的目标。联邦学习从名字上看，有两个明晰的主题：学习和联邦。什么是学习？这个概念源自于我们谈论的数据和信息。数据一般被认为是原始素材，客观描述事物的数量、属性、位置等关系。信息则是经过加工处理之后、具有逻辑关系的数据，通常会是对决策有价值。学习的内容是知识，知识则更多是在信息上再进一步归纳演绎之后，沉淀下来的有价值的信息。通常情况下，学习到的知识被认为是与决策有关的。从学习到联邦，其最终目的是希望通过一种安全的方式解决数据孤岛现象，达到“数据可用不可见”的目标。在联邦学习里，联邦本质上是一种安全协议下的数据交换共享，目的是有效利用各参与方的数据来进行知识的共创、共享和推理。2. 联邦学习的外延联邦学习与很多技术有一定关系，比如可信执行环境、密码学、隐私计算。例如，可信执行环境是一种芯片级的硬件安全计算技术，联邦学习可以依靠这种方式来实现更高的硬件层面的安全性能。如表1所示，列举了在联邦学习中涉及到的相关技术和算法。表1. 联邦学习相关技术3. 数据可用不可见数据可用不可见，即充分利用各方的数据，让数据保持对外开放，同时能够让数据不直接共享，不离开机构或个人。为了实现“数据可用不可见”这个目标，传统的中心化计算模式，也就是大数据经常会做的中心化聚集，把数据存储聚集再做训练，已经不能满足合规性的要求。中心化不可行，那就让数据分散在各个机构中，采用分布式或者去中心化方式计算或学习。在真正的实践中，通常采用一种弱中心化方式，过去强中心化大数据集成方式是不可行的，主要是安全存在很大隐患。但是完全的去中心化，也很难兼顾效率。弱中心化方式更多是一种强中心化和去中心化的折衷。原始数据直接共享不可行，我们可以采用两种方式，第一种方式是对数据进行加密，加密后也不破坏原始数据的统计特征。第二种方式，可以将数据知识化，也就是说将数据转化成一种模型策略的知识，再把这些分散的知识聚合在一起，实现数据的可用。(二) 联邦学习的模式1. 数据视角根据数据分布形式，联邦学习的模式可分为跨样本联邦（横向联邦）、跨特征联邦（纵向联邦）、复合型联邦（联邦迁移）。跨样本联邦的目的是要充分利用数据服务提供方的样本和标签数据，让各参与方利用私有数据在本地进行训练，再通过模型聚合方式不断更新模型。相同性质的机构之间拥有相似特征指标但是样本分布不同，通常采用跨样本联邦的模式，比如多个消金机构之间可以联合进行多头风险分析。跨样本联邦也称作横向联邦学习。跨特征联邦由于可能只有一个参与方有标签数据，由于模型需要多方数据才能训练，模型推理时也同样需要多方数据才能完成。跨特征联邦在金融行业有非常广泛的应用需求，不同性质的机构之间拥有的特征指标会差异很大，通常采用跨特征联邦的模式，比如银行与互联网机构之间进行联合智能风控、信用评估、反欺诈。跨特征联邦也成为纵向联邦学习。复合型联邦，只有一小部分样本或特征集是各参与方的交集，其余数据无论是特征分布还是样本分布都不尽相同。这种场景下，涉及跨样本联邦和跨特征联邦的组合。这种联邦在实际应用中更为常见，比如甲城市面向当地客户的保险公司、乙城市面向当地居民的医疗机构，两方联合训练核保模型。2. 应用视角从联邦应用视角来看，联邦学习的应用流程可划分为如图2所示的三个阶段，包括联邦预数据探查、联邦模型训练、联邦模型推理三个阶段。图2. 联邦学习应用流程参与方生成联邦模型之前通常需要预先对样本、数据进行联邦数据探查，联邦数据探查是指在保障数据安全和隐私的前提下对数据进行的一些处理和统计分析，包括样本对齐、特征处理、联邦分箱、联邦特征选择等。如图3所示，列举了在联邦数据探查阶段常用的联邦特征处理和联邦特征选择方法。图3. 常见的联邦特征处理和联邦特征选择方法完成联邦数据探查后，即可进行联邦模型训练生成联邦模型，根据联邦学习模式不同，联邦模型训练可以分为跨特征联邦、跨样本联邦以及复合型联邦，根据具体的业务场景，可选择相应的联邦算法，如：线性回归、逻辑回归、树、神经网络等模型的训练。联邦训练生成模型后就可以投入生产环境使用进行联邦模型推理了。跨样本联邦只需要本地特征数据和本地模型即可直接推理，不会涉及联邦参与方之间的数据交换。而跨特征联邦在训练过程用到了多方特征，推理时也会用到多方特征指标，但不会涉及到其他参与方隐私数据的交换。联邦推理方法是与联邦模型训练时选择的算法强相关的，一般都是配套设计实现的，通常包括回归模型推理、树模型推理、神经网络模型推理等。三、 联邦三部曲联邦三部曲由联邦协议、联邦算法和联邦平台组成，三者之间内部独立，且又相互关联。联邦协议是参与方之间进行安全数据交换的基础，联邦算法是基于联邦协议实现的多方联合训练和推理的计算过程，联邦平台是在封装了联邦算法之外又提供了更全面的产品化功能。下面将分别进行详细介绍。(一) 联邦协议为了在联邦学习的各个参与方之间，实现算法的训练和推理，必须在底层建立一套协议，使得各参与方之间能够协调一致的运行算法程序，期间进行必要的同步指令控制、执行双方一致的加解密方法、进行有效的信息交换等。就像HTTP协议承载了我们今天看到的极度丰富的互联网应用一样，联邦协议也是建立联邦学习应用所必不可少的基础协议，有了这个协议才能使得联邦学习应用得以标准化，使得联邦学习过程中的数据安全、模型性能得到有效的保障。由于联邦学习技术栈的丰富性，联邦协议涵盖了从数据通信协议、加密算法等多个层面的技术。其中处在最底层的数据通信协议，需要在任意的两个参与方之间能够建立有效的通信，并且双方的通信信道需要支持安全加密和身份的验证，常见的数据通信协议大多基于grpc，如EggRoll，IonicBond。而加密算法则是对于涉及敏感信息的数据，进行加密处理，以在保证数据安全的前提下，进行信息交换。(二) 联邦算法有了底层的联邦协议的支持，就可以构建对应联邦算法来解决实际的问题了，从机器学习算法演化出的联邦学习算法，即以多个参与方组成联邦的方式，从多个参与方各自拥有的数据源，训练机器学习的模型，并使用模型进行应用的特定的机器学习算法。这些算法通常都是比较经典的机器学习模型，例如逻辑回归，决策树等模型的联邦化版本。为了保证在整个建模过程中数据隐私的安全，通常只将模型训练使用的梯度信息进行通信传递，并在各个参与方本地进行模型的更新。所以，这些模型的设计上，会引入特别的设计，尤其以跨特征的联邦学习为代表（一条数据的特征分别出自不同的参与方），并设计独特的数据加密、交换顺序，以完成模型的训练。当然，最终用户得到的模型的性能效果与传统的本地模型是十分接近的，但是由于可以引入更加丰富的特征数据，使得联邦学习具备了更大的提升潜力。1. 跨样本联邦算法架构跨样本联邦算法的典型架构如图4所示。在该系统中，具有相同数据结构的N个参与者通过参数或云服务器（参与方N+1）协同学习机器学习模型。一个典型的假设是参与者是诚实的，而服务器是诚实但好奇的，因此不允许任何参与者向服务器泄漏信息。这种系统的训练过程通常包括以下四个步骤：第一步：参与者在本地计算训练梯度，使用加密、差异隐私或秘密共享技术掩饰所选梯度；第二步：参与方将掩码后的结果发送到服务器；第三步：服务器执行安全聚合，不了解任何参与者的信息；第四步：服务器将汇总后的结果发送给参与者；第五步：参与者用解密的梯度更新他们各自的模型。通过上述步骤进行迭代，直到损失函数收敛，从而完成整个训练过程。该结构独立于特定的机器学习算法（逻辑回归、深度神经网络等），所有参与者将共享最终的模型参数。图4. 跨样本联邦算法架构图在跨样本场景下，各参与方拥有完整联邦模型以及完整特征向量，所以可以在本地完成联邦推理。2. 跨特征联邦算法架构假设A公司和B公司想要联合训练一个机器学习模型，并且他们的业务系统都有自己的数据。此外，B公司还拥有模型需要推理的标签数据。由于数据隐私和安全原因，A和B不能直接交换数据，是一个典型的跨特征联邦的场景，其架构图如图5所示。跨特征联邦算法的通常包括样本对齐、模型训练和模型推理三个部分，分别对应于联邦应用的三个阶段。第一部分，样本对齐：由于两家公司的用户组不同，系统使用基于加密的用户ID对齐技术，来确认双方的共同用户，而A和B不会暴露各自的数据。在实体对齐过程中，系统不会公开彼此不重叠的用户。第二部分，模型训练：在确定了公共实体之后，我们可以使用这些公共实体的数据来训练机器学习模型。模型训练核心在于A、B使用加密、差异隐私或秘密共享技术不断交互中间计算结果，如模型梯度、树的分裂点信息、中间矩阵等，直至达到损失函数收敛或固定迭代次数。图5. 跨特征联邦算法的架构图第三部分，模型推理。跨特征线性回归、跨特征逻辑回归和跨特征神经网络的联邦推理方式实际上是共通的，都是各参与方进行一轮本地计算后，将本地计算结果通过安全聚合得到和，然后各参与方基于该和进行推理，我们将其称为跨特征安全聚合推理。(三) 联邦平台为了有效的组织多种多样的联邦算法，并建立满足产业界需求的落地应用，联邦平台应运而生。就像今天各大公司纷纷建立的机器学习平台以解决各自的业务问题一样，联邦学习也需要采用这样的平台来满足业务需求。不同于一般的机器学习平台，联邦平台需要在多个参与方同时进行部署和应用。例如一个联邦模型的训练想要启动，需要当前用户在联邦平台上发起联邦建模请求，并有其他的参与方用户接受对应的请求，双方达成协议后，才能用协商好的算法，开始模型的训练。对应的，在模型的应用阶段，也需要通过联邦平台取得各个联邦参与方的子模型返回（跨特征的模型），进而合并成最终的结果。不难看出，联邦平台技术是需要在机器学习平台技术的基础上，附以安全加密、联邦算法、分布式系统调度等技术的一个综合性系统，具备相当的技术挑战。由于解决问题的初衷不同，市场上的联邦学习产品也各有特色，互有差异。Google提出开源数据联邦学习应用框架Tensorflow Federated，主要支持移动设备上的联邦学习；NVIDIA发布Clara Federated Learning主要应用医疗领域。国内各公司也在进行联邦学习的布局，如百度的PaddleFL平台，平安科技的蜂巢等。此外，华为也基于自己的终端设备开展联邦学习探索，主要用于识别业务流量后的带宽控制、阻塞控制和业务保障。微众近期开源了FedVision视觉联邦框架，解决计算机视觉任务中的跨样本联邦的问题。字节跳动也于近期开源Fedlearner联邦学习框架，主要用于广告投放。大多数联邦学习产品主要还是以提供框架为主，部分提供了安全加密的算法或者方式，更多地以鼓励参与方利用框架自主解决问题，在解决方案上没有给出明确的标准。此外，还有少部分产品如同盾科技发布的智邦iBond平台，不仅提供了联邦学习框架和安全加密算法，还针对某垂直领域定制化设计解决方案，降低了使用门槛，可以让缺少算法资源储备的行业或公司，快速接入联邦学习场景。面对不同的场景下的数据差异性和标签专属性问题，有针对性地设计了场景定制的整套联邦学习技术方案，适用于各种需要打通数据孤岛实现智能化应用的行业。四、 联邦学习技术展望(一) 联邦学习技术发展展望相比成熟的理论体系和丰富的技术实现框架，联邦学习在生产实际的应用处于初始的发展状态。但随着相关产品和产业标准不断发展，联邦学习在保护用户数据隐私、满足合法合规的基础上进行机器学习，提供强有力的技术支持。目前国内一些大型互联网公司和金融科技公司，如阿里、腾讯、百度和同盾科技等多家单位也在进行联邦学习技术研究和产品实现，不同公司的产品定位和专注点各有侧重。随着企业投资力度的加大，校企之间的合作也是百花齐放，围绕数据经济与人工智能核心、共同创造AI无限想象的商业化未来生态。(二) 应用场景展望以金融行业为例，金融行业安全关乎国家经济运行稳定与人民财产安全，诸如银行、保险等业务面临着极为严格的数据安全监管要求。金融行业在应用联邦学习技术时需要与其它组织机构、系统平台等进行数据交换，以联合各方完成建模所需的数据探查处理、模型训练与推理等流程。此外，金融数字化转型的趋势愈加明显，有必要加强金融机构、企业之间，金融机构与政府之间的数据流转与融合应用。以银行为例，加强银企、银政之家数据要素有序流转与融合，有利于发挥数据要素倍增作用。金融行业在大力发展数字化转型的同时，也要注重安全能力的建设，在数据安全共享与利用的基础上，持续挖掘数据经济价值。通过采用联邦学习技术能够为智能风控、反欺诈、反欺诈、营销等多类型金融业务服务，提供了多维度的金融商业化场景方案。1. 智能风控用户信用评估是一种基于机器学习和深度学习的智能风控模型，以分数的形式展现个人的信用风险等级。随着隐私和安全政策的逐渐收紧，因使用权限不同，导致不同部门或者不同企业之间的数据不能共享使用，最后这些金融数据会以孤岛形式存在。数据模型的准确性取决于数据量、数据种类和数据质量，使用联邦学习共同使用各方数据，提升模型的精度。比如传统信用分的场景，需要信任某一方或第三方将原始数据聚合后，才完成风控模型的建模和推理分析。在联邦学习的技术支持下，可将原始数据的基于模型的梯度进行密文传输，共同构建联邦模型。联邦学习作为一种能够保障数据隐私、数据合法合规利用前提下，充分利用多方数据的建模方法，在智能金融领域拥有巨大的应用前景。2. 智能营销随着移动互联网技术的迅猛发展，当前金融业面临着巨大的科技变革冲击，主要体现在线下服务网点增长乏力，而线上移动互联网用户迅速增长，以往依赖业务员线下地推、电话推销、**的传统营销方式,存在营销针对性不强，市场需求把握不够精准，营销成本高等问题，如今如何通过人工智能、大数据、云计算等技术在“获客-促活-留存-转化-挽留”等核心运营环节实现多维度精准获客、数据化画像分析已成决胜分水岭，行业将面临重新洗牌与变革。为拥抱新时代的到来，各家银行纷纷采取措施，试图借助大数据、AI等技术搭建智能营销平台，投身智能营销建设，期望以金融科技为抓手，赋能业务实现新的增长点。通常智能营销由客户画像、客户行为预测和营销自动化组成，其各环节都会涉及到用户不同敏感等级的数据。以客户画像为例，全行业客户画像需要覆盖客户基础信息、兴趣爱好、社会属性、金融特征、客户价值和互联网特征等多种丰富的客户属性。然而，受制于日趋严格的数据监管，传统的将各行业数据汇集在一起、中心化的方式不再可行。通过联邦学习，能够达到各行业数据可用不可见，知识共创可共享的目的。例如，可以充分发挥企业集团内部丰富的线上线下渠道资源，通过打通集团内、集团外、线上、线下渠道（如银保协同），提升渠道覆盖度，确保流量形成闭环，配合机器学习、深度学习的联邦数据探查、联邦训练和联邦推理，找到更多潜在相似人群，构建多维、准确、及时的全息用户画像。基于联邦学习，还可以构建客户的全景视图，点对点构建客户的全方向画像，完善客户分析体系，结合高效活动效果追踪体系拓展社交渠道，以及发展直营对接多个三方权益平台，综合“客户画像+社交裂变+权益吸引”三方面聚能，最终赋能客户经理直达目标客户，并辐射扩展到社交渠道，大大提升营销的成功率。3. 智能化运营智能KYC和开放银行为典型的银行智能化运营场景。随着互联网银行（也称虚拟银行）的不断发展，智能KYC成为智能化运营中客户审核环节的关键一环。随着信息技术、人工智能、大数据技术的迅速发展，生物识别技术实现了跨越式发展，促进了人脸识别、声纹识别、指纹识别、指静脉识别等创新支付技术的行业应用。如何在保证客户隐私的同时，能综合利用客户的生物特征信息，如：人脸、声纹、语音，和客户的有效证件信息全方位认识客户，是一个有挑战性的难题。基于联邦学习的深度学习、强化学习是一个有效的解决方案。未来开放银行的发展和可持续深化给用户带来了极大的便利，也给银行和金融科技带来新的挑战。在开放银行的场景下，联邦学习将成为刚需，各个机构间各种复杂业务场景下，需要安全交换各种要素，联邦学习能够在保障数据安全和隐私的前提下进行开放银行应用场景的全面覆盖。4. 反欺诈《2019反欺诈行业调研白皮书》显示，截至2018年由于个人信息泄漏造成的总体经济损失可能已超900亿元，目前黑产市场规模预估已逾千亿级别。随着互联网金融的兴起，欺诈行为逐渐渗透到各个环节。欺诈分析需要海量多维化数据，随着数据需求量的增大以及随之带来的数据获取难度的增加，本地训练模型十分昂贵且困难，各机构对数据的隐私性和保密性要求会更加严格。对于反欺诈业务来说，整合某一个用户的所有信息将愈发困难，这将会对业务造成深远的影响。因此，采用联邦的方式，可以得到适应更多区域场景的联邦反欺诈模型。5. 反洗钱随着国际反洗钱监管环境日趋严苛，国际联邦反洗钱的各参与方希望在不泄露各自样本的前提下，充分利用跨国多家合作方的反洗钱样本，在可疑活动监测、客户尽职调查与监察名单筛选等模型中利用联邦学习框架，建立较单方样本训练效果更好、更稳健的联邦反洗钱模型，以降低罚款和声誉受损等业务风险。参考文献[1]Paillier P. Public-key cryptosystems based on composite degree residuosity classes[C]. International conference on the theory and applications of cryptographic techniques. Springer, Berlin, Heidelberg, 1999: 223-238.[2]Gillmor D. Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)[J]. IETF RFC 7919, 2016.[3]NIST Special Publication 800-90A. Recommendation for Random Number Generation Using Deterministic Random Bit Generators [OL]. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-90a.pdf. Last accessed on 10/21/2020.[4]NIST Special Publication 800-38G. Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption[OL]. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38G.pdf. Last accessed on 10/21/2020.[5]Chou T, Orlandi C. The simplest protocol for oblivious transfer[C]. International Conference on Cryptology and Information Security in Latin America. Springer, Cham, 2015: 40-58.作者介绍强锋博士，工商银行软件开发中心资深经理，主要负责工商银行大数据与人工智能实验室的数据科学场景建设和相关研究工作，qiangfeng@sdc.icbc.com.cn。引用链接：https://mp.weixin.qq.com/s/g8bhWBQAlnk15c2yLbKqkQ

Deep Double Descent: Where Bigger Models and More Data Hurt研究深度双波谷：更大的模型和更多的数据有时会产生负面作用2019 年中，包括 OpenAI 在内的一批学者「老调重谈」地再次讨论起模型复杂度和过拟合的问题来。机器学习界流传已久的观念是，随着模型的复杂度增大（学习能力提高），模型总能得到更小的训练误差，但测试误差和训练误差的差会越来越大（出现过拟合）；所以模型复杂度不能太低、也不能太高，我们需要找到相对平衡的那个点。（上面的 U 型图）但这两年来，一大批超级大、超级复杂的模型用实际行动表明了训练误差和测试误差都还可以一同持续下降。所以这次讨论形成的新共识是，我们需要在 U 型图的右侧继续扩充，用来表示现代的、大容量的深度学习模型在大小超过某个阈值之后，越大的模型会具有越好的泛化性。这样，整张图就形成了双波谷的样子（下图） —— 也就是说，当你的模型大小很不幸地落在中间的波峰的时候，你就会遇到模型越大、 数据越多反而表现越差的尴尬情境。论文地址：https://arxiv.org/abs/1912.02292    转自，杨晓凡，https://www.leiphone.com/news/201912/TK9EEFIUdjdbAC4J.html

3、马尔科夫逻辑网络马尔科夫逻辑网络（Markov Logic Network）的目标是把一阶逻辑规则和概率图模型结合起来。然而，直接使用马尔科夫逻辑网络不仅有拓展性问题，推理过程的计算复杂度也过高。近几年来，用神经网络改进马尔科夫逻辑网络的做法越来越多，今年我们能看到很多有潜力的网络架构，它们把符号规则和概率模型结合到了一起。论文9：Probabilistic Logic Neural Networks for Reasoning链接：https://papers.nips.cc/paper/8987-probabilistic-logic-neural-networks-for-reasoning.pdf论文 9 提出了 pLogicNet，这个模型是用来做知识图推理的，而且知识图嵌入和逻辑规则相结合。模型通过变差EM算法训练（实际上，这几年用EM做训练&模型优化的论文也有增加的趋势，这事可以之后单独开一篇文章细说）。论文的重点是，用一个马尔科夫逻辑网络定义知识图中的三元组上的联合分布（当然了，这种做法要对未观察到的三元组做一些限制，因为枚举出所有实体和关系上的所有三元组是做不到的），并给逻辑规则设定一个权重；你可以再自己选择一个预训练知识图嵌入（可以选TransE或者ComplEx，实际上随便选一个都行）。在推理步骤中只能怪，模型会根据规则和知识图嵌入找到缺失的三元组，然后在学习步骤中，规则的权重会根据已见到的、已推理的三元组进行更新。pLogicNet 在标准的连接预测测试中展现出了强有力的表现。我很好奇如果你在模型里选用了 GNN 之类的很厉害的知识图嵌入会发生什么。论文 10：Neural Markov Logic Networks链接：https://kr2ml.github.io/2019/papers/KR2ML_2019_paper_18.pdf论文 10 介绍了一个神经马尔科夫逻辑网络的超类，它不需要显式的一阶逻辑规则，但它带有一个神经势能函数，可以在向量空间中编码固有的规则。作者还用最大最小熵方法来优化模型，这招很聪明（但是很少见到有人用）。但缺点就是拓展性不好，作者只在很小的数据集上做了实验，然后他表示后续研究要解决的一大挑战就是拓展性问题。      论文11：Can Graph Neural Networks Help Logic Reasoning?链接：https://kr2ml.github.io/2019/papers/KR2ML_2019_paper_22.pdf最后，论文 11 研究了GNN和马尔科夫逻辑网络在逻辑推理、概率推理方面的表现孰强孰弱。作者们的分析表明，原始的GNN嵌入就有能力编码知识图中的隐含信息，但是无法建模谓词之间的依赖关系，也就是无法处理马尔科夫逻辑网络的后向参数化。为了解决这个问题，作者们设计了ExpressGNN架构，其中有额外的几层可调节的嵌入，作用是对知识图中的实体做层次化的编码。         转自，杨晓凡，https://www.leiphone.com/news/201912/GsRSElsUReef0z7o.html

“DevOps的价值是又快又好地交付软件”——《凤凰项目》的作者Gene Kim和《持续交付》的作者JezHumble当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，DevOps能帮助企业提升软件研发效率，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。基于此，我们策划组织了2期【DevOps职业认证训练营】，并邀请到姚冬、卜汉东两位专家老师全程陪伴学习与答疑。在整理问答的过程中我们发现，学员提出的问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等DevOps落地实践中的关键疑点与难点。本文从中挑选整理了60个精华问答，希望通过这些问题与解析，帮助更多DevOps实践者解决DevOps落地过程中的疑惑与痛点。（文末可下载大纲模式的pdf文档方便浏览）【一、华为端到端DevOps概览】Q1：华为端到端的DevOps工具链是如何承载敏捷和DevOps相关理念和方法的？A：敏捷和DevOps的理念其实是相通的，DevOps可以视作敏捷的延伸，敏捷思想打破了需求与开发之间的壁垒，DevOps则通过将开发与运维间的壁垒打破，打通软件交付全流程。华为云DevOps工具链DevCloud包含了从需求管理到代码托管、构建部署、测试等一系列步骤，覆盖软件开发全生命周期。理念往往需要结合实践，我们可以通过DevCloud进行需求管理、每日站会等等许多敏捷实践，通过提交代码可以触发执行流水线，让开发人员专注开发。Q2：华为云DevCloud与传统基于开源组件拼接的工具链，有什么差异优势？A：传统的由开源组件拼接而成的工具链，大部分都是使用Jira来进行需求管理、用Git来做代码托管、用Jenkins做DevOps开发，因为其组件大部分都是开源的，所以一般费用较低或者免费，其缺点是使用者需要掌握很多工具，而且这些工具并不是在同一个平台上。华为云DevCloud是一站式的软件开发平台，可以做到所有工具都在一个平台上，端到端打通覆盖整个软件开发全生命周期。用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的环境，还需要定制化地做一些脚本、配置等，华为云DevCloud相当于是一个已经封装好了的DevOps开发工具，可以极大减少这些操作。在华为云DevCloud里，将编译构建、部署任务等做成了原子化的操作，如果我们想要做Tomcat部署，可以直接使用这些模板，只需要对里面的步骤进行细微的调整即可。而且它还使用了可视化视图，操作起来一目了然，学习成本也比较低。华为云DevCloud还支持代码检查、自定义shell、Python、脚本、自定义report展示。Q3：DevOps /敏捷和SDLC 有何不同？A：DevOps/敏捷和SDLC的角度不一样。SDLC是指系统生命周期，它提出的几种典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。敏捷打破了需求和开发之间的沟通壁垒，DevOps则打通了整个软件交付的全流程。Q4：DevOps人员在与项目的结合中是否会承担更多开发、测试、运维的工作？A：DevOps不会让人去承担更多开发、测试、运维的工作。DevOps里有一个理念：让开发的人专注于开发、测试的人专注于测试、运维的人专注于运维，所有的工具层面的东西全部交给工具，只要把一切可自动化的东西自动化，所有的人忙自己手头的工作就好了。Q5：DevOps的反模式有哪些？A：参考《9种DevOps团队结构适用类型与7种反型》 Q6：DevOps适合哪些行业的业务模式？对于非软件行业是否需要调整模式?A：DevOps也好，敏捷也好，其初衷和理念适用于所有行业，但是每个行业在执行和实际落地效果上会有一些折扣，比如持续交付的生产环境、自动化部署、质量管控、自动化流转等过程的实现等。简单而言，互联网的一些应用，或者说SaaS应用，相对来说更适合DevOps的研发模式。原因是：其业务对软件更新、发布的要求较高；没有太大的历史包袱；相对更容易对标目标受众群体，包括生产环境等。传统类的业务比较重，比如银行的核心系统，实践起来相对较难，也不是说不能用敏捷或DevOps。比如持续集成、每天多次构建、多次提交代码、自动化测试、可视化等，都可以实行。对于非软件行业，如硬件、嵌入式、机械类，实践起来也比较难，比如测试自动化等，需要做一些工具或平台的适配，引进插件或工具后，流程也能够跑起来，只是会慢一些。综上，我认为敏捷和DevOps本身是一条没有终点的路，所有行业都可以到这条路上来，只是走得难易与远近的问题。Q7：在企业落地DevOps有没有什么套路？A：企业实际情况各不相同，落地DevOps没有统一的套路，但会有一些建议的方式。DevOps偏工程侧，通常建议先把版本管理建立起来，比如Git代码仓、代码分支管理等；接下来需要把流水线构建起来，在上面逐渐进行自动化测试、分层测试等。Q8：最能有效促进Scrum团队本身的持续改进的是什么实践？A：每个团队遇到的问题都是不一样的，如果一定要找一个通用的答案，首先要保证团队每日站会、评审会议等如质如期进行，以此来保持持续改进。 【二、持续规划与设计】Q9：基于DevOps实现持续有效规划应该先从哪个层面去入手呢？A：首先需要理解DevOps和敏捷的含义，我们一般说的规划与设计更偏向于敏捷项目管理中涵盖的需求和计划。狭义的DevOps主要是CI/CD，即持续集成和持续部署，是偏工程侧的。广义的DevOps，即本训练营中讲的DevOps是“端到端的DevOps”，从持续集成/持续部署，向前延伸到业务侧，向后延伸到运维/运营侧，因此也涵盖了前段的需求和设计层面。回到问题，基于DevOps实现持续有效规划，应该从需求和计划切入，包括整个的市场分析、目标客户群体的用户画像，用户的痛点是什么，针对这些痛点提供什么样的功能，然后到产品应该怎么设计，接下来才真正落到研发这个主体上。从方法论角度来看，需求和设计层面的方法论包括设计思维、精益创业等。做好需求分析后，就要进行需求拆分，排列优先级，这样就进到敏捷项目计划里，方法论包括看板、Scrum等，大规模团队敏捷框架有SAFe等。Q10：Scrum，看板和 XP 是敏捷开发的具体方式，老师能否具体讲解一下区别？A：参考文章《DevOps VS 敏捷：傻傻分不清楚》。Scrum和看板更侧重在团队级敏捷项目管理层面，XP更偏向于工程实践层面。Scrum和看板两者比较：“标准的”Scrum包括3355的框架；看板源自丰田的精益生产，其背后是精益的思想，通过可视化、限制在制品的数量，快速暴露问题和瓶颈点，集中对最严重的瓶颈点进行修复，然后去寻找下一个瓶颈点。DevOps的很多理念同样借鉴了精益的思想，个人认为，看板可以应用到很多领域。另外，Scrum和看板在实施或应用时并没有冲突，可以结合起来使用。 Q11：企业组织架构中什么角色或者部分适合推行DevOps落地？A：企业组织架构中一般都没有专门的组织来推行和落地DevOps。DevOps包括两个部分“Dev”和“Ops”，就是指开发部门和运维部门。几种常见的情况：如果是由开发部门来发起DevOps落地，就是由开发往运维去推进。我们平时看到比较多的是测试团队或传统的质量管理部门来发起，从开发到测试再往前一步到运维生产环境上去，因为这些部门本身就承担着代码托管、编译构建、自动化测试等职能。而有的公司会把内部的基础设施、IT支撑、测试等放在数据中心，往前去推把自己变成类似我们讲的DevOps工程师，然后通过自动化工具帮助开发团队进行自动化部署等，这就是从运维侧往前推进DevOps落地。还有一种情况，就是近年来比较火的云原生，架构师更多考虑采用微服务架构，通过基础设施即代码等方式自动化部署到Docker环境中去，因此引入自动化流水线、Infrastructure as Code（基础设施即代码）、接口测试等实践，这些都属于DevOps的范畴。还有一些其他的角色，比如敏捷教练、内部的技术教练等，他们本身就是在做研发管理的落地实践，很自然地转化去做DevOps推进。综上，DevOps的推进和落地不一定非要有一个DevOps工程师或独立的DevOps团队，初期引入DevOps的时候需要有一个团队或角色去承担起这个职责，进行概念和实践的导入和探索，这时更容易把DevOps工程师、DevOps团队建立起来。而后期应该把这些工程师或能力分散到各个团队中去，让DevOps在企业内有更广泛的传播和实践。Q12：请问在Scrum中，如果没有项目经理，是由TeamLeader还是ScrumMaster协调资源？A：应该由TeamLeader来协调资源，ScrumMaster不是管理角色，而更多的是一个辅助的牧羊犬的角色，在Scrum实施过程中守护团队Scrum流程不受干扰。Q13：对于非产品形态的项目，Product Owner来自哪个部门更合适？（业务部门/研发部门）A：Product Owner代表客户，一般是哪个部门更接近业务，更了解业务和系统，就由这个部门的人来担任。非产品形态项目的Product Owner，要求既了解业务又懂技术，一般可以由业务分析师、PMO等角色担任。Q14：实际开发中，客户往往无人承担PO的角色，而是领导来承担，如何破解这个问题？A：这种情况可称为“BDD”，Boss-Driven Development，老板驱动开发。好处是至少有一个人能拍板；坏处是拍板的人，你可能很难去辩驳或谈判，所以最好还是能够把客户侧的人拉进来。当然，如果老板确实对业务非常了解，也非常专业，并且是一个可沟通的人，也是可以的。PO的核心要求是需要有一个人代表客户或业务侧，针对需求或范围做决定，且当团队有问题的时候，可以随时找到这个人。Q15：影响地图主要应用于哪个环节？A：从HE2E DevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。Q16：请问如果一个大的Story拆分成多个小的Story，甚至再次拆分成孙子辈的Story，如何更好地表示这些关联关系？A：Story拆分有两种方式：一种是从epic（史诗故事）到feature到story的拆分，epic以月为单位，feature以周为单位，story以天为单位；另一种是平级拆分，所有拆分的故事全部叫story，只不过它们之间存在父子关系。不管是三层还是四层，我们只关注父子关系，从一个父story拆分出子story，如果粒度不够小，则以子story为父story继续拆分出它的子story。如果系统需要有层级追溯，可以用树状或脑图等结构来展现。Q17：学完课程感觉用户故事和项目管理里的工作包很像，二者有个共同的问题，拆解到什么粒度是好的用户故事？A：故事也好，需求也好，只是一个名字，用户故事之所以叫用户故事，有两点表征：1）它是站在用户的角度去看；2）它讲了一个故事、一个场景。好的用户故事遵循INVEST原则，即一个合适的用户故事应该是独立的（Independent）、有价值的（Valuable）、可讨论的（Negotiable）、小的（Small）、可估算的（Estimable）和可测试验证的（Testable）。Q18：如果采用敏捷开发，最终的用户需求如何呈现给用户？如果是需要存档的用户需求说明书、设计说明书或操作手册之类的文档，适合从DevCloud导出后再修改么？另外如果出现变更，如何确保文档与代码一致？A：如果是需求文档，可以以用户故事的形式存放，华为云DevCloud或者其他工具都提供多元的存储格式，如文本、图片、附件等，华为云DevCloud有一个帮助网站，每一个新上线的功能都会在这里进行同步和更新。也可以把词条或需求存放到wiki里，并跟前端的需求条目之间建立链接。wiki本身是可以有层级关系的，可以把需求从wiki里导出来形成文档形式，如果做得好，还会有版本计划，比如版本里包括10条需求，可以统一导出一篇需求规格说明文档。需求和代码之间的同步，可以通过流程等方式去控制，比如发版的检查点，这可能需要以人工方式去做，但也可以通过一些工具来辅助。比如提交代码的时候需要提交注释，可以把这个注释关联到一个工作项上，一个需求可能会修改多个文件里的多段代码，这其实就是一个完整的变更集的概念，这个变更是为了同一个目的，是有相关性的，如果要从代码里去剥离的话，应该会把这一次变更集统一进行剥离。在未来查看代码时，可以进行代码版本比较，看两个版本之间进行了哪些增加/修改、这些变更是为什么目的、其意图是什么。Q19：对于变化的需求或者新增的需求，是应该放到当前迭代里，还是规划到后面的迭代里，持续规划是指规划过程贯穿整个生命周期么？A：变化或新增的需求都会统一放到一个大的池子里，我们称之为product backlog（产品待办事项列表），这是一个一维的表格，所有需求按照优先级排列。我们要通过判断新进需求的优先级，看它应该放在什么位置。敏捷强调需求是动态变化的，我们会定期对需求列表进行梳理，看是否需要进行优先级排序的调整，因此变化或新增的需求不会放到当前的迭代里，因为当前迭代是一个固定的时间窗口，且范围相对固定，团队对此进行了承诺。我们会将其放入大的需求池，是在下个迭代还是之后的迭代实现，取决于该需求的优先级。Q20：对于初学者刚刚接触一个项目，但是项目的需求不明确、结构不成熟，怎么从敏捷入手？A：这里包括两种情况：初学者、项目在初级阶段。如果是初学者，应该通过获取现有资产快速熟悉和上手；如果项目处于初级阶段，需求也不太明确，可以通过敏捷的快速交付、精益的MVP等实践，快速获取反馈，对后续工作进行指导和建议。Q21：作为整个项目的入口，需求的质量如何把控和评测？A：明确定义需求可以转开发的标准，即DoR。那什么是DoR呢？敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。Q22：持续规划与设计有什么度量数据或指标用于衡量团队绩效或用于持续改进？如何衡量持续规划与设计的成熟度？A：度量工具推荐Scum的燃尽图、看板的累积流图。研发效能的核心度量数据指标包括团队速率、Lead time，即需求的平均交付时长。Q23：敏捷下的组织过程资产（配置、文档等）这些有好的存储方案么？A：理论上文档、资产等都存储在资产库里，常用的知识库或资产平台有Conflunce、IBM的Rational Asset Manager等。资产和知识是不同的概念，现在做资产管理的相对少一些，知识库可以用wiki等平台，便于统一维护更新和协同。Q24：DevOps 持续规划与设计在DevOps生命周期中是处于开始的时刻，为什么还说代码集成是整个DevOps生命周期的核心呢?A：“代码集成”包括两部分：代码和集成。整个软件生命周期包括三个版本：需求版本，即发版计划；代码版本；上线发布的二进制包的版本。其中代码版本处于承前启后的中间位置，且是唯一真正有价值的。需求和文档是没有价值的，只有由代码编译成二进制包并部署上线才是有价值的。在代码层面多花一些精力是非常有必要的，所有的研发其实都是在一个代码仓库里进行协同开发，包括代码版本管理、分支管理等模式，因此将代码视为DevOps生命周期的核心也是必然的。软件研发最痛苦的地方往往是在集成层面，一开始大家各写各的代码，一旦要将这些不同的代码进行集成的时候，问题就出现了。持续集成的概念来源于XP，“如果代码集成是一件非常痛苦的事情，那我们就每天多次地进行。”一切杀不死你的都会让你更强大，持续地进行集成，你会想办法去减少集成的痛苦。就像跑步一样，假如以前的集成是一块大石头，每天多次集成就相当于将这块石头变成一颗颗的小石子，大石头打在身上会非常疼，小石子就好多了。这也是我们为什么要把集成往前提，并且持续去进行的原因，所以在DevOps生命周期中持续集成也非常重要。【三、持续开发与集成】Q25：如何加强开发人员对于版本质量的信心？A：加强对版本质量的信心，不只是针对开发人员，对所有人都应该如此。整个DevOps的过程其实就是在保障整体的版本质量，包括静态代码检测、接口API测试等。另一方面，版本对需求的映射关系或完成程度，应该从业务场景往下去切，看整个需求的匹配程度。第三点应该是我们通常说的非功能性需求（Non-functional requirements），比如负载、性能、安全、并发支持等，这些要根据我们服务承诺的质量来做相关措施。 Q26：敏捷开发相比传统开发有什么优点？A：我认为最大的优点或特点是敏捷开发更真实，或者说它更愿意承认研发的本质或现状。传统的研发认为质量受三个因素制约：范围、资源、时间，且默认范围和资源投入是相对确定的，时间是变化的。然而，在真实场景或变化的市场下，时间和资源是固定的，没办法讨价还价，因为市场、业务、客户都不会等你，在这样的前提下，软件的需求或范围实际上是可以商量或讨论的，我们要以可变的范围去赢得市场、时间窗口。敏捷开发要求我们不断交付高优先级的需求，并获取反馈，不断调整。这是敏捷开发的最大的核心，承认市场是变化莫测的，需求范围是可变的。Q27：一个产品，既有主线版本，又有很多的行业定制分支（50+），适合什么样的分支策略？A：这种场景在传统的产品里比较常见，个人认为应该考虑的是产品策略而不是分支策略。如果分支非常多，会导致产品碎片化严重。我们在持续集成、持续交付的时候，推崇主干开发或短的分支，不希望这些分支长期存在，否则在产品进行合并时会非常痛苦，工作量也会随着分支的多少和分支存在的时间呈几何倍数增长，所以不建议用长期存在的分支。那可以用什么样的方式来解决呢？首先要看整个版本上是否一定要出现这么多定制化的分支，这些分支有没有可能通过配置文件、功能开放等方式处理或实现。举个例子，我们做项目管理的软件，每个客户要求的字段、功能流转的流程都不太一样，如果都通过代码实现，有多少客户就会出现多少个分支，可能都不止50个。我们是怎么做的呢？针对字段，我可以配置一个界面，里面包括常见属性的字段，这个字段可以是文本类型或下拉框等形式；功能流转的话，新进来一个需求，它的下一个状态是什么、应该触发什么动作、应该是什么样的角色来触发这个动作等这些都是可以进行配置的，这些配置信息存在数据库里，变成用户的配置数据，这样我的主代码主程序是保持不变的，只需要提供一套模型根据数据去驱动适配或实现。这是我们更推崇的方式，可以用来消灭那些分支。Q28：日常项目开发，在代码分支管理上经常疑惑用什么分支管理策略，比如是选择基于生产分支工作流，还是基于环境等等，在实际实践中，我们应该重点考虑哪些因素？既可以兼顾管理效率，又可以确保代码质量。A：个人建议采用分支开发主干发布或分支开发分支发布的分支管理策略。基于环境进行分支构建的话，以前我们会有开发库测试库等仓库管理的概念，但现在全部是持续集成、自动化部署，就没必要再基于环境去拉取分支了。如何保证代码质量，我们在CI/CD流水线、自动化部署和构建的同时需要考虑每一个环境上跑哪些测试，这些测试大部分通过自动化的方式实现，也有少量的是手工进行。Q29：像华为云这样团队成员能力超强、应用场景以线上服务为主，一般会采用什么样的分支管理模式？A：华为云团队也是采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。Q30: 要做到主干上的提交始终处于可发布状态，不受隐含的代码冲突、提交的feature只部分完成等因素影响，对开发团队和基础设施有哪些要求？A：首先主干上提交的流程或质量要严格控制，真正达到DoD（Definition of Done）的标准，这里可能需要一些机制人为地进行管控，比如Committer机制等。提交的时候，除了非功能性的要求，比如跑相关的回归测试、代码检视以外，还有很重要的功能性要求，比如对需求的实现程度的检查。另外“基础设施即代码”，还要看持续集成、持续部署、自动化测试能不能快速有效地跑起来，并保持高度一致。Q31：持续集成的成功因素是什么？ A：持续集成主要包括代码仓库、自动构建、自动部署、自动测试四个方面。要求每人每天都要向主干提交代码，触发自动构建和自动部署，在类生产环境进行自动化测试，同时需要团队每个成员确保清楚正在发生的状况，以此来保证持续集成的成功。Q32：华为云上的CI/CD与K8s上搭的CI/CD有什么区别？A：华为云DevCloud打通了端到端的软件交付全流程，集成了常用的DevOps开发工具，不仅可以完成CI/CD，还可以直接在上面进行项目管理和开发；而K8s只是软件开发中一个单独的工具，没有项目需求管理等功能，需要配合其他工具一起使用才能实现完整的软件开发与交付。Q33：开发和修复bug的工时如何进行安排呢？之前迭代出来的bug是按照单独工时安排，还是统一安排在开发中？A：主要看发版的标准和要求是什么，通常来说可以带病发版，但如果是非常严重的缺陷，就不能上线，必须先修复这些bug。一般bug会跟需求放在同一个池子里，根据它的优先级和影响程度来进行排序，决定是先修复bug还是先做需求。如果修改bug是为了扫清技术债务，建议在一个迭代里固定一定比例的时间来进行。Q34：感觉SaltStack和Ansible中哪个是最好的配置管理（CM）工具？为什么？A：两者定位不一样。个人认为Ansible并不是一个标准的配置管理工具，它更多是通过自动化部署的手段去touch环境这一侧，SaltStack相对来说功能性更强一些。Q35：在代码互评审和评审流程中如何高效的提升代码质量？A：人机结合，将重复性的，比如检查代码风格、命名规则等工作交给工具；人工集中看代码实践的逻辑、对需求的匹配等。将人从重复性的工作中解放出来，节约时间和人力。华为实行代码审查Committer机制，开发人员提交代码后，会自动拉起自动化代码检查。提交一个Pull Request，工具匹配相关的review进行评审和打分，如果是重要实现还可能会有一个评审会议，然后进入最终Committer决定是否将提交的代码合并到主干上去。【四、持续测试与反馈】Q36：“通过持续测试实现快速与高质量“是敏捷测试原则之一，而测试金字塔顶端的一些测试往往依赖许多外部因素，较为脆弱，容易因被测软件之外的因素而失败；且由于这类测试同时测试了软件中的多个模块，定位问题就会更难一些。对于 Flaky tests 怎样处理比较好？删除还是进行标记使其不中断后续的测试且不影响质量门禁？A：Flaky Tests，就是指在被测对象和测试条件都不变的情况下，有时候失败、有时候成功的测试。因此，Flaky Tests实际上就是不稳定的测试，或者随机失败(随机成功)的测试。测试金字塔之所以是正的三角形，核心理念是越往上，即金字塔顶端的测试，其跨度越大，影响面越大，一旦出现问题，爆炸的半径也会更大，在这个层面做测试投入产出较小，工作量大且很难执行，比如测试故障定位等，而且自动化用例的复用程度或稳定性也较差，维护成本也比较高。当然该做的工作一定要做，但相对而言，建议这个层面的测试数量要适当减少。相反，越往底层，比如单元测试，爆炸半径相对就小一些，复用度和投入产出比也更高，而且在这个层面发现的bug应该是最多的。建议金字塔底层的测试措施应该相对多做。中间比如接口测试或跨组件的集成等，如果微服务拆分相对颗粒度小一些，各方面相对就比较好，且接口测试相应的工具也比较多，投入产出比也会越来越大。接口测试也可以多做一些，这样中间层变大，金字塔也会变成橄榄球形。Q37：构建本地持续测试和云上持续测试的对比难易程度和成本，如何选取？A：本地持续测试和云上持续测试的差异在于：本地需要自行对工具和版本进行维护，云上的环境相对快捷。从成本方面考虑，云上是按需的，性能测试、压力测试等适合在云上进行，因为自己去搭建一套10万/100万并发的环境成本非常高；越往前端的测试频度非常高，适合在本地进行构建。另外还需要综合考虑开发人员的使用习惯、公司对于数据的安全要求等进行选取。Q38：从传统的瀑布型测试到敏捷测试再到DevOps，三者之间具体有什么区别？A：瀑布型测试是在开发完成交付以后才进行完整的测试，测试主体是测试人员；敏捷测试往前走一步，做大量的持续集成等实践（如果敏捷实践不只是在管理层面的话）；DevOps是全流程测试，除了测试左移外，还有测试右移，频繁地持续部署到准生产或生产环境上去跑相关测试，甚至还有现网测试，包括混沌工程、Chaos monkey等，其概念更广。DevOps信奉Resilience（韧性），测试这件事很痛苦，我们要频繁地去做。和反脆弱的概念比较一致，“一切杀不死你的让你更坚强”。Q39 在测试自动化环节中应该如何简化测试流程又能快速发现业务风险？A：测试流程未必会简化，所谓的简化应该是指人员参与的流程减少，把大量能够让机器完成的工作交给机器、回归测试等实现自动化，将人从枯燥的重复性的测试活动中解放出来，去做一些新型测试的探索。Q40：SRE和DevOps有什么区别和联系？A：DevOps通常由两种角色去发起，Dev和Ops，即开发和运维。SRE是Google首先提出的一个概念，Site Reliability Engineer（网站可靠性工程师），从Google运维体系出来的一个角色。SRE工程师会通过自动化工具帮助开发人员，以运维的角度去参与研发并提供一些支持，包括开发一些自动化部署及运维相关的工具，通过这些工具和流程使能开发人员。两者比较而言，DevOps概念和范围相对更大一些，SRE则聚焦在开发与运维层面。Q41：在Scrum中只有 Dev team，没有专门的测试团队。“做测试者胜于做检查者”也要求测试人员不仅能发现问题更要准确定位问题。持续测试向价值流持续交付的两端延伸，要求测试人员不仅要懂业务、懂开发还要懂运维，对测试人员的要求很高。在这种背景下，测试人员该如何进行职业发展规划？A：确实测试人员的焦虑相对更多，因为不管流程也好、角色分工也好，他都处于开发和运维之间的位置，像三明治一样，比较难受。换个角度来看，测试是承上启下的活动，DevOps或敏捷在开始的时候都会相对顺利一些，短期成效很快，但等真正进入到测试层面，就像进入深水区，推进变得困难，原因可能就是自动化测试没做好。这样看来测试人员或测试活动其实大有可为，我们强调测试应该是一类活动，分配在整个研发生命周期过程中，而不是中间的某个阶段，因此对测试人员的要求当然也会更高。以往测试人员给人的印象是在研发提交后才参与进来，或者大量通过手工界面的点击去做回归等工作。现在和未来，这类测试人员存在的价值会很低，未来可能会要求测试人员懂业务，从业务的角度设计测试用例；还要懂开发，需要写测试脚本；还要懂运维。其实这些要求对所有的工程师都同样存在，包括开发工程师，要会做架构、做设计、做开发、还可能要自己做测试、部署运维等；运维工程师也是如此，如果转型SRE工程师的话，也要往前段去走。从这点来看，大家都在同一水平线上，所有人都要求往T型人才发展。综上，测试工程师应该是一个全程的质量保障人员，要从专业测试的视角对研发流程、需求、交付等进行质量控制，还需要引入相关实践、开发工具或做工具集成，去赋能开发和运维。真正好的测试对整个团队的帮助和提升应该是最大的。Q42：与传统项目比较，在敏捷项目中，测试工作在整个流程中所占的比重是否更少了，频次更高了，这是否意味着人效更高了？在DevOps流程下，产品人员、开发人员、主导测试人员的比例是否有一个新的经验参考？A：与传统项目相比，敏捷项目中，测试工作比重更大、频次更高、人效也会更高，但这个更高不是通过人去堆，而是通过自动化工具或时间来完成。在DevOps流程下，专职的测试人员数量会下降，现在大量的开发测试是由开发人员来做，在华为内部称为开发者测试，强调开发人员自己去做测试，以前开发测试比例差不多是3:1， 甚至1:1，现在可能是5：1或10:1的比例。产品人员跟以往应该没有太大差异，现在强调产品思维、运营思维，业务运营人员的人数会增加。Q43：小团队（5人，分工：2前端，3后端，没有专业测试人员）需要单独配备测试人员吗，一边开发一边测试，还是每个人对自己代码负责最后一块集中测试。这两种哪种好一些？A：个人认为5人团队没有必要配置专职测试，可以先由开发承担测试，当团队认为需要有一个专业的测试去知道或支持时，再去引入专业测试人员。那端到端的测试谁来做？建议是采用轮岗机制，类似on call，让团队成员轮流去做，这样可以让所有人对完整的测试都有了解和重视。Q44：未来是否会研测一体化？A：我认为研侧一体化会是一个趋势，开发者测试或开发测试的比例会越来越大，且不断往前端延伸，社会分工本就是合久必分分久必合，大分工衍生了一些新的概念，专业的人做专业的事，驱使我们更聚焦于自己的业务本质，比如IaaS（基础设施即服务），运维/环境管理、系统管理等会有专业的人去做，可以看看你是否就是这样一个专职的人才；测试也是如此，比如TaaS（Test as a service），也是一个非常专业的领域，要求懂开发、懂业务、懂运维。再有就是看公司的核心业务是什么，很多公司都不是专门做测试、运维或工具的，我们应该专注聚焦于公司主营业务。【五、持续安全与审计】Q45：如果组织中缺少专业的安全与审计人员，应该如何去补足这方面的能力？A：有些团队会把这个能力转移给相关的SaaS服务平台或第三方厂商。但平台只能提供问题的展现，实际的安全审计处理还需要专人进行。团队规模小时，可以通过业务上的分割和一些工具手段，尽量减轻相应人员的压力。Q46：小团队安全管控得太严格了，对开发测试都会造成很多不便，也会影响问题排除追踪，如何合理度量安全管控？A：项目进入正规化流程后会有很多环境：开发环境、测试环境、类生产环境、生产环境等，可以采用多环境不同程度安全管控的策略，比如在进行开发环境测试时安全管控力度可以松一些，类生产环境测试时安全管控严格一些。【六、持续部署与发布】Q47：持续部署是不是可以做到热部署，不暂停业务直接通过流水线进行部署、提供用户体验？A：持续部署，每一次变化都是直接部署到生产环境里，但持续交付是有一定选择性的，我们可以选择性地把一些需要的东西部署到生产环境中。如果希望可以做到热更新、热部署，不暂停业务，可以通过持续部署的方式，直接使用流水线来实现。Q48：K8s和Docker在应用上有什么区别？A：Docker是一种容器技术，在实践中可以直接使用Docker进行镜像构建等操作；K8s是进行集群管理的技术手段，华为云DevCloud的帮助中心有一个凤凰商城的实践案例，和HCIP考试中的实验一样，只是多了CI/CD的环节，在这个环节中就使用了K8s。Q49：K8S 和 云原生是什么关系？A：云原生是包括微服务、DevOps、容器化、持续交付等理念和方法，K8s只是一个集群管理的工具。 Q50：如果生产环境有等保要求，还有什么办法实现持续部署吗？A：如果生产环境有等保要求的话，不太适合直接做持续部署，这时使用持续交付的方式更好一些，我们可以先决定应该把哪些特性搬到生产环境上去。Q51：新版程序修改了数据结构，如何进行应用设计或部署方案，以应对可能出现重大问题所需要的版本回退？A：当我们做一些比较大的修改时，一般会先部署到类生产环境上，检视没问题后才会通过灰度的方式同步到生产环境中。Q52：我们已经在做持续集成了，但持续交付和持续部署应该怎么落地？A：如果已经在做持续集成，且做得比较成熟了的话，再往前落地持续交付和持续部署会相对容易。我们经常说：持续交付只是持续集成往前的一小步，最后一公里或最后一米会比较痛苦。其实更多的痛点不在于技术层面，而是在于流程、制度层面，可能很难打穿部门墙、穿透企业管控类的要求，这些都未必是技术能解决的问题。【七、持续运维与监控】Q53：通过自动化的方式实现持续集成和持续交付，中间会不会出现干扰而发生错误？A：一般来说，通过自动化的方式实现持续集成和持续交付后，不是很容易发生错误。错误的出现可能是由于配置问题导致的，在配置相应流水线时没有配置好，比如参数出现问题，版本变得不一致等。除此之外还可能会有一个意外导致的问题，比如网络故障等。Q54：如果生产环境要求网络隔离，还有什么办法实现持续部署吗？A：如果生产环境要求网络隔离的话，我们的流水线一般会搭建在公司内部，也就是从提交代码到构建部署都会在公司内部实现。这个过程中使用云上自动化产品会少一些，因为目前大部分云上构建的工具都必须访问公网才可以做到流水线的效果。因此这种环境下，建议在本地搭建自动化构建流水线，或者购买可供私有化部署的工具。也可以在公网进行代码托管和构建，只在部署的时候通过手工部署的方式将软件包放到网络隔离的机器上去。Q55：Docker与虚拟机有何不同？A：从上图可以用比较清楚的看到Docker和虚拟机的异同。左边的VM是虚拟机使用，container是容器使用，也就是我们说的Docker。两边都有server端和Host OS（虚拟机上的系统）。我们知道每个APP上都有Bin/libs，在Docker容器技术环境下，相同的APP可以共用同一个Bin/libs。大大节省了所占的资源空间。【八、DevOps实践与转型路径】Q56：到目前为止，已经学习了很多DevOps的功能，但是有一个困惑，对于使用DevOps是零代码，那么对于专业的开发人员来说，会不会慢慢降低他们的代码开发积极性？A：DevOps提供的零代码是指在整个DevOps工具链中希望是零代码的，通过将一切可自动化的工具自动化，将开发人员从各种维护工作中解放出来，使他们专注于开发。Q57：在DevOps实践中，环境差异的问题需要在哪个环节就开始着手来注意减少或者避免？A：配置即代码，在开发环节配置差异化的时候把环境差异等都配置进去。Q58：在DevOps转型过程中，对组织和团队最有挑战的有哪些？A：我认为DevOps转型最难的有两方面：一是如何争取公司高层同意推动DevOps转型；二是如果请了教练/顾问协助DevOps转型，顾问/教练走后，如何继续保持和落地DevOps实践。Q59：小团队如果想要使用DevOps需要全员学习吗，感觉每个人都学习时间成本挺高的，是否可以专人负责特定阶段？A：团队如果想要进行DevOps转型，需要专门有一个人把这些流程和工具研究明白，或者聘请一位外部DevOps顾问，再由整个专职人员或DevOps顾问在整个团队进行培训和推动。Q60：四个闭环过程中遇到困难或者难点是否可以列举？有什么避免的方案？A：先回忆一下四个闭环过程：l   第一阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量； l   第二阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本； l   第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流； l   第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力。难点包括：l   打通需求难。产品侧和研发侧沟通难。在传统瀑布模式下产品和研发的沟通存在很多问题，比如需求沟通不明确等，引入敏捷的计划会议，在计划会议上做需求澄清，可以解决这一难题。l   开发测试融合难。在很多公司这是两个团队，还有些公司没有测试的角色，要进行人员和过程的融合比较困难。l   研发运营结合难。研发运营一体化，运营部分的内容怎么跟开发结合也是一个难点。l   组织结构管理难。整个流程打通了，人员的管理和组织结构的变动方面也可能会存在问题。以上难点需要根据公司具体情况来实践和探索最佳解决方案。+小姐姐微信加入训练营交流群

2、逻辑和知识图嵌入    如果你平时就有关注arXiv或者AI会议论文的话，你肯定已经发现，每年都会有一些越来越复杂的知识图嵌入模型，每次都会把最佳表现的记录刷新那么一点点。那么，知识图的表达能力有没有理论上限呢，或者有没有人研究过模型本身能对哪些建模、对哪些不能建模呢？    论文4：Group Representation Theory for Knowledge Graph Embedding链接：https://grlearning.github.io/papers/15.pdf    论文 4 从群论的角度来研究KG嵌入。结果表明，在复空间中可以对阿贝尔群进行建模，且证明了RotatE（在复空间中进行旋转）可以表示任何有限阿贝尔群。有没有被“群论”、“阿贝尔群”这些数学名词吓到？不过没关系，这篇文章里有对相关的群论知识做简要介绍。不过这个工作在如何将这个工作拓展到1-N或N-N的关系上，还有很大的gap。作者提出一个假设，即或许我们可以用四元数域H来代替复数空间C……论文5：Quaternion Knowledge Graph Embeddings链接：https://papers.nips.cc/paper/8541-quaternion-knowledge-graph-embeddings.pdf    在这次NeurIPS' 19上，这个问题被 Zhang et al. 解决了。他们提出了QuatE，一个四元数KG嵌入模型。什么是四元数？这个需要说清楚。简单来说，复数有一个实部，一个虚部，例如a+ib；而四元数，有三个虚部，例如 a+ib+jc+kd。相比复数会多出两个自由度，且在计算上更为稳定。QuatE将关系建模为4维空间（hypercomplex space）上的旋转，从而将complEx 和 RotatE统一起来。在RotatE中，你有一个旋转平面；而在QuatE中，你会有两个。此外，对称、反对称和逆的功能都保留了下来。与RotatE相比，QuatE在 FB15k-237上训练所需的自由参数减少了 80%。    论文 6：Quantum Embedding of Knowledge for Reasoning链接：https://papers.nips.cc/paper/8797-quantum-embedding-of-knowledge-for-reasoning.pdf论文 6 提出了 Embed2Reason（E2R）的模型，这是一种受量子逻辑启发的量子KG嵌入方法。该方法可以嵌入类（概念）、关系和实例。    这里面没有量子计算。量子逻辑理论（QL）最初是由伯克霍夫和冯诺依曼于1936年提出，用于描述亚原子过程。E2R的作者把它借用过来保存KG的逻辑结构。在QL中（因此也是E2R中），所有一元、二元以及复合谓词实际上都是某些复杂向量空间的子空间，因此，实体及其按某种关系的组合都落在了特定的子空间内。本来，分布定律a AND（b OR c）=（a AND b）OR（a AND c）在QL中是不起作用的。但作者用了一个巧妙的技巧绕开了这个问题。    作者在论文中还介绍了如何使用QL对来自描述逻辑（DL）的术语（例如包含、否定和量词）进行建模！实验结果非常有趣：在FB15K上，E2R产生的Hits @ 1高达96.4％（因此H@10也能达到）；不过在WN18上效果不佳。事实证明，E2R会将正确的事实排在首位或排在top10以下，这就是为什么在所有实验中H @ 1等于H @ 10的原因。    补充一点，作者使用LUBM作为演绎推理的基准，该演绎推理包含了具有类及其层次结构的本体。实际上，这也是我关注的焦点之一，因为标准基准数据集FB15K（-237）和WN18（RR）仅包含实例和关系，而没有任何类归因。显然，大型知识图谱具有数千种类型，处理该信息可以潜在地改善链接预测和推理性能。我还是很高兴看到有越来越多的方法（如E2R）提倡将符号信息包含在嵌入中。     论文 7：Logical Expressiveness of Graph Neural Networks链接：https://grlearning.github.io/papers/92.pdf    让我们继续来考察图神经网络的逻辑表达。论文 7 中对哪些GNN架构能够捕获哪个逻辑级别进行了大量的研究。目前为止，这个研究还仅限于一阶逻辑的两变量片段FOC_2，因为FOC_2连接到用于检查图同构的Weisfeiler-Lehman（WL）测试上。作者证明，聚合组合神经网络（AC-GNN）的表达方式对应于描述逻辑ALCQ，它是FOC_2的子集。作者还进一步证明，如果我们添加一个独处成分，将GNN转换为聚合组合读出GNN（ACR-GNN），则FOC_2中的每个公式都可以由ACR-GNN分类器捕获。这个工作怎么说呢？简直是不能再棒了！论文 8：Embedding Symbolic Knowledge into Deep Networks链接：https://papers.nips.cc/paper/8676-embedding-symbolic-knowledge-into-deep-networks.pdf    论文 8 提出了模型LENSR，这是一个具有语义正则化的逻辑嵌入网络，它可以通过图卷积网（GCN）将逻辑规则嵌入到d-DNNF（决策确定性否定范式）当中。在这篇文章中，作者专注于命题逻辑（与上述论文中更具表现力的描述逻辑相反），并且表明将AND和OR的两个正则化组件添加到损失函数就足够了，而不用嵌入此类规则。这个框架可以应用在视觉关系预测任务中，当给定一张图片，你需要去预测两个objects之间的正确关系。在这篇文章中，Top-5的准确率直接将原有84.3%的SOTA提升到92.77%。      转自，杨晓凡，https://www.leiphone.com/news/201912/GsRSElsUReef0z7o.html

作为大众耳熟能详的优化算法，梯度下降法受到的关注不要太多。梯度下降法极易理解，但凡学过一点数学的童鞋都知道，梯度方向表示了函数增长速度最快的方向，那么和它相反的方向就是函数减少速度最快的方向了。对于机器学习模型优化的问题，当我们需要求解最小值的时候，朝着梯度下降的方向走，就能找到最优值了。那么具体来说梯度下降的算法怎么实现呢？我们先来一个最简单的梯度下降算法，最简单的梯度下降算法由两个函数，三个变量组成：函数1：待求的函数函数2：待求函数的导数变量1：当前找到的变量，这个变量是“我们认为”当前找到的最好的变量，可以是函数达到最优值（这里是最小值）。变量2：梯度，对于绝大多数的函数来说，这个就是函数的负导数。变量3：步长，也就是沿着梯度下降方向行进的步长。也是这篇文章的主角。我们可以用python写出一个最简单的梯度下降算法：

1.TEE TEE（可信执行环境），存在于智能手机、平板电脑，或任意移动设备主处理器中的一个安全区域，确保各种敏感数据在一个可信环境中被存储、处理和受到保护。TEE为授权安全软件，也称为“可信应用”提供一个安全的执行环境，通过实施保护、保密性、完整性和数据访问权限确保端到端的安全。 2.MPC MPC（安全多方计算），是一个复杂的密码协议，最早是由姚教授在82年通过百万富翁问题提出来的。MPC的通用表述是：针对无可信第三方时，安全地进行一个协同计算问题。即在一个分布式网络中，多个参与实体各自持有秘密输入，各方希望共同完成对某函数的计算，而要求每个参与实体除计算结果外均不能得到其他用户的任何输入信息。 3.联邦数据分析 联邦数据分析是指允许多合作方参与的结构化数据SQL分析作业。开发者无须集中收集数据即可在多部设备上训练机器学习 (ML) 模型，确保用户数据保留在设备端，且能优化多种体验。 4.联邦机器学习 联邦机器学习允许多合作方参与模型训练和评估作业。联邦机器学习是一种加密的分布式机器学习技术，参与各方可以在不披**层数据和底层数据的加密（混淆）形态的前提下共建模型。它可以实现各个企业的自有数据不出本地，通过加密机制下的参数交换方式，就能在不违反数据隐私法规情况下，建立一个虚拟的共有模型。在这样一个机制下，参与各方的身份和地位相同，成功实现了打通“数据孤岛”走向“共同富裕”的目标。 5.横向联邦学习 横向联邦学习指的是参与各方拥有同样特征空间，而在样本空间上互不相同的联邦学习。例如，华为和多个合作伙伴们共建脑癌识别模型，但是各自利用自家样本建立的模型的效果和稳定性都不能满足现实需求。可以利用横向联邦学习的机制，充分利用多家的样本，同时在不泄露样本的条件下，构建一个非常大的模型，在横向联邦学习中，华为和所有合作伙伴们，都是有（X,Y）的数据的，其中X是输入，Y是标签。每个参与方利用本地数据训练模型，加密梯度上传给服务器A，服务器A聚合各用户的梯度更新模型参数；服务器A返回更新后的模型给各参与方；各参与方更新各自模型。 6.纵向联邦学习 纵向联邦学习是指在两个数据集的用户重叠较多而用户特征重叠较少的情况下，把数据集按照纵向（即特征维度）切分，并取出双方用户相同而用户特征不完全相同的那部分数据进行训练。纵向联邦学习的本质是特征的联合，比如华为有数据的A特征，合作伙伴有数据的B特征，双方需要合作来建模，需要用到数据的A和B两个特征，但是不能互相把数据发给对方，此时就需要用纵向联邦学习了。这种方法利用的是两边的数据都有共同的ID，但是特征是完全不一样的，可以通过一方特征来弥补另一方特征的不足。匹配过程中需要注意隐私保护的问题，在整个过程中参与方都不知道另一方的数据和特征，且训练结束后参与方只得到自己侧的模型参数。

这是一篇关于度量学习损失函数的综述。检索网络对于搜索和索引是必不可少的。深度学习利用各种排名损失来学习一个对象的嵌入 —— 来自同一类的对象的嵌入比来自不同类的对象的嵌入更接近。本文比较了各种著名的排名损失的公式和应用。深度学习的检索正式的说法为度量学习(ML)。在这个学习范式中，神经网络学习一个嵌 入—— 比如一个128维的向量。这样的嵌入量化了不同对象之间的相似性，如下图所示。学习后的嵌入可以进行搜索、最近邻检索、索引等。这个综述比较了各种损失的公式和应用。综述分为两部分。第一部分对对比损失和三元组损失进行了对比。第二部分将介绍N-pairs损失和Angular损失。.英文原文：https://ahmdtaha.medium.com/retrieval-with-deep-learning-a-ranking-loss-survey-part-2-

ModelArts 社区开发者成长路线ModelArts 快速上手ModelArts 系列课程ModelArts开发资源ModelArts：一站式AI开发平台AI 全栈计划基础篇ModelArts 官方开发文档AI 全栈计划进阶篇ModelArts 精品FAQ汇总ModelArts 快速入门文档AI 全栈计划应用篇 ModelArts 新特性及配套案例华为云 AI 实战营ModelArts-Lab GiteeModelArts 社区优质活动推荐MDG 及AI 创新沙龙《基ModelArts   OCR文字识别SQLite数据库管理》暨华为云MDG重庆站首秀 AI 创新开发者沙龙—在武大樱花下写防疫课观后感基于ModelArts的交通标志识别及其在无人车系统中的应用“如何转型搞AI”圆桌论坛高精地图3D目标检测DevRun 开发者沙龙下一代 AI：自监督 VS 有监督，谁更胜一筹？基于ModelArts与HiLens的智能塔台监控防护系统解决方案基于ModelArts与HiLens端云协同开发行人检测与跟踪方案北京老炮儿旭哥说AI：谈谈企业级AI开发平台普惠AI风口之下传统企业的转型之路AI Gallery-开发者学习·交流·实践HDC.Cloud 2020基于华为云AI平台开发口罩智能识别方案强化学习的落地实践华为诺亚方舟实验室在AutoML的技术成果分享基于ModelArts的AI应用开发调参及模型优化实践ModelArts平台上使用MindSpore实现ResNet50训练速度翻倍2020 AI 实战营2020年华为云AI实战营课程2020年华为云AI实战营活动汇总【直播回放】第1章-图像分类【直播回放】第2章-物体检测  【直播回放】第3章-图像分割  【直播回放】第5章-OCR  【直播回放】第6章-视频分析 【直播回放】第7章-NLP 【直播回放】第8章-语音识别 2020 AI 全栈计划2020年AI全栈成长计划活动汇总AI全栈成长计划-AI基础篇课程AI全栈成长计划-AI进阶篇课程AI全栈成长计划-AI应用篇课程【直播回放】零基础入门AI 零代码开发模型【直播回放】BUFF加持，ModelArts助你进阶炼丹师！【直播回放】ModelArts+HiLens   端云协同应用开发实战【直播回放】乘风破浪，一名合格AI打工人的学习之路2020 Qcon 上海王俊：MindSpore-端边云统一训练和推理的AI计算框架白小龙：ModelArts-全流程加快AI应用开发和部署夏飞：HiLens-端云协同多模态AI应用开发和实践朱声高：ModelArts Pro-在行业多模态AI开发的应用实践2020年十佳论坛帖2020年十佳博文【基于ModelArts】带你零代码开发检测口罩是否佩戴的模型医学与AI的结合（一）：如何基于ModelArts自动机器学习完成心脏病预测模型华为云“云上先锋”·AI主题赛（垃圾分类）-Top7复盘（转发自第7名获奖选手的分享）【手摸手学ModelArts】传说中的“云毕业照“，先睹为快!用ModelArts轻松玩转Python正则表达式和魔法方法难例挖掘助力ModelArts AI开发平台完成全流程闭环和大家一起讨论一下在modelarts操作中最容易遇到哪些问题ModelArts在数据标注、数据过滤上的“奇技淫巧”：自动分组ModelArts精品FAQ汇总数据风格变换：ModelArts的数据域迁移功能ModelArts开发速成，看这里！！（快速入门、进阶学习资料、开发案例、开发者活动等）【吃螃蟹的程序猿】ModelArts-AI市场算法，断点训练(Resume Training)和迁移学习(Finetuning）【每天进步一点点】基于ModelArts AI市场算法MobileNet_v2实现花卉分类，支持CPU、GPU、Ascend推理告别夏日空调，用华为云ModelArts训练AI鬼故事生成器，0成本打造降温神器【AI实战营】第五章OCR延伸学习材料【乘风破浪的开发者】华为云云享专家胡琦：快快使用ModelArts，零基础也能玩转AI！手把手教你用ModelArts基于YOLO V3算法实现物体检测Demo分享 | 当自动驾驶遇到ModelArts，ModelArts AI Gallery与HiLens Kit开发业界广泛流传一句话：数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限而已开发教程 |基于ModelArts的视频全量目标分析和建模案例分析2020年最受欢迎活动2020年最佳版主2020华为云AI实战营运气男孩主页 | 关注人工智能全栈成长计划向云而生1024程序员节云筑2020年终盛典：云上会考AI考场AI创意案例大PKModelArts 社区 2020 全面回顾请点击查看：【ModelArts 社区】2020我们茁壮成长《攀登AI之峰》致敬每一位AI 开发者，恭祝大家牛年勇攀高峰！(点击即可播放）新年福利来啦！本帖回复你想对 ModelArts 社区想说的话（文字中需含“ModelArts社区”关键字），如：学 AI 就上 ModelArts 社区，即可参与福利活动。获奖规则：楼层的的 5%、10%、15%、20%、25%、30%......95% 即可获得ModelArts书籍盖楼数排名前20送ModelArts社区大礼包（含 ModelArts 定制版限量口罩、笔记本、卫衣、贴纸、鼠标垫、ModelArts书籍等），相同楼层按照发帖顺序，最早的获得活动规则：参与用户必须体验或访问过 ModelArts 才可参与活动：点击访问 ModelArts 成功即可，否则视为无效参与；活动时间：即日起至2月27日00:00；活动结束后5日内公布详细结果，公示期3天，公示期结束开始兑奖，一般15个工作日左右完成发放，但可能会有所延长；所有奖品都是活动结束后，统一收集并确认信息后进行发放，活动奖品颜色随机，且部分奖品数量有限发完即止；因奖品采购时间、批次产生的差异属正常情况，如奖品库存不足将进行同价位奖品调换，介意者谨慎参与活动；如发现使用他人身份恶意重复报名活动，或采取机器批量注册/虚拟手机号注册/购买账号等恶意注册行为进行违规行为，华为云AI社区有权取消相应人员的活动参与权利，并收回相关奖励；所有的获奖账号必须在领取奖品之前就完成实名认证，且实名账号必须与参与活动的账号为同一个，同一实名账号仅可参与此活动一次。本次活动所有回帖内容需满足华为云论坛发帖规范：https://bbs.huaweicloud.com/forum/thread-23077-1-1.html。ModelArts 社区祝大家新年快乐，万事如意，代码无Bug！获奖公告：（因存在有人恶意刷帖，华为云论坛自动屏蔽，导致部分楼层断层，在活动基础上新增用户排序让真实的用户也能获得奖品）楼层排序楼层比例楼层中奖楼层（四舍五入）中奖账号奖品6135%30.6531zhengguixiangModelArts书籍61310%61.361多米诺的古牌ModelArts书籍61315%91.9592#N/AModelArts书籍61320%122.6123hispchomeModelArts书籍61325%153.25153疫情快快结束ModelArts书籍61330%183.9184#N/AModelArts书籍61335%214.55215#N/AModelArts书籍61340%245.2245#N/AModelArts书籍61345%275.85276#N/AModelArts书籍61350%306.5307#N/AModelArts书籍61355%337.15337#N/AModelArts书籍61360%367.8368#N/AModelArts书籍61365%398.45398#N/AModelArts书籍61370%429.1429#N/AModelArts书籍61375%459.75460#N/AModelArts书籍61380%490.4490#N/AModelArts书籍61385%521.05521麻衣ModelArts书籍61390%551.7552精彩无限ModelArts书籍61395%582.35582精彩无限重复 顺延下一位tzywwModelArts书籍用户排序正常通过审核用户数比例楼层（四舍五入）中奖楼层中奖账号奖品775%3.854离人上千秋ModelArts书籍7710%7.78加油O幸福ModelArts书籍7715%11.5512HW-QGSModelArts书籍7720%15.415拓佑ModelArts书籍7725%19.2519胡琦ModelArts书籍7730%23.123沈云ModelArts书籍7735%26.9527zhengyong134ModelArts书籍7740%30.831zgx1636964790ModelArts书籍7745%34.6535Hello DiggerModelArts书籍7750%38.539倪平宇ModelArts书籍7755%42.3542元气满满的少女月ModelArts书籍7760%46.246多米诺的古牌ModelArts书籍7765%50.0550云宝的小hModelArts书籍7770%53.954十年树木ModelArts书籍7775%57.7558listen2youModelArts书籍7780%61.662gudengModelArts书籍7785%65.4565夏暖ModelArts书籍7790%69.369麻衣ModelArts书籍7795%73.1573wcrw129ModelArts书籍大礼包用户（盖楼用户较少，只有两名用户参与）25张辉大礼包2RabbitCloud大礼包请上面获奖用户在2021年3月11日24点前反馈问卷，邮寄时间问卷截止后一周。问卷地址：https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=03ac5527840047a3a5a03d22d18cea22

直播回放https://bbs.huaweicloud.com/live/cloud_live/202101281900.html 内容讲解材料请参考附件实操材料课程名称链接使用java命令提交spark任务样例https://bbs.huaweicloud.com/forum/thread-90792-1-1.htmlSpark读写HBase样例https://bbs.huaweicloud.com/forum/thread-90827-1-1.htmlSpark-submit提交SparkSQL样例https://bbs.huaweicloud.com/forum/thread-90877-1-1.htmlSparkStreaming读取Kafka写入HBase样例https://bbs.huaweicloud.com/forum/thread-90888-1-1.html