Jev + Python 数据关联：用 jlink 做实体匹配

先定义“同一个”，再选择工具

企业母子公司是否视为同一企业？同一软件不同版本是否合并？这些是数据集的业务定义，不应由模型临时猜测。对于唯一编号一致、规范化名称完全相同的记录，先考虑确定性连接；模型更适合留给有语义歧义的候选。

该指南讨论实体匹配与跨表关联，不是让 Jev 生成 SQL 或随意补齐未知的企业关系。只提供名称时，不能要求模型验证当前股权事实。

jlink 的四个阶段

本地 blocking 先选出候选记录对；判定阶段把选定字段和匹配规则交给 Jev；随后程序按阈值、候选间差距和一对一或多对多约束决定关联。最后抽样检查结果。

固定版本实现会对部分规范化后完全相同的字段直接接受，跳过模型调用。没有进入候选集合的真实匹配，后面的 Jev 判定无法找回来。

依据: jlink — judge.py ↗

为一个小数据集设计匹配规则

以下是编辑设计的合成样本，不是模型测试结果。假设任务要求母子公司分开、同一公司仅变更法律形式可匹配；先把这两条写入规则，再检查候选生成是否覆盖这些情况。

Python 工作流应该保留哪些产物？

先在本地估算候选规模，再决定允许发送的字段与调用预算。源码支持记录结果并重新应用关联阈值；调整已有分数的接受策略，与修改语义规则重新判定，是两种不同操作。

• 保存左、右表的稳定 ID，以及清洗前后的字段映射。
• 记录 blocking 配置、匹配定义、实际模型标识和每对候选的结果来源。
• 保留精确匹配、模型判定、失败或未判定状态，避免把缺失分数默认为非匹配。
• 保存 scores 与 settings；改阈值时复用合适的已有分数，改规则或输入时重新核对缓存边界。

依据: jlink — linker.py ↗

怎样避免“高准确率、低召回率”的误读？

分别检查候选生成和最终关联。只审核被提交给模型的记录对，无法看到 blocking 漏掉的匹配。先用一小份人工确定的真实关联，确认正确对象有没有进入候选，再审查已判定分数区间。

用不同阈值比较误合并、漏匹配和人工复核工作量。还应抽查同分或接近分数的竞争候选；最高分并不自动意味着一对一分配中的正确对象。概率值需按数据集检验，不能直接当作已校准的正确率。

常见问题

能在本地离线完成吗？候选生成和部分精确匹配是本地步骤，真实 Jev 判定会把 on 中选定字段发给外部服务。先确认这些字段可用于该服务。

更改阈值一定要重新调用 Jev 吗？只重新筛选已保存分数通常不需要；改变输入、实体定义或模型则需要重新评估。

本文不复用作者速度、费用或 F1 作为本站结论。本站已核对实现，未运行模型或基准数据集。

依据: jlink — README.md ↗

接着看这些项目

继续阅读