博客

使用impurity选择树模型拆分节点

在近期的项目中经常会使用到连续值模型以提升模型效果。 例如在项目初期, 训练数据准备OK后,就会使用原有的LR模型初步训练model看实际的效果, 同时因为连续值模型, 特别是树类模型已经在其他项目中应用并取得较好的效果, 所以我们也会将离散特征进行变换处理后, 使用GBDT, RF看下实际效果。
虽然GBDT, RF都有现成的model训练环境,直接用就可以,在项目过程中还是顺便复习了一下与树类模型相关的impurity度量标准;就像侯捷在《STL源码剖析》中说的,开飞机的人不一定需要了解飞机的原理,但参观飞机制造厂也是一种乐趣。
常用的使用impurity选择树模型拆分节点的度量有以下几类,他们都来自于信息论:
  1. Information Gain
  2. Gain Ratio
  3. Gini Index
以上三种根据impurity进行拆分的度量方式各有优缺点, 一下具体介绍
Information Gain
首先要定义概念熵(entropy)可以理解为定义一个分布的信息量, 具体定义如下:
其中D为数据集合, pi为第i类在数据中出现的概率。之所以使用以2为底的对数, 是因为我们默认使用bit进行编码。而该处的info/entropy即描述分布不纯的程度。 而我们可以将树模型看成是对接点进行分裂, 之后根据拆分条件节点的建立使整棵树的叶子节点尽快达到较纯的状态。
假设现在有A,B,C作为拆分feature的候选,且假设我们选择使用featureA进行拆分, 则拆分后的信息为:
其中A为选择的feature,Dj为feature A的值为j的集合,而Information Gain,即表示在原分布上,确定待拆分的feature A 后, 所带来的信息增益(减少的信息量), 拆分时使用贪心算法, 信息减少量越多越好。故:
每次拆分时,贪心地选择Gain最大的feature A进行拆分即可。
最经典的Decision Tree算法ID3中即使用Information Gain作为节点拆分的标准。ID3算法具体描述参见:http://link.springer.com/article/10.1023/A:1022643204877
Gain Ratio
Information Gain在节点拆分时是有倾向的, 倾向于拆分属性值较多的feature,一个极端的例子,假设feature是具体的ID值,即每条instance的ID值都唯一,则对该feature进行一次拆分后,则每个节点都达到纯的状态,Information Gain值最大。为了解决该问题,在ID3的升级版Decision Tree中引入另外的拆分标准,Gain Ratio。
定义:
因为某feature的属性值越多, SplitInfo就会越大,故可以使用SplitInfo在一定程度上消除Information Gain倾向于多属性feature的偏好。 具体Gain Ratio如下:
在此:属性值越多Gain越大,但SplitInfo也会越大,这样就中合了Information Gain带来的偏向。
P.S. 做策略算法中,类似的操作都是互通的,例如在推荐引擎中,用户打分可能偏好不一样,有些习惯打高分,有些习惯打低分,则我们可以使用打分的均值去中和这种偏差;而有些人打分分值比较集中,有些人则分布比较广泛,则我们可以使用z-score,即处于标准差去一定程度上消除这种分布。
Gini Index
Gini Index在CART(Classify and Regression Tree)中使用,定义:
其中D为数据集, pi为类Ci在D中出现的概率, 可以直接使用|Dci|/|D|预估。
假设我们在feature A上进行拆分, 并且是进行二分类拆分,拆分得到D1,D2数据集
则拆分后的Gini Index如上。
同样, 我们使用Gini稀疏的减少量选择拆分的feature。
这里需要注意,CART中仅进行二分拆分,如果A为多属性, 则需要转化为二分类拆分。
细心的同学可能会发现,除了gini和entropy的定义不一样外,其余的计算Gain的方式都是相似的
reference:
induction to decision tree,  J,R,Quinlan
Data Ming: Concepts and Techniques
 也可关注微博: weibo.com/dustinsea
或是直接访问: http://semocean.com

经典聚类算法及在互联网的应用

此处并不会列举每一种聚类(Clustering)算法,因为学术界Clustering算法如果真要细分,还真有很多变种。此处只会介绍几种在我近几年互联网工作生涯中实际碰到的具体问题, 以及如何使用Clustering算法解决这些问题。
一般来说,我们可以将Clustering认为是将出现的数据进行Data Segmentation,也就是经常说的哲理: 物以类聚。 从机器学习的观点来看, Clustering算是Unsupervised Learning,或者叫做Learning by Observation,根据观察到的情况进行Clustering。 因为形成簇的数据都被聚到一起,所以Clustering 方法也可以用来发现噪音或是异常点。
Clustering 算法大致可以分为以下几类(参见Data Mining Concepts and Techniques):
  1. Partitioning Methods:这是一类经典的,最简单的聚类方式,就是直接按照类内的点距离最近,类间距离足够远的原则进行数据Clustering。该类方法比较经典的方法有K-Means 和K-Medoids。下文中会以广告分段问题来具体介绍K-Means的实现(K-Medoids类似)
  2. Hierachical Methods:层次Clustering算法,又大致分为bottom-up和top-down两种思路,bottom-up为自底向上,逐渐合并离得比较近的类以形成更大的类,top-down为一种divisive的思路,逐渐对离得比较远的类进行分裂。下文中会以如何合并搜索引擎中的同意,近义词词形成簇的的方式具体介绍bottom-up hierachical methods。
  3. Density-based Methods:以上两种方法基本上都是在高维空间中将数据聚成球形的多个类的方法,却不能处理非球形的聚类,Density-based Methods就是解决非球形数据的聚类方法。
  4. Model-based Methods:对数据进行建模,之后使用观察到的数据预估模型参数,比较经典的使用EM方法,先假设数据服从某种分布(例如k个高斯分布),并且这k个高斯分布由一系列隐随机变量决定。之后在E步预估这些隐随机变量,而在M步固定这些隐随机变量后,使用最大似然估计迭代得到最优参数。
文章以下内容将介绍3种聚类方法解决3个问题:
  1. 使用K-Means方法对广告受众网民进行Data Segmentation。
  2. 使用Bottom Up Hierachical Clustering方法对搜索引擎query进行聚类以进行流量推荐。
  3. 使用EM方式寻找数据中的隐藏主体。
 使用K-Means方法对广告受众网民进行Data Segmentation
K-Means是一种球形的聚类,在二维空间中,类别会被聚成以圆心为中心的圆,三维空间中则会被聚成以球心为中心的球状簇(当然,这与选择的相似度度量有关,例如使用cosine计算归一化后的两个向量长度,就会变成计算二向量的夹角)
在K-Means算法运行前,有两个因素比较重要: 数据预处理和距离度量方法。具体距离度量参见博文相似度度量 ,数据预处理则包括数据归一化, 去除噪音等操作。
因为K-Means算法本身较为简单,此处直接给出Andrew Ng机器学习公开课教案中的伪代码:
其中uj为第j个簇的中心点,ci为第i条数据的簇类别。基本步骤就是遍历数据,每一轮迭代,先计算当前数据与哪个类中心最近,该条数据属于距离最近的簇,之后根据新计算出来的每条数据的类别,更新类中心。下图给出在指定数据上给出2个类的4轮迭代情况:
使用distortion function度量分类的好坏情况, distortion 越小越好,当然,一般distortion大小需要和类别 k 的数量间进行权衡。
应用: 虽然k-means堪称最简单的算法,但之前在实习时,在前东家还是用了一把,应用场景是使用MSN用户的注册信息(年龄,喜好,性别),以及MSN用户在 msn.com上经常访问的导航类别,搜索关键词等数据,使用决策树选出区分度较大的特征构成特征向量,使用L1-Norm进行归一化后,对特征向量进行Clustering。之后按Clustering向广告主售卖这些用户的pv。 该模式的优势是具有一定的兴趣定向作用。
右侧即为MSN展示广告。当然,该方法已经是2007年所使用的方法,现在相信MS已经使用更精准的方法了 。
该过程中尝试较多的是如何选择合适的类别数量k值,以及如何初始化初始类中心。当时迫于项目进度,k值最后根据经验并进行了粗略的搜索选择,初始类中心则使用在相同k值得情况下进行多次随机初始化Clustering
使用Bottom Up Hierachical Clustering方法对搜索引擎query进行聚类以进行流量推荐
例如在搜索引擎中, 很多网民的query意图的比较类似的,对这些query进行聚类,一方面可以使用类内部的词进行关键词推荐; 另一方面, 如果聚类过程实现自动化, 则也有助于新话题的发现;同时还有助于减少存储空间等。
例如:
训龙记国语  训龙记2 寻龙记  训龙记博克岛的骑手  驯龙记电影
骂人大全    骂人不带脏字的顺口溜    骂人带脏字越毒越好  骂人脏字的狠话
要设计层次聚类,就需要考虑一下几个因素及环节:
  1. 使用何种聚类算法: top-down 还是bottom-up 还是其他
  2. clusting的合并策略
  3. 使用哪些特征
  4. 如何度量距离
  5. 使用何种评估标准对效果进行评估
确定以上5个因素后,聚类算法也就确定了。
聚类算法:考虑到实现的复杂度, 一开始我们就确定使用bottom-up的方式作为聚类策略;后续也就没有尝试top-down的方式。
clusting的合并策略:
一般有两类合并策略: 选取最相近的两个clustering进行合并;求连通分量。 因为寻找相近cluster的方式, 时间复杂度会达到O(n^2), 所以最后决定使用连通分量。
特征: 我们使用字面特征及query在session中的共现特征; 例如, 对字面进行切词后的term(做适当过滤降维:idf太小则过滤)
距离函数, 尝试过cosine和jaccard后, 最终使用jaccard作为距离度量。
 也可关注微博: weibo.com
或是直接访问: http://semocean.com

使用NDCG评估关键词推荐系统的相关性

对于传统推荐策略, 我们在验证其效果的时候, 一般会采用以下流程验证其实验效果:
  1. offline 的评测: 思路基本和传统机器学习的思路类似, 例如在推荐算法中我们直接使用AUC,F2等评估模型效果一样, 线下使用测试数据就能知道算法的初步效果。
  2. 用户调研实验: 该方式需要人的参与, 例如招一批人, 不告诉他们新老算法的界面或是使用的算法, 然后看用户的行为, 之后使用他们的最终交互, 或是选择判定算法/交互方案的优略。
  3. 线上实验: 最真实的尝尽, 例如小流量进行A/B test
具体关于评测后续会用专门的文章介绍,此处略去。 此处仅考虑一种特定的评估:关键词推荐系统的相关性评估。
因为baidu 关键词推荐系统是关键词的推荐,所以在很大程度上, 该推荐系统和传统的IR系统有着非常紧密的联系, 评估标准也较为相像。
对于一次推荐,用户进入百度关键词推荐系统交互界面: 关键词推荐系统会主动向用户push推荐的关键词,同时用户可以输入种子query进行查询:
如果将种子query看成是搜索引擎上的query,返回的关键词看成doc, 则问题就转换为搜索引擎的结果评估问题, 一种常用的方式为:NDCG(Normalized Discount Cummulative Gain)
CG
要介绍NDCG,我们首先介绍CG(Cummulative Gain), 其思想比较简单, 就是将相关性的分值累加后, 作为某个query/ 请求结果的分值。
reli 为处于位置i的推荐结果与query的相关性, p代表我们要考察前p个结果。
DCG
CG的一个缺点是CG没有考虑结果处于不同位置对结果的影响,例如我们总是希望相关性高的结果应排在前面,相关性低的结果排在靠前的位置会严重影响用户体验, 所以需要在CG的基础上引入位置影响因素,即DCG(Discounted Cummulative Gain)
即相同的相关性rel,排在对整次检索结果的正向影响,相较于放在后边更大。
NDCG
DCG仍然有其局限之处,即不同的query之间,很难进行横向的评估。例如, 我们评估百度关键词推荐系统, 或是搜索引擎的时候,都不可能仅使用一个query及相应结果进行评估, 一般都是是使用一批query及结果进行评估。 不同的query的评估分数就需要进行归一化。 也即NDCG。
例如我们定义:
其中DCG的定义如上, IDCG为特定query返回的最好结果, 即假设返回结果按照相关性排序, 最相关的结果放在最前面, 此序列的DCG为IDCG。因DCG的值介于 (0,IDCG],故NDCG的值介于(0,1]
具体操作方式
在具体操作中, 可以事先确定query和结果的相关系分级, 例如可以使用 0,1分别表示相关或不相关, 或是这是0~5分别表示严重不相关到非常相关。 相当于确定了rel值的范围。
之后对于每一个query的返回结果给定rel值,然后使用DCG的计算公式计计算出返回结果的DCG值。
使用根据sort后的rel值得序列计算IDCG值, 即可计算NDCG
参考文献:
百度关键词系统评估
 可关注微博: weibo.com/dustinsea
也可直接访问: http://semocean.com

google的商业产品之路

之前公司从google总部招了一位经验非常丰富的PM。入职后就请他给大家为大家布道google的商业产品推进的方法。 听了之后感触颇多, 在此与记录并与大家分享(因为自己也是学习别人在google的经验, 当中会加上一些自己工作中的感受, 其中有疑问的地方欢迎讨论)

        像google这样的公司, 做出的产品基本上能够直接影响到全球, 或者说是全人类的生活。 而它的商业产品, 也能够为这个公司成为你全球最大互联网公司提供收入保障。那google在进行商业产品的推进上,思路流程是怎样的呢?
        从系统产生, 项目开发的生命周期来看, 比较自然地就分为三个阶段: 提出想法, 设计, 执行/实现(即inspiration, design,   excution)
        首先是想法的提出(inspiration), google在提创意的原则是:‘ think big, start small’,作为世界级的公司,google 的产品都是直接影响全球的, 所以一般很多想法, 创意都是冲着改变整个产业去的(to change industry, to change world)。 例如google 比较成功的商业产品adwords,现在google大部分的收入, 都和这个产品有关; 又如百度的凤巢,贡献了百度绝大部分的变现。 当然不积跬步无以至千里, 一口也吃不成个胖子。 在一开始的时候虽然有着美好的憧憬和无端的自信, 做事的时候也是以某个具体的点入手, 开始逐步推进。
        然后是设计阶段(design)。  我们经常讲, 网民, 广告主, 搜索引擎三者参与商业产品的游戏, 三者相互关联, 获取自己想要的利益。  网民需要的是信息,  广告主进行自己信息的推广并希望在有限的支出下获取到最大的转化, 而搜索引擎希望从广告主获取最大化的利益。    而google 相较于通过搜索引擎从广告主获取最大利益, 更注重广告主的收益(至少我感觉跟国内搜索引擎公司相比), google的原则更像是: ‘make customers happy, and I’m happy’。 同时google认为advertisering is a repeat bussiness,让客户玩爽了, 客户才会持续地投入更多的钱, 从长远来说, 让客户爽就能挣更多的钱。 所谓细水长流, 才能天长地久; 但很多企业为了追求短期漂亮的财务报表, 不惜杀鸡取卵。
        另一个design阶段让我感触比较深的原则, 就是enpower users。 google(包括baidu等其他搜索引擎公司)其实是在做平台, 例如baidu未来的目标是成为全球第一大媒体平台, 全球有一半的人都在用baidu的产品。。。 而用户/客户才是平台上的主角, 平台的目的是让之上的参与者更高效, 所以google会有意地为客户提供各种提升效率的工具(self-help system and material helps customers),例如各种API, Batch工具,分析工具, 让客户随时随地能够满足自己的需求。 毕竟人民才是真正的用户,  PM,工程师的力量再大, 也大不过人民的群体智慧。
        在执行阶段, google 使用data driven的方式, 其实这个方式在很多策略型项目中都在使用:  dash board线性开发, 快速上线, 线上数据说话并根据效果的分析结论快速,持续迭代。 就算是失败, 也能从失败的数据中定位失败的原因, 然后迅速纠正。 总结起来就是: persistence(持续迭代优化), fail and learn(正确看待失败并从失败的经验,数据中进行改进), data driven(数据平台的建设)。  我是策略RD, 所以这方面感触比较深, 很多时候我们做的都是策略的优化,  最常见的情况是策略上线后效果不明显,甚至是负面效果, 此时对上线后的效果数据进行分析, 一般都能发现一些之前策略设计实现的时候没有碰到的问题, 之后策略中有针对性地对这些问题进行解决, 几次迭代后, 一般都能取得比较好的效果。
        当然google商业产品的思路, 远远不止这些, 而且各个公司的具体环境也不一样。种子只有在合适的突然才能发芽。此处也只记录了自己粗浅的理解及感受。
        写在最后,这位Google的PM大牛,就是现在力美的CTO梁信屏

管理者如何保持团队稳定性

前段时间,各大互联网公司间举行了一次‘互联网公司足球大赛’,其中一场比赛是百度对战360, 百度有最帅气年轻的VP李明远参与的球队, 最终于。。。。先不说最终比分如何,微博上一条神回复让我觉得挺搞笑但又挺有感触: ‘足球比赛,百度VS 360  是百度新员工和百度老员工的比赛’
事实其实也是这样,和我一起08年入职还在公司的员工真心不多。每次我刚入职所在的小组的10多个同事聚会,提到我还在公司,他们都会露出惊讶的表情: 怎么还在百度!
的确, 我一直都惊讶百度的离职率是如此之高, 但后来了解到其他互联网公司也差不多, 甚至更高,频繁地跳槽似乎已经成为一种常态。 但无论如何,对于一个公司来说,过高的离职率本身就是不正常的,作为管理者,就应该通过各种手段降低离职率,而不是因为行业如此,就任其为之。
以下就通过我个人在百度的经历,经验以及教训, 以及公司中的培训,说下我碰到的员工离职的原因, 以及在管理者能够操作的范围内,如何挽留员工,保持团队的稳定性及士气。
总结下来,主要有两个因素影响员工去留: 职业发展和薪水,即前途和钱途,员工的离职,基本上都是因为这两方面的原因。
职业发展有可以细分为团队的发展和个人的发展。不恰当但形象的例子,我们可以将团队的发展看成是股市的大盘而个人发展看成是具体的股票, 大盘疯涨的时候,个股一般都会水涨船高,大盘低迷的时候,很少有股票能够表现惊人。 例如在一个公司作为战略重点的部分会是组,得到的资源更多,更容易出成绩,而一些边缘部门或组,事实上就不太受重视,也没有太多资源投入,发展很慢,缺少核心技术,员工看不到未来。薪水则是马斯洛论述的底层需求,高薪水是高物质生活的象征,而且帝都生活压力也挺大的, 所以这个因素也会对员工的去留取决定性作用。
让员工对团队的认可和信心
员工都是在具体团队中工作, 团队做的事,方向就是这个员工的舞台,同样舞蹈功底的人,在人流涌动的中关村地铁站口与在满座的国家大剧院 跳同样的舞, 获得的关注及成就感肯定不一样;或者用另一句通俗的话讲: 台风来的时候,猪都能上天。 当然搞IT的都不是猪,大家都很聪明,团队的核心价值及接下来要做的事是否能得到员工认可就至关重要, 如果得到认可,员工就会认为自己是在国家大剧院跳舞,自豪感,满足感油然而生;而如果员工悲观地觉得自己只是个中关村街边的流浪艺人, 那么他会对未来悲观,迷茫,也许之后他会好好想想是不是要找另一个个像国家大剧院的舞台。
另外很重要的一点,就是就是leader是否能给员工信心,一直都听说马云初创的时候,很多人都一直跟着马云,就是信任马云,这个leader就像是古代战场上的将军一样,如果有一个自己佩服的老大,那就算团队,业务有较大的调整变动,但下边的人仍然有信心跟着老大,充满信心;而如果团队中这样的人离开, 那么员工也可能会因为看不清未来而选择离职。所以有时留住团队留住领军人物,就显得至关重要了。
非常现实的事实: 前些天老大说我们优化团队为支持无线的后续发展会进行调整以更高效地支持无线变现,正当团队热火朝天地组织各种讨论, 各种规划的时候,突然得到消息,后续计划有变, 团队会被整体划到另外一个部门,当时团队里知道这个消息的人真是惊呆了,与老大沟通了半天我也没感觉到团队划出去的好处,怎么看都是效率变低,当时真的立马就有一丝想离职的冲动。。。
另外对一些级别比较高的员工,有时也会因为对公司,团队一些做事的方向,理念,思路及做事方式不认可,而去寻找新的环境。
解决之道:明确团队方向规划,认可团队价值
需要让员工了解团队的价值, 让员工觉得自己是在为一项事业而工作,而不是简单的搬砖头,螺丝钉。
管理者需要明确团队的定位及核心价值,在此基础上制定明确的roadmap,并将这些信息充分向下传达并保证大家都能认同这些信息。 如果员工有内容不认同, 则需要详细了解是因为什么原因导致不认同,并及时使用有针对性的措施或是及时调整。同时要时时为员工打气,让其认识到团队的使命感, 自己的重要性。员工认可团队的核心价值及roadmap后,即使碰到风浪,他也会像乘坐在大船中一样,知道远航的目标。
当然,有时候明确团队方向这个问题, 受到管理者所在大环境的限制,相当于管理者所在的大环境决定了员工所能上升到的天花板。例如有些部门喜欢不断提出(或是从其他部门抢夺)一些新的项目,并且将其规划得很大重点去推,在项目推进的过程中,员工会感觉到自己做的事前途无量,上升空间很大。当然这种方式也有一个风险,就是更新更受关注的项目出现的时候, 资源很容易就被投到新项目。做原有项目的人会觉得被冷落而有一种失落感。 还有些部门是守着自己的疆土,将某一领域做深, 在自己土地上还能深挖的时候,员工会觉得自己能学到很多东西,能有成长, 但当整个领域已经达到一定高度,技术带来的提升不明显,而管理者提前没有去开发新领域时, 就可能出现问题。
相对于所处大环境决定的员工发展的天花板,员工管理者帮助员工制定的个人规划,则相当于在既定的天花板的事实上,如何让员工更接近这个天花板。管理者可以在这块有更多的发挥, 或者说也只能在这块上多做一些事。
让员工对自己发展有信心
以前一个同事的跟我说过‘自己只是公司微不足道的一小部分,对对于自己却是全部’,很多时候我们会谈公司的使命,价值观, 这个的确很重要,因为没有使命,没有明确价值观的公司很容易走偏,这些东西在将员工凝聚在一起时起了不可估量的作用,但很多时候员工更关注自己的发展,如果员工觉得自己的发展出现了瓶颈,看不清未来,且这种状态持续一段时间,那么他离职的可能性也非常高。
我们可以将员工对个人发展的认知过程分为: 向前看和向两边看两种方式。
向前看, 是指员工分析自己的个人发展,是否认可自己在团队,公司的发展及前景。 包括员工想在这个公司,这个团队做怎样的事,获得什么提升,有怎样的提升。
例如员工对照自己在团队中所负责的工作,感觉到这个工作规划比较清晰, 且在接下来的较长时间, 这个方向可以长时间投入且有较大的提升, 那么这个员工肯定干劲十足全情投入;反过来,如果这个员工觉得以同样的状态方式, 在接下来一两年都不会有太大长进, 那除非他就是想在公司养老,否则他肯定会考虑动一动,找一个自己认可的方向,团队或是公司。
另外员工如果感觉到自己的老大不重视自己,或是不重视自己所做的工作,员工也会比较沮丧,这也会滋生员工离职的想法。  这些是员工对自己发展的向前看的方式。
相对地,向两边看,是指员工与公司其他员工,或是公司,部门内外同行,同事的比较,也许员工在公司里的晋升并不慢,但如果员工看到觉得和自己水平差不多的员工发展得更好更快, 那么他也会产生一种不公平的感觉。比如我之前的一次经历: 经理告诉我没有晋升,我很沮丧, 他花了很多时间和我沟通,总算让我心情平静了一些,但当晋升结果公布时,平常由我带着做项目的员工居然晋升,界别比我高时,我出离愤怒了, 当时立马产生离职的念头。 后来经理又各种安抚。 这也或多或少有点不患寡而患不均的味道。
解决之道: 给空间,重认可,多指导
给空间: 我们经常会说一个贬义词(至少很多时候我觉得是个贬义词): 画大饼。  但画大饼真的比较重要, 而且很多时候, 没有画的大饼, 就不会有真正的大饼。 画大饼, 其实就是为员工描绘了关于他自己的一个美好的远景。 当然, 只画大饼远远不够,也许画大饼的时候员工的确能够对未来有美好的憧憬,不过一旦员工发现大饼是不能做成的,那后果会比较严重,不仅之后的画大饼不起作用,同时员工也会对管理者失去信任。 所以管理者不仅要画大饼,还要给足员工做大饼的料,帮助员工做成大饼。例如一开始给员工一个明确的目标规划,那就需要在资源上支持员工完成这个目标,时候也要和员工一起回顾目标完成的情况,是员工没做好,还是料没给够。如果料没给足,那很多时候管理者就需要反省了
重认可: 这里主要是指员工的工作是不是得到管理者,团队及公司的认可,这里包含两个层面: 第一是否得到精神上的认可。如果员工觉得自己的工作及成果连自己的管理者都没有认可,那员工很少能有后续动力继续推进,这种认可很多时候可以是语言上的和行动上的,管理者对员工的任何成长进行语言或物质上的奖励,都会带来正向的效果。例如一句及时的口头表扬,一封邮件,或是季度,年度的一个奖项,都能带来较好的效果。但同样的,管理者的行为细节会让员工感觉到管理者是否受到重视,所以管理者要非常注意在员工面前的表现, 相由心生,员工会根据管理者的这些行为细节(正确或错误)地感受到自己是否真的受重视。
同时管理者要非常重视one-one的过程,员工表现好的地方要多给表扬,激励其再接再厉,表现不好的地方,要以一种帮助其进步的姿态指出,并给其建议。
第二是实质上的认可, 最明显的就是员工有没有因为所做的工作而得到晋升,因为公司有自己的流程,所以有时的确会出现很多人做的很卖力,也得到了很多精神奖励,例如口头表扬,个人奖项, 但没有晋升的情况(况且不谈这样的流程是否是最合理的); 如果出现这种,员工也会认为的工作没有被认可,得到了不公的待遇,也会产生较为负面的影响。应该尽量减少这种精神和实质认可不一致的情况。
多指导
给了空间, 有了认可以后, 还需要持续指导员工。 这里的指导又包含多方面的,例如经理的指导和直接导师的指导, 而且很多时候导师的指导更加重要直接。 好的导师能够让员工学习到更多的东西, 无论是知识或是方法,同时能保证员工能够在自己的工作中不走偏(这个也需要经理的更多参与),导师在身边能在一定程度上增强员工的安全感。
薪水的重要性
事实上,现在人们生存的压力的确也比较大,所以一方面上级,团队,公司的认可,能够满足自己更高层次的追求,但作为马斯洛基本层次的需求, 薪水也是影响绝大部分员工去留的重要因素。也许他在团队中工作比较开心, 能学到较多东西,但换个场景:如果员工觉得他在另外一个环境中,也能够开心的工作且学到较多的东西,而且拿的钱更多,或者多很多, 那我会问:他为什么不跳槽?    另一种情况,他已经觉得这个环境拿的钱比较低了,而且未来也可以预期不会涨很多,那他肯定就会考虑换工作了。 特别现在互联网公司比较多,外部给出的待遇也还不错。
这个问题其实很难解决, 因为薪水这东西太实在, 我碰到过很多员工,在公司其实工作得也挺开心的,但还是选择了外部的机会,因为外部开出的薪酬条件更诱人; 也有很多员工本来就觉得公司给得低,主动选择的。
解决之道: 这个一方面依赖于公司能否给出较高的package;另一方面,也需要在员工的个人发展上狠下功夫, 让员工了解认可自己的发展,以及寻求外部发展的规律。例如对于新人,需要让他们了解他们现阶段主要精力应该花在如何提升自己的内容; 对于老一些的员工,和他们一起做好个人的规划,让他们充分认可,同时和他们沟通寻求外部发展的规律(我的看法是这个平台是否还能支撑自己的后续发展,能否达到自己追求的目标,以及外部的机会,是否是真的好机会,是否真的适合自己)
团队的氛围
团队的氛围不是决定性的因素,如果员工因为其他原因有了离职的想法,那好的团队氛围也是留不住员工的,不过较好的团队氛围,的确能减少员工离职的想法,或是在一定程度上抵消外部更高薪金的诱惑。 有那么一种说法, 比较好的团队氛围, 能够抵消外部最高30%~50%薪酬提升的诱惑。
总的来说,给员工发展空间,以及高薪金是公司能够提供的硬实力,他依赖于公司的发展阶段,盈利能力,以及公司对人才的投入,对每个人的投入;价值观,团队氛围等属于软实力,这是管理者更多需要发挥的地方。 很多时候,以为强调软实力会让员工更理性,而且一旦在发展,薪金上受了挫折或者不公,就可能产生比较负面的后果; 较强的软实力不能保证员工不离职, 但却能增强员工的凝聚力,增强员工的幸福感, 也能在一定程度上抵消外部的诱惑, 或者是因为这些软实力有些员工就不会有意识地和外部进行过多的接触,减少外部的诱惑。
从一开始招聘就关注离职风险
很多时候,从招聘的时候,就需要考虑这个人能长期留在公司的可能性, 说一个我碰到的例子: 我在公司负责流量推荐系统,之前来校招面试的一个小姑娘,技术面结果还可以,考虑到她有推荐系统的项目经验,就给了一个校招offer,不过后来HR联系我说这小姑娘比较浮躁,是HR见过的最浮躁的校招候选人,,她可能是想拿百度的offer去其他公司谈条件,建议不发offer。我给的建议是先发offer,看她是否签,结果不出HR所料她果然拒了offer。 但后来她没拿到其它公司更好的offer,又打电话联系我,希望给她offer。 最终我还是没有给她offer,因为觉得HR说得对,她不是那么踏实,而且也不是没给她机会。从这个事后,我面试候选人的时候,也会更加注意这个人是否浮躁,是否能长期待在公司。
工作1.5~2年或者工作5年也是离职高峰, 一般工作1两年的人,觉得在公司做的事已经比较熟练,想寻找更多挑战,或是外部薪水的诱惑,会有较高的概率离职,工作5年的人,会对自己的个人发展有更清楚的认识,也可能会做出判断后选择离职。所以这两个阶段也需要特别关注。 这些都需要在平常的one-one中细致观察多沟通,提前了解,做好功课。
也可关注我的微博:  weibo.com/dustinsea
或是直接访问: http://semocean.com

选择推荐算法时需要考虑得因素

推荐系统涉及到前端交互设计,后台算法选取优化, 所以在设计推荐系统时,不能单纯使用accuracy对推荐效果进行衡量,需要根据推荐系统的具体应用场景,使用对象,解决的问题使用多指标对其进行衡量。而且很多时候这些指标都是一个上涨其他跌,需要彼此间做权衡(例如在设计百度关键词推荐引擎时,就需要在关键词的召回和准确性之间进行权衡,同时要考虑用户操作的便利性,推荐关键词的多样性等)。 下边就对这些指标进行介绍:
User Preference
用户是否喜欢该RS(Recommender System)的设计。最简单的方法就是让用户选择, 实验那种算法/交互设计用户更喜欢, 然后被投票较多的一种胜出。
中间会涉及几个问题:
  1. A算法和B算法比,假设A算法胜出了, 而投票给A的人相对于B只是稍微喜欢A一点点。 但投票给B的人却非常不喜欢A,则这种情况下,有可能最终仍然需要选择B。
  2. 每一票的权重,也可能是不同的,例如在百度关键词推荐系统中,消费较高,买词较多的客户相对于新客户更专业,他们的选择一般更科学,说以权重需要高一些。
 Prediction Accuracy
很多推荐算法都是基于数据挖掘或是机器学习, 所以很多时候, 也会使用数据挖掘和机器学习的accuracy衡量标准。我们可以简单粗暴地默认accuracy越高, 推荐算法的效果越好。
NOTE: 下文中所有的推荐系统衡量标准具体公式参见本站:推荐系统中的相似度度量
推荐算法中可以将accuracy的衡量标准分为3类:
  1. Rating Prediction
  2. Usage Prediction
  3. Accuracy of Ranking Items
Rating Prediction
例如在Netflix,douban中预测user对某个item(电影or音乐)的打分,为了评估算法预测的效果及偏差,可以使用RMSE(Root Mean Squared Error)或MAE(Mean Absolute Error)进行评估。数值越大表示偏差越大。
Usage Prediction
例如在百度关键词推荐引擎中, 更多需要考虑的是推荐出候选关键词后, 客户是否采纳该关键词(use),此时就不适合使用RMSE或是MAE进行衡量了。该场景下使用经典的Precision/Recall方式衡量更为合适,即一方面需要考虑推荐结果是否合适,另外一方面也需要考虑是否所有适合该客户该场景的结果都被推荐出来。
Precision=tp/(tp+fp)
recall=tp/(tp+fn)
更多时候可以直接使用AUC进行衡量刻画
Ranking Measures
例如在百度关键词推荐系统中,推荐出来的结果是关键词的list,排在前边的结果用户更容易看到,用户选择的代价也就更小,所以需要尽可能将更相关的结果往前排。此时就需要使用Ranking的标准衡量推荐结果list的结果。
此时一般使用NDCG(Normalized Discount Cummulative Gain)对该序列进行衡量,具体使用方式参见:使用NDCG评估关键词推荐系统的相关性
Coverage
即推荐的覆盖率, 最简单的方法就是评估推荐系统推荐的item占item全集的比例,同时评估推荐系统能够推荐给总用户的比例。 例如电商有100W种商品,推荐系统能够覆盖80W, 则可以简单地认为该推荐系统的Coverage为80%;又如网站用户为100W,推荐系统能够覆盖50W用户,则可以简单定义用户覆盖面为50%
该方式的缺点显而易见: item有重要和不重要,热门和长尾的区分,例如,在国外,哈利波特深受大家喜欢,该书/音像制品的关注度非常高,该商品被购买的概率较大,所以推荐一个哈利波特后被购买的概率, 可能是推荐一个冷门商品的N倍(例如推荐一个了冷门的‘舵机’),所以在计算Coverage的时候,需要考虑item的冷热程度。
例如在百度关键词推荐系统中,我们可以简单地考虑推荐系统所能覆盖的关键词数量的比例,但其实考虑推荐关键词所能覆盖的pv的比例,更合理。 或者在专门推荐长尾流量的出口使用关键词数量覆盖比例。
推荐用户所能覆盖的比例也是一个需要慎重考虑得问题: 一般情况下,有些客户是不适宜覆盖的,例如新用户的profile还没有建立的时候,过早地对其进行推荐,虽然覆盖率上去了, 却不能保证正确性。 所以经常需要在准确性和覆盖率上做权衡(例如不同的应用场景可以选用不同的覆盖率,准确性标准, 或是在交互上进行提示,告诉用户:仅供参考)
Confidence
推荐的置信度,很多时候,使用模型方法时,都可以产生一个置信度, 我们甚至可以根据置信度, 选择推荐样式, 或是是否展现结果给用户。 例如,当系统产生一个置信度较低的结果时,可以选择不进行推荐。
Trust
即:能否博取用户的信任。需要从心理学的角度去进行设计,例如推荐时可以掺杂一些确信的用户喜欢的item,或是推荐的时候写明推荐的理由(这点非常重要,就是‘给一个理由先’, 给了理由,说服力立马倍增)
但Trust很难定量衡量, 更多是进行调研得到调研分析结果。
Novelty
什么是Novelty?所谓Novelty,就是需要推荐新的东西,用户已经关注,已经购买的东西,再推荐就没有多少价值了。 举个例子,我经常上amazon.cn买东西,但之前经常发现一个问题: 我要买一口炒锅, 浏览了很多炒锅相关的item,之后下单买了口爱仕达的炒锅, 回头再上amazon的时候,他竟然仍然向我推荐各种品牌的炒锅。 这就是Novelty做的不好。
Serendipity
就是要推荐一些有惊喜的东西,例如我经常看某一个演员的电影,推荐系统给我推荐一部该演员演的我没看过的电影,算是Novelty; 如果给我推荐一部不是该演员演的但是风格和这些电影类似的电影,就属于Serendipity。
一个比较特别的的例子:
“假设一名用户喜欢周星驰的电影,然后我们给他推荐了一部叫做《临歧》的电影(该电影是1983年刘德华、周星驰、梁朝伟合作演出的,很少有人知道这部有周星驰出演的电影),而该用户不知道这部电影,那么可以说这个推荐具有新颖性。但是,这个推荐并没有惊喜度,因为该用户一旦了解了这个电影的演员,就不会觉得特别奇怪。但如果我们给用户推荐张艺谋导演的《红高粱》,假设这名用户没有看过这部电影,那么他看完这部电影后可能会觉得很奇怪,因为这部电影和他的兴趣一点关系也没有,但如果用户看完电影后觉得这部电影很不错,那么就可以说这个推荐是让用户惊喜的。这个例子的原始版本来自于Guy Shani的论文”
简单地说,就是让用户感觉到‘毫无理由地’喜欢
以上例子内容来自于项亮同学所著《推荐系统实践》
Diversity
最经典的例子, 在百度上搜索关键词‘苹果’,如果我们认为用户大概率是要搜手机相关的内容就不出水果的搜索结果, 那就是一个diversity较低的例子; 又如旅游推荐时,如果都是推荐一个地方的同类旅游景点时,也是diversity的一个反例,当然diversity很多时候需要和precision做trade-off
Utility
即推荐系统的效用。效用可以从两个角度考虑: 推荐系统对用户的效用及推荐系统对网站(owner)的效用,从两个角度来看,可能会得到不同的结果。 以百度关键词推荐系统为例,从用户的角度看,我们需要推荐和用户推广意图相关的关键词, 且这些关键词能够带来最高的ROI;而从百度的角度看,推荐的关键词应该带来最大的消费(至少短期的衡量标准是这样,长期考虑还是需要提升用户的ROI),针对不同的效用就需要建立不同的模型。
例如从公司的utility考虑,需要建立题词率模型(最大化推荐结果的采用率模型)及点击率模型; 从用户的角度,需要建立模型最大化ROI。 一般系统都是综合考虑这些效用决定最终结果。
 也可关注微博: weibo.com/dustinsea
或是直接访问: http://semocean.com

Google experiment infrastructure 阅读心得

背景

Google 的文化就是数据驱动:不停实验,不断得到实验结果进行分析并进行改进,这样就会导致所有R&D(Researcher&Developer)都会有不断实验的冲动和需求。这就对实验框架提出了文中重点描述的三个需求:
1.        More: 更多能够同时进行的实验
2.        Better:不合法的实验不能在框架中实验, 而合法的实验, 但如果效果不佳, 则应该能够被及时发现并下线
3.        Faster:实验应该能快速建立并启动
和google search engine面临的问题一样,推荐系统也存在大量实验,故文中的思想可以在后续关键词推荐的设计中借鉴。
原有相关工作
一般来说,进行实验的目的有以下两个:
1.        测试新的features
2.        在已有features上,测试各种参数的最优值及组合
而原有框架却有较多限制。例如google在2007年以前使用single Layer模式,该方式实现较为简单, 却有很多限制, 包括:
1.        每个请求最多只能做一个实验,可能导致很多实验流量不足
2.        添加条件进行分流时会使框架变得复杂
3.        上游模块做了较多流量划分后,下游模块可能出现stravation的状况
另一种方式:Mutil-factorialdesign,让每个参数都相对独立地做实验,最多能同时做N个实验,其中N为参数个数。缺点是不容易调整,且很多参数是不独立的,文中给的例子是UI显示文字,背景的颜色不能相同。

Overlapping Experiment Infrastucture

主要思想:
1.        将待实验参数划分为独立的N组subsets。例如,不同的binary功能不一样,则可以认为他们的parameters不相交,可划分到不同的subsets中
2.        定义domain, layer,experiment后,对流量进行划分及条件判断,其中:
l  Domain: 流量的划分,domain之间流量是不能有交集的
l  Layer:每组相关的subset参数组成一个实验layer
l  Experiment:具体实验,在一个subset中,测试0个及多个测试参数
3.        Domain, layer, experiment可以嵌套
如下图所示:
其中(a)为single layer,(b)为带有非覆盖domain的简单示例,(c)中包含两个launchlayer(d)中则存在更多嵌套
具体的参数设置, 既可以通过代码修改来实现, 也可以通过更新数据来制定(对应文中的binarypush 和data push,一般情况下data push 能够更快地进行更新)。
对于domain流量的划分,在searchengine 中一般是通过cookie来划分(不能通过request等非机器/用户属性进行划分,否则用户看到的效果可能出现跳动),而在Overlapping Experiment Infrastucture中,流量划分有以下原则:
1.        Domain 流量不能有交集,一旦流量划分到某个domain,则流量不能再其他平级的domain中被使用,所以一般domain的划分可以使用。一般使用cookie,或是cookie-day,userid取模来进行划分。
2.        Layer可以考虑使用不同的功能模块binary来进行划分参数。在各layers中,分流可使用mod =f(cookie, layer)进行流量划分
3.        在具体实验中,需要考虑condition(具体实验条件是否成立)
具体实验逻辑参见下图:
同时文中提到会使用配套数据校验工具校验数据格式正确性(其实这个是上线的必须具有的工具,并无新意),另外线上会时时关注重要指标,例如CTR,如果CTR等重要KPI超过异常边界,则新实验直接下线。这样的检测固然能保证避免异常,但是否会限制实验的上线速度需要思考,毕竟线上多个实验同时进行的话, CTR类似的KPI发生异常时,不能很快确认是哪个实验导致。
和传统方式一样, 实验框架提供的是实验流量的定位,但具体实验中,某次请求究竟是走了实验组逻辑,还是走了控制组逻辑,则仍需要从日志中分析。
其他
文中提到的以下内容也非常值得借鉴:
1.        文中提到了canary code的概念,表明google会在线上开实验,小流量测试代码正确性。也是正式,让google公司中RD/QA的比例很高(中国主要的search engine公司中,代码正确性更多是在线下验证,这就要求更多测试工程师)
2.        所有和实验框架的代码均被抽离成shared library的形式编译到各binary中,这样就让实验代码实现高度统一。但这里有一个问题:很多复杂系统中数据流是通过很多层binary后,才能得到最后的结果,如何控制各层之间的数据流向,设计时需要重点考虑。
需思考的问题
1.        涉及到多层次模块的架构中,如何控制各实验在各层之间的数据传输(如使用binary push的方式,则同一层的binary可能不一样,除非统一binary,而由data push控制)
2.        如何记录实验结果:文中使用logging的方式仍然会导致线下需要较多的logging事后分析的工作
也可关注我的微博:  weibo.com/dustinsea
或直接访问 semocean.com