第五章 本体与语义层

5.1 实体解析：把两套会员 ID 变成一份主数据

承前：第二章的本体草图上，"会员"对象旁边插着两面小旗——"新旧双轨 ID"和"标签塞备注"。第三章口径公式里，复购率的 JOIN 显式依赖那张"双轨 ID 映射表"，覆盖率 87% 这个数字反复出现。到现在，这颗雷一直在被"标注"和"绕行"，没有被真正排掉。这一节我们正面拆它：实体解析（Entity Resolution）的完整方法论——从精确匹配、模糊匹配到概率匹配，从匹配置信度阈值到人工审核队列，再到合并后的主数据管理。这是 W5 专题周的第一块硬骨头。

---

5.1.1 为什么"会员数"算不对：同一个问题的技术表达

先把青禾的病灶翻译成技术语言。青禾 2023 年上了新会员系统，老 CRM 没有下线，两套系统并行跑了近两年：

• 老 CRM：约 40 万条会员记录，主键 old_member_id，注册时只留手机号和姓名，大量一人多号；
• 新会员系统：约 66 万条记录，主键 new_member_id，绑定了实体卡和支付账户；
• 两个 ID 之间没有官方映射表。约 30 万会员两边都有记录，但因为手机号录错、一人多卡、换手机号，同一人在两边经常"长得不一样"。

这就是实体解析问题：**判断两条记录是否指向现实世界中的同一个实体，并把它们合并成一条唯一的主记录。**它不是青禾独有的病——这是数据集成领域几十年的经典难题。人口普查局要合并普查数据和抽查数据，医院要合并不同系统的病历，电商要合并 App 注册和门店扫码——凡是有"两套系统记录同一群人"的地方，就有实体解析。

这个问题在 Agent 项目里的权重被急剧放大：北极星指标"90 天会员复购率"的计算链条上，每一个 JOIN 都踩在这套映射上。ID 不通，指标在数学上就是错的——不是偏差，是错。

5.1.2 三级匹配：精确、模糊、概率

匹配策略分三级，强度递增、误杀风险也递增。

**第一级：精确匹配（Deterministic Matching）。**用一个或多个字段完全相等做判断。青禾的第一版规则是"手机号 + 姓名"双字段精确匹配。这一级快、准（基本不会误合并），但召回低：手机号录错一位、姓名多个空格，两条本应匹配的记录就被漏掉。精确匹配跑完，30 万双端会员只匹配上约 17 万——剩下的 13 万不能就当作"不是同一个人"。

**第二级：模糊匹配（Fuzzy Matching）。**容忍字段内的误差：编辑距离处理"王小辉/王小挥"，拼音归一化处理同音字，标准化处理"+86"前缀和分隔符。模糊匹配把召回率拉上来了，但引入了灰色地带：两个"王伟，138xxxx"可能真是两个人。

第三级：概率匹配（Probabilistic Matching）。不再问"相等还是不相等"，而是问"这对记录是同一个人的概率有多大"。这套方法的数学根基是 Fellegi 和 Sunter 1969 年提出的记录链接理论（Record Linkage）：把每对候选记录在各字段上的"一致/不一致"累加成对数似然比，得到一个匹配分数。关键洞察是：字段的区分度不同，权重就不同——"性别相同"几乎不提供信息（全国一半人性别相同），"手机号相同"提供极强的信息。姓氏权重低（王伟满街都是），生僻字姓氏权重高。

工程上还有个绕不开的前置步骤：分块（Blocking）。40 万 × 66 万 = 264 亿对候选，全比一遍不现实。先用便宜的键（手机号前 7 位、姓名拼音首字母、门店+日期桶）把记录分到同"块"里，只在块内做精细比较——把比较对数降几个数量级。

5.1.3 置信度阈值：不是"对/错"，是"自动/人工"

概率匹配的输出是一个 0-100 的置信度分数。FDE 要做的核心决策是：**阈值划在哪里？**这不是技术参数，是风险预算。

青禾项目的匹配置信度分层表（示意）：

置信度区间	处置策略	青禾沙盘实际占比	理由
95-100	自动合并，直接进主数据	61%	手机号+姓名+办卡门店全一致，误合率 <0.1%
85-95	自动合并，标记"机器合并"待抽检	17%	抽检 5%，错误反馈回权重
60-85	进人工审核队列	15%	手机号一致但姓名差异大，或一人多卡场景
40-60	挂起，标记"疑似同人待验证"	5%	等新证据（下次到店消费时补录）
<40	判为不同人	2%	仅弱信号重合

三条设计原则：

• **阈值向"宁可不并"倾斜。**把两个不同的人合并成一条主数据，后果是发错券、算错指标、隐私串号——错误是外溢的。该并没并，后果只是会员数多算一个——错误是内部的。不对称的代价决定不对称的阈值。
• **灰区不是失败区，是流程区。**60-85 区间那 15%（约 4.5 万对）进人工审核队列，不是让运营经理点 4.5 万次鼠标，而是让一线门店在顾客下次到店时顺手核一句"您是不是也办过我们的老卡"。人工审核要嵌进业务动线，而不是变成数据团队的加班。
• **阈值是给客户的决策，不是你替客户拍板。**把这张表投到评审会上，让增长副总裁亲手圈"自动合并的下限划在哪"。他划的线，他认账。

5.1.4 合并之后：主数据管理才刚开始

匹配完成不等于工作结束。两条记录合并成一条，立刻面临幸存者规则（Survivorship Rules）：合并后的每个字段取哪边的值？

• 手机号取新系统的（更新鲜）、姓名取老 CRM 的（录入时人工核过身份证）、积分取两边之和？还是取大？
• 每条规则都要写进主数据管理（MDM）规范：谁产生记录、谁负责维护、字段级优先级、冲突裁决人。
• 每次合并保留审计链：master_id → 两个 source_id → 匹配分数 → 匹配时间 → 依据字段。任何一次误合并都可以回滚，任何一次质疑都可以追查。

这里有个容易被忽视的政治维度：**合并会消灭权力。**老 CRM 的 40 万会员归营销部门"所有"，合并后主数据归谁管？这在青禾吵了一周。最终方案是新成立数据治理小组管 member_master，营销和门店系统都变成主数据的"订阅方"——写入走统一接口，不允许各改各的。实体解析的技术产物（主数据表），最终以组织制度（唯一写入方）的形式存活下来。这是 FDE 反复会遇到的规律：数据问题的最终解药一半在制度里。

5.1.5 沙盘实况：87% 覆盖率是怎么来的

把整个流程在青禾跑一遍，三周的节奏：

**第一周：分块与精确匹配。**按手机号分块跑精确匹配，17 万对自动匹配。同时做"一人多号"检测：老 CRM 里手机号相同但 old_member_id 不同的记录群——挖出 8000 多个"会员注册了两次"的簇。

**第二周：模糊与概率匹配。**对剩余 13 万未匹配记录，用编辑距离 + 拼音归一 + 消费行为特征（常去门店、客单价区间）构建概率评分。累计匹配再 +1.9 万，4.5 万对进人工队列。

**第三周：审核与落主数据。**人工队列借门店动线消化 +1 万，合并生成 member_master，全量对账：主数据会员数 76.4 万——这就是第三章那个"你算出 76 万"的技术来源。双端应匹配人群的映射覆盖率 87%（13 万应匹配中解决约 11.3 万），剩余 13% 挂起待验证。

覆盖率 87% 而不是 100%，是诚实的上限：剩余 13% 依赖"新证据出现"（顾客下次到店），强行匹配只会制造假数据。指标语义层里所有依赖会员数的指标，都带着"覆盖率 87%"的 caveat——误差条不是缺陷，是工程成熟度的标志。

双轨ID合并 · 产出清单（进SOW交付物附录）
├─ member_master            主数据表（含幸存者规则文档）
├─ id_mapping               old/new → master 映射 + 分数 + 审计链
├─ review_queue             人工审核队列（带消化动线设计）
├─ match_spec.md            分块键、字段权重、阈值表（客户签认版）
└─ coverage_report          覆盖率与误合率抽检报告

5.1.7 常见陷阱与反模式

实体解析工程里，有几类错误反复出现，提前打疫苗：

**陷阱一：拿"全字段一致"当银弹。**有团队把姓名、手机号、地址、注册时间全部设为必匹配字段，精确匹配的召回率跌到 40% 以下，然后得出结论"这数据没法合并"。正确认知是：匹配字段的选择本身就是建模——区分度高的字段（手机号）给高权重做主键级判断，区分度低的（性别、城市）只做加分项，缺失字段不是"不一致"而是"无信息"（Fellegi-Sunter 框架里的 missing 处理）。

**陷阱二：合并完就删源表。**有人为了"彻底统一"，合并后想把老 CRM 的表归档下线。千万别——在青禾，老 CRM 还承载着营销部门的触达功能，主数据是"身份层"不是"功能替代层"。正确姿势是源系统保留、加同步标记（5.4 节的回写阀门），等功能真正迁移完成（彩排+对账通过）再谈下线。实体解析解决"是谁"，不解决"存在哪"。

陷阱三：一次性项目思维。合并做完、映射表交付，团队解散——三个月后新会员继续在新系统注册，老系统也还在收数据，映射表开始腐烂。实体解析是持续过程不是一次性工程：新记录进来要走同样的匹配管道，人工审核队列要有人长期值守，字段权重要随数据质量变化调优。这也是为什么交付物清单里有 match_spec.md——分块键、权重、阈值都要文档化，让客户数据团队接得住、养得起。

**陷阱四：对"一人多号"过度合并。**真有一人注册三号的（家里老人小孩共用），也有同名不同人的。手机号相同+姓名相似就合并，可能把一家人的消费记录并到一个人头上——复购率虚高，触达打扰错误的人。青禾的解法是给"疑似家庭共用号"单独分簇处理，标记 household_flag 而不是强行合并成一个人。合并粒度的选择（个人 vs 家庭）是业务决策，要在口径会上和客户确认，不是算法能自动决定的。

5.1.8 要点总结

• 实体解析 = 判断"两条记录是不是同一个人/物"并合并成主数据；三级策略（精确→模糊→概率）召回递增、灰色地带递增，分块（Blocking）是控制算力成本的前置工程。
• 概率匹配的理论根基是 Fellegi-Sunter 记录链接（1969）：按字段区分度加权，输出置信度分数而不是对错判断。
• 阈值表是风险预算表：向"宁可不并"倾斜（误合并的错误外溢），灰区配人工审核动线而不是加班，阈值由客户签认。
• 合并之后是主数据管理：幸存者规则、审计链、唯一写入方制度。数据问题的最终解药一半在制度里。
• 87% 覆盖率是诚实上限，不是失败；所有依赖映射的指标都应带着覆盖率 caveat 走。

参考资料

• Probabilistic Record Linkage and Deduplication after Indexing, Blocking, and Filtering — J. S. Murray (Duke University) — 系统梳理 Fellegi-Sunter 框架与分块/过滤工程实践的经典讲义。
• A simple two-step procedure using the Fellegi-Sunter model for frequency-based record linkage — PMC — Fellegi-Sunter 模型中字段频率权重的推导与应用，理解"为什么手机号权重远大于性别"。
• Probabilistic Matching Compared to Deterministic Matching for Student Enrollment Records — IEEE — 确定性 vs 概率匹配的实证对比，含三分法（匹配/非匹配/待定）的落地讨论。