引言：模型设计出来以后数据从哪里来
如果"实体 + 位置关系"只是一个漂亮的数据模型，那么它并不能解决实际问题。真正困难的部分很快就会出现：这些实体从哪里来？我们可以很容易定义 Building、Unit、Room、Road、AdministrativeArea，也可以定义 part_of、located_in、addressed_by、contains，但面对"浙江省杭州市西湖区文一西路998号西溪首座5号楼3单元1201室"这样的地址，真正的问题变成了：西溪首座是谁？它在什么位置？5号楼是否真实存在？它属于哪个建筑群？3单元是否对应这个楼？1201室是否可以验证？文一西路998号是否就是这个建筑的地址？如果政府数据、地图数据和用户输入不一致，谁是正确的？如果道路改名，旧地址怎么办？如果建筑拆除，实体 ID 是否还保留？如果两个地址文本其实指向同一栋建筑，如何发现？从"实体 + 位置关系"开始，地址标准化真正进入了地址数据工程与地理实体治理的领域。
地址标准化最容易犯的一个错误，是认为标准化字符串就等于唯一实体。"北京市朝阳区建国路88号"看起来已经非常规范，但它仍然只是字符串。真正需要的是 Building ID 或者 Parcel ID 或者 POI ID，只有建立了稳定的实体标识，才能解决"北京朝阳区建国路88号"、"北京市朝阳区建国路88号"、"朝阳区建国路88号"、"建国路88号"是否指向同一个实体的问题。因此地址标准化的终点应该尽可能是 Entity Resolution，而不是 String Normalization。
一、数据来源天然是多源异构的
现实中的地址数据通常来自很多渠道。政府数据包括行政区划、地名地址、不动产和房屋、门牌、基础地理信息；商业地图包括 POI、道路、建筑、地址和地理编码；邮政和快递包括收寄地址、投递单元、网点和地址编码；企业数据包括注册地址、办公地址和分支机构；互联网数据包括网站、电商、用户输入和社交媒体；现场采集包括测绘、外业调查和设备采集。
这些数据源的目的不同，因此它们对"地址"的理解也不同。政府数据关心行政和治理，地图数据关心空间和导航，快递数据关心可投递性，企业数据关心登记主体，POI 数据关心商业地点。因此不同数据源并不是在描述同一个"地址字段"，而是在从不同业务视角描述现实世界。这正是多源地址治理的基础。现实世界实体往往不是只有一个名称，正式名称、简称、商业名称、历史名称、口语名称可能同时存在。例如"杭州西溪首座"、"西溪首座"、"西溪首座商务中心"、"西溪某某大厦"、"西溪那个写字楼"可能指向同一个实体。因此实体模型中应该区分 canonical_name、aliases、historical_names 和 source_names，而不是简单地用一个 name 字段。地址文本中的变体更多，"3栋"、"3号栋"、"3号楼"、"3幢"、"三栋"、"三号楼"、"3#楼"可能表达相同实体，道路也一样，"建国路"、"建国路东段"、"建国门外大街"、"建国门外大街东段"不能简单认为所有相似字符串都代表同一个实体。
同名实体极其普遍，"人民路"在全国大量城市都有，"和平路"同样如此，甚至"阳光小区"可能在同一个城市出现多次。所以 name 等于"人民路"根本不是实体身份，必须结合行政区、geometry、parent entity、source、entity type、address number 进行消歧。可以抽象成 Entity Candidate 等于 Name 加 Type 加 Spatial Context 加 Parent 加 Geometry 加 Source。
二、实体关系不是静态的，关系比实体更难治理
地址数据最大的复杂性之一来自时间。2020年还叫 XX路，2024年可能改成 XX大道；2023年还存在 5号楼，2025年可能已拆除；行政区划调整导致原来的 A区变成 B区。如果数据库只保存当前状态，那么历史数据就无法正确解释。因此地址实体需要时间维度，Entity 需要 valid_from、valid_to 和 status，关系也可能具有时间，例如 Building located_in District A 在2023年失效，同时产生新的 Building located_in District B 关系。这实际上把地址数据带入了 Temporal GIS 或 Temporal Knowledge Graph 的领域。
建立一个 Building B123 还不够，我们还要确认 B123 part_of C456 是否成立，还要确认 B123 addressed_by Road R789 加 Number 88 是否成立。这意味着数据治理不只是"这个实体存在吗"，还包括"这个关系成立吗"。因此质量控制至少应该覆盖 Entity Validation、Relation Validation、Geometry Validation、Address Validation 和 Temporal Validation。不同数据源对同一实体可能给出不同答案，政府数据记录"建国路88号"，地图数据记录"建国路88号国贸中心"，企业数据记录"北京市朝阳区建国门外大街88号"，用户输入"朝阳建国路88国贸"。这些信息可能全部正确，它们只是在不同场景下采用不同表达。因此治理策略不应该简单地判定 Source A 对 Source B 错，而应该建立 Canonical Entity，将多个数据源共同作为一个实体的 Evidence。
三、必须建立 Provenance 与可信度
一个成熟的地址实体至少应该能够回答：这个实体是谁发现的？这个名字来自哪里？这个坐标来自哪里？这个关系来自哪里？什么时候更新？为什么认为它可信？因此建议为实体和关系增加 source、source_id、source_timestamp、created_at、updated_at、confidence 和 verification_status。
例如一个 Building 实体记录可以包含 entity_id、type、name，以及 source 数组，其中每个 source 包含 provider 和 confidence。这比简单保存 building 等于 5号楼 要有价值得多。如果真正建设一个地址实体库，不应该只依赖一种数据源。比较合理的架构是：第一层是权威数据，如行政区划、官方地名、官方门牌、基础地理信息、房屋建筑等，特点是权威性强但覆盖和开放程度可能有限；第二层是商业数据，如地图 POI、地理编码服务、商业地址库、导航数据，特点是覆盖广、更新快但数据来源和授权模式各不相同；第三层是业务数据，如快递地址、企业地址、电商地址、客户地址，特点是非常接近真实使用场景但噪声和隐私问题也更明显；第四层是众包与开放数据，如 OpenStreetMap、开放地理数据、社区贡献数据，特点是灵活、更新快但质量需要评估。这些数据源最终汇聚到 Entity Fusion，形成 Canonical Entity 和 Relation Graph。
四、数据融合与实体解析是核心难点
数据融合不是简单的 Join。假设 Source A 的 id 是123，名称是"西溪首座5号楼"，Source B 的 id 是 abc，名称是"西溪首座5幢"，不能直接 JOIN name 因为名称不同，也不能只 JOIN 经纬度因为坐标存在误差。真正的 Entity Resolution 往往需要名称相似度、地址相似度、行政区一致性、空间距离、父实体一致性、实体类型一致性、门牌号和数据源可信度，形成综合评分，超过阈值判定为 Match，否则进入 Candidate 或 Review。
地址标准化最终会不可避免地进入 Entity Resolution 或 Entity Linking 的领域。例如"西溪首座5栋"需要从数据库中找到 Building B12345，这和搜索并不完全一样。搜索是在找"最相关的结果"，实体解析是在判断"它是不是同一个现实世界实体"。因此需要考虑 Exact Match、Fuzzy Match、Spatial Match、Hierarchical Match、Contextual Match 和 Cross-source Match 等多种策略。
五、LLM 能解决什么不能解决什么
在今天的地址数据处理中，LLM 会非常有价值，但不能把所有问题交给 LLM。LLM 擅长地址语义解析、实体类型识别、非标准表达理解、简称识别、上下文推断和候选实体排序，例如"朝阳建外88国贸A座"这样的非标准表达，LLM 可以比较好地理解其语义结构。但 LLM 不应该独自决定这个建筑的唯一 ID 是什么、地址坐标是多少、这个建筑是否真的存在、两个建筑是不是同一个。这些问题需要数据库、GIS、权威数据、空间计算、规则和证据的支持。
因此比较合理的架构是 LLM 负责 Semantic Parsing 和 Candidate Generation，然后由 GIS 和 Database 进行 Entity Resolution 和 Validation，最终得到 Canonical Entity，而不是让 LLM 直接生成标准地址字符串。传统数据治理经常强调去重、纠错、标准化，但地址数据有一个特殊性质：现实世界会变化。所以真正的治理应该是发现、创建、验证、关联、更新、版本化、失效、历史保留的持续循环。一个实体不应该因为当前地址变化就消失，例如 Building B123 可以保持不变，2020年位于建国路88号，2024年改为建国大道88号，地址发生变化但实体身份保持连续。这对于历史数据分析、物流、企业数据、人口数据等都非常重要。
六、需要把地址变化和实体变化分开
道路改名时，Road 实体不变，变化的是 Name；建筑更名时，Building 实体不变，变化的是 Name；行政区划调整时，建筑本身不变，变化的是 Building located_in District 这个关系；建筑拆除时，才意味着 Building 的 status 变为 retired。所以实体生命周期、名称生命周期、地址生命周期和空间关系生命周期应该分别治理，这也是"实体 + 位置关系"模型相比地址字符串最大的治理价值之一。
数据粒度不一致也是一个非常困难的问题。不同数据源可能分别提供城市级、道路级、建筑级、房间级的数据，例如用户输入"建国路88号3号楼2单元501室"，地图可能只能定位到 Building，而快递系统可能知道 Room，政府数据可能只提供 Address Point。因此不能简单认为所有系统都必须达到同样粒度，更合理的是记录 parsed_granularity、validated_granularity 和 geocoded_granularity，例如 parsed 等于 ROOM、validated 等于 BUILDING、geocoded 等于 BUILDING，这可以非常真实地表达系统能力。空间精度也是一个独立问题，地址实体并不一定有一个简单的点，Building 可以有 Point、Polygon、Centroid、Entrance，Road 通常更适合 LineString，行政区是 Polygon。因此 Entity 需要 geometry、geometry_type、accuracy 和 coordinate_reference_system，更进一步，一个建筑可以同时存在 Building Polygon、Building Centroid、Entrance Point 和 Address Point，它们不是同一个概念。
一个真正完整的地址实体应该包含 entity_id、type、names、relations、geometry、address、provenance 和 valid_time，这已经不是一个传统意义上的 address table，而是一个 Geographic Entity Record。
七、未来真正值得研究的问题与建设路径
"实体 + 位置关系"真正落地后，还有大量开放问题。全球统一 Core Model 到底应该统一到什么程度？统一太少则各国完全无法互操作，统一太多则强行套用一种地址体系，真正困难的是找到最小但足够的共同语义层。地址实体的唯一 ID 应该由谁维护？政府 ID、地图 ID、企业 ID、OSM ID、内部 ID 如何建立跨体系的 Entity Crosswalk？地址关系如何自动发现？Building part_of Compound 这个关系可能来自 GIS、地址文本、POI、建筑数据或人工调查，如何自动推断并验证是一个很大的研究方向。如何建立时态地址知识图谱？理想状态是2020年 Road A 关联 Building B，2023年 Road A 改名 Road C 仍关联 Building B，2026年 Building B 拆除，这需要 Temporal Entity 加 Temporal Relation 加 Historical Address。如何处理不确定性？真实世界不是所有数据都有确定答案，应该允许 confirmed、inferred、probable、conflicting、unknown 而不是只有 true 或 false。如何建立地址质量评价体系？传统地址质量往往看是否完整规范，未来更应该看 Entity Accuracy、Relation Accuracy、Spatial Accuracy、Temporal Accuracy、Source Reliability 和 Resolution Rate，也就是从文本质量转向地理实体质量。
如果从长期建设角度看，中国最值得建设的不是一个"超级地址字符串库"，而是全国级地址实体与关系基础设施。其核心资产不是"北京市朝阳区建国路88号"这个字符串，而是 Entity ID 加 Entity Type 加 Names 加 Relations 加 Geometry 加 Address 加 Time 加 Provenance，地址字符串只是其中一个视图。
一个比较现实的建设路径是分阶段推进。第一阶段是地址组件标准化，先解决文本到 Province、City、District、Road、Building 的识别；第二阶段是实体标准化，建立 Road ID、Building ID、POI ID、AdministrativeArea ID；第三阶段是实体关联，建立 Building part_of Compound、Building located_in District、Building addressed_by Road 加 Number 的关系；第四阶段是多源融合，将政府、地图、快递、企业、开放数据统一到实体层；第五阶段是时间和版本治理，支持历史地址、历史名称、行政区划变化、道路变化、建筑生命周期；第六阶段是智能化，让 LLM、NER、Entity Linking、Graph Reasoning、Spatial Reasoning 参与自动化治理。这样技术路线会比"直接让大模型生成标准地址"稳健得多。
如果把三篇文章串起来，可以得到一个完整的逻辑：第一篇指出传统地址模型的固定字段和固定层级存在局限，国际体系逐渐采用组件、实体、位置和粒度，由此提出"实体 + 位置关系"；第二篇将"实体 + 位置关系"展开为 Entity 加 Relation 加 Geometry 加 Identity 加 Time 加 Provenance，通过 E-R、空间数据库和图模型形成地址实体模型；第三篇进入工程层面，讨论多源异构数据、Entity Resolution、Relation Validation、Temporal Governance、Provenance 以及仍待解决的开放问题。最终可以把这个研究方向概括为一句话：地址标准化的核心，不是把不同字符串变成同一个字符串，而是把不同语言表达映射到同一个现实世界实体及其位置关系。这也是"实体 + 位置关系"真正具有研究和工程价值的地方。
维智科技（WAYZ）专注构建高质量、标准化的地址数据库，提供地址解析、地址匹配、实体对齐与空间治理等地址服务，帮助企业和开发者把杂乱的非结构化地址文本，稳定对应到唯一地理实体与位置关系，让地址数据变得可用、可信、可维护。