一、背景

1.1 业务现状

为了持续增加平台价值，除了推动用户和商户在数量和质量上的不断提升之外，更高效地匹配用户需求和商户供给也是重要抓手之一。

为了提升匹配的效率，我们需要更充分、深入地理解用户需求和商户供给，并且尝试从用户视角出发来组织和管理供给。当前，“行业-类目-商户-商品”是一种较为常见的供给组织和管理方式，然而随着业务和行业的快速发展，这种组织方式带来的痛点日渐突显，举例来说：

• 部分指向性不明确的用户需求，较难得到适合的匹配结果。例如“周末陪宝宝去哪儿玩？”由于平台的匹配结果不理想，用户往往只能在线下完成类目决策，决定带宝宝去农家乐烧烤，再到平台上搜索相应的农家乐团购。
• 部分需求跨多个类目，匹配过程不够流畅。例如“周末和朋友去哪里放松一下？”用户在线下完成类目决策后，可选类目包括KTV、酒吧、密室、桌游等，但各类目的承载页面相互独立，用户需要在承载页面间来回切换。
• 在部分指向明确的类目中，用户仍然难以找到满足自己需求的供给。例如在医美类目下，因为缺乏相关知识，用户往往并不了解商户提供的形形色色的服务项目分别具有什么功效，适合什么部位，应该使用什么材料，无法高效地找到适合自己的服务供给。

上述问题的本质原因在于供给的组织方式主要是从行业视角出发，没有充分考虑到用户视角。在当前以满足用户需求为首要目标的市场环境下，我们需要迭代完善现有的供给组织方式。

1.2 问题解析

人类从需求层次出发，在市场中完成交易，最终需求得以满足，那么在市场中交易的过程可以被拆解为“起心动念->考虑->选择评估->交易购买->履约/服务”。并且，经由前三个阶段，用户的需求逐渐从粗粒度演变为细粒度，从抽象过渡到具象。下面将结合具体的例子来进行解读：

• 需求层次：在马斯洛需求层次中有一个情感层次，对应了人类丰富多样的情感需求，包含亲情、友情、爱情等等。作为一个母亲，与自己的宝宝之间往往存在一种强烈的母子情，并且希望不断去强化这种情感。
• 起心动念：为此，母亲往往都会尽力花较多的时间去陪伴宝宝。通过增加陪伴方式的维度，变为“陪宝宝玩”；通过增加时间、空间等维度，变为“周末陪宝宝去哪儿玩？”
• 考虑：对于上述问题，母亲会找出很多种方案，比如户外烧烤、农家采摘、主题公园等等。当她决定选用户外烧烤这一方案时，便会转化为具体的商品需求，如购买烤架。
• 评估选择：母亲于是在可触达的供给范围中进行选择。正如人们常说的货比三家，选择的依据会各不相同，如价格、质量、口碑等等。
• 交易购买：当完成选择之后，母亲便会进行交易，以换取商品或服务。
• 履约服务：即商品到货、完成服务等等。

市场是人类社会的一个子系统，电商平台则是市场中的一个子系统。同时，电商平台是一种线上化的子系统，它提供了搜索、推荐等形式的供给检索能力。当前的一个现状是：用户往往在线下完成了“起心动念”到“考虑”的过程，转化为具体的商品/服务需求，随后进入电商平台完成“选择评估”到“履约服务”的后续过程（如下图1所示）。而电商平台往往聚焦于后三个阶段的能力提升，容易忽略前两个阶段。

因此，用户较难形成在平台上完成“起心动念”和“考虑”的心智，而大部分电商平台按“行业-类目-商户-商品”的方式对供给进行组织和管理。最终，用户和电商平台之间形成了一种相互掣肘的关系。

事实上，相对于“烤架”这种明确的商品需求，用户还有很多抽象的、模糊的、不明确的需求，依然停留在前两个阶段。例如，周末陪宝宝去哪儿玩？周末和朋友去哪里放松一下？结婚前怎样才能让自己变得更美？暑假如何培养孩子的动手能力？同时，这样的需求往往跨越多个类目，或者在同类目下存在多种选择。

电商平台只有打破既有的掣肘关系，向用户提供前两个阶段（起心动念、考虑）的能力，才能进一步满足用户的需求。用户的决策成本进一步降低，决策过程更加连贯，用户体验也能得到相应的提升，同时用户在市场中的交易过程也能够进一步实现线上化。

以“行业-类目-商户-商品”作为参考，如果电商平台能够识别出用户在前两个阶段的需求，并且在其和供给之间建立新的关联关系，辅以搜索、推荐等检索能力，用户便有可能在线上完成前两个阶段。而知识图谱作为一种揭示实体之间关系的语义网络，用以解决上述问题显得尤为合适。

基于上述图谱，这位母亲可以直接在天猫上表达“户外烧烤”的需求，而非更具体的“烤架”；天猫也会将烤架以外其他和户外烧烤相关的重要商品反馈给这位母亲。从对应关系来看，AliCoCo的电商概念层对应至“考虑”阶段，商品层对应至“选择评估”阶段。显然，由于AliCoCo的存在，天猫能够从“考虑”阶段开始介入用户的交易过程。

由此推论，我们应该可以将图谱构建得更为完整，以覆盖“起心动念”阶段。在此阶段，人类的需求，按马斯洛需求层次，通过增加一个或多个维度约束，而被逐渐具象化。对于这样的维度约束，我们统称为“场景约束”。因此，我们将“考虑”阶段对应的需求称为“具象需求”；将“起心动念”阶段对应的需求称为“场景需求”。为此，我们希望构建一个本地生活综合性需求图谱（GENE：lifestyle GEneral NEeds net），如下图3所示。对于本地生活场景下所涉及的数百个综合性行业，我们认为新的供给组织方式更能贴近用户需求，也是从用户视角去解决供需匹配的问题。

2.2 具体方案

延续2.1中的构建思路，我们尝试构建一套多层次的图谱结构，并将“具象需求”和“场景需求”拆分为独立的层次，既避免了两种类型的需求合在同一层级中而引起混淆，又能对用户场景化的需求进行更详尽的拆解、更丰富的刻画。本地生活综合性需求图谱（GENE），主要由六部分构成，包含场景需求层、场景要素层、具象需求层、需求对象层、行业体系层和供给层，如下图4所示：

在场景需求层，我们用Human-Readable的短句来表征场景化的用户需求，如“国庆节陪3岁宝宝去哪玩”、“结婚前让自己变得更美”、“小学生提升思维能力”等。一个场景需求的表述中，通常会包含人物、目的、时间、空间、方式等要素，以“国庆节陪3岁宝宝去哪玩”为例，“3岁宝宝”是人物，“陪宝宝玩”是目的，“国庆节”是时间。

在场景要素层，为了更好地表达场景需求，我们将这些短句进行拆解，细化成多个细粒度的词汇，用这些词汇对场景需求中的人物、目的、时间、空间、方式等要素进行完整的覆盖和系统的组织，我们将其称为“场景要素”。

在具象需求层，由于场景需求的表述往往并不显式地指向某个具体的服务/供给，而是隐含了一批潜在的适合这一场景的服务/供给。例如，在“国庆节陪3岁宝宝去哪玩”这个例子中，户外烧烤、喂羊驼、玩滑梯、骑小马等都是适合这一场景需求的具体服务。所以我们需要将所有这些具体的服务通过短语的形式显式的展现出来，这些短语直接反应了用户具体的服务需求，被称之为“具象需求”。

在需求对象层，为了进一步的理解具象需求，我们将具象需求分为具体的服务需求所对应的对象，我们称之为“需求对象”，以及该服务中用户和对象之间的交互行为。例如，对于具象需求喂羊驼，可以分为羊驼（需求对象）和喂（服务交互），由于本地生活服务的多样性，围绕羊驼这一需求对象，除了喂羊驼外，还可以产生触摸羊驼、骑羊驼和看羊驼表演等多种具象需求。这一层除了包含需求对象节点外，也会涵盖需求对象的属性信息，以对需求对象进行更详尽地描述。例如对于具象需求户外烧烤，可分为烧烤（需求对象）、户外（需求对象属性）和体验（隐含的服务交互）。

在行业体系层，由于用户的场景需求和具象需求往往会跨越多个传统的服务类目，为了给用户需求确定一个具体的业务范围，我们还需要构建出各行业涉及的类目体系，作为上述各层构建的业务基础。

在供给层，包含内容这类虚拟供给和商户与商品这类实体供给，这些供给将会和具象需求和场景需求等节点进行关联，从而为用户需求提供相对应的供给支撑。例如，一个提供户外烧烤的供给将会关联上具象需求“户外烧烤”，并进一步关联上场景需求“国庆节陪3岁宝宝去哪玩”。

综上所述，在本地生活综合性需求图谱中，用户场景化的需求和具体的服务需求被分别表达成短句级别的场景需求和短语级别的具象需求。这两种需求分别通过场景要素和需求对象进行表达。最后，不同类型的供给都会和场景需求和具象需求相关联，从而以用户需求为纽带，提升供给和用户的匹配效率。

三、实现方法

当前，本地生活综合性需求图谱已经初步涵盖了用户在玩乐、医美和教育三个本地生活相关行业中的多元化需求。我们在图谱的构建过程中，自底向上按照行业体系层、需求对象层、具象需求层、场景要素层、场景需求层的顺序逐层进行构建，并将各层的节点与各种类型的供给建立关联关系。下文将以玩乐行业为例，对图谱每一层的构建细节以及涉及的算法进行介绍。

3.1 行业体系层

3.1.1 行业类目树的构建

在玩乐行业中，行业体系层包含了能够提供玩乐服务的类目，类目信息通过一个树形结构来表征。由于玩乐行业体系的构建，对专家知识的要求非常高，并且这部分的设计对后续各层的知识挖掘至关重要，因此我们没有直接进行人工定义，而是以当前我们成熟的行业类目树为基础，通过对其进行剪枝和分裂来构建。

首先在类目树中筛选出和玩乐相关的一级类目节点，包括“休闲娱乐”、“亲子”、“旅游”、“餐饮”等。对于每个一级类目，我们进一步筛选其和玩乐相关的下一级类目直至叶子类目，并剪去与玩乐无关的类目。此外，我们还对剪枝后的类目树中可以细分的玩乐相关的叶子类目进行分裂，例如将“洗浴”细分为“私汤”、“洗浴中心”等，最终得到完整的玩乐行业类目树。

3.1.2 类目的供给关联

确定了类目树后，我们还需要获取实体供给（商户和商品）和虚拟供给（内容，例如UGC）与类目的从属关系，从而为后续的一系列挖掘提供数据支持。由于商品和内容均可链接到商户，所以我们只需要获取商户与类目的从属关系即可。玩乐类目树是对我们已有的类目进行剪枝和分裂得到的，除了分裂出的新类目外，其余类目和商户的关系均可直接继承原有的结果。对于新分裂的类目，我们则需要重新构建商户和其之间的从属关系。

要判断一个商户属于哪个类目，最直观的依据就是商户名、商品名及商品详情，然而很多商户的商户名和商品包含的信息往往较少，增加了类目判别的难度。为了确保商户类目判别的准确性，我们引入更多的商户信息，包括商户UGC和商户画像，设计了一个多源异构数据融合判别模型，整体模型结构如下图5所示：

其中，不同来源数据的特征提取和处理方式如下：

• 商户名、商品名及商品详情：均为文本数据，直接通过BERT^[3]提取文本特征后输出。
• 商户UGC：由于商户的UGC往往数量非常多，为了对其信息进行有效利用，首先通过Doc2Vec^[4]的方式进行Encode得到UGC的特征后，再通过一个Self-Attention^[5]模块进行特征处理后输出。
• 商户画像：转成One-Hot特征后，通过全连接层进行非线性映射后输出。

上述三种特征相连接后进行融合，通过全连接层和softmax层实现最终的类目判别。基于多源数据的融合建模，商户信息得到了充分利用。以洗浴细分类目为例，仅利用商户名、商品名及商品详情数据，基于BERT判别，准确率为92%，而基于多源融合模型判别后，准确率提升到98%。

3.2 需求对象层

在需求对象层，我们希望能够挖掘出玩乐行业体系中各类目涉及的玩乐对象词作为该层的节点，这些词能够描述出用户在实际玩乐过程中的交互对象，这是用于组成具象玩乐需求的基础。为了确保玩乐对象挖掘的全面性，我们采用多源多方法的形式。

在数据上，我们采用来自商户和用户的相关文本作为挖掘语料。在方法上，我们采用两种方式来挖掘玩乐对象词：

• 第一种是无监督的扩充，在开始挖掘前运营会首先根据经验，提供一些玩乐对象词作为种子输入，我们提前利用语料构建无监督的Skip-Gram结构的Word2Vec模型，对业务输入的种子词提取词向量，并结合余弦相似度，快速扩充相关的对象词。
• 第二种是有监督的标注，我们将其定义序列标注问题，采用基于BERT+CRF的模型，在语料中自动识别出新的对象词。

在实践过程中，为了更高效的挖掘，我们将无监督环节扩充和质检后的对象词在语料中进行文本匹配，并将匹配结果转化为有监督标注环节的训练样本；同时对于有监督标注的结果，经过运营质检后，也会将其作为无监督扩充的输入，通过两个环节相结合，我们完成玩乐对象的挖掘，完整流程如下图6所示。此外，在运营人工审核玩乐对象词的过程中，对于一些业务已知的核心玩乐对象，也会直接输入业务侧已经沉淀的相关特征作为其属性，进一步完善玩乐对象的信息，例如对于“剧本杀”这一玩乐对象，增加相应的“实景”和“桌面”等类型属性。

在获取对象词后，我们还需要知道对象词属于哪个类目，以便下一步的具象需求挖掘及供给关联，为此我们构建对象词和类目之间的关系。通过各类目下的语料文本中提及对象词的次数来衡量两者关系，是最直观且准确率最高的方法。因此，我们直接使用对象词在每个类目下的语料中进行文本匹配，通过词频高低来确定关系。同时，我们进一步构建对象词之间的上下位和同义关系，当前常见的有通过投影和分类（如BERT句间关系模型）等方法来进行关系判别等有监督方法。在实际过程中，我们采用规则辅助人工的方式，基于对象词的统计特征及Pattern共现的结果指导人工快速完成构建。

3.3 具象需求层

3.3.1 具象需求挖掘

具象需求层可以看成是用户在玩乐行业中的具体服务需求的集合，每个具象玩乐需求是该层的一个节点，由玩乐对象叠加用户与对象之间的多元化的交互行为及对象描述信息得到，它通过短语的形式表达出用户对于玩乐服务供给的本质诉求。具体玩乐需求挖掘的流程流程可以分为两个步骤：

1. 候选短语生成：围绕玩乐对象词，生成大量包含玩乐对象的短语，作为具象玩乐需求候选集。
2. 短语质量判别：建立一个语义判别模型从候选集中提取真实的具象玩乐需求。

候选短语生成

在步骤1中，首先我们以需求对象词为核心，采用与玩乐对象挖掘相同的语料，进行候选短语的生成。常用的短语挖掘算法如AutoPhrase^[6]，是以Ngram来进行短语组合，而这种形式对于有需求对象的短语显得过于冗余，所以我们考虑基于句法结构来进行短语挖掘。

为了使生成短语符合句法的要求，我们以预设的句法关系为模板进行挖掘。在大规模语料中为了更高效地挖掘句法关系，我们基于更轻便的ELECTRA^[7]预训练模型获取句子各成分的Embedding后，再利用BiAffine^[8]预测其句法关系。通过依存句法分析，我们在各个类目的语料中挖掘出包含相应的玩乐对象且符合句法关系的短语。此外，需求对象层中对象的属性也会被用作对象描述进行短语生成。最终所有挖掘的短语，经过词频等统计特征粗筛后将作为具象玩乐需求的候选集，挖掘示例如图7(a)所示。

短语质量判别

在步骤2中，经过步骤1获取的候选集短语虽然符合预设的句法关系，但是从语义上仍然存在大量与用户实际需求不符的表述，通过抽检分析我们发现符合要求的短语不足10%。如何从海量的候选短语中挑选出反映真实的用户具象玩乐需求的短语成为亟需解决的问题。

AutoPhrase通过基于短语统计特征的判别模型进行短语打分，然而仅通过统计特征难以识别语义质量低的短语，为此我们进一步基于统计和语义特征联合建模，构建一个Wide&Deep^[9]结构的判别模型，对候选集合中的短语是否为具象玩乐需求进行判别，我们希望判别模型能过滤掉大量的低质短语，从而为运营节省大量的人力成本。判别模型的整体结构如图7(b)所示，其中：

• Wide部分，提取候选短语的全局和上下文的统计特征，通过全连接层进行非线性映射后输出。
• Deep部分，提取候选短语的深度语义特征，通过BERT完成相应特征的提取后输出。

上述Wide和Deep部分输出的特征相连接后进行融合，优势互补，经过全连接层和softmax层来实现最终的短语判别。在实践过程中，除了直接使用已经积累的短语标签作为正样本外，我们还通过预设一些常识性的Pattern从候选集中构造正样本，例如观赏[植物]、触摸[动物]，并对候选集采样构造负样本，完成初版模型的训练，之后结合主动学习，经过多轮迭代，模型最终达到92%的召回率和85%的准确率。通过质量判别后保留的短语则会交由运营人工审核提炼后成为最终的具象玩乐需求。

3.3.2 具象需求的供给关联

在具象需求层中，由于具象玩乐需求是由玩乐对象得到的，所以两者之间天然地建立了对应关系。而对于具象玩乐需求之间的上下位和同义关系，则可以基于其对象之间的关系及其句法关系，在人工审核的环节来辅助人工完成构建。除此之外，更重要的是需要将具象玩乐需求与实体供给（商户和商品）及虚拟供给（内容，例如UGC）进行关联。

我们将这个问题抽象为一个语义匹配的问题，通过具象玩乐需求与其对应的类目的供给的文本信息进行匹配来实现，其中，商户使用商户名文本信息，商品使用商品名和商品详情文本信息，UGC使用其自身文本信息。由于UGC和商品属于商户的一部分，所以具象玩乐需求与UGC/商品的关系也会加入其与商户关系的构建中。整体匹配流程如下图8所示，我们首先进行具象玩乐需求与UGC/商品的匹配，在此基础上再结合商户名文本的匹配结果，一起通过规则聚合后关联到商户。

由于具象玩乐需求数量众多，同时供给的文本信息通常包含多个子句，出于效率和效果的平衡考虑，我们将匹配过程分为了召回和排序两个阶段。

在召回阶段，我们粗筛出和具象玩乐需求可能有潜在关联的子句。对于具象玩乐需求，我们基于构建的同义关系，扩展具象需求的同义标签，并将其与子句文本进行粗粒度Pattern匹配，对于匹配中的子句则将进入到排序阶段进行精细化的关联关系计算。

在排序阶段，我们构建基于BERT句间关系分类的语义匹配模型，通过在BERT后增加全连接层和softmax层来实现分类。模型通过对召回阶段得到的粗筛样本进行预测，识别两者在语义上的匹配关系（关联/不关联）。最终供给关联关系的平均召回率和准确率分别达到90%和95%。

3.4 场景要素层

3.4.1 场景要素拆解

场景要素层包含了组成用户场景化需求的场景要素。如文初提及，要描述一个场景，需要交代特定的人物、时间、空间、目的等要素。例如，对于“国庆节陪3岁宝宝去哪儿玩？”这个场景化需求，我们可做如下拆解：时间-国庆节，人物-3岁宝宝，目的-亲情陪伴（陪宝宝玩）。所以我们按照上述方式，对场景要素进行拆解，以期对场景要素的挖掘和梳理尽可能的全面与系统。

3.4.2 场景要素挖掘

完成了场景要素拆解后，下一步就是要分别在每个拆解的类别中进行场景要素的挖掘。场景要素作为具象需求的场景化的信息，往往来自于用户的直观感受，所以挖掘的语料我们选择与具象玩乐需求关联的UGC的上下文语料。与需求对象挖掘的方法类似，我们将每个类别的已提炼总结的场景要素作为种子词，通过相关要素扩充和序列标注的方式完成场景要素的挖掘。

确定场景要素后，接下来的关键是完成场景要素与具象玩乐需求的关系构建，即对于每个场景要素，找出其适合的具象玩乐需求，如春季适合观赏樱花、孩子适合亲近动物。我们通过对UGC文本分析后发现，UGC中用户说到某一具象玩乐需求的同时，往往也会交代一些相关的场景要素信息，所以我们继续选择与具象玩乐需求关联的UGC的上下文语料，作为关系构建的数据来源。

最初我们采用基于Pattern的方法，通过归纳可用于判断场景要素和具象玩乐需求关系的Pattern，从语料中直接抽取包含两者的文本。但由于用户表达的多样性，不仅准确率无法保证，同时有限的Pattern也影响了召回，因此我们进一步尝试使用基于模型判别的方法提升泛化性，完善关系的构建。

由于我们使用的语料中的具象玩乐需求是已知的，如果将场景要素看成是具象玩乐需求的属性，那么问题就可以看成是一个属性级（Aspect-Based）的分类问题。参考属性级情感分类的做法^[10]，我们通过预设句子模板的方式，结合场景要素和具象玩乐需求构造出辅助句子，将属性级分类转换为一个类QA的句对分类问题。例如，对于已经关联了“喂羊驼”这一具象玩乐需求的某个语料：“这个周六我们到农家乐喂了羊驼”，其中一个辅助句子为“周末适合喂羊驼”。

我们采用BERT句间关系分类模型来实现句对分类，如图9所示。辅助句子与语料文本通过[SEP]相连后输入模型进行判别，模型输出判别结果（适合/不适合）。最后我们根据在所有语料上的关系提取结果，对每个场景要素和具象需求之间的关系进行投票计算评分后来确定两者的关系。

3.5 场景需求层

3.5.1 场景需求组装

在场景需求层，我们会将场景要素层和具象需求层的信息进行组装，从而生成大量的场景需求。组装出的场景需求，既可能仅含场景要素，如“国庆节陪3岁宝宝去哪儿玩？”不含任何具象需求，又可以同时包含场景要素和具象需求，如“周末去郊外摘草莓”中，周末、郊外是场景要素，摘草莓是具象需求。

3.5.2 场景需求判别

对于组装得到的场景需求，最重要的是保证其合理性，例如“周末”和“亲子”就是合理的玩乐场景，而“闺蜜”和“亲子”则是矛盾的玩乐场景。为此，我们首先需要计算场景要素之间的关系评分，从而指导场景需求的组装。场景要素只有依托具象需求，搭配上适合的玩法，参与组装的场景需求才有意义。因此，对于场景要素之间的合理关系构建，我们尝试以场景要素和具象需求的关系得分作为依据，通过关系传递评估两个场景要素之间的相关性。

在3.4.2节中，我们已经量化了场景要素和具象需求之间的关系评分，一个最直观的想法是通过场景要素-具象需求-场景要素的关系传递来进行计算场景要素之间关系的计算。如图10(a)所示，以具象需求“喂羊驼”为纽带，可以获取“亲子”和“闺蜜”两个场景要素的关系得分。

我们首先构建场景要素和具象需求的关系评分矩阵，考虑到玩法数量满足长尾分布的情况，对矩阵进行具象需求维度的列归一化处理，同时为了保证场景要素-场景要素矩阵的自相关系数为1，对归一化后的场景要素-具象需求矩阵进行L2行范数归一化处理，因此该归一化矩阵与自身转置的矩阵乘得到的新矩阵即可作为场景要素-场景要素的关系评分矩阵。