前言
作为一个转行的人，自然要介绍一下自己的专业背景。笔者在本科的时候的专业是数学与应用数学，外行人可以理解为基础数学。在博士期间的研究方向是动力系统和分形几何，所做的还是基础数学，和计算机的关系不大。
如果有人想了解笔者究竟在做什么科研的话，可以参考知乎文章：
复动力系统（1）--- Fatou集与Julia集
链接：https://zhuanlan.zhihu.com/p/30952328
至于机器学习的话，在读书期间基本上也没接触过，甚至没听说过还有这种东西。不过在读书期间由于专业需要，C++ 之类的代码还是能够写一些的，在 UVA OJ 上面也留下过自己的足迹。
2015 年：尝试转型
行路难，行路难，多歧路，今安在？
在 2015 年毕业之后机缘巧合，恰好进入腾讯公司从事机器学习的相关工作。不过刚进来的时候压力也不小，现在回想起来的话，当时走了一些不该走的弯路。用李白的《行路难》中的诗词来描述当时的心情就是“行路难，行路难，多歧路，今安在？”
在 2015 年 10 月份，第一次接触到一个不大不小的项目，那就是 XX 推荐项目。而这个项目是当时组内所接到的第二个推荐项目，当年的推荐系统还是搭建在大数据集群上的，完全没有任何说明文档和前端页面，当时的整个系统和全部流程复杂而繁琐。不过在接触这个系统的过程中，逐步开始学习了 Linux 操作系统的一些简单命令，SQL 的使用方法。
了解 SQL 的话其实不只是通过了这个系统，通过当时的 ADS 值班，帮助业务方提取数据，也把 SQL 的基础知识进一步的加深了。SQL 的学习的话，在2015年读过两本非常不错的入门教材《SQL基础教程》与《HIVE编程指南》。Linux 的相关内容阅读了《Linux 命令行与 Shell 脚本编程大全》之后也就大概有所了解了。于是工作了一段时间之后，为了总结一些常见的 SQL 算法，写过一篇文章 "HIVE基础介绍"。
在做推荐项目的过程中，除了要使用 SQL 来处理数据，要想做机器学习，还需要了解常见的机器学习算法。当年接触到的第一个机器学习算法就是逻辑回归（Logistic Regression），既然提到了机器学习的逻辑回归，无法避免的就是交叉验证的概念，这个是机器学习中的一个基本概念。
通过物品的类别属性和用户的基本特征来构造出新的特征，例如特征的内积（inner product）。后来在学习的过程中逐步添加了特征的外积和笛卡尔积，除了特征的交叉之外，还有很多的方法来构造特征，例如把特征标准化，归一化，离散化，二值化等操作。除了构造特征之外，如何判断特征的重要性则是一个非常关键的问题。
最常见的方法就是查看训练好的模型的权重，另外还可以使用 Pearson 相关系数和 KL 散度等数学工具来粗糙的判断特征是否有效。在此期间也写过一些文章“交叉验证”，“特征工程简介”，“KL散度”。关于特征工程，除了阅读一些必要的书籍之外，最重要的还是要实践，只有实践才能够让自己的经验更加丰富。
在做推荐系统的时候，之前都是通过逻辑回归算法（Logistic Regression）离线地把模型的权重算好，然后导入线上系统，再进行实时的计算和打分。除了离线的算法之外，在 2015 年的 12 月份了解到了能够在线学习的 FTRL 算法。调研了之后在 2016 年初在组内进行了分享，同时在zr9558.com 上面分享了自己的总结。
在做 XX 推荐项目的过程中，了解到了数据才是整个机器学习项目的基石，如果数据的质量不佳，那就需要进行数据的预处理，甚至推动开发人员去解决数据上报的问题。
通常来说，要想做好一个推荐项目，除了特征工程和算法之外，最重要的就是数据的核对。当时的经验是需要核对多方的数据，那就是算法离线计算出来的结果，线上计算出来的结果，真实产品中所展示的结果这三方的数据必须要完全一致，一旦不一致，就需要复盘核查，而不是继续推进项目。在此期间，踩过无数的数据的坑，因此得到的经验就是一定要反复的核查数据。
2016：从零到一
站在巨人的肩膀上，才能看得更远。-—学习推荐系统
“站在巨人的肩膀上，才能看得更远。”到了 2016 年的 2 月份，除了 XX 推荐项目的首页个性化调优算法之外，还开启了另外一个小项目，尝试开启首页的 tab，那就是针对不同的用户推荐不同的物品。这个小项目简单一点的做法就是使用 ItemCF 或者热传导传播的算法，在用户收听过某个节目之后，就给用户推荐相似的节目。
这种场景其实在工业界早就有了成功的案例，也不算是一个新的场景。就好比与用户在某电商网站上看中了某本书，然后就被推荐了其他的相关书籍。之前也写过一篇推荐系统的简单算法“物质扩散算法”，推荐给大家参考一下。至于 ItemCF 和热传导算法的相关内容，会在后续的 Blog 中持续完善。
“读书千遍，其义自见。”在使用整个推荐系统的过程中，笔者只是大概知道了整个系统是如何搭建而成的。而要整体的了解机器学习的相关算法，光做项目则是远远不够的。在做推荐业务的这段时间，周志华老师的教材《机器学习》在2016年初上市，于是花了一些时间来阅读这本书籍。但是个人感觉这本书难度不大，只是需要另外一本书结合着看才能够体会其中的精妙之处，那就是《机器学习实战》。在《机器学习实战》中，不仅有机器学习相关算法的原理描述，还有详细的源代码，这足以让每一个初学者从新手到入门了。
路漫漫其修远兮，吾将上下而求索。
说到从零到一，其实指的是在这一年体验了如何从零到一地做一个新业务。到了 2016 年的时候，为了把机器学习引入业务安全领域，在部门内部成立了 XX 项目组，这个项目在部门内部其实并没有做过大规模的尝试，也并没有成功的经验，甚至也没有一个合适的系统让人使用，而且安全业务和推荐业务基本上不是一回事。
因为对于推荐系统而言，给用户的推荐是否准确决定了 CTR 是否达标，但是对于安全系统而言，要想上线打击黑产的话，准确率则需要 99% 以上才行。之前的推荐系统用得最多的算法就是逻辑回归，而且会存储物品和用户的两类特征，其余的算法主要还是 ItemCF 和热传导算法。这就导致了当时做 XX 项目的时候，之前的技术方案并不可用，需要基于业务安全的实际场景来重新搭建一套框架体系。
但是当时做安全项目的时候并没有实际的业务经验，而且暂定的计划是基于 XX1 和 XX2 两个业务来进行试点机器学习。为了做好这个项目，一开始笔者调研了几家号称做机器学习+安全的初创公司，其中调研的最多的就是 XX 这家公司，因为他们家发表了一篇文章，里面介绍了机器学习如何应用在业务安全上，那就是搭建一套无监督+有监督+人工打标签的对抗体系。
笔者还是总结了当时两三个月所学的异常点检测算法，文章如下：
异常点监测算法（一）
异常点检测算法（二）
异常点检测算法（三）
异常点检测算法综述
在 2016 年底的时候，说起来也是机缘巧合，有的同事看到了我在 2016 年 11 月份发表的文章，就来找笔者探讨了一下如何构建游戏 AI。当时笔者对游戏AI的应用场景几乎不了解，只知道 DeepMind 做出了 AlphaGo，在 2013 年使用了深度神经网络玩 Atari 游戏。在12月份花费了一定的时间研究了强化学习和深度学习，也搭建过简单的 DQN 网络进行强化学习的训练。
通过几次的接触和交流之后总算 2017 年 1 月份做出一个简单的游戏 AI，通过机器学习也能够进行游戏 AI 的自主学习。虽然不在游戏部门，但是通过这件事情，笔者对游戏 AI 也产生了浓厚的兴趣，撰写过两篇文章“强化学习与泛函分析”，“深度学习与强化学习”。
2017 年：再整旗鼓
在做日常项目的同时，在 2017 年也接触量子计算。在后续几个月的工作中，持续调研了量子计算的基础知识，一些量子机器学习的技术方案，写了两篇文章“量子计算（一）”，“量子计算（二）”介绍了量子计算的基础概念和技巧。
三十功名尘与土，八千里路云和月。
提到再整旗鼓，其实指的是在 2017 年再次从零到一的做全新的项目。到了 2017 年 7 月份，随着业务安全的机器学习框架已经逐渐完善，XX 项目也快走到了尾声，于是就又有了新的项目到了自己的手里，那就是织云智能运维项目。运营中心这边还在探索和起步阶段，业界的智能运维（AIOPS）的提出也是在2017年才逐步开始，那就是从手工运维，自动化运维，逐步走向人工智能运维的阶段，也就是所谓的 AIOPS。只有这样，运营中心才有可能实现真正的咖啡运维阶段。
正式接触到运维项目是 2017 年 8 月份，从跟业务运维同学的沟通情况来看，当时有几个业务的痛点和难点。例如：织云Monitor 时间序列的异常检测，哈勃的根因分析，织云ROOT 系统的根源分析，故障排查，成本优化等项目。在 AIOPS 人员短缺，并且学术界并不怎么研究这类技术方案的前提下，如何在运维中开展机器学习那就是一个巨大的难题。
就像当年有神盾系统，无论怎么做都可以轻松的接入其余推荐业务，并且也有相对成熟的内部经验，学术界和工业界都有无数成功的案例。但是智能运维这一块，在 2017 年才被推广出来，之前都是手工运维和 DevOps 的一些内容。于是，如何尽快搭建一套能够在部门内使用的智能运维体系就成了一个巨大的挑战。面临的难题基本上有以下几点：
历史包袱沉重
AIOPS 人员短缺
没有成熟的系统框架
在这种情况下，外部引进技术是不可能了，只能够靠自研，合作的同事主要是业务运维和运营开发。当时第一个接触的智能运维项目就是哈勃的多维下钻分析，其业务场景就是一旦发现了成功率等指标下跌之后，需要从多维的指标中精准的发现异常，例如从运营商，省份，手机等指标中发现导致成功率下跌的原因，这就是经典的根因分析。这一块在调研之后发现，主要几篇文章可以参考，综合考虑了之后撰写了一份资料，那就是“根因分析的探索”。
PS：除了哈勃多维下钻之外，个人感觉在 BI 智能商业分析中，其实也可以是这类方法来智能的发现“为什么DAU下跌？”“为什么收入没有达到预期”等问题。
除了哈勃多维下钻之外，织云Monitor 的时间序列异常检测算法则是更为棘手的项目。之前的 Monitor 异常检测算法，就是靠开发人员根据曲线的特点设定三个阈值（最大值，最小值，波动率）来进行异常检测。这样的结果就是准确率不准，覆盖率不够，人力成本巨大。
在上百万条曲线都需要进行异常检测的时候，每一条曲线都需要人工配置阈值是完全不合理的。于是，导致的结果就是每周都需要有人值班，有了问题还不一定能够及时发现。而对于时间序列算法，大家通常能够想到的就是 ARIMA 算法，深度学习的 RNN 与 LSTM 算法，Facebook 近期开源的 Prophet 工具。这些方法笔者都调研过，并且未来会撰写相关的文章介绍 ARIMA，RNN，Prophet 的使用，欢迎大家交流。
其实以上的几种时间序列预测和异常检测算法，主要还是基于单条时间序列来做的，而且基本上是针对那些比较平稳，具有历史规律的时间序列来进行操作的。如果针对每一条曲线都单独搭建一个时间序列模型的话，那和阈值检测没有任何的区别，人力成本依旧巨大。而且在织云Monitor的实际场景下，这些时间序列异常检测模型都有着自身的缺陷，无法做到“百万条KPI曲线一人挑”的效果。
于是在经历了很多调研之后，我们创新性地提出了一个技术方案，成功的做到了“百万条曲线”的异常检测就用几个模型搞定。那就是无监督学习的方案加上有监督学习的方案，第一层我们使用无监督算法过滤掉大部分的异常，第二层我们使用了有监督的算法来提升准确率和召回率。
在时间序列异常检测的各类算法中，通常的论文里面都是针对某一类时间序列，使用某一类模型，效果可以达到最优。但是在我们的应用场景下，见过的曲线千奇百怪，笔者都说不清楚有多少曲线的形状，因此只用某一类时间序列的模型是绝对不可取的。
但是，在学习机器学习的过程中，有一种集成学习的办法，那就是把多个模型的结果作为特征，使用这些特征来训练一个较为通用的模型，从而对所有的 织云Monitor 时间序列进行异常检测。这一类方法笔者总结过，那就是“时间序列简介（一）”，最终我们做到了“百万条曲线一人挑”，成功去掉了制定阈值的业务效果。
走向未来
亦余心之所善兮，虽九死其犹未悔。
在转行的过程中，笔者也走过弯路，体会过排查数据问题所带来的痛苦，经历过业务指标达成所带来的喜悦，感受过如何从零到一搭建一套系统。在此撰写一篇文章来记录笔者这两年多的成长经历，希望能够尽微薄之力帮助到那些有志向转行来做机器学习的人。从这两年做项目的经历来看，要想从零到一地做好项目，在一开始就必须要有一个好的规划，然后一步一步的根据项目的进展调整前进的方向。但是如果没有一个足够的知识积累，就很难找到合适的前进方向。
“亦余心之所善兮，虽九死其犹未悔。”在某些时候会有人为了短期的利益而放弃了一个长远的目标，但是如果要让自己走得更远，最佳的方案是让自己和团队一起成长，最好的是大家都拥有一个长远的目标，不能因为一些微小的波动而放任自己。同时，如果团队或个人急于求成，往往会导致失败，而坚持不懈的学习则是做科研和开展工作的不二法门。
诗人陆游曾经教育过他的后辈：“汝果欲学诗，功夫在诗外”。意思是说，如果你想真正地写出好的诗词，就要在生活上下功夫，去体验生活的酸甜苦辣，而不是抱着一本诗词歌赋来反复阅读。
如果看过天龙八部的人就知道，鸠摩智当时上少林寺去挑战，在少林高僧面前展示出自己所学的少林七十二绝技，诸多少林高僧无不大惊失色。而当时的虚竹在旁边观战，就对少林高僧们说：“鸠摩智所耍的招数虽然是少林绝技，但是本质上却是使用小无相功催动出来的。虽然招数相同，但是却用的道家的内力。”为什么少林的高僧们没有看出来鸠摩智武功的关键之处呢，那是因为少林高僧们在练功的时候，一直抱着武学秘籍在修炼，一辈子练到头了也就13门绝技。
其实从鸠摩智的个人修炼来看，修练武学的关键并不在武学秘籍里。没有找到关键的佛经，没有找到运功的法门，无论抱着武学秘籍修炼多少年，终究与别人有着本质上的差距。
笔者在 SNG 社交网络运营部的这两年多，用过推荐项目，做过安全项目，正在做运维项目，也算是部门内唯一一个（不知道是否准确）做过三种项目的人，使用过推荐系统，从零到一搭建过两个系统。目前笔者的个人兴趣集中在 AIOPS 这个场景下，因为笔者相信在业务运维这个传统领域，机器学习一定有着自己的用武之地。相信在不久的将来，AIOPS 将会在运维上面的各个场景落地，真正的走向咖啡运维。
