分享嘉宾: 蒋锵、严明，平安银行大数据部门

整理出品: AICUG人工智能社区

关注本站公众号获取完整PPT

其实刚刚也讲到随着银行转型，对于数字驱动这件事情的迫切度是越来越高，就是最开始的时候可能大家对于数据怎么用，有一个业务强主导，我可能就要这一份数来帮我做一个决策，或者我就要这样的一个客群来帮我去做一个定向的运营，在这个过程中逐渐大家对数据的推荐这些词的需求越来越多以后，会发现其实去应用推荐的时候是参差不齐的能力，所以我们想这是一个背景。就是我们怎么样能打造一套相对通用的能够服务于所有业务线的推荐，怎么样去让培养客户对于理财投资的成熟度提升这样的一些内容运营，这样的一些模块里面怎么把推荐技术用进去，这是第一个背景。

第二个背景的话是我们是一个公共平台部门，我们在跟第一个业务线接触的时候，发现大家虽然对于数字化经驱动经营有一个模糊的或者框架性的概念，但在落地的时候，他们的目标或者他们的决策的方向上都还是是会有一些差异的，我们也希望通过一个相对于框架化和标准化的模块，来帮他们快速搭建统一推荐的能力。那么这个背景然后我们怎么去做它，我们是做了这样的一个设计，这个设计其实是希望是靠我们一般推荐的通用的一个结构，底层是数据，一般的推荐都用人给推内容对吧？人推内容这个内容怎么去构建？

然后在队伍经营如果面向于销售的这种场景，我可能是让我的队伍去经营哪个客户，客户身上有哪些价值线索，我怎么让他转化，这些就是一般的业务运营的动作，这些动作怎么把它知识化，怎么把它结构化，这是我们这一块业务作业的，然后往上的话是一个通用的推荐，也就是召回排序，然后可能在这个之上的一些场景化的金牌打散，我们有一个统一的技术工程引擎能够来实现不同目标大目标下以及子目标之间的协同。

我们在权重点上，我们大数据做了一件事，就是基本上有能力去把全部的触点去打通，主要分成三类的触点，一类触点就是互联网常见的就是线上的这些触点，主要包括 APP的触点里面的所有的运营内容，广告位弹窗的，然后推荐为一些列表，然后产品推荐类，然后一些消息通知类的这样的栏位。然后第二个的话就是偏向于线下的传统比较常见的也就是销售团队，我们零售的话大概1万个人左右的一线销售队伍，就是面向于理财投资的销售队伍，这个队伍比较庞大，他们承载了日常产品，产品跟客户与客户之间的沟通，他们也是个非常重要的接触渠道。还有一类就是空中的渠道，常见的就是远程的外呼，然后还有短信，微信不在APP，它可能可以相对来讲可以离线去交互的这样的一些渠道，然后这个过程中可能都有一些AI的加持，我们现在做了AI的外呼，语音外呼有可能用到的科技技术去做了一些TS转语音的这种语音外呼的能力，然后也有一个机器人的交互，我们在口袋内部有一个客户经理的交互，这是我们的全渠道，我们全渠道的下面这个图中就可以看到的是我们一些典型的应用场景，有一些瀑布流失也是偏向于互联网的瀑布流式的或者是来推荐有一些 AI客户经理中交互的一些产品推荐，有我们在动战尾随中跟场景相关的我一个消费，我可以跟他的消费上下文去产生消费相似的活动或者相似的产品的推荐。

比如说经营目标，先后顺序在不同客群之间先后顺序的切分，切分要相对来讲要逐渐地精细化，然后我就能知道我在经营一类客户的时候，我尽量是一个相对各渠道之间统一的目标。第二个是数据打通，我接触之间应该要保持数据的完整性，互通的难点在于达标的难点，因为我们现在其实已经有了所有的接触数据，但是接触数据的标签做的其实因为历史它都是为了做运营动作而已，不是为了让你去做闭环，让你去做那个机器的学习和提升，所以这个的标签化很难做。然后第二个是关于目标，目标的话我们想法是说对于渠道，把接触的优先级也接触的顺序交给渠道来决策，比如说什么我认为某一个客户他应该被销售某一支产保险产品，同时他可能也满足销售一个贷款的这样的潜质，刚刚讲的组织的目标应该让渠道清晰的知道。

然后最后的话是统一价值衡量，我们也是在摸索，因为我们在做线上广告的时候比较常见，就是我们一个APP它其实是有不同的领域的，不同的领域代表着其在我的口袋在银行里面我既可以买到理财，也可以办贷款，也可以办也可以办信用卡，频道的流量是有限的，我们现在这个平台大概是400万的日活，然后可能有1亿1亿左右的页面总累计访问量，这样的其实一级频道页流量是比较内容比较多，它是比较分散的，这样的过程中我怎么样去分配好的流量，我们就要有统一的价值衡量。我们现在的想法是一切都为一个短短期短期中期和长期的营收目标为服务。我们希望通过这个计算，我们所有发生过这个行为的，比如说我点击的物料，或者我产生了购买的客户，在短期中期和长期用统一的营收作为衡量标准，把大家之间产生的价值两张统到一元钱或者一个营收上面，最终的话我们对于所有物料实现价值的评分，然后就可以去决策，然后最后我们也预留了一些给到每个板块，他们这个渠道方有不同的目标，他可能近期就是要卖贷款，他贷款压力比较大，我们也给他在这个方面一些加权的调整，来实现我在分配流量上或者我再借再排序上面一个统一的价值衡量。

目前我们的口袋APP的话大概有4000万的一个月活，然后前期的一些算算主要是偏离线的，就前一天晚上用历史数据去做建模，然后第二天上线，这样的话它的实质性不太够。用户比如说你最近看了什么搜了什么，这些实时的一些行为数据没关到我们系统里面，原来那么这也是一块需求。第三块的话前期我们的推荐接触场景的话成本是比较高的，可能需要做一些定制化，那么在场景比较多情况下，我们需要排期，发吧对业务来说可能是不太容易接受的，这是我们当时这个背景。这是我们在去年下半年我们总结出我们一些痛点，一个是我们的流程比较长，因为银行本身它比较复杂，所以说我们做推荐的事情它其实关联方很多，那么要上线一个产品，可能关联方会有五六个，那么涉及到排期，这个流程的话导致我们的接入效率不太高。

第二块的话是数据的实时性，那么前期主要考虑到一些快速上线，所以说实时数据之外，我们是没有太多的纳入系统中去。第三块的话是我们对这种客群画像没有一个系统化的工程，前期主要是依靠每个算法自己的一些经验，他可能在其他地方做过或者来到平安银行。他用他自己已有的经验带过来，但是他的一些画像知识他可能不能形成体系，导致他的被复用可能性不太大，那么我们也想在这方面做一些努力。

这是我们的一个画像，这是我们整个推进系统的一个技术架构，主要有三块，第一左边的话是我们的一些数据，中间的话就是我们推荐以前的一个主要流程，右边是我们的应用场景。特征的话我们这边有两块特征，一些有离线的有实施的，离线的话主要是用大数据的 h平台去做一些加工。行实施的行为的话，我们是基于这种 link是bug技术去流计算，去把数据实时进行加工回复到我们系统中来，我们同时也会对这些特征进行一些预处理。

从我们推荐引擎本身来说，它跟一般主流的车间差不多，它大概是分倒回过滤，排序的话也用的是一些离线召回，用了一些协同顾虑以及举证分解这种比较常规的一些召回算法去做一些离线的分析。同时我们也提供了这种实施召回能力，类似我们去一些业务系统去获取当前热销的一些产品，然后通过去把用户在我们 APP上一些实际行为去做一些扩展，比如说你最近看过什么会点过什么，我们就会去根据你点看过一些产品进行扩展，同时也支持地理位置的一些召回。过滤层的话主要是会做一些这种包括大家一些复网的能力，同时我们会基于商品的一些状态进行过滤，确保那种已经卖完了。或者说已经不属于出色状态的，那个产品不要推给我们的用户。

再简单介绍特征中心，是希望把我们所有算法工程师把大部分时间是花在这种特征体系上，我们希望把这部分时间省下来，让他去抓住去做优化，所以说我们研发的叫特殊中心的产品，它主要解决几个问题，一个是我们特征的一些使用情况，做到闭环，就是说哪些特征是比较重要的，哪些特征可能基于场景的角度出发，说这个产品可能就这些事都是比较有效的，不需要算法工程师过来之后重新去摸索一遍，一些效果数据把它沉淀在我们的系统里面去。同时我们对特征的一些字段进行管理，因为之前可能不同算法有不同的加工逻辑，导致可能是一个数据，但是有在这系统有不同的，名字我们希望说通过它的宣扬分析，能把它相同的一些特征把它识别出来，一个是结合我们存储，同时的话让我们特征的定义更加聚焦。

另外的话我们有这个平台之后，我们可能有专门的，人力去做这种特征的一些维护，确保我们特征它的上游可能发生变化的情况下，我的下游的数据不会受影响。然后在银行这边还是在其他公司也一样，就是数据的一个敏感性，我们特征不可避免的用到用户的一些比较敏感数据，那么我们希望通过一些透明手段或编码手段，在不影响模型什么情况下我去做脱敏，反正这个数据对算法来说能用，但是他又看不到真正的一个值，一个这样的话满足我们安全的一个需求。我们的系统目标第一个就是刚才讲的我们的一个安全性数据，确保它是安全可靠的使用，并且不会发生一切的让算法工程师从头到尾所用的数据都在我们系统里面，不会脱离我这个系统。稳定，就是我们会去追踪我们特征一些学员，确保上游的数据出现变化时，下游不会说这个值可能是上游表一块，我们下游等一下空值。

高效的话是我们通过互动的方式去做到这个特征的一些费用，节省我们算法工程师的工作是一些工作量。这东西的话上面说我们已经完成了一个比较支持，目前的话我们大概沉淀了1万多个特征供所有算法工程师去使用，他不需要重新从头再去建。然后第三点他是实现了一些特征共享，当然我们也支持每个Java工程师加工一些私有的特征，可能他自己的私有财产方，方不方便分享的话，我们也是支持的，但我们是鼓励他去做分享，然后后面我们可能想做一些特色模拟，就是在一些产品像我们想用特殊性的一些数据去模拟出一个典型客户，那么我在一些场景还没上线的时候，我又不是典型用户去做一些模拟，这样它的效果怎么样？

还有一块是特征治理，就是随着我们特征速度数量慢慢变多的话，就是它的一些资料可能需要有监控手段确保说我的特征是有效的，能用的。特征衍生的话是我们老百姓实际上我们将来有达到千亿级的一个特色，目前我们特征其实1万个还是比较少的，我们希望通过外部的一些工具去做一些衍生，慢慢地把我们真的丰富起来，让算法有更多的数据味道，它的模型里面去。我们在3.0升级过程中，我们是增加一个网关，把所有的推进流量都搜索到这里面去，让这一个出口去对接所谓的推荐。有几个好处，一个是我们的标准化接入，确保为接口是同一个所有的产品都是一个结果。然后同时因为一旦我们搜索流量之后，我们可能在流量入口可能做一些其他事情，我可以插入一些广告这种。另外的话我们在网关层做了一些数据收集的工作，就是我们曝光点击一些政府反馈用户是上报这个系统中来。第三个的话是做一些监控，确保我们的推荐是有异常的第一时间知道，在业务报问题之前，我们就把它发现把它修复掉。

另外的话我们也在想，是因为现在如果说提前为每个用户去生成，比如500或1000个特征，其实对我们存储要求挺高的，我们在想可能后面会去探索一些实时的召回，用双导模型去做在线的召回，而不是说提前算好很多都放在，因为有些用户他可能不来，但我要放那里对我们存储是一个比较大的指号，这是召回这块一个优化。我们这边的简单提下有我们的一些召回的一些方法，首先我们有一些规则可能是偏于有一些，规则是业务根据他业务经验提出的规则，还有一些是根据用户的地理位置以及一些我们的热销产品去做召回。第二块的话是我们的一些算法召回，那算法的话基于他自己对一些经典算法做我们的离线的召回，实时到货的这块主要是去用户行为去做一些相似的或者搜索过的东西，去做个类似物品的一个召回。

我们有些产品还是需要就把多品类，比如说商品和资讯，还有一些理财产品进行一个混推。过滤的话这块主要是根据一些副反馈以及一些产品包用业务可以去定义一些可能是不太好卖的产品把它排除掉，或者类似这样一个顾虑手段。我们通过这种方式的话去保证我们最终结果一个多样性。实施召回这块的话，主要是列一下我们在实践中用到的一些实施召回的手段，这里主要是依赖我们用户在APP的一个行为，同时还有是用户的一些实时政府反馈。当然我们也结合用户的一些业务系统的一些数据，比如他提供一个接口告诉我说当前这个热销的是什么，我们会把东西拿到我们的账户里面去，然后我们还接用户的一些搜索行为，以及在我们APP里面一些断点行为去做到一个插入，还有是我们的一些商品状态的变化，我们也会把它同步到我们的一个计算引擎去影响到我们实时照会员。

冷启动简单说一下我们用的一些用户冷启动和商品冷启动，用�