阿里工业级LBS DMP设计思路

先打个广告: 团队长期招p6~p9数据,工程,算法; 业务发展快。 感兴趣的同学可直接关注以下公众号获取岗位信息:

前言

通过阅读本文, 可以有两方面的收获:

  1. 我们针对LBS 场景的DMP建设, 定义了新的基于底层人地关系原子能力的范式,避免了传统DMP用户数据生产过程中, 标签建设代价过大,无法迅速扩展的缺陷
  2. 展示了分层DMP建设的框架

个人隐私相关的行业背景

最近国家密集出台史无前例的互联网个人隐私管控的法律,以及算法管控备案的条纹, 例如:《互联网个人信息保护法》中明确对互联网APP个人信息收集,利用做了非常严格的限制。

对于各种设备级ID的使用, 例如原来imei, idfa, androidid等都有较为严格的限定,对于类似于轨迹,定位数据也做了较为严格限定。

从系统分发的角度, 《互联网信息服务推荐算法管理规定》也对算法的分发提出了较多要求, 对于个性化, 大数据杀熟等国家也在加强备案和管控。

在这样的行业背景下, 互联网的大数据使用会逐渐趋于规范和精细化。 这里需要明确的是, 国家不是限定大数据的发展,而是限定原有不规范,粗放式的数据使用。

例如早些年我的确听说有些公司对外提供DMP服务,按照请求次数收费,各种个人隐私数据不管应用方的类似随便使用, 这样的确是很恐怖的情况。 因为现在每个人在手机上产生的数据太丰富: 包括家庭住址,信息获取偏好, 购物, 所在位置等。

挑战

在这样的大背景下, 在构建工业级的LBS DMP体系的时候, 就会面临两大类挑战:

  1. 传统的技术挑战, 更多是技术问题, 包括如何更高效,实时地处理海量数据; 如何从数据中,对业务的LBS 能力进行原子能力的抽象; 基于原子能力如何对数据资产沉淀, 以及如何更通用化, 更高效地对外提供数据能力的支持。 每一个点均能衍生出较多非常多的技术挑战点需要攻克。
  2. 新的隐私数据安全, 包括哪些隐私数据我们能够收集, 哪些能够使用, 应该如何使用, 提升个性化效果以及触及个人隐私的边界在什么地方,这些都需要在数据使用,系统设计实现的时候充分考虑。 毕竟我们在社会主义的红旗下,需要做遵纪守法的产品研发,打造合法的系统。

同时,在大数据时代,我们也不可能就因为个人隐私风险而放弃对数据的建设, 毕竟互联网快速发展了20多年,基于数据算法的个性化被证明是提升系统效果的利器, 过去工业界,学术界的算法得核心也是数据驱动的个性化精准分发, 同时以后随着数字化的发展, 更多IOT设备的加入导致更多的信息需要处理都需要我们有更加强大的数据处理能力。

所以各个公司, 特别是阿里,腾讯,字节等大厂, 更是会在这一块工作上持续投入。 都会构建自己工业级的LBS DMP,以便在各种搜广推的分发应用中,提升分发的效率。

下边就为大家介绍我们LBS DMP建设的思路。

设计


图:LBS DMP架构分层图

工程实现

从具体设计实现的角度,高德的LBS DMP从工程的角度和业界是比较类似的,从底层数据到上层应用,主要分成以下四层:

  1. 底层原始数据数仓,该层主要包括原始的数据收集,数仓ETL建设,以及对应的实时计算。具体的数据包括超级APP端内的搜点规划导航等LBS数据和用户行为数据的处理,以及高德开放平台数据。这两类数据一个最大的区别就是APP端内数据可以对应到具体的用户,但开放平台的一部分数据,我们是对应不到具体的用户的,拿不到体用户ID的数据,这些数据可以用来做热力相关的应用。具体实现层面,该层我们会基于ODPS和Blink来进行数据处理。
  2. 第二层是我们的人地关系算法层,该层更多的是基于我们的原始数据做进一步的深加工,包括对应的数据挖掘以及实时的算法处理。该层的算法挖掘质量会决定最终DMP效果。在实现层面,我们会用到非常多的深度学习,以及推荐类似的算法,所以也需要算法架构的支持,这次我们就基于AI OS去打造我们的数据挖掘和匹配逻辑算法。但是我们会给我们的应用场景去抽象,我们极少的原子能力,不求多,但求精。
  3. 第三层是我们的数据资产沉淀层,我们需要基于第二层打造出来的核心原子能力,进行灵活的拼装,组成上层应用,包括实时或离线的特征和标签,这些特征和标签既有表征用户长期兴趣特点的类型,又有实时用户的状态,行为的类型,例如,用户长期的类别偏好,兴趣偏好,这些都是用户长期的数据积累下来的,并且是在一定时间之内,不太会改变的用户的固有属性,这种就是长期的兴趣标签数据,另外,类型是跟永辉相关的事实,实的会很快改变的,需要快速补充的类型,例如,当前用户的需求是不是在饭店需要吃饭?是不是在外地需要订酒店?甚至细化到最近30分钟是不是有酒店需求这样的动态标签,这些都是实时类型。 从我的角度,我们对标签的定义进行了扩展:这些都是标签,只是长期兴趣标签总体来说没有时效性,相对稳定而短期实时标签具有动态性和时效性。
  4. 第四层就是服务层,例如,以什么样的方式对外提供数据服务,构建什么样的中台,什么样的通用的数据方式去提供通用的数据解决方案。这层我们会基于阿里的 AIOS,并且配合我们的数据管理平台,对外提供通用化的数据伏。

算法

从算法的角度,最重要的就是我们如何去抽象我们的LBS场景问题,将众多的数据以及对应的应用抽象为可数的几个核心原子能力

原子能力
这里先解释一下什么是原子能力:原子能力就是基于最底层的抽象,不能再分割的能力,而上层的更复杂的业务能力,都是由底层的可数的原子能力拼装组合并演绎而出。

之前在听美团的干嘉伟的一个分享的时,他提到所有的问题都可以进行拆解,再打碎为原子能力后重构,而对LBS场景所有的问题都可以根据时间,空间去进行拆解,所以我们在这样的拆解框架之下,只要我们的原子能力从时间和空间的角度分成点线面(空间)*过去现在未来(时间)的模式:


图:LBS 时空原子能力拆解

我们在建设上层特征及标签的时候,不再遵循传统的方式对标签进行一对一的深加工定制,因为这样是有一个扩展性的限制的,扩展性标签的代价是线性的,当标签非常多的时候,代价是不可承受的。不可能无限的扩展。

例如,在之前的系统中,我们建设了400多个标签,但之后就无法再高效准确的维护对应标签的数据质量,所以后来我们转变思路:所有标签都是基于我们的原则能力,在上层,进行组合加工得到最终的标签,底层的原则能力会持续地不断深化,

对于原子能力,我们在单点上进行深化建设,底层的原子能力,我们使用了非常多的深度学习及图关系的算法,讲原子能力做的足够准确,相反上层的组合做的足够简单,并且可解释,当然,底层的原则能力都需要配合debug分析平台来提升数据质量。

这一部分其实是这个算法的核心,因为算法会涉及到比较多和业务相关的数据能力,数据算法能力,所以此处主要就说一下思路更多的时间此处就不展开了。

这里也有一个比较有意思的现象,就是无论线上的搜广推还是离线的LBS标签建设,在实现的时候都是使用相同的思路。

例如,我们在线上搜光腿检索轮实现的时候,经常会进行召回排序机制将各个环节分开进行;比较有意思的是,在离线进行数据处理标签建设的时候,也会使用类似的思路,都是先招呼一个大集合,然后再去做排序,最后再进行挑选。像我们在识别一个用户,他的家庭住址的时候,也会先挑出来这个用户候选的家庭住址,然后再去做打分排序,最后再选TOP N。

或者在进行路线规划的时候,也是先选择一部分的候选路线,再进行排序。整个过程从框架思路上没有本质区别。所以这应该也是搞互联网技术的人比较倾向于招搜广推经验丰富的候选人,因为搜广推比较有经验的话,这些技术迁移到其他的领域也会比较方便。

从本质上来说,这些操作都是信息处理过程,都是user和item的匹配,这可能是这些技术比较相近最本质的原因。

成果

和公司相关的业务此处就不再展开。此处人地关系的通用原子能力,我们也发表了对应的论文,会在后续的文章中介绍。具体参见《learning the continuous context-aware temporal knowledge graph representation for user and poi understanding》

Reference

  • Learning the Continuous Context-aware Temporal Knowledge Graph Representation for User and POI Understanding
  • 阿里巴巴 AIOS

在高德吃喝玩乐!LBS信息的AI技术应用

还是先插个招聘信息: 急招推荐,搜索,语音算法,数据挖掘,工程人才,阿里P5~P9,欢迎推荐和自荐,微信扫码关注以下二维码了解详细信息

以下才是正文。。。。

从毕业步入职场到现在10年多的时间,就一直在搞两个技术领域:搜推广信息分发以及LBS。

搜推广不用说,近十年一直都是热门的领域,另一个是LBS的技术,可以说也是深入到我们生活的方方面面。过去既做LBS的信息分发,也做底层的实时路况,ETA以及RP算路,甚至更底层的地图匹配(或者叫抓路,绑路,map matching),目前,更多在做人地关系大数据,以及基于LBS的搜推广。相当于将两个领域结合到了一起。

更详细的LBS相关内容可参见:
GITC演讲-滴滴路况感知AI及应用
[LBS]地图Map-Matching流行算法及应用
[LBS]工业界ETA应用及滴滴WDR技术

《在高德如何吃喝玩乐!LBS信息分发的AI技术应用》就是团队的工作在高德技术开放日进行的介绍,感兴趣的同学可以在抖音,B站等平台观看交流。 具体B站的链接视频,参见‘阅读原文’

对于地图平台,无论是高德地图还是百度地图,腾讯地图,现阶段心智最强的功能还是出行。而在整个出行的用户交互过程当中,用户首先需要进行定位,确定自己所在的位置,然后进行POI的搜索,确定要去的目的地,之后就是怎么去的问题?包括路线规划导航ETA等相关技术。

随着地图平台的定位由出行工具逐渐转成吃喝玩乐相关的LBS本地生活平台,信息分发的范畴也在扩展:从原有的POI搜索,展到了交易的分发以及广告的分发。

同时,这个过程当中需要有非常多的内容的理解,包括文本,语音以及视频内容的建设。具体参见:ID+图像特征联合训练CTR模型

同时,分发的手段也有更多的扩展,由原来的搜索,扩展到推荐以及语音的更多的交互方式。包括搜前,搜中,搜后,语音主动提示等多种交互方式,和用户进行信息的交互。(完整的工业级搜索+推荐 用户交互机制实现参见:关键词推荐工具中的用户引导机制

同时,分发的形态,也由原来的单纯的POI list,扩展到视频,聚合榜单的更加丰富的模式。

对应的工作也包括最底层的数据建设,上层的引擎平台的建设,通用算法策略的建设,以及业务的定制。都是非常复杂的过程。

在这个过程当中,也会用到非常多机器学习相关的算法模型,当然,我们要时刻意识到,机器学习模型只是整个业务逻辑很小的一部分,虽然它起着无可替代的重要作用。

LBS的搜推广和传统的信息分发最大的区别,就是他会有很强的空间,时间的划分属性。

在LBS场景,每一个区域,或者每一个POI,都可以看成他是一个个的局域网,这些局域网之间其实是没有非常强的关系的,例如一个云南的用户,可能从来也不会去一个天津的饭馆吃饭,因为地域天然将这两个要素隔离开。 这和淘宝的信息分发是有本质的区别的,在淘宝上,一个云南的用户和一个天津的用户可能都会买同样一个商家的,同样一个商品,而且几乎代价是没有区别的。

因为地域,或者距离的差别,就会导致LBS的信息分发和传统的信息分发有本质的区别,这样就衍生出非常多的LBS信息分发独特的技术。

例如POI的别名挖掘,如何挖掘同一个地点的不同的别名。 以及反过来如何挖掘不同地点,有相同名称的POI,都是特有的结合LBS空间挖掘的技术。

同时,我们会依赖于用户的搜索,点击导航路线规划以及位置信息,去使用定制的序列模型挖掘用户的行为序列信息,去做更准确的用户个性化定向。

在地图场景,需要主动给用户展示信息的入口/场景非常多,而且不同的入口有不同的产品形态和定位,如果对每一个入口都定制一个推荐模型,那维护的成本是非常高的;同时,不同入口的信息无法共享,所以我们也是用了多任务的模型,对不同入口的推荐算法进行统一的建模。(具体ctr预估参见:推荐系统,变现系统CTR&CVR预估算法演进-模型

而且在地图场景,我们使用了丰富的LBS数据,却对用户的时间,空间,行为进行预测,例如,用户接下来会去的地点,区域和城市,并且取得了显著的效果。

这个领域的工作非常多,也非常有意思,而且LBS本地生活是非常重要,非常有前途的一个领域,也是目前各个大公司重兵投入的兵家必争之地。如果大家感兴趣,请联系我进行高德岗位的内推。