07 / 数据

身份解析

匹配记录时应包含明确的审核状态,而非仅凭名称相似就认定为同一身份。

配对详情
利用不确定性防止错误合并: 0.78
record A
record B
mia@northstar.io
mia@northstar.io
Northstar Labs
Northstar
+1 415 555 0192
—
Finance lead
Operator
质量控制可能匹配 · 需审核

配对详情

名称仅为单一信号

当判定结果能解释一致性、冲突及缺失证据时,实体解析的效果最佳。

01

相同或不同

明确身份判定依据,而非仅依赖单一字段。

02

字段一致性

查看哪些字段支持匹配,哪些字段存在冲突。

03

审核状态

对于模棱两可的配对,在人工或政策介入解决之前,保持其分离状态。

配对详情

01

查找候选对象

利用确定性匹配或嵌入(embeddings)技术,构建可管理的候选集。

review当判定结果能解释一致性、冲突及缺失证据时,实体解析的效果最佳。
02

比较字段

综合比对名称、地址、域名、ID 及其他身份验证信息。

review当判定结果能解释一致性、冲突及缺失证据时,实体解析的效果最佳。
03

遵循政策

明确界定哪些证据在您的业务领域内属于强证据、弱证据或排除性证据。

review当判定结果能解释一致性、冲突及缺失证据时,实体解析的效果最佳。
04

避免盲目合并

将低置信度的匹配项分流至审核队列,而非强制得出结果。

review当判定结果能解释一致性、冲突及缺失证据时,实体解析的效果最佳。

比对两条记录

在提高自动化程度之前,先评估错误合并的情况。

错失匹配通常可以补救,但错误的合并却可能导致所有下游记录受损。

比对两条记录
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?" }
  }
}

常见问题

关于身份解析的常见问题

这能取代确定性匹配吗?+

不能。应先使用确定性键值(deterministic keys)和候选集生成;Jev 可协助审核剩余的模糊匹配对。

输出结果必须是二元的吗?+

通常不必。“相同”、“不同”和“需人工审核”的分类为流水线提供了一个更安全的中间状态。

如何防止错误合并?+

定义强有力的判定依据,显式呈现冲突,并对不可逆的合并操作设定更高阈值。