我正在研究基于客户属性（例如人口统计）和过去的产品交互（例如购买或未购买）向客户推荐产品的方法。有大约 250 种产品可供推荐。这当然是一个隐式反馈推荐引擎设置。
我有两个问题与分解机的使用有关。
1) 为该算法构建数据的唯一方法是为每个客户/产品交互创建 1 行，其中包含客户属性的列和正在考虑的产品的单热编码矩阵？包含用于目标列的 1/0。这将是一个非常稀疏的矩阵，例如 libsvm 格式。如果客户和产品的每种组合不可行，则将包括所有积极的互动（客户购买）和每个客户的负面示例样本。
2）一旦建立模型......如何提供建议？是否必须为每个客户遍历所有产品（变体）？这似乎令人望而却步。
虽然这被描述为产品推荐，但广告技术中的点击模型将是另一种常见情况。想知道人们在现实世界中是如何处理这个问题的吗？
你的直觉是正确的，除非我们有几万个项目，否则很快就会变得过于昂贵，无法生成数十万个排名然后对它们进行排序。所做的事情通常称为“候选项目选择”；为可用项目的子集生成估计值。我们的目标是避免不必要地评估那些有极小概率进入最终 top-排名的项目。在这个程度上，由于隐式或显式反馈机制没有区别。
简单地说，上面提到的“剪枝”可以通过简单地评估项目来实现，这样这些项目是由一组用户 U 排名的，这些用户本身与候选用户聚集在一起。这是更为严格的方法：该任务的原型算法是加权与（WAND），因为这是由 Broder 等人提出的。(2003) 在使用两级检索过程的高效查询评估中。它基于某些高影响特征的存在与否创建可以被视为“近似”排名，然后如果该近似排名高于某个阈值，则估计完整排名。阿萨迪和林 (2013)多阶段检索架构中候选生成的有效性/效率权衡很好地概述了不同的候选生成方法。最近的发展建立在 WAND 之上（例如 Borisyuk 等人（2016） CaSMoS: A Framework for Learning Candidate Selection Models over Structured Queries and Documents）以及完全规避（例如 Wang X. 等人（2016） Skype：top-k空间关键字在滑动窗口上发布/订阅）。为了完整起见：每种算法使用的实际索引系统至关重要。在不涉及任何血腥细节的情况下，WAND 和其他算法（如 BMW）就是我们所说的 DaaT - 一次文档方法，文档以迭代方式评估，我们有文档排序索引。还有其他方法，例如一次 Term-at-a-time (TaaT)，我们有频率顺序索引和 Score-at-a-Tie (SaaT)，我们有影响顺序索引。起重机等人。(2017)一次文档和一次得分查询评估的比较提供了对这种比较的全面了解。
最后的警告：正如人们可能正确地认识到前面提到的方法夸大了“越来越富有”问题的问题，即受欢迎的项目得到一致推荐的频率更高。虽然这种现象已经有好几年了（例如 Celma & Cano (2008) From hits toniches? 或者流行艺术家如何影响音乐推荐和发现），但它仍然是一个非常活跃的研究领域（例如参见 Wang Y. et al. (2015) Peacock: Learning Long-Tail Topic Features for Industrial Applications或 Antikacioglu & Ravi (2017) Post Processing Recommender Systems for Diversity）如果我们确实只需要对可用候选者的一个子集进行排名，最好保留记住它。
为了简洁地解决输入格式的初始问题：编码负面示例（或缺少信息）确实会导致非常大的稀疏数据数据集。最早解决此问题的 ML 格式之一是稀疏数据的LibSVM 格式。LibSVM 仍然被普遍接受为一种半合理的标准，尤其是在排名（即推荐系统）应用程序方面。例如，XGBoost 和 Tensorflow 都提供了读取 LibSVM 数据的方法（更多详细信息，请分别参见此处和此处的链接）。尽管如此，很多事情都是特定于案例的，并且特定于所使用的算法；.txt 文件中每部电影评级使用的旧Netflix 奖，而最新的2019 年 RecSys挑战报告 .csv 文件中的会话信息。最终，我们确实需要“一些稀疏矩阵”功能，以及是否将由我们使用的格式（例如 LibSVM）提供，或者我们只是在读取数据时构建它（例如在 RecSys 挑战中）由我们决定。当数据大小是一个重要因素时，熟悉算法输入格式的细节（例如，DMatrix在 XGBoost 的情况下）是至关重要的。