我们这里要简要介绍一下增强学习(RL)——一种为了提高玩游戏效率的训练程序的通用技术。我们的目标是解释其实际实现:我们讲述一些基本理论,然后走马观花地看一下为玩《战舰》游戏而训练神经网络的最小python程序。 导言 增强学习[RL]技术是一种可用于提高效玩游戏效率的学习算法。与督导机器学习[ML]方法一样,增强学习是从数据——这里是指过去玩游戏的数据——中进行学习。然而,尽管督导学习算法只是根据现有的数据进行训练,但RL还挑战如何在收集数据的过程中表现良好性能。具体地说,我们所追求的设计原则是 让程序从过去实例中识别好的战略, 通过连续地玩游戏快速地学习新的战略。 我们在这里特想让我们的算法快速学习的理由是在培训数据有限或者战略空间太大而难以进行穷尽搜索的情况下最富有成果地运用RL。正是在这种体制下督导技术面临困境而RL则闪耀着光芒。 我们在本贴中要回顾一般性的RL培训程序:策略梯度、深度学习方案。我们下一节要回顾一下这种办法背后的理论。随后,我们将粗略地演示一下培训神经网络来玩战舰游戏的 python 实现。 我们的python码可以从我们的github网页这里下载。它需要 jupyter, tensorflow, numpy, 和 matplotlib包。 策略梯度,深度RL 策略深度和深度RL有两个主要构件。下面我们要详述二者并描述它们是如何协作训练好的模型的。 策略网络 一定深度RL算法的策略是一种神经网络,它将状态值ss映射为一定游戏行为 aa的概率。 换句话说,该网络的输入层接受环境的数字编码——游戏在特定时刻的状态。当输入通过网络馈送后,其输出层的值对应着我们现有每个行动可选的对数概率——我们可供选择的每个可能的行动都有一个输出节点。请注意如果我们肯定知道我们应采取的步骤,只有一个输出节点有一定的概率。但如果我们的网络不能肯定哪种行动最优时,那么就不只一个节点有一定的权值。 为了说明这一点,我们来图示一下下面“战舰”程序中所用的网络。(要回顾“战舰”的游戏规则请看注[1])简明起见,我们只用一维战舰网格。我们然后对我们对手的每个网格位置用一个输入神经元将我们对目前的环境知识进行编码。具体地说,我们对于每个神经元/下标运用下列编码: 在下面例图中,我们有五个输入神经元,因此游戏盘的大小是五。前三个神经元的值是−1−1 表明我们尚未轰炸这些网格点。最后两个分别是+1+1 和 00, 意味着战舰位于第四而不是第五的位置。 需要注意的是,在所显示的策略网输出层中,前三项值标为对数概率。这些值对应着每个下标的下次轰炸的概率。我们不能再次轰炸第四和第五个网格点,所以,尽管网络可能对这些神经元输出一些值,我们会忽略它们。 需要注意的是,在所显示的策略网输出层中,前三项值标为对数概率。这些值对应着每个下标的下次轰炸的概率。我们不能再次轰炸第四和第五个网格点,所以,尽管网络可能对这些神经元输出一些值,我们会忽略它们。 在我们继续前,我们注意到我们对我们的策略运用神经网络的理由是进行有效地归纳:对于象围棋这样有大量状态值的游戏来说,收集每个可能的游戏盘位置的数据并不可行。这正是ML算法所擅长的场合——根据过去的观测进行归纳从而对新局面做出很好的预测。为了将注意力放在RL上,我们不想在本贴中回顾ML算法(但你可以看看我们的库中的入门章节)。我们只是提请注意——利用这些工具,我们通过只培训游戏中有代表性的子集就能获得良好的性能而不必研究会非常庞大的整个集合。 收益函数 为了训练RL算法,我们必须反复地进行游戏/得分过程:我们根据当前的策略玩游戏,根据与该网络输出的概率成比例的频率做出移动选择。如果所采取的行动得到好的结果,我们就要在往后提高这些行动的概率。 收益函数是我们用于对我们以前游戏的结果进行正式打分的工具——我们将鼓励我们的算法在游戏期间努力将该量最大化。它其实是RL算法的超级参数:可以使用许多不同的函数,并每个都得出不同的学习特征。对于我们的战舰程序来说,我们用下列函数 只要游戏日志完备,该函数考查在时间t0时所采取的行动a并返回命中值h(t)的加权和,以及该游戏所有未来步骤。在这里,如果我们在步骤t时命中,h(t)则为1,否则为0。 在到达(2)时, 我们承认并不对所有可能的收益函数集合进行仔细搜索。但我们肯定这一选择会有很好的游戏效果,它们有良好的目的性:具体地说,我们注意到加权项(0.5)t−t0(0.5)t−t0 能强烈地激发当前步骤的命中率 (对于在t0时命中,我们得到的收益为11 ), 但在(t0+1)(t0+1)时命中的行为在 t0t0 时也有收益—— 其值为0.50.5。同样,在 (t0+2)(t0+2) 时命中收益为0.250.25, 依此类推。 (2)的这种超前加权起到了鼓励有效探索棋局的作用:它迫使程序顾及有利于未来命中的步骤。 (2) 中出现的其他要素是减去h(t)¯¯¯¯¯¯¯¯¯h(t)¯。 这是随机网络会获得的预期收益。通过将该项除去,我们的网络只有表现超过随机选择才有收益——该收益是这一学习过程的净加速。 随机递减 为了训练我们的算法在游玩期间收益最大化,我们运用了递减法。为了表现这一点,我们设想让我们的网络参数 θθ 在游戏的某些特定步骤发生改变。对所有可能的步骤进行平均,于是有了预期收益的梯度公式, 这里, p(a)p(a) 的值是我们网络行动的概率输出。 不过,我们通常无法求得上述最后一行的值。但我们可以用抽样值进行迫近:我们只是用我们当前网络玩游戏,因此我们用在第 ii次移动时所获得的实际收益取代上述的预期收益, 这里aiai 是所采取的行动, r(ai)r(ai)是获得的收益,可以通过反向传播求该对数的导数(对于那些熟悉神经网络的人来说:这是叉熵损失函数的导数,当你处理类似督导学习训练事例的事件时,可以用所选择行动 aiai 做为标记以应用该函数)。函数g^ig^i 提供理想梯度的噪声估计,但步骤多了会导致“随机”递减,一般推动我们朝着正确的收益最大化前进。 训练过程总结 总之,RL训练是迭代进行:要起动迭代步骤,首先我们用我们当前的策略网络玩游戏,随机地根据网络输出选择移动步骤。在游戏结束后,我们通过计算每次移动所获得的收益来对结果打分,例如在战舰游戏中,我们用(22)。 一旦完成这一步,我们就用 (44)来估计收益函数的梯度。最后,我们用αα小步长步骤参数更新网络参数 θ→θ+α∑g^iθ→θ+α∑g^i, 接着,我们用经过更新的网络继续玩新的游戏,依此类推。 要明白这一过程实际上是鼓励在练习中产生良好结果的行动,注意 (44) 与在步骤 ii中所获收益成比例的。因此,我们在 (44)的方向上调整参数,我们极力鼓励那些产生很大收益结果的行动。另外,收益为负的步骤受到抑制。网络按这种方式经过一段时间后将学会考察这一系统并提出可能产生最佳结果的步骤。 这说的是深度策略梯度RL的基础。我们现在回到我们战舰python示例上来。 Python 代码流程 — 战舰 RL 加载所需的包。 定义我们的网络——一个全面相联的三层系统。下面代码基本上是 tensorflow 标准本,通过了其第一教程就可得出。有一项非同凡响的事是我们已将(26)集的学习速度定为占位符值 (9) 。这将让我们用下列所观察到的捕获收益改变我们的步长。 其次,我们定义了让我们用我们的网络玩游戏的方法。变量TRAINNING决定了我们是否采取理想步骤或选择随机步骤。请注意该方法返回一组记录游戏过程的日志集。这些是训练所需要的。 我们收益函数的实现(2): 最后是我们的训练循环。我们反复地玩多次游戏,每次都记分,然后调整参数——用阿尔法乘以所获得收益得出学习速度。 运行上一单元,我们看到训练起作用了!下面例子通过将TRAINNING设为FALSE跟踪play_game()方法。这展示了一种智能步骤选择过程。 这里前五行是游戏盘编码——每一步都用(11)来填充网络。第二至最后一行是所选择的系列网络选择。最后一行是命中日志。请注意前两步很好地抽样了游戏盘不同地区。此后,所记录命中为 66。该算法然后智能地选择 77和 88,它能推断它们一定是战舰的最后位置。 下图进一步地描述了学习过程的特征。它将游戏平均长度(完全轰炸战舰所需步骤)与训练时间进行对照。该程序非常迅速地学到基础知识并随着时间推进而持续进步。 小结 在本贴中,我们讲到RL的一种——即策略梯度、深度RL方案。该方法一般是当前最知名战略 ,偶尔也从其他方法中取样,最终实现策略的迭加改进。其两个主要成份是策略网络和收益函数。尽管网络结构设计通常是督导学习考虑得最多的地方,但在RL的情况下最费神的是收益函数。为了方便训练(依靠长远预测会放慢学习过程),好的选择应该是时间上尽可能地靠近。然而,收益函数常常也会损害到这一过程的最终目标(“赢”这场游戏——鼓励侧向追求,而一些侧向追求是不必要的,但如果不加注意会时常出现)。要在这两种互相竞争的要求间进行权衡并不容易。所以收益函数设计在某种程度上说是一种艺术。 我们这个简短的介绍只想说明RL实际上是如何实行的。更多细节,我们推荐两个来源:Sutton 和Barto的文本书[3]和最近John Schulman的谈话[4]。 注释和参考资料 [1]游戏规则:(常见的简单游戏:略) [2] 我有位同事(HC)提出,该程序可能在某个点上开始拟合过度。但这种一维游戏战舰的位点太少,训练集分割似乎不太合适。不过,如果我们转移到更高维度并加入更多战舰时会管用。 [3] Sutton 和 Barto, (2016). 《增强学习引论》文本地址在 此. [4] John Schulman, (2016),《弯区的深度学习学院》 Youtube 的谈话录音在 此. 本文译者为:kundogma 原文来自:EVAVDB
互联网金融相关技术的突破,带动了金融行业在不同垂直领域的加速发展。从最早的电子支付,到最近的银行,理财,保险,信用,……,互联网金融正在逐步渗透到大众生活的方方面面。蚂蚁金融服务集团(以下简称:蚂蚁金服)作为互联网金融的实践者,一直在努力探索技术创新,用技术与数据的力量,给社会大众带去“安全、普惠、绿色”的金融服务。普惠金融是指立足机会平等要求和商业可持续原则,以可负担的成本为有金融服务需求的社会各阶层和群体提供适当、有效的金融服务。小微企业、农民、城镇低收入人群、贫困人群和残疾人、老年人等特殊群体是当前我国普惠金融重点服务对象。大力发展普惠金融,是我国全面建成小康社会的必然要求,有利于促进金融业可持续均衡发展,推动大众创业、万众创新,助推经济发展方式转型升级,增进社会公平和社会和谐【1】。 近年来,我国普惠金融发展呈现出服务主体多元、服务覆盖面较广、移动互联网支付使用率较高的特点。伴随着服务主体和服务内容的快速扩大,如何给用户提供更安全,更高效、更便捷的随身服务,成为我们的一个非常重要的课题。蚂蚁金服长期致力于对前沿技术创新的探索与应用,结合自身的业务发展要求,摸索出一套智能化、体系化的智能服务解决方案,并应用到日常客服服务中,在2015年“双11”承受了巨大服务量的考验,通过自助机器人承接95%服务请求,整体接通率98%以上,给用户带去随身随地可触达的极致服务体验。接下来希望通过本文,分享蚂蚁金服在智能服务领域的实践经验和思考,和业界同行们一起来共同推动智能服务技术在互联网金融的发展和应用。一、蚂蚁智能服务整体架构及应用 蚂蚁业务的快速发展,对客服响应能力和应急能力提出了非常高的要求。如何在保证业务快速发展的背景下,给用户提供体验更好、服务质量更优的客户服务保障体系,是我们智能服务体系架构的核心目标。蚂蚁智能服务整体架构包含四个主要部分:我的客服(自助),服务大厅(在线),95188(热线),服务工作台(工作台)。蚂蚁智能服务整体架构如图1.1所示。 图1.1 蚂蚁智能服务整体架构 从用户服务诉求角度,可以大致划分为咨询类、求助类、举报类三种类型。从支付宝钱包中“我的客服”的真实使用数据分析,大部分的用户问题是能够通过自助渠道得到较好的服务。目前蚂蚁智能机器人(我的客服)应用已经承接了日常90%的服务诉求(图1.2),服务满意度已经接近人工服务满意度。 在蚂蚁智能服务中,我们大量采用了以深度学习和自然语言处理为核心的人工智能技术,其中数据技术发挥了非常重要的作用。在“我的客服中”,以用户的行为轨迹作为特征,训练深度神经网络模型,精准“猜测”用户问题。我们构建了一个模型预测的数据闭环,模型产生预测结果推荐给用户,用户点击形成反馈数据,反过来进一步训练和改进模型。通过这样一个数据闭环,一个场景的问题预测从冷启动到自动更新全部自动化。在热线电话的IVR中,我们采用了国际领先的基于深度学习的语音技术,改变传统热线CC系统的菜单式引导模式,让用户直接通过对话语音描述需要求助的问题,理解用户语义进行精准的用户引导。用户画像和行为分析能够根据用户的不同状况,准确分析用户问题的复杂度和紧急程度,智能化引导用户进入最合适的渠道进行问题处理。例如对于涉及到安全、欺诈类的问题第一时间自动切换到VIP人工服务,最大化程度给用户提供安全保障。 最后,我们采用先进的文本聚类技术,从客服对话记录中挖掘用户问题和每个问题的答案,这样就生产出更加贴合用户真实诉求的知识库。其中的问题到答案的映射也通过深度神经网络完成。深度学习,自然语言处理,大数据处理,以及智能语音等技术的应用,有效提升了服务能力,缩短用户服务路径,从而大幅度优化用户服务质量和服务体验。智能服务体系的广泛应用,带动了服务行业的全面升级,把服务模式从繁重人力投入的1.0时代升级到机器智能为代表的2.0时代,非常贴合“安全、普惠、绿色”的整体社会目标,具备广阔的应用前景和巨大的社会价值。在此基础上,蚂蚁金服已经在服务赋能生态的目标上走出了坚实的一步,把蚂蚁自身业务沉淀的智能服务整体解决方案在蚂蚁金融云上打造了SAAS化的蚂蚁云客服产品,对外赋能合作商户、合作机构等生态合作伙伴。 图1.2 我的客服交互示例二、智能机器人技术 智能机器人技术在客服领域的应用,取得了非常好的业务效果,对于整体服务能力的优化提升以及对于行业模式的升级带来了变革性突破。在此基础上,我们扩展了通用的智能机器人技术,同时沉淀了一个智能机器人平台。 在智能机器人技术方面,我们大量使用了深度学习为主的人工智能算法。在知识库匹配上,我们使用深度神经网络语义模型来精确理解用户的问题。在聊天引擎中,我们采用文本到文本的递归神经网络(LSTM)来自动产生回答,可以跟用户进行非常好的拟人化和趣味性的交互。深度神经网络也被应用于实体提取、语言理解和对话状态跟踪,用来更好的理解用户意图。智能机器人技术还关注各种智能问答。例如,我们可以让机器人通过查询搜索引擎,归纳总结返回的结果来解决用户的问题。我们也可以让智能问答对接后台的投资顾问、保险等业务模型,来给用户提供金融服务。总之,智能机器人作为一个拟人化的智能界面,非常自然的连接了用户的需求和我们后台提供的金融服务。 整个智能机器人平台包括如下几个核心模块:对话管理、知识库管理、用户画像、语音处理、语义理解、策略引擎、问答匹配。智能机器人平台流程如下图所示(图2.1)。 图2.1智能机器人平台架构 通用的智能机器人技术和平台的沉淀,给上层业务发展提供了强大的通用化能力。智能机器人的服务能力不再局限于客服领域,应用到口碑O2O场景中可以演变成随身随地的生活小助手,应用到蚂蚁聚宝场景中可以变成您身边的高端投资理财顾问,给上层业务提供了更加灵活和人性化的服务能力。我们期待智能机器人技术的不断进步和完善,能够助力互联网金融行业的快速升级,给用户带去更加“安全、普惠、绿色”的金融服务。三、结语 蚂蚁金服长期致力于对前沿技术创新的探索与应用,结合自身的业务发展要求,摸索出一套智能化、体系化的智能服务解决方案,并应用到日常客服服务中。服务能力和服务质量在实践中得到了充分的验证,给用户带去随身随地可触达的极致服务体验,带动了服务行业的全面升级,把服务模式从劳动力密集型的1.0时代升级到机器智能为代表的2.0时代。同时,我们相信机器人技术具备更加广阔的应用场景,可以带动互联网金融行业的全面能力升级。机器人平台能力的沉淀,能够结合不同的业务场景,快速演变成随时随地无处不在的“助手”,如生活助手、投资顾问、保险顾问等等。蚂蚁金服将持续坚持“安全、普惠、绿色”的社会目标,致力于更多先进技术的探索和实践,和生态合作伙伴们一起推动互联网金融的升级,给社会大众带去可更大范围的“安全、普惠、绿色”的金融服务。 参考文献: 【1】国务院:《推进普惠金融发展规划》,2015年12月
“改变,是为了不变的年味。”从2015年10月28日中标央视春晚的一刻,支付宝春晚红包团队用4个月时间兑现了这一句承诺。尽管利用互联网红包守岁传统中国年已不再是新鲜事,然而“咻红包”的横空出世,还是为2016农历丙申年平添了一种有趣的过年声音、注入了一类全新的送福方式、增加了一个美满的守岁理由,并最终营造了一场盛大而幸福的国民事件。 支付宝统计数据显示,在2016年央视春晚直播期间,参与红包活动用户近2亿人。总参与3245亿次,是2015年春晚红包110亿次的29.5倍。在“咻红包”引爆的“国民派发红包现象”背后,支付宝是如何想的、怎么做的?整体成效是否达到了预期?本刊记者于2月17日赴杭州采访了支付宝红包团队的几位负责人。11亿现金投入值不值? 支付宝春晚红包的累计现金投入近11亿元,由三部分组成:一是中标央视的费用2.688亿元,由支付宝和手机淘宝承担。二是6.15亿元现金红包,由45家品牌商承担,招商过程耗时1个月。三是近2亿元的裂变红包现金,由支付宝承担。总体看,支付宝承担的现金成本总计超过3亿元。看到这组数据,很多人会为互联网巨头再次贴上“重补贴、轻KPI、不差钱”的标签。 面对这个问题,蚂蚁金服集团品牌与公众沟通部总经理陈亮从冠名费的视角为支付宝的投入算了一笔账。2016年央视春晚多屏直播收视率达到30.98%,近8.28亿观众通过电视和网络观看了直播。而国内某档知名综艺节目的冠名费是11亿元,平均收视率是每集2.6%,需要连续播放12集以上并且观众不重复才能与央视春晚的受众总量并论。陈亮直言:“仅从投入成本角度看,值不值,大家可以对比测算。” “8.28亿人看春晚,支付宝可以直观地看到多少人参与,多少高质量的关系生成。”在蚂蚁金服品牌部总监易杨看来,这是一笔划算的生意。“最终我们也给出了实际的回馈,超过8亿现金都作为红包、彩头回报给了观众。” 在投入数据的背后,陈亮对红包价值的产出也有一番解读。“支付宝基于4个目的做春晚红包:一是获得我们想要的关系链。二是让更多用户了解并加入我们。三是为合作商户扩大品牌宣传。四是为用户传递快乐和福气。” 据了解,支付宝预期用咻红包的方式拿到2亿对关系链,而实际新增了11亿对关系链。其中64%的用户来自三四线城市,包括很多之前覆盖不到的小城市及农村地区。同时,红包对理财产品销售的联动作用明显,春节期间余额宝申购金额同比增长61%,其中农村用户同比增长54%,西藏、贵州两地规模增长分别达到99%和82%。据蚂蚁金服商学院、第一财经商业数据中心联合发布的报告称,1亿支付宝实名用户分享了8亿现金红包,30%的用户将福卡传递给家人,裂变分享给好友的红包被领走超过9000万个。 对于市场反馈的一系列数据,陈亮评价:“从我们获得的关系链价值、商户获得的品牌宣传价值以及红包活动传递给客户的过年氛围看,市场表现远远超过了我们的预期。我们对红包活动的整体成效非常满意。” 市场的认可得益于优质的体验和亲民的玩法。在应用设计方面,支付宝直接在APP首屏的右上角建立红色按钮,点击即可进入红包界面。在玩法方面,有整点拼手气现金红包、裂变红包、“五福临门”福卡红包三种,在确保人与人之间互动性的前提下,三种玩法保证了游戏的及时性和持续性,形成了良好的体验互补。抢红包的过程则用支付宝当面付的独有声音“咻”来表现,简单而有趣。 “低门槛、新玩法,使我们在短时间内能够快速聚集用户并抓住其兴趣点。之前,我们在一二线城市的互联网用户密集度和活跃度非常高,而此次活动能够做到三四五线城市的高渗透率和用户增量,这绝对是一个意外惊喜!”尽管红包活动已在一周前结束,作为本次红包产品的负责人,蚂蚁金服支付事业群产品专家陈冠华仍难掩激动的心情。技术支撑完美体验 除夕夜21:09分,“咻一咻”的峰值请求达到了210亿次/分钟。作为蚂蚁金服无线支付的技术负责人,蚂蚁金服支付事业群研究员倪行军坦言:“技术部在去年12月收到春晚红包保障任务。从接到任务到2月1日做第一次测试,我们只有1个多月的准备时间,这对我们无线技术的基础设施和运维保障能力是一次极大的挑战。” 在基础设施层面,支付宝充分利用了集团内春节期间的空闲服务器资源,近一万台服务器在一周内完成快速扩容部署,充分体现了金融云的弹性能力。在运维保障层面,依据多年大促经验沉淀的“海量业务预测系统”做了全面的预测,制定了整体技术方案和各项技术指标,通过“全链路压测技术”对生产业务系统进行全链路覆盖的压力测试,以检验技术方案和各项指标的合理性与完整性,同时预备了上千条技术应急预案。 因完全基于无线客户端展开,在技术层面,这次任务和阿里巴巴历年的“双十一”、“双十二”大促有较大差异。比如“咻一咻”产品设计对技术提出了更为严苛的要求,在极限模拟测试中,单一客户端的极限点击是7次/秒,服务请求量较以往大促更为庞大。 以整点红包为例,从“咻一咻”到资金到账,技术处理分为两个阶段。一是“开奖阶段”,5分钟之内抢完6000万个红包,支付宝将红包业务系统前置,保证前置系统能够处理更大的并发访问量,保证用户请求能够及时进入红包系统并实时反馈中奖情况,实际达到了并发响应210亿次/分钟的业务请求。二是并行启动“资金到账任务”,6000万个红包被安排在分钟级发放至对应的6000万个客户账户,核心系统达到了百万笔每秒的处理能力。 得益于多年支付金融技术发展沉淀而来的金融云平台处理能力,技术部“零差错”完成了这两个阶段的任务,打了一场准备充分的技术战役。倪行军告诉记者:“我们将这场战役视为检验技术能力的绝佳机会,我们带着全新的方式,带着敬畏之心来做这个项目。整体效果完全满足之前的预测指标,整体体验是非常好的。”借红包唤醒关系链,凭场景做实关系链 “Back to basic!我们可以忘掉KPI,忘掉战略,但一定不能忘掉客户价值!”这是彭蕾来到支付宝后说的最多的一句话。 坐拥4亿实名用户,支付宝的账户优势不言而喻,这也是其打造高质量关系链、维系客户价值的天然基础。而通过红包贯通社交和支付两端、唤醒关系链的做法能够很好地拓展用户之间的关联度,进而配合蚂蚁金服体系内的各种场景方便用户更好地在线上、线下实现互动,包括网购消费、金融交易以及各种O2O场景。从此角度看,支付宝名为做红包,实则是为体系内的各种场景积累关系链。由此可见,今年红包之争的背后是社交关系链之争。 易杨表示,虽然很多人认为目前支付宝仅仅是一个支付工具,但它承载的各项应用早已脱离了工具的定位。支付宝的未来品牌定位是一种生活方式,它将是很多场景的集合。比如商品推荐、AA收款、互赠保险、“花呗”提额等等,都能够基于关系链做相应产品功能的激活或优化,进而提升产品活跃度。 在用场景维系关系链活跃度的同时,支付宝内部有一个评判好友真实关系及关系强弱的模型,从不同维度获取数据,比如是否经常联系、是否在手机通讯录中等等,进而依据维度权重对好友关系进行打分,动态监测关系链的质量及变化。 可以预期,在获取11亿对关系链后,阿里巴巴体系内的各种场景将进一步盘活这些关系链。以金融产品为例,蚂蚁金服有余额宝、招财宝、蚂蚁花呗、蚂蚁借呗等等,支付宝是承载这些金融产品的底层账户。正如陈亮所言:“支付宝希望借助红包和福卡,从不同维度唤醒这些底层账户的关联性,构建独特的生活场景、金融场景关系链,从而不断激发用户的互动意愿和交易活跃度。对于支付宝来说,社交的意义在于打造牢固的基于场景关系链的便捷服务。” 红包源自年俗,年俗决定需求。以海量需求为基础,互联网红包天然成为了支付与社交的绝佳契合点。利用春晚红包,支付宝为用户送去福气的同时,也为未来的场景服务、互动服务埋下了伏笔。
近几年来,伴随着全球范围内互联网技术普及和传统金融行业对创新变革的诉求,我国的互联网金融行业开始快速发展。拥有健全的客户识别与验证机制是金融企业开展业务的必要条件和监管要求,识别每一个客户的身份是金融企业应尽的企业义务。蚂蚁金融服务集团(以下简称:蚂蚁金服)作为互联网金融的实践者,一直在努力探索这类技术创新,在实践中摸索符合金融监管要求的互联网身份验证方法。 传统金融企业的客户身份识别过程主要依赖于“面对面”的用户到场的柜台当面签约,这种方式有助于核实本人操作并保障本人意愿。但在互联网的业务背景下,这种模式实现过于单一,并且面临柜面渠道不足、便捷性不佳和存在人工舞弊等风险。为了解决此类便捷性和可靠性之间的矛盾,蚂蚁金服一直在研发通过生物识别技术实现“非面对面”身份验证的方法,并在蚂蚁金服不同的业务场景做积极的探索和尝试,其中在支付宝APP 9.3版本中首次向亿万用户推出了“刷脸登录”,标志着互联网身份认证真正进入了“刷脸”时代,我们相信以“人脸识别”为代表的生物识别技术在互联网金融领域还有更广阔的应用场景和更大的提升空间,因此也希望通过本文向各位致力于将生物识别技术应用于互联网金融行业的客户身份识别体系和建设的同行分享和交流,并共同推动这一技术不断向前,使其真正成为互联网生态下的一种基础设施。 一.生物识别技术概述 生物识别技术是一个既古老又新潮的技术,拿指纹来说,“摁手印”这种身份认证方式已经有几千年的历史,说它新潮,也就是最近两三年,随着智能手机的快速发展和普及,指纹识别作为一种替代密码的登录或认证方式,也已经被很多用户接受。而现在我们所接触到的生物识别技术,本质上都是将生物技术与信息技术结合起来的新型识别技术,它将人体所固有的生理特征或行为特征,通过计算机技术、光学、声学、生物传感器等手段进行数字化,然后利用起来进行个人身份鉴定。相比于传统的身份识别方法,生物特征识别技术具有稳定、便捷、不易被仿造等优点,成为了安全认证的首选方式,近年来在国际上已经得到广泛的研究和应用。 原则上,人的任何生理或者行为特征,只要满足普遍性、安全性、唯一性、稳定性、可采集性等条件,都可以作为生物特征用于身份鉴定。所谓普遍性,指每个人都具有具备的特征;所谓安全性,指此特征对于每个人是独特的,可用于个人身份证明;所谓唯一性,指任何两个人的该特征都是不相同的;所谓稳定性,指该特征不会随时间等条件的变化而变化,至少在一段时间内是不变的;所谓可采集性,指该特征要便于采集和定量测量。 生物特征识别技术主要可解决两类问题:身份认证和身份识别。身份认证是判断待识别用户是否是他所声明的身份,只需要将输入的用户特征与数据库中所存储的该身份的模板特征相比对,是“一对一”的比较;身份识别是利用注册用户数据库来确定待识别用户的身份,需要将输入的用户特征与库中所有的身份模板特征进行比对并给出相似度,来判别待识别用户是库中的哪个身份(相似度最高),是“一对多”的比较。 一些常用的生理特征包括指纹、虹膜、人脸、视网膜、掌纹等,常用的行为特征包括声纹、笔迹、步态等。虽然每一种生物特征都可以作为身份辨别的依据,但是安全与体验衡量每一种生物特征优劣的两个标准,如图一所示不同的生物特征技术在这两个维度上都有所区别,各有侧重。比如虹膜识别技术是目前已知的所有生物识别技术中安全性最高的(十万分之一误识率的情况下准确率可以达到99%),但同时也是用户体验较差的,因为目前虹膜的采集还依赖与专用的红外摄像头,也需要用户主动式配合。从图一也可以看出指纹和人脸是在安全性和用户体验两方面都比较平衡的,也是目前市场上应用最广泛的两大生物识别技术。 图一:不同生物特征比较 二.基于人脸识别的身份认证体系 人脸识别技术相比较指纹识别技术,还有另一大特点就是人脸(或者说肖像)本身就已经是绝大多数身份证件(如身份证、护照、社保卡等)的鉴识主体,这个特点使得普通老百姓对人脸识别技术最容易接受,另一方面也因为存在官方的人脸数据库,采集人脸以后可以直接与官方人脸身份库比对,从而将“人脸“与”身份“直接联系起来,免去了用户提前注册的环节。下图二说明的就是一个完整的基于人脸识别的身份验证流程:通过移动客户端采集用户的活体人脸信息及身份证照片并进行防伪检测,最后使用人脸识别算法验证,检验“活体人脸”、“身份证照片人脸”与“官方人脸数据库”三者是否一致,从而达到人证合一校验的目的。这种方法的本质是利用“客户本人的生理特征要素”进行身份验证,与我国最新的《非银行支付机构网络支付业务管理办法》[1](第二十二条 支付机构可以组合选用下列三类要素,对客户使用支付账户余额付款的交易进行验证:[三]客户本人生理特征要素,如指纹等)的要求也是一致的。 图二 远程身份认证流程 蚂蚁金服一直致力于研发最先进的生物识别技术并将其应用于互联网身份认证领域,实现更高的安全性与更好的用户体验。以世界领先的人脸比对算法为基础,研发了交互式人脸活体检测技术和图像脱敏技术,并设计了满足高并发和高可靠性的系统安全架构,以此为依托的人脸验证核身产品提供服务化接口,已经成功产品化并在网商银行和支付宝身份认证等场景应用。这其中的几项核心算法分别是活体检测算法,图像脱敏算法以及人脸比对算法。其中活体检测算法是指系统发出几个随机的动作指令,如:点点头、眨眨眼、张张嘴等,并通过手机摄像头实时采集并检测用户是否正确的完成了相应的动作,同时检测其他 “活体面部信息”,最终达到采集活体人脸的目的。图像脱敏算法只是将人脸图像在网络传输之前,在采集端先进行某种单向变换使得图像不可逆,从而达到保护隐私的作用,同时又能保证脱敏后的人脸图像能尽可能的保留面部特征,在服务端可识别。人脸比对算法则是人脸识别核心算法中的核心,它的作用是判断任意两张人脸图片是来自同一个人还是不同人,从而达到识别人脸的目的。近几年随着深度学习神经网络技术的快速发展,以及社交网络带来的人脸图片数据爆发式增长,“人工智能+大数据”两方面的结合使得人脸识别核心算法也取得突破进展,根据2014年香港中文大学所做的一项研究结果表明,在国际公开人脸数据库LFW上,彼时人脸识别算法的准确率(99%)已经超过了肉眼识别(97.2%)[2],而目前蚂蚁金服运用的人脸识别算法在这个数据库上的准确率已经达到99.6%。另外在2015年初向公安部提交了人脸识别算法和技术的测试申请,进一步验证人脸活体检测防攻击和人脸比对两方面在实际真实场景的性能。 尽管如此,从算法到线上服务再到用户体验,从实验室性能到实际场景性能,仍然有很多挑战性问题需要解决。为此我们根据蚂蚁金服的业务场景,设计了满足高并发和高可靠性的系统安全架构,如下图三所示。除了算法服务层本身,还与核身决策层(核身行为采集)和业务决策层(业务行为采集)相结合,使得每一位用户的人脸验证结果,不仅仅取决于人脸比对算法的结果,还取决于这个用户在这个业务场景下发生的完整行为,从而形成一个多信息融合的立体决策体系和标准的人脸核身产品,支持蚂蚁金服不同的业务场景。 图三:生物识别核身架构 自2015年人脸识别功能在支付宝APP上线后,已在用户登录、实名认证、找回密码、商家审核、支付风险校验等多个场景中,作为主要身份验证方式全面应用,目前已经服务几千万用户,可同时满足每分钟20万人以上的身份验证需求。同时也在网商银行的会员注册场景使用人脸识别,内测阶段辅助注册三万多人,整体真实场景自动注册与审核环节包括人脸识别、身份证识别与防伪检测以及大数据分析三个步骤,人工确认环节未发生误检,极大的提高了人工效率并降低了审核成本,同时在真实业务场景下的千万级别用户身份验证的实践成果是其它国家尚未达成的,相信未来将成为互联网身份识别与验证的主流方法。 三.结语 实践表明,与传统基于密码等身份验证方法相比,人脸识别技术在安全性、可靠性、识别性能和用户体验方面的都得到了大幅提升,对实现互联网金融场景下的远程开户、网上支付等应用具有很现实的意义。蚂蚁金服在声纹,眼纹,掌纹,笔迹等生物认证核心技术研发上也同步推进,通过多因子认证的方式增强人脸识别,达到更高的安全等级和识别精度。此外,蚂蚁金服联合国家相关机构,正在起草人脸识别技术的系列标准,进一步规范人脸识别的技术指标和要求,为业务的深入和推广提供基础参考。 综上所述,创新身份验证技术的应用是对互联网金融业务的基础性工作,是金融稳妥创新的重要技术保障。经过实践检验的身份验证中的创新技术,是对传统身份验证方法在技术上的改进和提高,而不是对传统金融稳妥性的颠覆。新技术的应用有助于提高群众服务的便捷性,并且保证业务上更加安全、可靠。除此之外,这些创新技术的实践,还可以带动其它行业的类似业务场景,从而在全社会范围内促成更广泛的工作流程改进和社会成本节约。 参考文献: 【1】人民银行,《非银行支付机构网络支付业务管理办法》,2015年12月 【2】中国信息安全,《人脸识别新技术准确率超肉眼》,2014年7月
蚂蚁金融云是蚂蚁金服推出的针对金融行业的云计算服务,旨在将蚂蚁金服的大型分布式交易系统中间件技术以PaaS的方式提供给相应客户。在整个的PaaS产品中,蚂蚁金服通过基于Docker的CaaS层来为上层提供计算存储网络资源,以提高资源的利用率与交付速度,并用来隔离底层IaaS的不同,IaaS、CaaS 与PaaS三层相互借力,互相配合。为了进一步了解蚂蚁金融云的整个体系架构,InfoQ采访了蚂蚁金服基础技术部系统组leader吴峥涛。InfoQ:能否介绍下蚂蚁金服的金融云PaaS平台?吴峥涛:金融云PaaS是从2014年中开始研发的,目前已经承载了网商银行以及另外两个核心业务,后续会以公有云和专有云两种模式对外提供。之所以会有金融云PaaS这个项目,是因为蚂蚁这些年来在大型分布式系统领域涉及的SOA、消息通讯、水平扩展、分库切片、数据一致、监控、安全等技术方向积累了大量的中间件以及与之完整配套的监控运维研发流程体系,这一切在性能和稳定性以及扩展性上做的都不错,能够有效的支撑蚂蚁的业务发展,并应对『双11』这样的高负荷挑战。很多金融客户与伙伴都对此非常感兴趣,所以我们希望能够把这一整套的技术上云并产品化,以 PaaS的方式整体对外输出,帮助金融行业的客户使用云计算技术去IOE,帮助他们解决我们已经解决的技术问题,让他们能专注于业务逻辑。上帝的归上帝,凯撒的归凯撒。InfoQ:蚂蚁金服想把自己的中间件技术以PaaS产品的形式对外输出,这中间碰到了哪些问题?为什么会想到通过Docker这样的技术来解决? 吴峥涛:遇到的问题有很多,最主要的问题包括: 金融云PaaS是承载在阿里云IaaS上的,最初的方案是,用户部署应用的时候,根据所属技术栈,由系统解析软件包(例如sofa4依赖CloudEngine、Tengine、cronolog、JDK等等),下载安装配置并启动。这样的资源交付、应用部署周期比较长,客户体验不太好。 蚂蚁的应用架构采用的是基于服务发现、消息总线的SOA方案,模块间通过服务接口调用;服务可以是本地接口也可以是远程接口,对于调用者是解耦合的。在实际部署的时候,我们会根据业务纬度切分大量的服务模块出来,以金融云PaaS中枢为例,目前已经有几十种服务模块。这样的话,我们希望资源粒度越小越好,原有以VM为粒度的资源分配方式已经不能满足我们的需求。同时资源交付速度慢导致扩容缩容慢,影响资源利用率。 金融云PaaS如果对外输出,可能使用非阿里云的IaaS,所以需要一个中间层屏蔽多种IAAS的区别。 镜像管理比较麻烦,无法自动化,也不是白盒。 而遇到的这些问题,都可以通过Docker来解决。InfoQ:能否介绍下你们整个平台的系统架构?Docker在整个架构中扮演怎么样的位置?吴峥涛:我们在PaaS和IaaS之间插了一个AntCaaS层,这是一个基于Docker的管控平台,他的职责是: 以微容器(Docker)为载体,为用户(PaaS、SaaS)按需提供计算存储网络资源,提高资源的利用率与交付速度。 对PaaS、SaaS屏蔽IaaS实现细节。 实现容器、集群级别的标准化与可复制、可迁移。 AntCaaS提供container、app、cluster三层接口,可以把他当作一个轻量级的IaaS,区别仅仅是提供Container而不是VM,然后也提供PaaS层的接口。 一个比较有特色的功能是,通过『镜像中心+集群template+环境相关参数列表』,我们实现了集群的快速复制,目的是为了应付突发的负载高峰。InfoQ:在PaaS层面,你们是如何屏蔽底层不同IaaS的区别的?吴峥涛:目前AntCaaS可以直接运行在物理机上也可以运行在经典网络的ECS VM集群中,VPC、ECS支持还在开发过程中。在AntCaaS中,我们采用三层架构,通过创建不同pool来兼容不同的IaaS。pool包含了: 多个node(container的载体)。 ZK用以监控node和container。 scheduler 调度器,负载container的创建调度。 manager,对master提供管控的HTTP Rest接口。 registry-proxy 保证网络联通性以及cache镜像数据,加速镜像下载。 在node内起cadvisor监控container。 Docker默认的bridge/host网络模式不能满足我们的需要,根据IaaS提供的网络功能不同,我们扩展了vlan/vxlan 两种网络driver,第三者vpc driver还在开发中。 vlan模式,事先为container分配一个与node不一样的网段, vxlan模式,首先通过ovs实现跨node的私有网络,然后通过zk缓存同步vpcid、vpc ip、node ip的映射关系,极端情况下,如果一个vpc有1000个container分布在1000个node上,那么新建一个container加入这个vpc 时,需要通知所有的node。 另外在VPC内,我们提供轻量级的DNS,用于内部域名解析;轻量级的LB,用于内部的负载均衡。 下图是可扩展的容器创建流程。InfoQ:容器的安全问题是怎么解决的?吴峥涛:基于pool-node-container的三层解决方案。用户和pool是1对多的关系,所以 pool的node必然都属于同一个用户,同一个node上的container属于同一个用户。pool和pool之间根据IaaS不同采用不同的隔离方案,经典网络的ECS使用安全组隔离,vpc ecs使用vpc隔离。 InfoQ:社区中有反馈说Docker会经常无故挂掉,你们有遇到过吗?有做过深入跟进吗?吴峥涛:碰到过,我们的架构设计允许Docker Daemon和Container挂掉。使用了集团的一个Docker Patch,在Docker Daemon挂掉后,不影响container运行。出现比较多的场景是docker pull时候。InfoQ:你们是如何将基于Docker的系统与原有系统对接的?吴峥涛:为了与现有的运维流程管控SCM系统对接,帮助现有系统迁移,以及帮助开发同学转换开发模式,我们做了不少妥协方案。作为Docker fans,理想的开发模式是下面这样。 但是实际上蚂蚁目前已经有1000多个应用,几千的开发人员,很难让他们一下都切换到Docker这种以镜像为中心的研发模式上;但是如果一个团队一个团队的推广,那么耗时不可控。并且蚂蚁原有的运维、监控、SCM等系统都是以VM为纬度的,基于Docker的运维发布系统需要与原有系统对接集成难度比较大。 所以我们的第一个策略是,首先解决线上环境的Docker化部署问题,开发者的本地开发环境Docker化问题暂且不管,希望通过线上环境Docker化来吸引开发人员学习使用Docker。 接下来的问题是,谁来写Dockerfile,首先各个研发团队的人不关心是否使用Docker部署,所以不可能写Dockerfile,由 Docker团队或者运维同学负责,没有应用代码的编辑权限,同时工作量太大并且不了解应用容易出问题。所幸蚂蚁的业务应用大多数都是基于sofa3或 sofa4框架的Java应用,所以我们做了sofa3/4的基础镜像以及提供一个辅助工具,使用sofa3/4镜像启动一个container,然后使用原有的发布工具将应用的tgz包(类似war)发布到container中。这样就不需要写Dockerfile,同时原有运维系统也能把 container当作VM,无缝对接。 InfoQ:聊聊你们异地多机房的统一镜像中心解决方案?吴峥涛:关于跨机房镜像中心的解决方案要点: 将镜像数据存在OSS写三份,保证数据安全性; Registry本地不保存数据,是无状态的服务,可以水平扩展; Registry 上跑一个Nginx,提高镜像数据访问速度; 在每个pool中部署一套Nginx,开启文件缓存,对常见镜像进行预热,构建缓存。 本文转载自InfoQ 原文链接:http://www.infoq.com/cn/articles/docker-in-the-antgroup-cloud-platform/