(转载)年终总结 & 算法数据的思考 & 结尾彩蛋

时间：2014-12-18 18:51:43 阅读：251 评论：0 收藏：0 [点我收藏+]

标签：style http ar io color os sp for java

来自豆瓣真心不错的好文章原文链接

从前东家离职已经一个多月的时间了，在这一个月，前前后后也和几家公司做了技术交流，自己也第一次静下来这么久来思考总结。今年是我毕业的第五年，也正巧赶上年底，就把这些凑到一起写个小总结吧，也没有什么主题，没有主次，纯粹记录，想到哪儿写到哪儿。

1. 推荐系统

在最近的三四年时间里，我的主要工作就是搭建推荐系统，这几年来不说看了上千篇论文也有数百篇了，这种专注让我自认为在推荐系统领域至少处在一个业界相对领先的水准，但是也恰恰是这段经历让我被打上了深深的标签：他是一个“推荐系统专家”。既然这样，那我就先来说说推荐系统吧。

推荐系统是一个太庞大的词，我们不妨先退一步说推荐算法本身，其实推荐算法本身是一个综合性的问题，他说浅他可以做的很浅，说深也可以把他做到很深。你可以简单地用最基本的Content-based，再复杂点可以Collaborative Filtering，如果你想做的深入一些，基于SVD/LDA等的降维算法，基于SVD++等的评分预测算法，基于Learning To Rank的排序算法，甚至你再转换问题，把推荐问题再转换成分类问题，或者采用以上算法前先用各种聚类算法做数据的预处理，你可以折腾出很多很多的花样。所以做推荐领域的工程师是个很“痛苦”的事儿，因为只要机器学习领域有任何的突破性进展，你都需要去做跟踪，NLP领域出了Word2Vec，出了GloVe，其他领域的算法工程师可以说我对NLP不感兴趣，但是你必须跟踪，因为他可以辅助你去做文本内容类的推荐算法；Deep Learning可以让图像识别领域做更棒的特征工程，你也马上要去跟踪学习，因为在做图片推荐时终于有一种方式也许能解决元信息问题；RecSys2013的best paper通过调整节点顺序从而优化矩阵分块策略，极大改善了矩阵分解算法的效率，你就要去跟踪来更新自己的旧有离线算法；微软亚研搞出了一个Light LDA允许在低网络流量下去做LDA的多机并行，你就要兴冲冲地跑过去读他们啰啰嗦嗦的几十页的paper，因为终于不用忍受LDA低劣的性能了，而这些追踪往往是无穷无尽的。但是如果你一旦停止了更新知识库，就会学术界远远甩在身后，做一个“协同过滤”工程师。

但是算法的一切调整只有寄托于产品才能发挥出其最大的威力，但是如何根据产品去选择和调整算法是我认识大多数的算法工程师所非常薄弱的一点。举个实际的例子，我们都知道在所有的比赛中，多种算法的混合是最重要的环节，经常就会有人问我，说哪种混合策略是最好的，但是其实这是严重依赖于产品本身的。例如Tinder，他们的产品形态是每次只出现一个人，让你点击喜欢还是不喜欢，那么这种情况你必须需要一个算法的分类器来为每个用户选择一个合适的推荐算法，并且根据用户的反馈来实时调整分类器，因为如果用户连续Unlike了几个用户，他可能就流失掉了。但是对于LinkedIn的用户推荐列表中，你很适合用若干算法混合的算法，因为这样可以保证至少让整个列表中至少有X个所感兴趣的用户，而往往同一个推荐算法的Items是趋同的。再对于展示在首页的推荐入口区域，可以优先选择若干推荐算法的交集策略，这样可以用少量的高质量Item最大化的满足用户的心理底线，从而吸引用户点击。所以认清产品的形态和交互形式，依据产品去订制算法是成为优秀算法工程师，而非算法研究员的重要一点。

一个优秀的推荐算法，一个优秀的推荐系统的确可以为企业创造很多价值，曾经和某知名电商网站的数据总监交流，他们的推荐系统实实在在地把销售额增加了15%，但是过于神话迷恋推荐算法和过于看扁推荐算法都是一种偏激的行为。作为推荐算法工程师更应该清楚推荐算法本身的瓶颈，或者可以估计到该算法为企业带来的实际价值，从而来决定是否应该继续优化该推荐算法。何时始，何时止，是任何一个推荐算法工程师都必须要面对和决定的问题，但是聊这个话题必须要牵扯到推荐系统的两个重要部分：产品和数据。

一时想不起更好的例子来了，就说淘宝吧，以淘宝的搜索推荐为例。首先，我相信淘宝从整体来讲是不需要推荐算法的，因为淘宝是以爆款商品为主打的，构成了淘宝盈利的大部分，而我相信以淘宝的KPI和运营文化，必然会以CTR为主要的KPI，所以在这个程度上，淘宝的运营必然不停地推荐爆款商品而不可能冒着风险让这部分来做个性化。这就是产品不适合做推荐的典型例子。另一方面，由于爆款商品的推荐所以让长尾的产品没办法积累到足够的点击数据，这使得数据的缺失和偏移变得异常严重，推荐算法更是无从发挥威力。（没在淘宝工作过，所以纯属局外人猜测，另外我相信电商网站大多如此）

那么你从这一个例子就否定掉推荐系统的作用？这个我觉得有一个例子非常容易反应情况：现在地上每隔1米就有100块钱，在遥远的10000米外可能会有500W，你到底是选择一直低头捡100块钱，还是跑向遥远的10000米去找那500W的问题。

2. 深度学习

深度学习近两年可谓是机器学习领域最热的词了，大有飞入寻常百姓家的意思，现在你去参加一个数据的活动，你要是说你不会深度学习，估计会被当做神经病一样看待。但是实际上，深度学习到底有多大的价值呢？这是需要理性看待的问题。

我们先说什么是深度学习。其实从整体上来讲，Deep Learning就是曾经的多层神经网络，整体的思想认为每一个层次都可以被作为一个独立的特征抽象存在，所以最广泛地被用作特征工程上，而GPU的存在更是解决了几十年前的ANN的训练效率问题。那么简单来说，Deep Learning可以对抽取出的特征进行非线性组合形成更有效的特征表示。确实，从这一点来说，Deep Learning确实从理论上很好的解决了机器学习领域很麻烦的“特征抽取”问题，但是在实际的工业界，“特征工程”到底有多复杂？我们看看Deep Learning表现最好的IR领域吧，曾经是怎么做的呢？据了解微软有个小Team专门做的事儿就是从图片上找各种各样的特征，因为算法本身其实已经被锁死在Random Forest上了，往往特征的微调就能带来算法效果的极大提升，那么Deep Learning的出现当然可以很好地取代这项工作(实际效果确实无法得知)，那么总结下Deep Learning的好处：从海量的特征中通过特征工程抽取出有效的特征组合。

但是刨除掉语音和图像领域，转向离我们更近的工作，无论是推荐系统还是数据挖掘，特征是怎么出来的呢？对于一个电影，对于一个用户，满打满算一共就那么多特征，这个时候Deep Learning根本无从发挥。那么再退一步说，就算把User对于Item的标定作为Item的特征，由于在实际中大部分的缺失值存在，那么如果你希望用Deep Learning来对该矩阵做特征重组，第一件事情就是如何填充缺失值，而这恰恰是比特征工程更困难的事情。

至少从我目前的眼界来看，我还没有找出几家真正需要用Deep Learning来为企业创造价值的公司。

3. 大数据的反思

每一家公司都在说自己是大数据，要利用大数据，更是出现了“大数据工程师”这个职位，但是在我看来，对于算法工程师而言，该做的不是迷信大数据，而是把大数据给提取成小数据，利用小数据为企业创造价值。大数据标志着需要更大规模的集群，更大规模的计算能力，更长的生产周期，而这些都是企业的“成本”，对于大部分公司，基本面临的都是两个问题，如何拿到数据和如何利用数据，而不是如何“最好”地利用数据。

大数据其实意味着大样本量，那么大样本量带来的是高置信度以及广覆盖度。例如从FM来说，大数据量意味着更全面地了解一个用户的听歌品位，从金融互联网的信用风险评估来说，大数据量意味着不仅仅从消费记录而包含了社交网络信息去对用户做更全面的评价，从用户画像来说意味着建立全面的兴趣图谱和知识图谱，这些都是大数据带给我们的实际意义。说得学术一些，我们不妨认为大数据是频率学派对于贝叶斯学派一次强有力的逆袭。那么既然说到这个份上了，我们不妨思考一下，我们是不是有希望在回归贝叶斯学派，利用先验信息+小数据完成对大数据的反击呢？

另外，既然我们已经说到了大数据的广覆盖度，就针对这个再额外说一下吧。诚然，大数据能够全面地覆盖到所有信息，但是从实际的工业界来看，考虑到实际的计算能力以及效果，大多数公司都会对大数据做“去噪”，那么在去噪的过程中去除的不仅仅是噪音，也包括“异常点”，而这些“异常点”，恰恰把大数据的广覆盖度给降低了，于是利用大数据反而比小数据更容易产生趋同的现象。尤其对于推荐系统来说，这些“异常点”的观察其实才是“个性化”的极致。

4. 技术选型

既然都说到这里了，就顺着说到技术选型。之前和某公司聊过，他们说，你对技术选型怎么看，这里我就把当时说过的话重新整理一下吧。我认为初创公司技术选型分做两个层面看：

A. 对于大部分互联网初创公司，一般是根据初创成员擅长的领域去选择语言，选择无外乎两种，要么选择开发效率高并且入门简单的语言框架，例如Python , 例如Rails。要么选择市场覆盖量大，容易招人，并且有着非常成熟解决方案的语言，例如Java。
B. 对于小部分用Clojure的初创公司(我真心不愿意去黑)，必须满足一点，公司就是小团队作战，不需要扩张，用这种语言的好处就是连这种语言都会或者都愿意去学，会省掉很多面试的成本，但是招人的成本也增加了不少。(我真的是勉强为这种公司找个理由)

对于成熟公司的技术转型，也是分成几点来看：

A. 性能问题：说实话我极少遇到一个公司语言成为了性能瓶颈，我目前好像知道的也就是Twitter把一些核心架构从Rails变成了Java，实际原因是不是因为性能我也不知道。但是其实一定避免说上来性能问题先怪语言，据说腾讯某些工程师就特别愿意干这样的事儿，把C++当圣经，鄙视一切其他语言……但是如果真的是撑不住了，那么就换吧。

B. 社区问题 & 开发效率问题 & 招人成本问题：在10年左右的时候，大批的公司把.NET平台换成Java平台，最核心的原因除了Windows的价格问题外，还包括遇到了问题解决不了，因为大公司都是用Java/C++的，所以至少出了性能问题我还能去定点挖人，用.NET出了问题都不知道去哪儿找人。另外就是比如C++开发起来确实慢，而且非常容易系统崩溃，这个时候逐渐地去做技术转型到其他语言也是有道理的，只是要掌握节奏的问题。最后就是那些刚开始作死用一些小众语言(比如Clojure)的公司，随着大规模招人就需要做技术转型了。在这一点上，最主要的就是避免为了转型，为了秀技术，为了跟风而转型，我相信新技术也一定有新技术的好，一定解决了某一方面的问题，但是转型有着转型的代价，人力成本，系统稳定性，量产招人的困难程度，这些都可以换算成“成本”，那么在做这种转型时一定要把这笔账算清，再决定转还是不转。

C. 管理问题。一个网站，一个服务，我们不分MVC，纯粹去用PHP往模板里面写代码，其实也能做出来，开发成本稍微高点呗，但是代码容易看懂啊。这个例子有些极端，我想表达的是，用再烂的技术都能做出一个可用的东西。但是问题是，在现在的时代，程序员真他妈难找啊！当薪资几乎相同的情况下，也只能靠技术来吸引人和留人。也就是说至少要让员工觉得他们能学到新东西，外人来面试的时候我也要有能吹牛逼的资本，这时怎么办？我一般会选择在一些边缘系统上去做技术尝试，例如我会倾向于用其他语言(例如Go, Swift)搭建外围系统或实验室项目。这也是我对某些流失情况严重的团队最大的建议。

5. 算法，产品和企业价值

这一点又回到了曾经老生常谈的问题，算法工程师对于企业的价值是什么，为了讨论的方便，我们还是把算法工程师换成数据工程师吧。

A. 任何系统不要脱离产品而存在。先吐个槽，之前在某个公司面试，某个公司上来就问我，你觉得我们的用户画像应该怎么做？这个问题是非常业余的(这个问题就像是有人问我我们网站有性能问题，你说咋办；好吧，这个问题也是这个公司问我的)，任何数据系统都是强产品关联的，这也是太多公司去做数据系统的误区，在这里我还是用户画像为例。用户画像到底是什么，其实说简单了他就是一个用户宽表，如果偏要我说需要注意的，就是在选择数据库的时候一定要选择列容易扩充的数据库。如果要说具体需要哪些字段，我还真的没法说，我只能把他归类成用户元属性数据，行为统计数据，潜在挖掘数据，至此而已。因为数据系统从来不是一个事先规划好的系统，而是需要随着业务增长来逐渐填充的系统，这也是数据平台难做的原因。所以我真心无法理解有一些不太大的公司成立了一个部门，这个部门专门做用户画像(例如PPTV)。

B. 数据工程师不仅仅是处理数据而是理解数据。我遇到的数据工程师大抵分成两类，一类是数据开发工程师，例如Hadoop工程师，数据仓库工程师；一类是学术化的工程师，深钻模型，这种工程师其实还是更适合研究院；当然，这两种工程师都各有优缺点，但是我更觉得对于大部分企业来说更需要一个理解数据而非处理数据的工程师，核心价值更应该在于深入去理解产品业务，数据处理，数据建模，做数据分析和挖掘，接下来对于产品的发展做数据化的驱动，并且知道何时应该继续对模型进行优化，何时应该适可而止。

C. 沿着上一点继续说，Growth Hacker & Data Scientist。一个优秀的算法/数据工程师应该具备Growth Hacker 和 Data Scientist的能力，其实这两点也恰恰标志着不仅仅是数据，而是一个产品的最重要两点：增长和留存。作为Growth Hacker，你应该为企业找到潜在的机会点，帮助产品增长；另一方面，你也应该作为Data Scientist，发现现有数据的问题，帮助产品优化体验，提升留存，而推荐系统往往是属于这一部分的子集。

D. 避免成为成本部门。这是我后期去带一个事业部的时候才有着的最深体会。对于任何一个部门来讲，最痛苦的莫过于自己成为了公司的成本部门，所以为什么小公司的实验室部门根本搞不下去，所以为什么数据部门都希望自己有个数据产品，所以为什么技术部门都不希望自己仅仅是一个支撑部门。那么无论是对于技术团队，还是数据团队，作为部门的负责人，永远需要想的都应该是，我们为企业到底创造了什么实际的价值，而这个价值是不是当前公司所最紧缺的。例如公司现在最缺的是增长，你整个部门偏偏要拼死命做留存；公司最需要的是产品快速迭代，你偏偏要去搞底层性能优化。这些很势利，却是决定着部门荣辱兴衰的最重要一点，无论是什么部门，去帮忙解决公司最痛的那个点才是最重要的。

6. 数据和直觉

有一次我和别人聊了很多，他说所以做产品经理必须要数据决策对不对？我觉得这个事儿也对也不对。

数据驱动是什么？数据驱动是从已有的数据中去发现规律对产品进行优化，但是数据做不到的是从未知中挖掘机会点，而这往往是一个优秀产品经理的直觉。我经常和人举的一个例子是，要是数据驱动，也许今天应该也出现不了微信。很多时候优秀的创意就是来源于一个直觉，而不是循规蹈矩的分析推导，因为这样往往会陷入我在上文提到的大数据的窘境。所以不要无视数据，更不要神化数据，该相信直觉的时候还是相信直觉。其实有时候做算法也是一样，你不可能把上千种算法都A-B Test一次，有时候别人问我为什么，我能说的也就是直觉，作为算法工程师的直觉，“用另外一种算法效果不会更好的”。

更何况产品经理的沟通，协调，跟踪能力同样是不可或缺的一部分，也是大部分工程师所缺乏的自身特质。

7. 数据工程师的窘境

这一点我不知道该从何写起，其实算是数据工程师职业生涯上面临的最大尴尬吧。

现在所有公司都在谈数据驱动，可是说实话我目前还真的没看到有真正数据驱动的公司，为什么呢？很关键的就是，说驱动你得驱动得起来才行啊。对于大部分公司，数据部门只是作为一个独立的支撑部门存在，我让你干嘛你就干嘛就行了，今天帮我跑个数据，明天帮我上个模型，产品是我的，你别和我指手画脚。再一些公司呢，数据部门，不对，不能叫做部门，“数据组”只是产品的一个附属部门，部门的老大都是产品总监，你就更没资本去驱动你的Boss了。其实归根结底，还是中国人不相信这些东西，老板自己都不相信或者不重视，各位想一下大部分中小公司对于CTO和技术总监的要求就知道了：帮我把性能问题给解决了，而这些却恰恰应该是一个系统架构师的定位。这里必须要再丢一下caoz的文章：《CTO这点事 - caoz的梦呓》

那么数据工程师发展到最后职业生涯到底进展到哪儿呢？我也不知道，也许我们都只能期望国内数据行业的进一步成熟和被认可了。而这些就是我以前老大讲的，在数据的工程领域，我们都是先行者，没有人可以告诉我们怎么走，这些都是需要我们自己去探索和闯荡的路。

8. 企业价值 & 市值

我一直有个理论，一个大的市场，一定能够容纳下两家上市公司。例如我们认为分类信息是个大领域，那么58上市了，我相信赶集一定能上，而且如果“58” 30亿的市值，我相信赶集应该会在20亿上下浮动。这个其实极大地关系到了如何选择一个公司。

其实现在就这么多行业了，社交网络已经日渐没落，腾讯和陌陌已经切去了聊天IM的大部分市场，所以现在一家再做细分领域的聊天社交，包括匿名社交我相信都只是骗骗投资人的钱罢了。视频行业大势已定，几乎没什么太大空间了。唯一一个老牌并且有想象空间的就是音乐，问题还是在于版权和付费意识决定了音乐行业的变现一直是大问题，所以倒是仍然值得再去拼一次。

那么剩下的就是大家都热炒无数次的。
电商: 电商一定还会有市场，只是新应用的用户获取成本太高，如何选择品类，如何实现用户的自传播从而实现盈利成为了最关键的问题。
O2O: 一个又一个细分市场，因为线下太大，没有任何一家有资本和能力全部囊括。但是稍微熟悉O2O行业的都知道，O2O的最大关键还是在于Offline的服务品质，线上只是线下的一个宣传手段罢了，就像曾经在QQ上也能订餐，现在只是发展出一个APP然后服务规模扩大化精细化了而已，既然只是一个渠道，那么Online的部分在O2O行业所能得到的重视程度自然也就有限(个人意见，不喜可喷)。
互联网金融：金融互联网是个千万亿的市场，一旦成功注定是秒杀互联网行业的，可是正是因为这种高市值也伴随着高风险，一个不小心现金流就如同那些P2P公司一样卷铺盖跑路了。另外问题一样，互联网金融，核心还是金融，互联网只是渠道，那么核心竞争力还是取决于如何利用数据来推动金融业务的发展，例如现在P2P里的信用风险评估，其实就是金融业的最基本概念罢了，现在拿出来用互联网再炒一遍。
在线教育：不懂.....只是直觉觉得不看好，因为觉得反人性的，太严肃的东西在互联网上都玩不转
硬件：离我太远，我只是觉得现在的智能硬件还处于太初级的阶段，大多是传统硬件加个Wifi而已，有待继续发展。

其实对于大多数人来讲，技术永远都不是瓶颈，难的都是如何选择一个公司和行业，从短期来讲选公司，在过去我们都可以靠融资多少，风投机构是否靠谱来判断一个公司，但是在资本大热的今天变得越来越不可行了，那么这个时候只能依靠自己的判断。例如拉勾，B轮2500万美元，那么也就是说预计B轮估值3亿左右，那么就看看吧，51job和智联都在10个亿左右的市值，而拉勾做的太深领域无法自拔，只能是他们的一个金字塔顶，于是你可以去推算一下他的想象空间。
长期来讲选行业，那么未来几年内大热的行业也就这么多，选行业看看前车之鉴例如旅游，看看途牛的估值也知道这个行业的互联网发展了；再接下来我觉得重要的还是在于在这个行业中到底能扮演什么样的角色，是否能解决核心问题，例如硬件的核心问题从眼前来看是供应链和生产工艺，那么做数据去盲目进入只会沦为边缘角色，如此类推。

9. ........

考虑实际影响，已经删除彩蛋

(转载)年终总结 & 算法数据的思考 & 结尾彩蛋

标签：style http ar io color os sp for java

原文地址：http://blog.csdn.net/sp_programmer/article/details/42008305

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行