T-LEAF：分类系统学习和评估框架

分类系统是用于对信息进行分类和组织的知识组织系统。分类系统使用文字（而不是数字或符号）来描述事物，并使用层次结构来将事物进行分类。分类系统的结构反映了这些事物是如何相互关联的。例如，超赞房东是房东的一种类型，而房东是爱彼迎用户的一种类型。分类系统提供了重要的术语控制，使下游系统能够通过其定位信息以及分析一致的、结构化的数据。

爱彼迎在前端产品中使用分类系统来帮助房客和房东发现优质的住宿、体验、内容以及客户支持产品。爱彼迎也在后台工具中使用分类系统来结构化数据、组织内部信息以及支持机器学习应用程序。

我们需要对爱彼迎社区成员所面临的问题进行分类，因为：

• 房东和房客需要能够向爱彼迎描述问题，以便获得相关的帮助建议和获得最好的用户支持。
  

• 爱彼迎的社区支持专家需要能方便快速地获取到能够解决房东和房客问题的操作流程。
  

• 爱彼迎业务部门需要了解房东和房客在何处遇到问题以及为什么会遇到该问题，以便我们改进我们的产品，让爱彼迎的体验更好。

联系原因分类系统是一个全新的、统一的问题分类系统。在联系原因分类系统之前，社区支持部门分别为房东和房客、社区支持大使、机器学习模型独立提供分类系统，每个分类系统使用不同的内容和结构来对相同的问题进行分类，并依靠手动映射来保持同步。

将这些彼此独立的分类系统整合到联系原因分类系统是我们第一次在爱彼迎尝试此类项目。开发一个这样的新分类系统需要迭代学习：由分类专家来创建/修订分类系统；发布给机器学习模型、产品和服务；评估分类系统的质量并识别出需要改进的领域。在此项目之前，并没有一个系统的流程来评估分类系统的进展或性能，并且迭代过程大多是主观和定性的。为了对分类系统的质量进行更加量化和客观的评估，并以此来加速迭代开发，我们创建了 T-LEAF（Taxonomy Learning and EvaluAtion Framework），一个分类系统学习和评估框架，来对分类系统从覆盖率、有用性和一致性三个方面进行量化评估。

在爱彼迎社区支持的领域，我们经常需要在没有真实用户数据和清晰的下游应用之前，创建新的分类系统或分类系统节点。由于没有一致的量化评估框架来生成输入指标（Input metrics），我们很难在新的分类系统应用到下游应用时衡量系统的质量。

分类系统通常是通过以定性为中心的方法开发的^[1]。当我们开始开发新分类系统原型时，我们综合评估了当前系统的用户反馈，并招募多了名房东和房客进行多轮次的用户调研来洞察用户需求。虽然像领域专家评审之类的定性评估在识别大的机遇和挑战时是有帮助的，但由于样本量小和参与调研的用户的潜在样本偏差，它不足以提供大规模评估。

开发和发布分类系统是一个漫长且渐进的过程，可能需要几个季度的使用才能获得真实可靠可量化的反馈。一个典型的过程包括：

• 探索和开发 基于产品需求或数据驱动分析对分类系统进行探索和开发。

• 改动生产系统 将新的分类系统集成后端环境和前端界面中，例如一些必要的产品设计和内容文案的改动。

• 机器学习模型（重新）标注训练数据，重新训练，以及部署机器学习模型。
  

• 对用户的反馈进行打点以及数据分析。

 图1: 分类系统的典型开发迭代过程

在 T-LEAF 诞生之前，分类系统的开发过程完全依赖输出指标（Output metrics）来衡量新分类系统的有效性，这意味着：1）重大改动需要很长的时间进行实验和测试；2）小的改动并没有被测试所覆盖，例如添加或更新分类系统节点。这两个痛点可以通过使用 T-LEAF 框架提供的持续定期的评分机制解决。

T-LEAF 的开发是为了在分类系统中包含更多的量化评估，以解决上述痛点，实现加速分类系统开发迭代。

T-LEAF 框架从三个方面衡量分类系统的质量：1）覆盖率，2）有用性和3）一致性。

图2: T-LEAF 的结构

覆盖率表示分类系统是否良好的界定了真实数据对象的范围。以联系原因为例，覆盖率分数评估分类系统是否恰当地捕捉到房客和房东联系爱彼迎社区支持团队的原因。当“覆盖率”较低时，许多用户问题（数据对象）并没有被分类系统覆盖到，这些问题最终成为“其他”或“未知”。

覆盖率分数 = 1 - 分类为“其他”或“未定义”的数据占比

有用性显示了对象在分类系统结构中是否均匀地分布到有意义的类别中。如果分类系统的粒度过粗（例如，节点或类别太少），数量有限的选项可能无法充分区分正在描述的对象。另一方面，如果分类系统的粒度过细，它可能无法解释对象之间的相似性。

在 T-LEAF 中，给定有 n 个样本的基准数据集（例如，不同的用户问题），我们假设包含 sqrt（n）个节点^[2]的分类系统在“粗粒度”和“细粒度”之间提供了良好的平衡。对于任何输入 x （分类系统节点数量），我们计算出一个结果在 (0,1] 范围内的拆分分数以评估分类系统的“有用性”：

我们希望通过假设数据服从正态分布来评估数据偏差，例如，对于 100 个不同的用户问题，如果我们拆分为 1 个类别（'粗粒度'）或 100 个类别（'细粒度'），那么对应的有用性得分将接近 0；如果我们拆分为 10 个类别，对应的有用性得分将为 1。

一致性反映给定分类系统的评分者间信度（inter-rater reliability）。我们提出了两种评估一致性的方法。

基于人工标注的评估值者一致性

多个人工标注者根据分类系统的定义对同一份数据进行标注，然后我们使用科恩卡帕系数（Cohen’s Kappa） 计算出结果在 [-1,1] 范围内评分者间信度。

基于机器模型训练准确率

让多名人工评分者标注同一个数据集是很昂贵。实际上，大多数的数据仅仅由一位评分者标注。在爱彼迎的社区支持中，每个客户问题/工单由一名客服专员来处理，客服专员根据分类系统标记工单的问题类型。我们使用单一评分者标注的数据集训练机器学习模型，然后将此模型应用于训练数据来衡量训练准确率。如果分类系统定义明确（即具有高度的“一致性”），那么相似的客户问题（数据对象）应该有相似的标签，即使这些标签来自于不同的客服专员。在有高度一致性的训练数据集上训练的机器学习模型应该具有很高的训练准确率。

我们通过实验对 1）基于多位标注者得出评分者间信度的方法，和 2）基于单一评分者标注的数据集训练机器学习模型得出训练准确率的方法进行了比较。

结果如表 1 所示。我们观察到，对于这两种方法：1）分类系统的前两个级别的准确性相似（L1 和 L2 问题会在下一节中定义）；2）两种方法都有相似的混淆区域。也就是说，如果分类系统的节点定义足够清晰，足以让社区支持专员完成标注，那么一致率会增加，机器学习模型也可以更好地捕捉到人类的意图。相反，如果社区支持专员对选项感到迷惑或者无法选择合适的类别，机器模型训练准确率也会受到负面影响。

创建一个多人工标注者数据集花费了 1 名分析师和 9 名标注员大约一个月的时间。相比之下，在单一评分者标注数据集数据上训练机器模型并计算训练准确率仅需花费一名机器学习工程师一天的时间。如表 1 所示，基于机器学习训练准确率和基于人工标注的评估方法在衡量分类系统的一致性上给出了相似的结果。

联系原因分类系统由大约 200 个节点组成，分布在一个三级层次结构中，第 1 级（L1）是较为的宽泛的类别、第 2 级（L2）是较为细化的类别和第3级（L3）详细具体的问题。例如：

• 预订相关问题（L1）

• 清洁和健康问题（L2）

• 房源中有烟味或其他气味（L3）

相比于旧有的分类系统在不同的部分之间有着不可预测的粒度水平，联系原因分类系统提供了一个一致的三级结构，更好地支持了持续评估框架。在旧分类系统过渡到新分类系统（联系原因分类系统）的过程中，我们使用了 T-LEAF，使得新分类系统在发布到生产环境之前就更快的获得反馈并提供可量化的质量控制。

图3: 使用 T-LEAF 对分类系统的进行开发、评估、部署的迭代流程

首先，我们把一个真实数据集给到爱彼迎社区支持实验室（CS Labs），一群技术熟练的社区支持大使，来进行人工标注。然后，我们使用 T-LEAF 分数作为分类系统开发过程的输入。使用该输入，核心机器学习（CoreML）工程师团队和分类系统团队在一起紧密合作，并在生产环境运行实验前就显著地提高了 T-LEAF 分数。

为了在生产环境中验证联系原因分类系统，我们审查它在爱彼迎客服机器人^[3]中的表现。爱彼迎客服机器人是社区支持的核心产品之一，它可帮助房客和房东自助解决问题，并在必要时联系社区支持大使。我们发现，T-LEAF 评估出的联系原因分类系统在覆盖率、有用性和一致性指标上的改进也转化为在问题覆盖率、自助解决有效性和问题预测准确率的实际改进。

表2: 新 / 旧分类系统的 T-LEAF 评分

在发布联系原因分类系统后，我们回顾了前 4 个月的生产环境数据，发现有 1.45% 的问题标注为“其他问题”，这比旧分类系统少了 5.8%。这与 T-LEAF 覆盖率得分的提高比率一致（比以前的版本覆盖率高 5.3%）。

例如，在新分类系统中，有两个新节点，分别称为 “取消和退款>取消您的预订>帮助房东取消” 和 “取消和退款>取消您经营的预订>帮助房客取消” 旧分类系统只有 “预订>取消>房东发起” 和 “预订>取消>房客发起” 节点，旧分类系统的节点没有颗粒度来表明来寻求客服支持的房客或房东不是申请取消的发起者。

有了这些新的节点，我们开发了一个机器学习模型，引导用户走向特定的取消操作流程^[4]。这确保了房客可以收到正确的退款，房东取消订单的处罚也仅会在正确的情况下被应用，所有这些流程都不需要联系到爱彼迎社区支持大使。

图4: 爱彼迎客服机器人提供的的自助解决方案

与基于旧分类系统上建立的问题预测模型相比，基于新分类系统建立的机器学习模型准确率提高了 9%。这意味着机器学习模型预测的问题类别更有可能与社区支持大使选择的类别相同。

图5: 用户 / 客服专员和机器学习模型的一致性

T-LEAF 是一个评估分类系统的量化框架，可以让分类系统更快的迭代，同时降低发布新分类系统带来的切换风险，并且对我们所有的使用方（房客、房东、社区支持大使和爱彼迎业务部门）带来积极的影响。T-LEAF 框架对分类系统的覆盖率、有用性、一致性三个方面进行评分，并且现已应用在社区支持的生产环境上分类系统中，结果表明，使用此方法论来量化评估分类系统可以带来更好的模型表现和更高的问题覆盖率。

作为分类系统持续改进框架的一部分，T-LEAF 的开发、试运行和正式发布是跨团队的合作的结果。CoreML 工程师团队与分类系统团队、产品团队和 CS Labs 紧密合作，一起创建了这个用于问题分类和预测的迭代开发模型。在尝试了使用新的工作方式实现联系原因分类系统后，我们相信，随着我们继续将T-LEAF 方法论应用于将来更多的分类系统中，我们将看到更多正向的结果。

[1]: Szopinski, D., Schoormann, T., & Kundisch, D. (2019). Because Your Taxonomy is Worth IT: towards a Framework for Taxonomy Evaluation. ECIS. https://aisel.aisnet.org/ecis2019_rp/104/

[2]: Carlis, J., & Bruso, K. (2012). RSQRT: AN HEURISTIC FOR ESTIMATING THE NUMBER OF CLUSTERS TO REPORT. Electronic commerce research and applications, 11(2), 152–158. https://doi.org/10.1016/j.elerap.2011.12.006

[3]: Intelligent Automation Platform: Empowering Conversational AI and Beyond at Airbnb. https://medium.com/airbnb-engineering/intelligent-automation-platform-empowering-conversational-ai-and-beyond-at-airbnb-869c44833ff2

[4]: Task-Oriented Conversational AI in Airbnb Customer Support. https://medium.com/airbnb-engineering/task-oriented-conversational-ai-in-airbnb-customer-support-5ebf49169eaa

作者：Mia Zhao，Peggy Shao，Maggie Hanson，Peng Wang，Bo Zeng，译者：Keyao Yang，校对：Huifan Qu。

感谢 CS Labs 对现有和新分类系统的标注支持！特别鸣谢 Joy Zhang，Lianghao Li 给予的帮助，以及各位领导和同事对于本文的支持！

如果你想了解关于爱彼迎技术的更多进展，欢迎关注我们的 Github 账号（https://github.com/airbnb/） 以及微信公众号（爱彼迎技术团队）