项目github地址:bitcarmanlee easy-algorithm-interview-and-practice
欢迎大家star,留言,一起学习进步
中午和一前同事一起用餐,发现还是有很多碰撞点的。交流了很多正在做的事情,
对方也提供了非常多的思想值得自己很好的思考。
先是和他聊了下我们现在做内容标签的进展,其实就是在做内容画像。我们一般都是在谈用户画像,其实内容也是要画像的。
我之前说,内容和用户是现在互联网企业核心的两个东西,用户的行为则将内容和用户连接了起来。
很多人一上来,撸起袖子就开始做用户画像,后面会发现,如果没有对内容做好分析,其实用户画像这个东西也会做不好。因为用户的行为是以内容为承载的,只有把内容画像做好了,才能进一步提升用户画像的品质。而要做内容画像,其实有两件事情要做的:
从多个维度刻画内容的,并且形成对应的标签体系
如何将这些标签打在内容上
另外在如何做的这件事情上,他也谈及了自己的看法,就是要求以Spark的Mlib为载体,尽量所有人共用一个算法平台。 我诧异的说,竟然和我的想法不谋而合。他说这样做的好处是大家信息共享会更快,同一个平台也更好维护。我进一步补充,其实如果每个人都有Google工程师的水准,其实倒也不用限制在一个平台上,但事实上如果每个人都坚持自己擅长的方式,其实隐形成本非常高。
比如,算法工程师写了一个巨牛逼的算法原型,然后他需要先给工程师讲懂这个算法,工程师看个人水平,先不说能否将算法实现,实现所花的时间,以及是否真的有时间和精力去帮着实现,实现的是不是有问题就是一个很大的问题了。来回一折腾,两个人都会比较累。当然,我前面也说了,如果都是Google工程师级别的,事情自然能更快。如果大家都使用spark 平台,这种交流成本小非常多。研发工程师只要将算法工程师已经写好的spark代码做些调整优化,估计就可以直接上线看效果了。所以我做的更极端一些,要求算法工程师用到的算法都必须是Spark Mlib现有的,或者有能力自己实现的,不能单机去Lib跑跑就行。
他还问我说,怎么才算对算法有了真正的理解。 这个问题真的把我问住了,我之前肯定会说,知道什么场景使用什么样的算法,就足够了。但是现在真的静下心来做,发现不是这么一回事。
我们先谈谈,怎么知道什么场景,使用什么算法。首先我们要知道具体场景能对应到一个什么类别的问题上。是一个聚类的问题?一个分类的问题?还是一个回归类问题?定义了类别之后再去找对应的算法。比如聚类可以使用KMeans,LDA,K近邻等,分类可以贝叶斯,SVM等。然而你会发现,其实还是太简单了。
一个场景要解决的一个问题往往不是这么直观明显的,就如同我们上面提到的构建内容画像的问题,就得到了两个子问题,每个子问题又需要划分成好多个步骤,每个步骤可能对应一个或者多个算法问题。
但是就算这样,也还是是远远不够。因为我们即使做到了具体知道该使用哪个算法,但是一用,发现效果完全不是那回事。这个时候我们至少需要了解两方面:
算法的核心是什么,有什么潜在的需求?比如是不是对数据的分布做了什么假设么?
特征和数据集的情况是如何的
而且很多算法做了很多很粗暴的假设,这种假设会导致算法存在一些固有的问题,如果你不了解其内部的这些假设,你会以为这些是他的一个特性,其实是一个缺点。比如Gini Importance,如果你不去了解的内部思想,你在理解数据时,就会造成误解,导致错误的认为先被选中的特征是很重要的,而其余的特征是不重要的,但实际上这些特征对响应变量的作用确实非常接近的。
做公式推导到底重不重要呢。 我们常常觉得那些对算法里的公式能做推导的人,很牛,能做到这点,自然值得鼓励和钦佩,但是我觉得算法和能不能推导公式是两码事。我可以把算法里的每个公式拎出来,找个数学系的人进行推导,它可能比较轻松的搞定。但是我们说他懂得这个算了么?他连算法是什么都不知道,对么? 所以从工程转过来的人,一定不要为此觉得有什么障碍,其实我们可以忽略公式的本身推导过程。
我有时候觉得,引用算法工程师最流行的一个话,就是tricky。 中文我不知道怎么翻译更合适,很多时候是需要悟性和对事物本质的了解,才能了解一个算法的,绝对不是靠几个公式就能搞定的。
协同算法是我们应用的比较广泛的一个算法。 但是我觉得协同不应该算是一个算法,而是一种模式。 我们常见的很多模型,最后都是协同模式。举个例子来说,是不是个A1用户推荐文章B1,我们可能是这么做的:
把用户用向量做表征,文章也是
观察大量的用户A2,A3…AN 是不是有点击该B1
使用逻辑回归/SVM等分类算法训练模型
把A1,B1丢进模型,得到是否推荐。
但事实上这套算法,用的就是协同。为啥的?本质上还是相近的用户做的选择互相推荐。