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

バージョン間の主な変更点の 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 バージョンの比較 を参照してください。

サービス・プランの選択

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

• プランについて詳しくは、 Discovery の料金プラン を参照してください。
• 成果物の制限について詳しくは、 制限の詳細 を参照してください。

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

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

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

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

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)」 プロジェクト・タイプを作成します。

文書 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 個の文書を取得するには、 count を 100 に設定し、 offset を 0 に設定して、照会を実行依頼します。

   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 個のサブグループに分割できます。

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

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

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

  • 明確化
  • 感情
  • 評判

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

  

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

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

  

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

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

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

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

• コレクションに追加された 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"]	違いはありません。