Hunch:自动问答和决策机

有这么一个网站,蛮有意思的:Hunch 。

zhengyun@ju690 20100308 综合网络资料汇编而成:

有趣在于成功地利用了群体智慧


『第一步,在Hunch这个网站,不必做什么事,它就是一直问网友问题,然后网友一直解答。
在每个解答之后,Hunch就告诉你,有百分之多少的人和你回答一样的结果,用这个方式来引诱你回答更多的问题。回答之后,Hunch就更认识你,也收集更多「像你这样的人」的喜好与决定。这些喜好与决定,告诉很多其他的事。』
『第二步,变成你可以从Hunch找到答案。它不必干什么事,只要把「你」和其他和类似你的人的答案相比对,就大概知道你「应该」会怎么回答其他的问题,全世界上的问题,Hunch都可以代你回答了。
它的智慧来自于众人,而众人的智慧绝对比一个人还大。』(from mr6


可以认为这是一个理想的自动问答机器,利用协同过滤原理和语义技术,同时又有人工编辑审核问题和答案保证机器学习的质量。

跑题一下:Akinator

去年年初特火的Akinator也是一个决策机游戏,它让你心中默想一个东西,然后通过问你几个问题,最终猜出这个东西是谁。

同事评价道:『

很明显是用决策树就可以完成的,而且非常有可能是用的决策树,因为他的问题答案都是离散值的,这个比较适合决策树来搞。
另外一个证明:你先后猜测毛主席,江***,邓总设计师,会发现他提问顺序基本类似,这也说明很可能是决策树,越是相似的人物其走的路径分支越相像,从这点看很像决策树。
完全可以搞个中文的这个游戏,做起来其实很简单。首先列出一个属性列表(性别,活着否,演艺人士否,etc),然后根据人名填写属性(相当于训练过程),比如:  谁谁谁 男性 去世了 非演艺人士 政治人物 国家元首......
然后构建一个决策树就可以work啦。

回到Hunch

Hunch最后如何帮你决策?『举个例子,你不知道应不应该搬去和你女友一起住吗? Hunch就会再问你,「你们一起约会多久了?」「如果你们关系变差了,你还有钱可以搬出去住吗?」你回答这些问题后,Hunch应该就会去资料库找,看看有谁回答过这些问题,当时应该也有问他们「最后的决定」,如果你是属于A型,那最后的决定是不要搬进去,Hunch就会建议你:「不要搬进去」。』(from mr6

之所以能做到广泛领域内(理性的、感性的)的自动问答,它的第一个基础是:
『Hunch在开站前,只找来4万名回答者,这个数字没了不起,了不起的是,这4万名使用者,竟然已经回答了总共700万个问题,平均每个使用者回答了175个问题!』(from mr6)这得多大的家业才能办到啊。也就是大学研究机构利用校园资源可以轻松积累到。
第二个基础是产品设计得引你不断地回答问题,并主动安排好训练材料。

有了大数据量虽未必都精准的回答和知识结构,Hunch便有了运算的基础,更进一步,引导你一步一步走向决定,一个很棒的「Decision Engine」就这么work了。


参考资源:
1、Hunch收集全球智慧帮人解答问题,并有平均每人浏览175页之潜力?
2、Hunch Launches Monday - But It Already Knows All About You
3、Hunch: A Cure for Indecision?

4、

Linkc在Resys写道:

hunch的前身是MIT 的一个机器学习项目,旨在收集知识与经验,并将之充分加以利用。在使用hunch的这段时间里,我对他独特的协作机制很感兴趣。

功能

hunch可操作的单元有topic,question,result,目的是让用户通过回答question,找到某些 result。与wikipedia类似,hunch也分为贡献用户和浏览用户。贡献用户写一个topic,topic是整个网站的组织核心,以一个疑问句的形式表现。
如Which city should I visit in China ? 并且在这个topic下写几个question和result,最后建立二者之间的关系。这样,当某个用户想来中国旅行,面对数百个城市茫然失措时,就可以计入这个topic,点几下鼠标,回答几个问题,系统就会推荐一些result。

协作

当一个topic发布后,除了问题本身只有贡献者可以编辑外,任何用户都可以为topic贡献question和result,并且,用户浏览和回答的历史也会被记录在案,作为训练算法的数据(这个下面具体说)。与wiki和Q&A类的应用不同,hunch的操作被简化到了极致。result的摘要会自动从wikipedia里面取,图标自动在网上搜索,轻点几下鼠标,一个完美的topic就完成了。where should I go in
Beijing? 是我今早发布的,用了大概半小时,包含5个question和31个result。

上面提到,用户还可以完善topic。如修正result对应的answer,顶或踩某个result,这些动作都被视作用户的贡献,在我们看来微不足道,但积累到一定量级,就能凸显出统计学和社会学上的意义。

算法(这里说得不准确)

hunch有两层算法。首先是"自问自答"的机制带来了格式化的数据。topic用来定位用户兴趣,几种question和answer的组合筛选出适合的result。

贡献者可以定义某个result对应question里面的哪个(或哪几个)answer,当用户选择了不同的answer后,就会按一定算法对result进行排序。比如这个where should I go in Beijing?,我回答想来北京看古迹,我对古建筑感兴趣而且不想出城,系统就会推荐给我故宫,前门和国子监。但是简单的算法只能筛选出所有可能的result,并不能保证排序是最优的。这样就引出了第二层算法,数理统计模型。和豆瓣的评分、SE的点击调权类似,当用户回答完毕,将有机会为各个result投票,这样通过统计方法,对结果进行排序,不断训练程序。

运营

hunch遵循"宁缺勿滥"的运营方式,一个topic刚刚被创建是不会被公开发布的,只会放到作者的 workplace里面。只有topic下有一定数量的question和result,并且被足够多的用户"训练"过后,才会发布到公共频道。编辑的审核也非常严格,我写了一个"如何挑选NDS游戏"的topic,被编辑删除了,建议我合并到"电子游戏选购"这个topic下。可见,hunch希望每一个topic都是有用的,鼓励用户不断完善内容。

hunch的徽章系统很有特色,分别是里程碑,特殊角色,训练相关,个性化。具体请参考

    * 里程碑:的到100、500、1000、5000......个积分。
    * 特殊角色:建筑师、发明家、哲学家、批评家......以评价为评判对象。
    * 训练相关:教师、讲师、演讲者、教授,以训练数据为评判对象,鼓励用户训练程序算法。
    * 个性化:为浏览用户而设。

细节

完成一个topic的全过程都是ajax形式进行的,体验很流畅,让贡献内容变得很轻松。为了确保数据质量,hunch还有很多小细节值得借鉴。如,某topic有一个result叫summer palace,我不小心再一次输入summer palace,系统提示我"有一个相同的result",改为输入"old summer palace",提示我"您的意思是不是summer palace?"。还有很多类似的小细节,大家可以亲身体验一下。

Linkc继续在Resys写道:

hunch的用户协作分为两块,一块是topic的构建和result的选定,这部分对用户来说成本还是挺高的,如其中必要的一部是让用户为
result添加描述,hunch可以直接调用wikipedia的内容,但在国内还没有一家能够提供丰富且结构适合的内容(互动百科和百度百科都不行),协作的人数可能也就是5%。

另一块是让用户回答几个问题,然后给出答案,对于大多数用户来说还是可行的。

在国内推出这样的服务有几条路可走:
1、走细分,电影(豆瓣),音乐(豆瓣或taste),其实都可以算是某种决策引擎;
2、运营上调整一下,每天只推出三个问题,先由编辑引导完善,通过这种方式积累内容,宁缺勿滥,让用户"10%贡献,30%分享,60%发现";
3、走娱乐路线,类似于http://en.akinator.com/ 和20Q,但到最后也只是个小游戏

个人比较倾向于第二种路线,初始的用户团队和内容质量把控好了,还是能有所作为的。

盈利方面有几种:
1、决策结果中加广告,告诉用户,"这个是广告,但也是一种选择";
2、专题topic合作,如topic"聚德华天:北京入夏吃什么最好?",得到的结果都会对应一个餐馆的广告;
3、显示相关问答结果,与百度知道等Q&A网站合作,在result页面展示相关的问答结果。感觉百度知道做这个比较好,用户契合,有忠实用户,不差人,不差钱。

 

hunch改版了。

首先,result不是一系列问题回答完了再出现的,而是随着问题变化,这样做提高了用户评论result的概率(也有可能是因为很多用户没有耐心回答完所有问题而做的妥协)
其次,社区元素加入了很多,在profile页面强化了好友关系和状态,同时推出service,开始支持第三方社区。

当前的 hunch像一个用问题和答案串联起来的大社区,根据之前对问答网站的调研(样本数500),大概40%的问题是寻求抉择(该买哪款相机),20%是open question(如心情不好怎么办?),40%是需要大段语言描述的答案。

如果把hunch复制过来,做好产品本地化,让国内市场接受,还是很有前景的。

5、Resys小组的讨论贴

posted @ 2010-03-08 16:20  旁观者  阅读(3912)  评论(0编辑  收藏  举报