交叉验证不是把两张表拼起来
站上好几个来源页都建议把多个来源合并使用：地图数据验证企业是否仍在经营，目录数据补覆盖面，点评数据补口碑维度。这个建议是对的，但合并本身是有成本的，而且做错了比不合更糟。
不合并，你有两份各自口径清楚的数据。合并错了，你有一份看起来统一、实际混着重复和错值的数据，而且再也分不清哪条来自哪里。
所以合并之前必须先定三件事。
一、主键：按什么判定是同一个实体
这是全部问题的起点。企业数据没有天然的唯一标识，只能用组合字段推断：
- 名称加地址：最常用，但两边的写法差异很大。有限公司还是 Co., Ltd.、街道缩写不缩写、有没有门牌号，都会让同一家公司匹配不上。需要先做归一化。
- 电话：准确度高，但要求两边都有电话。没有电话的记录直接失去参与匹配的资格，而这类记录往往正是小微企业。
- 网站域名：适合企业类名单，准确度也高，但同样只覆盖有网站的那部分；另外集团旗下多家公司共用一个域名的情况会造成误合并。
没有哪个规则绝对正确。实际项目里通常是分层匹配：先按最严格的规则合一轮，剩下的再放宽条件，最后留一批人工确认。
二、冲突裁决：同一字段两个值，信谁
匹配上之后，两边同一字段给了不同的值，这是必然会遇到的。
处理方式取决于字段类型：
- 容易过期的字段（地址、电话、营业状态）：信更新更及时的来源。地图类来源通常比目录类新。
- 主观字段（行业分类、标签）：不要裁决，两个都保留并标注来源。不同目录的分类体系本来就不通用，强行选一个会丢信息。
- 数值字段（评分、评论数）：不要合并，分平台保留。跨平台的评分制式不同，平均出来的数字没有含义。
- 明显冲突（两个完全不同的地址）：标记出来，不要自动选。这类记录数量通常不多，但往往正是数据质量问题的信号。
规则必须在合并前定好并写进交付说明。合的时候临时决定，就等于没有规则。
三、来源标记：合并后能不能回溯
每个字段保留它来自哪个来源、哪一页、什么时候采的。
这一项在数据没出问题的时候看起来是多余的，出问题的时候它是唯一能救你的东西。客户质疑某条记录的电话不对，有来源标记就能当场查出这个值来自哪个目录的哪一页、是什么时候采的，据此判断是采错了还是目录本身过期。
我们的做法是：交付合并表的同时，保留各来源的原始记录文件。合并表用于业务使用，原始记录用于回溯。
合并能带来什么，代价是什么
收益主要在字段完整率，不在条数。
两份各一万条的名单合并后，条数可能只有一万三千条——重叠部分被识别成了同一家企业。但如果 A 来源有电话没网站、B 来源正好相反，合并后两个字段的完整率会明显提升。判断合并成效要看完整率，不是看总数变大了没有。
代价有三项：需要归一化处理、需要一轮人工确认边界情况、以及交付物变成两套文件而不是一套。这些都应该体现在报价里。
什么情况下不该合并
- 两个来源的口径根本不同。比如一个统计的是企业法人，另一个统计的是门店网点，合并后的条数既不是企业数也不是门店数。
- 主键字段在两边的覆盖率都很低。匹配不上的比例过高时，合并的结果基本等于两张表叠在一起，只是多了一列来源标记。
- 只是为了让数字更好看。合并不会创造信息，只会重新组织信息。如果目的是让名单看起来更多，那不合并反而更诚实。
评估阶段我们会先用小样本测一下匹配率。匹配率太低的话，我们会建议分开交付，而不是硬合。