お客様のデータの処理方法

データ・ソースに接続すると、 Discovery は データ・ソースからの情報を処理して コレクションを作成します。

データ・ソースを処理する目的は、意味のある情報を識別し、コレクションに追加されたときにその情報にタグを付けることです。これにより、後でその情報を見つけて取得することが容易になります。

すべてのデータ・ソースに適用される処理には、以下のステップが含まれます。

  • データ・ソース内の個々の文書を識別する
  • 文書内のフィールドの検索
  • フィールドに索引を付ける

「フィールドの管理」 ページから、索引付けされたフィールドのリストを表示できます。

  1. 「コレクションの管理」 ページに移動し、コレクションを選択します。

    まず、コレクションの処理が完了していることを確認してください。 「アクティビティー」ページに処理状況が表示されます。

  2. 「フィールドの管理」 タブをクリックします。

表示されるフィールドは、データによって異なる場合があります。 ただし、フィールドのサブセットは常にリストされます。 footer や header などの名前を持つこれらのフィールドは、Smart Document Understanding (SDU) ツールから派生したものであり、コレクションに SDU モデルを明示的に適用しない場合でもリストされます。 (SDU 生成フィールドの完全なリストについては、 使用可能なフィールド を参照してください。) 指定されたデータ・タイプのフィールドのみがコレクションの索引に保管されます。

索引に保管される SDU 生成フィールドの 1 つは、 text フィールドです。 通常、 text フィールドには、元の文書のテキストの本文が含まれます。 「改善とカスタマイズ (Improve and customize)」 ページから送信した検索結果で返されるコンテンツのほとんどは、この 1 つのフィールドからのものです。 このフィールドから関連する情報のチャンクのみを解析して返す方法は、プロジェクトによって使用される照会結果構成によって決定されます。 詳しくは、 デフォルトの照会結果のプレビュー を参照してください。

処理が増えると、フィールドが追加されます。 また、プロジェクト・タイプに応じて、より多くの処理が自動的に適用されます。 コレクション内の文書に対してプロセスが実行されると、プロセスに関連付けられた情報を保管するための追加フィールドが追加されます。 例えば、組み込みエンティティー・エンリッチメントがコレクションに適用されると、 enriched_{field_name}.entities で始まる名前のフィールドをコレクション内の文書に追加するプロセスが開始されます。

フィールドの処理方法

ほとんどの非構造化ファイル・タイプでは、ファイルの内容の大部分が text という名前のフィールドに追加されます。 固有のデータ構造を持つファイル・タイプ (JSON ファイルなど) の場合、コンテンツが保管されるフィールドに名前を付けるために、ソース・ファイルからの名前が使用されます。 このタイプのファイルをアップロードする場合は、フィールドにいくつかの命名上の制限が存在することに注意してください。

以下のフィールド名は特別な意味を持ちます。 可能であれば、構造化ソース・ファイルでこれらの名前を使用しないでください。

  • document_id
  • highlight
  • html
  • metadata
  • parent_document_id
  • result_metadata
  • score
  • spans

以下の条件を満たすフィールド名は使用しないでください。 これらの制限された文字を持つフィールド名は照会されません。

  • 文字 _、 +、および - で始まります。 例えば、+extracted-contentです。
  • 文字 .、 ,、 #、 ?、 (、 )、 : 、またはスペースが含まれます。 例えば、 extracted content や new:extracted-content などです。
  • 数値で終了します (例: extracted-content2)。

Discoveryで文書を処理するには、特定のフィールドに対してコレクション内のすべての文書のデータ型が同じでなければなりません。 特定のフィールドのデータ・タイプが文書間で異なる場合、フィールド索引付けプロセスは失敗し、コレクションの 「Activity」 ページの 「Warnings and errors at a glance」 セクションに「Failed to index」エラー・メッセージが表示されます。

HTML フィールド

文書索引の html フィールドには、文書に関する構造情報が保管されます。

  • Smart Document Understanding ツールを使用してコレクションにアノテーションを付けると、文書表現は html フィールドで索引付けされます。
  • Smart Document Understanding ツールを使用して、事前トレーニングされたモデルをコレクションに適用すると、文書表現は html フィールドと text フィールドの両方で索引付けされます。
  • html フィールドにはサイズ制限があります。 詳しくは、 フィールドの制限 を参照してください。

データの拡張に関する注意事項:

  • 文書内の表を理解できるエンリッチメントを適用する場合は、文書に html フィールドが含まれている必要があります。

日付の処理方法

日付は、ファイル・タイプごとに異なる方法で取り込まれます。

非構造化ファイル

非構造化データを含む文書の本文から日付情報をキャプチャーする最良の方法は、自然言語処理モデル・エンリッチを使用することです。 例えば、事前作成されたエンティティー・エンリッチメントは、日付を認識し、 text フィールド (または String データ型のその他の本体フィールド) でそれらの日付にアノテーションを付けます。 エンリッチメントが適用されている文書では、 enriched_{fieldname}.entities.type=Date のラベルが付いたフィールドを検索することで、日付を見つけることができます。

Dates from metadata date fields, such as extracted_metadata.publicationdate, are stored in the index as dates as long as the date format matches one of the supported date data type formats. You can't see nested fields from the Manage fields page. And when you view a search result as JSON, date field values are displayed as string values because the JSON editor shows the date as a string. However, values from date fields behave like dates. You can use greater than (>) or less than (<) operators with such fields in Discovery Query Language queries, for example.

構造化ファイル

インポートする構造ファイル (CSV ファイルや JSON ファイルなど) には、日付データ・タイプとして保管する日付フィールドが含まれている場合があります。 Discovery は、多くの日付形式を認識できます。 ただし、リストにフォーマットを追加する必要がある場合があります。 詳しくは、 日付形式の設定を参照してください。

日付形式の設定

文書に日付情報を含むルート・レベル・フィールドがある場合は、そのフィールドを索引の Date データ・タイプ・フィールドに設定できます。

Discovery は、以下の日付形式を自動的に認識します。

yyyy-MM-dd'T'HH:mm:ssZ
yyyy-MM-dd'T'HH:mm:ssXXX
yyyy-MM-dd'T'HH:mm:ss.SSSZ
yyyy-MM-dd'T'HH:mm:ss.SSSX
yyyy-MM-dd
M/d/yy
yyyyMMdd
yyyy/MM/dd

日付を他の形式で保管する場合は、サポートされる形式のリストにその形式を追加できます。

日付形式を追加するには、以下のステップを実行します。

  1. コレクションの 「フィールドの管理 (Manage fields)」 ページで、 「日付形式 (Date formats)」 フィールドに新しい行として形式を追加します。

    Java SimpleDateFormat クラスでサポートされている日付フォーマットを指定します。

    例えば、レコードに日付の年の値のみが格納されている場合は、サポートされる日付形式のリストに yyyy を追加します。 その後、年の値を含むフィールドのデータ・タイプを *「日付」*に設定して、コレクションを再処理できます。 その結果、日付フィールドに 2019 が出現すると、索引に 2019-01-01T05:00:00Z として保管されます。

    日付形式を追加する場合は、日付に関連付けられたタイム・ゾーンを指定する必要があります。

  2. タイム・ゾーンを指定します。

  3. オプションで、日付ロケールを選択します。

    選択したロケールは、日付タイプのデータ・セット・フィールドの日付を表すストリング値を解析するために使用されます。 例えば、 EEE, MM dd, yyyy というフォーマットを使用すると、 英語（米国）ロケールでは "Wednesday, 07 01, 2020" の文字列値を解析でき、 日本語（日本）ロケールでは "水曜日, 07 01, 2020" の同じ文字列値を解析できます。

  4. 認識されなかった形式の日付を持つ文書を既にインポートしている場合は、文書を再処理します。

Discovery は、テキスト・フィールド内で言及されている日付を索引の 「日付」 フィールドとして保管できません。 ただし、 「エンティティー」 エンリッチメントなどのエンリッチメントを使用して、テキストで言及されている日付を識別できます。

ファイル・タイプの処理方法

文書をアップロードすると、ファイル内のデータが索引付けされます。 さまざまなファイル・タイプが Discoveryによって異なる方法で処理されます。

CSV ファイル

データの追加に関する注意事項:

  • CSV ファイルに定義されている各行は、それぞれが同じ parent_document_id を持つ別個の文書として索引に追加されます。

    子文書は通常、 {parent-ID}_n という構文の文書 ID を持ちます。ここで、 {parent-ID} は追加された元のファイルの文書 ID で、 n は連続番号です。 例えば、5 行の CSV ファイルをアップロードすると、 f5214225c1e03e25190ffcdfad8e84ff_0 から f5214225c1e03e25190ffcdfad8e84ff_4 などの文書 ID を持つ 5 つの文書がコレクションに追加されます。

  • CSV ファイルに対して光学式文字認識 (OCR) 機能を有効にすることはできません。

  • CSV ファイルにヘッダーがある場合、ヘッダー名を使用して、対応する列の内容が保管されるフィールドの名前が指定されます。 Discoveryで特別な意味を持つ名前を使用しないでください。 フィールド名が命名規則に従っていることを確認してください。例えば、スペースも数字も付加されないようにします。 例えば、ファイルを追加する前に、 start date ヘッダーの名前を start_date に、 label1 ヘッダーの名前を label-one に変更できます。 詳しくは、 フィールドの処理方法 を参照してください。

  • CSV ファイル・ヘッダー名に制限された文字が含まれている場合、文書コンバーターは、結果のフィールドを索引に追加するときに、制限された文字をフィールド名から自動的に削除します。

データの拡張に関する注意事項:

  • 事前に作成された、またはユーザーがトレーニングした Smart Document Understanding モデルを CSV ファイルに適用することはできません。

HTMLファイル

Web サイトなどの HTML ファイルを使用して HTML ファイルをアップロードしたりデータ・ソースをクロールしたりすると、 text フィールドとともに html フィールドが生成されます。 詳しくは、 HTML フィールド を参照してください。

JSON ファイル

データの追加に関する注意事項:

  • ソース JSON ファイルからのオブジェクト名は、コンテンツが保管されるフィールドに名前を付けるために使用されます。 Discoveryで特別な意味を持つ名前を使用しないでください。 名前が命名規則に従っていることを確認してください。例えば、スペースも数字も付加されないようにします。 例えば、ファイルを追加する前に、 updated on オブジェクトの名前を updated_on に、 answer2 オブジェクトの名前を answer-two に変更できます。 詳しくは、 フィールドの処理方法 を参照してください。

  • ルート・レベル・フィールドが配列であるが、項目が含まれていない場合、そのフィールドは索引から省略されます。

  • ルート・レベル・フィールドが配列であり、項目が 1 つしか含まれていない場合、配列は 1 つの項目のデータ・タイプとして索引付けされます。 例えば、1 つのストリングを持つストリング配列は、ストリングとして索引付けされます。

  • ネストされたフィールドに配列が含まれている場合は、配列に値が 1 つしかない場合でも、配列として索引付けされます。

  • ルート・レベル・フィールドが配列であり、複数の項目が含まれている場合、データは配列として索引付けされます。

  • Discovery によって生成された JSON をコピーし、それを JSON ファイルとしてアップロードする場合は、まずファイルからシステム生成フィールド document_id、 parent_document_id、 filename、および title を削除してください。

  • JSON ファイルに対して光学式文字認識 (OCR) 機能を有効にすることはできません。

  • ソース文書に document_id という名前のフィールドがある場合、そのフィールドはスキップされ、コレクション内の索引に追加されません。

    JSON ファイルの document_id フィールドの処理方法は、API の 2023-03-31 バージョン更新によって変更されました。 更新前は、製品のユーザー・インターフェースから JSON ファイルをアップロードしたとき、または 「文書の追加」 メソッドで API を使用して JSON ファイルを追加したときに、ファイルの document_id フィールドの値が照会結果で document_id 値として表示されていました。 しかし、別の文書 ID が割り当てられ、 parent_document_id フィールドに保管されました。 割り当てられたドキュメントIDは、 List documentsメソッドを呼び出した際に返されたものであり、 Delete documentsメソッドのリクエストのエンドポイント URL の document_id として使用しなければならないものです。 Update document メソッドを使用して新しい document_id を割り当てた場合、元の ID は引き続き照会結果で返されます。 ただし、割り当てられた ID を使用して文書を削除する必要がありました。 以前の動作に依存するアプリケーションがある場合は、API 呼び出しで 2023-03-31 より前のバージョン番号 ( 2020-08-30 など) を指定できます。

データの拡張に関する注意事項:

  • 事前作成された、またはユーザーがトレーニングした Smart Document Understanding モデルを JSON ファイルに適用することはできません。

  • JSON ファイルからフィールドにエンリッチを適用すると、フィールド・データ・タイプが配列に変換されます。 フィールドは、単一値が含まれている場合でも配列に変換されます。 例えば、"field1": "Discovery" は "field1": ["Discovery"]になります。

  • JSON ファイルのカスタム・フィールドの最初の 50,000 文字のみがエンリッチされます。

  • 品詞 (POS) エンリッチメントが自動的に適用されるプロジェクト・タイプでは、コレクションに追加される最初の JSON ファイル内のファイル・コンテンツの大部分を含むフィールドにエンリッチメントが適用されます。 このフィールドは、以下の規則によって決定されます。

    • text という名前のフィールドがある場合は、POS エンリッチメントがそのフィールドに適用されます。
    • ストリング値が最も長く、特殊値の数が最も多いフィールドが選択されます。
    • 複数のフィールドが前の条件を満たす場合、フィールドの 1 つがランダムに選択されます。

  • ネストされたフィールドにエンリッチメントを適用する場合は、コンテンツ・マイニング・プロジェクトを作成してから、そのエンリッチメントをフィールドに適用する必要があります。 コンテンツ・マイニング以外のプロジェクト・タイプを使用する場合は、他の場所でコンテンツ・マイニング・プロジェクト・タイプを使用して作成したコレクションを再利用できます。 詳しくは、 エンリッチメントの適用 を参照してください。

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

パッセージの派生方法

Discovery は、高度なアルゴリズムを使用して、照会によって返されるすべての文書からテキストの最適なパッセージを判別します。 デフォルトでは、パッセージは文書ごとに返されます。 これらは、各文書照会結果内のセクションとして表示され、パッセージ関連度順に配列されます。

Discovery は、センテンス境界検出を使用して、完全なセンテンスを含むパッセージを選出します。 およそ 200 文字の長さのパッセージを検索してから、その 2 倍の長さのコンテンツのチャンクを調べて、完全なセンテンスを含むパッセージを見つけます。 文境界検出は、サポートされるすべての言語で機能し、言語固有のロジックを使用します。

*「会話型検索」*以外のすべてのプロジェクト・タイプの場合、 「表示のカスタマイズ」>「検索結果」 ページから、検索結果でのパッセージの表示方法を変更できます。 例えば、文書ごとに表示されるパッセージの数と、パッセージごとの最大文字サイズを構成できます。