搜索和推荐1的区别。场景需求不同。顾名思义，搜索场景就是用户提供自己想要找的东西的描述，系统将匹配结果返回给用户。常见场景，如文字输入框搜索、图片搜索、听音乐、标签筛选等。看似很多场景，其实用户输入内容的形式都不一样。
推荐的场景通常是来自各大app首页的个性化推荐(比如猜你喜欢的/每日歌曲推荐)，以及来自精选页面的关联推荐(买买买，看着看着，由买了的用户购买等)。).推荐的场景更加丰富，因为对用户提供的内容没有限制，场景更加多样，推荐方式多种多样，比如基于内容的推荐、基于用户行为的推荐、协同过滤等等。
由于服务内容和平台成熟度不同，各大互联网平台对搜索和推荐的重视程度不同，但都不可或缺。
比如房产类应用，用户目标明确，搜索服务会带来更多购买力，但相关推荐会给用户带来更多选择，这也是不可或缺的。
对于短文章平台来说，由于用户很难通过文字或图片提供对内容的描述，自然会把重点放在推荐服务上。
对于电商来说，在起步阶段，搜索服务肯定带来了更多的购买率。当购买率达到瓶颈时，推荐带来的购买率是突破瓶颈继续发展的必要手段。
2.不同的输入输出，无论是搜索还是推荐，其实都是一个为用户提供服务的黑匣子，可以根据用户/物品/场景等信息，从候选物品池中选择匹配用户的物品列表。
不同的是，对于搜索服务，它还提供了用户需求的附加描述信息(当然，描述可能不准确)。
投入的不同自然会导致用户对结果的不同期望：
不同程度的个性化
推荐系统更强调个性化，甚至是惊喜感。准确性和多样性之间经常有一个权衡；搜索系统更加强调相关性。如果搜索结果与用户的目标不匹配，用户的接受度就会很差，个性化对于搜索系统来说是没有意义和风险的。
更好的安排和更完整的搜索
对于推荐系统来说，排名更重要，因为只有最初的推荐结果吸引了用户，用户才能反向浏览。
对于搜索系统来说，召回更重要，因为用户会主动向后浏览，希望找到自己的目标，但如果最后没有找到，也就是搜索不完整，就会有很差的用户体验。
快速满足还是持续服务？
说到搜索系统，经常会提到马太效应。只有符合用户搜索结果的商品才会呈现给用户，让用户快速满意。所以符合需求的商品非常多，搜索越精准，用户越不会向后浏览，最后的点击也只会集中在很少一部分商品上。这也是为什么广告最初诞生于搜索系统的原因。
说到推荐系统，经常会提到长尾效应，即时刻保持用户新鲜感和惊喜感，考虑用户长远利益，提高用户粘性，留住用户，提供持续服务，这也是短文章停不下来的原因。
实时和滞后
搜索数据的实时性要求特别高，数据往往需要秒级更新。比如某商品缺货，不应该搜索出来。但是很多推荐数据是可以容忍日级更新的，而且由于推荐要考虑大量的用户行为信息，必然有一定的滞后性。
搜索和推荐1之间的联系。同样本质的搜索和推荐，本质上都是当前时代信息过载的产物。解决这个问题的根本思想是通过匹配(回忆)和排序，从过载的信息中选取用户想要的信息。只是根据业务场景的不同，召回和排序阶段的考虑重点不同。
2.推荐中搜索与推荐搜索的协同作用
推荐服务中基于内容的推荐实际上相当于一个静默搜索，在搜索服务中往往是利用倒排索引等技术来实现的。比如基于内容的推荐，往往是通过规则或者推荐模型获取用户感兴趣的内容的标签，然后利用搜索服务的方法对标签进行搜索匹配，得到最终的推荐列表。
搜索中的推荐
当大量数据满足用户需求时，就需要根据推荐服务中用户画像的结果，帮助搜索服务匹配用户的需求。比如周一晚上搜索得到的结果列表会和周五晚上搜索得到的结果列表不一样。
推荐和搜索往往合作在一个页面中为用户提供服务，比如搜索引擎的搜索结果页面的相关推荐，电子商务软件的搜索浏览页面的相关推荐等等。
架构的演进和统一搜索架构的演进一般来说，一个企业的搜索引擎，因为初期业务线不多，所以可以提供简单的搜索服务。随着服务数量的不断增加和搜索需求的不断抽象和统一，可以逐渐发展到平台阶段，提供多种数据源的编写和多种服务的统一搜索能力，不同服务的不同需求可以灵活配置。
在业务线数量越来越多，对接业务的工作占据大部分开发时间的情况下，开发更便捷的运维管理能力，帮助进入业务自助接入平台，可以进一步提高搜索功能开发的效率。此时的搜索架构已经进入了运维更加便捷的云平台阶段。
推荐架构的演变
对于推荐引擎来说，初期一般采用基于内容的推荐方式。由于缺乏数据，企业在初期会根据业务端提供的经验规则对物品和用户进行标记，然后通过在线标签匹配进行推荐。继续发展，随着业务的不断丰富和迭代，对推荐系统会有更多的期待。当体验规则不能满足业务需求时，就需要一些基于模型的推荐方法和个性化的推荐服务。再者，推荐引擎和搜索引擎一样，也需要连接多个业务线，发展到平台阶段，提供统一的公共服务，通过配置满足不同业务线的需求。
架构统一从上面的介绍和架构演变可以发现，推荐和搜索的架构有很多可以复用的地方，所以架构是可以统一的。
流程统一：
无论是搜索还是推荐，都会经历回忆-排序-重排的过程，最终得到呈现给用户的物品列表，但过程中每个阶段的目标会有所不同。
数据和数据平台的重用；
搜索的项目和推荐的项目是统一的，召回排名训练模型时需要的埋点数据/用户行为数据也是统一的，自然获取数据/处理数据的平台自然可以复用。
算法和算法平台的重用；
搜索和推荐发展到一定阶段。当简单的专家规则已经不能支持复杂的搜索和推荐需求时，它们都会发展到基于模型的召回排序阶段。这时候就需要根据用户数据/物品数据/埋点数据进行模型训练。但是训练出来的模型参数可能会因为训练目标的不同而不同，但是算法平台或者我们常说的机器学习/AI平台是可以复用的。
A/B测试实验平台的复用；
由于业务需求的不断变化和模型的不断更换，为了帮助企业不断验证和优化搜索和推荐策略，可以通过A/B测试平台获得用户在真实生产环境中的反馈。
配置中心的重用：
您可以通过配置中心为不同的业务和服务配置不同的搜索和推荐策略，并提供便捷的一键部署功能。
所以很多公司，在业务领域，搜索和推荐分属不同的部门，但是很多
摘要本文介绍了搜索和推荐的区别和联系，架构的演变和架构的统一。我们都知道架构是因为需求的扩大而不断演进的，比如从服务阶段到平台阶段，因为要提高多服务对接的效率；从基于内容的推荐到结合线上用户画像和线下用户画像的复杂个性化推荐，是因为单纯基于规则或标签的推荐无法满足用户和商家的需求。
所以不要一开始就被一个过于复杂的架构所束缚。您可以设计一个简单的架构，用于搜索/推荐您自己的业务需求，然后逐步演进和优化该架构。
来源：thoughtworks
