中午和一前同事一起用餐，发现还是有很多碰撞点的。交流了很多正在做的事情，
对方也提供了非常多的思想值得自己很好的思考。
先是和他聊了下我们现在做内容标签的进展，其实就是在做内容画像。我们一般都是在谈用户画像，其实内容也是要画像的。
我之前说，内容和用户是现在互联网企业核心的两个东西，用户的行为则将内容和用户连接了起来。
很多人一上来，撸起袖子就开始做用户画像，后面会发现，如果没有对内容做好分析，其实用户画像这个东西也会做不好。因为用户的行为是以内容为承载的，只有把内容画像做好了，才能进一步提升用户画像的品质。而要做内容画像，其实有两件事情要做的：
- 从多个维度刻画内容的，并且形成对应的标签体系
- 如何将这些标签打在内容上
** 另外在如何做的这件事情上，他也谈及了自己的看法，就是要求以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丢进模型，得到是否推荐。
但事实上这套算法，用的就是协同。为啥的？本质上还是相近的用户做的选择互相推荐。
