3

IBM Watson Cognitive Insights (CI) サービスを使用して、自然言語検索機能を実装しようとしています。ユーザーが自然言語を使用して質問を入力し、CI コーパスから適切なドキュメントを返すことができるようにしたいと考えています。トレーニングの必要性を回避し、Watson インフラストラクチャのコストを抑えるために、Watson QA サービスではなく CI を使用しています (つまり、コーパス/ユース ケースごとに専用の Watson インスタンスが必要になるのを回避します)。

CI API を使用して必要なコーパスを構築することはできますが、可能な限り正確で正確なクエリを実行するには、どの API をどの順序で使用すればよいかわかりません。

私たちの当初の考えは次のとおりでした。

  1. ユーザーの自然言語の質問を受け入れ、そのテキスト文字列を「テキストの概念を識別する」API (CI API リファレンス ドキュメントの下から 6 番目にリストされている) に投稿して、質問に関連する概念のリストを取得します。

  2. 次に、「コーパス内で概念検索を実行する」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}]

最初の例からも「修復」の概念を取り戻すべきだったようです。「修復」を送信すると API が「修復」の概念を返すのに、「修復」という単語を含む「MySQL データベースの破損を修復するにはどうすればよいですか」というテキストを送信すると返されないのはなぜですか。</p>

Watson Concept Insights サービスに基づいて自然言語検索機能を実装する最良の方法についてアドバイスをお願いします (適切な場合は他のサービスと組み合わせてください)。

4

1 に答える 1

3

ご質問ありがとうございます。回答が遅くなり申し訳ありません。

最初の質問 - これは、この投稿の最初の段落で説明した目的を達成するための正しい方法ですか? 目的を達成するために、CI >API を別の方法で組み合わせたり、複数の Watson サービスを一緒に使用したりする必要がありますか?

上記の手順を実行することは、やりたいことを達成するための自然な方法です。ただし、「テキストに注釈を付ける」API は現在、コーパス内のドキュメントをコア ナレッジ グラフ内の概念に接続するためにシステムが持っているテクノロジーとまったく同じテクノロジーを使用しているため、個々の質問指向ではなく、より「段落」指向であることに注意してください。より正確に言えば、小さなテキストで概念を抽出する問題は、一般的に大きなテキストよりも困難です。なぜなら、後者には、正しい選択を行うために使用できるコンテキストがより多くあるからです。この観察により、注釈テキスト API は、その段落に焦点を当てているため、再びより保守的なルートに進みます。

そうは言っても、私たちが現在持っている /v2 API は概念抽出技術の速度と品質を向上させるので、自然言語の質問からトピックを抽出するためにそれを使用することに成功する可能性があります. これが私がすること/注意することです:

1) 入力の自然言語から CI が抽出したものをユーザーに明確に表示します。私たちの API は、概念ごとに少し要約を取得する方法を提供します。これは、概念が何を意味するかをユーザーに説明するために使用できます。それを使用してください。

2) 抽出された概念リストから概念を削除する (取り消し線を引く) 機能をユーザーに提供します。

3) 概念洞察の概念は現在、「トピック」の概念にほぼ対応しているため、より抽象的な意図を推測する方法はありません (たとえば、質問の意味の鍵が動詞または形容詞にある場合)。名詞に対して、概念の洞察はそれを推測するための貧弱な方法です)。ワトソンには、あなたが以前指摘したように、質問応答向けの技術があります (自然言語分類子はその構成要素の 1 つです)。

しかし明らかに、例の質問に関連する他の概念 (修復、破損、データベースなど) があります。

これと投稿された質問の残りの部分に対する答えは、ある意味では上記のとおりです。私たちの意図は、最初に説明したように、より簡単な作業である「より大きなテキスト」のテクノロジーを提供することでした。この質問が最初に投稿されてから、今日、新しいアノテーション テクノロジー (/v2) を導入したので、パフォーマンスが少し向上するかどうかを読者に確認することをお勧めします。

長期的には、一般的なアプリケーションのコンテキストを指定する正式な方法をユーザーに提供して、関連する概念を抽出できる可能性を高めるつもりです。また、ユーザーがカスタム コンセプトを指定できるようにする計画もあります。これは、ウィキペディアにないため、ユーザーが関心を持っている一部のトピックを現在のデザインに一致させることが不可能であることが過去に観察されたためです。

于 2015-09-13T12:14:42.443 に答える