0 / 0
資料の 英語版 に戻る
IBM Match 360 のマッチング・アルゴリズム
最終更新: 2024年11月22日
IBM Match 360 のマッチング・アルゴリズム

IBM Match 360は、マッチング・アルゴリズムを使用して、データ・レコードをマスター・データ・エンティティに解決します。 データ・エンジニアは、データのエンティティー・タイプごとに異なるマッチング・アルゴリズムを定義できます。 その後、マッチング・アルゴリズムは、データを分析してレコードを評価および比較し、一致したレコードを収集してエンティティーに入れることができます。

データに対してマッチングを実行する一般的な理由は 2 つあります。

  • レコード重複排除とエンティティー解決の場合、マッチング・プロセスによってデータが分析され、データ内に重複レコードが存在するかどうかが判別されます。 重複の疑いがあるレコードは、マスター・データ・エンティティーにマージされ、データの単一の信頼できる 360 度ビューが確立されます。
  • 他のタイプのエンティティー関連を作成するために、マッチング・プロセスはデータを分析して、世帯などのさまざまな種類のグループを表すエンティティーにレコードを収集します。

以下のビデオを視聴して、 IBM Match 360 を使用して、カスタマイズしたデータ・モデルのマッチング・アルゴリズムをセットアップする方法を確認してください。

このビデオは、本書の概念とタスクを学習するためのビジュアル・メソッドを提供します。

このトピックでは、

マッチングして複数のタイプのエンティティーを作成

IBM Match 360 マッチング・アルゴリズムは、関連データのエンティティー・タイプによって駆動されます。 データ・モデル内のレコード・タイプごとに複数のエンティティー・タイプを定義できます。 エンティティー・タイプごとに、対応するマッチング・アルゴリズムを構成および調整して、 IBM Match 360 が組織の要件を満たすエンティティーを作成するようにします。

単一のレコードを複数の別個のエンティティーの一部にすることができます。 データ・モデルに複数のエンティティー・タイプが含まれている場合は、同じデータ・セットに対して異なるタイプのマッチングを実行できます。 例えば、企業全体の担当者レコードを含むデータ・セットについて考えてみます。 「担当者」レコード・タイプに「担当者」エンティティー・タイプおよび「世帯」エンティティー・タイプの定義が含まれている場合は、エンティティー解決および重複排除のために「担当者」マッチング・アルゴリズムを実行できます。また、「世帯」マッチング・アルゴリズムを実行して、同じ世帯に属する担当者レコードで構成されるエンティティーを作成できます。

マッチング・プロセス

マッチング・エンジンは、レコードをエンティティーに突き合わせるために、定義されたプロセスを実行します。 マッチング・プロセスには、以下の 3 つの主要なステップがあります。

  1. 標準化。 このステップでは、アルゴリズムによってデータのフォーマットが標準化され、マッチング・エンジンで処理できるようになります。

  2. バッケティング。 アルゴリズムは、データをさまざまなカテゴリーまたは「バケット」にソートして、類似した情報を比較できるようにします。

  3. 比較。 このアルゴリズムは、データを比較して最終比較スコアを決定します。 その後、アルゴリズムは比較スコアを使用して、レコードが一致しているかどうかを判別します。

これらの各ステップは、マッチング・アルゴリズムによって定義および構成されます。

レジリエンス・ルール

IBM Match 360API を使用して、レコード データの変更に対するマッチング アルゴリズムの対応方法を制限する弾力性ルールを構成できます。

弾力性のあるルールがないため、マスター・データ・レコードが追加、更新、または削除されたときに発生する可能性のあるエンティティ・リンクの変更が多数あります：

  • 新記録が追加されれば、それは可能だ：

    • 既存の事業体に参加する。
    • グルーレコードとして機能することにより、2つ以上の既存のエンティティを結合させる。
    • 新しいシングルトン・エンティティを形成する。

  • レコードが更新されれば、それは可能だ：

    • 現在のエンティティに属さなくなり、新しいシングルトン・エンティティになる。
    • 現在所属している団体に所属せず、別の既存の団体に所属する。
    • 現在のエンティティを複数のエンティティに分割する。
    • グルーレコードとして機能することによって、他のエンティティを既存のエンティティに参加させる。
    • エンティティの構成に変更はない。

  • レコードが削除されると、その可能性がある：

    • そのシングルトンエンティティも削除する。
    • 現在のエンティティを分割する。

レジリエンス・ルールを定義することで、データ・エンジニアは、IBM Match 360マッチング・エンジンがこれらの各シナリオにどのように対応するかを設定することができます。 マッチング・エンジンは、設定した弾力性ルールに沿うようにリンク動作を制御する。 弾力性ルールを設定することで、エンティティのマージとスプリットを制限することができます。

resiliency_rulesAPIを使用して弾力性ルールを定義する。 指定されたルールが「FALSE」に設定されている場合、対応するエンティティリンクシナリオは、通常のエンティティリンクの変更を完了しない。

現在の弾力性ルールのセットを取得するには、以下のAPIコマンドを実行する：

GET /mdm/v1/resiliency_rules

弾力性ルールを更新するには、ペイロードを更新して以下のAPIコマンドを実行する：

PUT /mdm/v1/resiliency_rules

{
"link_resiliency_rules": {
  "records": {
     "person": {
        "add": {
           "join_existing_entity": "true/false",
           "merge_entities": "true/false"
        },
        "update": {                                                                                    
            "record_becoming_singleton": "true/false",
            "join_existing_entity": "true/false",
            "original_entity_split": "true/false",
            "merge_entities": "true/false"
        },
        "delete": {
            "singleton_entity_deletion": "true",
            "original_entity_split": "true/false"
        }
     }
   },
   "entities": {
   }
 }
}

マッチング・アルゴリズムのコンポーネント

3 つの主なコンポーネント・タイプで、 IBM Match 360 マッチング・アルゴリズムを定義します。

標準化機能

名前が示すように、標準化機能によってデータの標準化方法が定義されます。 標準化により、マッチング・アルゴリズムは、さまざまな属性の値を、マッチング・エンジンで処理できる標準化された表現に変換できます。

マッチング・アルゴリズムは、複数の標準化機能を使用します。 各標準化機能は、レコード・データにある特定の属性タイプを処理するのに適しています。

標準化機能は JSON オブジェクトによって定義されます。 各標準化機能の JSON オブジェクト定義には、以下の 3 つのエレメントが含まれています。

  • label - この標準化機能を識別するラベル。

  • inputs - inputsリストには、JSON オブジェクトである 1 つのエレメントがあります。 その JSON オブジェクトには、fieldsとattributesの 2 つのエレメントがあります。

    • fields - 標準化に使用するフィールドのリスト。
    • attributes - 標準化に使用する属性のリスト。

  • standardizer_recipe - JSON オブジェクトのリスト。各オブジェクトは、関連付けられた標準化機能の標準化プロセス中に実行される 1 つのステップを表します。 standardizer_recipeリスト内の各オブジェクトは、以下の 4 つの主要なエレメントで構成されます。

    • label - 標準化機能レシピでこのステップを識別するラベル。
    • method - 使用される内部方式。 このエレメントは参照用であり、編集してはいけません。
    • inputs -1 つ上のレベルに定義された inputs リストの単一エレメント。
    • fields - このステップに使用されるフィールドのリスト。 これは通常、1 つ上のレベルの inputs リスト内で定義されているすべてのフィールドのサブセットです。 すべてのステップですべてのinputsフィールドを処理する必要があるわけではありません。
    • set_resource - このステップに使用されるsetタイプのカスタマイズ可能なリソースの名前。
    • map_resource - このステップに使用されるmapタイプのカスタマイズ可能なリソースの名前。

    ステップの動作によっては、対応する JSON オブジェクトで追加の構成エレメントが必要になる場合があります。

事前構成された標準化プログラム

以下の標準化機能は、 IBM Match 360ですぐに使用できます。 事前構成された標準化プログラムもカスタマイズ可能です。

個人名の標準化

この標準化機能は、個人名属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  2. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  3. Tokenizer -定義された区切り文字のリストに基づいて、入力フィールド値を複数のトークンにトークン化します。
  4. Parse token - IBM Match 360 リソースの事前定義値に応じて、入力フィールドの値を解析して異なるトークンにします。 例えば、このレシピを使用して、接尾部、接頭部、および生成値を適切なフィールドに解析することができます。
  5. Length -指定された長さ範囲外のトークンを破棄します。 最小値と最大値は、 IBM Match 360 リソースで定義されます。
  6. Stop token -構成されている匿名入力値を削除します。
  7. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

個人名の標準化では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • person_map_name_alignments -接尾部、接頭部、および生成値を適切なフィールドに解析します。

個人名の標準化では、デフォルトで以下の Set リソースが使用されます。

  • person_set_name_aname -匿名の個人名の値を削除します。
組織名の標準化

この標準化機能は、組織名の属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  2. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  3. Stop character -名前値から不要な入力文字を削除します。
  4. Map token -指定された入力のニックネームまたは代替名を生成し、その情報を別の新しい内部フィールドに保管します。
  5. Tokenizer -定義された区切り文字のリストに基づいて、入力フィールド値を複数のトークンにトークン化します。
  6. Stop token -構成されている匿名入力値を削除します。
  7. Acronym -指定された組織名の頭字語を生成し、別の新規内部フィールドに情報を保管します。 この頭字語の値は、短縮名を処理するために比較時に使用されます。
  8. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

組織名の標準化では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • org_map_name_cnick_name -指定された入力のニックネームまたは代替名を生成します。

組織名の標準化では、デフォルトで以下の Set リソースが使用されます。

  • org_set_name_aname -匿名組織名の値を削除します。
日付標準化

この標準化機能は、日付属性値を標準化するために使用されます。 多くの異なる日付形式をサポートし、以下のレシピが順番に含まれています。

  1. Map character -スラッシュ文字 (/) をダッシュ文字 (-) に変換します。
  2. Date function -さまざまな形式の日付入力を標準化された形式に変換します。
  3. Stop token -構成されている匿名日付値を削除します。
  4. Parse token -入力フィールド値を解析して、特定の正規表現に応じて異なるトークンにします。 例えば、このレシピを使用して、完全な日付入力を日、月、および年のトークンに解析することができます。
  5. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

日付標準化では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_date_separators-スラッシュ (/) またはその他の区切り文字をダッシュ文字 (-) に変換します。
  • map_date_tokens_year_month_day -正規表現に基づいて、入力日付値を内部フィールド ( birth_year、 birth_month 、および birth_day) に解析します。

日付標準化では、デフォルトで以下の Set リソースが使用されます。

  • set_date_date -匿名日付値を削除します。
ジェンダー標準化

この標準化機能は、性別属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  2. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  3. Stop token -構成に従って、匿名入力の性別の値を削除します。
  4. Map token - IBM Match 360 リソースで構成されたとおりに、入力トークン値を同等の値に変換します。
  5. Parse token -処理されたフィールド値を適切な内部フィールドに解析します。
  6. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

性別標準化では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • map_gender_gender -異なる入力性別の値を標準値にマップします。
  • map_gender_tokens_gender -正規表現に基づいて、入力トークン値を内部 gender フィールドに解析します。

性別標準化では、デフォルトで以下の Set リソースが使用されます。

  • set_gender_anon_gender -匿名入力の性別の値を削除します。
住所標準化

この標準化機能は、住所属性値を標準化するために使用されます。 アドレスは、ロケールに応じて、いくつかの異なる形式を持つことができます。 この柔軟性により、アドレスを標準化された形式に変換するための複雑な処理が必要になります。 アドレス標準化機能には、以下のレシピが順に含まれています。

  1. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  2. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  3. Map token - IBM Match 360 リソースで構成されたとおりに、入力トークン値を同等の値に変換します。 例えば、「United States of America」、「United States」、および「US」は、すべて「USA」にマップできます。 このマッピングは、国および都道府県/州のフィールド値に共通です。 さらに、リソースで構成されている区切り文字は、スペース文字にマップされます。
  4. Tokenizer -定義された区切り文字のリストに基づいて、入力フィールド値を複数のトークンにトークン化します。
  5. Stop token -構成されている匿名入力値 (郵便番号など) を削除します。
  6. Keep token -指定されたフィールドの値の定義済みリストのみを許可します。 例えば、標準化中に許可される郵便番号のリストを定義できます。 許可リストにない入力値は削除されます。
  7. Parse token -リソースで構成されている特定の正規表現および事前定義値に応じて、入力フィールド値を適切な内部フィールドに解析します。 このレシピを使用すると、正規表現を使用して特定のトークンを特定の長さに切り捨てることができます。 また、さまざまな英数字パターン・セットを正規表現の形式で定義して、特定のパターンのみを許可することもできます。
  8. Join fields -複数のフィールドを結合して、内部フィールドに割り当てられる新しい結合値を作成します。 例えば、 latitude フィールドと longitude フィールドの値を結合して、 lat_longという名前の新しい内部フィールドを形成することができます。
  9. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

アドレス標準化では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • map_address_country -入力された国の値を同等の値に変換します。
  • map_address_province_state -入力された都道府県/州の値を同等の値に変換します。
  • map_address_delimiter_removal -リソースで構成されている区切り文字をスペース文字にマップします。
  • map_address_addr_tok -入力アドレス・トークン値を同等の値に変換します。
  • map_address_tokens_unit_type_and_number -入力フィールド residence_number を正規表現に基づいて内部フィールド ( unit_type および unit_number) に解析します。
  • map_address_tokens_street_number_name_direction_type -正規表現に基づいて入力フィールド address_line1 を内部フィールド ( street_number、 street_name、 direction、および street_type) に解析します。
  • map_address_tokens_sub_division -正規表現に基づいて入力フィールド address_line2 を内部フィールド sub_divisionに解析します。
  • map_address_tokens_pobox_type_and_number -入力フィールド address_line3 を正規表現に基づいて内部フィールド ( pobox_type および pobox) に解析します。
  • map_address_tokens_city -正規表現に基づいて city フィールドの入力値を解析します。
  • map_address_tokens_province -正規表現に基づいて province_state フィールドの入力値を内部フィールド provinceに解析します。
  • map_address_tokens_postal_code -正規表現に基づいてフィールド zip_postal_code の入力値を内部フィールド postal_codeに解析します。
  • map_address_tokens_country -正規表現に基づいてフィールド country の入力値を解析します。
  • map_address_tokens_latitude -正規表現に基づいてフィールド latitude_degrees の入力値を内部フィールド latitudeに解析します。
  • map_address_tokens_longtitude -正規表現に基づいてフィールド longitude_degrees の入力値を内部フィールド longitudeに解析します。

アドレス標準化では、デフォルトで以下の Set リソースが使用されます。

  • set_address_postal_code - zip_postal_codeの匿名入力値を削除します。
電話標準化

この標準化機能は、電話属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Stop character -電話の値から不要な入力文字を削除します。
  2. Stop token -構成されている匿名電話の値を削除します。
  3. Phone -異なるロケールの異なる形式の入力電話番号を、共通の形式に解析します。 このレシピは、電話番号から市外局番と国別コードを削除するように構成できます。 また、標準化された電話番号に特定の桁数を保持することもできます。
  4. Parse token -リソースで構成されている特定の正規表現に応じて、処理されたフィールド値を適切な内部フィールドに構文解析します。
  5. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

電話標準化機能は、デフォルトで以下のマップ・リソースを使用します。

  • map_phone_tokens_phone -正規表現に基づいて電話の値を内部フィールドに解析します。

電話標準化機能は、デフォルトで以下の Set リソースを使用します。

  • set_character_phone -英数字以外のすべての文字を置き換えます。 正規表現を指定できます。
  • set_phone_anon_phone -匿名電話の値を削除します。
識別標準化

この標準化機能は、識別属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  2. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  3. Stop character -識別値から不要な入力文字を削除します。
  4. Stop token -構成されている匿名入力値を削除します。
  5. Map token - IBM Match 360 リソースで構成されたとおりに、入力トークン値を同等の値に変換します。
  6. Parse token -リソースで構成されている特定の正規表現に応じて、処理されたフィールド値を適切な内部フィールドに構文解析します。
  7. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

ID 標準化機能は、デフォルトで以下のマップ・リソースを使用します。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • map_identifier_equi_identifier -入力トークン値を同等の値に変換します。
  • map_identifier_tokens_identification_number -リソースで構成されている特定の正規表現に応じて、処理されたフィールド値を適切な内部フィールドに構文解析します。

ID 標準化機能は、デフォルトで以下の Set リソースを使用します。

  • set_character_identification_number -識別値から非英数字入力文字を除去します。 正規表現を指定できます。
  • set_identifier_anonymous -匿名識別値を除去します。
E メール標準化機能

この標準化機能は、E メール属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  2. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  3. Stop token -構成されている匿名入力値を削除します。
  4. Map token - IBM Match 360 リソースで構成されたとおりに、入力トークン値を同等の値に変換します。
  5. Parse token -リソースで構成されている特定の正規表現に応じて、処理されたフィールド値を適切な内部フィールドに構文解析します。
  6. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

E メール標準化機能は、デフォルトで以下のマップ・リソースを使用します。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • map_non_phone_equi_non_phone -入力トークン値を同等の値に変換します。
  • map_non_phone_tokens_non_phone -入力フィールド email_id を正規表現に基づいて内部フィールド email_local_part および email_domainに解析します。

E メール標準化機能は、デフォルトで以下の Set リソースを使用します。

  • set_non_phone_anon_non_phone -匿名 E メール値を削除します。
ソーシャル・メディア標準化機能

この標準化機能は、ソーシャル・メディア属性値を標準化するために使用されます。 これには、以下のレシピが順に含まれています。

  1. Map character -UNICODE 入力文字を同等の英字に変換します。 オプションで、 IBM Match 360 リソースでマップを定義します。
  2. Upper case -大文字に相当する値を使用するように入力フィールド値を変換します。
  3. Stop token -構成されている匿名入力値を削除します。
  4. Map token - IBM Match 360 リソースで構成されたとおりに、入力トークン値を同等の値に変換します。
  5. Parse token -リソースで構成されている特定の正規表現に応じて、処理されたフィールド値を適切な内部フィールドに構文解析します。
  6. Pick token -トークンのサブセット (またはすべて) を、バケット化および比較で使用する標準化されたデータとして選択します。

ソーシャル・メディア標準では、デフォルトで以下のマップ・リソースが使用されます。

  • map_character_general -UNICODE 入力文字を同等の英字に変換します。
  • map_non_phone_equi_non_phone -入力トークン値を同等の値に変換します。
  • map_non_phone_tokens_non_phone -正規表現に基づいて、入力フィールド social_media_handle を内部フィールド social_media_id に解析します。

ソーシャル・メディア標準化機能は、デフォルトで以下の Set リソースを使用します。

  • set_non_phone_anon_non_phone -匿名 social_media_id 値を削除します。

エンティティー・タイプ (バケット)

単一のマッチング・アルゴリズム内で、各レコード・タイプは複数のエンティティー・タイプ定義 (entity_type JSON オブジェクト) を持つことができます。 例えば、「担当者」レコード・タイプに対して定義されたアルゴリズムでは、複数のエンティティー・タイプ定義 (「担当者」エンティティー、「世帯」エンティティー、「ロケーション」エンティティーなど) を作成することが必要な場合があります。

各エンティティ―・タイプを使用して、さまざまな方法でレコードのマッチングとリンクを行うことができます。 エンティティー・タイプは、マッチング・プロセス中にレコードをバケットにして比較する方法を定義します。

マッチング・アルゴリズムの各エンティティー・タイプ定義 (entity_type) には、以下の複数の JSON エレメントがあります。

  • clerical_review_threshold - 比較スコアが要検討レビューしきい値より低いレコードは、不一致と見なされます。

  • auto_link_threshold - 比較スコアがオートリンクしきい値より高いレコードは、自動的にマッチングされるほど十分に強い一致であると見なされます。

  • bucket_generators - このセクションには、エンティティー・タイプ用に構成されたバケット・ジェネレーターの定義が含まれます。 バケット・ジェネレーターには、バケットとバケット・グループの 2 つのタイプがあります。

    • バケットは、1 つの属性に対してのみバケット化を行います。 各bucket定義には、次の 4 つのエレメントが含まれます

      • label - バケット・ジェネレーターを識別するラベル。
      • maximum_bucket_size - ラージ・バケットのサイズを定義する値。 バケット・サイズがこの値より大きいバケット・ハッシュは、マッチング時に候補の選択対象として考慮されません。
      • inputs - バケットの場合、inputsリストには、JSON オブジェクトである 1 つのエレメントのみが含まれます。 その JSON オブジェクトには、fieldsとattributesの 2 つのエレメントがあります。
        • fields - バッケティングに使用するフィールドのリスト。
        • attributes - バッケティングに使用する属性のリスト。
      • bucket_recipe -バケット・レシピ・リストは、バケット・ジェネレーターがバケット・プロセス中に完了するステップを定義します。 各bucket_recipeリストには、いくつかのサブエレメントがあります。
        • label - バケット・レシピ・エレメントを識別するラベル。
        • method - 使用される内部方式。 このエレメントは参照用であり、編集してはいけません。
        • inputs -1 つ上のレベルに定義された inputs リストの単一エレメント。
        • fields - このバケット用に使用されるフィールドのリスト。 これは通常、1 つ上のレベルの inputs リスト内で定義されているすべてのフィールドのサブセットです。
        • min_tokens - レシピがバケット・ハッシュを形成するときに使用するトークンの最小数。
        • max_tokens - レシピがバケット・ハッシュを形成するときに一緒に使用するトークンの最大数。
        • count - バケット・ジェネレーターから生成される単一レコードに対するバケット・ハッシュの数の制限。 レコードによって多数のバケット・ハッシュが生成される場合、このエレメントによって設定されたハッシュの数のみが取得されます。
        • bucket_group - バケット・ハッシュを生成するバケット・グループのシーケンス番号。 中間ステップまたはレシピには、シーケンス番号は割り当てられません。
        • order - 複数のトークンが結合されてバケット・ハッシュを形成する場合に、トークンを辞書式順序でソートするかどうかを指定します。
        • maximum_bucket_size - ラージ・バケットのサイズを定義する値。 このエレメントは、バケット・ジェネレーター・レベルで定義されたエレメントと同じです。また、バケット・レシピ・レベルで定義されたエレメントを使用すると、大きな個々のバケットをより細かく制御できます。

    • バケット・グループには、複数の属性のバケッティングが関係します。 各bucket_group定義には、次の 5 つのエレメントが含まれます

      • label - バケット・ジェネレーターを識別するラベル。
      • maximum_bucket_size - ラージ・バケットのサイズを定義する値。 バケット・サイズがこの値より大きいバケット・ハッシュは、マッチング時に候補の選択対象として考慮されません。
      • inputs - バケット・グループの場合、inputsリストには複数の JSON オブジェクト・エレメントがあります。 JSON オブジェクトには、それぞれfieldsとattributesの 2 つのエレメントがあります。
        • fields - バッケティングに使用するフィールドのリスト。
        • attributes - バッケティングに使用する属性のリスト。
      • bucket_recipe -バケット・レシピ・リストは、バケット・ジェネレーターがバケット・プロセス中に完了するステップを定義します。 各bucket_recipeリストには、いくつかのサブエレメントがあります。
        • label - バケット・レシピ・エレメントを識別するラベル。
        • method - 使用される内部方式。 このエレメントは参照用であり、編集してはいけません。
        • inputs -1 つ上のレベルに定義された inputs リストの単一エレメント。
        • fields - このバケット用に使用されるフィールドのリスト。 これは通常、1 つ上のレベルの inputs リスト内で定義されているすべてのフィールドのサブセットです。
        • min_tokens - レシピがバケット・ハッシュを形成するときに使用するトークンの最小数。
        • max_tokens - レシピがバケット・ハッシュを形成するときに一緒に使用するトークンの最大数。
        • count - バケット・ジェネレーターから生成される単一レコードに対するバケット・ハッシュの数の制限。 レコードが多数のバケット・ハッシュを生成する場合、このエレメントによって設定されたハッシュの数のみが取得されます。
        • bucket_group - バケット・ハッシュを生成するバケット・グループのシーケンス番号。 中間ステップまたはレシピには、シーケンス番号は割り当てられません。
        • order - 複数のトークンが結合されてバケット・ハッシュを形成する場合に、トークンを辞書式順序でソートするかどうかを指定します。
        • maximum_bucket_size - ラージ・バケットのサイズを定義する値。 このエレメントは、バケット・ジェネレーター・レベルで定義されたものと同じです。 バケット・レシピ・レベルで定義できるため、個々の大きなバケットをより細かく制御できます。
        • set_resource - バケット・レシピに使用されるsetタイプのリソースの名前。
        • map_resource - バケット・レシピに使用されるmapタイプのリソースの名前。
        • output_fields - このレシピが入力フィールドのバケッティング機能を完了した後に新規フィールドを生成する場合、このエレメントには、生成されるフィールドの名前のリストが含まれます。
      • bucket_group_recipe - バケット・グループ・レシピ・セクションは、通常、複数の属性で構成されるバケットを定義するために使用されます。 bucket_group_recipeリストの各エレメントは、単一のバケット・グループの構成体を定義する JSON オブジェクトです。
        • bucket_group_recipe 内の inputs リストには複数のエレメントがあります。これは、 inputs 配列で定義されている複数の属性を 1 つ上のレベルで参照していることを意味します。
        • fieldsエレメントはリストのリストです。 フィールドのすべての内部リストは、それぞれのattributesリストに関連付けられています。
        • min_tokensおよびmax_tokensリストには複数のエレメントがあり、各エレメントはそれぞれのattributesリストに対応しています。
      注:

      一部のバケット・レシピ定義には、 search_onlyという名前のプロパティーがあります。 デフォルトでは、その値は falseです。 trueに設定した場合、このプロパティーは、バケットまたはバケット・グループが確率的検索シナリオにのみ使用され、エンティティー解決 (マッチング) シナリオには使用されないことを示します。

  • compare_methods - エンティティー・タイプ用に構成された比較メソッドの定義。 各compare_methods JSON オブジェクトは、さまざまなcompareメソッドの定義で構成されます。 マッチング・アルゴリズムは、各compareメソッド定義のスコアを合計して、最終的な比較スコアを取得します。 各compareメソッドの JSON オブジェクトには、以下の 3 つのエレメントが含まれています。

    • label - compareメソッドを識別するラベル。
    • methods - 比較グループを形成するコンパレーターのリスト。 この配列内の各エレメントは、1 つのコンパレーターを表します。これは、1 つのタイプのマッチング属性を対象としています。 マッチング・アルゴリズムは、methodsリスト内のすべてのコンパレーターのスコアの最大値を、この比較グループの最終スコアと見なします。 各コンパレーター定義には、次の 2 つのエレメントが含まれます。
      • inputs - コンパレーターの場合、inputsリストには、JSON オブジェクトである 1 つのエレメントのみが含まれます。 その JSON オブジェクトには、fieldsとattributesの 2 つのエレメントがあります。
        • fields - 比較に使用するフィールドのリスト。
        • attributes - 比較に使用する属性のリスト。
      • compare_recipe - このリストは主に、比較ステップを定義するために使用されます。 通常、この配列には 1 つの JSON エレメントのみがあり、比較を行うための 1 つのステップのみを表します。 このステップには次の 5 つのエレメントがあります。
        • label - 比較ステップを識別するラベル。
        • method - 使用される内部方式。 このエレメントは参照用であり、編集してはいけません。
        • inputs -1 つ上のレベルに定義された inputs リストの単一エレメント。
        • fields - inputs リストで 1 レベル上に定義されているすべてのフィールドのうち、この比較に使用されるフィールド。
        • comparison_resource - この比較ステップに使用されるカスタマイズ可能な比較リソースの名前。
    • weights - コンパレーターによって行われる各比較の結果は、0 から 10 までの数値スコアになります。 この数値は、距離測度または類似度と呼ばれます。 距離が 0 の場合は、比較される値がまったく同じであることを示します。 距離が 10 の場合は、それらがまったく異なることを示します。 11 個の異なる値 (0 から 10) に対応して、コンパレーターごとに 11 個の重みが定義されます。 距離を計算した後、比較方法によって重みリストから対応する重み値が判別され、合計比較スコアが算出されます。 データ・エンジニアは、データ品質、分布、またはその他の要因に基づいて、必要に応じて重みをカスタマイズできます。

  • record_filter -レコード・フィルタリング・エレメントにより、マッチング・エンジンは、エンティティー・タイプに基づいてマッチングするレコードを選択できます。 各レコード・フィルター定義には、1 つのエレメントが含まれます。

    • criteria -特定の条件に基づいて、一致するレコードを包含または除外します。 このエレメントには、キーと値のペアを持つ 1 つの JSON オブジェクトが含まれます。

      criteria JSON オブジェクトのキーは、属性名です。 以下のいずれかにすることができます。

      • record_source システム属性。
      • 単純属性タイプ (文字列) のユーザー定義カスタム属性。

    criteria JSON オブジェクトの値は、1 つのエレメントを含む別の JSON オブジェクトであり、以下のいずれかになります。

    • allowed -ストリング値の配列。 これらの値のいずれかを含むレコードは、マッチング時に考慮されます。
    • disallowed -ストリング値の配列。 これらの値のいずれかを含むレコードは、マッチング時に考慮されません。

  • source_level_thresholds -ソース・レベルのしきい値を使用すると、ソースからソースへのベースでオートリンクおよび事務的なレビューのしきい値を定義できます。 ソース・レベルのしきい値は、デフォルトのグローバルしきい値をオーバーライドします。 各ソース・レベルのしきい値構成には、オプションのソース固有のデフォルトしきい値を持つソースの集合、またはソースごとに異なるしきい値を定義できるソース間のしきい値ペアの集合が含まれます。 詳しくは、「 高度なマッチング・アルゴリズムのチューニング 」トピックの「 ソース固有のマッチングしきい値の構成 」を参照してください。

バケット・リソース

バケット化定義では、デフォルトで以下のマップ・リソースが使用されます。

  • person_map_name_nickname -指定された個人名入力のニックネームまたは代替名を生成します。
  • org_map_name_cnick_name -指定された組織名入力のニックネームまたは代替名を生成します。

バケット定義は、デフォルトで以下の Set リソースを使用します。

  • person_set_name_bkt_anon -匿名の個人名の値を削除します。
  • org_set_name_acname -匿名組織名の値を削除します。

比較関数

比較関数 ( コンパレーターとも呼ばれる) は、マッチング・アルゴリズムのキー・コンポーネントの 1 つです。 比較関数は、マッチング・エンジンによって、マッチング・プロセス中にレコード・データを比較するために使用されます。 基本的に、レコード・マッチングでは、異なるレコードのデータ間で異なるタイプの属性を比較します。

個人ドメイン、組織ドメイン、およびロケーション・ドメインでよく使用される属性タイプの多くについて、 IBM Match 360 マッチング・エンジンには、事前構成された比較方法が含まれています。

IBM Match 360では、比較関数は、 フィーチャー・ベクトルと呼ばれる比較の方法を使用します。 IBM Match 360 には、さまざまな比較機能に使用されるさまざまなカスタマイズ可能なフィーチャー定義があります。 各比較の結果は、指定された 2 つの属性値がどの程度異なるかを示す距離 (ベクトル) の測定値になります。

マッチング・アルゴリズムでは、それぞれの離散距離の値に、その値をどの程度考慮するかを決定する重みが与えられます。 重みは距離と結合して比較スコアを生成します。 マッチング・アルゴリズムは、すべての比較スコアを加算して、レコード間比較全体の最終比較スコアに到達します。

フィーチャーについて

フィーチャーは、比較関数の詳細レベルを表します。 異なるタイプの属性は、異なるタイプの類似性検査を使用します。これは、それらの機能も異なることを意味します。

フィーチャー定義は、各比較関数に使用される内部関数のタイプを指示します。 内部関数の例としては、完全一致突き合わせ、編集距離、ニックネーム、表音等価、または初期一致などがあります。

比較リソース

各比較方法には、その内部比較操作の詳細を含むリソースが含まれています。

デフォルトの比較タイプには、それぞれ独自のリソースがあります。 関連リソースの詳細については、各比較タイプを参照してください。

genericのマッチング・タイプを持つカスタム属性タイプを比較する場合、汎用比較方式には以下のリソースが含まれます。

  • compare_spec_generic -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_compare_spec_genericです。

個人名の比較

個人名属性内の異なるフィールドは、異なる方法で処理されます。 接頭部、接尾部、および生成値などのフィールドについては、正確性または不一致が検査されます。 名、姓、ミドルネームなどのその他のフィールドは、主に以下の機能を使用します。

  • 完全一致突き合わせ
  • ニックネーム・マッチング
  • 編集距離
  • イニシャルの一致
  • 音声によるマッチング
  • トークンの誤配置
  • 追加のトークン
  • 欠損値

個人名の比較方式には、以下のリソースが含まれます。

  • person_compare_spec_name -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_nameです。 例えば、person_person_entity_compare_spec_nameです。

組織名の比較

組織名の場合、ビジネス名全体を含む 1 つのフィールドがタイプとして存在します。 このフィールドは、主に以下の機能を使用して比較されます。

  • 完全一致突き合わせ
  • ニックネーム・マッチング
  • 編集距離
  • イニシャルの一致
  • 音声によるマッチング
  • トークンの誤配置
  • 追加のトークン
  • 欠損値

組織名については、頭字語とニックネームも正確性について比較されます。

組織名比較方式には、以下のリソースが含まれます。

  • org_compare_spec_name -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_nameです。

日付比較

日付の場合、通常、比較する 3 つのフィールド (日、月、年) があります。

year フィールドは、以下の機能を使用して比較されます。

  • 正確さ
  • 編集距離
  • 不一致
  • 欠落

day フィールドと month フィールドは、以下の機能を使用して比較されます。

  • 正確さ
  • 不一致
  • 欠落

また、日付コンパレーターは、日付形式のロケールの違いにより、 day フィールドと month フィールドが入れ替えられたかどうかを検査します。

日付比較方式には、以下のリソースが含まれます。

  • compare_spec_date -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_dateです。

性別比較

性別属性は、以下の機能を使用して比較されます。

  • 正確さ
  • 不一致

性別比較方法には、以下のリソースが含まれます。

  • compare_spec_gender -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_genderです。

アドレスの比較

アドレス属性内の異なるフィールドは、異なる方法で処理されます。

国、市区町村、都道府県/州、サブディビジョンなどのフィールドは、以下の機能を使用して比較されます。

  • 正確さ
  • 同値
  • 編集距離
  • 不一致
  • 欠落

郵便番号フィールドは、以下の機能を使用して比較されます。

  • 正確さ
  • 編集距離
  • 不一致
  • 欠落

ストリート番号、ストリート名、ストリート・タイプ、ユニット番号、および方向などのフィールドは、以下の機能を使用して比較されます。

  • 正確さ
  • 同値
  • イニシャルの一致
  • 編集距離
  • 不一致
  • トークンの誤配置
  • 欠落

アドレス比較方式には、以下のリソースが含まれます。

  • compare_spec_address -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_addressです。

電話の比較

電話番号属性は、以下の機能を使用して比較されます。

  • 完全一致突き合わせ
  • 編集距離
  • 不一致

電話の比較方法には、以下のリソースが含まれます。

  • compare_spec_phone -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_phoneになります。

ID の比較

識別番号属性は、以下の機能を使用して比較されます。

  • 完全一致突き合わせ
  • 編集距離
  • 不一致

ID 比較方式には、以下のリソースが含まれます。

  • compare_spec_identifier -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_identifierです。

E メールの比較

E メール属性は、固有 ID (@ 記号の前) と E メール・ドメイン (@ 記号の後) の 2 つの部分で構成されます。 以下の機能を使用して、ID 部分とドメイン部分の両方が個別に比較されます。

  • 完全一致突き合わせ
  • 編集距離
  • 不一致

2 つの比較の結果は重み付けされた方法で結合され、全体的な比較スコアが生成されます。

E メール比較方式には、以下のリソースが含まれます。

  • compare_spec_email -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_emailです。

ソーシャル・メディアの比較

ソーシャル・メディア・ハンドル属性は、以下の機能を使用して比較されます。

  • 完全一致突き合わせ
  • 編集距離
  • 不一致

ソーシャル・メディア比較方式には、以下のリソースが含まれます。

  • compare_spec_non_phone -生成されたアルゴリズムでは、このリソースの名前の形式は recordType_entityType_ compare_spec_non_phoneです。

編集距離

IBM Match 360 マッチング・エンジンは、さまざまな属性の比較およびマッチング時に、内部関数の 1 つとして 編集距離を計算します。 編集距離は、2 つのストリングが互いにどの程度異なるかを測定したものです。 これは、一方のストリングを他方のストリングに変換するために必要な変更の数をカウントすることによって計算されます。

さまざまなストリング操作のセットを使用して編集距離を定義するには、さまざまな方法があります。 デフォルトでは、 IBM Match 360 は、文献に公開されている標準の編集距離機能を使用します。 代わりに、特殊な IBM Match 360 編集距離関数を使用することもできます。

  • 標準編集距離関数を使用すると、マッチング・エンジンのパフォーマンスが向上します。 このため、これは「電話」属性タイプを除くすべての属性のデフォルトの比較構成です。

  • 特殊編集距離関数は、ハイパー精度のユース・ケース用に作成されています。 このオプションでは、タイプミスまたは類似した文字 (8 と B、0 と O、5 と S、または 1 と I など) が考慮されます。 類似した文字に基づいて比較される 2 つの値に不一致がある場合、割り当てられる非類似度の測定値は、標準編集距離関数によって割り当てられるものよりも小さくなります。 その結果、これらのタイプの不一致は、特殊な関数によって強力にペナルティーが科されることはありません。

    重要: 特殊な編集距離関数には、いくつかの複雑な計算が含まれます。 その結果、このオプションを選択すると、マッチング・プロセス中のシステム・パフォーマンスに影響を与えます。

編集距離をカスタマイズする API の使用など、マッチング・アルゴリズムのカスタマイズについては、 マッチング・アルゴリズムのカスタマイズと強化を参照してください。

もっと見る

親トピック: マスター・データの管理

生成 AI の検索と回答
これらの回答は、製品資料の内容に基づいて、 watsonx.ai のラージ言語モデルによって生成されます。 詳細