年前总结了游戏搜索做的事情，现在把slide放出来当做这个月的作业。

1.总纲

2.架构

架构是骨骼，算法策略是灵魂，所以同等重要。一个正常的系统都可以分为三部分：线上系统接收用户请求，监控系统实时发现异常和报警，离线系统分析挖掘数据进而反馈给线上。

2.1监控和报表

监控常见的是QPS和服务延迟，还能包括业务关注点。

2.2 离线JOB

离线系统用于挖掘用户行为进而反馈给线上，提升策略效果。常用的是日志收集、分析提取、算法计算。本文用facebook的scribe收集日志，用hdfs存储，使用mapreduce/hive/spark进行日志的提取和分析，最终结果由线上系统加载使用。注意点是原始日志的分析最好是以天为单位进行，不要一个月的去提取，一是数据量大，二是一天的日志有问题容易导致整个job失败。

2.3 两个细节

线上系统设计到query的分析，是流式的多模块进行。多模树用于query中的多字符串提取，很有效果。

3.策略

3.1 Query理解

query理解分为清理、改写、查询分类、修饰词提取、query扩展几个部分。其中query扩展包括同义词扩展、拼音/单字扩展、相似查询扩展。

3.2 相似查询挖掘

从用户的查询日志中挖掘出相似查询，同一个用户在一段时间的查询词认为是有关联的，通过共现度、内容相似度来确定为相似查询。用于对原始query进行扩展。

3.3 搜索排序

排序以文本相关度为主，辅助以下载指标/用户评价指标等。

3.4 多样搜索

不同的query往往有不同的查询目的，有的是精确查找，有的是模糊查询，有的是查询相关公司，所以在query理解部分我们都要识别出来，进而针对不同的目的构造不同的查询排序逻辑。

3.5 结果调整

查询结果返回后，会进行更细节的调序，如过去该query下的下载历史情况、运营的干预、相似游戏的补充等。

3.6 suggest

suggest承担着引导用户正确输入的功能，可以让用户的输入更规范，避免无效输入。

4.总结

最终游戏搜索系统形成一个生态，用户和用户，用户和游戏，游戏和游戏都互相影响，互相促进。本文没有涉及到针对用户自身历史的个性化搜索，根据用户喜好来展示搜索结果。另外，实现上我们根据query的下载历史，对相似查询和相似游戏进行了反馈，用下载历史调序相似查询和相似游戏。