Jev 实体对齐：同名、别名和规格冲突怎么处理

一步步设计

先定义什么叫同一实体

虚构商品库按“品牌、型号、规格版本”识别商品，而不是只看名字。X2 蓝色耳机与 X2 红色可能是同型号不同 SKU；如果业务要合并到型号层，应保存 SKU 子记录。先决定粒度，再制定标签，不让模型替你选择数据库语义。

先召回候选，控制组合数量

代码用型号、品牌别名和规格初筛，得到有限候选对。中日英文名称可建立人工确认的别名字典，但不能把翻译近似当相等。N 条对 M 条全比较成本随 N×M 增长；记录候选预算和漏匹配的抽检结果。

比较支持字段与冲突字段

官方配方展示整体 Score 与逐字段 Noul 判断。本例比较型号、容量、配件和销售地区；容量不同是实质冲突，标点不同可能只是书写差异。字段缺失要保留 unknown，不能把双方缺失判作一致。

先建议关联，后审核合并

可以建立暂时的匹配建议，保留两个原记录及字段来源。明确不同就不关联；疑似同一但关键字段冲突交人工。高整体分不能自动压过硬规格冲突；实际合并由代码事务完成，并能按来源撤销。

在合并前检查整体约束

逐对认为 A≈B、B≈C 不代表 A、B、C 可合成一个实体。检查每组的型号、唯一标识和规格一致性；冲突组先保留。评测要同时看错合并和漏合并，按语言、别名与版本切片，错误成本可以不同。

完整走查 · 本站虚构样本

观察到什么	如何判断	代码怎么处理
X2 64GB / X2 128GB	同系列但容量冲突	不自动合并
品牌中英别名；型号与规格一致	可能同一，仍需依据	形成可复核匹配建议
两边容量都未提供	缺失不是一致	补数据或人工复核

可复制的设计草案

以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。

# Input contract for an invented pair; not an API result.
{
  "left": {"id": "A", "model": "X2", "capacity_gb": 64},
  "right": {"id": "B", "model": "X2", "capacity_gb": 128},
  "entity_granularity": "model_and_capacity",
  "allowed_outcomes": ["match", "different", "review"]
}

设计我的任务

容易踩的坑

只按名字相似度合并。
将 missing==missing 当字段一致。
把局部匹配关系直接做全组传递合并。

TRY / THINK / COMPARE

先想一想，再看解析

A 与 B 名称一致，但地区版本不同，可以合并价格吗？

展开解析

先确认实体粒度与地区 SKU 关系。不同版本的价格应保留来源和范围；不能因为名称一致就覆盖成一个价格。

交付前检查

实体粒度与唯一字段已定义。
候选规模与漏匹配有抽检。
冲突和缺失单独表示。
合并前有组约束与撤销依据。

常见问题

Score 高就可以直接合并吗？

仍需关键字段规则、权限和可撤销记录。

别名字典怎么维护？

每条别名保留依据和审核记录，避免相似名字连锁污染。

资料与延伸阅读

参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。