上班族找房，知识图谱能帮你！

1 引言

壳立方是一个创新产品，孵化于贝壳找房第二届 Hackthon 大赛，首次将知识图谱技术应用到地图找房产品形态中，旨在基于房产知识图谱技术来提升找房体验的产品。本文将介绍壳立方这个产品的技术原理，看一看知识图谱如何在找房中落地。

本文将分三个方面来讲：

背景介绍：用户需求和痛点有哪些；

详细介绍：产品设计和技术实现；

未来展望：列举一些下一步的优化方向。

2 背景介绍

我们从贝壳找房的数据中发现，找房需求中有相当一部分来自通勤族，比如，用户常常会围绕工作地点来查找周边附近的房源，他们不但对时间、通勤方式有明确的需求，而且也越来越注重居住品质，比如对周边的生活环境有所要求，用户会关注房子周边是否有大型商超、餐饮、学校等等。

基于以上需求，我们对已有的找房产品提出两方面改进：

一是在主页面增加通勤筛选模块。以用户搜索的地标为中心，通过用户指定的交通方式和时间区间来缩小找房范围，提供更加有效省时的筛查。

二是加入可缩放的局部视图，在用户选中合适的房源后，可以在主页面右上角局部窗口中以图的表现形式查看该房源的周边设施，比如餐饮、生活服务、交通等，这些呈现的背后主要是以知识图谱技术作支撑。

下面，我们主要从项目介绍，技术方案和未来展望三方面来详细阐述。

3 产品效果

UI 选择了落地在 web 端，主页面上加入了两个选择维度：时间范围和交通方式，这是通勤族的核心需求。现有的找房产品的常规逻辑是：当用户进入详情页，我们会给出周边设施详情和房源之间的距离信息。而实际上，周边设施是否齐全也是选房的一个重要考量因素，仅有距离信息已然不够。为此，我们改变以往贝壳找房通过详情页展示周边设施的方式，在主页面增加局部视图，让用户在首页就可以搜索合适房源，并直接查看房源的周边设施详情。

点击房源后，页面会以图谱的方式展示选定房源的周边设施，当鼠标移动到周边设施节点后会，除了会展示基础信息外，还包括特色标签，比如医院是否"三甲"等。这样就能摆脱你需要切换浏览器和贝壳找房来了解周边某设施情况的困扰。

当用户在搜索框输入某一地点时，地图可直接定位到该地点。除此之外，用户还可以指定时间区间和交通方式来缩小找房范围，查看该地点附近满足条件的房源。当放大地图选定合适的房源后，地图上可显示出该地点到房源的通勤路径和通勤时间。右上角的局部可以看到该房源周边设施的情况，不同类型的设施由不同 logo 标识，使界面更方便美观。

和传统产品相比，新增的通勤模块使得上班族找房目标更明确；局部视图又提供了一种更加省时有趣的方式方便大家查看周边详情。具体技术实现细节上，我们也增加了很多 trick，以下内容会具体讲解。

4 技术方案

壳立方技术架构如下图所示：

核心模块有：知识图谱、NLU、排序。主要分为基础数据层、挖掘数据层、计算服务层和前端 UI 四层，接下来我们重点介绍前三层。

4.1 基础数据层

数据层我们主要依托于楼盘字典中结构化数据和外部半结构、非结构化数据。其中结构化数据主要是来自楼盘字典、埋点日志等，这些也是贝壳打造真房源的基石。而外部半结构、非结构化数据主要包括问答数据、文章等日渐积累下的数据。

4.2 挖掘数据层

数据挖掘层，主要依赖于内部维护的房产领域内的知识图谱和 NLU 词表。基于用户搜索、点击日志构建用户画像，用于判定用户浏览房源时的偏好，构建个性化推荐体系。接下来我们着重介绍下前两项：知识图谱和 NLU 词表。

4.2.1 知识图谱

房产知识图谱主要是内外网的房产数据经过本体建模、归一化、融合、推理补充，统一加工处理成两种三元组形式：

属性型三元组 <实体 属性 属性值 >

关系型三元组<实体 关系 实体>

从而打造出房产行业图谱。我们现已覆盖 40 种类型实体，约 190 种关系。

从下图中我们更形象地看到知识图谱局部数据类型之间关联，共约 1500 种关系属性，图谱的数据规模：16 亿个实体、390 亿条三元组。知识图谱和传统的关系型数据库相比，更适合图数据的挖掘应用，是人工智能应用的首选数据模型。

4.2.2 NLU 词表

NLU 词表是在知识图谱中实体词的基础上再进行扩展，我们通过调研小区和社区的命名规律，充分挖掘社区词。在楼盘字典的基础上增加了 7w+个社区词。壳立方项目中，我们对 14 种类型的实体进行别名挖掘，调研各类型实体词的命名规律，并且利用已有的别名进行扩展，最后新增 153w+个别名，比如“北京大学第三医院”的别名是“北医三院”，“安慧北里秀园小区”的别名是“秀园”等等。挖掘这些数据主要是为了提高用户搜索的召回率，尽可能地返回用户想要搜索的内容。

为支持该项目的地标搜索以及通勤的筛选，我们引入优质 POI 数据，覆盖约全国 1500 万地标数据，其中北京地区约 30 万。我们离线计算一个小区附近 20km 内 POI 四种通勤方式（公交、驾车、骑行、步行）对应的通勤时间和通勤距离。通勤数据以 CVT(Compound Value Type)模式抽象设计，每条通勤数据携带通勤时间、通勤距离、通勤方式等信息，然后灌入 neo4j 中，支持后期检索。

4.3 计算服务层

服务层主要应用 NLU 技术和检索排序。NLU 技术主要是对搜索 query 的意图理解，当前支持两种意图：地名意图识别和通勤意图识别。其中，通勤意图识别是指对“距离西二旗地铁走路 30 分钟以内的房源”类似的问题识别出地标、通勤方式和时间，主要基于词表匹配和 BILSTM-CRF 模型相结合的方式。关于这一点背后的技术原理，我们在之前的文章中有详细介绍。

由于地标名的歧义性，检索排序会按照一定的策略将搜索结果重新排序，依照优先级排序返回给用户。比如，“五道口”可能是商圈、地铁不同类型的地点。这个问题可以抽象描述：将“五道口”设为 c，地标类型设为 t，t 取值 t1, t2, …tn。在给定 c 下，预测各地标类型的概率。概率值越大，就越可能为目标类型 t’。利用贝叶斯公式可得：

t' = argmax(p(t|c)) = argmax( p(c|t)p(t))

我们从之前积累的搜索点击日志中，通过计算每个类型下搜索该地标次数，以及归一各地标类型对应的数据量，获得上式的结果，将该结果直接作为目标类型返回给用户，或者根据概率值从大到小依次排序返回。

5 未来展望

以上就是项目架构的大体内容，正因为有了这些庞大的数据支撑和技术积累，该项目的功能才会较为完备，该项目是在贝壳找房第二届 Hackthon 大赛中孵化而出，并以小组第二的成绩胜出参加总决赛。但由于两天赛期的时间有限，用来参赛的作品只是对目前产品优化方向的一次探索，也是第一次将知识图谱应用在找房产品上，还存在许多不足，以下是我们针对目前的产品总结可以继续完善的地方：

5.1 产品形态

首先，展示周边设施详情的的局部视图一方面可以增加分类体系，并且通过用户调研去了解用户最感兴趣的类别来个性化取舍，而不是全部展示在页面上。

第二，当用户选定某个类别后，可以通过列表的方式去展示具体细分类别下的设施。

下图是优化第一版的局部视图模块，在小区周边抽象出配套的父类标签，分层展示。这里以“东花市北里西区”小区举例，展示了周边美食、购物、公交车站等配套信息，并在关联关系边上显示出统计信息。后续还可以在可视化方面继续完善，使得展示页面更友好。

5.2 知识推理

在底层技术上还需要进一步探索，目前知识图谱支持的局部视图模块推理的内容较少，大多来自楼盘字典结构化数据，而对各个来源的非结构化数据挖掘融合也非常有必要，有待尝试。

5.3 房源标签

在知识图谱的应用场景实践方面，本次参赛也尝试使用知识图谱技术来查看房源之间在标签体系下的关系，但只从评论里挖掘了一小部分标签数据来支持项目，还处于初步探索期。在标签挖掘技术方面上仍需要尝试不同的算法模型来提升效果，并且在未来可建立一套评估策略。

5.4 用户画像

在排序模块应该引入个性化因素，加入贝壳的用户画像，对于不同用户的不同偏好，得到千人千面的排序结果。

6 总结

壳立方是基于知识图谱技术在找房产品上的一次探索，虽然功能较为完备，但在用户体验方面仍然是一项较大的挑战。希望以后可以充分调研，从用户角度深挖痛点，努力将技术用来优化现有业务，将技术和需求相结合，使产品有更好的用户体验。其中具体涉及的技术详情可参考公众号发表的其他文章，后续也会奉献更加精彩有趣的技术分享，敬请期待~

作者介绍：

小白鹿（企业代号名），2018 年 7 月毕业于北京工业大学计算机学院，研究方向是自然语言处理。毕业后加入贝壳工作，目前主要负责行业数仓的知识图谱构建工作。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/7JUXhXx8OA7zbIOLy-4f_w