記事をシェアする:

本ブログ記事は、IBM Cloud Docs の「Migrating to Discovery v2」ページ を翻訳したものです。最新情報は、https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2　をご参照ください。

 

再設計された Discovery は、2019 年 11 月に Discovery v2 としてリリースされました。Discovery v2 は、Discovery v1 よりもはるかに多くのメリットを提供します。

このトピックでは、データの移動とアプリケーションの更新の方法も含めて、Discovery v1 のサービス・インスタンスを Discovery v2 に移行する方法について説明します。

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

• v2 では、「環境」という概念がありません。ニーズに合った適切なサービス・プランを選択することによって、サイズや索引容量などのデプロイメントの詳細がすべて管理されます。マネージドのデプロイメントの場合、プラス・プラン、エンタープライズ・プラン、またはプレミアム・プランなどから選ぶことができます。インストールされたデプロイメントの場合、サイジングは Cloud Pak for Data にサービスをインストールする際に指定するデプロイメント・タイプによって管理されます。
• v2 では、単一の構成オブジェクトはありません。v2 では、文書に適用されるエンリッチメントの制御は、コレクションおよびプロジェクト・オブジェクト内で管理されます。取り込み時の変換ステップをカスタマイズできるなど、v1 で利用できた構成機能は v2 では使用できません。
• v2 では、カスタム・エンリッチメントのプログラミングへの対応が強化されています。エンリッチメントの作成に使用できる、新しいエンリッチメント API メソッドが提供されています。さらに v2 では、プログラムからの文書分類器モデル学習に使用できる、文書分類器の API メソッドも導入されました。API を使用して、後からカスタム・エンリッチメントをコレクションに適用することができます。
• v2 では自然言語照会の検索機能が拡張され、文書ごとに最も関連性の高いパッセージを返すことや、パッセージから簡潔な答えを返すことが可能になりました。表の検索など、その他の高度な検索機能も導入されています。v2 では、重複排除パラメーターや類似性パラメーターのほか、Continuous Relevancy Training と照会ロギングの機能が使用できなくなくなりました。
• 機能の違いについて詳しくは、the feature comparison table を参照してください。
• API の違いについて詳しくは、API version comparison を参照してください。

 

Discovery v2 は、プラス・プランまたはエンタープライズ・プランのインスタンス、あるいは 2020 年 7 月 16 日以降に作成されたプレミアム・プラン・インスタンスのすべてのユーザーが利用できます。v2 は、IBM Watson™ Discovery for IBM Cloud Pak® for Data カートリッジのユーザーも利用できます。

 

移行の概要

Discovery v1 から v2 への移行は、お客様に実施いただくプロセスで複数の手順で構成されます。

Discovery サービスの 2 つのバージョンの間には多くの違いがありますが、v1 のインスタンスで使用していた手法やユーティリティーを新規の v2 インスタンスでもそのまま使用できます。

v1 から v2 に移行するには、大きく分けて以下の手順を完了する必要があります。

1. 移行の計画
2. 文書の移行
3. v2 の API を使用できるようにするためのアプリケーションの更新
4. 回帰テストの実行と、更新されたアプリケーションのデプロイ

注記: API を使用したプログラムの変更が必要な手順もあれば、製品のユーザー・インターフェースで変更可能な手順もあります。

 

移行の計画

v2 インスタンスをプロビジョンする前に、v2 の新機能と v1 との違いについて理解を深めましょう。v2 のプラス・プランでは、最初のインスタンスを、30 日間の無料評価版として使用できます。インスタンスをプロビジョンする前に移行について理解を深めて、しっかりと計画を立てることで、無料評価版を最大限に活用できます。

移行を開始する準備が整ったら、プロセス完了に向けた移行スケジュールを作成します。v2 サービスの使用に切り替えてv1 インスタンスを削除する前に、必ず新規の v2 サービス・インスタンスをセットアップし、この新規サービスでプロジェクトとコレクションを再作成してください。

Discovery v2 のプラン・オプションを確認し、お客様の長期的なニーズに合ったプランを選択してください。手始めに使用したプラス・プランが十分ニーズを満たす場合もあれば、エンタープライズ・プランまたはプレミアム・プランを選択することもあるでしょう。プラス・プランからの直接アップグレードはエンタープライズ・プランに対しては可能ですが、プレミアム・プランに対してはできません。

 

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

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

 

プロジェクトが使用できるようにアプリケーションを適応させる際には、次の点を考慮します。

• v2 では「環境」という概念は存在しませんが、データは変わらずコレクションに編成されています。v2 では、コレクションがプロジェクトにグループ分けされています。ほとんどの場合において、単一の v1 コレクションを単一の v2 コレクションに移行することをお勧めします。
  v1 コレクションに適用されている関連性トレーニングの情報を維持したい場合は、コレクションの文書を単一の v2 プロジェクト・コレクションに追加してください。
• 各 v2 プロジェクトに追加するコレクションの数を決定します。コンテンツ・マイニング・プロジェクトを除くすべてのプロジェクト・タイプには、最大 5 個のコレクションを含めることができます。データに適したプロジェクト・タイプを選択するようにしてください。
  検索結果を最適化するために、それぞれ用途の違うプロジェクト・タイプに追加されるコレクションには、さまざまなエンリッチメントおよび構成オプションが自動的に適用されます。詳しくは、次のトピックを参照してください。

• • Project descriptions
  • Default project settings
  • Default query settings

• Discovery v2 APIは、特にプロジェクトとコレクションに対応できるように変更されました。一部の API 呼び出しは、コレクション・レベルではなく、プロジェクト・レベルでアクションをサポートするよう変更されました (照会の送信や関連性トレーニングの実行など)。その他多くの API メソッドが変更され、いくつかは v2 では使用できなくなっています。v1 と v2 の API メソッドの詳細な比較については、API version comparison を参照してください。

 

サービス・プランの選択

プラス、エンタープライズ、またはプレミアムのマネージド・プランから選択するか、または IBM Cloud Pak for Data の Discovery カートリッジを購入することで、オンプレミス・インストールを選択することができます。選択する前に、各プラン・タイプのメリットと制限を確認してください。

• プランについて詳しくは、Discovery pricing plan を参照してください。
• 成果物の上限について詳しくは、Limit details を参照してください。

 

v1 と v2 で類似するマネージド・デプロイメントのプラン・タイプを以下の表にまとめています。

現在のv1 プラン	v1 でのデータ使用量の例	類似のv2 プラン
ライト	N/A	プラスの評価版 (30 日間のみ無料)
拡張 (低い使用量を想定)	1 カ月当たり 10,000 文書、10,000 照会	プラス
拡張 (高い使用量を想定)	1 カ月当たり 100,000 文書、100,000 照会	エンタープライズ
プレミアム	N/A	エンタープライズまたはプレミアム

類似プラン

 

ヒント: 　現在使用されているストレージ、文書、およびコレクションの情報を表示するには、製品のユーザー・インターフェースの上部にある「環境の詳細 (Environment details)」アイコンをクリックしてください。

ライトまたは拡張などの v1 プランから v2 プランに直接アップグレードすることはできません。新規の v2 プランを作成してから、データを新規のサービス・インスタンスに移行してください。v1 から v2 へのデータ移行時には、v1 のインスタンスと v2 のインスタンスの両方が同時にデプロイされている可能性が高いです。この期間中は、最初のプラス・プラン・インスタンスで利用可能な 30 日間の無料評価版の活用を検討してください。

 

メトリックの収集

移行後にサービス・インスタンス・データと比較できるように、以下の情報を書き留めておきます。

• コレクションの数
  v1 インスタンスにあるコレクションの数を取得するには、List collections API を使用します。

• コレクションにある文書の数
  v1 のコレクションにある文書の数を取得するには、Get collection details API を使用します。GET {url}/v1/environment/{environment_id}/collections/{collection_id}`API が、使用可能な文書の合計数を含め、コレクションにある文書のステータスについて情報を返します。

“document_counts”: {
“available”: 34,
“{other}”:”{values…}”
}

 

v1 から v2 への文書の移行

文書の移行方法は、v1 で文書の取り込みに使用された手法によって異なります。

 

コレクションは 1 個ずつ再作成する必要があります。複数の取り込みプロセスを同時に開始すると、システム・リソースに高い負荷がかかり、プロセスが完了するまでの時間も長くなってしまいます。また、この取り込みプロセスで生成される情報メッセージにも注意してください。コレクションを 1 個ずつ取り込むことで、取り込み時に問題が発生してもトラブルシューティングが行いやすくなります。

 

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

API を使用して Discovery v1 に文書をアップロードしていた場合、v2 でも類似の API を使用してコレクションに文書をアップロードできます。プロジェクトとコレクションの新しい構成を反映するためには、プロセスの自動化に使用するあらゆるワークフローを更新する必要があります。

 

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

クロールされたデータ

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

 

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

 

サービスが外部データ・ソースから文書をクロールして取り込むには、時間とリソースがかかります。コネクターは 1 つずつ再作成してください。移行計画のスケジュールでは、データの再クロールにかかる時間も考慮してください。

 

事前作成済みのデータ・コレクション

v2 では、以下の組み込みのデータ・ソース・コレクションは使用できなくなりました。

 

Watson Discovery News

この事前にエンリッチされたデータ・ソースは v2 では使用できません。ニュース・データを取得する代替の方法について詳しくは、v2 でのニュース・サービスの使用を参照してください。

 

COVID-19 キット

これは、COVID-19 に関する顧客の質問に回答するための IBM Watson™ Assistant と Discovery で構築された動的チャットボットを強化することを目的とした、事前作成済みのコレクションです。v2 では、類似ソリューションを構築できます。COVID-19 の質問に対する答えを提供している、信頼できる Web サイトをクロールするコレクションを追加した、会話型検索 (Conversational Search) プロジェクト・タイプを作成します。詳しくは、 チュートリアルを参照してください。

 

データの取り込み

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

① v2 サービス・インスタンスを作成する。

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

③プロジェクトにコレクションを追加する。

• アップロードされたデータ:
  API を使用して、２つの個別メソッドで、コレクションを作成し、文書を追加します。まず、Create a collection メソッドでコレクションを作成します。次に、v1 コレクションに追加したソース文書と同じものを v2 コレクションに追加します。Add document または Update document メソッドを使用します。v2 コレクションに追加する文書に v1 の文書 ID と同じものを割り当てるには、エンドポイントに文書 ID を追加します。詳しくは、文書 ID の維持を参照してください。v2 の製品ユーザー・インターフェースを使用して、v2 コレクションに v1 コレクションに追加したソース文書と同じものを追加します。
• クロールされたデータ: v2 では、データを外部データ・ソースからプログラムでクロールすることはできません。製品ユーザー・インターフェースを使用して外部データ・ソースへの接続を再作成し、最初から外部データ・ソースをクロールし直します。

④ 製品ユーザー・インターフェースを使用して、Discovery v2 コレクションを構成できます。例えば、光学式文字認識 (OCR) や FAQ の抽出の設定を有効または無効に設定できます。外部データ・ソースに対しては、クロール・スケジュールを設定できます。

⑤ データにエンリッチメントを適用します。事前作成済みの自然言語処理 (NLP) エンリッチメント、またはお客様が作成するカスタム・エンリッチメントを適用できます。

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

 

文書 ID の維持

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

 

このような一意の識別子を利用するプロセスを実行している場合、v1 文書 ID を v2 でもそのまま維持することが望ましいこともあります。例えば、アプリケーションの回帰テストでは、文書 ID をチェックすることによって、特定の文書の検証結果を返すものもあります。関連性トレーニングでは、文書 ID を使用して、実行されるトレーニングの間で文書を追跡します。v1 と v2 のインスタンスの間で同一の文書 ID を使用することで、これらのプロセスを適応しやすくなります。同一の文書 ID を使用しない場合、Discovery v1 インスタンスで使用されるプロセスを、Discovery v2 インスタンスに文書が追加されてから割り当てられる ID に再度マッピングする必要があります。

 

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

注記：データがJSONファイルに保存されている場合、元のドキュメントの配列は、番号が追加されたドキュメントIDを生成します。 たとえば、original_id_nです。 番号のサフィックスなしで元のドキュメントIDを保持するには、JSONファイルの配列を削除します。 たとえば、[{“name”：”value”}]を{“name”：”value”}に変更します。

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

 

文書のリカバリー

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

重要: この方式でリカバリーできるコレクションの文書は、最初の 10,000 文書のみです。

以下の手順に従って、文書の情報を v1 から v2 に移行します。submit an empty query API を使用して、v1 から文書を抽出します。

① submit an empty query API を使用して、v1 から文書を抽出します。

例:　GET {url}/v1/environment/{environment_id}/collections/{collection_id}/query?q=

API が結果を返します。matching_results フィールドが結果の合計数を示しています。results object が、一致する文書を返します。各ドキュメントは個別の JSON オブジェクトとして返されます。デフォルトで最大 10 文書を返します。

{
“matching_results”: 34,
“session_token”: “nnn”,
“results”: [
{“{result objects}”:”{maximum of 10 by default}”}
]
}

② count と offset のパラメーターを使用して、照会結果をページに分けて表示し、すべての文書を保存するように設定します。

例えば、1 回の照会で 100 文書を取得するには、count を 100 に、offset を 0 に設定して照会を送信します。

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

次に、count を 100 にしたまま、offset を 100 に設定して、次の 100 文書を取得します。

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

このように offset を 100 単位で増やしていき、すべての文書を取得するまでこのプロセスを繰り返します。

③ エクスポートされた文書を v2 に取り込むために準備します。

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

どのフィールドを維持するかを判断するには、以下のヒントを参照してください。

• Discovery v2 でエンリッチや検索の対象としたい text フィールドまたはその他のテキスト・コンテキストのフィールドを含めます。
• 文書に保管されたカスタム・メタデータを含めます。通常は Discovery を活用するアプリケーションに固有であるこのメタデータは、検索で文書をフィルターするために使用されます。
  例: customer_id
• Discovery v1 で適用されたエンリッチメントは含めません。
  例: entities
  Discovery v2 は独自のエンリッチメントを生成します。
• Discovery で生成されたフィールドは含めません。ただし、アプリケーションで活用され、文書の v1 バージョン固有の情報が含まれている場合を除きます。この場合、フィールドの名前を変更し、Discovery v2 への文書の取り込み時にフィールドが置き換えられないようにします。例えば、publicationdate は、文書が取り込まれると Discovery により生成されるフィールドです。また、v1 の metadata.parent_document_id の情報を維持することで、単一のソース文書からどのようにサブ文書が生成されたかを理解できます。
• 予約されているフィールド名を持つフィールドは避けるようにします。詳しくは、How fields are handled を参照してください。

④ それぞれ編集された v1 JSON 文書を Discovery v2 インスタンスに取り込みます。Discovery v1 の文書 ID は、Discovery v2 でそのまま維持できます。文書 ID の維持について詳しくは、文書 ID の維持を参照してください。

 

関連性トレーニングの移行

Discovery v1 で行った関連性トレーニングは、Discovery v2 に移行できます。トレーニングを移行するには、Discovery v1 のコレクションと同じ文書を含めたコレクション１つを追加した Discovery v2 プロジェクトを使用することが推奨されます。

コレクションが追加されたり、文書が変更されたりしても、関連性トレーニングは移行できます。しかし、このような変更を反映するために、トレーニングは必ず更新してください。

以下の手順に従って、関連性トレーニングを移行します。

1. Discovery v2 に文書をロードします。
2. Discovery v1 での関連性トレーニングに使用された照会をプログラムでダウンロードします。詳しくは、List training data を参照してください。
3. Discovery v2 で関連性トレーニングのデータをプログラムで再作成します。Create a query (照会の作成) メソッドを使用してトレーニングの照会を個別に追加します。詳しくは、Create a training query を参照してください。v2 コレクション ID を必ず指定してください。文書 ID も指定する必要があります。

注記: v1 と v2 のコレクションの間で文書 ID を維持しなかった場合、ダウンロードされた照会の例で参照されている v1 の文書 ID に該当する v2 の文書 ID を特定してください。

 

モデルの移行

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

SDU モデル

v1 で作成した SDU モデルを使用できますが、v2 に移行した SDU モデルを編集することはできません。モデルをそのまま再利用したい場合は、v1 からエクスポート (V1でのエクスポート) し、v2 に SDU モデルをインポート (SDUモデルのインポート) します。

機械学習モデル

Watson Knowledge Studio で作成してエクスポートされた機械学習モデルを Discovery にインポートできます。ただし、モデルが 2020 年 7 月 16 日以降にエクスポートされていることが条件です。この日付より前にエクスポートされているモデルについては、Watson Knowledge Studio から再度エクスポートする必要があります。モデルのエクスポートは、Knowledge Studio の有料プランでのみサポートされています。

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

• IBM Cloud Pak® for Data: Exporting a machine learning model
• IBM Cloud: Deploying a machine learning model to Watson Discovery

Discovery v2 へのモデルのインポートについて詳しくは、Importing Machine Learning models を参照してください。

 

v2 の API を利用できるようにするためのアプリケーションの更新

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

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

現在 Discovery v1 API を使用しているアプリケーションを v2 を使用するようにポーティングするには、2 つのバージョン間での以下のような違いに対応する方法を計画する必要があります。

これらの大まかな変更に加えて、その他に必要になる可能性のある変更を理解するために、各メソッド・レベルで違いをレビューしてください。詳しくは、API version comparison を参照してください。

• v2 では、データがプロジェクトおよびコレクションごとに編成され、環境という概念はありません。例えば、コレクションを取得するためのリクエストを比較してみます。v1 のGet collectionGET {url}/v1/environments/{environment_id}/collections/{collection_id}v2 の Get collectionGET {url}/v2/projects/{project_id}/collections/{collection_id}

 

• v1 では、関連性トレーニングは単一のコレクションで実行されます。一方で v2 では、関連性トレーニングはプロジェクトで実行されます。このプロジェクトには、多数のコレクションが含まれている可能性があります。このような場合では、関連性トレーニングはすべてのコレクションにわたって適用されます。関連性トレーニングの移行について詳しくは、関連性トレーニングの移行を参照してください。
  例えば、関連性トレーニングのステータスを返すリクエストを比較してみます。v1 の Get collectionGET {url}/v1/environments/{environment_id}/collections/{collection_id}v2 の Get projectGET {url}/v2/projects/{project_id}

 

• 2 つのバージョン間で照会の送信方法は類似しています。v2 では、プロジェクト内のすべてのコレクションに対し照会を実行するか、または collection_ids パラメーターを指定して 1 つか複数のコレクションに対象を絞って照会を実行できます。例えば、以下のデータで照会を比較してみます。v1 の Query リクエストPOST {url}/v1/environments/{environment_id}/collections/{collection_id}/query送信するデータ:{
  “query”: “text:IBM”
  }v2 の Query リクエスト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_answers と per_document の両方が true に設定されていると、文書の検索結果と文書ごとのパッセージの検索結果は、答え信頼度に基づいて順序が調整されます。順序の調整の目的は、最初の文書の最初のパッセージの最初の答えを最も関連の高い答えとして表示することです。同様に、find_answers パラメーターが true に設定され、per_document パラメーターが false に設定されていると、パッセージ検索の結果は各文書と各パッセージの信頼度の高い答え順 (降順) に調整されます。

 

アプリケーションによる照会結果の処理方法の更新

v1 と v2 の照会では、照会結果の文書構文に以下のような違いがあるため、アプリケーションで結果の表示方法を修正する必要がある可能性があります。

• v2 では、エンティティー・エンリッチメント・レベルで以下の情報がサポートされていません。
  • センチメント
  • あいまいさの除去 (明確化)

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

 

• v1 の count と relevance の代わりに、v2 には mention (言及) が含まれています。

mention の各エントリーは、文書テキストで言及されているエンティティーに該当します。以下の例では 7 回の言及がありました。1 回の言及につき、信頼度スコアと言及テキストのオフセットが表示されています。ユーザー・インターフェースに表示される結果では、オフセットを使用して文書テキストにある言及を強調表示できます。

• v2 では、照会応答の JSON 構造が若干調整されています。
• 重複排除および類似性の情報は、v2 の照会応答に含まれません。
• v2 では、enriched_text は、オブジェクトではなく配列です。
• Discovery v2 では、v2 のエンティティー・エンリッチメントが使用されています。v2 のエンティティー・タイプの名前は、すべて大文字ではなく、タイトル・ケース (頭文字大文字) で指定されます。エンティティーの名前を指定する照会や集約を使用する場合には、大文字を変更する必要があります。例: PERSON を Person に変更します。
• コレクションに追加される JSON ファイルからのフィールドは、v1 と v2 では変換方法が異なります。これらの結果を処理するアプリケーションがある場合、適宜調整が必要です。

元の JSON フィールドのコンテンツ	v1 での表現	v2 での表現	備考
“field”: null	“field”: null	N/A	v1 ではヌル値を維持。 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 ではシングルトン配列を維持。v2 ではシングルトン配列を値のみに変換、配列の一部として保管しないようにする
“field”:[ 1, 2, 3 ]	“field”:[ 1, 2, 3 ]	“field”:[ 1, 2, 3 ]	違いなし
“field”:[ “v6”, “v7”, “v8” ]	“field”:[ “v6”, “v7”, “v8”]	“field”:[ “v6”, “v7”, “v8”]	違いなし

JSON のソース・フィールドの処理方法

 

データの移行が成功したことの検証

移行が成功したことを検証するには、以下のメトリックを移行前に書き留めておいたメトリックと比較します。

• コレクションの数

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

• コレクションにある文書の数

アップロードされたデータがあるコレクションについては、Query a project API メソッドで空の照会を送信してコレクションにある文書の数を確認します。コレクション ID パラメーターを指定して、結果を 1 つのコレクションにある文書に限定するようにします。空の照会はすべての文書を返します。したがって、応答の matching_results の値を確認することで、文書数の合計がわかります。

コレクションごとの文書の数は、v1 の同じコレクションに保管されていた文書の数に近いはずですが、完全に一致しないこともあります。

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

 

ヒント: v1 と v2 のインスタンスで、同じクエリーでも照会の結果は、必ずしも一致しないことを覚えておいてください。

 

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

v1 で Watson Discovery News のデータ・ソースを使用していて、v2 でも同等の機能があるデータ・ソースを作成したい場合、Webz.io News API の使用を検討してください。Webz.io News API を使用することで、JSON 形式でニュース記事を抽出し、JSON ファイルをアップロードして、v2 プロジェクトに News コレクションを作成できます。

Webz.io への必要な API 呼び出し数を判断するために、現在 1 カ月に Watson Discovery News から取得しているニュース文書を判別します。Discovery News の 1 文書は、Webz.io News API で取得する記事 1 件 (JSON オブジェクト) と同等です。1 回の Webz.io News API の呼び出しは、約 100 件のニュース記事を返します。したがって、1 カ月に 50,000 の Discovery News 文書を使用している場合、Webz.io News API では約 500 回の呼び出しを実行する必要があります (50,000/100 = 500)。詳しくは、Webz.io News API を参照してください。

 

原文：IBM Cloud Docs – Migrating to Discovery v2 (https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2)