3

我们正在尝试使用 IBM Watson Cognitive Insights (CI) 服务来实现自然语言搜索功能。我们希望用户能够使用自然语言输入问题，然后从 CI 语料库中返回适当的文档。我们使用 CI 而不是 Watson QA 服务来避免培训需求并降低 Watson 基础架构成本（即避免每个语料库/用例都需要专用的 Watson 实例）。

我们能够通过 CI API 构建必要的语料库，但我们不确定以什么顺序使用哪些 API 来完成最精确/准确的查询。

我们最初的想法是：

  1. 接受用户的自然语言问题并将该文本字符串发布到“识别一段文本中的概念”API（在 CI API 参考文档中从底部倒数第 6 位）以获取与问题相关的概念列表。

  2. 然后使用“在语料库中执行概念搜索”API（在 CI API 参考文档中从底部倒数第 3 个）执行 GET，以从语料库中获取相关文档的列表。

第一个问题——这是实现本文第一段所述目标的正确方法吗？我们应该以不同的方式组合 CI API 还是同时使用多个 Watson 服务来实现目标？

如果我们最初的方法是正确的，那么我们会发现当我们向“识别一段文本中的概念”API 提交一个简单的问题（例如“我如何修复 MySQL 数据库损坏”）时，我们并没有得到全面的返回相关概念列表。例如：

curl -u userid:password -k -d "How can I repair MySQL database corruption" https://gateway.watsonplatform.net/concept-insights-beta/api/v1/graph/wikipedia/en-20120601?func=annotateText

返回：

[{"concept":"/graph/wikipedia/en-20120601/MySQL","coords":[[17,22]],"weight":0.85504603}]

然而，显然还有其他与示例问题相关的概念（修复、损坏、数据库等）。

在另一个示例中，我们刚刚将文本“修复”提交给“识别一段文本中的概念”API：

curl -u userid:password -k -d "repair" https://gateway.watsonplatform.net/concept-insights-beta/api/v1/graph/wikipedia/en-20120601?func=annotateText

它返回：

[{"concept":"/graph/wikipedia/en-20120601/Repair","coords":[[0,6]],"weight":0.65392953}]

似乎我们也应该从第一个示例中恢复“修复”概念。为什么我们提交“repair”时API会返回“repair”概念，但提交文本“How can I repair MySQL database corruption”时却没有返回，其中还包含“repair”一词。</p>

请就基于 Watson Concept Insights 服务实现自然语言搜索功能的最佳方式提出建议（如果合适，可能与其他服务结合使用）。

4

1 回答 1

3

非常感谢你的问题，我很抱歉这么晚才回答。

第一个问题——这是实现本文第一段所述目标的正确方法吗？我们应该以不同的方式组合 CI >API 还是同时使用多个 Watson 服务来实现目标？

执行上述步骤将是完成您想做的事情的自然方式。但是请注意，“注释文本”API 目前使用的技术与系统用于将语料库中的文档连接到核心知识图中的概念完全相同的技术，因此，它更面向“段落”而不是面向单个问题。更准确地说，在较小的文本中提取概念的问题通常比在较大的文本中更困难，因为在后者中有更多的上下文可用于做出正确的选择。鉴于这一观察，注释文本 API 再次走更保守的路线，因为它以段落为重点。

话虽如此，我们现在拥有的 /v2 API 确实提高了概念提取技术的速度和质量，因此使用它从自然语言问题中提取主题可能会更成功。这是我会做/注意的事情：

1) 向用户清楚地显示输入中从自然语言中提取的 CI。我们的 API 为您提供了一种方法来检索每个概念的一些抽象，它可以用来向用户解释一个概念的含义——请使用它。

2）让用户能够从提取的概念列表中删除一个概念（删除它）

3）由于目前概念洞察中的概念大致对应于“主题”的概念，因此无法推断出更抽象的意图（例如，如果问题意义的关键是动词或形容词，而不是对于名词，概念洞察力将是一种不好的推断方式）。正如您之前指出的那样，Watson 确实拥有面向问答的技术（自然语言分类器是其中的一个组成部分），所以我会看一下。

然而，显然还有其他与示例问题相关的概念>（修复、损坏、数据库等）。

从某种意义上说，这个问题和其余问题的答案都在上面——我们的目的是首先为“更大的文本”提供一种技术，正如我所解释的那样，这是一项更容易的任务。由于这个问题是第一次发布的，今天我们确实引入了新的注释技术（/v2），所以我鼓励读者看看它是否表现得更好。

从长远来看，我们确实打算为用户提供一种正式的方式来指定通用应用程序的上下文，从而增加提取相关概念的机会。我们还计划让用户能够指定自定义概念，因为过去已经观察到，用户感兴趣的某些主题无法在我们当前的设计中匹配，因为它们不在维基百科中。

于 2015-09-13T12:14:42.443 回答