语音数据处理指南

随着企业开始进行人工智能技术的探索,三个特定的领域引起了很多关注:计算机视觉、自然语言应用和语音技术。世界知识产权局(WIPO)最近的一份报告发现,这三个领域的专利占了人工智能相关专利的大部分:计算机视觉占49%,自然语言处理(NLP)占14%,语音技术占13%。

企业里有很多非结构化和半结构化的文本数据,而很多公司已经拥有了 NLP 和文本分析的经验。虽然比较少的公司拥有收集和存储图像或视频的基础设施,但计算机视觉是许多公司开始探索的领域。深度学习和其他技术的兴起促使初创公司商业化了一些计算机视觉的应用,包括安防和合规、媒体和广告以及内容生成。

一些企业也在探索话音和语音的应用。自然语言和语音模型的最新进步提升了准确性,从而开辟出了一些新的应用。在企业语音应用方面,呼叫中心、销售和客户支持以及个人助理等应用处于领先地位。在消费者应用方面,语音搜索、智能音箱和数字助理正越来越普及。虽然远非完美,但目前这一代话音和语音应用已经足够得好,从而推动了语音应用的爆炸性增长。语音技术的潜力的一个早期线索是语音驱动的搜索的增长。Comscore 估计,到 2020 年,大约一半的在线搜索将使用语音。Gartner 建议企业重新设计其网站,以支持视觉和语音搜索。此外,从 2018年到 2019 年,智能音箱预计将增长 82% 以上。到今年年底,此类设备的安装数将超过 2 亿台。

音频内容数据也正在呈现爆炸式的增长。这就需要使用语音技术进行搜索和挖掘,从而能解锁这些新内容。例如,根据《纽约时报》最近的一篇文章,在美国“每个月中大概有三分之一的人会至少收听一次播客”。播客节目的增长并不仅限于美国,包括中国在内的世界各地的播客量都在增加。

语音和对话应用挑战性

在文本和 NLP 或计算机视觉领域里,程序员可以简单地开发出一个应用。但语音应用(不是简单的语音命令)对许多企业来说仍然具有挑战性。口语比书面文字有更多的“噪音”。例如,在阅读了许多播客脚本后,我们可以证明语音对话的脚本仍然需要大量的编辑工作。即使你可以获得最好的转录(语音到文本)技术,你也通常也会看到一个包含暂停、填充、重启、插话(在对话的场景里)和不合语法结构的句子的脚本数据。脚本还可能包含需要改进的段落,因为有人可能“在开脑洞”或难以准确地表达特定的观点。此外,由转录产生的脚本可能无有在正确的位置打标点或进行大写处理。因此,在许多应用中,脚本的后处理就需要人类编辑参与。

在计算机视觉(现在是 NLP )中,我们已经处于数据至少与算法同等重要的阶段。具体而言,预先训练的模型已经在计算机视觉和 NLP 的若干任务中提供了最好的性能。那么语音领域怎么样?“一个模型能满足所有的”语音模型没能出现的原因有下述几个:

  • 存在各种声学环境和背景噪音:室内或室外、在汽车里、在仓库里或在家庭等。
  • 可能需要支持多种语言(英语、西班牙语、中文普通话等),特别是在说话人在对话过程中使用(或混用)多种语言的情况下。
  • 应用类型(如搜索、个人助理等)会影响对话流程和词汇表。
  • 根据应用的复杂程度,需要针对特定领域和主题来调整语言模型和词汇。这一点对于文本和自然语言应用也成立。

构建语音应用

尽管存在挑战,但正如前面我们所指出的那样,语音技术和语音应用已经出现了相当多的让人激动的内容。虽然我们尚未达到可以使用通用解决方案为各种语音应用“供电”的阶段,同时也没有能够跨多个领域的语音智能助理。

然而,已经有一些很好的基础模块可以被用来组装有趣的语音应用。为了帮助正在探索使用语音技术的公司,我们整理了以下指南:

  • 集中你的注意力。正如我们所指出的那样,当前一代语音技术无法实现“一个模型能满足所有的”场景。因此最好将重点放在特定任务、某种语言和某个领域。
  • 理解应用想要实现的目标,然后再去看所需要的技术类型。如果你能知道应用的 KPI,那么就可以使用这些 KPI 来找到为特定应用领域实现这些度量标准所需要的语言模型。
  • 在“真实数据和真实场景”里进行实验。如果你计划开始使用现成的模型和服务,请注意“真实数据和真实场景”的重要性。在许多情况下,初始测试数据并不能代表用户与想部署的系统进行交互的方式。
  • 获取每个特定任务的标记样本。例如,识别英语中的“cat”和中文普通话中的“猫”将需要不同的模型和不同的标记数据。
  • 制定数据采集策略以保证收集到合适的数据。确保构建的系统可以随着收集到更多的数据而持续学习,以及制定一个支持持续改进的迭代流程。
  • 语音应用的用户关心的是结果。语音模型只有在推导出洞察力并使用这些洞察力而采取行动时才有意义。例如,如果用户要求智能音箱播放特定的歌曲,那么对该用户唯一重要的就是音箱能播放那首歌曲。
  • 自动化工作流程。理想情况下,所需的字典和语音模型可以在没有太多干预(来自机器学习或语音技术专家)的情况下进行更新。
  • 语音应用是复杂的端到端系统,因此要尽可能地进行优化。单单一个语音识别系统就是由我们在前一篇文章中描述的多个模块所组成。训练和再训练模型的代价可能很高。根据应用和场景,延迟和持续连接也是重要的考虑因素。

从 NLU 到 SLU

我们仍处于企业级语音应用的早期阶段。在过去的12个月中,我们看到预训练的自然语言模型取得了快速进展,这些模型在多个 NLP 基准测试中创造了新记录。开发人员开始采用这些语言模型,并针对特定领域和应用对它们进行微调。

对 AI 应用来说,语音数据又增加了另一层的复杂性,它超越了自然语言理解(NLU)。口语理解(SLU)需要能够从口语中提取含义。虽然 SLU 还没有被用于语言或语音应用,但好消息是,已经可以使用现有的 SLU 模型构建简单、特定用途的语音应用。为了找到正确的应用场合,企业需要了解当前技术和算法的局限性。

与此同时,我们将会一步一步地进行。正如 Alan Nichol 在一篇关注基于文本的应用的博文中指出的那样,“聊天机器人只是实现真正的 AI 助手和自动组织的第一步。”同样地,今天的语音应用揭开了即将发生的事情的一角。

Spark模型在Uber机器学习平台应用

Evolving Michelangelo Model Representation for Flexibility at Scale
Evolving Michelangelo Model Representation for Flexibility at Scale

Michelangelo 是 Uber 的机器学习(ML)平台,可以训练并服务于整个公司范围内生产环境中的数千种模型。该平台被设计成了一个端到端的工作流,目前支持经典的机器学习、时间序列预测和深度学习模型,可以涵盖大量的用例,从 生成市场预测、响应客户支持工单 到 准确计算预计到达时间(EAT) 以及使用自然语言处理(NLP)模型在驾驶员 App 中提供 一键式聊天功能。

大多数 Michelangelo 模型都是基于 Apache Spark MLlib 的,这是一个可伸缩的 Apache Spark 机器学习库。为了处理高 QPS 的在线服务,Michelangelo 最初仅通过内部定制的模型序列化和表示支持 Spark MLlib 模型的一个子集,这使得客户无法灵活地试验任意复杂的模型管道,限制了 Michelangelo 的扩展速度。为了解决这些问题,我们改进了 Michelangelo 对 Spark MLlib 的使用,特别是在模型表示、持久性和在线服务方面。

在 Michelangelo 中改进 Spark MLlib 用法的动机

我们最初开发 Michelangelo 是为了为生产环境提供可扩展的机器学习模型。它对基于 Spark 的数据摄取调度、模型训练和评估以及批量和在线模型服务部署提供端到端的支持,在 Uber 获得了广泛的认可。

为了将 Spark 用于数据预处理和低延迟服务,并使用 GPU 进行分布式深度学习训练,Michelangelo 针对深度学习用例使用了一致的 Spark 管道架构。
为了将 Spark 用于数据预处理和低延迟服务,并使用 GPU 进行分布式深度学习训练,Michelangelo 针对深度学习用例使用了一致的 Spark 管道架构。

最近,Michelangelo 已经发展到可以处理更多的用例,包括提供在核心 Michelangelo 之外训练过的模型。例如,深度学习模型的扩展和端到端加速训练需要在不同环境中执行操作步骤,以便利用 Spark 的分布式计算转换、Spark Pipelines 在 CPU 上的低延迟服务以及使用 Horovod(Uber 的分布深度学习框架)在 GPU 集群上的分布式深度学习训练。为了使这些需求更容易实现,并保证训练和服务的一致性,有一个一致的架构和模型表示很重要,它可以利用我们现有的低延迟的基于 JVM 的模型服务基础设施,同时提供正确的抽象来封装这些需求。

具有活动 Spark 会话的外部环境可以无缝地反序列化来自 Michelangelo 的经过训练的管道模型,并序列化供 Michelangelo 生态系统的其余部分使用的模型。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标识并不意味着 Apache 软件基金会的认可。
具有活动 Spark 会话的外部环境可以无缝地反序列化来自 Michelangelo 的经过训练的管道模型,并序列化供 Michelangelo 生态系统的其余部分使用的模型。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标识并不意味着 Apache 软件基金会的认可。

另一个动机是使数据科学家能够使用 PySpark 在熟悉的 Jupyter 笔记本(数据科学工作台)中构建和试验任意复杂的模型,同时仍然能够利用 Michelangelo 生态系统可靠地进行分布式训练、部署和服务。这也为 集成学习 或 多任务学习 技术所需的更复杂的模型结构提供了可能性,同时让用户可以动态地实现数据操作和自定义评估。

因此,我们回顾了 Michelangelo 对 Spark MLlib 和 Spark ML 管道 的使用,概括了其模型持久性和在线服务机制,目的是在不影响可伸缩性的情况下实现可扩展性和互操作性。

Michelangelo 最初推出的是一个统一的架构,它负责管理紧耦合的工作流和用于训练和服务的 Spark 作业。Michelangelo 对每种支持的模型类型都有特定的管道模型定义,并使用内部定制的 protobuf 表示经过训练的服务模型。离线服务通过 Spark 处理;在线服务使用添加到 Spark 内部版本的自定义 API 来处理,以实现高效的单行预测。

向本地 Spark 序列化和反序列化转变在模型持久化管道阶段(Transformer/Estimator)层面上实现了灵活性和跨环境兼容性。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标识并不意味着 Apache 软件基金会的认可。
向本地 Spark 序列化和反序列化转变在模型持久化管道阶段(Transformer/Estimator)层面上实现了灵活性和跨环境兼容性。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标识并不意味着 Apache 软件基金会的认可。

最初的架构支持通用机器学习模型(如广义线性模型 GLM 和梯度增强决策树模型 GBDT)的大规模训练和服务,但是自定义的 protobuf 表示使添加对新 Spark 转换器的支持变得困难,并排除了在 Michelangelo 之外训练的模型。当新版本的 Spark 可用时,Spark 的自定义内部版本也使得每次的升级迭代变得复杂。为了提高对新转换器的支持速度,并允许客户将自己的模型引入 Michelangelo,我们考虑了如何改进模型表示并更加顺畅地添加在线服务接口。

Michelangelo 的架构和模型表示法的演变

Michelangelo 的架构必须处理由不同功能需求带来的复杂性,并保持训练和服务环境之间的一致性。 Uber 的机器学习工作流通常很复杂,涉及不同的团队、库、数据格式和语言;为了使模型表示和在线服务接口可以恰当地演化,我们需要考虑所有这些维度。
Michelangelo 的架构必须处理由不同功能需求带来的复杂性,并保持训练和服务环境之间的一致性。

Uber 的机器学习工作流通常很复杂,涉及不同的团队、库、数据格式和语言;为了使模型表示和在线服务接口可以恰当地演化,我们需要考虑所有这些维度。

部署并提供机器学习管道模型服务包括模型前面的所有转换和操作步骤。
部署并提供机器学习管道模型服务包括模型前面的所有转换和操作步骤。

要部署用于服务的机器学习模型,需要部署整个管道,包括模型前面的转换工作流。通常还需要打包数据转换、特征提取、预处理甚至预测后转换。原始预测通常需要解释或转换回标签,在某些情况下需要转换到不同的维度空间,比如日志空间,以便下游服务使用。它也可以用于通过额外的数据加强原始预测,如它们的置信区间,通过 概率校准 来校准概率。我们想要一个能够反映 Spark MLlib 模型固有管道步骤的模型表示,并允许 Michelangelo 与外部工具进行无缝交互。

选择一种最新的模型表示

在评估可供选择的模型表示时,我们评估了不同的需求,包括:

  • 表示广义转换序列的能力(必需)
  • 处理在线用例的轻量级服务的可扩展性(必需)
  • 支持使用非 Michelangelo 原生 Spark 工具替换存储在 Michelangelo 中的模型(必需)
  • 训练时和服务时的模型解释偏差风险低(非常想要)
  • Spark 更新速度要快,并且易于编写新的估计器 / 转换器(非常想要)

我们考虑的一种方法是使用 MLeap,这是一个独立的库,它通过一个专用的运行时来执行管道,提供了管道和模型序列化(到 Bundle.ML)和反序列化支持。MLeap 具有所需的表达能力和对轻量级在线服务的支持。但是,它有自己专有的持久化格式,这限制了与序列化和反序列化普通 Spark MLlib 模型的工具集的互操作性。

MLeap 还引入了服务时行为偏离训练时评估的风险,因为在技术上,正在提供服务的模型加载时的格式与训练时内存中的格式不同。MLeap 还降低了 Spark 更新的速度,因为除了 Spark MLlib 本地使用的方法之外,还必须为每个转换器和估计器添加单独的 MLeap 保存 / 加载方法。Databricks 的 ML 模型导出 dbml-local 提供了类似的方法。

我们考虑的另一种方法就是将训练模型导出到一个标准的格式,如 预测模型标记语言(PMML) 或 可移植分析格式(PFA),它们都具备我们需要的表达能力并且可以和 Spark 交互,Spark 直接提供了 PMML 支持,而 aardpfark 可以将 Spark 模型导出为 PFA。然而,这些表示还是存在服务时行为偏离方面的风险,我们认为这一风险高于 MLeap,因为一般标准在特定的实现中通常会有不同的解释。这些标准在 Spark 更新速度方面也带来了更大的阻碍,因为根据 Spark 变化的性质,标准本身可能需要更新。

我们发现,最直接的方法是使用标准的 Spark ML 管道序列化来表示模型。Spark ML 管道展示了我们想要的表达能力,允许与 Michelangelo 之外的 Spark 工具集交互,展现出了低风险的模型解释偏差,对 Spark 的更新速度影响较小。它还有助于编写自定义的转换器和估计器。

我们看到,使用 Spark 管道序列化的主要挑战是它与在线服务需求的不兼容性(Nick Pentreath 在 2018 年的 Spark AI 峰会 上也讨论了这一点)。这种方法会启动一个本地 Spark 会话,并用它来加载一个训练好的 Spark MLlib 模型,这相当于在单台主机上运行一个小型集群,内存开销和延迟都很大,使它不适合许多在线服务场景要求的 p99 毫秒级延迟。虽然现有的用于提供服务的 Spark API 集在性能上还不足以满足 Uber 的用例,但我们发现,我们可以在这种开箱即用的体验中进行许多直接的更改,以满足我们的需求。

为了提供用于在线服务的轻量级接口,我们将 anOnlineTransformer添加 到可以提供在线服务的转换器中,包括利用低级 Spark 预测方法的单个方法和小型方法列表。我们还调整了模型加载的性能,以满足我们的目标开销要求。

使用增强型转换器和估计器的管道

为了实现一个可以由 Michelangelo 在线训练并提供服务的 Transformer 或 Estimator,我们构建了一个 OnlineTransformer 接口,它扩展了开箱即用的 Spark Transformer 接口,并执行两个方法:1)Transform(instance: Dataset[Any]) ;2)ScoreInstance(instance: Map[String, Any])。

Transform(instance: Dataset[Object]) 作为分布式批处理服务的入口,提供了开箱即用的基于数据集的执行模型。ScoreInstance(instance: Map[String, Object]): Map[String, Object] 作为较为轻量级的 API,用于低延迟、实时服务场景中出现的针对单一特征值映射集的单行预测请求。ScoreInstance 背后的动机是提供一个更轻量级的 API,它可以绕过依赖于 Spark SQL Engine 的 Catalyst Optimizer 的 Dataset 所带来的巨大开销,从而对每个请求进行查询规划和优化。如上所述,这对于实时服务场景(如市场营销和欺诈检测)非常重要,其中 p99 延迟的 SLA 通常是毫秒级的。

当加载 Spark PipelineModel 时,任何具有相似类(包含 OnlineTransformer 特性)的 Transformer 都会映射到该类。这使得现有的训练好的 Spark 模型(由支持的转换器组成)获得了提供在线服务的能力,而且没有任何额外的工作。注意,OnlineTransformer 还实现了 Spark 的 MLWritable 和 MLReadable 接口,这为 Spark 免费提供了对序列化和反序列化的本地支持。

保持在线和离线服务一致性

转向标准的 PipelineModel 驱动的架构,通过消除 PipelineModel 之外的任何自定义预评分和后评分实现,进一步加强了在线和离线服务准确性之间的一致性。在每个管道阶段,实现自定义评分方法时的标准实践是首先实现一个公共评分函数。在离线转换中,它可以作为 DataFrame 输入上的一组 Spark 用户定义函数(UDF)运行,相同的评分函数也可以应用于在线 scoreInstance 和 scoreInstances 方法。在线和离线评分一致性将通过单元测试和端到端集成测试进一步保证。

性能优化

我们最初的度量结果显示,与我们自定义的 protobuf 表示的加载延迟相比,原生 Spark 管道加载延迟非常高,如下表所示:

这种序列化模型加载时间上的性能差异对于在线服务场景是不可接受的。模型实际上被分片到每个在线预测服务实例中,并在每个服务实例启动时、新模型部署期间或接收到针对特定模型的预测请求时加载。在我们的多租户模型服务设置中,过长的加载时间会影响服务器资源的敏捷性和健康状况监控。我们分析了加载延迟的来源,并进行了一些调优更改。

影响所有转换器加载时间的一个开销来源是 Spark 本地使用 sc.textFile 读取转换器元数据;从一个小的单行文件生成一个字符串 RDD 非常慢。对于本地文件,用 Java I/O 替换这段代码要快得多:

[loadMetadata in src/main/scala/org/apache/spark/ml/util/ReadWrite.scala]

在我们的用例中(例如,LogisticRegression、StringIndexer 和 LinearRegression),影响许多转换器的另一个开销来源是对与转换器相关的少量数据使用 Spark 分布式 read/select 命令。对于这些情况,我们使用 ParquetUtil.read 代替 sparkSession.read.parquet;直接进行 Parquet read/getRecord 大大降低了转换器的加载时间。

树集成(Tree ensemble)转换器有一些特殊的调优机会。加载树集成模型需要将序列化到磁盘的模型元数据文件读取到磁盘,这会触发小文件的 groupByKey、sortByKey 以及 Spark 的分布式 read/select/sort/collect 操作,这些操作非常慢。我们直接用更快的 Parquet read/getRecord 代替了它们。在树集成模型保存方面,我们合并了树集成节点和元数据权重 DataFrame,以避免写入大量读起来很慢的小文件。

通过这些调优工作,我们能够将基准示例的本地 Spark 模型加载时间从 8 到 44 倍减少到仅比从自定义 protobuf 加载慢 2 到 3 倍,这相当于比 Spark 原生模型快 4 到 15 倍。考虑到使用标准表示的好处,这种水平的开销是可以接受的。

需要注意的是,Michelangelo 在线服务创建了一个本地的 SparkContext 来处理任何未加密的转换器的负载,因此,在线服务不需要 SparkContext。我们发现,当没有模型加载处于活动状态时,让 SparkContext 继续运行会对性能产生负面影响并导致延迟,例如,通过 SparkContext 清理器的操作。为了避免这种影响,我们在没有运行负载时停止 SparkContext。

可服务管道的灵活结构

使用管道模型作为 Michelangelo 的模型表示,用户可以灵活地组合和扩展可服务组件单元,使它们在线和离线服务时保持一致。然而,这并没有完全封装管道模型在机器学习工作流的各个阶段使用时的操作需求差异。有些操作步骤或概念本质上与机器学习工作流的特定阶段相关,而与其他阶段完全无关。例如,当用户对模型进行评估和迭代时,常常需要进行超参数优化、交叉验证以及生成模型解释及评估所需的特定元数据等操作。这些步骤允许用户帮助生成模型、与模型交互以及评估管道模型,但是一旦准备好进行产品化,就不应该将这些步骤合并到模型服务中。

同时,在机器学习工作流不同阶段的需求差异,促使我们开发了一个基于通用编排引擎的工作流和操作员框架。除了组合自定义可服务管道模型的灵活性之外,这还允许用户以有向图或工作流的形式组合和编排自定义操作的执行,以实现最终的可服务管道模型。

Michelangelo 基于 Operator Framework 的工作流提供了另一种程度的灵活性,通过优化的执行计划来方便地定制操作,从而生成可服务的、序列化的 Michelangelo 管道模型以及有用的工件。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标记并不意味着 Apache 软件基金会的认可。Docker 和 Docker 标识是 Docker 公司在美国和 / 或其他国家的商标或注册商标。Docker 公司及其他各方也可以在本协议中使用的其他条款中享有商标权。本标记的使用并不意味着 Docker 的认可。TensorFlow、TensorFlow 标识及任何相关标识均为谷歌公司的商标。
Michelangelo 基于 Operator Framework 的工作流提供了另一种程度的灵活性,通过优化的执行计划来方便地定制操作,从而生成可服务的、序列化的 Michelangelo 管道模型以及有用的工件。Apache Spark 是 Apache 软件基金会在美国和 / 或其他国家的注册商标。使用这个标记并不意味着 Apache 软件基金会的认可。Docker 和 Docker 标识是 Docker 公司在美国和 / 或其他国家的商标或注册商标。Docker 公司及其他各方也可以在本协议中使用的其他条款中享有商标权。本标记的使用并不意味着 Docker 的认可。TensorFlow、TensorFlow 标识及任何相关标识均为谷歌公司的商标。

未来展望

在这一点上,Spark 原生模型表示已经在 Michelangelo 生产环境中运行了一年多,作为一种健壮且可扩展的方法,在我们公司范围内提供 ML 模型。得益于这种演变和 Michelangelo 平台的其他更新,Uber 的技术栈可以支持新的用例(如灵活的试验和在 Uber 的 数据科学工作台 中训练模型)、Jupyter 笔记本环境以及使用 TFTransformers 的端到端深度学习。为了介绍我们的经验并帮助其他人扩展他们自己的 ML 建模解决方案,我们在 2019 年 4 月的 Spark AI 峰会 上讨论了这些更新,并提交了 SPIP 和 JIRA,把我们对 Spark MLlib 的更改开源。

Joshua Gordon《TensorFlow 2.0讲解》PPT

Tensorflow2.0 对于新手来说更为易用,而对于老手来说,功能更为强大,Josh Gordon 为我们介绍了TensorFlow2.0  的一些新的特征与使用技巧。

在构建模型方面,针对不同的使用人群,TensorFlow2.0 提供了不同层面的 API,针对刚接触 TensorFlow 的新手,提供了Sequential API, 针对工程师,开放了 FunctionalAPI 与 build-in 层,针对有更高需求的工程师,开放了 FunctionalAPI 与可定制的层,评估指标,损失函数等,而针对科研工作者,开放了 Subclassing,可以定制一切函数。

在训练模型方面,从简单到复杂也分很多层次。从快速实验的 model.fit(),到定制回调函数 callbacks,到定制训练循环 batch (使用 GAN 时很有效),到完全定制训练过程,包括优化算法等 (GradientTape).

在数据方面,提供了 tensorflow_datasets,能够轻松地加载数据集。

在并行训练方面,得益于分布式策略,无需改变代码,就可以在多台机器、多个 GPU 上训练(MirroredStrategy, MultiWorkerMirroredStrategy)。

教程最后还介绍了两个项目:TinyML: 轻量级的机器学习项目 与 TF.js.

Joshua Gordon 《TensorFlow 2.0讲解》

《美团机器学习实践》下载

美团作为国内 O2O 领域领 先的服务平台,结合自身的业务场景和数据,积极进行了人工智能领域的应用探索。在美团的搜索、推荐、计算广告、风控、图像处理等领域,相关的人工智能技术得到广泛的应用。本书包括通用流程、数据挖掘、搜索和推荐、计算广告、深度学习以及算法工程 6 大部分内容,全面介绍了美团在多个重要方面对机器学习的应用。

本书非常适合有一定机器学习基础的工程技术人员和在校大学生学习和阅读。通过本书,有经验的算法工程师可以了解美团在这方面的做法,在校大学生可以学习机器学习算法如何在具体的业务场景中落地。

下载:https://pan.baidu.com/s/1NC2aov1iszDQPEr09OyVCQ
提取码:841h

Google 发布两个全新的自然语言对话数据集

如今的智能助理功能十分强大,被寄希望于完成多类任务并对不同主题的请求返回个性化结果,例如获取上映电影列表、预订餐厅和做计划旅行等。

然而,尽管智能助理近年来已取得巨大进步,但依旧未能达到人类的理解力水平。

这在一定程度上是由于我们缺乏优质训练数据,无法将人们的需求和偏好准确的反映给智能助理。系统的局限性导致在理解人类话语时会有偏差,我们为了让智能助理能够理解,不得不调整自己的措辞。换言之,现今智能助理的对话仍旧十分简单,远未达到人类理解所需的对话复杂度。

为解决该问题,Google 发布 Coached Conversational Preference Elicitation (CCPE)Taskmaster-1 英文对话数据集。

偏好导向 (Preference Elicitation) 数据集

在电影导向型 CCPE 数据集中,扮演“用户”的人员对着麦克风讲话,之后我们会向扮演“智能助理”的人员直接播放所录的音频。“智能助理”则以文字形式输出其响应,然后通过文字转语音向“用户”播放。这些双人对话中难免会出现双方之间自然发生的卡顿问题和错误,而这很难通过合成对话复制出来。由此,我们便能针对人们的电影偏好,创建一系列自然的结构化对话集合。

通过深入分析此数据集,我们发现人们会采用极其丰富的方式来描述自己的偏好。该数据集首次大规模展现了这种 丰富性。

我们还发现,人们的偏好与智能助理(或本例中的推荐网站)描绘选项的方式并不总是相符。换言之,您在搜索自己喜欢的电影或服务时所使用的的关键词,与您在向他人推荐您喜欢的电影时,使用的描述词汇可能会并不相同。

任务导向型对话数据集

askmaster-1 数据集结合使用上述方法和单人书面会话这两种方式来增加语料库规模和发言者的 多样性,最终得出约 7700 条书面的“自我对话”以及约 5500 个双人口语对话。

在书面对话中,我们会为每个任务概述相关场景,让人们据此自行创建完整对话,从而同时扮演“用户”和“助理”的角色。虽然口语对话更能真实反映双方语言上的交互,但书面对话在丰富度和复杂度方面都表现良好,并且收集这些数据的难度和成本也更低。我们基于以下 六项任务 之一来创建数据集:订披萨、进行汽车维修预约、租车、订购电影票、订咖啡和预订餐厅。

该数据集还使用简单的注释架构,为数据提供丰富的背景信息,同时让工作人员为对话添加标签时,能更好的保持一致性。传统意义上的详细策略很难使工作人员再添加标签时保持稳定的一致性,与之相比,我们只关注每类会话的 API 参数,即执行事务所需的变量。

如:在一个有关拼车安排的对话中,我们会为“目的地”和“出发地”位置以及车型(经济车、豪华车、拼车等)分别附加标签。在预定电影票时,我们为电影名称、影院、时间和票数附加标签,有时还会为放映类型(如 3D 或标准版)附加标签。语料库发布中随附有完整的标签列表。

我们希望这些数据集将能在对话系统和会话推荐的研究课题中,助力学术圈顺利开展实验和分析。