京东亿级商品搜索核心技术解密(3)

对于问题2),我们将拉取倒排结果分为两部分,第一部分是从全量索引拉取倒排的结果,第二部分是从实时索引拉取倒排的结果.为了和全量索引的更新频率保持同步,我们把第一部分数据进行缓存的周期置为1天.对于第二部分数据,由于增量结果远远少于全量结果(一般增量只有全量5%不到),每次缓存都进行实时计算,这就是图3中的doc cache机制.从实践中来看,命中doc cache的响应时间比未命中的降低了1-2个数量级.将来随着增量结果的积累,如果实时拉取倒排结果成为性能瓶颈,可以对增量索引分段也进行缓存.

2. 截断策略

对于有些热门查询,由于其结果较多,比如“男装”、“鞋”之类的query,原始查询结果几千万个,如果对这些结果挨个进行处理,性能会非常差.同时,从用户角度分析,一个查询只有排在最前面的结果对用户才有意义.通过分析用户翻页次数,可以得到截断保留topN结果.如何保证截断不影响用户体验呢?首先我们对商品建立离线模型,即为每个商品计算出一个质量分数据.然后在索引阶段,将所有商品按照质量分降序排列,保证在倒排链中,排在前面的商品质量分总是高于后面的.在线从前往后拉取倒排过程中,如果结果数达到10*topN时,停止拉取倒排.随后对结果计算文本相关性,再按照文本相关性取topN个.截断算法上线前后,虽然KPI指标无明显变化,但是对大结果查询性能提升了一个数量级.

3. 均匀分片策略

从总体架构图中我们可以看到,如果我们将一个term的倒排链进行均分,那么相应term的拉取倒排也会被分配至各个searcher列.正是由于各个searcher列是并行计算的,这样的均分操作就可以大大减少每个查询的平均响应时间.从理论上来讲,我们采用的均匀分片策略,也有效的契合了拉取倒排、排序、在线业务处理等CPU密集型的任务.但是分片增加,会带来硬件成本增高的后果,同时集群节点间的通信成本也会增加,需要进一步权衡折衷.

4. 业务优化

京东的搜索业务并不只有上面所述的策略和工程逻辑,还必须融合很多业务逻辑.由于每一次搜索几乎都会召回很多结果,如果业务逻辑处理不好,也会导致搜索体验不好.针对这一问题并没有通用的解决方法,但是通过实践我们总结出一个基本原则：在离线阶段完成尽可能多的业务逻辑,减少在线计算量!例如进行搜索排序时,我们需要根据用户搜索历史行为(浏览、点击、购买等)对召回的结果进行排序上的调整,在工程实现上我们会先离线统计出同一个query下所有用户对每个展示商品的行为,然后建立模型,计算出该query下每个商品的权重,将其以hash结构存储；在线排序时,直接以query+商品id为key,取出权重作为反馈特征参与综合排序.

搜索技术的新发展

我们在当前的架构基础之上,正在进行一些新的探索,比如场景搜索和图像搜索.

场景搜索

随着目前京东集团的业务的扩展,用户在使用搜索时,目的不仅仅是查找商品,还可能查询促销活动信息.为了满足这些新的需求,我们在目前商品索引融合了促销系统的数据.我们首先在Query Processor中增加对应意图的识别,然后将促销等数据转换为索引数据.只要Query Processor识别出用户提出这方便的查询意图,将对应的结果返回.

图像搜索

传统搜索仅仅针对文字,但是电商系统的商品图片非常重要,很多购买决策依赖于它.目前我们利用deep learning技术离线训练图片特征,并将其做成索引.当用户使用实拍图或者网图来搜索时,采用相同的方式提取特征,然后从索引中召回最相似商品返回给用户.

文章出处：开涛的博客(订阅号ID：kaitao-1234567)

（编辑：ASP站长网）