需求满足综述

　　一、什么是需求满足
　　1。1什么是需求满足
　　用户来搜索章鱼保罗，就文本相关性而言，搜索引擎只要返回和章鱼保罗内容相关的结果就可以了，这样用户是否满意呢？
　　用户甲：听说章鱼帝挂了，来看看最新结果，怎么全是8月份的，往后翻页中
　　用户乙：今天同事们在讨论章鱼哥挂了，章鱼哥是啥？我又out了，来搜索一下章鱼帝生平事迹是啥，怎么全是最新的结果，没有章鱼哥的介绍啊，变换个query看看
　　用户丙：我是铁杆球迷，看完章鱼哥，再看看足球相关的吧，鲁尼，杰拉德是否又进球了，怎么连个相关推荐都没有，还得我亲自输入。
　　用户丁：找个章鱼哥的头像用一下吧，一定很拉风，怎么全是结果没有方图呢，这么扁的图怎么用啊
　　用户戊：换个章鱼哥的壁纸，也许下次买彩票能发大财，咦，怎么全是小尺寸的图
　　（以上信息通过分析20101027用户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变换等，在这方面我们做的工作不多，经验也不多，是我们后续工作的重点。
　　专名amp；amp；需求词
　　判断query中包含专名或者需求词等关键词，是最直接的方式。比如红色宝马，显示的表达了颜色方面的需求。
　　时效性需求
　　时效性需求包括三部分，突发时效性、周期时效性和泛时效性需求，目前线上做的是突发时效性需求。需求的识别，主要是通过检索量的突发，资源数突发和实效性事件来判断的。
　　检索量的突发，是指累积每个小时的用户检索频率，用连续15天的用户检索频率，计算突发的斜率，根据斜率的大小，来判断时效性需求的强弱。
　　上述方法只适合热门query，对于长尾query，检索频率很低，无法通过这种方式识别出来，一般这种query是多term的query，可以通过是否命中关键词来判断：
　　通过事件判断：这种方式，主要是想看关键term命中时效性事件的比例。当然这些事件是通过主动挖掘的时效性query，通过聚类后，对每个类别训练出来的关键词。
　　2。1。2需求的强弱
　　要做好需求满足，不仅要识别query有哪一类型的需求，而且要识别该类型需求的强弱，他直接指导了后续需求调权的力度。
　　每个维度的需求，必须要有需求的强度，在各维度调权合并时，需求的强度决定了该维度的权值。比如时效性需求，需求的强度很高，要求满足时效性的资源，一定要排在前面。又比如清晰度饱和度调权，对大部分query而言，需求不是很强烈，调权时的力度就不能太大。
　　需求强弱的计算，和后面rankmodel的要求相关，理想的状态是每个query，可以动态的计算在每个维度上的需求强弱，我们在这方面经验不多，如果暂时不能做到准确的计算的话，暂时可以考虑人工指定的方式，比如针对不同的query分类，人工设定需求维度的强度。目前可以想到的一些方式：
　　显式的需求为强需求
　　用户通过在query中包含需求词的方式，表达自己的需求，这样的为强需求。
　　比如，最新刘德华图片，红色宝马
　　基于统计的方式挖掘需求时，判定值超出阈值的比例大小，决定需求的强弱
　　在用统计挖掘用户需求的方法时，一般会选取某个维度的属性，量化后计算它的统计特性，可以根据统计后该数值的分布情况，判断需求的强弱。比如，时效性需求，某段时间内，该query检索量突发特别大，是昨天检索量的100倍，如果我们设定的阈值是2倍的话，那么这个query就可认为时效性需求特别强。
　　又比如通过用户点击数据挖掘size需求，对于头像类的query，大部分用户点击的是100100的方图，但是所占总点击中的比例不是很高，比如只到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需求满足体系框架的建立
　　之前做了很多需求满足的工作，颜色，格式，尺寸，人脸，表情，头像等等，分别是casebycase来做的，其实他们之间存在着很多相似的地方。从调研过程来看，可以分为需求识别、资源满足和需求调权三大部分。
　　这样分散的各个点去做，有很多弊端，一是调研重复，效率低；二是前端调权系统像打补丁一样，越来越乱，没有形成清晰的体系框架。三是容易造成调权重复。
　　目前比较好的思路是建立需求满足的体系框架，包括前端的需求分析和后端需求调权。前端分析清楚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多结果页的形式也未必是最优的，如何更好的发挥作用，需要更加深入的调研和创新的思路。