1、立项原因： 同一自然人的地址在不同业务系统、不同登记渠道中存在多种写法——行政区划缺省、小区别名俗称、楼栋单元门牌格式不一、错别字与繁简混用等，例如"XX区幸福小区3号楼2单元501室"与"幸福花园3-2-501"实为同一地址。地址无法对齐导致人地关系关联漏配、错配严重，"以地找人"只能靠人工模糊检索逐条比对，效率低、准确率差。本项目旨在建设地址归一化能力，将同一人多种不同写法的地址归一为唯一标准地址，解决地址多源异构导致的人地关系无法准确关联的产品问题。
2、行业场景、业务背景： 在社区网格化治理、人口服务管理、应急寻人救援、物流投递、金融风控核验等业务中，普遍存在"以地找人"的刚性需求：给定一个地址，需快速、准确地找到与之关联的全部人员。系统通过地址要素解析（省市区、街路巷、小区、楼栋、单元、户室）、标准地址库匹配、文本相似度计算与聚合归并，把不同来源、不同写法的地址映射到同一标准地址。
1、项目分五个模块：地址清洗、要素解析、区划修正、两级归一、自学习知识库。
2、清洗：数据是10万条广州快递面单地址，混着手机号、人名、"放门口别放快递柜"这种备注，还有错字和繁体字，先把这些噪声去掉。
3、要素解析：用MGeo模型把地址拆成省市区、街道、道路、门牌、小区、楼栋这些字段。区划写错或缺失的自动修，比如"增鸽城区"修回增城区，判断不了的放进疑难池，不乱猜。
4、两级归一：细的一层一行一个地址，栋号铺位全保留；粗的一层管到小区和门牌，"石滩第一城""第一城6幢1座""2栋117铺童装店"这些写法归成同一个位置ID，拿这个ID能查出一个地址下面关联的所有人，也就是以地找人。
5、建库：结果按可靠程度分A+到C四档入库，新地址进来直接查SQLite知识库匹配，不用整个重跑。最终10万条归成5.5万个位置，行政区正确率99.9%，归并正确率92.5%。
1、分工：调研、开发、后期质量修正都是我一个人做的。
2、技术栈：Python、PyTorch、transformers，模型用达摩院MGeo的要素解析和地址对齐两个，另外有cpca、OpenCC、SQLite。流程拆成五个脚本：清洗、模型推理、归一建库、位置级归一、自学习库。
3、性能：官方modelscope的推理接口太慢，把模型权重拿出来自己写了推理代码，在Mac的GPU上一秒能跑五百多条，结果跟官方接口比对过是一致的。
4、难点：归并特别容易出错。快递驿站、连锁店的名字满大街都是，直接拿来当合并依据的话，全市的"兔喜生活"就成同一个地方了，只能建词表排除；同名小区街道对不上的一律不合并；门牌号要多数写法一致才敢用，两种写法各占一半就空着不填，怕填错。
5、迭代：这些规则是对着错误案例一轮轮改出来的，前后大概30轮，每次改完全量重跑验证，最后拿高德和阿里云的接口比过准确率。
评论