企业官网建设流程全解析

判重这件事做得好不好，先看一个地方：用来比对的维度是怎么配的。同一批记录，维度不同，查出来的结果能差出很远。

在助贷系统里跑线索查重，麻烦很少出在「比不了」，多半出在维度与权重没先说定。下面把常用的三个维度分别摊开，说清各自能认定到什么程度、噪声从哪来，再看阈值与处理链该怎么排。

维度一，手机号

三个维度里，手机号的认定力相对突出。一个号码对应一个主体的概率较高，命中之后基本可以往「同一个人」上靠。

它的噪声来自换号。同一个人换过号码，旧号留在一条记录里、新号在另一条里，按手机号比就是两条互不相干的记录；反过来，号码被回收后再分配给另一个人，也会造成误判。所以它认定力强，但不是无条件强。

实现上，号码要按统一格式入库——去掉空格与分隔符、国内号补全国际前缀，比对之前先归一化。否则同一号码被写成了两种样子，按字符直接比就漏了过去。

维度二，姓名

姓名的特点是命中机会高，认错的概率也高。

常见写法差异就够呛：全名与简称、中间留不留空格、生僻字的不同输入法编码。放宽匹配能多召回，也会多召回一批不相干的人。所以它在维度体系里更适合当一个「加重项」，而不是「决定项」——命中了给它加分，不命中也不因此排除。

姓名还有一个坑在编码上：同一个字的全角与半角、繁体与简体，直接按字符比对会被判成不同的两条。归一化这一步不做，姓名的命中率会明显偏低。

维度三，设备与访问来源

这一类比前两个弱，适合做辅助。

同一台设备或同一个出口地址在短时间内出现多条记录，是一个可以观察的信号，但它说明的是「可能相关」，不是「就是同一个人」。办公场景里共用网络、共用终端是常态，单靠它下结论很容易错。

所以这一类在权重里通常压得低，只在前两个维度给出倾向时作为顺水推舟的一票，不单独触发判定。

权重与阈值怎么配

三个维度不是平行投票，而是分层的。

强维度走「命中即可拦」：手机号一旦比对成功，直接进待确认队列，不再等其他维度。弱维度走「累计计分」：姓名与设备各自命中加一分，累计到设定阈值才提示。两类分开处理，是为了让强信号不必被弱信号的噪声拖住。

阈值不宜定得太低。定低了，每天弹出一堆需要人工确认的条目，几次之后就没有人认真看了；定高了，真正的重复又漏过去。折中的做法是先按上面的分层跑一段时间，看提示量落在哪个区间，再微调。这套权重与阈值不是写死的常量，而是一个可配置项——不同的记录规模、不同的录入习惯，配出来的值本来就不该一样。鲲极在这一处的处理，是把分层规则放进定义，交给使用方按自己的情况去配。

命中之后要走一条处理链

提示只是开头，后面得有一条明确的处理链：命中后是自动合并、先挂起等人看，还是转人工协商归属。

自动合并适用于强维度直中的情形，代价是合并不可逆，所以合并前的两条原记录要保留可回溯的引用。挂起适用于弱维度累计触发的提示，交给熟悉这批记录的人判断。转人工适用于涉及归属争议的情形——这一条比较耗时间，也格外需要把判断依据留痕，否则下一次同样的争议还要从头讲一遍。

不管走哪一条，处理结论都要落到记录上：谁处理的、什么时候、依据是什么。这一步是事后复盘主要的落脚点。

几处与判重相邻的技术设定

顺着上面几条，有三处相关但与判定本身无关的设定，顺带说清。

一是比对用到的字段要脱敏。手机号在展示层面通常做手机号脱敏处理，只在具备相应权限的角色下还原，免得判重界面本身成了一条敏感信息的出口。

二是成批取走记录的口子要单独设管。数据导出权限管控这一层定的是谁能把哪些字段成批取走、范围能铺到多宽——判重跑在系统内部，取数则是另一件事，两者要分开管。相关的取数与变更动作也要进操作日志审计，留下可回溯的一条链路。

三是这套东西装在哪。若装在使用方自己的机器上，也就是独立部署这种方式，比对用的索引与归档可以分目录存放，轮转策略各自设，比混在一处更稳；工单流转这类过程记录则会持续追加，宜与比对索引分开。

先讲清楚的两处

有两处先讲清楚比较好。

一是维度再多也补不了录入本身不规范的问题。号码填错一位、姓名用了别名，比对逻辑再细也照不出来——判定能补的是「同一条信息被录了两次」，补不了「两次录的都不是同一条信息」。

二是跨系统的一致性不在范围内。这里的比对只覆盖本系统内的记录，系统之外的名单对不上，需要业务侧自己另做对照。

维度先定下来，阈值与处理链跟着定，判重这件事才有据可依。这套系统出自鲲极（鲲鹏的鲲），交付时把三个维度与分层规则一并写进说明，不留给使用方去猜。

以上为开发与交付过程中的技术记录，供同行参考。