深度学习在互联网房产推荐场景的算法实践

导读本次分享的题目为深度学习在互联网房产推荐场景的算法实践。

主要内容包括以下四大部分：

1. 58 房产业务介绍

2. 向量化召回

3. 多任务，多场景多任务模型优化

4. 总结与展望

分享嘉宾｜胡作梁 58安居客资深算法工程师

编辑整理｜鲍亭文

内容校对｜李瑶

出品社区｜DataFun

58 房产业务介绍

58 房产作为互联网领先的找房平台，致力于提供全方位的房源信息和相关服务。其业务涵盖新房、二手房、租房、商业地产、海外地产以及装修等多个领域，为用户提供了丰富的选择。目前，58 集团正处于产业化转型的关键阶段，积极推动线上线下融合，力求为用户带来更高效、更便捷的服务体验。

58 房产的主要业务场景涉及房东、经纪人和找房用户三个角色。房东可以选择将房源委托给经纪人进行发布，或者自行发布个人房源。经纪人则负责发布、维护房源信息，并通过平台获取潜在客户商机。对于找房用户来说，他们可以在 58 房产平台上获取房产资讯，搜索或筛选小区和房源，并与经纪人或房东进行联系。

在整个流程中，找房用户在 58 房产平台上进行搜索、筛选，进入房源列表页浏览房源，或通过平台的推荐系统获取个性化的房源推荐。当用户进入房源详情页后，他们可以通过 VR 带看、电话、微聊等方式与经纪人进行沟通交流。如果用户对某套房源表现出进一步的兴趣，经纪人会安排实地带看，让用户更直观地了解房源的实际情况。当用户有进一步意向时，经纪人会协助用户和房东进行洽谈，促成交易的达成。

此外，58 房产平台在线下某些阶段也会积极参与，例如提供金融服务等，为用户和房东提供更加便捷和全面的服务体验。

58 房产的核心推荐场景广泛，覆盖用户在平台上的各个关键触点，比如大首页的推荐、大类页的推荐、零少结果的推荐、房源单页的推荐，以及默认列表页的推荐等。推荐内容主要围绕房源、经纪人、小区以及榜单、房源包等，不仅涵盖了用户直接需要的房源信息，还包括与房源相关的经纪人和小区等信息，帮助用户更全面地了解房源背景。

58 房产推荐系统架构主要分六层：

数据层：负责离线数据和实时数据的存储。此外，房源向量存储在 Faiss 中。
计算层：涵盖了离线和实时计算任务、模型训练、Faiss 向量检索以及画像个性化检索等。
召回层：采用多种召回策略，包括向量化召回、商业房源召回、兴趣召回、基于位置的召回、再营销召回以及热门召回等。
排序层：应用精排模型，对召回层提供的房源进行精细化的排序。
重排层：进一步对排序后的房源进行加权、去重、过滤和打散等操作，以优化推荐列表的多样性和相关性。
应用层：为线上的推荐位提供接口服务。

向量化召回

在向量化召回中，训练数据预处理包括以下几点：

两次点击行为时间间隔大于一定阈值时，我们会将用户的浏览房源序列分割成两个新的序列；
剔除一些用户误点击的房源，这些误点击的房源通常表现为停留时长过短或两次行为之间房源的差异过大；
对于经过修改的房源，只保留最后一次修改后的行为数据；
剔除一些异常用户的数据，如经纪人的行为数据；
对于用户的连接行为，如电话、微聊、分享、收藏等，我们也会进行适当的过采样处理。

在模型选择方面，采用了多种效果显著的 I2I 模型。其中，Skip-gram 模型主要利用用户的浏览房源序列训练 word2vec，生成房源的向量表示。DeepWalk 模型则基于用户的浏览房源序列构建有向带权图，通过在图上随机游走生成房源序列作为训练样本。EGES 模型在 DeepWalk 的基础上引入了属性信息（side information），以解决数据稀疏和新房源冷启动的问题。

此外，我们还尝试了一些其他的模型，如图卷积网络（Graph Convolutional Network）等，以不断探索和优化推荐算法。

对于用户-房源（U2I）模型，将用户点击的房源作为正样本，同时从同城点击、同城曝光以及全国范围内进行负采样构建负样本。用户特征包括用户的长短期行为序列、连接序列以及搜筛特征等。

在模型探索上，我们首先尝试了双塔模型。双塔模型由用户塔和房源塔两个部分组成，分别对用户行为序列和房源特征进行 embedding，embedding 向量随后被输入到深度神经网络（DNN）中，得到用户和房源的向量表达。通过计算这两个向量的余弦相似度，得到它们的匹配分数，进而进行分类。然而，双塔模型的一个显著缺点是用户特征和房源特征在底层无法直接交互，这可能导致某些细粒度特征在 DNN 的交互过程中丢失，从而影响模型的最终效果。

为了处理这个问题，我们借鉴了张俊林老师提出的思想，在用户和房源特征 embedding 的基础上引入了一个 SENET 模块。这个模块的主要作用是进行特征选择，即对每个特征学习一个权重，然后再把学习到的权重乘到对应特征的 embedding 上，这样就可以动态学习特征权重，通过小权重抑制噪音或者无效低频特征，通过大权重放大重要特征的影响。

另外一种优化方法是模型融合，比如多级并联双塔模型。在这个模型中，我们将用户和房源的特征 embedding 输入到多个模型（如 MLP，CIN、DCN、FM 等）中，分别提取用户和房源在这些模型中的向量表达。然后将这些向量表达进行哈达玛积，再输入到逻辑回归模型中学习各个元素的权重。线上预测时，可以先将逻辑回归的权重写入用户向量中，然后直接进行检索。

为了增强用户搜索和房源描述之间的匹配能力，我们引入了 SentenceBert 模型。相较于之前尝试的原生 BERT 模型，SentenceBert 在句子级任务上展现出更为优越的性能。作为一种双塔模型，它将传统的 DNN 替换为 Bert，从而在处理复杂文本任务时更具优势。

在应用中，我们将用户的检索词（涵盖区域、商圈、楼盘等信息）视作“sentence A”，而房源的详细描述则作为“sentence B”。这样的设定有助于模型更准确地理解用户的搜索意图，并与相关房源进行精确匹配。

在构建训练数据集时，我们精心选择了正样本和负样本。正样本主要包括那些被用户点击或曝光的房源描述，以及与人工构造词相匹配的房源信息。负样本是通过随机负采样获得的，但保证“sentence B”不会直接包含“sentence A”，以避免模型学习到错误的匹配模式。

预训练采用了来自哈工大的中文版本 BERT 模型作为基础。

我们也设计了一种基于Bert 的用户序列化召回模型 B4SR，其训练过程分为两个阶段。预训练阶段，模型通过随机Mask 点击序列中 15% 的 token 来学习从完整序列的上下文中进行预测的能力，使模型具备了强大的上下文感知能力。Prompt-Tuning 阶段，将点击序列的最后一个 token Mask，并训练模型预测序列的末项。这种训练策略增强了模型在单向序列上进行预测的能力，使其更符合推荐系统的实际应用场景。

为了解决冷启动和稀疏性问题，序列不仅包含了房源 ID，还融入了房源的属性信息。与 EGES 方法不同，我们没有采用注意力机制将房源 ID 和属性信息融合成单一向量，而是直接将房源 ID 的 embedding 向量与各个属性信息的向量进行拼接，形成了房源的最终向量表示。这种处理方式避免了对 embedding 维度大小一致的要求。随后，我们将处理后的 embedding 向量输入到 Bert 模型中进行特征交互。在模型输出端，我们提取被 Mask token 对应的 embedding 向量作为用户向量表示。为了进一步增强模型的分类能力，我们将用户的 embedding 向量表示按维度大小切割回房源 ID 和各个属性信息的 embedding 向量，并采用了类似于 Youtube DNN 的结构对它们进行分类。这种分类方式使得模型能够直接对各个属性和房源 ID 进行分类预测。

在损失函数方面，我们采用了各个属性和房源 ID 的 softmax 损失之和作为最终的损失函数。这样的设计有助于模型在多个属性上同时进行优化，提高召回效果。

除了运用离线指标如命中率来评估召回模型外，我们还采用可视化手段来进一步分析模型效果。具体而言，我们会选取关键维度，如区域、商圈、面积价格等，并在这些属性维度下随机抽取部分房源。通过降维处理，将这些数据可视化，这种方法不仅提供了更直观的模型效果展示，还有助于我们更深入地理解模型在不同属性下的表现。

一般使用 I2I 模型时，我们首先获取用户实时浏览的房源序列，并获取每个房源的embedding 向量。然后利用 FAISS 等工具，查找与每个房源 embedding 最相似的房源。而使用 U2I 模型时，我们通过深度学习平台获取用户的 embedding，并使用 FAISS 等方法召回与用户 embedding 最相似的房源。

在实际应用中，线上系统通常会存在由多套模型生成的多种 embedding。针对这些embedding，我们采用了特定的融合方式进行召回。

常见的融合方式是为每套 embedding单独构建一个 Faiss 服务。然而，这种做法存在一些问题。比如，每套 embedding 可能需要构建多个 Faiss 服务，召回性能可能会受到影响，时延将取决于最差模型的召回时延。此外，由于不能保证召回的房源在每一路 Faiss 中都出现，可能导致分数融合有偏。

为了改进这一问题，我们采用了另一种融合方式。我们将每一套模型 embedding 进行归一化处理后，concat 作为最终的 embedding。这种方式只需维护一个 Faiss 服务，召回性能相对较高，且融合的得分是无偏的。

具体来说，对于查询向量 E_Q，我们将各路 embedding 归一化，并与对应的权重相乘。同样地，对于房源的 embedding E_D，我们也对每种模型的 embedding 进行归一化处理。然后，计算 E_Q与 E_D的内积，即可得到融合后的得分结果。这种方式分结果与第一种方式是等价的。

以商业地产推荐为例，由于业务的复杂性，即使我们采用基于 Faiss 融合的向量化召回，还面临以下几个问题：

分城市分业务类型召回：商业地产推荐涉及多种业务类型，如写字楼租售、商铺、厂房仓库的出租转让等。
分层召回：保证会员房源优于个人房源展示。
优质房源加权召回：需要对一些比较优质的房源进行加权召回。
召回足量房源：由于城市间房源数量差异巨大，从几百到几十万不等，这给召回策略带来了挑战。比如我们采用 Faiss 的参数设置（nlist=100，nprobe=20），即将房源聚成一百类，在检索时从二十个最相似的类中挑选 top n 最相似的房源。这种策略理论上只能召回五分之一的房源。对于房源数量较少的城市，这可能导致召回结果不足。

针对推荐中分城市分业务类型的召回需求，我们采用了多分区 Faiss 服务作为解决方案。该服务由我们的深度学习平台 WPAI 提供，通过构建分区，一个 Faiss 服务具备集成多个 Faiss 索引的能力。

在构建多分区 Faiss 服务时，我们将城市 ID 与房源的业务类型进行组合，生成唯一的分区 ID。每个房源在构建 Faiss 索引时都会被映射到对应的分区 ID 下。在用户进行检索时，根据用户的点击、连接、关注等行为序列推测其偏好的业务类型，并结合线上实际请求的业务类型，确定应该请求哪个分区下的房源数据。

对于分级召回的需求，采取了分别构建会员和个人 Faiss 服务的策略。在召回过程中，优先从会员房源中进行召回，仅当会员房源数量不足时，才会转向个人房源的Faiss 服务进行补充召回。

对优质房源的加权处理有两种方式。一种方式是将各个 embedding 向量拼接后，对每个元素乘以相应的加权系数。这些加权系数是根据房源的评估结果和优质性因子综合计算得出的。

第二种方式是将各种加权因子组合成一个新的向量，经过评估，这种方式并不适合当前的业务需求。因此，我们采用了第一种方式。

为了确保召回房源充足，当某个分区的房源量低于预设阈值时，会将这些房源整合到一个新的 Faiss 服务中。在这个新服务中，我们为房源的 embedding 增加了一个维度，用于标识该房源是属于会员还是个人。

在检索时，通过调整这个新增维度的权重，来灵活地控制会员房源和个人房源的召回优先级。此外，值得注意的是，这个新 Faiss 库的参数设置为 nlist=1 和 nprobe=1，相当于进行完全匹配。因此，能够确保召回全量的房源。

多任务，多场景多任务模型优化

精排的演进包括以下几个阶段：线性模型、树模型、深度神经网络、多任务，以及多场景多任务。

精排数据集的正样本是用户的真实点击行为，负样本则是基于用户点击位置以上的真实曝光但未点击的房源。同时我们过滤掉了误点击、经纪人以及异常用户（如爬虫）产生的数据。特征主要包括房源特征（如区域、商圈、价格、面积等）、上下文特征（如用户行为序列、搜索筛选行为等）、用户画像以及统计特征等。

针对业务方对商业房源的特殊曝光需求，我们在页面上实施了流量倾斜策略。这也导致了前排房源的偏差问题。为了纠正这种偏差，我们最初尝试了 PAL 和 Google 提出的偏置网络等偏差建模方法，但线上效果并不理想。最终，采用了手动去偏策略，仅将第 K 个位置之后的曝光点击房源作为训练样本。

在早期尝试中，采用了 Wide&Deep 深度学习模型。Wide 层主要负责特征记忆，如统计特征和交叉特征。而 Deep 层则专注于特征的自动交互。我们通过 Transformer+DIN Attention 机制来建模用户行为序列。Transformer 通过自注意力机制捕捉用户行为序列中各个 item 之间的关联关系。DIN Attention 则专注于建模用户行为序列中房源与待推荐房源之间的关联性。

当然，仅建模点击率（CTR）并不足以满足业务需求。提高用户和经纪人之间的连接效率同样重要，因为这直接关系到经纪人的利益以及用户能否快速找到想要的房源。此外，单一目标衡量也存在偏见，可能会导致一些质量较低但点击率高的房源排在前面，影响用户体验。为了更全面地优化推荐系统，我们除了考虑CTR 任务外，还需要引入连接任务。

我们最早尝试的多任务模型是 ESMM（Entire Space Multi-Task Model）。ESMM 是一种针对有任务依赖性的多任务模型，特别是在推荐系统中处理 CTR（点击率）和 CVR（转化率）这类具有顺序依赖性的任务时表现出色。在推荐场景中，用户首先需要点击一个物品，然后才可能发生转化行为，因此 CTR 和 CVR 之间存在天然的顺序依赖关系。ESMM 通过联合建模 CTR 和 CVR，解决了传统方法中单独建模 CVR 时面临的数据稀疏性和样本选择偏差问题。

在我们业务场景中，用户与房源的交互方式多种多样，包括点击、电话、微聊、收藏和分享等。这些行为反映了用户对房源的不同偏好程度，因此我们对它们分别建模，在 ESMM 上取得了一定的效果。然而，只关注用户的短期行为序列可能导致推荐的房源过于相似，缺乏多样性，从而影响用户体验。同时用户找房行为往往具有周期性，所以我们需要考虑用户的长期兴趣。

我们将距今 k 天前的最近 n 次行为作为用户的长期兴趣序列。这个序列能够反映用户在前一段时间的偏好和兴趣。在优化多任务模型的 Loss 权重时，采用了 GradNorm 方法。

由于 ESMM 模型在底层特征上是共享的，对于某些相关性较弱的任务，可能会出现所谓的“跷跷板现象”。为了解决这个问题，我们参考并尝试了几种业界表现优秀的解决方案。

首先，我们尝试了 MMoE+ESMM 的模式。MMoE（Multi-gate Mixture-of-Experts）的底层由多个共享专家组成，每个专家负责学习任务的一部分表达。同时，每个任务都有自己的 gate 网络，用于控制每个专家的权重。这种模式在我们的线上环境中取得了一定的效果。

此外，我们还尝试了 SNR+ESMM 的模式。与 MMoE 相比，SNR（Sub-Network Routing）具有更加灵活的专家子网络结构。然而，其效果与 MMoE 相当，并未带来显著的提升。

最终，我们线上采用的组合是：PLE+ESMM。PLE（Progressive Layered Extraction）结合了 MMoE 和 SNR 两个模型的特点，既包含任务特有专家，也包含共享专家。在 PLE 中，专家层可以叠加，各层专家之间可以进行交互。同时，每个任务通过 gate 来控制专家的权重。

除了上述尝试外，我们还探索了阿里巴巴提出的 ESCM2 模型。这个模型旨在解决ESMM 存在的两个偏差问题：预估有偏和独立性先验假设。但模型线上效果并不好，可能与理论假设和实际场景之间的差异有关。

在模型优化的过程中，我们还发现了一个问题：不同场景下模型的表现存在显著的差异。有些模型在某些场景下表现优秀，但在其他场景下效果平平，甚至在某些更小的场景下出现负面效果或毫无提升。

以商业地产推荐为例，用户在进入推荐频道和浏览详情页时，对推荐房源的需求是不同的。在列表页，用户可能更希望看到与他们刚才搜索或筛选的房源相似的房源；而在详情页，用户则更关注与当前房源相似的房源。这就需要我们针对不同场景进行分别建模。

然而，对于流量较小、用户行为稀疏的场景，模型往往难以有效地学习。同时，如果对每个场景都单独建模，后期的迭代和维护成本将会非常高昂。此外，不同场景之间既存在共性又存在特性，不同任务之间也有一定的关联。

因此，我们考虑进行多场景多任务的联合优化。但需要注意的是，相同任务在不同场景以及相同场景下的不同任务的特征语义和重要度是不同的。如果简单地将所有数据混合并使用统一的模型进行建模，就可能会忽略场景和任务之间的差异性，从而导致“跷跷板现象”——即某些任务或场景的效果提升了，而其他任务或场景的效果却降低了。

在尝试直接将场景特征输入到网络或以偏置形式加入网络后，我们发现离线环境下虽然有些许提升，但线上效果并不明显。因此，我们开始寻找业界更为有效的解决方案，并注意到了 LHUC（Learn Hidden Unit Contributions）这一流行模式。

LHUC 通过学习隐藏单元的权重来个性化网络。具体来说，LHUC 以个性化特征作为输入，并通过多层深度神经网络（DNN）生成一组权重向量，这些向量的维度与网络的中间层特征向量相同。然后，这些权重向量与主网络的中间层特征向量相乘，从而将个性化信息融入到主网络的中间层中。

此外，LHUC 还有一些改进的方法，如动态权重，它通过学习隐藏层连接权重的方式，进一步增强了网络的个性化表达能力。这种方法与阿里巴巴提出的 co-action 方法在某些方面是一致的，都旨在将个性化信息有效地融入到网络的中间层。

关于多场景多任务优化，我们采用了 LHUC-PLE 的模型结构。在这个模型中，输入层是多场景多任务共享的。

对于任务特有专家，我们通过 LHUC 融入了场景信息。这使得每个任务特有专家能够学习到针对特定任务和场景的特征表示。同时，我们也为任务共享专家通过 LHUC融入了场景信息。与任务特有专家不同的是，任务共享专家的输出是对所有任务在特定场景下的特征表示。

在模型中使用了 gate 网络来控制专家的权重。gate 的输入包括场景信息和任务信息，通过这种方式，可以动态地调整每个专家在不同场景和任务下的权重，实现更加灵活的模型调度。

这个模型在我们的推荐场景中取得了一定的效果，特别是在一些流量相对较大的场景下表现较好。

总结与展望

以上分享了 58 房产推荐从召回到排序等各个环节的算法实践经验，并深入探讨了如何优化多场景、多任务的模型。在未来，我们将继续细化这些优化工作，并积极探索将大模型应用到房产以及推荐领域的可能性。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

胡作梁

58安居客

资深算法工程师

2017 年毕业于同济大学，一直从事58房产推荐相关工作。目前主要负责五八、安居客商业地产、爱房推荐相关工作。

往期推荐

揭秘NVIDIA大模型推理框架：TensorRT-LLM

好的数据分析与业务洞察该如何做？

AI 大模型在汽车行业应用探索

DataOps 在联通数科的实践构建数据治理研发运营一体化能力

Data+AI，一站式指标平台的创新应用

大模型微调方案设计和能力整合

金融级实时数仓建设实践

数据存储的灵魂拷问：空间小、速度慢、不稳定，该咋办？

大数据安全治理与防范——网址反欺诈实战

货拉拉大数据新一代基础架构实践与思考

点个在看你最好看

SPRING HAS ARRIVED