从架构演进和统一看搜索与推荐

搜索与推荐的区别

1. 场景需求不同

搜索的场景故名思义，就是用户提供想要寻找的内容的描述，系统返回给用户匹配到的结果，常见的场景如文字输入框的搜索，图片搜索，听音识曲，标签筛选等，看似很多场景，其实只是用户输入内容的形式不同。

推荐的场景我们常见的有各大App首页的个性化推荐（如猜你喜欢/每日歌曲推荐），选择页面的关联推荐（买了还买，看了还看，买了它的用户还买等等）等，推荐的场景更加的丰富，因为没有用户提供的内容的限制，场景更具多样性，推荐方法也多种多样，例如基于内容的推荐，基于用户行为的推荐，协同过滤等等。

各大互联网平台由于服务内容不同，平台成熟度的不同，对搜索和推荐的偏重程度也就不尽相同，但都是缺一不可。

例如对于房地产应用来说，用户目标明确，搜索服务会带来更大的购买力，但关联推荐会给用户带来更多的选择，同样也是不可缺少的。

对于短视频平台而言，由于用户较难通过文字或图片提供内容的描述，那么自然会偏重推荐服务。

对于电商在初期肯定是搜索服务带来了更多的购买率，当购买率到达瓶颈时，推荐带来的购买率就是突破瓶颈和继续发展的必要手段。

2. 输入输出不同

不论搜索还是推荐，实际上对于用户来说，都是一个提供服务的黑盒，它能够根据用户/物品/场景等信息，从候选物品的池子中选出与用户匹配的的物品列表。

不同的是对于搜索服务，还额外提供了用户对于自己诉求的描述信息（当然可能描述的并不准确）。

输入的区别天然的导致了用户对于结果的不同期待：

• 个性化程度不同

  推荐系统更强调个性化，甚至更注重惊喜感。往往要在准确性和多样性之间作出权衡；搜索系统更强调相关性，如果搜索结果与用户的目标不符，用户的接受程度会很差，个性化对于搜索系统来说既没意义又有风险。

• 排的更好与搜的更全

  对于推荐系统来说，排序更加重要，因为只有最开始的推荐结果吸引了用户，用户才可能向后浏览。

  对于搜索系统来说，召回更加重要，因为用户会主动向后浏览，以期望找到自己的目标，但如果最终没有找到，也就是搜的不全，就会有很差的用户体验。

• 快速满足还是持续服务

  提到搜索系统，往往会提到马太效应，只有与用户搜索的结果更为匹配的物品才会被呈现给用户，让用户得到快速满足，那么满足需求的物品那么多，搜索的越准确，用户就越不会向后浏览，最终点击的热度就只会集中在少量的物品上。这也就是为什么广告最初诞生在搜索系统中的原因。

  提到推荐系统，往往会提到长尾效应，也就是让用户时刻保持新鲜感和惊喜感，考虑用户的长期兴趣，提高用户粘性，期望留住用户，并提供持续的服务，这也就是为什么刷短视频停不下来的原因。

• 实时性与滞后性

  搜索的数据实时性要求是特别高的，数据常常要求秒级更新，例如一个商品已经没有货了就不应该被搜出来了。而推荐的数据很多是可以容忍天级更新的，由于推荐要考虑大量的用户行为信息，一定是具有一定滞后性的。

搜索与推荐的联系

1. 相同的本质

搜索与推荐本质上都是当前时代信息过载的产物，解决的根本思路都是通过匹配（召回）、排序为用户在过载的信息中挑选出用户想要的信息。只是根据业务场景的不同，在召回，排序阶段考虑的侧重点不同。

2. 搜索与推荐的协同作用

• 推荐中的搜索

  推荐服务中基于内容的推荐实际上相当于一种无声的搜索，常常在实现时会采用搜索服务的中的倒排索引等技术，例如基于内容的推荐，常常是通过规则或推荐模型得到用户感兴趣的内容的标签，然后利用搜索服务的方法进行标签搜索和匹配即可得到最终的推荐列表。

• 搜索中的推荐

  当搜索出来符合用户的数据量很多时，需要根据推荐服务中用户画像等结果帮助搜索服务匹配用户的需求。例如周一的晚上进行搜索得到的结果列表和周五的晚上进行搜索得到结果列表就会有所差异。

推荐与搜索常常在一个页面中协同为用户提供服务，例如搜索引擎搜索结果页面的关联推荐，电商软件搜索浏览页面的相关推荐等。

架构演进与架构统一

搜索架构的演进

一般而言，一个企业的搜索引擎，由于在初始阶段业务线不多，提供简单的搜索服务即可。随着业务的不断增多，对搜索需求的不断抽象和统一，逐渐可以发展为平台阶段，提供多数据源的写入与多业务的统一搜索能力，不同业务的不同需求可以灵活配置。

等到业务线不断增多，对接业务的工作占据了大部分的开发时间时，开发更加方便的运维与管理能力，帮入业务自助接入平台就能够进一步提高搜索功能开发的效率，此时搜索架构就进入到了运维更为便捷的云平台的阶段。

推荐架构的演进

对于推荐引擎，起步阶段一般会采用基于内容的推荐方法，由于数据不足，企业初期会基于业务侧提供的经验规则对物品和用户进行标注，然后通过在线匹配标签的方式进行推荐。继续发展，随着业务的不断丰富和迭代，会对推荐系统有更多的期望，当不断修改或增加经验规则却满足不了业务需求时，就需要一些基于模型的推荐方法以及个性化的推荐的服务了。再进一步，与搜索引擎一样，推荐引擎也需要对接多个业务线，向平台阶段发展，提供统一的公共服务，通过配置满足不同的业务线的需求。

架构统一

从上面的介绍和架构演进我们可以发现，推荐和搜索的架构有很多可以复用的地方，因而可以进行架构的统一。

1. 流程上的统一：

   不论是搜索还是推荐，都会经历召回-排序-重排等流程，最终得到呈现给用户的物品列表，只不过流程中各个阶段的目标会不太相同。

2. 数据与数据平台的复用：

   被搜索的物品和被推荐的物品是统一的，召回排序训练模型时所需要的埋点数据/用户行为数据等也是统一的，那么自然获取数据/处理数据的平台自然就是可以复用的。

3. 算法与算法平台的复用：

   搜索和推荐发展到一定阶段，当简单的专家规则不再能够支撑复杂的搜索和推荐需求时，都会发展到基于模型进行召回排序的阶段，此时都需要根据用户数据/物品数据/埋点数据进行模型训练，只不过由于二者的训练目标不同，训练的模型的参数可能会不相同，但算法平台或者大家常说的机器学习/AI平台是可以复用的。

4. A/B Test实验平台的复用：

   由于业务需求的不断变化，模型的不断更替，通过A/B Test平台能够通过分流的方式拿到真实的生产环境中的用户反馈，以帮助企业不断验证和优化搜索和推荐策略。

5. 配置中心的复用：

   可以通过配置中心针对不同业务和服务配置不同的搜索和推荐策略，并且提供便捷的一键部署能力。

所以很多公司，在业务领域上搜索和推荐分属于不同的部门，但很多的公共的部分都有成熟的内部平台可以快速复用。

总结

本篇文章介绍了搜索和推荐的区别与联系，架构演进以及架构统一。我们都知道架构是因为需求的扩增而不断演进来的，例如从服务阶段发展到平台阶段，是因为要提高多业务的对接效率；从基于内容的推荐到复杂的融合在线用户画像和离线用户画像的个性化推荐，是因为简单基于规则或标签的推荐无法满足用户和业务侧的需求。

所以不要在一开始被过于复杂的架构绑住手脚，可以针对自身业务的需求进行搜索/推荐的简单架构设计，然后逐步演进和优化架构。

来源：thoughtworks