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