推荐算法面试集锦--架构工程

1. 假如算力允许，召回和排序是否可以合并？
   推荐系统核心阶段是召回和排序，召回解决的是从海量候选者中初步筛选出用户可能感兴趣的物品，然后再根据更细力度的特征进行排序精选出最可能产生正反馈的物品。

   那么，如果算力足够，是不是就不需要拆成两个阶段了呢？
   从算法模型的理想情况来看，如果可以使用单个模型对所有用户均可做个性化打分的话，似乎是可以合并两个阶段。
   问题在于除了计算能力限制外，实际问题的建模也不是这么理想，目前基于的AI算法模型的本质是基于对大数据样本的标签预测，如若真有一个端到端的模型可以学习到所有样本的个性化，通常在离线建模评估阶段，我们认定为这种是过拟合，通常不具备较好的泛化能力，是因为本身离线模型的样本集就是一个抽样集合，不太可能涵盖了各种类型的用户样本。那么我们就需要对问题域重新进行理解，会发现现实情况是，算法工程师在做的是从完美个性化推荐排序的问题域里，尽可能抽取覆盖大多数用户的兴趣及决策规律的样本子集，然后选择合适的算法模型去拟合这个样本集合。业务上的问题是尽可能让所有到访用户发生有效的正反馈，模型的问题是合理抽样问题域中的样本，尽可能去拟合样本集。很明显这并不是同一个问题，推荐个性化的问题中，算法建模无法脱离业务独立存在，那么就不可能存在这样一个单一的端到端的算法模型，足以将召回和排序的两阶段式合并。

   我们可以看出召回本质是在做什么？不仅仅是因为算力有限，无法从大规模物品候选集中选出最感兴趣的集合，也是因为召回的多样性，针对每个用户可以做到更全面的个性化(满足业务上尽可能让每个到访用户发生正反馈的目的)，来弥补端到端建模中无法真正做到完全个性化的不足，而这恰恰是机器学习算法建模天生的缺陷。因而我们不得不采取一些业