分类： 未分类

背景

随着移动互联网的普及， 以及各种超级APP的出现， 每个公司都对数据收集以及充分挖掘数据的价值非常看重，并几乎不计成本地投入。 在每个公司， 无论是实时的BI报表统计分析， 通过实时数据的异常监控， 还是根据用户的实时反馈进行算法效果模型预估，在各个公司都有非常多的应用，并对公司业务效果的保障有着巨大的影响和贡献。

当然， 随着近些年各种开源软件，平台的出现， 特别是以hadoop为起点的开源组件，使得各公司都能够基于这些组件，以及各大厂的云计算快速搭建自己的大数据平台，包括实时数据处理系统。

这里八卦下自己的看法， 个人觉得这些年百度相比于阿里，百度的技术其实是在退步的（虽然我在百度工作了很多年，百度是我的老东家）， 我觉得一个主要的原因就是百度的系统太封闭。这在早些年， 在开源社区还不活跃， 大家都需要自己封闭造轮子的时代，这个时代就比拼各个公司自己的技术能力，彼时以工程师为主导的文化， 的确让百度技术领先阿里一大截。 记得10年前，我们都特看不起阿里的技术，就觉得阿里没有技术， 就业务好。 甚至业界还没提云计算的时候， 我们在百度内部， 大家的开发机就已经是以虚拟账号的方式分配资源了。相当于内部已经开始某种意义上上云了。
但后来随着开源社区的兴起， 百度这样连STL都自己重新写一套的模式就慢慢跟不上节奏了： 开源社区结合了各路神仙的才智，对各种大数据组件进行打磨，这也是开放带来的牛逼之处。

通过近两年对老东家百度出来的同学的面试深深由此感觉， 百度甚至内部跑数据还在自己写各种MR，感觉跟我2013年还在百度的时候没啥区别。。。。

扯了那么多，就是想说各种中间件的大数据处理组件，还是需要开放生态，才能有竞争力。国家都需要开放，更别说公司技术。

此处就为大家介绍我们团队为了降低实时数据计算的成本， 构建的‘基于Blink DataStream的实时数据配置平台’，从思路上介绍我们是如何满足各种纷繁多样的基于LBS的实时数据计算需求的。希望对大家有借鉴作用。

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

解决问题

移动互联网目前已经发展到近乎巅峰状态，各个大厂都有自己主打的超级APP，头条各种基于内容的kill time app，腾讯， 阿里淘宝，包括高德都是DAU过亿的超级应用。 这些应用也时刻在产生海量的用户数据。 很多场景都需要对这些数据进行实时处理， 包括：

1. 用户行为反馈后，进行BI实时报表计算&分析&财务结算
2. 系统监控，包括业务效果的监控。
3. 实时特征生成供模型实时使用，例如搜推广的ctr,cvr，实时反作弊等

这个过程中， 实时计算就是一个绕不开的话题， 而且每个场景都会有非常多的定制化需求。

图：广告系统业务端到检索端的基准+实时增量数据同步

图：实时反作弊，需要实时对用户点击反馈进行反作弊计算。

以上两个广告的例子，广告系统业务端到检索端数据同步，以及实时反作弊，都会涉及到较多的实时计算。

挑战 & 实现

在我们的场景， 对实时计算有以下要求：

1. 实时性： 实时计算的延迟很多场景需要缩短到毫秒级别，才能在很多场景满足用户需求。例如:广告实时性能力建设 《风向标逻辑》
2. 极低的接入成本：理想情况希望业务方的工程OR算法就能通过平台操作攒出满足自己需求的实时数据计算，满足自己的需求。

基于以上两个要求， 我们定制了基于Blink Data Streaming的实时计算配置平台。
Why Blink? 很简单，flink在实时计算很有优势，流批一体， 且Blink基于flink，是阿里的。
Why Data Streaming：Data Streaming更底层，可以做更深层次的定制和性能优化。

图：基于Blink Data Streaming的实时数据平台架构

在具体实现的时候。 我们将系统抽象成以下几层：

数据层
其功能是对各种来源的数据，按照规范进行数据的normalizing， 因为高德是LBS场景， 所以所有的原始数据实时进入系统的时候， 都会被规范化为<time, location, userid, object, event>， 也就是时间地点人物事件，以及事件处理到的对象。
此处的userid及object并没有带维度属性，维度属性由离线batch逻辑生成。 并在引擎层进行id和维度属性的自动关联。

引擎
此处的引擎主要有两个作用：

1. 定义算子： 我们使用blink 的data streaming api开发并优化了常用的实时数据算子， 以便引擎能够将各种算子攒成任务， 此处的算子可以灵活定义并根据需求开发， 类似于一个faas平台。
2. 任务调度： 单个算子仅进行实时数据的一步原子计算， 需要引擎层中的任务调度， 根据上对层平台计算任务配置的解析， 组合成完成整个实时计算逻辑的task任务。 此处比较像tensorflow在运行时， 将各个operator按照有向无环图编排任务进行计算的过程。

服务层
服务层的两个作用：

1. 任务配置： 负责给平台使用者提供UI，以便用户进行任务的配置。目前开源有很多这样的配置管理组件可以使用， 我们内部使用Diamond平台
2. 资源状态管理： 从系统的角度对任务进行调度， 资源分配。

效果

目前我们团队开发的实时计算平台已经在各个业务中使用， 初步实现了配置化实时任务的生成， 启动，管理， 监控。 连写blink sql都免了， 用主要负责开发的同学的话说： '该平台再完善完善， 写blink sql的同学也可以失业了。。'

如果你对我们的工作感兴趣， 可以联系我们， 需要更多同学进行类似平台的建设和完善。

参考文献

1. 广告实时性能力建设
2. 在高德吃喝玩乐！LBS信息的AI技术应用

背景

说搜推广的时候，我们会用到很多的模型来对效果进行预估，包括ctr的模型和cvr模型。这就会涉及到使用对应的指标，对模型的效果进行衡量。

一般情况下，我们使用最多的指标就是auc，因为auc可以来评判排序的效果好坏。很多时候我们也会使用auc来评判广告中的ctr或者cvr模型的好坏。而且一般我们在特定的场景也会有一个auc和线上效果的大致转化关系。例如，我们会有这样的经验：线下auc提升一个点，线上的收入提升n个点。不同的广告平台会有很大差异。

但是随着广告效果的精细化，以及引入了更多的机制，这样的模式就会存在明显问题。例如对于cpc产品我们的rpm的预估收入公式是：ecpm=ctr*bid。这就要求我们不仅要保证预估ctr的排序正确，同时需要保证ctr预估的值也足够的准确。

这就是搜索推荐与广告在对于ctr预估的准确度上的区别：搜索推荐只考虑排序的正确性，但广告需要考虑ctr预估的准确性

解决广告ctr预估准确性的手段主要就是两种，第一就是让模型足够准确，狂怼模型预估能力；第二就是增加合理的校准逻辑。

这个地方再详细展开说一下，为什么广告中对于预估的准确性那么重要，主要由以下几个原因：

1. 只有ctr足够准收入，收入预估才足够准， 如上 ecpm=ctr*bid
2. 还是ecpm=ctr*bid，因为本质上广告主关注的还是效果，roi，所以如果转化率预估的足够准，我们是可以对好的流量进行提价的，也就是增加bid，同样可以提升收入。 具体参见:CVR优化的重要性
3. 现在很多广告平台都同时支持cpc广告和ocpc广告混排，这就需要将不同模式的广告效果进行拉齐排序，也要求预估足够的准确，否则变现效果不可比.
4. 自然结果和广告需要进行混排，而且很多时候收入和自然结果的体验会有对应的量化折算关系，也要求预估足够准确。具体参见:多目标广告混排机制在超级APP中的技术

具体如何让ctr预估模型更加准确，可以参见:推荐系统，变现系统CTR&CVR预估算法演进－模型，更多的是介绍如何让校准更加准确。

校准的要求

一般情况下，校准是在预估打分之后，机制之前进行的。因为线上的计算逻辑较重，所以一般都希望校准能够相对简单，并且可解释。同时，最好校准逻辑不要跟有业务逻辑绑定，需要通用。

图：预估校准阶段，在排序机制4（预估）之后，5（机制逻辑）之前

正所谓没法衡量，就不存在优化，所以和所有的算法逻辑一样，校准也有对应的标准来进行效果的衡量。目前经常使用的衡量指标有如下三种：

PCOC：该指标的基本思想就是平均预估值/统计真实值；该指标逻辑相对简单，但是不能反映分布的差异。

CAL-N：该思路对PCOC进行分桶统计，不同桶上的误差会累计，相当于一定程度上体现了分布的值。具体的计算逻辑为：

$CAL-N=\sqrt{\frac{\sum_{i=1}^N error_i^2}{N}}$

其物理含义，就是单独计算分桶的PCOC（或error）， 然后求平均误差。

GC-N：该指标就更进一步，针对某一个特定的维度去进行加权，毕竟什么事物都有个优先级重要性。例如在广告中根据单元或者计划的pv或者收入去进行加权。具体计算逻辑为：

$GC-N=\frac{\sum_{j=1}^m w_j Cal-Nj}{\sum{j=1}^m w_j}$

其物理含义， 就是分某个维度后， 在维度上计算CAL-N，然后再进行加权汇总。 例如在广告系统中， 此处的维度可以是广告计划维度， 权重为该计划的PV或者消费。

具体实现

知乎上《阿里妈妈展示广告预估校准技术演进之路》 中介绍的已经非常详细，写的非常赞。我们团队也是借鉴了阿里妈妈的技术，所以这个地方就不详细展开，大家可以上知乎看看同学的文章写得非常详尽。 此处仅介绍传统的方法和我们团队借鉴的SIR方法。

传统校准方法

主要有以下3种：

Platt's Method
该方法的思路是对预估的值在使用实际的label进行一次参数化的映射，使用LR方式进行参数化学习。 校准函数为：

$f(x)=\frac{1}{1+e^{ax+b}}$

其中a,b为学习出来的参数。该方式优点是比较简单，且是学习出来的结果， 缺点是对于假设空间有过强的假设（认为是sigmoid函数）

Isotonic Regression
该方式的思路是使用一个单调函数来最小化预估值和label之间的square error，对结果进行保序的校准。 该方式隐含的假设， 是预估值至少能够保证预估顺序的正确性。 该方式的缺点，是处理不好预估值在突变的情况

Binning Method
该方式的思路， 是将预估值进行排序后分桶，然后统计正样本占比。

图：Smoothed Isotonic Regression(SIR)方法

具体的计算逻辑为：

1. line 1-3进行排序分桶
2. line 4-9对每个桶，计算预估样本上下界，以及正样本概率
3. line 11-23构建每个分桶的线性插值函数。
   之后，对于任意x，使用x所落在的空间，使用该区间的线性差值函数即可进行预估数值的校准。

该方式可以按天分小时进行计算，以便体现时间上的ctr值得差异， 特别是在LBS场景， 中午餐饮行业， 下午晚上的休闲娱乐酒店的分布还是有较大差异的。

线上效果

进行SIR校准后， 在我们的场景， 效果有5%左右的相对提升， 另外理论上该机制也能够更好地平衡CPC & OCPC广告的混拍。 所以先不管提升是多少， 就是一个需要去做的正确的工作 。

末了附上一句阿里土话：if not now, when? if not me, who? -- 此时此刻，非你莫属

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

背景

在广告这个领域，CTR的优化有较为悠久的历史， 这些年也出现了较多系统性的优化方法， 包括样本如何选取， 各种模型的出现和创新，在整个领域都有较深的研究沉淀。 从事这个行业的同学也都较为了解。

但当CTR优化达到较高的水平，因为预估的ecpm=ctr*bid，收入的优化会逐渐达到瓶颈，此时如果要继续优化广告的效果，就需要加入其他更多的优化链路和环节，从更多的维度，更高的视角去进行整个系统的优化，其中非常重要的一个环节， 就是CVR的优化。

图：广告cvr在检索端位置

CVR优化的重要性

那CVR优化为什么重要？

下面就详细说下这个问题。
先补充个背景：我们可以认为， 广告和搜索&推荐这样的自然信息分发有本质区别的地方： 搜索&推荐这样的自然信息分发的主体是平台，平台完全自主决定了分发的机制； 但广告不一样，广告的主体是广告主，广告主会对自己的广告，也就是广告平台分发的内容增加约束（例如出价，定向条件，时段等），而各个广告主的约束总体又形成了带约束的竞争环境。
这些约束条件，就是广告分发和搜索&推荐分发的本质区别。

而从广告平台的角度，传统上我们认为平台能够调整的因素， 主要是CTR， 因为 ：

$ecpm = Q * Bid$

而且一般情况下，Q就是CTR，而Bid是广告主设定的，原则上Bid是广告主设定的，是不能改变的， 这就导致了广告平台能够直接影响的因素， 就是优化好CTR（其实也可以影响Bid，这个待会会介绍），将CTR预估做这也是为什么之前很长时间，大家提到搜推广，第一反应就是CTR预估。

但从本质上来说，广告平台的主体是广告主，广告平台需要满足广告主的目标诉求和约束， 广告主最终的目标还是转化和ROI（不同的投放任务可能还细微不同），而不是固定的出价， 所以近些年出现的各种智能出价，包括OCPC，OCPM，就开始考虑广告主的转化了： 如果认为对于广告主这个流量价值比较高，是可以动态调整Bid的，而流量价值如何判断，就依赖于准确的CVR预估。考虑了CVR后，流量的价值可以拆分为：

$ecpm=ctr\cdot cvr \cdot abid$

此处abid为广告主对一次转化的出价。

而CVR预估做准后有两个比较大的好处：

1. 就是能够进行动态调价，调Bid，直接增加单次流量的收益
2. 广告主转化/ROI得到保障后，会有更多预算的投入，让广告平台的整个竞争环境更加充分，有利于广告平台生态的良性循环

以上就是CVR预估为什么重要的原因。

CVR优化和CTR优化的异和同

相同点：都是标准的预估任务， 按照样本，特征，模型的思路死磕预估效果。 各种创新机制都可以搞。具体可以参见：推荐系统，变现系统CTR&CVR预估算法演进－模型

不同点：转化很多时候都不是立即发生的，都会有延迟，例如APP应用下载安装的归因，可能是7天，甚至更长； 淘宝的下单，也可能会有数天的延迟， 这就存在延迟归因的问题。 另外就是转化的数据一般都会比较稀疏，这就衍生出来不一样的建模方式， 例如阿里妈妈的

而对于延迟归因，主要的解决思路又是‘样本回补’策略，通过重要性采样（importance sampling）技术来进行样本的纠偏， 具体可参见老文章：移动端转化延迟相关CPI转化率模型建模方法，同时还有很多其他的方法来对转化样本进行纠偏。

参考文献

1. 移动端转化延迟相关CPI转化率模型建模方法
2. 推荐系统，变现系统CTR&CVR预估算法演进－模型
3. Ma X, Zhao L, Huang G, et al. Entire space multi-task model: An effective approach for estimating post-click conversion rate[C]//The 41st International ACM SIGIR Conference on Research & Development in Information Retrieval. 2018: 1137-1140.
4. http://semocean.com

介绍

很久没买美股了。昨天打开雪球扫了一眼结果惊呆了， 猎豹移动（CMCM）一天居然跌了40%， 其市值几乎和其现金等价物一致。于是搜了下新闻看到底发生了什么。后来了解到原来是Kochava(第三方监控公司)曝光猎豹旗下数款工具APP存在恶意欺诈行为，主要是大点击和安装劫持。做过移动广告的人应该都知道这两种模式，且这两种模式在行业内已经是不公开的秘密。之所以这两种恶意欺诈能够成功，主要还是因为现在移动应用市场归因机制的天然缺陷导致的。

目前国外应用市场相对比国内规范：国内各种应用市场，包括手机厂商自己的应用市场，以及BAT等巨头。而国外几乎只有两家，苹果的App Store和GooglePlay。但两种方式均存在安装归因缺陷。目前的方式是第三方监控公司（类似于Appsflyer, Adjust, Kochava等）监控来自某个应用或publisher的Impression或者click，之后在手机客户端产生app安装激活后，根据之前记录的来自该手机的impression和click，判定该安装应该归因给哪个publisher。该机制貌似合理，但存在很多问题：

1. 归因时间过长，很多时候归因时间窗口能达到7天
2. 第三方无法监控impression，click是否真实发生（可能是欺诈服务器自己构造的）
3. 恶意抢归因：例如在用户没有看到，点击广告的情况下模拟impression和click， 让后来用户自然安装的应用被归因为广告的效果，或者直接监控手机用户的app下载，在检测到用户正在下载的时候发送该app的impression或者click强占该归因。可以认为和拦路抢劫比较类似

这些机制的存在都会导致整个移动互联网广告市场的混乱，大家不再专心做效果，而是将更多的心思和研发资源投入到如何构造更高明能绕过反作弊的机制。而辛苦做效果的广告公司却因为收益被抢而难于存活，形成劣币逐良币的恶性循环。

相关的欺诈反欺诈技术，不是一两篇文章能够描述透彻，也不是今天要讨论的内容。本文主要关注的点，主要还是讨论如何使用技术的问题，来对延迟归因进行建模。

图：CPI广告示例，流量测以cpm和publisher进行结算，广告主侧以cpi进行结算

之所以存在这个问题，是因为刚才提到，移动CPI(按安装付费)广告的归因窗口可以长达7天，甚至到30天：即广告在被展示后，点击后，最终的归因，例如移动CPI广告的安装激活可能在用户展示点击后的7天才会发生，这和传统的CTR预估问题不一样， 传统的CTR预估，可以认为在向用户展现广告后我们马上就能知道用户有没有点击，而手机移动端则可能需要7天甚至更长时间。这样在训练模型时，就会带来以下几个挑战：

1. 数据量：对于CPI广告，安装毕竟是少数，如果仅使用有点击的训练样本进行训练，会导致训练样本较少，学习出来的模型能力较差
2. 训练样本的选取有偏：即使是CPI广告，在线上进行预估的时候，也是有impression（甚至是有request）的时候就需要去预估CPI，而如果我们仅挑选有点击的展示作为样本进行训练，会导致和线上真实面对的分布不一致
3. 如何选择训练样本？ 传统方式下有以下几种方案：
   1. 因为新的广告不断出现，故需要模型及时更新避免效果损失，但如果在模型训练的时候，将暂时还没有转化的样本视为负样本，则可能将后续潜在的正样本也当做负样本进行训练，效果不会理想
   2. 收集满7天数据后进行训练。此时是否为真实正样本已经确定，但该方式的缺点是模型会滞后7天才能训练出来
   3. unlabeled的样本（还暂时没有conversion的样本随机作为负样本），相当于半监督学习，该方式的缺点是：线上click后产生conversion的分布并不是随机的，而是离点击时间越长，转化的概率越小

所以以上传统的3中方法都不太可取。而既然click后产生conversion的分布不是随机，而是离点击时间越长，转化概率越小，那能否将该信息建模到模型中。本文参考医学中的survival time analysis方法，根据click到conversion之间的时间差，对样本是否为真实正样本的概率进行建模。

图：impression->click->conversion的样本空间差异，如果仅用有click的样本训练pcvr，则会导致和线上impression的空间不一致

图：click->conversion用户安装，中间的时间间隔可以达到7天，导致7天内很多样本都是unlabel状态，因为并不能确定没有conversion的样本后续就不会有转化

问题定义

线上的目标是准确预估ecpm，即千次展现的花费。而ecpm可以进行如下拆解：

其中1)项我们可以认为是传统的pctr模型，2)为pctcvr模型，即在有impression,click的情况下产生conversion的概率

故可以对问题进行一下定义：

此处我们根据线上数据，能观察到的数据如下：

1. xi:即特征
2. yi:截止到现在，是否已经发生conversion
3. ei：从点击到当前时间的时间差
4. di：如果yi=1，则从click发生到conversion发生的时间差

以上定义存在以下约束关系：

1. Y=0-->C=0 or E<D 还未观察到转化，则可能该样本为负样本永远不会转化；或者E<D，即后续会产生conversion只是现在暂时还未发生
2. Y=1-->C=1
3. P(C,D|X,E) = P(C,D|X) 即样本的固有属性，不会应为观察时间而改变

有了以上定义和约束关系后， 即可对问题进行重新建模，将问题建模为以下两个子模型：

1. P(C|X)：即传统的pcvr模型
2. P(D|C=1，X)：即给定样本特征后，且假设该样本为正样本的情况下，conversion发生的时间

再具体到具体模型的实现，P(C|X)为经典的pcvr预估模型，故可以使用传统的LR模型，或者更为复杂的模型。此处假设使用LR模型，即：

P(C|X) = 1/(1+exp(-w_lr*x))

而P(D|C=1,X)则使用指数分布进行建模，即：

P(D|C=1,X) = lambda(x)*exp(-lambda(x)*d)，其中lambda(x)=exp(w_lambda*x)为hazard函数，此处借鉴了survial time analysis的思路。故最终建模中，需要学习的参数有两组：w_lr和w_lambda。

损失函数

对观察到的数据，分为两类：

• P(Y=1,D=di|X=xi,E=ei)，即已经观察到存在转化，为C=1的情况推理公式如下：
• 
• P(Y=0|X=xi,E=ei)，即距点击已经过去了时间ei，但还未观察到conversion，推理公式如下：
• 

在Y=0 and Y=1的情况都公式化后，根据我们能够拿到的数据<xi, yi, ei, di>，根据最大似然估计构建损失函数：

之后使用梯度下降法求解w_lr和w_lambda即可完成建模。

总结

• 该方法适用于用户行为存在较长流量漏斗， g. 移动端request -> impression->click->conversion，且click->conversion存在较大延迟的场景
• 该方法能够使用impression对应的数据进行建模，且建模的过程中引入了对click后产生conversion的时间观察，更符合样本的内在天然属性
• 该方法不仅适用于移动端cpi广告，同时对电商类似的具有较长流量，交易漏斗的场景同样适用。

参考文献：

1. <Mobvista海外移动变现系统核心技术>
2. <变革：从运营驱动到数据驱动>
3. Chapelle O. Modeling delayed feedback in display advertising[C]//Proceedings of the 20th ACM SIGKDD international conference on Knowledge discovery and data mining. ACM, 2014: 1097-1105

之前看过一篇文章，讲述的是孙正义如何设定目标及如何达成目标， 具体的原话忘了， 大概的思路是： 先设想自己10年后想达成的状态和目标，之后再分析要达到这个目标， 在第8年的时候需要哪些资源， 需要达成怎样的状态， 之后不断倒推， 直到当前；当然， 这么牛叉的目标设定方法， 不是每个人都能掌控的。。。

以前也曾经听一个Google资深产品经理的讲座，介绍Google的产品设计理念时，也提到Google一开始会将产品设想得比较宏大， 之后从某一个小点入手推进该产品，直到将该产品越做越大， 直到影响几乎全人类。。。

进行团队规划时，也是如此。下边就来介绍下在团队中， 一般我们是怎么做团队规划的吧。

简单来说，团队规划，是不断回答完善以下一系列问题的过程，这些问题需要在工作推进的过程中定期review和调整：

1. 希望你的团队成为怎样的团队？
2. 现在离理想状态还有多远？
3. 分几个阶段，每个阶段如何做，才可以做到？
4. 需要哪些资源，才能做到这样的团队？

希望你的团队成为怎样的团队？

这个问题，解决的是目标问题， 我们经常说‘指哪打哪’， 这个问题就是回答‘指哪？ 以及是否指对’  的问题。 这个过程相当于为团队明确定位， 例如需要明确团队的职责， 理想的团队梯队和组织架构， 团队的意识和价值体系， 理想的团队氛围， 团队能够对更大范围产生的影响和输出价值。

明确团队的职责和定位： 这个相当于是限定了团队所要做的工作的范围以及价值， 例如之前我们对位团队负责百度搜索变现流量的挖掘，以便提升公司搜索变现效率。 这就是团队的职责，符合该职责的工作， 都需要考虑是否去做。 在这样的目标设定下，首先可以选择一些当前认为重要的， 且可以做到的事去做，量力而行，逐步推进。 之后可以设定设定一些未来看起来有希望的能够做到的重点工作作为中期目标进行推进。在设定中期目标的时候，一定要抓住重点，例如以前我的老大就跟我说过： 抓住最重要的3件事，避免大而全。

团队一般还会有其他的一些目标，但这些目标一定是围绕着团队的职责来设定的，例如组织架构是为了更高效地完成团队的职责，而且好的组织架构可以用一张清晰的图就能表述清楚；团队的价值体系也是使用简单明了的话就能进行介绍； 最好还能够形成几句比较好记，琅琅上口的团队口号， 这样能够让团队，员工更有凝聚力， 这个很重要。 例如经常说百度的使命是：‘让人们更便捷地获取信息，找到所求’， 我们团队会经常类比， 说我们的职责是：‘让广告主更高效准确地覆盖适合他的流量’， 简单地一句话就能概括团队的职责。

如何确定团队职责和定位是正确的：这个可以从多个角度来验证，例如和自己的上级， 下级， 平级的同事讨论。这个非常重要，团队的职责很多时候只有得到老大的认可这是必须的，如果老大都不认可这样的定位， 那后续的工作几乎能难开展（或者从某种程度上也没必要开展： 毕竟谁出钱谁拍板！），也很协调到资源来做。 与下级讨论的主要目的有两方面， 一方面下级对团队也会有自己的看法， 可以让管理者从另外一个角度来看团队定位职责是否正确， 因为有些资深员工还是会有自己非常独到的看法，从技术的角度来对这个问题进行审视； 另外一个主要的作用，就是可以看下下级对团队职责定位的认可程度， 毕竟他们是这些职责定位的落实者， 他们具体做事，只有他们认可，后续的工作才能顺畅开展（当然即使某人不认可， 也可以通过多次沟通进行说服）

另外需要注意，这个阶段更主要的是确定近期目标， 例如半年或一年目标， 所以需要确定的事既要比较实际，又要有所拔高； 同时也需要往前看一两年， 心里边要有一个大致的谱： 一两年后，自己的团队会走到哪里。

现在离理想状态有多远？

分析团队现状：在指定这些目标的时候， 非常重要的一点，就是需要分析团队的现状： 例如团队现在的梯队，组织架构， 氛围， 相当于我们设定目标的时候是从当前的实际情况去做拔高，这个非常重要，如果起点很低，而将目标设定的非常高，也不是说不能实现，但有可能会出现目标过高导致不可能实现（具体设多少，是个技术问题，有时像又是个艺术问题）

例如11年团队调整的时候， 当时关键词搜索推荐团队分为工程， 策略团队（当时的现状）， 后来考虑到这种组织架构会导致策略调研和策略上线之间存在断层（分析‘现状’）， 出于提高团队策略迭代速度的考虑， 后来就将工程团队和策略团队进行合并， 且重新制定开发流程， 即后续很多项目， 都是从策略调研， 开发， 到最终推上线小流量乃至全流量都是由唯一负责人负责， 这样就避免了原来策略团队策略调研完毕后， 工程开发同学还要向策略同学了解具体策略考虑的代价， 同时工程同学也不会再觉得自己就是个外包， 避免了那种帮别人实现算法的失落感。 当架构有非常大的调整时， 才会引入外部纯工程团队， 一起合作推进架构的重构。

规划时，排除干扰因素：在很多公司我们都会说： 拥抱变化， 或是说： 世界上唯一没变的， 就是变化。 的确很多时候我们在做规划的时候， 都是在一个动态发展的节点对未来进行预见，会有很多变数。 例如13年就碰到两次大的团队调整， 而且第二次调整时， 团队调整方案已经定下来了， 而且已经和团队成员沟通了团队调整方案后， 突然接到老大通知， 调整方案有变， 整个团队会很快被划到另外一个部门， 后来不得不重新进行规划。 在这样变化的环境中， 会有很多的干扰因素， 但规划的时候， 其实可以在一定程度上先排除这些干扰， 否则考虑太多这种干扰因素， 会导致规划无法进行。

分几个阶段达到理想状态，每个阶段如何做，才能做到

分几个阶段做： 每次做年度规划的时候， 都觉得第一季度的事是相对比较明确的，第二季度的也还基本可以预知，但第三，第四季度的就很难把握了， 而前面也提到， 指定规划后， 需要定期review和调整， 所以每个阶段，最好不要超过一个季度，否则可能出现有些方向走偏但没有意识到的情况。每个阶段进行review，之后根据当前的进度进行目标的调整。 如果有些目标的达成需要太长时间， 则可以将这个目标达成再进行分解，避免某个节点持续时间过长。

需要哪些资源才能达到这样的团队水平

设定了上述预见的远景外， 就可以分析， 要达到该远景，需要哪些资源了。

资源可以从几个维度去区分：自己团队需要那些人， 需要上级的哪些支持， 需要兄弟团队的哪些支持，需要更大环境的哪些支持。

例如， 我们在进行百度关键词搜索推荐引擎团队规划时，认为后续需要在机器学习上进行加强， 于是开始联系HR，让其帮忙招聘更多机器学习方面的同事，同时开始联系擅长机器学习的团队， 一方面希望从兄弟团队引入对我们的项目感兴趣的同学，另一方面也了解他们团队中的机器学习工具和技术。

再比如之前团队调整过程中， 觉得关键词搜索推荐应该加强与百度检索投放系统的联动，所以后来与老大讨论后， 将底层涉及基础技术的topic model 方向划到了关键词搜索推荐小组。 这就是需要上级支持的典型。

还有一个大原则， 就是上述的规划，并不是一经制定后就是一成不变的，我们经常说计划赶不上变化，那为什么还要做规划？   规划的更大的作用是能让我们能将这些事在现阶段想清楚， 就类似于说拿破仑虽然每次战争都不是按照作战计划进行， 但每次战前他都会制定周密的作战计划。 所以， 我们要对规划怀着开放的心态，做好调整的准备。

百度关键词工具介绍参见：http://support.baidu.com/product/fc/4.html?castk=24b18bi7062c720d0d596

也可关注我的微博：  weibo.com/dustinsea

或是直接访问： http://semocean.com

• Query片段：特指query的前缀，例如用户输入的query为“鲜花快递”，其全部query片段为‘鲜’，‘鲜花’，‘鲜花快’，‘鲜花快递’。
• 拼音片段：本文中特指query片段对应的拼音片段，例如用户输入query为‘鲜花’，则全部拼音片段为‘x’，‘xi’，‘xia’，‘xian’，‘xianh’，‘xianhu’，‘xianhua’。
• 候选query：指挖掘出的候选种子query。
• wcode：建立suggestion 索引时，为每个候选query的编号，该编号值表示对应字面在数组结构中的下标位置，为无符号整型。
• 个性化suggestion：根据客户帐户信息进行推荐的query suggestion。
• 通用suggestion:与个性化suggesion对应，所有客户都适用的query suggestion。

 

• 原始query片段索引结果与拼音query片段索引结果merge，按权重从高到低排序，返回前N个结果。
• 优先返回原始query片段索引结果，数量不足时由高权重的拼音query片段索引结果补充。