智能语义聚合框架:像人类一样收集和理解知识

郑昀 20071129

智能语义聚合框架并不是什么领域都适用的,能够进入的垂直领域特点:

  • 信息源:网络资讯足够丰富,碎片多且分散;
  • 用户需求:受众越来越依赖于网络碎片形成自己的意见;
  • 商业需求:容易建立商业模式或电子商务的领域。

也就是说,很多网络口碑公司,只是要么点评、要么点评搬家、或者拿出点儿商业报告、或者论坛营销把戏,但离真正理解人们在说什么还远得很。其实语义应用上有好多事情很好玩的,并不是只能像玩聚网搞得像techmeme一样热点自动发现,毕竟玩聚的热点故事还不能真正理解故事的本意;像大旗网的口碑榜还只是玩文本的情感倾向计算,但它也没有理解一个帖子为何说产品不好、不好在哪里、为何要买这个产品等等。

现在的搜索理解人们在说什么吗?

也是不知道的。

它们可能知道你提到了哪些关键词,哪些词更重要,但它不会像人类一样去看到网页内容形成知识,现有的搜索只能叫做“together”而已。

智能语义聚合框架可以。我们目前正在做的事情就是在证券市场上试图充分体现这个框架的优越性,挖掘一些本来只有人才能干的价值;在这个层面上,酷讯或者爱帮网的生活搜索只能算是“精确信息提取”和“灵巧组织”而已。

 

那么什么是像人类一样的收集和理解知识呢?

我们举一个雅虎全能搜索的例子。

雅虎的这个人际关系图后来也被谷歌在天涯来吧里复制:http://www.yahoo.cn/s?v=person&p=%E6%96%B9%E8%88%9F%E5%AD%90,方舟子的人际网络关系图。我们前几个月也抽了点时间玩了一把,首先收集所有各种明星的新闻资料,然后训练机器理解人类之间可能存在的关系有哪些,接着按实体名(你可以理解为人名)与实体名之间的距离远近以及关系词去统计实体与实体之间存在哪些潜在关系,最后反转和理顺关系、归纳即可。这里面的难点就在于实体与实体的关系并不一定简单的通过“XXX的XXX”这种简单句式来表达,汉语千变万化,新闻资讯阐述的往往是一个事件,你要给机器足够的训练,它才能理解足够多的关系。

这种模式的理解知识,就很象人(或小孩子学习)的思维了。这只是一个简单的例子。

 

小结:

智能语义聚合框架,是什么,第一步,选择好垂直方向;第二步,把知识碎片together起来,碎片包括blog、news、forum、microblog、live room等等;第三步,文本挖掘和统计;第四步,展现价值。

一般来说,计算语言学和自然语言信息处理研究的核心问题是语言的自动理解(Language Understanding)和自动生成(Language Generation)。智能语义聚合框架还属于前者的世俗应用。前者从句子表层的词语符号串识别句子的句法结构,判断成分之间的语义关系,最终弄清句子表达的意思。这个事情学术界搞了很久了,但要想隐藏掉背后的复杂技术,变成一个通用的应用需求,还是需要从实际生活中来,观察人类日常行为也许是个好办法。语义搜索或者语义网这高深的东西,我真的担心只有Geek才有的需求,让无数人竞折腰啊。

  

我的其他文章:

11/27/2007  话题营销在选择自由的当下只能是制造垃圾和垃圾流量
11/23/2007  爱帮网“搜索+社区”就地展开
11/01/2007  【乱讲】互联网人的“迷信”
11/06/2007 互联网大鳄的"打"、"着实打"、"用心打" 

11/06/2007  GPS导航服务的视野应该放远些

10/29/2007 【帮帮】移动互联网的“浑水”

10/22/2007 i机器人,MSNNEXT,MSNSHELL的周末聚会【帮帮俱乐部】

10/16/2007   Web2.0的信息组织需要引入语义的新思路

 

玩聚热点频道:

玩聚 民生 频道

 

玩聚 体育 频道

 

玩聚 娱乐 频道

 

玩聚 锐评 频道

 

玩聚 商业 频道

 

玩聚 科技 频道

 

玩聚 两性 频道

     
 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1908188

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结