IBM Match 360 REST API を使用した拡張マッチング・アルゴリズムのチューニング
拡張レベルのカスタマイズを実現するには、 IBM Match 360 REST API を使用して、マッチング・アルゴリズムを構成および調整します。
API を使用する場合は、マッチング・ジョブを実行する前に、アルゴリズムを明示的にデプロイする必要があります。
マイクロサービス API 内で、 api-model
メソッドは、指定された属性およびフィールドに基づいてマッチング・アルゴリズムを生成します。POST /mdm/v1/algorithms/{record_type}
メソッドを使用して、マッチング・アルゴリズムをさらにカスタマイズすることができます。これにより、メソッドのペイロードに完全定義マッチング・アルゴリズムを指定できます。PUT /mdm/v1/algorithms/{record_type}
以下に、オートリンクしきい値と、一致する属性およびフィールドのセットを定義する
のサンプル・ペイロードを示します。POST /mdm/v1/algorithms/{record_type}
{"person_entity":{"auto_link_threshold":0.4,"matching_attributes":[{"attributes":["legal_name"]},{"attributes":["primary_residence"]}, {"attributes":["mobile_telephone"]}, {"attributes":["birth_date"]}, {"attributes":["gender"]}, {"attributes":["personal_email"]}]}}
IBM Match 360REST API および対応する SDK の詳細については、認証手順や各メソッドの完全なドキュメントを含め、IBM Match 360API リファレンスを参照してください。
このトピックでは、
多次元比較フィルターの構成
多次元比較フィルターを定義することにより、マッチング・アルゴリズムをさらに細かく調整します。 マルチディメンション・フィルターでは、レコード間で属性を比較し、定義した基準に基づいて一致スコアと重みを上下に調整することができます。 多次元比較フィルターを使用すると、マッチング結果でのフォールス・ポジティブまたはフォールス・ネガティブの一致の数を減らすことができます。
また、多次元比較フィルターを使用して、機械学習ベースのマッチング結果をオーバーライドする独自の決定論的マッチング・ルールを組み込むこともできます。
多次元比較フィルターの生成
マッチング・アルゴリズムで多次元比較フィルターを生成するには、REST API コマンドを使用してマッチング・エンジン構成を更新します。
IBM Match 360 API インターフェースにアクセスして認証します。
以下の例のように、フィルターを定義する
ペイロードを指定します。POST /mdm/v1/algorithms/{record_type}
{"person_entity":{"auto_link_threshold":0.4,"matching_attributes":[{"attributes":["legal_name"], "post_filter_methods": ["false_positive_filter"]},{"attributes":["primary_residence"], "post_filter_methods": ["false_positive_filter"]}, {"attributes":["mobile_telephone"]}, {"attributes":["birth_date"], "post_filter_methods": ["false_positive_filter"]}, {"attributes":["gender"]}, {"attributes":["personal_email"]}]}}
サンプル・ペイロードで、
はカスタム・フィルターの名前です。 これは、フィルター名を含むペイロード内の各属性に適用されます。false_positive_filter
サンプル API ペイロードは、重みとペナルティーがデフォルト (0) である
を含むアルゴリズムを生成します。false_positive_filter
オプションで、組織の要件に合わせて重みとペナルティーをカスタマイズし、
API を使用して更新したアルゴリズムをデプロイすることができます。PUT /mdm/v1/algorithms/{record_type}
フィルターを定義するパラメーターについて
多次元比較フィルターを定義する構成パラメーターについて理解するには、前のセクションで作成した
の例を検討してください。false_positive_filter
API コマンド
を使用して、現在のアルゴリズムを取得します。GET /mdm/v1/algorithms/{record_type}
前のセクションで POST 要求を送信した後、対応するペイロードの例を使用して、アルゴリズム構成の以下のセクションが生成されました。
{ "false_positive_filter": { "filter_recipe": [ { "method": "FilterMethod.MultiDimFilter", "inputs": [1,2,3], "label": "Multi-Dim filter", "weights": [ { "distances": [0,0], "values": [0,0,0,0,0,0] } ] } ], "inputs": [ {"compare_method": "address_compare"}, {"compare_method": "date_compare"}, {"compare_method": "pername_compare"} ], "label": "false_positive_filter" } }
セクションの例には、多次元比較フィルターを定義する標準パラメーターが含まれています。false_positive_filter
-このセクションには、入力ごとに一致する重みを定義するために必要なレシピを提供するパラメーターの配列が含まれています。filter_recipe
inputs
セクションには、このフィルター・レシピが適用される入力の索引が含まれています。 これらは、filter_recipe.inputs
セクションにリストされている比較メソッドの順序に対応する数値です。 例えば、この例では、inputs
は1
メソッドに対応し、address_compare
は2
メソッドに対応し、date_compare
は3
メソッドに対応します。pername_compare
-weights
セクションは、3 次元比較で各入力をどのように重み付けするかを定義するエレメントの配列です。weights
セクションには、入力のweights
定義とdistances
定義が含まれています。 定義されていない入力のデフォルトの重みはvalues
です。0
-このセクションには、マッチング属性の比較メソッドが含まれます。 これらの方法では、inputs
セクションで定義した距離と重みを使用します。filter_recipe
-オプション (非表示)。 このパラメーターは、最大距離を定義します。 デフォルトの最大距離は 5 です。これは、max_distance
パラメーターに 6 つのエレメント (filter_recipe.weights.values
) を含めることができることを意味します。"values":[0,1,2,3,4,5]
カスタム・フィルターの構成
多次元比較フィルターで使用するために既存の比較方法をカスタマイズするには、以下のようにします。
現在のアルゴリズムを取得します。
GET /mdm/v1/algorithms/{record_type}
必要に応じてアルゴリズムを更新します。 例えば、以下を行うことができます。
セクションでエレメントを追加または更新して、リストされた入力の重みをカスタマイズします。weights
パラメーターを追加して、最大距離を定義します。max_distance
- デフォルトのマッチング・ウェイトの代わりにこのフィルターを使用する比較メソッドを入力として追加します。
更新したバージョンでマッチング・アルゴリズムを上書きします。
PUT /mdm/v1/algorithms/{record_type}
例 1: 最大距離を 9 に設定し、次のように入力と距離のさまざまな組み合わせに対してカスタムの重み付けとペナルティーを指定する場合は、以下のサンプル・ペイロードを使用します。 -input1 distance=0, input2 distance=0, input3 distance = [0,1,2,3,5,9. この場合、距離の組み合わせ [0,0, 3] のスコアは 15 になります。
- input1 distance=1、 input2 distance=0、 input3 distance = [0,1,2,3,4,5,6,7,8, 9]。 この場合、距離の組み合わせ [1,0, 9] は、ペナルティー付きスコア -30 を示します。
{ "false_positive_filter": { "filter_recipe": [ { "method": "FilterMethod.MultiDimFilter", "max_distance": 9, "inputs": [1,2,3], "label": "Multi-Dim filter", "weights": [ { "distances": [0,0], "values": [0,-5,-10,-15,-20,-25,-30,-30,-30,-30] }, { "distances": [1,0], "values": [0,-5,-10,-15,-20,-25,-30,-30,-30,-30] } ] } ], "inputs": [ {"compare_method": "address_compare"}, {"compare_method": "date_compare"}, {"compare_method": "pername_compare"} ], "label": "false_positive_filter" } }
例 2: 以下のサンプル・ペイロードのように、独自のカスタマイズされた比較メソッドを追加し、それらが全体的な一致スコアの要因から除外されるように構成することができます。 この場合、カスタム・メソッドは多次元比較フィルターでのみ使用されます。
以下の例では、
フィルターは given_name_only_compare
を overall_score_contribution
に設定します。false
{ "given_name_only_compare": { "methods": [ { "inputs": [ { "attributes": [ "legal_name" ], "fields": [ "given_name" ] } ], "compare_recipe": [ { "comparison_resource": "person_person_entity_person_compare_spec_name", "method": "CompareMethod.NameCompare", "inputs": [ 1 ], "label": "Given Name Only Match", "fields": [ "given_name" ] } ] } ], "overall_score_contribution" : false, "label": "Given Name Only Compare", "weights": [1,0,0,0,0,0,0,0,0,0,0] } }
編集距離関数の切り替え
IBM Match 360 マッチング・エンジンは、さまざまな属性の比較およびマッチング時に、内部関数の 1 つとして編集距離を計算します。 編集距離は、2 つのストリングが互いにどの程度異なるかを測定したものです。 これは、一方のストリングを他方のストリングに変換するために必要な変更の数をカウントすることによって計算されます。
標準編集距離関数または特殊編集距離関数のいずれかを選択できます。 標準編集距離は、マッチング時のパフォーマンスを向上させるためのデフォルト構成です。 編集距離について詳しくは、 IBM Match 360 マッチング・アルゴリズムを参照してください。
アクティブな編集距離機能を変更するには、REST API コマンドを使用してマッチング・エンジン構成を更新します。
IBM Match 360 API インターフェースにアクセスして認証します。
比較関数
の既存の構成 JSON ファイルを取得します。compare_spec_resource
GET /mdm/v1/compare_spec_resources/{resource_name}
ローカル・マシンで、JSON を編集して行
を追加します (デフォルトの編集距離設定に戻す場合は削除します)。"similar_characters_enabled": true
編集した JSON をアップロードして、 IBM Match 360 構成を更新します。
PUT /mdm/v1/compare_spec_resources/{resource_name}
グルー・レコードしきい値の構成
API コマンドを使用して IBM Match 360 マッチング・アルゴリズムを更新することにより、グルー・レコードしきい値を定義できます。
IBM Match 360 がマッチングによって対象を形成すると、一部の低品質レコードがグルー・レコードとして機能する可能性があります。 接着剤のレコードは、接着剤のような他の多くのレコードに留められているため、名前が付けられます。 グルー・レコードには、詳細な属性値がほとんどまたはまったく含まれていないため、多くの異なるレコードと一致するように見えることがあります。 グルー・レコードのマッチング動作により、共通して 1 つの低品質グルー・レコードのみを持つ非常に大きなエンティティーが誤って誤って作成される可能性があります。
簡略化された例として、「John Smith」など、名前以外の属性を持たない低品質レコードについて考えてみます。 このようなレコードは、データ・セット内の他の「John Smith」と容易に一致する可能性があり、一致しない他のレコードが単一の「John Smith」エンティティーに含まれることになります。
データ・エンジニアは、各エンティティー・タイプのマッチング・アルゴリズムでグルー・レコードしきい値を設定することにより、グルー・レコードが原因で、一致率の低い大規模なエンティティーが形成されないようにすることができます。
グルー・レコードしきい値が構成されている場合、 IBM Match 360 は、自己一致スコアを使用してグルー・レコードを識別します。 自己一致スコアは、レコードをそれ自体と比較することによって達成されるマッチング・スコアです。 自己一致スコアが高い場合は、レコードに高い品質のマッチング属性が多数あることを示しています。
IBM Match 360 は、自己一致スコアにグルー・レコードしきい値を加えた値が、エンティティー内のセンター・レコードの自己一致スコアより小さいかどうかを確認することによって、グルー・レコードを識別します。 これより小さい場合、レコードはグルー・レコードと見なされ、エンティティーには含まれません。
グルー・レコードしきい値はオプションであり、デフォルトでは設定されません。 各エンティティー・タイプのグルー・レコードしきい値は、個別に定義する必要があります。
グルー・レコードしきい値を設定するには:
IBM Match 360 API インターフェースにアクセスして認証します。
指定されたレコード・タイプの既存の構成マッチング・アルゴリズム JSON ファイルを取得します。
GET /mdm/v1/algorithms/{record_type}
ローカル・マシンで、JSON を編集して、適切なエンティティー・タイプの下に
パラメーターを追加します。 数値のしきい値を指定してください。 (既存のグルー・レコードしきい値を削除する場合は、このパラメーターを削除します。) 次に例を示します。glue_threshold
locale: {...} encryption: {...} standardizers: {...} entity_types: person_entity: bucket_generators: {...} auto_link_threshold: 65 clerical_review_threshold: 55 glue_threshold: 20 compare_methods: {...}
IBM Match 360 マッチング・アルゴリズムを更新します。
PUT /mdm/v1/algorithms/{record_type}
ソース固有のマッチングしきい値の構成
データ・エンジニアは、さまざまなレコード・ソースに固有のマッチング・アルゴリズム内で、事務的なレビューしきい値およびオートリンクしきい値を定義できます。 これにより、組織は、ソースの信頼性に応じて異なる方法でマッチングを処理できます。
組織によっては、それぞれが異なる属性を使用し、異なる品質レベルを持つ、異なるソースからのレコードが存在する場合があります。 レコード・ソース・レベルのマッチングしきい値を構成することにより、信頼性の低いソースからのデータよりも信頼性の高いソースからのデータを重み付けしたり、一部のソースをマッチングから除外したりすることができます。 マッチングから除外されたソースは、引き続きシステム内の参照ソースとして使用できます。
ソース・レベルのしきい値はオプションであり、デフォルトでは設定されていません。
ソース・レベルのしきい値は、データ・モデル内のエンティティー・タイプごとに個別に定義する必要があります。 注意として、各エンティティー・タイプには独自のマッチング・アルゴリズム定義があります。
ソース・レベルのマッチングしきい値をセットアップするには、以下のようにします。
IBM Match 360 API インターフェースにアクセスし、認証を行います。
構成するエンティティー・タイプの既存のマッチング・アルゴリズム構成ファイル (JSON 形式) を取得します。
GET /v1/algorithms/{record_type}
ローカル・マシンで、JSON を編集して、適切なエンティティー・タイプ (
など) の下にperson_entity
オブジェクトを追加します。 次に例を示します。source_level_thresholds
"person_entity":{ "auto_link_threshold":150, "clerical_review_threshold":120, "source_level_thresholds": { "src0": { "default":[165, 150], “srcxsrc” : { "src0": [null, null], "src1": [160, 130], "src2": [123, 111], "src3": [null, null] } }, "src1": { “srcxsrc” : { "src1": [160, 130], "src2": [123, 111], "src3": [136, 120], "src4": [120, null] } } } }
この例について、およびソース・レベルのしきい値 JSON オブジェクトを定義する方法について詳しくは、 ソース・レベルのしきい値を定義するサンプル JSON オブジェクトを参照してください。
IBM Match 360 マッチング・アルゴリズムを更新します。
PUT /v1/algorithms/{record_type}
ソース・レベルのしきい値について詳しくは、以下のサブセクションを参照してください。
ソース・レベルのしきい値のサンプル JSON オブジェクト
以下の JSON の例では、Person エンティティーのソース・レベルのしきい値を定義するマッチング・アルゴリズム構成ファイルのスニペットを確認できます。
"person_entity":{ "auto_link_threshold":150, "clerical_review_threshold":120, "source_level_thresholds": { "src0": { "default":[165, 150], “srcxsrc” : { "src0": [null, null], "src1": [160, 130], "src2": [123, 111], "src3": [null, null] } }, "src1": { “srcxsrc” : { "src1": [160, 130], "src2": [123, 111], "src3": [136, 120], "src4": [120, null] } } } }
上記の例では、
- デフォルトのグローバル自動リンクしきい値は 150です。
- デフォルトのグローバル事務レビューしきい値は 120です。
- src0、 src1、 src2、 src3、および src4 は、ソース名の例です。
オブジェクト内では、ソースごとのしきい値は、 src0 および src1の 2 つのソースに対して定義されます。source_level_thresholds
一般的なガイダンス:
オブジェクト内の各ソースの下で、source_level_thresholds
パラメーターを使用して、そのソースのデフォルトのグローバル・マッチングしきい値をオプションでオーバーライドすることができます。default
- 各ソースの下で、
プロパティーの下に、ソースからソースへのマッチングしきい値の配列を定義できます。 これらのしきい値は、リストされたソースからのレコードを比較するときに使用されます。srcxsrc
- 配列内で、大括弧で囲まれた値は、
の形式になります。 そのため、[autolink-threshold, clerical-threshold]
は、指定されたソースとソースの比較で、オートリンクしきい値が 136、事務レビューしきい値が 120 であることを示します。[136, 120]
- 両方の値が指定されている場合、オートリンクしきい値は常に、事務的なレビューしきい値よりも高くなければなりません。
- 値が
の場合、そのしきい値は無効になります。null
- ペアの両方の値が
として指定されている場合、2 つのソース間のマッチングとリンクの両方が無効になります。null
- 両方の値が
で、指定された 2 つのソースが同じである場合、ソースは 参照ソース のみと見なされます。 例えば、前述の JSON の例では、null
はsrc0
の参照ソースです。 参照ソースからのレコードのみを持つエンティティーは実行できません。src0
ソース・レベルのしきい値結果の評価
カスタム・マッチング・アルゴリズムでソース・レベルのしきい値を構成した場合は、以下の REST API メソッドを使用してスコアリングの詳細を取得します。
POST /v1/compare/?details=debug&crn={CRN}&entity_type={entity_type}&record_type={record_type}
このメソッドによって返される情報を使用して、結果を評価し、必要に応じてソース・レベルのしきい値構成を微調整することができます。
ソース・レベルのしきい値とペアのレビュー
ペア・レビューによって生成されたチューニング推奨を受け入れると、ソース・レベルのしきい値が上書きされる可能性があります。 お客様の組織が IBM Match 360 ペア・レビュー機能を使用してインテリジェントなチューニング推奨を生成する場合、ソース・レベルのしきい値を定義する前にペア・レビュー・タスクを実行することをお勧めします。
カスタム・マッチング・アルゴリズムでソース・レベルのしきい値を既に定義している場合は、 IBM Match 360 CR (
) を編集して、ソース・レベルのしきい値機能を無効にします。 CR でソース・レベルのしきい値を無効にするには、以下のコマンドを使用します。mdm-cr
oc patch mdm mdm-cr --type=merge -p '{"spec": {"mdm_matching": {"features": {"source_level_thresholds": {"enabled": false}}}}}'
変更を行った後、CR が調整されるまでに 20 分から 30 分かかる場合があります。 更新された構成を適用するには、
サービス・ポッドも再始動する必要があります。 必要に応じて、これらのポッドを手動で再始動する必要があります。mdm-matching
ソース・レベルのしきい値を再度有効にするには、次のコマンドを実行します。
oc patch mdm mdm-cr --type=merge -p '{"spec": {"mdm_matching": {"features": {"source_level_thresholds": {"enabled": true}}}}}'
次のステップ
もっと見る
- IBM Match 360 with Watson マッチング・アルゴリズム
- IBM Match 360で使用可能な API サービス
- マスター・データの探索
- マスター・データの構成
- マスター・データの管理
親トピック: マッチング・アルゴリズムのカスタマイズと強化