需求满足综述

一、什么是需求满足1.1 什么是需求满足

用户来搜索“章鱼 保罗”,就文本相关性而言,搜索引擎只要返回和“章鱼 保罗”内容相关的结果就可以了,这样用户是否满意呢?

用户甲:听说章鱼帝挂了,来看看最新结果,怎么全是8月份的,往后翻页中…

用户乙:今天同事们在讨论章鱼哥挂了,章鱼哥是啥?我又out了,来搜索一下章鱼帝生平事迹是啥,怎么全是最新的结果,没有章鱼哥的介绍啊,变换个query看看

用户丙:我是铁杆球迷,看完章鱼哥,再看看足球相关的吧,鲁尼,杰拉德是否又进球了,怎么连个相关推荐都没有,还得我亲自输入。

用户丁:找个章鱼哥的头像用一下吧,一定很拉风,怎么全是结果没有方图呢,这么扁的图怎么用啊

用户戊:换个章鱼哥的壁纸,也许下次买彩票能发大财,咦,怎么全是小尺寸的图…

(以上信息通过分析2010-10-27用户session得出。)

笼统的说,用户向搜索引擎表达他的需求,搜索引擎理解用户需求,提供各不同的需求下的资源,这整个过程可统称为需求满足。简单说,就是除了基础文字相关性之外的rank工作,都属于需求满足的范畴,也就是说,提供给用户的检索结果,不仅仅要求在字面上是和用户输入的文字相关的,还要满足用户的各种不同需求。

需求满足在rank体系中所处的位置:

1.2 为什么需要需求满足

用户通过query表达了自己的需求,而对于大部分query来说,尤其是具有隐含需求的query,仅仅字面匹配的查询结果未必能够满足其需求。目前我们的排序系统是主要是基于文本相关性这个维度的,权值体现了query中的term与obj的相关程度,在这个体系下,相关的结果未必能够满足用户需求。

例如前面提到的“章鱼 保罗”的例子,显然,这些需求在文本相关性这个维度下很难解决,尤其涉及到突发时效性需求,泛需求等。

1.3 需求满足包含哪些工作

从上面的例子中,可以看出,需求满足需要解决时效性需求问题,多需求问题,相关推荐,size需求,素材类需求,浏览引导等问题。除了基础文本相关性以外的rank策略以及为了这些所做的query分析工作可认为属于需求满足的工作,另外还包括前端结果展现与用户引导浏览的工作。

Image需求满足,按照不同的维度,可以划分为如下几个方面:

需求识别资源建设需求调权结果组织与推荐用户引导交互
二、需求满足如何做需求满足要解决的核心问题:

需求识别

资源建设

需求调权

2.1 需求的识别2.1.1 需求的类型

识别query有哪些需求,以及需求的强弱,是最基础的工作。首先要有需求的体系,能完备的描述各种需求,其次是如何识别这些需求,把每个query的需求对应到这个体系中去。

通过query分类识别需求:

现在线上query分类体系,是按照话题属性为依据来建立的。包括风景类,地名类,人物类,汽车类等等,对于每个类别,在一些维度上的需求是不一样的,比如风景类需要尺寸比较大,比较清晰,不包含人的图片,而聊天类则需要尺寸较小,最好是动态的gif图。

这个策略下的项目有:size调权,格式调权,人脸需求,人与非人等。

基于统计的需求识别

通过对大量的数据统计分析,可以识别出query有哪些方面的共性。可供分析的数据很多,比如用户行为数据,点击反馈,检索结果等。

比如:对query的检索结果,按照某一feature进行聚类,如果某个类别所包含的图片数很多,超过设定阈值时,则认为这个类别内的图片,在这个feature上,代表了这个query的需求。线上人脸需求识别就是这样来做的。

统计用户反馈来获取需求是最能反映用户需求的方式,用户的反馈包括用户点击,query变换等,在这方面我们做的工作不多,经验也不多,是我们后续工作的重点。

专名&需求词

判断query中包含专名或者需求词等关键词,是最直接的方式。比如“红色宝马”,显示的表达了颜色方面的需求。

时效性需求

时效性需求包括三部分,突发时效性、周期时效性和泛时效性需求,目前线上做的是突发时效性需求。需求的识别,主要是通过检索量的突发,资源数突发和实效性事件来判断的。

检索量的突发,是指累积每个小时的用户检索频率,用连续15天的用户检索频率,计算突发的斜率,根据斜率的大小,来判断时效性需求的强弱。

上述方法只适合热门query,对于长尾query,检索频率很低,无法通过这种方式识别出来,一般这种query是多term的query,可以通过是否命中关键词来判断:

通过事件判断:这种方式,主要是想看关键term命中时效性事件的比例。当然这些事件是通过主动挖掘的时效性query,通过聚类后,对每个类别训练出来的关键词。

2.1.2 需求的强弱

要做好需求满足,不仅要识别query有哪一类型的需求,而且要识别该类型需求的强弱,他直接指导了后续需求调权的力度。

每个维度的需求,必须要有需求的强度,在各维度调权合并时,需求的强度决定了该维度的权值。比如时效性需求,需求的强度很高,要求满足时效性的资源,一定要排在前面。又比如清晰度 饱和度调权,对大部分query而言,需求不是很强烈,调权时的力度就不能太大。

需求强弱的计算,和后面rank model的要求相关,理想的状态是每个query,可以动态的计算在每个维度上的需求强弱,我们在这方面经验不多,如果暂时不能做到准确的计算的话,暂时可以考虑人工指定的方式,比如针对不同的query分类,人工设定需求维度的强度。目前可以想到的一些方式:

显式的需求为强需求

用户通过在query中包含需求词的方式,表达自己的需求,这样的为强需求。

比如,最新刘德华图片,红色宝马

基于统计的方式挖掘需求时,判定值超出阈值的比例大小,决定需求的强弱

在用统计挖掘用户需求的方法时,一般会选取某个维度的属性,量化后计算它的统计特性,可以根据统计后该数值的分布情况,判断需求的强弱。比如,时效性需求,某段时间内,该query检索量突发特别大,是昨天检索量的100倍,如果我们设定的阈值是2倍的话,那么这个query就可认为时效性需求特别强。

又比如通过用户点击数据挖掘size需求,对于头像类的query,大部分用户点击的是100*100的方图,但是所占总点击中的比例不是很高,比如只到60%,那么对这个query而言,size需求是一般强度的需求。

2.2 需求的满足

识别出query有哪些需求,下一步的工作就是提供相应的资源。

2.2.1 资源的挖掘

如何获得满足需求的资源,是需求满足的另一个核心问题。在资源上,通过某一个或者几个特征组合,能够把满足要求的资源和不满足要求的资源区分开,找到用户需求需要的资源,去掉不满足要求的资源,是主要的工作。

内容属性特征

对内容属性维度来说,可以分为底层的物理特征,中层的物体识别和高层的语义特征;对于底层的物理特征,相对比较简单,我们现在可以利用的,包括尺寸,颜色,格式,清晰度饱和度等,中层特征,我们目前用到的不多,有人与非人的,色情图片的,整车的识别,手机图片的识别等;对于高层的语义特征,包括场景的识别,图片风格的识别,是我们未来发展的方向。

话题属性维度

类似的query分类的体系,也可以对资源进行相似的话题属性分类,我们目前只做了站点级别的分类,效果不是很理想,主要原因一是站点粒度太粗了,二是站点分类的召回存在很大的问题。

我们希望能做到obj级别粒度的分类,至少是页面级别的分类。如果有了话题属性的分类,和query需求的分类相配合,可以达到事半功倍的效果。

时效性资源的收录

我们目前时效性资源主要是挖掘的ps的时效性库,和news的资源,和非时效性资源的区分是比较容易的。

2.2.2 需求调权

明确了query的需求,挖掘了满足需求的资源,那么如何把满足需求的资源rank到前端呢?

对于各种不同的需求维度,都有自己的调权的策略。比如格式调权,假设query有gif图需求,对于gif的动态图,权值乘了1.2,对于静态图要降权,权值乘了0.1。又比如时效性需求,直接在前三页插入的时效性库的结果,这是因为时效性需求是一个强需求维度,简单的加权,不能保证结果调整到前三页。从这些例子中可以看出,目前需求调权的策略就是2种类型:在总权值上调权,在最后排序结果上调序。

目前这种策略直接叠加的调权方式,优点是简单,直接,缺点也比较多,最大的是不可控,一个维度上的调权,会对最后结果造成多大的影响,在多个调权维度上,他说的话,分量有多大,不知道。

未来的需求调权,首先应该把资源满足需求的情况,做出细化的分档,做到有直观的物理含义,其次,根据该维度需求的强弱,把这个维度的打分反映到最终结果中去,究竟是跨档调权还是档内微调,比如:

强需求:符合要求的结果直接调到最高档,比如时效性需求

一般需求:符合要求的结果,可以根据一定规则,提高自身档位

弱需求:不能提升档位,在同一档内,做权值调整

2.3 需求满足的效果

前面已经完成了query需求识别,资源识别已经需求调权的工作,那么用户是否满足了呢?搜索引擎最终是给用户服务的,用户觉得爽,才是最重要的目标。那么如何知道用户是否满意呢?

用户接收到搜索引擎的提供的信息后,会对这些信息做出反馈。这些反馈包括了用户对搜索结果的点击、对query的主动变换,以及这些行为之后的相关行为。通过对这些数据的分析,可以知道用户的满意度。

比如对需求识别的修正,通过用户点击反馈,可以知道query需求识别的是否正确,该需求是否该退场。比如时效性需求,被误判的query或者应该退场的query,都可以通过用户的反馈,来判定是否应该退场。

当然,这种方式是否合理还有待调研,毕竟用户不点击一张图的原因有很多可能,有可能是需求识别的问题,有可能是该维度强弱识别的问题,也有可能是rank的问题。目前用户反馈应用只有点击调权,是否用户的反馈可以在单独的维度上有效,还需要详细的调研分析。

另外,随着时间的推移,query的需求是在不断变化的,通过用户的反馈,可以做出及时的调整。

三、需求满足的展望3.1 需求满足体系框架的建立

之前做了很多需求满足的工作,颜色,格式,尺寸,人脸,表情,头像等等,分别是case by case来做的,其实他们之间存在着很多相似的地方。从调研过程来看,可以分为需求识别、资源满足和需求调权三大部分。

这样分散的各个点去做,有很多弊端,一是调研重复,效率低;二是前端调权系统像打补丁一样,越来越乱,没有形成清晰的体系框架。三是容易造成调权重复。

目前比较好的思路是建立需求满足的体系框架,包括前端的需求分析和后端需求调权。前端分析清楚query包含哪些需求,以及每个需求的强弱,把这些信息传递给后端;后端首先要有各个需求所对应的资源,然后结合上面提到的需求调权,给每个obj一个合适的档位和权值。

以后再做需求满足类项目时,只需要调整前端的需求识别即可,如果没有新增的需求维度,后端的资源和需求调权,都可以不用改动。

3.2 更智能的需求识别

1. 分析用户行为数据挖掘需求

用户在搜索过程中,能够被我们记录下来的一切行为,比如点击,翻页,query变换,停留时间,去向,来源等等,利用好这些数据,就能更好地理解用户的意图。目前在这方面的应用还只有点击调权,需要挖掘方面的应用还很少,是我们未来工作的重点方向。

2. 个性化需求挖掘

通过分析session,可以获取个性化的用户个体需求。目前我们结果的展示的好坏,主要是通过分析session,来判断用户的需求,而对于高频query,展示的结果是大规模用户的行为统计,得出的一个普适的模型,这个模型由于是统计出的,因此具有客观性,可能会伤害一部分个性用户。

3. 需求强度的识别

每个维度的需求,必须要有需求的强烈度,在各维度调权合并时,需求的强度决定了该维度的权值,比如时效性需求,需求的强度很高,要求满足时效性的资源,一定要排在前面。又比如清晰度 饱和度调权,对大部分query而言,需求不是很强烈,调权时的力度就不能太大。

3.3 资源建设

目前我们在query分类,query需求识别,query分析方面做了大量的工作,相比较而言,资源方面的建设,我们做的工作比较少,接下来希望推动obj级别的资源分类,内容属性上的几个资源分类:图标资源识别,地图资源识别,卡通动漫图的识别,以及一些截图的识别。

3.4 需求引导

Image是浏览型为主的产品,如何引导用户更加方便的浏览,是未来工作的重点之一。

我们已经尝试了明星结果页的query分类展示,未来我们希望能对更多类别的query,做主动引导。引用pm对主题式query的定义:“主题式”Query是指:Query指代的人、事、物中包含有多方面内容,具体表现为Query对应目前的检索结果中存在明显的多方面内容的混杂情况。其实就是指泛需求、多需求的query。

对于这种泛需求query的结果的展示样式,这种分tab多结果页的形式也未必是最优的,如何更好的发挥作用,需要更加深入的调研和创新的思路。

另外,还包括对rs展示优化,动态摘要的显示和套图展现等方面的持续升级。

四、结语

Image需求满足方向才刚刚起步,未来要向智能化,自动化,多样化方向持续的发展。我们最终的目标是把需求满足这个方向做没了,需求挖掘,资源满足全部自动化,做到“手中无剑 心中有剑”。

源地址:http://stblog.baidu-tech.com/?p=404

时间: 2024-09-20 09:02:32

需求满足综述的相关文章

如何进行需求的挖掘

需求满足综述 一.什么是需求满足 1.1 什么是需求满足 用户来搜索"章鱼 保罗",就文本相关性而言,搜索引擎只要返回和"章鱼 保罗"内容相关的结果就可以了,这样用户是否满意呢?用户甲:听说章鱼帝挂了,来看看最新结果,怎么全是8月份的,往后翻页中-用户乙:今天同事们在讨论章鱼哥挂了,章鱼哥是啥?我又out了,来搜索一下章鱼帝生平事迹是啥,怎么全是最新的结果,没有章鱼哥的介绍啊,变换个query看看用户丙:我是铁杆球迷,看完章鱼哥,再看看足球相关的吧,鲁尼,杰拉德是否

页游站点综述:仍然有需求但亟待引导

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 在游戏业这块大蛋糕里,太多的人想进来分的一碗羹,大家都是面面相觑,怵惕各自的软肋.所以风云翻转,岁月穿行,如今,游戏业主要形成了三足鼎力的局面,客户端网游(简称网游).手机游戏(简称手游)和网页游戏(简称页游)三大巨头.页游介于两者之间,他的优势不收时间和空间的限制,适合短暂的休息娱乐下,网页未来依然有着很大的发展空间.因为只要通过浏览器去搜

需求变更管理综述

需求变更是软件项目一个突出的特点,也是软件项目最为普遍的一个特点.虽然这与人类认识问题的自然规律是一致的,但是频繁而无管理的需求变更非常容易导致复杂.无形的软件在多变的情况下失控,加剧了软件开发过程中的不稳定性,从而造成多方的损失.那么如何对需求变更加以有效的控制和管理,从而保证软件开发的进度.成本和质量,便成为软件开发过程中一个值得思考的问题. 下面,我们将"需求变更管理"作为一个"项目",按照问题定义.需求分析.设计.开发等步骤,从软件工程的角度来加以分析,而这

时态数据库综述

数据|数据库  时态数据库综述   摘要:本文是时态数据库的一个综述,概要的介绍时态数据库的产生背景,研究动向,然后介绍了时态数据库的分类和现有的比较典型的模型,最后介绍了时态管理和时态数据库设计方面的问题.   l         背景 传统的数据库技术能反映现实世界中的数据,但是它仅仅能体现现实世界中数据的当前状态,只反应了一个对象在某一个时刻的状态(快照),不联系其过去和未来.这就是人们常说得快照数据库(Snapshot Database).现代的信息流包含事件的时态信息(Temporal

ESB综述2:ESB使用案例

我们以维基百科基础的(ESB)开始我们的讨论. 看起来,共识之一是ESB是与编制(orchestration)和业务过程管理(Business Process Management)截然不同的单独一类产品.此外,对于ESB到底是产品还是模式还有很大的争议. 在本系列的第二部分,InfoQ调查了ESB的使用目的 - ESB的使用案例和需求是什么? Sonic公司的开启前文中的讨论,暗示了Sonic软件公司可能事实上正试图标准化基于UML的模式集,实质上,它们定义了ESB的参考架构. (BEA系统策

ITTC数据挖掘平台介绍(综述)——平台简介

数据挖掘方兴未艾,大量新事物层出不穷.本系列将介绍我们自主设计的数据挖掘软件平台.与大家共同分享对知识,微博,人际等复杂网络的分析,以及对自然语言处理的见解. 一.我们需要怎样的数据挖掘系统       一直以来,以高校为代表的学术界和以公司为代表的商业界,都有很大的隔阂.学术界普遍不会做产品,商业界普遍不会搞研究.如果两者都强,那就是美国军方了.        在数据挖掘领域更是如此,大量关于复杂网络,自然语言处理的牛文层出不穷,却被研究机构和大公司养在深闺人未识.绝大多数智能机器学习算法被封

XMOVE3.0手持终端——综述:软硬件全部自行开发的彩屏体感控制器

编者注: X-MOVE是作者在业余时间于2010年6月份启动的以运动传感开发,算法和应用的平台,目前已经发展了三个版本,第四版的开发接近尾声.发布在博客园仅为交流技术,不存在商业目的,作者保留一切权利.   一. 综述 乔布斯曾经说过:做软件的人应该也制造属于自己的硬件. 不觉得每天给电脑,手机开发程序很不爽么? 为什么总是要"给别人打工",用别人的SDK? 小时候特别羡慕有文曲星的同学,也特别梦想自己做一个. 在大四这个理想也成为了现实. 我启动了我自己的体感项目XMOVE的2.0版

综述 | 知识图谱研究进展

1 知识图谱构建技术 本节首先给出知识图谱的技术地图,然后介绍知识图谱构建的关键技术,包括关系抽取技术.知识融合技术.实体链接技术和知识推理技术. 1.1 知识图谱技术地图 构建知识图谱的主要目的是获取大量的.让计算机可读的知识.在互联网飞速发展的今天,知识大量存在于非结构化的文本数据.大量半结构化的表格和网页以及生产系统的结构化数据中.为了阐述如何构建知识图谱,本文给出了构建知识图谱的技术地图,该技术地图如图1所示.整个技术图主要分为三个部分,第一个部分是知识获取,主要阐述如何从非结构化.半结

某B2C电子商务网站建设需求说明

网站建设需求说明书 1. 综述 1.1 网站名称:万能口袋. 1.2 网站定位:为个人及中小企业提供一站式翻译电子商务解决方案.打造出翻译行业领先.客户口碑佳.诚信价低的电子商务品牌,在大多数翻译公司还停留在本地运作,小规模经营的时候抢抓电子商务高速发展的机遇,创立翻译电子商务品牌. 1.3 建站背景(行业分析):盖特翻译公司虽然成立只有不到半年,但是有着三年多的翻译行业经验.两个淘宝店铺中最长的已经经营有三年多,目前拥有两个网站,对网站建设.推广优化有一定的了解.根据积累的实际操作经验,我们了