一、什么是需求满足 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多结果页的形式也未必是最优的,如何更好的发挥作用,需要更加深入的调研和创新的思路。