JustKiddings的一隅天地

由 liu yaping 撰写 　http://www.justkiddings.com/?p=4

最近做了一个知识问答产品中的label system设计，发现了一些关于label有意思的问题，基本上是设计一个label system 必须面对的问题。不过老实说，这个问题我还没想清楚，还需要花很多时间继续思考。
Motive
在问答产品中的提问流程，用户会把填写label视为提问过程中的一个阻碍。后来在科学家不断努力下，我们进入高科技时代，系统可以自动分析问题内容来推荐label，于是我们推荐几个label让用户简单去勾选，即使是这样，用户也还是懒得去点那个check box，究其原因，只是因为我们实在是找不出什么理由用户应该做这个事情。最终变成了我们默认就勾选一些 label，用户不需要做任何事情。
所有需要用户填写label的设计，都是给用户增加了一个额外的任务。我们必须明确的告诉用户，填写label对他有什么好处，不然他根本不会去填，这样会导致你基于这个label system 的设计全部变成空中楼阁。看到很多其他产品的设计中，甚至还有是否同意某个label的功能，这里也要问同样的问题：用户的动机是什么？
这个问题一直还没有很好的解决方案，目前我看到的做的不错的是Flickr，他的做法是填写标签这个额外的任务和管理照片这个方便的功能结合在一起，我还需要和flickr的重度用户聊聊，了解下给自己每个照片都加label的geek用户的心态。
Longtail
假设我们已经很好的解决了上面的问题，积累了相当多的label数据，第二个问题就来了。在问答中，系统创建的标签有700个左右，覆盖了绝大多数问题，但是UGC的标签大约有30万个，非常强烈的longtail。来吧，豆瓣也基本上是同样的状况。
怎么办？
一种简单的做法是，我们不断引导用户，让他们 “选择” 而不是 “创造” 标签，问答的30万个标签，大部分也都是用户在我们的系统还没有标签推荐机制时产生的，假如我们只有700个系统标签，那么就要简单很多了。体现在设计上，我们可以找人来创建最常用的几百个标签，保证longtail的头部质量足够好，然后尽可能的推荐这些标签，让用户感觉我们推荐的就挺合适，只需要简单选择就好了，这样不仅能降低交互复杂度，而且也尽可能的避免longtail .
当然longtail 也不总是坏事，豆瓣就很好的利用了longtail，但是难度比较大，不知道我们是不是可以学习下？一个最直接的设想是假设有一个很小众的label，如“闷骚”，一共只有十首歌，你听过其中五首，那么给你推荐剩下的五首，基本上是准确的。这个在Google music之前的某些项目中已经有一些探索和思考。
Machine Generated or User Generated？
其实上面谈论motive的时候已经提到过，我们的问答产品已经实现了完全的算法系统推荐label 给用户，不需要用户做任何事情的，但是就算Google的科学家们多么聪明，开发出来的算法仍然是不够智能，我们的系统推荐的label 精确度不高，为了保险起见，把推荐的label不够细分，而是很宽泛的 “科学” “生活” 等等，这样子的话，推荐的label不仅不够精准，而且数量很少，出现了每个label下几万个条目的情况，这样也就失去了label system的意义了。那么人肉推荐如何？好处当然是精准了，不过整个系统的成本会按照指数级别增加，这一点在Google 非常明显，况且人肉推荐的话，整个系统非常不scalable。
和刘云天（xiaoxiao）同学讨论之后，提出一种可能性，我们可以首先提取搜索系统的热门关键字，从中人工筛选取出靠谱的作为label，然后由系统推荐，让用户从中选取label 加给每一个条目，这样比较好的结合了用户产生内容和机器产生内容的优点。