从前东家离职已经一个多月的时间了，在这一个月，前前后后也和几家公司做了技术交流，自己也第一次静下来这么久来思考总结。今年是我毕业的第五年，也正巧赶上年底，就把这些凑到一起写个小总结吧，也没有什么主题，没有主次，纯粹记录，想到哪儿写到哪儿。
1.推荐系统
在最近的三四年时间里，我的主要工作就是搭建推荐系统，这几年来不说看了上千篇论文也有数百篇了，这种专注让我自认为在推荐系统领域至少处在一个业界相对领先的水准，但是也恰恰是这段经历让我被打上了深深的标签：他是一个“推荐系统专家”。既然这样，那我就先来说说推荐系统吧。
推荐系统是一个太庞大的词，我们不妨先退一步说推荐算法本身，其实推荐算法本身是一个综合性的问题，他说浅他可以做的很浅，说深也可以把他做到很深。你可以简单地用最基本的Content-based，再复杂点可以CollaborativeFiltering，如果你想做的深入一些，基于SVD/LDA等的降维算法，基于SVD++等的评分预测算法，基于LearningToRank的排序算法，甚至你再转换问题，把推荐问题再转换成分类问题，或者采用以上算法前先用各种聚类算法做数据的预处理，你可以折腾出很多很多的花样。所
以做推荐领域的工程师是个很“痛苦”的事儿，因为只要机器学习领域有任何的突破性进展，你都需要去做跟踪，NLP领域出了Word2Vec，出了GloVe，其他领域的算法工程师可以说我对NLP不感兴趣，但是你必须跟踪，因为他可以辅助你去做文本内容类的推荐算法；DeepLearning可以让图像识别领域做更棒的特征工程，你也马上要去跟踪学习，因为在做图片推荐时终于有一种方式也许能解决元信息问题；RecSys的bestpaper通过调整节点顺序从而优化矩阵分块策略，极大改善了矩阵分解算法的效率，你就要去跟踪来更新自己的旧有离线算法；微软亚研搞出了一个LightLDA允许在低网络流量下去做LDA的多机并行，你就要兴冲冲地跑过去读他们啰啰嗦嗦的几十页的paper，因为终于不用忍受LDA低劣的性能了，而这些追踪往往是无穷无尽的。但是如果你一旦停止了更新知识库，就会学术界远远甩在身后，做一个“协同过滤”工程师。
但是算法的一切调整只有寄托于产品才能发挥出其最大的威力，但是如何根据产品去选择和调整算法是我认识大多数的算法工程师所非常薄弱的一点。举个实际的例子，我们都知道在所有的比赛中，多种算法的混合是最重要的环节，经常就会有人问我，说哪种混合策略是最好的，但是其实这是严重依赖于产品本身的。例如Tinder，他们的产品形态是每次只出现一个人，让你点击喜欢还是不喜欢，那么这种情况你必须需要一个算法的分类器来为每个用户选择一个合适的推荐算法，并且根据用户的反馈来实时调整分类器，因为如果用户连续Unlike了几个用户，他可能就流失掉了。但是对于LinkedIn的用户推荐列表中，你很适合用若干算法混合的算法，因为这样可以保证至少让整个列表中至少有X个所感兴趣的用户，而往往同一个推荐算法的Items是趋同的。再对于展示在首页的推荐入口区域，可以优先选择若干推荐算法的交集策略，这样可以用少量的高质量Item最大化的满足用户的心理底线，从而吸引用户点击。所以认清产品的形态和交互形式，依据产品去订制算法是成为优秀算法工程师，而非算法研究员的重要一点。
一个优秀的推荐算法，一个优秀的推荐系统的确可以为企业创造很多价值，曾经和某知名电商网站的数据总监交流，他们的推荐系统实实在在地把销售额增加了15%，但是过于神话迷恋推荐算法和过于看扁推荐算法都是一种偏激的行为。作为推荐算法工程师更应该清楚推荐算法本身的瓶颈，或者可以估计到该算法为企业带来的实际价值，从而来决定是否应该继续优化该推荐算法。何时始，何时止，是任何一个推荐算法工程师都必须要面对和决定的问题，但是聊这个话题必须要牵扯到推荐系统的两个重要部分：产品和数据。
一时想不起更好的例子来了，就说淘宝吧，以淘宝的搜索推荐为例。首先，我相信淘宝从整体来讲是不需要推荐算法的，因为淘宝是以爆款商品为主打的，构成了淘宝盈利的大部分，而我相信以淘宝的KPI和运营文化，必然会以CTR为主要的KPI，所以在这个程度上，淘宝的运营必然不停地推荐爆款商品而不可能冒着风险让这部分来做个性化。这就是产品不适合做推荐的典型例子。另一方面，由于爆款商品的推荐所以让长尾的产品没办法积累到足够的点击数据，这使得数据的缺失和偏移变得异常严重，推荐算法更是无从发挥威力。（没在淘宝工作过，所以纯属局外人猜测，另外我相信电商网站大多如此）
那么你从这一个例子就否定掉推荐系统的作用？这个我觉得有一个例子非常容易反应情况：现在地上每隔1米就有块钱，在遥远的00米外可能会有W，你到底是选择一直低头捡块钱，还是跑向遥远的00米去找那W的问题。
2.深度学习
深度学习近两年可谓是机器学习领域最热的词了，大有飞入寻常百姓家的意思，现在你去参加一个数据的活动，你要是说你不会深度学习，估计会被当做神经病一样看待。但是实际上，深度学习到底有多大的价值呢？这是需要理性看待的问题。
我们先说什么是深度学习。其实从整体上来讲，DeepLearning就是曾经的多层神经网络，整体的思想认为每一个层次都可以被作为一个独立的特征抽象存在，所以最广泛地被用作特征工程上，而GPU的存在更是解决了几十年前的ANN的训练效率问题。那么简单来说，DeepLearning可以对抽取出的特征进行非线性组合形成更有效的特征表示。确实，从这一点来说，DeepLearning确实从理论上很好的解决了机器学习领域很麻烦的“特征抽取”问题，但是在实际的工业界，“特征工程”到底有多复杂？我们看看DeepLearning表现最好的IR领域吧，曾经是怎么做的呢？据了解微软有个小Team专门做的事儿就是从图片上找各种各样的特征，因为算法本身其实已经被锁死在RandomForest上了，往往特征的微调就能带来算法效果的极大提升，那么DeepLearning的出现当然可以很好地取代这项工作(实际效果确实无法得知)，那么总结下DeepLearning的好处：从海量的特征中通过特征工程抽取出有效的特征组合。
但是刨除掉语音和图像领域，转向离我们更近的工作，无论是推荐系统还是数据挖掘，特征是怎么出来的呢？对于一个电影，对于一个用户，满打满算一共就那么多特征，这个时候DeepLearning根本无从发挥。那么再退一步说，就算把User对于Item的标定作为Item的特征，由于在实际中大部分的缺失值存在，那么如果你希望用DeepLearning来对该矩阵做特征重组，第一件事情就是如何填充缺失值，而这恰恰是比特征工程更困难的事情。
至少从我目前的眼界来看，我还没有找出几家真正需要用DeepLearning来为企业创造价值的公司。
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.沿着上一点继续说，GrowthHackerDataScientist。一个优秀的算法/数据工程师应该具备GrowthHacker和DataScientist的能力，其实这两点也恰恰标志着不仅仅是数据，而是一个产品的最重要两点：增长和留存。作为GrowthHacker，你应该为企业找到潜在的机会点，帮助产品增长；另一方面，你也应该作为DataScientist，发现现有数据的问题，帮助产品优化体验，提升留存，而推荐系统往往是属于这一部分的子集。
D.避免成为成本部门。这是我后期去带一个事业部的时候才有着的最深体会。对于任何一个部门来讲，最痛苦的莫过于自己成为了公司的成本部门，所以为什么小公司的实验室部门根本搞不下去，所以为什么数据部门都希望自己有个数据产品，所以为什么技术部门都不希望自己仅仅是一个支撑部门。那么无论是对于技术团队，还是数据团队，作为部门的负责人，永远需要想的都应该是，我们为企业到底创造了什么实际的价值，而这个价值是不是当前公司所最紧缺的。例如公司现在最缺的是增长，你整个部门偏偏要拼死命做留存；公司最需要的是产品快速迭代，你偏偏要去搞底层性能优化。这些很势利，却是决定着部门荣辱兴衰的最重要一点，无论是什么部门，去帮忙解决公司最痛的那个点才是最重要的。
6.数据和直觉
有一次我和别人聊了很多，他说所以做产品经理必须要数据决策对不对？我觉得这个事儿也对也不对。
数据驱动是什么？数据驱动是从已有的数据中去发现规律对产品进行优化，但是数据做不到的是从未知中挖掘机会点，而这往往是一个优秀产品经理的直觉。我经常和人举的一个例子是，要是数据驱动，也许今天应该也出现不了北京看白癜风是多少钱科学抗白北京中科技术精湛