知识的诅咒

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

管理,都和人相关,所以很多时候都是在讲心理学, 无论是更加了解自己, 还是更加了解别人。 同时发现一个比较有意思的现象, 就是中式心理学更关注自己的内心,中式心理学更关注了解自己,提升自己的修养;而西式心理学似乎更功利一些, 不仅探究内心,更在乎如何去影响他人。

今天听了一场讲座,里面提到一个比较有意思的概念,叫知识的诅咒。今天就跟大家聊聊这个概念。

先说一下什么是知识的诅咒,指的是一旦当你掌握某种知识,你就会认为这个事很容易,但是这反过来就会让你去教授或者讲解该内容的时候变得很困难,别人想听懂你教授知识的难度,比你想象中,听众掌握该知识的难度要高得多。

是不是没有理解以上我所说的话?这也是一个知识的诅咒:)

举个形象的例子,网上经常流传着一些段子,就是家长在鸡娃的时候都很崩溃,突然就觉得自己家的娃变傻了,那么简单的问题都不会?

或者我们在公司跟同事沟通的时候,也老觉得对方为什么听不懂我们说的内容,尽管觉得我们说的很清楚,内容也很简单。

这就是知识诅咒的例子:一旦我们掌握了某个知识,我们就觉得这个知识无比简单,但是我们就永远也无法完全理解没有掌握该知识的人的真实情况,就会导致我们认为:掌握该知识的难度和具体学习的人觉得的难度的偏差非常之大。

所以以后在工作当中,不要轻易的去质疑别人为什么听不懂。大家能在同样一个公司工作,教育背景都很优秀,智商都很高,都是通过高考这种千挑万选,独木桥上留下的人选,最大的可能就是你现在正在经历知识的诅咒。这也是一种非常普遍的认识偏差,或者其实也是人天生的一种偏见。一定要客观的看待他,并且尽量的减少它的影响。

所以你好好观察一下,你身边是不是经常会有这样的人:他的智商似乎没有你高,不过他们和别人沟通非常频繁,就会导致他们推进事情更顺畅以及产出更多,更能得到团队的认可。很多时候,这也是他们尽量避免知识诅咒所带来的缺陷,这也是大家在他们身上值得学习的优点。

所以很多时候我们需要尽量的去换位思考,看我们的沟通对象到底是什么样的人?他是不是已经具有了我们足够多的沟通背景知识?沟通的双方是不是已经真的在同样的一个频道上?如何补齐大家的认知偏差?

这也是我最近几年的一个比较大的感悟:同样一个事儿,你站在不同的角度看,会得到完全不一样的答案,甚至是截然相反的答案,但他们都是对的,只是所看的角度和立场不一样罢了。

比如你可以想一想,‘996福报’是不是对? 不一样的人会有完全不一样的答案,例如公司的角度,公司需要的是拼搏精神,而且很多事都是拼刺刀拼出来的,并且冲在最前边的人大概率会有更多的回报。。。。那就应该996!
当然,如果你说我就是要家庭工作平衡,那是不是就完全不一样?
我是经历过创业型公司的,算是近距离看过创业型公司的老板从白手起家到市值做得非常高,财务自由的过程。这种公司的老板非常之拼,比如经常半夜12点发一个微信过来,说有一个特别好的idea想讨论一下,几天之内就需要验证模式是否OK;或者他们基本上在电梯里,在车上都在讨论问题,都在开会,都在和合作伙伴谈生意。

记得之前有一次,和创业公司的老板连线讨论问题,他在国外是当地的半夜,他一边吃刚泡的白天在外边买的泡面,一边和我们开会,而且说没想到国外桶装泡面当里没有叉子,所以就拿卫生间的梳子当叉子,吃着泡面,和我们讨论问题。 又有多少人能够做到这么拼?

别人所吃的苦是我们很难想象的,当然,别人所拥有的财富也是我们所难想象的。

沟通视窗4象限

对于我们在沟通方面的认知,可以使用沟通视窗为4个象限来描述


图:沟通视窗4象限

公开象限
每个人都有自己的公开象限,就是别人知道自己到底是一个什么样的人。这个象限的大小,我们是可以控制的,不能说它是越大越好,还是越小越好。这个象限的大小有他的作用,也有它的弊端。

一般情况下,公众人物的这个象限是比较大的,这也会为他们带来好处,例如,他们可以塑造自己正面,积极,阳光的形象,为他们带来名声,之后就会产生相应的利益。

我们看市面上有各种各样的成功学,或者说各种CEO老板的传记,其实他们都在放大自己的公开象限,而且专挑好的说,这些文章或者书籍,也许你在看的时候不知不觉就这些人带来流量作为他们变现的工具,但从你的角度,你可能还以为自己学到了别人成功的经验。是不是很搞笑的一件事?

当然,公开象限比较大,也会带来它的弊端,例如你的隐私会变少,或者会不会你苦心经营或者伪装的人设在瞬间崩塌? 这样的例子其实非常多,比如打工皇帝唐骏,或者各种崩塌的明星。

隐私象限
隐私象限,这个象限和公开象限是相对的,这个象限具体对每个人的大小是可以控制的,到底要公开多少,每个人都会有自己的选择。有些人就会让隐私上线比较大这样这个人就会显得比较低调,这样的人一般不容易出事儿,但是因为别人对你不太了解,所以跟你就会产生距离感。

盲点象限
这个上线也是很大的每个人都有,而且很多时候处理不好是很致命的.一般的人有网点上线可能更多的是因为自己的认知偏差,很多绝顶聪明,并且又有非常多阅历的人,也经常会陷入盲点象限, 特别是当他们位高权重掌握各种利益分配权利的时候。

举个例子,在袁世凯的晚期,他所有的手下都在骗他,甚至手下还专门出了一份供袁世凯看的报纸,全北京这份报纸就只给袁世凯看,让他以为他称帝是民心所向。。多么恐怖的一件事。

但比较搞笑的是,我之前听百度的同事也提到,之前百度信息流有一个专门供李彦宏看的版本,老板看到的内容跟其他用户看到的是不一样的。。。历史是何等相似且在不断重复,真是细思极恐。

所以不管是谁,忠言逆耳,兼听则明。人性都是喜欢听好话,但当听到别人说自己不好的一方面时,那最好先冷静下来想一想,是不是别人正在说自己的盲点象限。

潜能象限
这是一个非常大的象限,每个人的潜能象限都特别大,而且我们每个人一生都致力于开发潜能象限。记得之前听到一种说法,好像说是字节,张一鸣说的:姜子牙80多岁才辅助周武王平定天下那他之前在干什么呢?主要就在读书和锻炼身体,我们可以认为他就是在不断的开发潜能上限。

而对于我们这些寻常人来说,确实,随着年龄的增长,身体的机能和精力是在下降的,但是如果保持一个年轻的心态,不断学习,不断探索,其实我们永远能够取得超乎我们想象的成绩。

在阿里,大家不断的在提升,大家的压力也非常大,环境也逼着大家不断的去挑战自己,也经常说一句土话,今天最好的表现是明天最低的要求,其实我觉得背后也是要把大家的潜能逼出来。

特别是很多问题,我们需要放在时间的维度去考虑。例如我到阿里之后,其实我从来没有去过健身房,也没有刻意的锻炼,但我觉得我的身体素质是是在变好的,随便爬个十多层的楼梯,可以小跑的速度上去,原因很简单,每天坚持做50个俯卧撑,几分钟就搞定。 简单却并不容易,坚持下来, 会发现很不一样。

所以大家一定要保持一个年轻的心态,就像小孩一样的求知欲。

【管理】产品与技术的相爱相杀

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

引言

各位研发同学,大家有没有这样一种感觉:就是在工作中, 你经常会有如下感叹:

  1. 为什么我们的产品需求如此多? 就不能想清楚再做吗?
  2. 为什么我们的产品居然给算法提了个效果翻5倍这样愚蠢而不可能完成的增长要求
  3. 产品抱个脑袋想出一个需求,研发就要吭哧吭哧搞半天,那产品平常都在搞啥?


总体来说研发同学有这样的想法是很常见的, 也是很正常的。 而且以我的经验,无论是大厂,初创公司,或者中型公司,都会存在这样的情况,无论是以工程师文化著称的百度,还是以强势业务导向的阿里, 或者其他一些小公司都不会例外。

下边我就来分析下研发为啥会有这样的想法, 以及站在产品的角度, 又会看到那些不一样的东西。

公司里最大的理,就是对业务的发展有利

在这里先抛一个基本原则, 无论你的角色是产品还是研发, 无论你看你对应的产品, 或者技术再怎么不顺眼, 这些都是有主观立场有屁股的看法, 而且是信息不完全的看法;每个人都会以自己的角度,自己的经验去看问题。
这样就会出现我经常和下属讲的:二元世界理论:同样一个事,从不同的角度看,会得到不同的结论,并且都是对的。

公司里边最大的理,就是要对业务的发展有利。其他的诸如研发觉得产品是不是需求提太多, 是不是需求不合理, 是不是在压研发的排期, 甚至是不是在找事儿, 这些都是有屁股, 有偏见的主观的看法,不是理

产品与技术的相爱相杀

前两年听淘宝一个研发负责人分享,末了一个听众问了个问题,大抵是问研发在业务需求非常多的时候,如何平衡技术长期建设和短期业务需求的关系。 当时那个研发负责人提到,‘产品和技术的关系,是相爱相杀的关系’,产品和技术都会有自己想做的, 自己认为重要的的事, 那如何去决定什么事重要, 优先级如何, 其实就会涉及到优先级的PK, 或者是较多的平衡。

产品与技术的目标一致吗?

可能这里有研发的小伙伴会问: 不是一直说产品和研发的目标是一致的吗? 那还需要平衡什么?
但你认真想想,产品和技术, 目标真的一致吗?
我个人的观点是: 产品和技术的目标, 是不一致的, 或者说是不完全一致的。否则从公司组织机制上,就不用专门分出来产品和技术两个工种了 。

那为什么说是不完全一致的?简单想想:产品会考虑稳定性吗? 会考虑实现如何具有可扩展性吗? 似乎不太会吧。
但技术需要考虑这些。 虽然有些技术小伙伴接需求接麻木了, 需求挡又挡不回去, 就干脆需求来了后就糙快猛把需求怼上去,产品说啥就是啥吧, 但最后系统越来越复杂,越来越慢,直到某天迭代不动了, 影响到了业务发展, 这是谁的问题? 其实还是技术的问题!

所以,大家的业务目标是一致的,但当业务需求提过来的时候,技术同学有必要,也有义务从技术的角度,审视需求的合理性,并需要结合长短期的技术发展,确定合理的方案
而且很多时候,以我的经验,技术的长短期方案的权衡,以及必要的技术投入, 其实都是可以和产品同学一起聊, 一起沟通的。 至少我打过交道的产品同学, 虽然他们更多从产品的视角来看问题,但你讲你的技术长期考虑,长短期如何权衡和他们沟通后, 都还是可以得到理解或者支持的。 如果确实有些需求是有很大的业务压力,必须要糙快猛地搞,大家至少在信息上是可以拉平的。 当然, 如果资源上实在无法拉齐,至少信息拉齐了,可以上升到老板来决策。 前提是研发需要有自己的判断。

产品业务同学的压力

很多时候技术同学觉得自己比较辛苦, 压力比较大,还被产品同学PUSH得不行,甚至心里委屈有气, 其实在和产品充分沟通后,换位思考一下, 其实产品,业务的压力更大。
为什么更大? 业务,包括产品都是需要背业务指标的,收入一年翻5倍, 核心指标翻3倍。。。 可能都是老板直接就拍下来了。
技术同学可能还会根据各种数据,指标估一个合理的可能的增长,但业务一般不是这样,都是先拍KPI,再想达成的手段,这样在KPI拆解的过程中, 就会导致很多理智的逻辑性很强的研发同学觉得产品对技术的要求高的可笑,觉得产品同学不靠谱,但其实这正是产品同学的压力所在。
很多问题其实就是个屁股问题, 换个角度看, 就能理解了。

开头的3个问题

对于开始的3个问题,读了上文后,应该就有答案了:

  1. 为什么我们的产品需求如此多? 就不能想清楚再做吗?
    答:很难,没有人能预知未来,换你,也只能快速地去试,只能做到Fail Fast。 因为从‘肯尼芬框架’的角度来看,产品所处的象限是‘复杂’的象限, 技术所处的角度为‘繁杂’ 甚至是‘简单’的象限。
  2. 为什么我们的产品居然给算法提了个效果翻5倍这样愚蠢而不可能完成的增长要求
    答:因为老板拍目标的时候,就是按照更高的要求拍下来的,产品也没地方说理(且不说很多时候高目标也能够实现)
  3. 产品抱个脑袋想出一个需求,研发就要吭哧吭哧搞半天,那产品平常都在搞啥?
    答:产品涉及各种上下游拉通,好好想想就知道了, 其实真的很操心


图:肯尼芬框架简图,产品业务一般处于‘复杂’区间,技术处于‘繁杂’或‘清晰’区间

但有一点是肯定的,产品在整个价值链路上处于中枢的角色,对全局的信息更加了解,而技术则处在底层,信息比较局部,仅是‘重要的环节’, 所以遇到问题,多和产品沟通,多了解下更加全局的信息,这样对整个业务的了解会更加全面和透彻。 在整个过程中不要有情绪,和产品同学的合作不要有偏见,这些都是主观的。 一定要记住:公司里边最大的理,就是要对业务的发展有利

P.S. 在公司里,一定不要因为不爽而和产品对抗,考虑问题多考虑上边提到的公司最大的。另外产品同学更接近业务,是需要对公司发展,或者说挣钱负责的, 技术固然重要,但更多是公司运作的单一环节。 二者如果竞争,这就像一个6维空间的文明, 和3维空间的文明对抗一样, 维度不一样,结果可想而知。

阿里工业级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