- API 文档
- CLI
- 集成指南
- 博客
- 机器如何学习理解单词:NLP 中的嵌入指南
- 使用变换器进行基于提示的学习
- 高效的变换器 II:知识提取和微调
- 高效的 Transformers I:注意力机制
- 深度分层无监督意图建模:无需训练数据即可获取价值
- 使用 Communications Mining 修复注释偏差
- 主动学习:在更短的时间内构建更好的 ML 模型
- 一切尽在数字中 - 使用指标评估模型性能
- 模型验证为何如此重要
- 比较 Communications Mining 和 Google AutoML 以实现对话式数据智能
Communications Mining 开发者指南
比较 Communications Mining 和 Google AutoML 以实现对话式数据智能
在利用 NLP 和 ML 的功能实现流程自动化、获得更好的分析效果并更深入地了解公司的对话时,第一个决定通常是是否购买解决方案,或者构建自己的解决方案。
本文将Communications Mining平台的性能和设计原理与目前最强大的云 NLP 解决方案之一Google 的 AutoML 进行了比较。
我们希望就使用专用企业通信智能产品的过程与使用更通用的工具进行比较,以及可以期待的取舍提供一些见解。
Communications Mining 和 Google AutoML 都要求用户创建带批注的训练数据集,以将标签与对话相关联。 训练数据的质量决定了从该经过训练的模型返回的预测的质量。
高质量训练数据的关键是一致地应用标签,并准确地表示您要进行预测的域。
Communications Mining 与 Google AutoML 之间的第一个主要区别是关于如何使用产品的设计理念。
批注任务与主动 学习
AutoML 流程用于离线创建带批注的数据集,该数据集在上传并用于训练模型。 标注数据集是一项昂贵的操作,需要大量的预先工作。 如何生成标签超出了 AutoML 的范围,但一种可能的解决方案是将注释工作外包给第三方。 为此,Google 提供了与 AutoML 集成的标注任务,或者用户也可以使用亚马逊的 Robotic Turk 。
这并非最佳选择,原因有几个
-
对于敏感的内部对话,第三方访问通常行不通。
-
最好不要将标注工作外包给不具备充分了解公司错综复杂的沟通所需的相关见解的人员
-
领域的上下文知识是获得高质量训练数据的关键。 例如,任何人都可以为猫和狗的图像添加注释,但不能为来自交易后投资银行运营商邮箱的电子邮件添加注释,因为需要主题专家 (SME) 来为电子邮件添加注释。
在 Communications Mining,我们鼓励人们上传大量未注释的数据,并利用我们的主动学习功能以交互方式创建注释。 我们认为,交互式数据探索和标注是构建一组标签的关键,这些标签能够以正确的粒度级别真正捕获公司对话中的所有有趣信息和细微差别。
当然,如果您已经拥有一个大型带注释的数据集,并希望将其用作起点,则也可以使用我们的CLI 工具上传带注释的数据集。
瀑布式和敏捷式模型 构建
AutoML 通过显示每个标签的误报和漏报,为如何改进模型提供了一些帮助。 Communications Mining 为每个标签提供了一组警告和建议的操作,这使用户可以更好地了解模型的故障模式,从而找到改进模型的最快方法。
AutoML 和 Communications Mining 的另一个不同之处是它们使用的数据模型。 AutoML 为输入和目标提供了一个非常通用的结构。 Communications Mining 针对以自然语言为中介的主要通信渠道进行了优化。
半结构化 对话
大多数数字对话都以以下格式之一进行:
-
电子邮件
-
工单
-
聊天
-
通话
-
反馈/评论/调查
这些都是半结构化格式,其中包含的信息不仅仅是所包含的文本。 电子邮件具有一个发件人、一些收件人以及一个主题。 聊天具有不同的参与者和时间戳。 评论可能具有关联的元数据,例如分数。
上传训练示例时,AutoML 没有规范的方法来表示这些半结构化信息,它仅处理文本。 Communications Mining 为电子邮件结构提供一流的支持,并通过用户属性提供任意元数据字段。
如下面的示例所示,企业电子邮件通常包含大签名和/或法律免责声明,这些签名和/或法律免责声明可能比电子邮件的实际内容长得多。 AutoML 没有签名去除逻辑,因此我们使用 Communications Mining 来解析签名,然后再将签名传递给 AutoML。 虽然现代机器学习算法可以很好地处理签名引起的噪声,但对于人工加标签者却并非如此。 当尝试解析电子邮件中适用和识别有趣主题的任何标签时,必须忽略长签名的认知负担是不可忽略的,并且可能导致标签质量下降。
相关 概念
Delivery
> Speed Delivery
> Cost Delivery
> Tracking
。 对于更精细的见解,可以进一步细分,例如Delivery
> Cost
> Free Shipping Delivery
> Cost
> Taxes & Customs
。
Delivery
”标签的分析,而无需对子标签显式执行任何操作。
AutoML 不支持结构化标签,而是假定标签之间完全独立。 这是适用于 NLP 标签的最通用的数据模型,但我们认为它缺乏以最佳方式处理半结构化对话所需的特殊性。
除了标签结构外,反馈或调查分析时,一段文本的情感通常也很重要。 Google 提供了一个单独的情感模型,允许用户使用现成的情感模型,该模型将为输入提供全局情感。 但是,对于复杂的自然语言,同时具有多种情感的情况很常见。 例如,考虑以下反馈:
Positive
和Negative
版本,在 AutoML 中执行类似的操作,但无法表明它们是同一标签的两个版本,这意味着用户需要将其标注为两次大量数据。
相同的 输入
另一个有趣的观察结果与输入的重复数据删除相关。 一般来说,在验证机器学习模型时,保持训练集和测试集之间的严格分离至关重要,以防止数据泄漏,数据泄漏可能导致过于乐观的性能估计,从而在部署时出现意外的失败。
AutoML 会自动对所有输入去重,并警告用户存在重复输入。 虽然这是通用 NLP API 的正确方法,但对话数据并非如此。
从外出邮件到会议提醒,许多内部发送的电子邮件都是自动生成的。 在分析调查结果时,许多人完全有可能回答完全相同的问题,尤其是在回答诸如
Is there anything we could do to improve? → No.
这意味着许多重复输入在现实世界的分布中都是合法重复的,因此评估模型在这些众所周知的完全相同的输入上的执行情况非常重要。
设置
我们的目标是尽可能公平地进行比较。 我们评估了代表三个核心企业 NLP 用例的三个数据集的性能
大小 |
已分配的标签 |
唯一标签 | |
---|---|---|---|
投资银行电子邮件 |
1368 |
4493 |
59 |
保险承保电子邮件 |
3964 |
5188 |
25 |
电子商务反馈 |
3510 |
7507 |
54 |
我们按如下方式处理了数据
-
数据格式。 对于 Communications Mining,我们使用内置的电子邮件支持。 AutoML 需要文本 blob,因此,为了表示电子邮件结构,我们使用了
Subject: <SUBJECT-TEXT> Body: <BODY-TEXT>
格式。 -
签名剥离。 所有电子邮件正文都经过预处理,以去除签名,然后再传递给机器学习模型。
鉴于 AutoML 标注任务不适用于机密内部数据,我们使用 SME 借助 Communications Mining 主动学习平台标注的标签来创建用于训练两个模型的监督数据。
我们选择这些数据集是因为它们具有代表性,并且在看到初始结果后没有对其进行修改,以防止任何抽样偏差或择优挑选。
我们保留一个固定的测试集,用于评估两个平台,并使用完全相同的训练数据来训练这两个平台。 AutoML 要求用户手动指定训练和验证拆分,因此,我们按照AutoML 文档的建议,从训练数据中随机抽样了 10% 以用作验证。
指标
平均精度更好地说明所有标签的性能,因为它是单个标签性能的未加权平均值,而平均精度、精度和召回率可捕获模型在所有输入和标签上的全局行为,从而更好地表示出现的标签。
我们比较以下指标:
-
平均精度Communications Mining 使用的指标,即标签之间的宏平均精度
-
平均精度AutoML 使用的指标,是所有预测的微平均精度
-
单独使用F1 分数“精确度”和“召回率”并没有意义,因为可以互换另一个分数。 我们报告 F1 分数,该分数代表精度和召回率同样重要的任务的性能。
有兴趣的读者可以在相关部分找到完整的精度-召回率曲线。
在所有基准数据集的每个指标上,Communications Mining 的性能都优于 AutoML,平均高 5 到 10 个点。 这清楚地表明,专门从通信中学习的工具更适用于高性能企业自动化和分析。
由于 AutoML 是为处理通用的 NLP 任务而构建的,因此它必须足够灵活,以适应任何基于文本的任务,而不会影响任何特定任务。 此外,与许多利用迁移学习的现成解决方案一样,AutoML 的初始知识更侧重于社交媒体和新闻文章中常用的日常用语。 这意味着,使其适应企业通信所需的数据量比主要目的是处理企业通信的模型要大得多,例如 Communications Mining,后者可以利用非常相似的初始知识中的迁移学习。 就现实影响而言,这意味着 SME 将更有价值的时间用于注释,需要更长时间才能从模型中获取价值,并且采用成本更高。
低数据 状态
除了完整的数据集外,我们还希望评估使用少量数据训练的模型的性能。 由于收集训练数据是一个昂贵且耗时的过程,因此在选择 NLP 平台时,在给定数据的情况下,模型的改进速度是一个重要的考虑因素。
使用少量数据进行学习称为少量学习。 具体来说,当尝试从每个标签的 K 个示例中学习时,这通常表示为K-shot 学习。
为了评估少样本性能,我们通过对每个标签采样 5 个和 10 个样本来构建每个数据集的较小版本,并将这些数据集分别记为 5 样本和 10 样本数据集。 如前所述,Communications Mining 使用层次结构标签结构,这意味着我们无法为每个标签正好抽样 5 个示例,因为子项无法在没有父项的情况下进行应用。 因此,我们通过对层次结构中的叶子标签进行抽样来构建这些数据集,因此父元素可能拥有更多示例。
这些样本完全是随机提取的,不存在可能有利于 Communications Mining 平台的主动学习偏差。
由于除非所有标签都至少具有 10 个示例,否则 AutoML 不允许用户训练模型,因此我们无法报告 5 次测试的性能
在低数据情况下,Communications Mining 在所有任务的大多数指标上的性能都显着优于 AutoML。 我们观察到,在大多数指标上,Communications Mining 的 5 次测试性能已经可以与 10 次测试 AutoML 的性能相竞争。
拥有一个几乎没有带注释的训练点的准确模型非常强大,因为这意味着人们可以更早地开始与模型协作,从而收紧主动学习循环。
衡量 AutoML 性能更高的一个指标是客户反馈的 10 次性能的平均精度,其中 AutoML 的性能比 Communications Mining 高 1.5 个点。
由于 AutoML 是一个通用工具,因此它最适合散文状的数据,而客户反馈往往不包括通用工具无法处理的重要半结构化数据或特定领域的术语,这些数据这是 AutoML 运行良好的原因之一。
训练 时间
模型训练是一个复杂的过程,因此训练时间是需要考虑的一个重要因素。 快速的模型训练意味着更快的迭代周期和更紧密的反馈循环。 这意味着人工应用的每个标签都可以更快地改进模型,从而减少从模型中获取价值所需的时间。
Communications Mining |
AUTOML | |
---|---|---|
投资银行电子邮件 |
1 分 32 秒 |
4 小时 4 分钟 |
电子商务反馈 |
2 分 45 秒 |
4 小时 4 分钟 |
保险承保电子邮件 |
55 秒 |
3 小时 59 分 |
Communications Mining 专为主动学习而构建。 训练时间对我们非常重要,我们优化了模型,可以在不影响准确性的情况下快速训练。
与 Communications Mining 相比,训练 AutoML 模型的速度平均慢约 200 倍。
AutoML 模型的训练时间需要延长几个数量级,这使其不太适合在主动学习循环中使用。 由于迭代时间很长,因此改进 AutoML 的最佳路径可能是在模型重新训练之间进行大批量标注,这存在标注数据冗余(为已经很好理解的概念提供更多训练示例)和标注效果不佳的风险。数据探索(不知道模型不知道什么会导致更难实现更高的概念覆盖率)。
构建企业 NLP 解决方案时,模型的原始预测能力只是需要考虑的一个方面。 虽然我们发现 Communications Mining 在常见的企业 NLP 任务上优于 AutoML,但我们获得的主要见解是这些平台的 NLP 方法存在根本差异。
-
Communications Mining 是一款专为半结构化对话分析量身定制的工具。 它包含在敏捷框架中从头开始构建模型所需的更多组件。
-
AutoML 是一种通用的 NLP 工具,必须与其他组件集成才能发挥作用。 它更专注于在用于机器学习模型构建的瀑布框架中使用预先存在的带注释的数据构建模型。
-
这两个工具都能够构建高度竞争的最新模型,但 Communications Mining 更适合于企业通信分析中常见的特定任务。
除非可以预先定义确切的要求,否则 AutoML 模型的训练时间较长,无法在主动学习循环中推动交互式数据探索,而 Communications Mining 正是为此而构建的。
AutoML 要求在训练模型之前每个标签要有 10 个示例,这意味着人们无法在早期阶段有效地使用模型来指导标注,而这正是机器学习项目中最困难的部分。
此外,AutoML 和 Communications Mining 预期的任务之间的分布差距意味着,由于更有针对性地使用了迁移学习,更具体的工具能够更快地生成更高质量的模型。
如果您觉得此比较有趣,有任何意见或问题,或想要尝试使用 Communications Mining 以更好地了解公司的对话,请与UiPath 联系!