你「构建」的啥?

工程师眼里,所有事情都是工程。也是为什么会有 social engineer、social hack……

工程师的主要工作是:应用科学+构建可用之物。

依照这个前提,所有人无非是三个级别的工程师 – 构建的对象不同:

1. 物

最常见的工程师,也就是一般意义上的工程师,越牛的工程师能够构建的物品越复杂。比如软件系统、汽车、建筑。

2. 人

比较常见的就是老师了,但其实大多数的领导者,只要团队超过1个人,就算。领导的人越多越牛,当然前提是能够产出。

3. 想象

也就是真正意义上的大师、哲学家,提出一整套的体系,至于是不是由他来构建,不重要。有时候,没构建出来反而更受大家追捧。

瞎扯~

选择基于用户(user-based)还是基于物品(item-based)的过滤?

“推荐”的本质是 – 为a推荐b,a是主体(或者在一个协同过滤系统中叫user),b是客体(在协同过滤系统中叫item)
而学习的来源是已有数据中 user对item的选择(协同过滤)
user-based和item-based只是两个方向,简单来说:
user-based是“人以群分”,item-based是“物以类聚”。
如果某几个user经常选择相似的item,或者说某几个user对某个item的评价(“品味”)是相似的。那么当另一个user表现出相似的品味时,推荐给他那些根据品味聚集起来的其他user所选择的item。也就是所谓的“人以群分”,这是user-based。
优点:比较容易实现,适合规模较小但变化频繁的数据集,比如音乐推荐和分享类网站。这样网站的用户更愿意了解和自己”臭味相投“的人。
如果预先算出item之间的相似度,然后根据user对其中一个的选择来推荐其他的相似item给他,就是item-based。也就是”物以类聚“
优点:不需要随时计算,可以预先或者通过后台增量去计算。关键在于物品间的比较不会像”用户选择“的比较那么频繁变化。(比如购物网站,或者item非常多)
在实践中,无论是user-based还是item-based都在于搞清楚哪个是user哪个是item。
那么举个例子,如果是”发掘潜在的付费用户“这个主题,到底是user-based还是item-based呢?
(以下只是分析,未必是标准答案)
首先,这个表达不是很明确,潜在的付费用户是如何定义的?
是购买相似产品的用户?
是购买过产品的用户?
是第一次购买吗?如果用户有第二次购买行为需要发掘吗?
个人觉得“发掘潜在的购买行为”更准确一些。
还有一个因素要考虑,产品的种类有多少,如果像淘宝/amazon那样有数以十万计的商品,显然应该是item-based。但是如果是很少部分(比如1%)的用户购买几个产品。反倒是user-based也比较合适(甚至人工介入)。
但是注意,“您购买了a我推荐您购买b”。此时a和b应该避免是同一个类别,当然,如果推荐结果里出现过多的“同类推荐”,说明算法有问题。用户已经购买了,貌似已经不是”发掘潜在”了。
其实这里还是应该使用“item-based” – 先把所有的用户进行聚类,然后发掘和付费用户相似的的用户。发掘潜在的付费行为也就有了着落。此时最大的问题是聚类属性的选择。
所以,无论是user-based还是item-based,都要看问题的本质是什么,如果没有正确理解问题本质,要么逻辑很复杂,要么效果差。