我们正在尝试使用IBM Watson Cognitive Insights（CI）服务实现自然语言搜索功能。我们希望用户能够使用自然语言键入问题，然后从CI语料库返回相应的文档。我们使用CI而不是Watson QA服务来避免培训需求并降低Watson基础架构成本（即避免为每个语料库/用例使用专用的Watson实例）。
我们能够通过CI API构建必要的语料库，但我们不确定使用哪种API来实现最精确/准确的查询。
我们最初的想法是：
接受用户的自然语言问题，并将该文本字符串发布到“识别文本中的概念”API（在CI API参考文档的底部列出第6位），以获取与问题。
然后使用“在语料库中执行概念搜索”API（在CI API参考文档的底部列出第3个）进行GET，以从语料库中获取相关文档的列表。
第一个问题 - 这是实现本文第一段所述目标的正确方法吗？我们是应该以不同方式组合CI API还是一起使用多个Watson服务来实现目标？
如果我们的初始方法是正确的，那么我们发现当我们提交一个简单的问题（例如“我如何修复MySQL数据库损坏”）到“识别一段文本中的概念”API时，我们不是获得一个完整的相关概念列表。例如：
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}]
似乎我们应该从第一个例子中恢复“修复”概念。当我们提交＆＃34;修复＆＃34;时，为什么API会返回“修复”概念？但是当我们提交“我如何修复MySQL数据库损坏”文本时，并不包括“修复”一词。
请告知基于Watson Concept Insights服务实现自然语言搜索功能的最佳方式（如果合适，可能与其他服务结合使用）。
答案 0 :(得分：3)
非常感谢您提出的问题以及对于回答这么迟的道歉。
第一个问题 - 这是实现我们的目标的正确方法＆gt;在本文的第一段中描述了吗？我们应该以不同的方式组合CI＆gt; API，还是一起使用多个Watson服务来实现目标？
执行上述步骤将是完成您要执行的操作的自然方式。但请注意，“注释文本”API使用的系统目前使用的技术与将语料库中的文档连接到核心知识图中的概念完全相同，因此，它更加“段落”而不是面向问题。更确切地说，在较小的文本中提取概念的问题通常比在较大的文本中提取更困难，因为在后者中有更多的上下文可用于做出正确的选择。鉴于此观察结果，注释文本API在其段落焦点的情况下再次成为更保守的路径。
话虽如此，我们现在拥有的/ v2 API确实提高了概念提取技术的速度和质量，因此您可以更成功地使用它来从自然语言问题中提取主题。以下是我要做的/注意的事项：
1）清楚地向用户显示从输入中的自然语言中提取的CI。我们的API为您提供了一种方法，可以检索每个概念的一些摘要，可以用来向用户解释概念的含义 - 使用它。
2）让用户能够从提取的概念列表中删除概念（将其删除）
3）由于概念洞察中的概念目前大致与“主题”的概念相对应，因此无法推断出更抽象的意图（例如，如果问题含义的关键是动词或形容词而不是名词，概念见解将是推断它的一种不好的方式）。正如你之前所指出的那样，Watson确实有面向问答的技术（自然语言分类器是其中的一个组成部分），所以我会看一下。
显然，还有其他与示例问题相关的概念＆gt;（修复，损坏，数据库等）。
对此以及所发布问题的其余部分的答案在某种意义上 - 我们的目的是首先为“大文本”提供技术，正如我所解释的那样，这是一项更容易的任务。由于这个问题是第一次发布的，今天我们确实引入了新的注释技术（/ v2），所以我鼓励读者看看它是否表现得更好。
从长远来看，我们的目的是为用户提供一种正式的方式来指定一般应用程序的上下文，以便提取相关概念的机会增加。我们还计划让用户能够指定自定义概念，因为过去已经观察到用户感兴趣的某些主题在我们当前的设计中无法匹配，因为它们不在维基百科中。