01
同じか違うか
1 つのフィールドに依存するのではなく、アイデンティティの決定を明示的に行います。
ペア
不確実性を利用して誤ったマージを防止する: 0.78record A
record B
mia@northstar.io
mia@northstar.io
Northstar Labs
Northstar
+1 415 555 0192
—
Finance lead
Operator
品質管理マッチの可能性・レビュー
ペア
名前はただの信号です
エンティティの解決は、その決定によって合意、対立、欠落している証拠が説明できる場合に最も効果的に機能します。
02
現場協定
どのフィールドが一致をサポートし、どのフィールドが競合するかを確認します。
03
レビュー状態
あいまいなペアは、人またはポリシーによって解決されるまで分離しておいてください。
ペア
01
reviewエンティティの解決は、その決定によって合意、対立、欠落している証拠が説明できる場合に最も効果的に機能します。候補者を見つける
決定論的なマッチングまたは埋め込みを使用して、管理可能な候補セットを作成します。
02
reviewエンティティの解決は、その決定によって合意、対立、欠落している証拠が説明できる場合に最も効果的に機能します。フィールドを比較する
名前、アドレス、ドメイン、ID、その他の身元証拠を一緒に渡します。
03
reviewエンティティの解決は、その決定によって合意、対立、欠落している証拠が説明できる場合に最も効果的に機能します。ポリシーの尊重
どの証拠があなたのドメインにとって強い、弱い、または不適格であるかを説明してください。
04
reviewエンティティの解決は、その決定によって合意、対立、欠落している証拠が説明できる場合に最も効果的に機能します。ブラインドマージを避ける
結果を強制するのではなく、信頼性の低い一致をレビュー キューにルーティングします。
2 つのレコードを比較する
自動化を増やす前に誤ったマージを測定する
ミスした試合は多くの場合回復可能です。マージを誤ると、すべてのダウンストリーム レコードが破損する可能性があります。
2 つのレコードを比較する
POST /v1/resolve{
"state": {
"record_a": { "name": "Acme Inc.", "domain": "acme.io", "city": "Oakland" },
"record_b": { "name": "ACME Incorporated", "domain": "acme.com", "city": "Oakland" }
},
"questions": {
"identity": { "type": "choice", "instructions": "How should these records be treated?", "criteria": { "same": "same entity", "different": "different entities", "review": "not enough evidence" } },
"domain_conflict": { "type": "noul", "instructions": "Is the domain conflict material?" }
}
}よくある質問
ID 解決に関する質問
これは決定論的マッチングに代わるものですか?+
いいえ。最初に決定論的なキーと候補生成を使用します。 Jev は、残っているあいまいなペアを確認するのに役立ちます。
出力はバイナリでなければなりませんか?+
通常はそうではありません。同じ、異なる、をレビューすることで、パイプラインがより安全な中間状態になります。
誤ったマージを防ぐにはどうすればよいですか?+
強力な証拠を定義し、競合を可視化したままにし、不可逆的なマージにはより高いしきい値を必要とします。
