做咨询十一年，客户档案清理是我进场后最常接的活。几乎每家企业的客户表里都埋着重复档案：同一个客户以两三种写法各占一行，销售各自维护自己的版本，月底对账时才发现同一个客户在系统里欠着两笔账。这篇讲一套实战检验过的客户档案去重方案，重点讲相似度匹配怎么做。结论先行：客户去重的难点不是查出一模一样的重复，而是识别形不相同实为同一人的模糊重复——靠精确匹配只能抓三成，剩下七成要靠相似度算法加人工确认的组合拳。
一、一家贸易公司的重复档案普查
1.1 触目惊心的普查结果
去年服务的一家建材贸易公司，客户表八千二百行，进场普查后确认重复一千四百多行，重复率一成七。最夸张的一个客户，五家分公司各自建过档，加上历史录入错字，系统里有九个版本：全称、简称、加括号的、错字的、少行政区的，应有尽有。后果实打实：应收账款按客户汇总的数字和业务员的口径对不上，信用额度被重复档案绕开——单客户限额五十万，五个档案每个挂四十万，实际敞口两百万。
1.2 重复是怎么长出来的
重复档案的成因归纳下来四种：录入不规范——同一个客户有人录全称有人录简称，系统不拦；销售割据——各业务员维护自己的客户池，建档不查重；历史迁移——换系统时旧数据多次导入，一批客户翻倍；录入手误——错字、多空格、全半角混乱。四种成因指向同一个结论：指望源头一次录对是不现实的，去重必须是常备机制而不是一次性运动。
1.3 治理目标分层
方案目标分两层：存量清洗，把一千四百行重复归并成唯一主档，业务数据全部挂到主档；增量防控，建档环节加查重拦截，新重复进不来。两层的关系是先清后防——存量不清，查重逻辑没法标定；只清不防，半年后又是一地鸡毛。
二、相似度匹配的实现
2.1 精确匹配先行：只抓三成
头一轮先做便宜的精确匹配：全半角归一、去空格、统一大小写之后完全相等。这一轮能抓到的重复约占三成——同一家公司被两三个人原样照抄的情况比想象的多。精确匹配零误判，可直接自动合并，先把它吃掉，剩下的硬骨头才值得动用模糊匹配。工程上便宜的先做，永远如此。
2.2 规则相似度：抓最常见变形
第二轮上规则相似度，处理常见变形模式：
SELECT a.id, b.id,
(CASE WHEN a.tax_id = b.tax_id THEN 100 ELSE 0 END
+ CASE WHEN SOUNDEX(a.name) = SOUNDEX(b.name) THEN 40 ELSE 0 END
+ CASE WHEN a.phone = b.phone THEN 30 ELSE 0 END
+ CASE WHEN a.addr_district = b.addr_district THEN 10 ELSE 0 END) AS score
FROM customer a JOIN customer b ON a.id < b.id
WHERE (a.tax_id = b.tax_id)
OR (SOUNDEX(a.name) = SOUNDEX(b.name) AND a.addr_district = b.addr_district)
OR (a.phone = b.phone AND a.phone <> '')
ORDER BY score DESC;
规则设计思路：税号是强标识，税号相同直接判重，一票定音；名称发音相近加同区域，抓错字和简称；联系电话相同加分，抓同人建档。规则相似度能再抓四成多，但也开始出误判——发音相近的两家公司确实存在。所以这一轮的结果标为疑似，进人工确认队列。
2.3 编辑距离：兜住拼写变形
第三轮用编辑距离算法扫尾：两个客户名的编辑距离除以长度，比值小于阈值判定疑似。这轮专抓规则漏掉的拼写变形，比如差一个字、调换两个字的位置。编辑距离的阈值调过三轮：太松，大量无关客户被标疑，人工确认的队列爆仓；太严，漏掉真重复。最终定在比值零点二五，配合区域过滤，疑似队列的量控制在可人工消化的范围。算法的参数没有教科书答案，只有拿自己的数据试出来的答案。
2.4 人工确认的界面设计
疑似队列的人工确认是去重成败的最后一环。界面设计要点：每对疑似档案左右并排，关键字段——名称、税号、电话、地址、创建人——高亮差异；下方带出两边的业务数据摘要：订单数、应收额、最近交易时间，让确认的人一眼看出哪边是活跃主档；操作三个键：合并、跳过、标记非重复。确认界面设计得好，一个人一天能处理四百对；设计得差，看一百对就眼花。工具的效率，一半在算法，一半在让人舒服地干活。
三、合并的学问
3.1 主档怎么选
确认重复后的头一个问题：两个档案合成哪个？主档选择规则定死：优先税号齐全的；其次业务数据多的——订单多的说明这边的编码在业务里用得深；再次创建早的。选主档的原则是业务连续性优先——编码要选系统里引用最多的那个，业务数据往主档迁移，反着迁会让下游引用全部断链。这个原则说来简单，真做的时候每对档案都要按规则跑一遍，不能凭感觉指定。
3.2 从档不能一删了之
从档的处理是外行最容易踩的坑：直接删除，引用它的历史单据瞬间变成孤儿数据。正确做法是归并——从档转为从档状态保留，主从关系入档，所有业务数据重挂主档；对外查询从档编码时，系统引导到主档。半年观察期后无异常，从档归入历史库。那家建材公司八千行档案清理完剩六千八，一千四百从档全部可追溯，审计来查，每个合并动作有确认人、有依据、可还原。
3.3 合并的事务保护
合并不是改个标记，是一串动作：业务数据迁移、编码映射登记、从档状态变更，必须在一个事务里完成，中途失败整体回滚。我们做过保护设计：合并前自动备份两方档案快照，合并出问题可一键还原。一千四百次合并，翻车两次，都是接口超时导致的数据迁移中断，靠事务回滚和快照还原救回。批量操作历史数据，没有事务保护和回滚预案，等于不系安全带上高速。
四、增量的防控
4.1 建档查重拦截
存量清完，防控上线：新建客户时，录入名称或税号即触发实时查重——精确匹配加规则相似度现算，疑似重复弹出对比窗口，操作员必须选择继续新建(填理由)或使用已有档案。拦截上线头一个月，挡下三成新建申请——录入员发现原来早有档案，直接复用。这层拦截的价值不只是防重复，还悄悄改变了建档习惯：大家知道有查重，录入前会先搜一搜。
4.2 查重的体验调优
实时查重起初体验很差：输入一个字查一次，弹出窗口频繁打扰录入。优化后改失焦触发——名称输完离开输入框才查；对比窗口折叠显示前三条，展开看全部。别小看这种细节，查重功能被吐槽到关掉的公司不在少数，防重复的闸门如果挡了录入效率的路，一线会用脚投票让它形同虚设。防线设计的铁律：不能让守规矩的人更累。
五、总结
客户档案去重的完整打法：三步匹配漏斗——精确匹配自动合并，规则相似度加编辑距离产出疑似，人工确认收尾；合并讲规矩——主档按业务连续性选，从档归并保留可追溯，事务保护加快照兜底；增量靠拦截——建档实时查重，疑似弹窗强制决策，体验调优保住防线不被绕开。档案数据是企业数字化的地基，重复档案不清理，上层的信用管控、客户分析全是空中楼阁。去重这个活技术不深，贵在流程严谨——每个判断有依据，每个动作可回滚，每个结果可审计。
常见问题
问:两个业务员都有各自的客户档案,合并后业绩怎么算?
答:业绩归属和档案归并要解耦:档案是客观数据,合并按规则走;业绩归属是管理约定,合并前先把两边的业绩记录打上归属标签,合并后查询按标签分,不按档案分。切忌为了业绩好分而维持重复档案——那是拿数据完整性换管理的懒,业绩怎么分是考核规则的事,档案该合就合。
问:相似度匹配的误判率控制到多少合适?
答:换个角度想:疑似队列宁可多不可漏。误判进疑似队列,代价是人工多看一眼;漏判出队列,重复档案继续潜伏,代价是下次对账再爆。我们的运行数据:疑似队列里四成是真重复,六成人工排除——听起来误判不小,但每对确认只要十秒,总代价可控。把阈值调到零误判,漏掉的重复会以账目对不上的形式加倍奉还。
问:客户名称里有简称和别名,怎么处理最干净?
答:主档只存标准名,别名简称进别名字段,一对多维护。查重时主档名和别名字段一起参与匹配,这样简称建档也能命中已有主档。别名的来源包括:营业执照全称、惯用简称、历史旧名。别名字段是查重准确率的大助推器——贸易公司的客户八成有惯用简称,不建别名表,规则匹配等于缺了一条腿。
问:去重做完,过半年又长出新重复怎么办?
答:说明防控层有漏洞,按三查排:查重拦截是否被绕过——新建时选了强行继续且理由敷衍的,抽样回访;合并是否彻底——业务数据有没有漏迁的尾巴;外部导入是否有旁路——批量导入接口也要过查重,很多新重复是从这个后门进来的。把这三条堵住,再配每季度的例行查重扫描,新重复基本长不起来。去重是持续卫生,不是一次性手术。
