IBM Cloud Docs
Discovery v2 へのマイグレーション

Discovery v2 へのマイグレーション

製品 Discovery v2の再設計が 2019 年 11 月に導入されました。 Discovery v2 は、 Discovery v1より大きな利点を提供します。

v1 Discovery サービス・インスタンスを Discovery v2にマイグレーションする方法 (データを移動してアプリケーションを更新する方法を含む) について説明します。

Discovery v1 と v2 の主な構造上の違いは以下のとおりです。

  • v2には環境の概念はありません。 ニーズに合った適切なサービス・プランを選択すると、デプロイメントの詳細 (サイズや索引容量など) が管理されます。 管理対象デプロイメントの場合は、プラス・プラン、エンタープライズ・プラン、プレミアム・プランなどを選択できます。 インストール済みデプロイメントの場合、サイジングは、 Cloud Pak for Dataでサービスをインストールするときに指定するデプロイメント・タイプによって管理されます。

  • v2には、単一の構成オブジェクトはありません。 文書に適用されるエンリッチメントの制御は、 v2のコレクションおよびプロジェクト・オブジェクトで管理されます。 取り込みの変換ステップをカスタマイズする機能など、その他の v1 構成機能は、 v2では使用できません。

  • v2のカスタム・エンリッチメントでは、より優れたプログラマチック・サポートを利用できます。 エンリッチメントを作成するために使用できる新しいエンリッチメント API メソッドが使用可能になりました。 v2 には、文書分類モデルをプログラマチックにトレーニングするために使用できる文書分類 API メソッドも導入されています。 API を使用して、これらのカスタム・エンリッチメントをコレクションに適用できます。

  • 自然言語照会検索の機能が v2 で拡張され、文書ごとの上位パッセージと、パッセージからの簡潔な回答を返すことができるようになりました。 表の取得など、その他の拡張検索機能が導入されました。 v2では、deduplication パラメーターは使用できず、連続関連性トレーニング機能および照会ロギング機能は使用できません。

  • 機能の違いについて詳しくは、 機能比較表 を参照してください。

  • 詳細な API の違いについて詳しくは、 API バージョンの比較 を参照してください。

Discovery v2 は、プラス・プランまたはエンタープライズ・プランのインスタンス、または 2020 年 7 月 15 日より後に作成されたプレミアム・プランのインスタンスのすべてのユーザーが使用できます。 v2 は、 IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data ユーザーも使用できます。

移行の概要

Discovery v1 から v2 へのマイグレーションは、独立して実行できるマルチステップ・プロセスです。

Discovery サービスの 2 つのバージョンには多くの違いがありますが、新しい v2 インスタンスで使用するために v1 インスタンスに適用された技法とユーティリティーを採用することができます。

v1 から v2にマイグレーションするには、以下の手順の概要を実行する必要があります。

  1. マイグレーションを計画します
  2. 文書を転送します
  3. v2 API を使用するようにアプリケーションを更新します
  4. リグレッション・テストを行い、更新されたアプリケーションをデプロイします。
  5. v1 プラン・サービス・インスタンスを削除します

API を使用してプログラマチックに変更する必要があるステップもあれば、製品のユーザー・インターフェースから行うことができる変更を必要とするステップもあります。

マイグレーションの計画

v2 インスタンスをプロビジョンする前に、 v2 の新機能について理解し、それが v1 とどのように異なるかを理解してください。 最初の v2 Plus プランのトライアル・インスタンスは、30 日間無料で使用できます。 トライアル版を最大限に活用するために、インスタンスをプロビジョンする前にマイグレーションについて学習し、マイグレーションの計画を立ててください。

マイグレーションを開始する準備ができたら、プロセスの完了時に自分とチームが従うことができるマイグレーション・スケジュールを作成します。 v2 サービスの使用に切り替える前、および v1 インスタンスを削除する前に、必ず新しい v2 サービス・インスタンスをセットアップし、新しいサービス・インスタンスでプロジェクトとコレクションを再作成してください。

Discovery v2 プランのオプションについて学習し、長期的なニーズに合った適切なプランを選択できるようにします。 開始するために使用するプラス・プランで十分です。 ただし、代わりにエンタープライズ・プランまたはプレミアム・プランを使用することもできます。 プラス・プランからは、エンタープライズ・プランへのインプレース・アップグレードを実行できますが、プレミアム・プランへのアップグレードは実行できません。

アプリケーションの適応方法の計画

バージョン間の主な変更点の 1 つは、 Discovery v2 がプロジェクトを導入することです。 プロジェクトは1つ以上のコレクションで構成されます。 プロジェクトを使用する利点は、1 つの照会を複数のコレクションに対して同時に実行できることです。 各コレクションには、アップロードしたドキュメントや、ウェブサイト、Microsoft SharePoint, などの単一のデータソースからクロールしたドキュメントを含めることができます。

プロジェクトを使用するようにアプリケーションを調整する際に考慮すべき事項:

  • 環境の概念は v2には存在しませんが、データは引き続きコレクションに編成されます。 v2では、コレクションはプロジェクトにグループ化されます。 ほとんどの場合、単一の v1 コレクションを単一の v2 コレクションにマイグレーションします。

    v1 コレクションに適用される関連性トレーニング情報を保持する場合は、 v2 プロジェクト内の単一のコレクションにコレクション文書を追加します。

  • 各 v2 プロジェクトに追加するコレクションの数を決定します。 コンテンツ・マイニング・プロジェクトを除くすべてのプロジェクト・タイプには、最大 5 つのコレクションを含めることができます。 データに適切なタイプのプロジェクトを選択します。

    検索結果を最適化するために、さまざまなエンリッチメントおよび構成オプションが、さまざまなプロジェクト・タイプに追加されるコレクションに自動的に適用されます。 詳しくは、以下のトピックを参照してください。

  • Discovery v2 API は、プロジェクトとコレクションを考慮するように変更されました。その他の機能拡張もあります。 一部の API 呼び出しは、照会の送信や関連性トレーニングの実行など、コレクション・レベルではなくプロジェクト・レベルでのアクションをサポートするように変更されました。 他の多くの API メソッドが変更され、一部は v2では使用できません。 v1 と v2 API メソッドの詳細な比較については、 API バージョンの比較 を参照してください。

サービス・プランの選択

PlusEnterprise、および Premium の管理対象プランから選択するか、 Discovery IBM Cloud Pak for Dataのカートリッジを購入してオンプレミス・インストールを選択します。 プランを選択する前に、各タイプのプランの利点と制限を確認してください。

以下の表に、 v1 と v2の間で一般的に類似している管理対象デプロイメントのプラン・タイプを示します。

類似計画
現行の v1 プラン v1 データ使用例 類似の v2 プラン
ライト 適用外 プラス・トライアル (30 日間のみ無料)
拡張 (低使用率) 1 カ月当たり 10,000 件の文書、10,000 件の照会 プラス
拡張 (高使用率) 1 カ月当たり 100,000 件の文書、100,000 件の照会 エンタープライズ
プレミアム 適用外 エンタープライズまたはプレミアム

使用されている現在のストレージ、文書、およびコレクションに関する情報を取得するには、製品のユーザー・インターフェース・ヘッダーから 「環境の詳細」 アイコンをクリックします。

ライト・プランや拡張プランなどの v1 プランから v2 プランへのインプレース・アップグレードは実行できません。 新しい v2 プランを作成してから、データを新しいサービス・インスタンスに移動する必要があります。 v1 から v2にデータをマイグレーションすると、 v1 と v2 の両方のインスタンスが同時にデプロイされる可能性があります。 この期間中は、最初のプラス・プラン・インスタンスで使用可能な 30 日間の無料試用版を使用することを検討してください。

メトリックの収集

マイグレーション後にサービス・インスタンス・データと比較できるように、以下の情報をメモしておきます。

  • コレクション回数

    v1のインスタンス内のコレクションの数を取得するには、 コレクションのリスト API を使用します。

  • コレクションごとの文書数

    v1のコレクション内のドキュメントの数を取得するには、 コレクションの詳細の取得 API を使用します。

    GET {url}/v1/environments/{environment_id}/collections/{collection_id}`
    

    この API は、コレクション内のドキュメントの状況に関する情報を返します。これには、使用可能なドキュメントの総数が含まれます。

    "document_counts": {
        "available": 34,
        "{other}":"{values...}"
    }
    

v1 から v2 への文書の転送

文書の転送方法は、 v1で文書を取り込むために使用された手法によって異なります。

一度に 1 つのコレクションを再作成します。 複数の取り込みプロセスを同時に開始すると、システム・リソースに負担を課し、処理の完了にかかる全体的な時間を増やすことができます。 また、取り込みプロセスによって生成されるすべての通知メッセージについても注意する必要があります。 取り込みの問題をトラブルシューティングする方が簡単です。例えば、一度に 1 つのコレクションを取り込む場合などです。

アップロードされたデータ

API を使用して文書を Discovery v1にアップロードした場合、文書をコレクションにアップロードするための類似の API が v2 で使用できます。 プロジェクトおよびコレクションの新しい配置を説明するプロセスを自動化するために使用するすべてのワークフローを更新する必要があります。

Discovery v1 に取り込んだ元の文書が使用できなくなった場合は、照会 API を使用して Discovery v1から文書テキストを抽出できます。 その後、 Discovery v2のコレクションにテキストを追加できます。 詳しくは、「 文書の回復」を参照してください。

クロールされたデータ

v1で外部データ・ソースのデータをクロールした場合は、 v2の同じ外部データ・ソースのデータを引き続きクロールできます。 すべての同じデータ・ソースがサポートされます。

外部データ・ソースからのデータを使用するには、 v2 プロジェクト内でコレクションを再作成し、データ・ソースのクロール方法を構成する必要があります。 詳しくは、 データ・ソースの概要 を参照してください。

このサービスは、外部データ・ソースから文書をクロールして取り込むための時間とリソースを必要とします。 コネクターを一度に 1 つずつ再作成します。 データを移行計画スケジュールに再クロールするのにかかる時間を考慮します。

事前構築されたデータ・コレクション

以下の組み込みデータ・ソース・コレクションは、 v2: では使用できません。

Watson Discovery ニュース
この事前にエンリッチされたデータ・ソースは、 v2では提供されません。 ニュース・データを取得する別の方法について詳しくは、 v2でのニュース・サービスの使用 を参照してください。
COVID-19 キット
この事前構築されたコレクションは、 IBM® watsonx™ Assistant および Discovery で構築された動的チャットボットを、 COVID-19に関するお客様の質問に答えるのに役立つように設計されています。 v2では、同様のソリューションを作成できます。 COVID-19 の質問に対する回答を得るために信頼できる Web サイトをクロールするコレクションを使用して、 「会話型検索 (Conversational Search)」 プロジェクト・タイプを作成します。

データの取り込み

v1 データを Discovery v2 インスタンスに取り込むには、以下の手順を実行します。

  1. v2 のサービスインスタンスを作成します。

  2. プロジェクトを作成する。

  3. コレクションをプロジェクトに追加します。

    • アップロードされたデータ:

      API から、コレクションを作成し、2 つの別個のメソッドを使用してコレクションに文書を追加します。 Create a collection メソッドを使用して、コレクションを作成します。 次に、 v1 コレクションに追加したものと同じソース文書を v2 コレクションに追加します。 「文書の追加」 メソッドまたは 「文書の更新」 メソッドを使用します。 v2 コレクションに追加する文書に同じ v1 文書 ID を割り当てるには、その文書 ID をエンドポイントに追加します。 詳しくは、 文書 ID の保持 を参照してください。

      v2 製品ユーザー・インターフェースから、 v1 コレクションに追加したものと同じソース文書を v2 コレクションにアップロードします。

    • クロールされたデータ: v2では、外部データ・ソースからプログラマチックにデータをクロールすることはできません。 製品のユーザー・インターフェースから、外部データ・ソースへの接続を再作成し、外部データ・ソースを最初からクロールします。

  4. 製品のユーザー・インターフェースから、 Discovery v2 コレクションを構成できます。 例えば、光学式文字認識を使用可能にするかどうかを選択できます。 外部データ・ソースの場合は、クロール・スケジュールを設定できます。

  5. データにエンリッチメントを適用します。 事前作成された自然言語処理エンリッチメントまたは作成したカスタム・エンリッチメントを適用できます。

    v1では、エンリッチメントは、環境の作成時に生成される構成に関連付けられます。 v2では、エンリッチメントはコレクション構成に関連付けられます。 一部のエンリッチメントは、使用するプロジェクトのタイプに応じて、デフォルトでコレクションに適用されます。 詳しくは、 デフォルトのプロジェクト設定 を参照してください。 v2では、文書のフィールドで使用可能なエンリッチメントの任意のサブセットを使用するようにコレクションを構成できます。

文書 ID の保持

文書 ID は、製品ユーザー・インターフェースからアップロードするとき、または 文書の追加 API メソッドを使用して追加するときに、 v2 コレクションに追加する文書に割り当てられます。

これらの固有 ID に依存するプロセスを使用している場合は、 v1 文書の ID を v2 に保持することをお勧めします。 例えば、アプリケーションのリグレッション・テストでは、文書 ID を検査することによって、特定の文書が返されることを検証できます。 関連性トレーニングでは、文書 ID を使用して、トレーニング実行間で文書を追跡します。 v1 インスタンスと v2 インスタンスの間で文書 ID が同じであれば、これらのプロセスの適応が容易になります。 それ以外の場合、 Discovery v1 インスタンスで使用されるプロセスは、 Discovery v2 インスタンスに追加された文書に割り当てられた ID に再マップする必要があります。

v1 サービス・インスタンスに文書を追加したときに独自の文書 ID を指定した場合は、 「文書の追加」 メソッドではなく 「文書の更新」 メソッドを使用して ID を保持できます。 update メソッドを使用すると、文書を v2 コレクションに追加するときに、文書 ID を文書に割り当てることができます。 詳しくは、 文書の更新を参照してください。

データが JSON ファイルに保管されている場合、元の文書内の配列によって、番号が付加された文書 ID が生成されます。 例えば、original_id_n です。 番号接尾部を付けずに元の文書 ID を保持するには、JSON ファイル内の配列を削除します。 例えば、 [ {"name": "value"} ]{"name": "value"} に変更します。

v1 文書にシステム生成 ID がある場合は、空の 検索照会 を送信して、文書とその ID のリストを取得できます。 その後、 v2で新規コレクションに追加するときに、各文書に同じ ID を割り当てることができます。

文書のリカバリー

場合によっては、 Discovery V1 に取り込まれた元の文書が使用できなくなります。 Discovery v1 インスタンスを使用して、文書から情報を取得できます。 Discovery は、取り込む各文書のテキスト・コピーを作成します。 コピーはテキストのみであるため、HTML、PDF、またはその他の非テキスト形式の文書はテキストのみのバージョンに変換されます。

この方法を使用すると、コレクション内の最初の 10,000 個の文書のみをリカバリーできます。 10,000 個を超える文書を復旧する方法について詳しくは、 コレクションからの 10,000 個を超える文書の復旧 を参照してください。

文書情報を v1 から v2に転送するには、以下の手順を実行します。

  1. API を使用して 空の照会を送信 することにより、 v1 から文書を抽出します。

    例えば、GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q= です。

    API は結果を返します。 matching_results フィールドは、結果の総数を指定します。 results オブジェクトは、一致する文書を返します。 各文書は、個別の JSON オブジェクトとして返されます。 デフォルトでは、最大 10 個の文書を返します。

    {
      "matching_results": 34,
      "session_token": "nnn",
      "results": [
        {"{result objects}":"{maximum of 10 by default}"}
      ]
    }
    
  2. count パラメーターと offset パラメーターを使用して、照会結果をページ送りし、すべての文書を保存することができます。

    例えば、一度に 100 個の文書を取得するには、 count100 に設定し、 offset0 に設定して、照会を実行依頼します。

    GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=0
    

    次に、カウントを再び 100 に設定できますが、今回はオフセットを 100 に設定して次の 100 個の文書を取得します。

    GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=100`
    

    すべての文書を取得するまで、オフセットを 100 ずつ増分して、このプロセスを繰り返します。

  3. エクスポートされた文書が v2に取り込まれるように準備します。

    Discovery v1 から取得した結果の各 JSON ファイルには、元の文書から抽出されたデータ (テキスト、HTML、その他のフィールドなど) が含まれています。 カスタム・メタデータが v1にアップロードされたときに文書に関連付けられていた場合は、JSON ファイルにも存在します。 さらに、このファイルには、 v1 分析によって生成されたいくつかのフィールドが含まれています。 Discovery v2に追加する文書の一部として、このデータのサブセットのみを保持します。

    以下のヒントは、保持するフィールドを決定するのに役立ちます。

    • Discovery v2でエンリッチまたは検索できるようにするテキスト・コンテンツを含む text フィールドまたはその他のフィールドを含めます。
    • 文書に保管されているすべてのカスタム・メタデータを含めます。 このメタデータは通常、 Discovery を使用するアプリケーションに固有であり、検索で文書をフィルタリングするために使用されます。 例えば、metadata.customer_id です。
    • Discovery v1からのエンリッチメントを含めないでください。 例えば、 enriched_text.entities. Discovery v2 は、独自のエンリッチメントを生成します。
    • Discovery によって生成されるフィールドを除外します。ただし、これらのフィールドがアプリケーションによって使用され、文書の v1 バージョンに固有の情報が含まれている場合を除きます。 その場合は、フィールドの名前を変更して、文書が Discovery v2に取り込まれたときに置換されないようにします。 例えば、 extracted_metadata.publicationdate は、文書が取り込まれたときに Discovery によって生成されるフィールドです。 単一のソース文書からサブドキュメントがどのように生成されたかを理解するために、 v1 の metadata.parent_document_id 情報を保持したい場合があります。
    • 予約フィールド名を持つフィールドは避けてください。 詳しくは、 フィールドの処理方法 を参照してください。
  4. 編集した各 v1 JSON 文書を Discovery v2 インスタンスに取り込みます。 Discovery v1 文書 ID は、 Discovery v2で保守できます。 文書 ID を保持する方法について詳しくは、 文書 ID の保持 を参照してください。

コレクションからの 10,000 個を超える文書のリカバリー

1 つの照会で返すことができる文書の最大数は 10,000 個です。 ただし、コレクションから 10,000 個を超える文書をリカバリーする場合は、文書を重複しないサブグループに分割する方法が必要です。 各サブグループには、照会で返すことができる文書が 10,000 個未満でなければなりません。 その後、結果をページ編集して文書を取得できます。

結果のページ編集は、照会によって返される最大 10,000 個の文書に制限されます。 具体的には、 count ページ編集パラメーターと offset ページ編集パラメーターを組み合わせて使用すると、10,000 ドキュメントを超えることはできません。

文書を重複しないサブグループに分割する 1 つの方法は、すべての文書に存在し、固有値を含むフィールドを活用することです。 例えば、 SHA-1 フィールドには、元のソース・ファイルのハッシュが含まれ、16 進数ストリング値としてフォーマット設定されます。 コレクションをサブグループに分割する方法として、フィールドの先頭文字を使用できます。 SHA-1 には 16 進値が含まれているため、最初の文字には最大 16 個の可能な値 (0 から 9 または a から f) を入れることができます。 first_char_of (SHA-1) == 0 でフィルタリングすると、コレクション全体の約 1/16 が返される可能性があります。 その後、可能な 16 個の値のそれぞれをループして、残りの文書を取得できます。 いずれかのサブグループで最適な数の文書が返されない場合は、代わりに SHA-1 フィールドの最初の 2 文字を使用して、コレクションを 256 個のサブグループに分割できます。

関連性トレーニングの転送

Discovery v1 で行われた関連性トレーニングを Discovery v2に転送できます。 トレーニングの転送は、 Discovery v1 コレクションからの同じ文書を含む 1 つのコレクションを持つ Discovery v2 プロジェクトで最適に機能します。

コレクションが追加された場合や文書が変更された場合でも、関連性トレーニングを転送できます。 ただし、変更を反映するためにトレーニングを更新する必要があります。

関連性トレーニングを転送するには、以下のステップを実行します。

  1. Discovery v2に文書をロードします。

  2. Discovery v1で関連性トレーニングに使用された照会をプログラムでダウンロードします。 詳しくは、 トレーニング・データのリストを参照してください。

  3. Discovery v2でプログラマチックに関連性トレーニング・データを再作成します。 「照会の作成」 メソッドを使用して、各トレーニング照会を個別に追加します。 詳しくは、 トレーニング照会の作成を参照してください。

    必ず v2 コレクション ID を指定してください。 文書 ID も指定する必要があります。

    v1 コレクションと v2 コレクションの間で 文書 ID を保持 しなかった場合は、ダウンロードした照会例で参照されている v1 文書 ID に対応する v2 文書 ID を見つける必要があります。

モデルの転送

v1 で作成した一部のモデルを v2 プロジェクトで再利用できます。

Smart Document Understading (SDU) モデル

ディスカバリー v1 で作成された SDU モデルを Discovery v2にインポートできます。 ただし、モデルのパフォーマンスはバージョンによって異なる場合があります。 v2 の v1 SDU モデルの結果を比較して、動作が同じであることを確認します。 インポートされた v1 SDU モデルは編集できません。 インポートされたモデルが、 v1 で認識した文書要素、およびユース・ケースにとって重要な文書要素を認識できない場合は、 Discovery v2 製品ユーザー・インターフェースで SDU モデルを再作成する必要があります。 詳しくは、 v1 資料の SDU モデルのエクスポート 、および v2 資料の SDU モデルのインポート を参照してください。

機械学習モデル

Knowledge Studioから Discovery v2 サービス・インスタンスにモデルを直接デプロイすることはできません。 代わりに、 Knowledge Studioから機械学習モデルをエクスポートして、 Discoveryにインポートする必要があります。 モデルは、2020 年 7 月 16 日以降に Knowledge Studio からエクスポートされている必要があります。 その日付より前にエクスポートされたモデルがある場合は、 Knowledge Studioからそのモデルを再エクスポートする必要があります。 モデルのエクスポートをサポートするのは、有料の Knowledge Studio プランのみです。

詳しくは、以下のいずれかのトピックを参照してください。

モデルを Discovery v2にインポートする方法については、 Machine Learning モデルのインポート を参照してください。

v2 API を使用するためのアプリケーションの更新

Watson Developer SDK は、 Discovery v1 と v2の両方をサポートします。

以下の手順は、アプリケーションが最新バージョンの v1 API (バージョン 2019-04-30) を使用していることを前提としています。

現在 Discovery v1 API を使用して v2を使用するアプリケーションを移植する場合は、2 つのバージョン間の以下の大まかな違いに対処する方法を計画する必要があります。

これらの大まかな変更に加えて、メソッドごとのレベルで相違点を検討して、他に何を変更する必要があるかを理解してください。 詳しくは、 API バージョンの比較 を参照してください。

  • v2 は、プロジェクトおよびコレクションごとにデータを編成します。環境の概念はありません。 例えば、以下の要求を比較してコレクションを取得します。

    v1 コレクションの取得

    GET {url}/v1/environments/{environment_id}/collections/{collection_id}
    

    v2 コレクションの取得

    GET {url}/v2/projects/{project_id}/collections/{collection_id}
    
  • v1では、関連性トレーニングは単一のコレクションに対して実行されます。 v2では、関連性トレーニングはプロジェクトに対して実行されます。 プロジェクトには多数のコレクションが含まれている場合があります。 その場合、関連性トレーニングはすべてのコレクションに適用されます。 関連性トレーニングを転送する方法については、 関連性トレーニングの転送 を参照してください。

    例えば、関連性トレーニングの状況を返す以下の要求を比較します。

    v1 コレクションの取得

    GET {url}/v1/environments/{environment_id}/collections/{collection_id}
    

    v2 プロジェクトの取得

    GET {url}/v2/projects/{project_id}
    
  • 照会の送信は、2 つのバージョン間で似ています。 v2では、プロジェクト内のすべてのコレクションを照会することも、 collection_ids パラメーターを指定して照会を 1 つ以上のコレクションに制限することもできます。 例えば、以下の要求を比較してデータを照会します。

    v1 照会 要求

    POST {url}/v1/environments/{environment_id}/collections/{collection_id}/query
    

    要求とともに送信されるデータ:

    {
      "query": "text:IBM"
    }
    

    v2 照会 要求

    POST {url}/v2/projects/{project_id}/query
    

    要求とともに送信されるデータ:

    {
      "collection_ids": [
        "{collection_id_1}",
        "{collection_id_2}"
      ],
      "query": "text:IBM"
    }
    

    オプションで、 collection_ids パラメーターを省略して、プロジェクト内のすべてのコレクションを照会することができます。

  • 照会の passage パラメーターに、文書の品質によって文書をランク付けする新しい per_document オプションが追加されました。このオプションは、応答の結果リスト内の文書項目ごとに、文書ごとに最もランクの高いパッセージを document_passages フィールドに返します。 false の場合、文書の品質に関係なく、すべての文書のパッセージをパッセージ品質によってランク付けし、応答の別個のパッセージ・フィールドに返します。

  • 照会に対してパッセージが返された場合は、回答の検索を有効にすることもできます。 true の場合、応答オブジェクトは、照会結果の各パッセージの一部として返されます。 find_answersper_document の両方が true に設定されている場合、各文書内の文書検索結果とパッセージ検索結果は、回答の信頼性を使用して再配列されます。 この再配列の目的は、最初の文書の最初のパッセージの最初の回答として最良の回答を配置することです。 同様に、 find_answers パラメーターが true に設定され、per_document パラメーターが false に設定されている場合、パッセージ検索結果は、各文書とパッセージの信頼性の高い回答の降順で再配列されます。

  • v1 と v2 の両方でカスタム・ストップワードがサポートされます。 ただし、カスタム・ストップワードの使用方法には、以下のようないくつかの違いがあります。

    • v2の日本語コレクションには、デフォルトのカスタム・ストップワード・リストはありません。
    • v1でカスタム・ストップワードを定義すると、既存のストップワード・リストがストップワード・リストに置き換わります。 v2では、リストによってデフォルト・リストが拡張されます。 リストを置き換えることはできません。つまり、 v2のデフォルト・リストに含まれているストップワードを削除することはできません。

アプリケーションが照会結果を処理する方法を更新する

v1 照会と v2 照会の間で照会結果文書の構文に以下の違いがあるため、アプリケーションが照会結果を表示する方法を更新する必要がある場合があります。

  • エンティティー・エンリッチ・レベルでは、以下の情報は v2: ではサポートされません。

    • 明確化
    • 感情
    • 評判

    「品詞 (Part of Speech)」 エンリッチメントは、 v2のほとんどのプロジェクト・タイプの文書に自動的に適用されますが、エンリッチメントによって生成される索引フィールドは文書の JSON 表現には表示されません。

    エンティティのデータ構造の違い*
    のデータ構造の違い

  • v1の count および relevance の代わりに、 v2 にはメンションが含まれます。

    メンション内の各エントリーは、文書テキスト内のエンティティーのオカレンスに対応します。 以下の例では、7 つのオカレンスが検出されます。 出現箇所ごとに、信頼性スコアとメンション・テキストのオフセットが表示されます。 結果がユーザー・インターフェースに表示されるときに、オフセットを使用して文書テキスト内のメンションを強調表示できます。

    Mentions in Discovery v2
    Entity mentions in Discovery v2

  • 照会応答の JSON 構造は、 v2では若干再配置されます。

  • 重複排除情報は、 v2 照会応答には含まれません。

  • v2では、 enriched_text はオブジェクトではなく配列です。

  • Discovery v2では、エンティティー v2 エンリッチメントが使用されます。 v2 のエンティティー・タイプ名は、すべて大文字ではなく、ヘッドライン・ケースで指定されます。 エンティティー名を指定する照会または集約を使用する場合は、大文字化を変更する必要があります。 例えば、 PERSONPerson に変更します。

  • コレクションに追加された JSON ファイルのフィールドは、 v1 と v2の間の取り込み時に異なる方法で変換されます。 アプリケーションがこれらの結果を操作する場合は、調整が必要になることがあります。

    JSON フィールドを移動またはマージするには、API の Update a collection メソッドで normalizations オブジェクトと conversions オブジェクトを指定できます。

    JSON ソース・フィールドの処理方法
    元の JSON フィールドの内容 v1 表現 v2 表現 注記
    "field": null "field": null N/A v1 は NULL 値を保持します。 v2 は、ヌル・フィールドをすべてスキップします。
    "field": "" "field": "" N/A v1 は空のテキスト値を保持します。 v2 は、空のテキスト・フィールドをすべてスキップします。
    "field": "value2" "field": "value2" "field": "value2" 違いはありません。
    "field": [] "field": [] N/A v1 は空の配列を保持します。 v2 は、空の配列のフィールドをすべてスキップします。
    "field": [ "value4" ] "field": [ "value4" ] "field": "value4" v1 は singleton 配列を保持します。 v2 は、singleton 配列を値のみに変換します。配列の一部としては保管されません。
    "field": [ 1, 2, 3 ] "field": [ 1, 2, 3 ] "field": [ 1, 2, 3 ] 違いはありません。
    "field": [ "v6", "v7", "v8" ] "field": [ "v6", "v7", "v8"] "field": [ "v6", "v7", "v8"] 違いはありません。

データが正常にマイグレーションされたことの確認

マイグレーションが成功したことを確認するには、以下のメトリックを、 マイグレーション前にメモしたメトリック と比較します。

  • コレクション回数

    v1 で使用し、保持したいすべてのコレクションを必ず再作成してください。 v2 コレクションのリスト API メソッドを使用すると、コレクションのリストを取得できますが、プロジェクトごとに要求を送信する必要があります。 サービス・インスタンスごとのコレクションの総数を取得するために 1 つの呼び出しを使用することはできません。

  • コレクションごとの文書数

    データがアップロードされたコレクションの場合、 プロジェクトの照会 API メソッドを使用して空の照会を送信することにより、コレクション内の文書の数を確認します。 結果を 1 つのコレクション内の文書のみに制限するには、コレクション ID パラメーターを指定します。 空の照会では、すべての文書が返されます。 そのため、返答文書の matching_results 値から文書の総数を取得できます。

    コレクションごとの文書の数は、 v1の同じコレクションに保管された文書の数に近いはずです。 数値が同じではない可能性があります。

    クロールされたデータについては、 v2 コレクションの文書数が少ないとしても驚かないでください。 v1 コネクターは、外部データ・ソースから削除された文書を Discovery コレクションから削除しません。 コレクションの v2 バージョンには、今日の外部データ・ソースに存在するデータのより新しいクロールがあります。

v1 インスタンスと v2 インスタンスで送信する照会では、検索結果が同じになると想定しないでください。

v2 でのニュース・サービスの使用

Watson Discovery ニュース・データ・ソースを v1 で使用していて、 v2の同等の機能を持つデータ・ソースを作成する場合は、ニュースおよびイベント・データ・プロバイダー・サービスを見つけます。 JSON 形式でニュース記事を抽出するニュース API を提供するサービスを探します。 その後、JSON ファイルをアップロードして、 v2 プロジェクトにニュース・コレクションを作成できます。

v1 サービスインスタンスを削除する

データがマイグレーションされ、新しい v2 サービス・インスタンスを使用するようにアプリケーションが更新されたら、必ず v1 サービス・インスタンスを削除してください。 v1 サービス・インスタンスは、削除するまで課金されます。 詳しくは、 管理対象サービス・インスタンスの削除 を参照してください。