下拉提示是搜索引擎的标配功能，它能起到减少用户输入的作用，自动补全搜索关键字，提升用户使用搜索引擎的体验，好的下拉提示还可以引导用户输入质量高的 query，这些高质量 query 最终能输出用户想要的搜索结果。既然是标配，那么提供云搜索服务的开放搜索产品，必然不会缺失这方面的能力，而且开放搜索面向的客户是广大的搜索提供商，由于他们的需求具备多样性的特点，所以下拉提示方面的功能只会更为丰富。
本文会从以下几个方面对开放搜索的下拉提示进行介绍
- 设计理念
- 核心功能
- 未来展望
设计理念
互联网产品注重快速迭代是众所周知的事情，开发效率高的团队和产品才能适应不同的需求，用户不断被满足，他们才会依赖这个产品，这样的产品才能把用户留住，这也是为什么我们会把「拥抱变化」作为一个团队乃至一个公司内部的核心价值观的原因。
其实它还有另一个原因，就是很少有团队能真正做到「拥抱变化」，这种能力是稀缺的，所以它很重要。究其原因无非也是大家经常抱怨的：用户的需求是无限的，而团队的人数是有限的。为了解决这个矛盾，人们又总结出另一个重要的开发原则——先「把核心功能做到极致」，之后再由一个点扩展到面，最后由面到体。可以看到，这里的原则并不适用于云服务产品，因为云产品一开始就是一个面，它的每一个客户，都是一个不同的点，如何解决这方面的问题从而做到高效就成了开放搜索团队首先要面对的。
如何提升云产品的开发效率？这个问题其实操作系统已经给出了答案，那就是抽象，操作系统中一切皆文件的思想，简化了操作系统的设计；而虚拟文件系统的抽象，让它可以很容易的适配不同的文件系统……
因此，在云产品的设计中，一个核心的理念就是把整套服务抽象为几个标准的流程，所有的用户按照这个流程来，就可以构建属于他自己的服务，然后再在不同的流程中实现定制化的需求，这样就形成了分工协作——云平台团队专注于平台建设，丰富定制化能力；而其客户则专注于实现多样的需求。
可以预想到，开放搜索的下拉提示也遵循了这一开发理念，我们可以把下拉提示服务的整个过程分为3个部分
- 数据处理部分ETL（Extact、Transform、Load），解析并加载用户的数据
- 数据训练部分，训练有意义的 query 信息，产生下拉提示索引
- 在线查询部分，能快速根据用户敲入的关键字，返回下拉提示列表
其中前两个步骤，客户拥有一定的定制化空间，在第1步中，用户可以根据自己的需要，选择性的导入 query 日志、点击数据、可被训练的文本字段、黑白名单等，每一类数据都有其不同的作用，例如点击数据可以用来调整 query 质量，由文本字段抽取的 query 可以避免服务冷启动等（下文有详细介绍）。
在第2步，我们会提供不同的训练算法（如不同场景下的分词算法），根据这些算法，客户可以按需进行选择，调整其中的参数，最终输出符合自己业务的 query 数据集。
最后一步，每个用户的需求应该都是一样的，即要求高qps、低延迟、服务高可用，这也是搜索事业部沉淀下来的 Ha3 或 D2 所擅长的工作，这里复用它就好了。
核心功能
丰富的查询方式
可以通过中文前缀、拼音全拼、拼音首字母简拼以及汉子加拼音等查询候选 query，例如“连衣裙”这个 query，可以通过以下方式查询得到：
- 中文前缀：连，连衣
- 全拼前缀：li，lianyi，lianyiqun
- 简拼前缀：l，ly，lyq
- 汉字加拼音：连yi，连衣qun
除了前缀查询之外，还支持中间词前缀获得下拉推荐，例如”port antigua“这个 query，可以通过以下两种方式召回
- 前缀：p，po 或 port
- 中间词前缀：a，an，ant 等
智能抽取query
该功能是下拉提示的亮点，也是开放搜索这种云搜索场景下独有的能力（区别于google、百度等全网搜索引擎），旨在解决客户接入搜索服务后，由于没有足够多的query数据，无法提供完善的下拉提示体验，于是智能抽取 query 应运而生，它会根据用户的 doc 文档数据，抽取相关性高，有意义的 term 组合，形成下拉提示数据集，这样即便没有任何搜索请求，用户也可以使用下拉提示功能，解决了搜索应用的冷启动问题。
具体的，我们在实现该功能时，先基于用户期望的抽取字段进行分词，这里我们会提供多种分词算法，用户可以选择新闻领域、电商领域或视频领域的分词库。
接着，根据分词后的词性，我们会挑出有意义的词性组合，形成候选 query，组合包括「地名+名词」、「专有时间词+专有名词」等，例如“春款连衣裙”就会和后者匹配，根据训练结果的好坏，我们筛选了20多种词性组合。
最后，我们对这些有意义的候选 query 进行TF计算，选择出现频率较高的 TopN 的候选列表，当然，为了让不同前缀的 query 组合足够的丰富，我们在做 TopN 时，会对超过一定数量的相同前缀的 query 进行降权，例如：如果“iphone”这个前缀非常多，我们只会抽取前 m 条，剩下的会降权处理，待下拉列表不足时，才会使用降权query进行补足，这种做法既满足了数据的多样性，也保证了数据的完备性。
可以看到，上面的算法很大程度上依赖于分词库的能力，毕竟我们面向的是不同领域的服务商，不同客户之间的数据集都有很大的差异，分词库很难覆盖所有的场景和 case，所以在抽取用户 query 的过程中，我们增加了一个策略：即保留字段中长度较短的 term，例如10个字长度的 term，这样，一部分无法被分词器识别的专有词汇会根据这些 term 的出现频率自动的被筛选出来，而客户也可以根据这种特性，把他们期望保留的 query 以这种形式存储在文档字段中。
干预能力
对于一些突增热词，例如当“iphone Xs”发布时，它的 query 频次肯定不及发布了一年的“iphone X”，这种 case 下，客户肯定希望当他的用户敲入“iphone”时，“iphone Xs”排在下拉提示的最前面，这时我们提供的推荐名单功能就可以派上用场了，客户可以手动输入“iphone Xs”词条，这样它就可以排在最前面了。
相反，有些query客户是不希望被展示的，例如一些法律敏感的词汇，或 query 返回的结果集较少的词汇，此时客户可以使用我们提供的黑名单功能，运用该功能后，用户输入的 query 如果部分匹配或全部匹配黑名单词条时，相关的下拉提示结果会被屏蔽。
未来展望
前面提到了，当前的下拉提示的 query 抽取比较依赖于分词器的词性辨识能力，而词性之间的组合对抽取结果的影响也不够灵活，更为弹性的做法是分析数据源，利用词和词之间组合的概率来确定哪些词组是有意义的，这种方法会让抽取过程更为智能，它能够适应于不同的数据源场景，同时将来和 OpenSearch 的算法平台结合后，客户也可以通过简单的修改几个参数，可视化的调整训练结果，获得更好的搜索体验。
回到下拉提示的初衷，它是为了让用户在使用搜索产品时，推荐给用户好的 query，以输出他想要的搜索结果，对于用户所期望的结果，这里还有很多优化方案，例如筛选 query 时，对这些 query 的搜索结果有要求，优先召回高质量结果的 query；除此之外，还要具备防作弊的能力，要能够识别相同用户做出的重复请求，以及恶意刷 query 数的行为。
在移动互联网时代，需要在手机端做更多的优化和体验，典型的有优化输入体验，例如对下拉提示列表页的结果进行分类，让用户在有限的输入情况下能获得到更丰富的内容，可以想象在一个旅行类 app 的场景下，当用户输入“北京“这个关键字时，系统会同时给出以”北京景点”相关的下拉提示以及“北京酒店”、“北京美食”等相关的下拉提示。
总之，开放搜索让搜索技术更简单，为更多商家挖掘出商业价值，未来可期。
推荐与搜索技术钉钉交流群
