笔者看来，推荐系统和搜索系统选用模型的区别，主要是由于建模目标和特征特性导致的。搜索系统相关的博文，之前笔者简单写过一些[1-4]，对于搜索系统的用户而言，他们的某次检索行为大多数都是向系统“索要”答案的过程，用户期待系统返回的内容能解决ta的疑惑，并且这个内容最好具有质量好，权威性高，不会过时（时效性好）等优点。在这个消费过程中，用户具有明显的目的性，如果我们的系统单纯以用户指标，比如点击率，展现，跳转，分发，pv，uv等指标去衡量策略的优劣，那么即便这个内容的CTR，CVR预估等的确是非常靠前的，也很有可能出现系统返回的结果并不能满足用户的检索需求。
这点很容易理解，举个例子，轻微涉黄类的内容（美女主播搞擦边球），激进社评这类型的吸引眼球的内容总是有更多的用户点击，但是这些内容并不能满足用户的检索需求（用户在这些内容中找不到答案），如果用户在搜索系统中无论搜索什么内容，都出来这类型的结果，用户体验将会极其恶劣。
因此搜索系统的结果好坏，是需要同时评估用户指标和用户体验的。用户指标通过AB试验进行评估，而用户体验则会考虑对于同一个query，按照基线和策略分别检索得到两批doc list，评估这策略 vs 基线中，这两批doc list结果的优劣（Good， Same或者Bad的case数量）。这个评估同样可以在不同产品中进行评估，比如对于检索词“鸡块上有黑点怎么办”，如Fig 1.1所示在百度和头条上有不同的搜索结果，一般我们评估都需要剔除广告后进行评估（因为广告结果是由商业部门插入的，和搜索部门无关，搜索部门只考虑自然结果的排序和呈现）。显然，用户对于“鸡块”的理解，和百度搜索对于“鸡块”的理解有所偏差，对于系统理解的“鸡块”并不是当前用户的主需求，因此就这个case而言，百度用户体验指标是Bad（相对于竞品而言）。当然，这只是一个case，百度还会有其他Good case，对于两个系统，或者两个策略的综合评估，需要抽样不少的query进行用户体验评估后才能作出。
gsb_case
Fig 1.1 在相同Query下的百度搜索结果 VS 头条搜索结果，需要剔除广告结果。
而对于推荐系统，就笔者个人观点来看，是比较少考虑搜索系统用户体验这个维度的，更多的还是在关注用户指标。无论是视频，文章，新闻，音乐还是商品，用户期望在推荐系统中刷到自己喜欢的东西，对于“喜欢”的定义通常是多维度的。用户可能之前刚刚关注了某个up主，就会倾向于推荐该up主的其他视频；用户可能经常收听古典音乐，下一次推荐可能就是“月光奏鸣曲”；用户刚买了牙刷，系统就推荐牙膏；用户刚关注了一个LSP用户，系统就倾向于推荐该LSP用户喜欢的小黄图（不是系统搞黄色，而是协同滤波:P）；用户刚将个人资料学历改成了专科，系统就推荐专升本广告。我们作为用户，在日常耍手机的过程中发现了无数类似的推荐模式，虽然知道这些套路但是我们还是喜欢点击，无他，这就是推荐系统设计之处干的事情，推荐用户喜欢的东西，充分刺激分泌你的多巴胺，荷尔蒙，促进你的消费。由于用户通常是多标签的，对于推荐的物料通常没有所谓的正确答案，因此验证推荐策略的好坏，更多还是依赖于AB试验得到用户指标后进行评估。
从搜索系统和推荐系统的建模目标，我们不难看出搜索系统在解case的时候是更需要考虑模型的可解释性的，出来一个如Fig 1.1所示的Bad case，我们要考虑整个系统中是哪个模块出问题导致的。正如笔者在博文[1]所讲的，搜索系统就是由由各种打分与条件规则组合成的复杂系统，那么bad case或多或少可以归因到里面的某个或某些打分没打对，或者某些条件规则出现了意外情况导致的。对于打分没打对的情况，我们需要模型具有足够的解释性，让我们分析倒底是哪个打分出问题了。
说到模型可解释性，自然首选还是树模型。树模型在训练过程中，由于可以对每个特征的分裂增益进行统计，因此可以计算每个特征的重要程度，我们将其视为是特征的权重，越高表示该特征在树模型决策中具有更重要的作用。在搜索系统中，根据训练结果是pointwise，pairwise或者listwise，我们经常采用GBDT，GBRank，LambdaRank和RankSVM等LTR算法进行排序[3]。如Fig 1.2所示，LTR排序模型的每个输入都可能来自于其他高级特征，比如通过BERT建模的Query-Title的相关性匹配打分，通过双塔多模态建模的Query-Video相关性，通过神经网络建模的CTR预估模型，甚至LTR排序模型的输入可以是其他树模型的输出（比如权威性模型，质量模型，CTR预估树模型等）。当然，LTR排序模型的输入也可以是一些统计特征，比如后验播放时长，后验点击率，后验跳转等。在出现bad case的时候，我们通过分别交换case之间的树模型特征，可以得到swap diff，这个diff衡量了在该特征下，目标case和bad case之间排序打分差别。通过对比swap diff可以对特征的影响进行分析，从而将debug的影响面快速收敛到一个或者几个特征中，而不需要在海量的打分中进行纠结和猜测。这样debug快速收敛的能力，让我们能够对不理想的高级特征模型进行快速迭代。
IR_frame
Fig 1.2 排序模型的输入大多数来自于高级模型的打分，高级模型可以是深度学习模型，可以是树模型，甚至是一些统计模型。
对于推荐系统来说，其最主要还是用户特征，物料特征，其他特征的充分特征交叉，以及如何对这些特征进行表达。这些特征可能大部分都是未曾进行预处理的原始特征，即便进行了预处理，其预处理通常也是离散化（分桶），截断，除去离群值，填补缺失值等。这种情况在搜索系统中很少出现，搜索的排序模型大多输入都是高级特征，原始特征比如Title，Query，OCR，ASR等文本信息，文档类型，视频分类等ID类信息，大多都在高级模型里面转化为数值型打分了。那么推荐系统为什么不考虑采用类似于搜索系统的模型构型，采用树模型进行各个高级模型特征的汇总呢？其主要原因，笔者认为还是建模目标的不同，推荐系统不需要整个系统具有很强的可解释性，但是比起搜索系统更强调在线用户指标的提升，需要考虑如何更好地进行各种特征的交叉。正如上文举的例子，用户会对某个物料感兴趣的原因是多种多样的，ta可能刚好看到关注人观看过，可能是突然心血来潮，可能这个资源就是刚出的热榜资源，流行度足够高，也可能这个内容和你最近的消费习惯极其相关，这些因素之间可能单独生效，也可能多个因素综合生效，导致你对某个资源感兴趣。为了让模型能够充分地挖掘这些因子之间的关联，就需要设计模型让特征进行充分的交叉。如果采用类似于树模型的结果，对神经网络模型个人觉得可能会有几点不足：
- 树模型的拟合能力不如深度模型，采用深度神经模型的推荐模型可以更好地对特征之间的关系进行学习。
- 树模型常用于处理数值特征，数值特征是连续并且可比的。而推荐系统中存在大量的类别特征（categories feature），比如商品id，用户id等，这类型的特征往往不可比，比如商品id=123456会比商品id=200000更差吗？类别特征数值的比较通常是无意义的，在树模型中不能直接进行特征分裂（否则就是在比较类别特征的数值大小了），通常需要将其转化为one-hot编码后进行处理。
- 树模型无法很好地处理embedding特征。我们之前聊语义标签的时候[5]简单提过分布式表征，Embedding就是一种分布式表征，可以将one-hot编码的稀疏特征转化为密集表征（dense feature），从而提供语义关联。目前大多数推荐模型都会考虑采用Embedding层对某些类别特征进行Embedding编码，而树模型则无法很好地处理这类型信息。
wide_and_deep_model
Fig 1.3 Wide and Deep 模型是推荐里面的经典模型，其wide部分对特征进行记忆，Deep部分对特征进行泛化。
Reference
[1]. https://blog.csdn.net/LoseInVain/article/details/126214410 《【见闻录系列】我所理解的搜索业务二三事》
[2]. https://fesian.blog.csdn.net/article/details/125078683 《【见闻录系列】我所理解的“业务”》
[3]. https://fesian.blog.csdn.net/article/details/123767279, 《搜索系统中的Learning To Rank模型：GBRank》
[4]. https://fesian.blog.csdn.net/article/details/116377189, 《从零开始的搜索系统学习笔记》
[5]. https://blog.csdn.net/LoseInVain/article/details/114958239, 《语义标签(Semantic label)与多模态模型的一些关系》