为各行各业构建认知解决方案，第 3 部分: 让认知数据变得可以搜索和理解的设计模式

内容简介：为各行各业构建认知解决方案，第 3 部分: 让认知数据变得可以搜索和理解的设计模式

为各行各业构建认知解决方案，第 3 部分

让认知数据变得可以搜索和理解的设计模式

Janki Vora , Mathews Thomas , Tomyo Maeshiro , Ronald Rutkowski , Joshua Purcell , 和 Juel Raju

2017 年 5 月 04 日发布

在本系列 前面的教程中，我们概述了认知计算，提供了使用认知计算创建行业解决方案的示例。我们还提供了一些成功的认知用例，帮助您理解可通过构建认知平台实现哪些目的。在本系列的第 3 篇教程中，我们将介绍让认知数据变得可以搜索和理解的设计模式。

人类和机器生成的数据量正在呈指数级增长。最近几年，科技进步使我们能够使用大数据分析平台从大型数据集中获取洞察。IBM 认知平台使企业能在其决策过程中理解和使用 暗数据 。它使用认知搜索模式实现此目的。这种暗数据的每种表现形式 — 文本、视频、故障通知单或社交媒体数据 — 都需要一种独特模式。在本教程中，我们将从整体上定义认知搜索模式的构成和用途，探讨用于处理特定暗数据类型的过程、 工具 和流程 — 具体来讲，暗数据包括电信、媒体和娱乐行业中的数据。（请参阅上一篇 教程，了解关于我们的场景的更多信息。）

认知搜索模式是什么？

认知数据是人类可以轻松处理的信息。通过将音频与视觉数据点结合到一起，我们就能轻松观看视频并理解它。IBM 认知平台使机器能理解和学习各种各样的非结构化暗数据，比如电子邮件、手册、3D 视频和音频数据。为此，该平台采用了一种认知搜索模式 — 一个特定的工具、技术和流程集合 — 从数据来源提取暗数据，并使其变得可以搜索并最终能够被使用。

认知搜索模式具有独特的魅力且种类繁多，它们利用的数据类型和您希望使用它们实现的目的也十分广泛。由于这个原因，我们将本教程中的讨论限定到 4 种流行模式，我们已将它们应用于上一篇 教程中讨论的用例：

• 模式 1：使文本变得可搜索。在使用自然语言查询的上下文中，这种搜索模式可以从非结构化数据语料库获取最相关的响应或类似主题的响应。
• 模式 2：使视频变得可搜索。在使用自然语言查询的上下文中，这种搜索模式从视频语料库获取最相关且经过时间编码的视频响应。
• 模式 3：从文本中搜索和报告洞察。这种搜索模式从非结构化语料库中收集出现的模式、关联和洞察，并在仪表板中查看它们。
• 模式 4：搜索和探索社交及新闻提要。这种搜索模式从社交和新闻提要数据中收集洞察。

通过对每种数据类型应用最佳认知搜索模式，您可以超越简单的关键词搜索结果，获得已通过机器学习为您解释的发现。我们积极地应用我们获得的成果来帮助支持技术人员解决他们遇到的最难的网络问题 (Watson for Network Operations)，帮助无线电话客户回答有关其设备和无线计划的问题 (Device Doctor)，并提供个性化的媒体内容推荐 (Personalized TV)，而随着该领域不断成熟和您自己的专业技能不断增长，潜在的用途还会继续增加。

模式 1：使文本文档变得可搜索

在 Watson for Network Operations 用例中，我们希望从各种各样的网络设备手册、故障通知单和日志数据中收集洞察。在 Device Doctor 用例中，我们使用了来自社区论坛的故障排除建议来扩充现有的知识库。在这两种情况下，得到的知识库都被证明是非结构化、大型和复杂的。但是，在这两种情况下，我们都能应用以下认知搜索模式快速找到文档和论坛文章中的最相关章节，而所有这些都是在使用自然语言搜索问题的上下文中完成的。

如图所示，自然语言查询被解析并应用了上下文感知的学习算法，最相关的搜索结果显示在顶部。该系统能从它的成功和失败经历中学习，并根据反馈来改进结果。我们通过 3 种不同方式应用此模式：基于上下文的搜索、主题相似性搜索和 排序 搜索。

第 1 步：聚合并爬取文档

网络爬虫

网络爬虫代表上述模式中的第一个过程。在某些情况下，比如 Watson for Network Operations，知识库已存在，这意味着不需要配置网络爬虫。但在自助服务代理用例中，我们需要从外部 Web 论坛收集数据来构建知识语料库，而且要完成该任务，需要使用网络爬虫。

网络爬虫是 IBM Watson Explorer 中的组件，用于管理远程数据源与 Watson Explorer 的剩余部分之间的联系。网络爬虫将原始数据源联合到单个队列中供进一步处理，比如执行文档转换。文档转换代表我们的搜索模式中的下一步，将在下一节中讨论。使用网络爬虫可带来以下业务收益：

• 能够在单个集中化的知识语料库中组织和整合所有感兴趣的数据。
• 能够基于事件触发器或计划的时间间隔来自动更新或刷新语料库，保持知识语料库最新。
• 能够基于不同的条件设置来过滤数据，比如在文档中检测某个字符串。

流程

在确认拥有这些来源的适当的访问和使用权后，只需选择想用于创建网络爬虫的数据源即可。（本系列后面将讨论爬网最佳实践。）接下来，我们为每个数据源创建了要添加到网络爬虫中的种子。在这之后，我们使用特定的全局设置和条件语句来配置网络爬虫。

默认情况下，Watson Explorer 支持 40 多种不同的数据源类型。我们将文件和 URL 作为项目的主要来源。更确切地讲，我们使用了传统的 Windows 文件/文件夹分层结构，通过配置文件类型源来让这些分层结构包含各种不同的文档，比如 Word、PDF、Excel 或富文本类型文件格式。此外，我们的 URL 类型种子代表 HTML 格式的在线公开 Web 论坛。每个 HTML 页面都代表论坛上的一条线索，它由一个技术问题和一个或多个用户评论形式的答案组成。我们为选择包含的每个 Web 领域创建一个 URL 类型的种子。此刻，除了通过选择相应种子类型来添加种子之外，不需要任何进一步工作。在下图中，可以注意到我们向 “DeveloperWorks” 语料库网络爬虫添加了两个 URL 类型的种子，它们分别对应每个 Web 领域。我们配置了更多设置来允许 Website2.com 最多包含 99 跳，Website1.com 最多包含 3 跳，这里的 “跳” 指的是网络爬虫将在网页上单击的深度。

将种子添加到网络爬虫中后，我们可以配置两个设置面板。第一个设置面板 Global Settings 代表可为网络爬虫指定的各种各样的性能控制措施。例如，用户可指定网络爬虫应丢弃所有重复网页，下载不超过 5Mbs 的数据，或者每隔 7 天自动重新爬取。在下图中，可以注意到对于爬取限制，最大 URL 数量设置为 25,000 个网页。

我们配置的第二个设置面板是 Conditional Settings 面板，它在网络爬虫的范围上提供了更高的灵活性。Watson Explorer 支持约 12 种条件语句，但对于我们的用途，我们只仅需要创建 URL Filters。URL Filters 让用户基于 URL 的字符串模式来指定爬取哪些 HTML 网页。在下图中，条件规则规定，所有 URL 不得包含子字符串 /tagged/ 或 /users/ ，但必须包含子字符串 /questions 。此外，根据正则表达式的定义，对于所有 URL，必须有一个子字符串包含一个或多个连续数字（比如 12345）。

完成网络爬虫配置后，很快就会创建一个自定义转换器。

第 2 步：将文档转换为合适的文件格式和答案单元。

转换器

Watson Explorer 支持使用转换器将非结构化数据转换为半结构化甚至结构化文件格式。转换器是 Watson Explorer 内的组件，允许处理跨不同文件类型的数据。转换器可自定义为根据传统条件语句来执行，而且可使用各种编程语言来配置。总体上讲，转换器的使用时间为爬取数据源之后到索引和导出文档之前。默认情况下，Watson Explorer 拥有 50 多种不同的转换器，支持开箱即用地使用 100 多种文件类型。Watson Explorer 还允许企业创建自己的自定义转换器，这增强了 Watson Explorer 可执行的转换类型。

通过创建自定义转换器，您可以：

• 过滤掉半结构化或非结构化数据源中不必要或不相关的数据
• 将半结构化或非结构化数据组织到结构化文件系统中
• 直接从一种文件类型转换为另一种文件类型

流程

要创建转换器，首先要选定输入文件类型和想要的输出文件类型。接下来，我们指定了应执行转换器的条件。最后，根据之前指定的文件类型，选择编程语言，用于指定在转换过程中执行的自定义指令。自定义指令包含的代码指定了我们希望从原始输入提取哪些文本片段，以及我们想要丢弃的文本片段。我们甚至通过指定输出文件类型来组织提取的数据。

在自助服务代理示例中，为在爬取过程中收集的每个 HTML 文件创建了一个自定义 XML 文件。使用的主要数据源是在线公开论坛。每个 HTML 文件都代表论坛上的一条线索，它由一个技术问题和一个或许多用户评论形式的答案组成。因此，我们选择 HTML 作为转换器的输入文件类型。

因为我们想要的输出文件类型是自定义 XML，所以我们选择 Watson Explorer XML（或 VXML）作为转换器输出文件类型。传统 XML 与 VXML 之间的区别在于，VXML 中嵌入了更多特定于 Watson Explorer Product Suite 的功能。确定了输入和输出文件类型后，我们编写了条件语句来控制转换器应在何时执行。对于条件语句，Watson Explorer 支持各种各样的语言，包括通配符、XPaths 及 Perl 中的正则表达式。我们配置了条件语句来检测我们爬取的各种 URL 内的通配符表达式。此外，我们仅在检测到包含字符串 questions/ 的 URL 时执行转换器。所有与此规则不符的 URL 都被忽略。

创建转换器的最后一步是编写 XSL 指令，我们选择它是因为它支持使用 XPath 语句从 HTML 文件中提取文本，并将该文本注入 XML 文件。通常，最后一步代表着创建转换器所需的大部分工作，因为识别 HTML 文件中的模式并将这些模式编写为 XSL/XPath 语句格式并不总是那么简单。

转换过程和代码得到了一个能创建高质量 XML 文件语料库的转换器，语料库中的每个文件仅包含相关的文本片段。在下面的示例中，代码告诉转换器在 VXML 文件中创建一个名为 answer1_text 的元素。XPath 指定了在 HTML 文件中查找一个包含答案 ID 的 div 标签。在该答案 div 标签中，跳到第二个嵌套的 div 标签。在第二个嵌套 div 标签中，找到另一个与类 post-text 匹配的 div 标签。最后，复制文本的值，并将其设置为 answer1_text 元素的值。

对于部分介绍的爬取过程，在完成网络爬虫和转换器后，Watson Explorer 引擎会获得通过概述窗格启动的权限，实际逐个爬取和转换文档，并从头创建一个 XML 文档语料库。下图表明，爬取了 25,000 个网页 — 其中忽略了 855 个 URL，创建了 24,145 个 XML 文档。

Watson Explorer 提供了文件导出功能，可轻松地导出完整的数据语料库供其他产品和服务使用，无论供应商或品牌是什么。具体地讲，对于自助服务代理示例，最终导出了新 XML 文件的语料库供 Watson Retrieve and Rank 服务使用。

在我们的一些项目中，还使用了 IBM Document Conversion 作为工具来改变输入数据。Document Conversion 不是网络爬虫，但它将接收单个 HTML 代码并将该文件拆分为更小的分段（称为答案单元）。它会考虑 header（h1、h2 等）标签，而且对于每个 header 标签，它都会标记并创建一个答案单元。我们在 Watson for Network Operations 示例中使用了 Document Conversion，摄取了一些网站的 HTML 代码。它提供了非常好的结果，可轻松地与 Retrieve and Rank 服务相集成。此外，它还可以摄取 DOC 和 PDF 文件，这些文件被转换为 HTML 并以相同方式处理。在启动新的 Retrieve and Rank UI 时，需要拥有 Document Conversion 实例。

第 3 步：注释文档

文本标记和注释也称为实体提取，形成了语言处理任务（包括文本挖掘、信息提取和信息检索）的一个重要组件。还可以使用带注释的文本让搜索符合上下文。对于自助服务代理，对文档注释了设备制造商、操作系统和型号。还注释了设备故障排除问题。此过程使我们能定义更加智能且符合上下文的搜索。本教程将讨论注释过程的细节。下一节将讨论我们如何注释故障通知单数据，并将它用于文本挖掘和信息提取。在本系列的下一篇教程中，将更深入地探讨如何使用更多工具和技术来执行注释，因为这是改进搜索模式的准确性和相关性的重要一步。

第 4 步：为 排序算法 创建参考事实 (ground truth)

从名称可以看出，Retrieve and Rank 是两个组件的组合 — 使用 Apache Solr 执行 “检索”，使用复杂机器学习算法细化搜索体验或对它们进行 “排序”。Retrieve and Rank 服务在 Bluemix 上以基于云的服务形式提供，服务文档中还提供了一组 API 端点。借助这些 API，可以轻松地将 Retrieve and Rank 集成到几乎任何 RESTful 应用程序中。

Apache Solr 是一个众所周知的开源搜索平台。Solr 提供了丰富的查询解析器和搜索功能，可根据矢量空间和布尔模型的组合来确定文档与查询的相关性。ranker 是一个组件，它处理 Solr 搜索，对经过训练的机器学习组件所确定的结果进行排序。 Watson Developer Cloud 上定义并记录了创建 ranker 的步骤。带 ranker 的 Solr 提供了可靠的自然语言搜索功能。

可通过不同方式连接到 Bluemix 上的 Retrieve and Rank 引擎：

• 使用任何 REST 客户端（curl、postman 等）在 Bluemix 上直接调用这些 API
• 使用不同语言（Java 语言™、Node.js、 Python 、iOS 等）中的 Watson Developer SDK
• 使用新的 Retrieve and Rank 用户界面

前两种方法需要执行 4 个主要步骤来让实例做好摄取文档的准备：

1. 在 Bluemix 上创建服务。
2. 创建一个集群。
3. 上传 Solr 配置。
4. 创建一个集合。

相对而言，使用 Retrieve and Rank UI 需要的步骤更少一些，而且可以使用一个友好的 Web 界面来完成。在我们的项目中，我们试验了所有 3 种方案。前两个过程更强大一些，因为它们允许创建自定义 Solr 配置。Retrieve and Rank UI 方法更简单，但带有无法更改的默认 Solr 配置。下图显示了一种自定义 Solr 配置。

您可以对比一下该配置与默认配置。

创建配置后，很容易创建集合。只要您的集群和 Bluemix 中的资源允许，可以上传任意多种配置，创建任意多个集合。在 Watson Network for Operations 示例中，我们直接创建了该服务并使用 API 摄取语料库。对于 Device Doctor 示例，我们使用了 Java SDK 来自动化此配置/摄取过程，使将此功能连接到其他数据源（比如网络爬虫、数据库或其他存储库）成为可能。我们为两个项目都提供了经过主题专家精心设计和验证的 ranker。

下图显示了一个创建参考事实的示例。CSV 文件显示了一个问题、文档在 Retrieve and Rank 上的 ID，以及与该问题的相关性。请注意，相关度范围被设置为 0 - 4，其中 0 表示与问题无关，4 表示与问题紧密相关。此相关度范围是为一种褒/贬反馈机制设置的，采用 0-1 的二进制范围，其中 0 表示无关，1 表示相关。

摄取语料库并训练 ranker 后，就可以向 Retrieve and Rank 询问问题了。搜索查询发送到一个 Solr 实例，并检索一组相关文档。通过计算查询词汇与摄取的文档的余弦相似性，以数学方式计算这个文档集合。通过此方法，Solr 可以获取与查询搜索最相似的文档。然后，ranker 对响应进行排序，使用经过训练的机器学习模型对为查询提供一组细化的答案单元。为了进一步增强搜索，我们通过附加上下文信息来包含了与查询相关的信息。在 Device Doctor 场景中，我们让 Watson Conversation 跟踪记录上下文，比如设备类型、型号和操作系统版本。类似地，Watson for Network Operations 示例从外部网络监控系统上生成的警报中获取其上下文。此上下文被附加到查询并提升权重，以便在搜索上拥有比其他词汇更高的权重。

模式 2：使视频内容变得可搜索

多媒体是数据编码音频、图像和视频的巨大来源。作为一种信息来源，这些格式的内容变得越来越流行，但作为一种非常麻烦、难以有效使用的来源，它们被许多人忽视。原因可能是在这些媒体类型内搜索不方便。内容通常只能按它的元数据（比如标题、标签和时长）进行搜索。传统搜索引擎很难解释音视频内容本身。考虑到这一点，我们使用了 Watson 服务，通过从音轨中生成文本来提取内容本身的特征。此外，我们还提取视频帧作为静态图像，并运行不同的算法来注释这些图像，识别这些图像中的物体、人员和文本。

音频频道通常提供了许多可供分析的元素：所说的语言、音乐轨道和常见音效。我们使用了 Watson Speech to Text 来提取音频的带时间戳的文字记录。该服务提供了准确的文本识别功能，但受到限制，因为它无法识别讲话的不同实体。为了获得更好的结果，我们使用了只有一个讲话实体的视频。我们为利用搜索引擎提取的文本建立索引，以便找到提及这些特定主题的视频片段。为了进一步扩充内容，我们使用该文本提取语言特征（通过使用 Alchemy Language），比如概念、实体和关系。通过为文字记录注释这些额外信息，我们不仅能为视频内容建立索引，还能在数据内建立与视频中未明确提及的文本的更好关系，从而获得更丰富的搜索功能。

我们使用我们创建的某个自定义工具每秒提取一个视频帧（该提取频率是可配置的）。然后，我们对视频帧使用 Watson Visual Recognition 服务，获得另一个维度的信息，也就是图像的注释。此服务提供 3 个主要的提取功能：图像标记、面部识别和图像文本识别。图像标记是一个可训练的功能，它生成图像上的物体、位置和操作信息。例如，它可以识别人群、车辆等物体，或者人们参加体育运动等操作。尽管这些服务并不总是会提供完全准确的结果，但这是一种注释视频（在过去是一项高成本的手动任务）的好方法。面部检测功能使用机器学习算法来检测人脸上的特定特征，甚至检测性别和估算年龄范围。也可以提取图像上的文本。所有这些特征都会标记时间戳，并与音频中提取的数据相关联，以便提高可用数据的质量。

模式 3：从文本中搜索和报告洞察

在我们的 Watson for Network Operations 用例中，我们应用了各种不同的认知模式。可使用不同的工具来执行这些模式。我们将根据这些工具是企业内部的还是外部的（云上），或根据技能来对它们进行讨论。在本节中，我们将探讨如何从非结构化故障通知单数据中收集洞察和趋势。对于此搜索模式，我们使用了 Watson Explorer Content Analytics 平台。

故障通知单包含丰富的信息，包括任何服务请求、客户查询、问题管理记录，或者服务台、帮助台或支持企业在解决客户问题时开发的其他任何形式的文档。故障通知单包含与特定客户、日期和时间、遇到的问题类别，以及（最重要的）这些问题的解决方法相关的详细信息。关闭的故障通知单包含丰富的信息，包括客户面临哪些问题，如何克服这些问题，以及如何解决或预防这些问题。存档、管理和使用故障通知单的企业能够访问所有这些洞察，但通常很难从这种流行格式的暗数据中获得有意义的信息。

大多数企业都在不断记录、收集和存储海量的故障通知单数据，但仅对它们执行了有限的分析，尽管有可能获得更深入、更有吸引力的洞察。一种深入分析方法包括结合使用认知技术（比如自然语言处理）和文本分析。结合使用认知技术和文本分析的企业可获得的潜在收益示例包括：

• 识别特定文本分组之间的关系，有助于自动识别问题主题，以及自动识别解决方法和故障排除步骤。
• 使用自然语言处理，有助于自动检测客户意图，能够智能地路由和解决客户查询，提高客户满意度和首次呼叫解决率，同时减少通知单升级率和支持中心开支。

方面划分流程

Watson Explorer Advanced Edition 是我们用于网络操作代理和自助服务代理场景的主要工具之一。在整个教程中，在讨论我们的场景、工具和方法时，都引用了 Watson Explorer。在我们的解决方案开发项目中，我们将 Watson Explorer 定位为大规模爬取、转换和注释数据的解决方案。对于网络操作代理示例中的故障通知单注释，我们提供了 Watson Explorer Content Analytics，这是 Watson Explorer Advanced Edition 产品套件中的一个工具。

从技术角度讲，Watson Explorer Content Analytics 遵循 IBM UIMA 架构，该架构提供了一个执行文本分析的框架。基本上讲，UIMA 架构建议在文本分析管道中执行 3 个主要流程：爬取和导入、解析和索引、搜索和内容分析。

本教程前面已讨论了第一个流程：爬取和导入。第二个流程 “解析和索引” 包含自定义注释器所执行的大部分工作。第三个流程 “搜索和内容分析” 指的是对结果的管理。在这里，我们将重点介绍第二个流程和创建自定义注释器。

注释流程

Watson Explorer Content Analytics Studio 是一个开发环境，用于就在 UIMA 管道的第二个流程中执行的文本注释对 Watson Explorer Content Analytics 执行训练。基本上讲，我们使用 Content Analytics Studio 创建自定义字典和解析规则，然后将它们上传到 Watson Explorer Content Analytics 服务器，我们的语料库中的所有故障通知单都在该服务器中进行注释。字典是与一个实体关联的提及内容集合。例如，实体 “IP Quartet” 的字典可能包含 “192” 或 “168” 等内容。解析规则是一个或多个实体可能发生的特定顺序。例如，“IP Address” 解析规则可能要求在 “IP Quartet” 内容后紧跟字符 “.”，然后是另一个 “IP Quartet” 的内容，等等。在经过良好训练的文本注释器中，文本 “192.168.1.1” 会被识别为 IP 地址。

通过训练和注释，可以识别出不同方面。默认情况下，Watson Explorer Content Analytics 能识别传统的词性，比如名词、动词和形容词。但是，Content Analytics Studio 可创建自定义词性，比如问题主题或人员。我们将这些词性称为方面。下图显示了一个 Verb 事实类型的示例。

IBM 最近提供的一个替代工具是 Watson Knowledge Studio。Knowledge Studio 没有使用本地开发环境，比如 Watson Explorer Content Analytics，它基于云，而且包含一个通过 Web 浏览器使用的简化的用户界面。Knowledge Studio 没有使用 Watson Explorer Content Analytics，不会逐个定义自定义字典、方面和解析规则，然后执行示例注释来训练注释器，它使用一个实体（类似于方面）列表、关系和带颜色编码的 UI，支持快速创建示例注释来帮助训练注释器。Knowledge Studio 和 Watson Explorer Content Analytics 都始终需要一定程度的手动人工干预来训练注释器，但 Knowledge Studio 希望让训练过程变得更快更轻松。此外，Knowledge Studio 还被用于创建一种认知机器学习模型，该模型根据您的示例注释、实体和关系来处理文档和推断注释。

模式 4：搜索和探索社交和新闻提要

认知计算允许您使用来自非传统数据集的洞察，这些数据集在以前被认为太复杂，机器无法理解。在本节中，我们将通过示例来讨论我们的工作中使用的不同数据集。第一步是获取数据并进行整理，采用下面介绍的各种数据暂存和处理模式。

在 Personalized TV Agent 场景中，我们使用了各种非传统数据，比如社交数据、数据新闻提要和视频数据。我们在上面讨论了视频数据，在下一篇教程中，将继续详细讨论视频注释。

社交媒体包含海量数据，可使用它们找到有价值的元数据。但是，存在两个障碍。第一个障碍是获取有用的数据，第二个障碍是如何过滤和增强该数据，使它能为您的用例所用。

对于 Personalized TV 示例，我们专注于收集匿名化的客户，以及一组就某些主题发表推文的人的社交媒体数据，以便理解他们对某个媒体内容的看法。然后我们比较该数据，查看是否出现了任何模式，从而确定他们可能喜欢观看的其他内容。

我们判断，比较和收集我们想要的数据的最佳方式是，使用一个人们最有可能发表其观点的信息来源，即 Twitter。通过使用 Bluemix DashDb 数据库服务和 IBM Insights for Twitter，我们能够根据查询来拉入数据。如果想要亲自试验：

1. 打开您的 DashDB 实例并使用您的凭证登录。
2. 从仪表板中，转到 Load > Load Twitter Data > Select your Twitter Service 或创建一个新服务并单击 Next 。
3. 输入您的查询

我们在媒体和娱乐行业执行搜索，所以我们的关注点是流行的电视节目。当时最流行的节目之一是 The Walking Dead 。在 Twitter 上进行一定的研究后，我们发现在引用 The Walking Dead 时使用的一些流行的哈希标签包括 #TWD 和 #TheWalkingDead。我们还发现有人使用 #Walkers。但是，当时的另一个流行节目 Game of Thrones 也将它的一个反派角色称为 “White Walkers”。这些标签能为我们提供大量数据的词汇，也对我们的数据产生了负面影响。因此，我们决定从查询中排除 #Walkers。

您可以快速进行一次查询统计，看看可以获取多少数据，然后选择 Next 并选择您希望将数据加载到的表。您会看到所有表以及通过查询获得的数据。完成数据收集后，可以前进到下一步——细化/过滤数据，以便丰富该数据。

AlchemyData News 服务是 AlchemyAPI 中提供的一个 API。AlchemyData 拥有过去 60 天内的新闻和博客文章的大量索引，可使用这些索引来检索已通过自然语言处理功能扩充的文章。我们使用此 API 拉取概念和实体，进一步丰富我们的搜索结果。此过程为我们提供了可在 Twitter 搜索过程中使用的更多搜索词汇。我们使用此服务来理解出现的主题。

结束语

在本教程中，简要概述了我们用来构建认知系统的不同模式。根据讨论，可以使用各种不同的企业内部和外部工具来实现类似的结果。Watson API 使认知应用程序的开发变得非常容易。在本系列的下一篇教程中，我们将讨论用来实现认知用户体验的模式。我们将讨论如何通过机器沟通和加深人类理解的能力来定义认知用户体验，以及如何使人工智能系统能理解人类行为的模式。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 认知
• [原]对开源的认知
• 对过WAF的一些认知
• 对过 WAF 的一些认知
• 认知的高度 = 人生的高度
• 谈对事物认知能力的全面提升(200702)

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。