使用 IBM Watson Content Hub 创建智能文章

应用程序正变得越来越高级。它们不再仅仅是输入和输出数据，而是利用复杂的系统来丰富内容，以支持更高级的决策。在 Fixate，我们正在构建这样的应用程序。我的组织会生成大量内容。我们引以为豪的一点是，我们的内容及时且相关。绝无虚言。维持这一标准并非易事，而如今，这完全是手动完成的。这就是我们可以利用内容，分析我们已创建的所有内容以及网络中类似内容，以帮助策划未来主题并制作更深入、更高质量文章的地方。我们正在考虑使用 Watson Content Hub (WCH) 来完成所有这些工作。

它真的算 CMS 吗？

WCH 的一个关键价值主张是它是一个内容管理系统 (CMS)。但它真的算吗？当我听到内容管理系统 (CMS) 这个词时，我想到的是非常静态的东西。一个你上传内容、存储一段时间、偶尔使用、然后删除的地方。如果你以这种方式使用 Watson Content Hub，那你将错失良机。

对我而言，Watson Content Hub 是一个内容智能平台。是的，你可以存储内容，并且在那里存储内容具有一定的价值。但真正的价值在于内容在 Hub 中“发布”后的分析。这是我们的主要用例。对于开发者来说，因为它提供了 API，该平台带来的智能非常有价值。

我们将把 WCH 纳入我们的内容流程。当我们部署完成的资产时，我们会以编程方式将其上传到 Hub。它们将被分析，分析结果将被汇总并呈现给内容作者，以供未来内容创作参考。

我不确定我们的用例是否典型。大多数组织会利用内容库来创建系统中的其他内容或页面。你也可以通过 API 来完成这一点，然后轻松地将页面集成到你的应用程序中。这在未来对我们来说是可能的，但目前，分析是关键方面。

使用内容 Hub

我们的应用程序是用 PHP 编写的。我们使用 Unirest 库来发布和解析从 Content Hub 获取的 JSON 流。WCH 的 API 是 RESTful 的，所有内容都通过 JSON 交付。未来，我们正考虑从使用 Azure Functions 作为运行应用程序的无服务器代码的托管 PHP 应用程序迁移。

我们在一天之内就能够测试并将 WCH 集成到我们的应用程序中，并很好地了解了我们如何使用它。要开始，你首先需要 创建一个 30 天试用版。用户界面设计非常简洁，并且他们有一个非常好的教程来解释一些核心组件、资产、内容和网站。对于我们的应用程序来说，我们将要处理的最重要的对象是资产，因为内容已经创建，并且将以 PDF 格式上传。

在用户界面中，你需要花一些时间在设置上。对我们来说，提前创建分类法非常重要。虽然你可以使用 Categories 函数以编程方式创建分类法，但对我们来说，保持分类法的一致性并在我们的应用程序中保持不变是很重要的。对我们的应用程序来说，类别/术语将由保存文章存档的 Drive 帐户的目录名称决定。虽然类别不是立即有益的，但随着时间的推移，它们将是维护 CMS 中内容的关键，也是我们计划实现的一些新功能。

我们还为我们的内容创建了一个特定的内容类型。我们的内容类型与“示例文章”类型唯一的区别是我们排除了任何图像。

你还需要设置你的用户/角色。对我们来说，我们只有一个用户，那就是应用程序本身，并且使用最小特权原则，其角色设置为编辑器。现在，我们可以开始使用 API 将我们的应用程序集成到平台中了。

API

API 有两个端点——创作和交付。对我们来说，所有我们需要的功能都在创作端点里。

与 WCH 的集成并不难。最难的部分是认证。目前，它们不使用 API 令牌，但我从产品团队了解到这一点即将推出。我们使用的是 basicauth 方法，这意味着你必须在主机上生成一个带有访问令牌的 cookie。（随着我们的开发环境的增长并在不同环境中部署应用程序，这将很困难。如果我们最终转向无服务器代码，这可能会成为一个障碍。）但是，一旦我们获得访问权限，过程就只是上传内容、等待分析，然后检索标签。

上传/创建的请求 URL 是：

https://{DomainName}/{path}/authoring/v1/assets?fields=undefined&include=undefined&analyze=true&notify=true&autocurate=true

对我们来说，analyze、notify 和 auto-curate 参数需要设置为 true。原因是我们最需要的是标签信息。Analyze 将指示平台从资产正文中提取标签，notify 将在完成时通知应用程序。这一点至关重要，因为一旦完成，标签就会被提取并存储到一个单独的数据库中。而 auto-curate 会自动接受所有标签。如果不将 analyze 设置为 true，则无法使用 auto-curate。

返回的字段值提供了我们添加的资产的 ID，以便我们在检索类别时引用它。检索很简单。检索仍然在创作 API 下进行，这一点有点奇怪，但 URL 如下：

https://{DomainName}/{path}/authoring/v1/assets/{id_string}?fields=undefined&include=undefined

我们只关心类别以及我们提取的资产的日期范围，因为我们只查看过去两个月的结果。下面是一个上传资产的结果示例（为节省空间省略了大量元数据）。

{
  "mediaType": "application\/pdf",
  "name": "Continious Deployment for Docker Apps to
Kubernetes.pdf",
  "path":
"\/dxdam\/29\/294f063f-e775-4193-b42d-34b80485eef3\/Continious Deployment
for Docker Apps to Kubernetes.pdf",
  "digest": "OXNoq5MWdwc4v+YIXtYPJQ==",
  "usageRights": {
    "categories": [
    ]
  }
  "assetType": "file",
  "lastModified": "2017-09-26T21:30:05.631Z",
  "description": "",
  "tags": {
    "values": [
      "concept:Cloud computing",
      "entity:Google",
      "entity:Kubernetes",
      "entity:Codeship",
      "entity:Kubernetes Cluster",
      "entity:Cloud services",
      "entity:\u00e2\u20ac\u2039official"
    ],
    "accepted": [
    ],
      "analysis": "complete"
  },
  "isManaged": true,
  "categoryIds": [
  ],
  "fileName": "Continious Deployment for Docker Apps to Kubernetes.pdf",
  "creatorId": "b9628c6e-b88e-4438-9c18-148ade25665f",
  "rev": "4-e6ecfd96424be0b50ac0d42f315bffdf",
  "cognitive": {
    "concepts": [
      "Cloud computing"
    ],
    "entities": [
      {
        "name": "Google",
        "type": "Company"
      },
      {
        "name": "Kubernetes",
        "type": "Company"
      },
      {
        "name": "Kubernetes",
        "type": "Person"
      },
      {
        "name": "Codeship",
        "type": "Company"
      },
      {
        "name": "Codeship",
        "type": "Person"
      },
      {
        "name": "Kubernetes Cluster",
        "type": "GeographicFeature"
      },
      {
        "name": "Kubernetes",
        "type": "City"
      },
      {
        "name": "Cloud services",
        "type": "FieldTerminology"
      },
      {
        "name": "\u00e2\u20ac\u2039official",
        "type": "JobTitle"
      }
    ],
    "keywords": [
      "Google Cloud",
      "Docker image",
      "deployment",
      "Kubernetes",
      "Google Cloud Platform",
      "Google Container Registry",
      "Kubernetes Deployment",
      "Codeship Docker Platform",
      "Docker image push",
      "set Docker image",
      "Codeship Docker workflow",
      "functioning Kubernetes Deployment",
      "Deployment update",
      "previously defined Deployment",
      "automatic Kubernetes Deployment",
      "Kubernetes Deployment update",
      "title  Continuous\u00c2 Deployment",
      "powerful automated deployment",
      "\u00e2\u20ac\u2039Codeship Docker Platform\u00e2\u20ac\u2039",
      "Docker\u00c2 Apps",
      "Google Cloud service",
      "Google Cloud Registry",
      "Google Cloud environment",
      "encrypted environment file",
      "Docker images",
      "Google Cloud services",
      "Deployment update command",
      "Google Cloud Key",
      "current build",
      "Google Project ID",
      "Google Authentication Email",
      "Deployment updates",
      "Deployment definitions",
      "registry push step",
      "appropriate Deployment",
      "deployment workflows",
      "kubernetes cluster",
      "\u00e2\u20ac\u2039built-in push steps\u00e2\u20ac\u2039",
      "push image_name",
      "complex container architecture",
      "multiple nodes",
      "previously defined gcr_dockercfg",
      "new code",
      "actual Kubernetes interactions",
      "previously defined google_cloud_deployment",
      "container image",
      "Container Registry Pushing",
      "relatively new way",
      "Container Registry URL",
      "smaller development project"
    ],
    "status": "complete"
  },
 }

太棒了！你会看到的最有趣的事情之一是系统试图生成“概念”。在上面的文档中，它选择了“云计算”这个概念，这是一个不错的高层次的分类。在对 50 篇文档进行测试后，我们发现这个概念往往很宽泛。关于概念的另一个有趣之处在于，当它们正确时，它们就非常正确；当它们错误时，它们就大错特错。没有中间地带。

未来，概念将是杀手级功能，可以直接用于我们的内容贡献者，无需任何修改。标签和关键词本质上是同一件事。但标签更静态且置信度更高。通常标签比关键词少，而关键词是文档提取的任何实体，因此遍布各处。我们同时使用两者，但我们对关键词的重视程度远低于标签。

对于标签，另一个很棒的功能是能够指定实体类型。准确性不是很高，但我希望它会随着文档的添加而学习。我们可以建立一个接受流程，因为如果我们不使用 auto-curate 参数，关键词和标签将作为建议出现，我们可以有一个手动接受流程。但现在，精度不是最重要的。考虑到我们能够输入到系统中的内容量，准确性水平已经足够。

展望未来

在我创建试用版时，网站功能需要启用，但我没有测试过。但是，我可以看到，如果我们决定让 Watson Content Hub 成为我们内容的最终目的地，那么拥有用于快速查看文章的网站将很有用。

在使用该平台的过程中，有几次内容无法检索，但这是间歇性的，所以总体性能很好。以下是我希望的功能：

根据标签自动填充类别：当标签与类别/分类法术语匹配时，自动填充类别将非常棒。这将使其作为 CMS 对我们更有用。然而，误报可能存在风险。

消歧：我希望能够根据类别或自定义词典进行一些消歧。许多标签和关键词在文档中以细微的变化重复出现。

澄清术语：例如，“分类法”和“类别”之间的区别不是 100% 清楚。它们似乎是相同的，但通过 API，你无法访问“分类法”。

更好的认证：我希望他们能像在其他产品中那样开始使用 API 密钥，以便于认证。

更好的文档搜索：API Explorer 中的文档非常扎实，特别是如果你以线性方式学习产品。我通常不这样学习 API，所以搜索至关重要。而且对于文档，如果你进行搜索，你会得到跨越不同产品的结果，而不仅仅是 WCH，这会耗费时间和并不总是准确的。

WCH 受到一些影响，因为它不直接面向应用程序开发者。该产品似乎仍然专注于通过 API 使用 Web 界面的用户。由于我们的主要用例是通过 API 使用，我感觉它不是优先事项。然而，UI/UX 简单易用，对于快速测试非常有帮助。我没有发现这带来了技术问题——只是不清楚开发者应该如何利用该产品以及关键用例是什么。因为我们是 100% 黑盒的，使用它可能不是一个很好的用例。

为什么选择 WCH

“CMS”这个词并没有完全体现 WCH 的价值。是的，你可以在那里存储内容，但它的强大之处在于分析如何提升内容。我来自 NLP 和内容管理平台背景，对我来说很清楚，WCH 相对于其他内容管理系统的真正价值在于内置的智能。正因为如此，以及以下其他原因，我们正在考虑将该平台完全集成到我们的应用程序中：

1. 集成简单。
2. 与 Watson 智能解决方案实现更大集成的前景。
3. 在使用该解决方案时，我对分析文档的性能感到非常震惊。一篇大约 850 字的文章分析耗时 1-2 秒。

WCH 将使我们无需手动集成开源 NLP 库（我们必须成为该领域的专家），从而降低将智能集成到我们的应用程序中的风险和所需时间。不到一天的时间，我们就完成了一个集成到我们代码库的原型，为我们的内容交付流程带来了巨大的价值。

有关 WCH 的更多信息，IBM 在此处有一个专门的开发者页面 在此。