SEO / GEO 数据治理与规范标准细则（十）：Entity Identity & Master Data——为什么名称统一了，系统仍然可能把不同对象当成同一个？

系列专题：SEO / GEO 数据治理与规范标准细则

本篇主题：Entity Identity / Master Data Management / Entity Resolution

发布日期：2026年10月29日

核心关键词：Canonical ID、Identity Namespace、Entity Resolution、Master Data Management、Golden Record、Identity Mapping、Entity Relationship、Merge Rollback、Entity-aware RAG

一家工业设备企业已经建立了较为完整的数据治理体系。

工程数据具有正式Source of Truth，字段定义进入Metadata Registry，生产者和消费者之间建立了Data Contract，关键数据可以追溯来源，并通过质量检测才能进入产品知识库。

然而，一次看似普通的数据去重，仍然造成了严重错误。

企业从三个系统获得以下记录：

来源	产品名称	型号	制造商
PLM	Industrial Dryer FW-30	FW-30	Manufacturer A
CRM	FW30 Dryer	FW30	Manufacturer B
WordPress	FW-30 Industrial Drying System	FW-30	Manufacturer A

数据清洗程序首先将FW30、FW-30与其他相似表达统一为标准型号。

随后，系统根据产品名称与型号相似度，将三条记录识别为重复数据，并自动合并。

最终，知识库得到一份看似完整的产品资料：

Product Model:
FW-30

Manufacturer:
Manufacturer A

Rated Power:
82 kW

Operating Capacity:
Manufacturer B specification

Warranty:
Manufacturer A policy

其中每一条属性都可能来自真实文件。技术参数可能没有写错。字段类型可能符合Schema。来源也可以追溯。

但这份合并结果描述的产品，可能根本不存在。

问题不是某条数据不准确，而是：

原本属于不同业务对象的数据，被归到了同一个实体身份之下。

当WordPress使用这份记录生成产品页面，当销售系统根据它制作报价，当RAG系统用它回答客户问题，错误会沿着整个数据分发链持续传播。

这说明，企业即使拥有正确的数据，也可能因为实体身份错误而生成错误知识。

第十篇需要解决的，正是这一层问题。

Entity Identity负责确认数据描述的真实业务对象；Master Data Management负责围绕这个对象，建立一致、可信、可追溯、可修正的主数据体系。

一、为什么名称统一，不代表实体统一？

名称标准化是企业数据清洗的重要工作。

例如：

FW30
FW-30
FW 30
Model FW-30

这些名称可以通过大小写、连字符、空格和固定前缀规则，转换为相同的规范化表达。

但Name Normalization只能回答：

这些文本是否可以采用统一表达？

它不能直接回答：

这些记录是否描述同一个真实业务对象？

原因在于，名称往往不具备全局唯一性。

不同制造商可能采用相同型号。一个产品系列与其具体型号可能使用相近名称。同一个型号可能存在不同配置。同一家公司可能使用多个商业名称。一个客户集团也可能包含多个独立法人。

因此，名称相似性只能提供匹配线索，而不能直接构成身份结论。

企业必须建立一条基础原则：

Name Equality ≠ Entity Identity。

这一原则对于SEO/GEO非常重要。

因为搜索系统、网站结构化数据和AI知识库都需要明确对象。

如果企业把不同对象错误合并，即使最终页面使用统一名称、统一Schema和统一来源链接，也只是在稳定地传播错误的身份关系。

统一错误的身份，只会让错误变得更加一致。

二、前九篇治理数据，第十篇治理数据所描述的对象

此前的系列已经建立多项能力。

治理能力	解决的问题
Source of Truth	哪个来源拥有事实解释权
Data Ownership	谁负责数据及其审批
Source Governance	什么来源可以被使用
Data Provenance	数据如何产生与传播
Data Quality	数据是否符合使用要求
Data Contract	数据交付遵守什么约定
Metadata Governance	字段及业务概念是什么意思
Entity Identity	数据究竟描述哪个业务对象

例如，系统已经确认：

某款设备的额定功率为82 kW。数据来自经过审批的工程规范。适用于标准50Hz配置。拥有有效版本和证据。

但如果这条记录被关联到另一个制造商的同名产品，那么整个事实就被错误使用。

所以，完整的业务事实至少应具备：

Verified Entity
      +
Verified Attribute
      +
Applicable Context
      +
Effective Version
      +
Evidence & Provenance
      ↓
Governed Business Fact

这意味着：

字段质量合格，并不代表实体身份合格。

反过来，实体身份经过确认，也不能证明全部字段都准确。

两种治理能力必须同时存在。

三、首先区分Entity、Record、Identifier与Reference

建立主数据体系以前，需要明确几个基础概念。

Entity（实体）是企业需要独立识别的业务对象，例如一家法人企业、一款产品型号、一种配置、一台具体设备。

Record（记录）是某个系统保存的实体信息，例如PLM产品记录、CRM客户记录或WordPress文章。

Identifier（标识符）是在规定命名空间和使用规则下，用来识别对象的标识。

Reference（引用）是记录或对象之间建立的关联。

例如：

Real-world Product Entity
             ↓
Canonical Entity ID
             ↓
Identity Mapping Registry
      ┌──────┼──────┐
      ↓      ↓      ↓
     PLM    PIM    CMS
   Record Record Record

一个实体可以在多个系统中拥有不同Record。

一个Record也可能引用多个实体。

例如，某个项目案例记录可能同时引用制造商、设备型号、配置、客户组织和实施地点。

因此，企业不能简单采用“一条数据库记录就是一个实体”，也不能采用“两个记录名称相同就是一个实体”。

实体身份必须独立于单个系统的记录形式建立。

四、Entity Granularity：究竟需要识别到哪个层级？

实体身份治理首先需要确定业务粒度。

工业设备的数据体系可能包含：

Manufacturer
      ↓
Product Family
      ↓
Product Model
      ↓
Product Configuration
      ↓
Physical Equipment Unit

这五个层级并不是所有企业必须遵守的固定模型，而是一种常见的业务建模方式。

实体类型	示例	身份范围
Organization	Manufacturer A	组织
ProductFamily	Industrial Dryer Series	产品系列
ProductModel	FW-30	产品型号
ProductConfiguration	FW-30 Standard 50Hz	产品配置
EquipmentAsset	SN-2026-001	具体设备实例

产品型号与产品配置存在关系，但不应简单视为同一个实体。

一台具体设备也不能与其所属型号等同。

例如，一台设备产生维修记录，只能说明该设备实例曾经出现特定情况，不能直接推断所有同型号设备都存在相同问题。

这也是实体粒度对AI知识库的重要影响。

如果模型级信息、配置级信息和设备实例级信息混在一起，AI就可能把局部事实扩展成普遍事实。

因此，Entity Registry必须明确：

Entity Type、Identity Scope与Granularity Rule。

这些规则应该由具有业务Authority的角色批准，而不是完全按照数据库表结构推断。

五、Canonical ID：为什么需要稳定的主身份标识？

假设企业决定将FW-30作为一个正式产品型号管理。

可以为其分配：

Canonical Entity ID:
PRODUCT-MODEL-000184

PLM中使用PLM-2026-1042，PIM中使用PIM-00882，WordPress中使用post_id = 420。

这些标识可以通过Identity Mapping指向同一个Canonical Entity，但没有必要变成相同的字符串。

Canonical ID应当满足：

在指定命名空间内唯一。不因普通名称变化而改变。不重新分配给另一个实体。具有明确实体类型。保留合并、拆分、替代与退役历史。不依赖不稳定的展示名称生成永久身份。

实际系统可以使用UUID、统一主键或独立身份服务。

PRODUCT-MODEL-000184只是本系列的内部示例，并非ISO或Google规定的固定格式。

需要特别注意：

Canonical ID并不等于SEO Canonical URL。

前者用于识别业务实体；后者用于帮助搜索引擎处理重复或高度相似网页的规范化。

两者可以建立关联，但不能直接替代。

六、Identifier Namespace：为什么相同型号可能属于不同产品？

考虑以下两个标识：

{
  "identifier": "FW-30",
  "namespace": "Manufacturer-A-Models",
  "entity_type": "ProductModel"
}

{
  "identifier": "FW-30",
  "namespace": "Manufacturer-B-Models",
  "entity_type": "ProductModel"
}

虽然Identifier Value相同，但Namespace不同。

如果企业将它们直接合并，就忽略了型号标识的分配范围。

因此，身份判断至少应考虑：

Identifier Value + Namespace + Entity Type + Identity Scope。

更完整的Identifier Registry还应记录标识分配者、有效时间、核验状态、来源、是否允许复用、是否存在退役或替换关系。

这种思路同样适用于法人、品牌、供应商和客户组织。

例如，同一个集团可能包含多家独立法人。两个公司可能共享地址、电话或商业名称，但不能据此认定法律身份相同。

所以，企业需要依据不同Entity Type分别建立身份政策。

七、外部身份标识：GTIN、LEI与内部ID的边界

对于部分业务对象，企业可以使用正式的外部标识体系。

例如GS1的GTIN用于识别贸易项目。GLEIF的LEI用于识别法律实体。

但不同标识不能混为一谈。

GTIN不等于产品型号。LEI不等于品牌ID。SKU也不一定等于企业级Canonical Entity ID。

对于工业设备而言，一款产品可能拥有制造商型号，却没有正式分配GTIN。对于企业组织而言，一家公司可能拥有注册名称和内部客户编码，但并未取得LEI。

所以：

不能为了完善数据结构或SEO Schema而编造外部身份标识。

应当在标识真实存在、经过核验并适用于对应对象时使用。

GS1 GTIN Management Standard：

https://ref.gs1.org/standards/gtin-management/

GLEIF Legal Entity Identifier：

https://www.gleif.org/en/organizational-identity/introducing-the-legal-entity-identifier-lei

需要强调，外部标识只解决其规定范围内的身份问题，并不能自动解决全部企业主数据匹配和属性质量问题。

八、Master Data Management究竟管理什么？

Master Data Management，简称MDM。

它不等于把全公司的数据复制到一张主表。

更重要的是围绕关键实体，建立统一的身份、属性、关系、来源、质量、版本和分发管理能力。

例如：

PLM ─────┐
PIM ─────┤
ERP ─────┤
CRM ─────┤
         ↓
  Master Data Governance
         ↓
  Canonical Identity
  Identity Mapping
  Attribute Authority
  Golden Record
  Entity Relationship
  Lifecycle Management
         ↓
CMS / Analytics / RAG / AI

PLM仍然可以负责工程数据。ERP仍然可以负责交易信息。CRM仍然可以管理客户关系。WordPress仍然负责内容发布。

MDM的目标不是消除所有业务系统之间的差异，而是确保：

它们能够围绕相同的真实对象，按照明确规则交换与使用核心数据。

ISO 8000的标准边界

ISO 8000-110:2021规定包含特征数据的主数据交换消息要求，涉及形式语法、语义编码、数据规范符合性和数据字典访问等内容。

ISO 8000-115:2024进一步规定主数据交换中质量标识符的语法、语义及解析要求。

它们为主数据交换提供标准参考，但不能直接等同于完整的企业MDM架构标准。

本文提出的Golden Record、身份判定阈值与操作流程，属于面向SEO/GEO的企业实施设计。

九、Entity Resolution：如何判断两个Record是否属于同一个实体？

Entity Resolution的核心不是让系统尽可能多地合并记录，而是尽可能正确地识别对象。

建议采用如下流程：

Source Records
       ↓
Normalization
       ↓
Candidate Generation
       ↓
Entity Type Validation
       ↓
Namespace & Scope Check
       ↓
Identity Evidence Comparison
       ↓
Hard Constraint Evaluation
       ↓
Match Decision
       ↓
Identity Mapping

Normalization负责统一名称和可比较字段。

Candidate Generation负责找出值得进一步检查的候选。

Identity Evidence Comparison负责核对强身份标识、权威来源和其他证据。

Hard Constraint用于阻止明显不合理的合并。

Match Decision才作出正式判断。

关键原则是：

候选匹配不是已经验证的身份关系。

对于高风险产品、法人组织和客户主体，不能因为名称相似度很高，就直接进入Golden Record合并。

十、Hard Constraint：哪些情况必须阻止自动合并？

一个实体匹配系统可以使用名称、分类、制造商、地址或技术参数作为辅助特征。

但不能让软性相似信号抵消关键身份冲突。

例如，同一产品名称对应不同且经核验的制造商；ProductModel与ProductConfiguration属于不同实体类型；两个独立法人拥有不同的有效法律身份；一台设备实例与一个产品型号被当成同一个对象。

这些情况至少需要拒绝直接合并，或进入正式业务审核。

可采用以下规则：

IF entity_type differs:
    NON_MATCH

ELSE IF verified identity conflict exists:
    BLOCK / REVIEW

ELSE IF authoritative identifier matches:
    VERIFY remaining constraints

ELSE:
    Evaluate supporting evidence
    → MATCH / POSSIBLE_MATCH / NON_MATCH

这里的Hard Constraint需要由业务Owner批准。

不同企业、不同Entity Type不能直接复用同一套约束。

例如，品牌与法人组织可以具有合法关联，但不意味着它们具有相同身份。

同样，产品型号与配置可以高度相关，但不属于同一粒度。

十一、Deterministic Matching与Probabilistic Matching

Deterministic Matching使用明确的匹配规则。

例如，同一已核验的标识发行者命名空间内，两个记录拥有相同且有效的强身份标识，并满足实体类型和业务约束。

Probabilistic Matching则通过多个特征估计记录可能匹配的程度。

例如：规范化名称相似、制造商相同、产品系列相同、技术文件关联、地址或其他商业信息一致。

概率模型可以帮助发现大量潜在重复记录，但不能把未经校准的相似度分数直接解释为真实身份概率。

例如：

match_score = 0.96

并不天然表示“96%的概率是同一个实体”。

只有经过标注数据、统计评估与适当校准，才可以赋予这种概率解释。

本系列建议将结果划分为：

VERIFIED_MATCH：身份已通过适用证据和规则验证。

POSSIBLE_MATCH：存在较强候选关系，但证据不足。

NON_MATCH：不满足同一身份条件。

CONFLICT：存在需要裁决的关键身份矛盾。

对于Critical Entity，POSSIBLE_MATCH不应直接进入自动合并。

十二、为什么False Merge通常比漏合并更难处理？

实体匹配常见两类错误。

False Merge：将不同实体错误合并。

Missed Match：未发现实际上属于同一实体的记录。

漏合并可能造成重复产品页面、客户记录分散、营销统计重复以及数据维护成本增加。

错误合并则可能造成不同产品技术参数混合、法人身份混淆、报价归属错误、认证与证据错误引用、AI知识库跨实体污染。

False Merge更加危险的原因在于，它会把多个真实对象压缩成一个错误对象。

这个错误对象随后可能被其他系统当作可信主数据使用。

因此，企业不能将“去重数量”当作MDM最重要的成果指标。

更应该衡量身份判断是否正确、误合并是否受到控制、错误发生后是否能够撤销、下游是否能够恢复。

十三、Golden Record不等于字段拼接

Golden Record是围绕已确认实体，按照既定规则形成的受治理参考视图。

它不是所有系统字段的简单拼接、最近更新时间的字段集合，也不是出现次数最多的属性组合。

尤其不能将冲突数值简单求平均。

例如：

属性	PLM	PIM	CMS	选择依据
额定功率	82 kW	82 kW	75 kW	已批准工程数据
公开名称	工程名称	批准名称	页面标题	PIM的正式展示名称
制造商	A	A	A	组织主数据
页面URL	无	无	当前URL	CMS发布记录
销售状态	可能未知	Active	Published	对应业务Authority

Golden Record可能需要综合不同权威来源的不同属性。

因此，第三篇建立的Source of Truth应落实到：

Attribute-level Authority。

即每项属性根据具体业务定义、Context、生效时间和责任领域，采用相应权威来源。

没有充分依据时，Golden Record允许处于DISPUTED或INCOMPLETE状态。

不应为了获得完整主记录而强行裁决未知事实。

十四、Attribute Survivorship Policy：怎样选择可信字段？

Survivorship Policy规定多来源数据如何形成最终属性。

示例：

policy_id: SURV-PRODUCT-001
version: "1.0"

entity_type: ProductModel

attributes:
  manufacturer_id:
    authority: OrganizationRegistry
    conflict_action: block

  rated_power_kw:
    authority: PLM
    context_required: true
    select_by: approved_effective_version
    conflict_action: owner_review

  public_name:
    authority: PIM
    select_by: approved_current

  product_url:
    authority: CMS
    select_by: active_publication

该YAML是本系列设计的内部规则模板，并不是可直接部署到全部MDM平台的通用标准文件。

正式执行时，应明确如何查询权威来源、怎样确定生效版本、同一属性的适用Context、是否允许覆盖旧数据、如何保留冲突记录。

尤其应避免：

latest_updated_at直接决定全部字段的取值。

因为技术更新时间并不总等于业务有效时间。

十五、Golden Record必须保留字段级来源与决策证据

假设最终记录为：

{
  "entity_id": "PRODUCT-CONFIG-000184-50HZ",
  "rated_power_kw": 82
}

它虽然简洁，却没有解释82为什么成立。

建议对Critical Attribute保留更完整的信息：

{
  "entity_id": "PRODUCT-CONFIG-000184-50HZ",
  "attribute": "rated_power_kw",
  "value": 82,
  "source_record": "PLM-2026-1042",
  "evidence_id": "ENG-SPEC-V4.2-P18",
  "survivorship_rule": "ENGINEERING_APPROVED",
  "context": "standard_50hz",
  "effective_from": "2026-09-20",
  "decision_status": "APPROVED"
}

这将第六篇Data Provenance与第十篇Golden Record连接起来。

Golden Record需要保存的不只是结果。

更重要的是：

结果来自哪里，经过什么决策，为何被选用，以及在什么条件下有效。

十六、Identity Mapping Registry：跨系统身份怎样登记？

实体识别完成以后，不应该删除来源系统ID。

因为这些ID仍然服务于历史记录、同步、售后、审计和系统迁移。

建议为正式身份映射建立独立记录。

{
  "mapping_id": "IDMAP-0042",
  "canonical_entity_id": "PRODUCT-MODEL-000184",
  "entity_type": "ProductModel",
  "source_system": "PLM",
  "source_record_id": "PLM-2026-1042",
  "namespace": "Manufacturer-A-Model",
  "relation": "IDENTITY_MATCH",
  "decision": "VERIFIED",
  "evidence_refs": ["IDENTITY-EV-001"],
  "rule_version": "1.0",
  "status": "ACTIVE"
}

Identity Mapping至少应具有唯一映射ID、Canonical Entity ID、Source System和Source Record ID、Identifier Namespace、Entity Type、身份判定规则和版本、Evidence引用、审核状态、生效时间、撤销或失效状态。

这样，身份映射才不再只是一次性数据清洗的产物。

它成为受治理、可追溯、可更新的业务对象。

十七、Identity Evidence：为什么匹配结论也必须能够追溯？

企业可能依据正式制造商目录、PLM主记录、合同、合法分配的外部编码或系统迁移记录，判断两条数据是否属于同一个实体。

这些依据应该保存为Identity Evidence。

并进一步区分：

Evidence Exists：存在引用材料。

Evidence Valid：材料真实且适用于当前判断。

Evidence Supports Identity：材料确实支持两个Record具有同一身份。

例如，两个产品记录拥有同一张宣传图片，不能单独证明它们是同一型号。

同一个项目案例提到两款设备，也不能证明它们属于同一产品实体。

因此，Identity Evidence应当与第六篇Provenance建立关联。

Identity Decision
       ↓
Evidence References
       ↓
Source Registry
       ↓
Provenance
       ↓
Approval Record

如果一项高风险身份判定缺少可验证依据，就应该维持POSSIBLE_MATCH或QUARANTINED，而不是提前晋升为Verified。

十八、Identity Graph：相关实体不等于相同实体

制造商与产品型号有关联。产品型号与配置有关联。配置与具体设备有关联。产品页面与产品有关联。技术文件与配置有关联。

但是，这些关系不是身份等价关系。

例如：

Manufacturer A
      │
      └── manufactures
              ↓
        Product Model FW-30
              │
              ├── hasConfiguration
              │       ↓
              │   Standard 50Hz
              │
              ├── describedBy
              │       ↓
              │   Specification V4.2
              │
              └── representedOn
                      ↓
                 WordPress Page

上述关系名称属于本系列内部语义建模示例。

企业可以建立Identity Graph，保存实体及实体之间的关系。

但应区分SAME_IDENTITY、MANUFACTURED_BY、PART_OF、HAS_CONFIGURATION、INSTANCE_OF、DESCRIBED_BY、SOLD_BY、SUPERSEDES。

因为：

相关关系不等于身份相同。

这一原则在知识图谱、SEO和RAG中都十分重要。

十九、为什么owl:sameAs不能用于普通相关关系？

W3C OWL中的owl:sameAs表达两个标识符所指向的是同一个个体。

它是一种强身份断言。

不能将以下情形直接写成owl:sameAs：

两个产品型号属于同一系列。

经销商销售制造商的产品。

一个品牌由某法人经营。

一份文档描述某个产品。

它们应当使用具有不同业务含义的关系。

W3C OWL Reference：

https://www.w3.org/TR/owl-ref/

Schema.org也存在sameAs属性，但它主要用于提供对象身份相关的参考URL，不能不加区分地当成OWL严格身份推理规则使用。

因此，企业需要把不同语义体系的关系用途明确记录在Metadata Registry中。

对于未经验证的身份关系，不应使用具有确定性含义的等价断言。

二十、Canonical Entity ID、Schema.org @id和Canonical URL的区别

SEO领域尤其容易混淆三个概念。

标识	主要用途	识别对象
Canonical Entity ID	企业主数据治理	业务实体
JSON-LD @id	图数据节点标识	结构化数据中的对象
Canonical URL	搜索索引规范化	网页资源

例如：

Canonical Entity ID:
PRODUCT-MODEL-000184

Web page:
https://example.org/products/fw-30/

JSON-LD @id:
https://example.org/products/fw-30/#product

这些标识可以相互关联，但不能直接认定为同一种身份。

Google对Canonical URL的说明主要涉及重复或高度相似网页的规范化处理。

Google可能根据多种信号选择规范URL，网站声明的Canonical并不构成绝对保证。

官方来源：

https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

因此：

SEO规范网址不能替代企业业务实体的Canonical ID。

如果一家企业拥有多个语言版本网站、产品专题站或分销渠道，一个业务实体也可能被多个网页描述。

这些页面是否需要使用不同Canonical URL，应按照网页内容与SEO规范化要求决定。

业务实体身份则应独立治理。

二十一、WordPress与ACF怎样保存实体身份？

对于WordPress网站，可以通过受保护的自定义字段建立内部身份关联。

例如：

WordPress Post ID:
420

Canonical Entity ID:
PRODUCT-MODEL-000184

Entity Type:
ProductModel

PIM Record ID:
PIM-00882

Identity Status:
VERIFIED

Identity Mapping Version:
1.2

这种方式可以避免仅依赖Slug、文章标题、产品展示名称或WordPress数据库ID。

但新增ACF字段不是最终目的。

系统还应该在发布前检查：

Canonical Entity ID是否存在？

Entity Type是否正确？

PIM映射是否有效？

是否存在已知身份冲突？

是否错误引用其他产品配置？

未经授权的编辑人员是否能修改主身份字段？

对于关键产品页，应把这些条件接入发布前质量门禁。

同时，内部身份审批资料不一定需要展示在前台。

身份治理应区分可公开的Entity Information与仅供内部管理的治理Metadata。

二十二、ProductGroup能否直接用于全部工业设备配置？

Google支持使用ProductGroup和Product等类型描述适用的商品变体。

其中包括hasVariant、variesBy、productGroupID等属性。

但Google当前文档对变体属性、页面结构及商品展示条件有具体要求。

例如，Google支持的variesBy属性主要涉及颜色、尺寸、年龄、性别、材料、图案等类型。

官方来源：

https://developers.google.com/search/docs/appearance/structured-data/product-variants

因此，不能直接推断：

标准50Hz配置、特殊电压配置、增加工程模块的设备、不同安装工况下的解决方案，都天然属于Google当前支持的商品变体场景。

企业可以在内部MDM中建立正式的ProductConfiguration实体。

至于网页是否适合使用ProductGroup，还需要根据具体数据、页面结构和Google文档判断。

同时，不能为了满足Schema测试而编造GTIN、SKU、价格、评分或其他属性。

内部主数据建模与Google搜索展示资格，是相关但不同的两项工作。

二十三、CRM客户与组织实体为什么需要独立身份规则？

产品数据之外，CRM也需要实体身份治理。

例如：

Alpha Industrial Group

Alpha Industrial Trading Ltd.

Alpha Industrial Manufacturing Ltd.

这些名称可能属于同一集团，但未必属于同一个法律主体。

如果系统将它们直接合并，可能造成合同主体错误、销售归因错误、客户账户混合、财务数据不一致以及客户信息访问权限异常。

因此，CRM需要区分Legal Entity、Organization Group、Business Account、Contact、Relationship。

尤其需要避免把同一邮箱域名、同一地址或类似公司名称作为唯一合并依据。

对于客户个人信息，应同时落实适用隐私保护、访问控制与数据保留要求。

MDM的目标不是无条件减少CRM中的记录数量，而是建立能够反映真实业务关系的身份结构。

二十四、RAG为什么需要Entity-aware Retrieval？

对于AI知识库，错误身份可能导致不同制造商、产品型号或客户的信息被混合。

假设知识库包含两份技术文件：

Manufacturer A的FW-30。

Manufacturer B的FW-30。

如果系统只使用文本相似度检索，两份文档可能同时进入模型上下文。

即使每份文档内容都正确，AI仍可能把不同实体的技术参数组合在一起。

因此，建议给Document和Chunk增加实体身份Metadata。

{
  "chunk_id": "CHUNK-2026-1042",
  "document_id": "DOC-FW30-V42",
  "canonical_entity_id": "PRODUCT-MODEL-000184",
  "entity_type": "ProductModel",
  "manufacturer_id": "ORG-0008",
  "configuration_id": "CONFIG-50HZ",
  "source_id": "PLM-008",
  "evidence_id": "EV-4201",
  "identity_status": "VERIFIED",
  "knowledge_status": "APPROVED",
  "effective_from": "2026-09-20"
}

当用户明确询问Manufacturer A的产品时，系统应该识别目标实体，并在检索和证据使用环节保留该身份约束。

User Query
      ↓
Entity Resolution
      ↓
Canonical Entity ID
      ↓
Context & Access Check
      ↓
Source / Version Filtering
      ↓
Evidence Retrieval
      ↓
Answer Generation

需要注意，在Chunk上写入canonical_entity_id，不等于系统已经真正实施身份过滤。

只有检索程序、权限策略及答案验证实际使用这些字段时，才能形成Governed Retrieval。

此外，如果用户问题本身包含多个实体，系统也需要支持跨实体比较，而不是一律限制为单个Entity ID。

Entity-aware Retrieval的目标是保持身份边界，而不是阻止合法的跨实体分析。

二十五、误合并以后，为什么不能只修改Golden Record？

假设企业发现Manufacturer A与Manufacturer B的产品被错误合并。

数据管理员将Golden Record中的Manufacturer改回A。

这并不一定解决问题。

因为错误可能已经传播到PIM、WordPress、技术PDF、CRM、报价系统、分析报表和AI知识库。

如果系统只修改主数据表，不处理这些下游资产，它们仍然可能继续使用错误关联。

因此，Identity Merge必须具备审计和撤销能力。

对于关键实体，不应该只记录最终的Canonical ID。

还应保留：

哪些来源记录参加了合并？

原来分别属于哪些实体？

合并依据是什么？

哪个规则版本作出决定？

谁批准？

合并影响了哪些消费者？

这就是Merge Event的作用。

二十六、Merge Rollback与Entity Split如何执行？

企业可以将身份合并保存为正式事件。

例如：

{
  "event_id": "MERGE-EVENT-0084",
  "source_entities": [
    "PRODUCT-MODEL-000184",
    "PRODUCT-MODEL-000285"
  ],
  "target_entity": "PRODUCT-MODEL-000184",
  "decision": "APPROVED",
  "evidence_id": "IDENTITY-EV-008",
  "rule_version": "1.0"
}

当确认属于False Merge时，应建立纠正事件。

执行流程建议为：

Identity Conflict
       ↓
Suspend Affected Identity Mapping
       ↓
Preserve Evidence & Snapshot
       ↓
Owner / Steward Review
       ↓
Determine Correct Identity
       ↓
Reassign Source Records
       ↓
Rebuild Golden Attributes
       ↓
Identify Downstream Impact
       ↓
Repair CMS / CRM / RAG
       ↓
Re-evaluate & Close

这里的Rollback不是简单将整个数据库恢复到过去某个时间点。

因为其他合法业务数据可能已经变化。

更稳妥的方式通常是使用事件日志、历史快照和来源映射，执行范围受控的补偿性修复。

例如：

恢复两个原本独立的Canonical Entity。

撤销错误Identity Mapping。

重新分配对应技术事实。

重新生成受影响的WordPress页面。

撤销或重新索引受影响的RAG Chunk。

复核已经发出的报价和技术文件。

整个过程应保留审计记录。

Identity Repair不是修改一个ID，而是恢复正确的业务对象边界。

二十七、怎样通过数据库约束防止重复有效映射？

对于已经建立Identity Mapping Registry的企业，可以在数据库层增加基础约束。

例如，以下使用PostgreSQL语法：

CREATE UNIQUE INDEX uq_active_source_identity
ON identity_mappings (
    source_system,
    source_namespace,
    source_record_id
)
WHERE status = 'ACTIVE';

该约束用于防止：

同一个来源系统、同一个命名空间内的同一个Source Record，同时拥有多条Active映射。

这对于避免一份来源记录同时被认定属于多个Canonical Entity具有帮助。

但它不能自动证明某一条Active Mapping一定正确，也不能解决历史时间窗口重叠、同一实体在不同系统中的身份冲突、同名不同制造商的误合并。

因此，数据库约束只是Entity Identity Gate的一部分。

对于版本化映射，还应结合有效时间与历史映射管理。

二十八、如何建立最小的Identity Registry数据模型？

中小型企业可以先建立四类对象。

Entity Registry

保存：

canonical_entity_id
entity_type
identity_scope
canonical_name
identity_status
business_status
owner_id
created_at

Identifier Registry

保存：

identifier_id
canonical_entity_id
identifier_type
identifier_value
issuer
namespace
verification_status

Identity Mapping Registry

保存：

mapping_id
canonical_entity_id
source_system
source_record_id
decision_status
evidence_refs
mapping_version

Entity Relationship Registry

保存：

relationship_id
subject_entity_id
predicate
object_entity_id
evidence_id
effective_from
effective_to

这些并不一定需要独立部署四套数据库。

企业可以使用关系数据库、专门的MDM工具或其他受版本控制的数据管理方式。

关键在于：

实体身份、来源映射、外部标识和实体关系，应当被明确区分并独立治理。

二十九、Entity Identity Lifecycle：身份是否会失效？

实体可能经历多种业务状态。

例如某型号产品：开发中、正式发布、停止销售、停止生产、继续提供售后服务、最终归档。

但业务生命周期变化，并不一定意味着身份消失。

因此建议将三种状态分开管理。

Identity Resolution Status

CANDIDATE
PENDING_REVIEW
VERIFIED
DISPUTED
REJECTED

Business Lifecycle Status

DRAFT
ACTIVE
DISCONTINUED
RETIRED
ARCHIVED

Identity Mapping Status

ACTIVE
SUPERSEDED
REVOKED

例如，某款产品已经停止销售，但其身份仍然是Verified。

历史技术手册仍然可能需要保留。

WordPress的旧产品页面可能需要调整内容和用户引导，而不一定立即删除。

RAG仍然可以在明确历史时间范围的情况下引用该型号资料。

因此：

实体退役不等于删除历史身份。

历史使用资格应通过Lifecycle Policy明确控制。

三十、Entity Identity Gate：如何把身份治理变成生产规则？

前九篇已经建立Source、Provenance、Quality、Contract和Metadata治理。

第十篇应进一步建立Entity Identity Gate。

建议采用以下检查：

检查项	失败情形	处置
Entity Type	类型未知或错误	Block
Canonical ID	不存在或冲突	Block
Namespace	不合法或缺失	Quarantine
Identity Evidence	不足以支持身份	Review
Hard Constraint	关键身份冲突	Block
Mapping Status	映射被撤销	Block
Merge Decision	未经批准	Review / Block
Lifecycle	不适合当前用途	Conditional / Block
Provenance	来源记录不可追溯	Quarantine
Consumer Compatibility	依赖关系未验证	Defer / Block

这张表的核心不是增加更多审核字段，而是让身份问题能够真正阻止错误进入下游。

例如：

Data Contract Pass
        ↓
Metadata Quality Pass
        ↓
Entity Identity Gate
        ↓
Data Quality Gate
        ↓
Golden Record Approval
        ↓
Publication Eligibility

需要明确，实际系统可以将这些检查并行执行，不必严格按表面顺序运行。

但只要存在适用的Critical Identity Violation，就不应允许数据自动进入正式知识发布。

三十一、CI/CD怎样测试实体身份规则？

第八篇已经将Data Contract验证接入CI/CD。

Entity Identity也可以采用类似思路。

但测试重点不再只是字段结构。

还包括：两个Record是否应当匹配；不同实体是否被错误合并；不同配置是否保持独立；失效映射是否被拒绝；错误合并能否正确恢复。

例如，建立一组测试样本：

TEST-001:
Manufacturer A / FW-30
Manufacturer A / FW30
Expected: POSSIBLE or VERIFIED MATCH
Subject to evidence

TEST-002:
Manufacturer A / FW-30
Manufacturer B / FW-30
Expected: NO AUTO MERGE

TEST-003:
FW-30 ProductModel
FW-30 Standard 50Hz Configuration
Expected: DIFFERENT ENTITY TYPES

TEST-004:
Revoked Source Mapping
Expected: REJECT FOR PRODUCTION USE

其中，TEST-001的预期结果不能只由名称决定。

还需要验证制造商、型号身份、来源证据和匹配策略。

自动化测试可以检查：

规则引擎是否正确执行Hard Constraint。

是否错误将Possible Match晋升为Verified。

是否允许重复的Active Mapping。

是否保留身份决策日志。

是否能够识别违反契约的实体类型变化。

这一阶段的重点是：

让身份规则成为可重复测试的生产控制，而不是依靠人员记忆执行。

三十二、如何验证Entity Resolution模型的实际质量？

企业不能只统计“自动合并了多少记录”。

因为自动合并数量越大，不代表结果越准确。

建议建立经过人工核实的评估样本，并区分True Match、True Non-match、False Merge、Missed Match。

常见评价指标包括Precision、Recall以及其他适合Record Linkage任务的指标。

但必须明确统计单位：

是记录对？

候选匹配？

最终实体Cluster？

还是Golden Record？

这些不同层面的质量不能混用。

此外，还应建立独立的业务风险指标。

例如：

Critical False Merge Count。

Unresolved Identity Conflict。

Revoked Mapping Usage。

Golden Record Dispute Rate。

Downstream Repair Completion。

对于涉及正式技术参数、客户合同和合规资料的场景，应重点关注误合并对业务决策造成的影响，而不是单纯追求更高自动匹配覆盖率。

三十三、谁应该负责实体身份？

Identity Governance必须明确责任。

Domain Data Owner负责实体类型、身份范围、关键匹配政策及重大争议裁决。

Data Steward负责日常登记、候选复核、映射维护、异常跟踪和质量报告。

Data Producer负责提供来源ID、身份信息及必要证据。

Data Custodian / IT负责实现Identity Registry、技术约束、权限和日志。

Data Consumer应当按正式映射使用实体信息，并反馈身份冲突。

其中，关键业务身份的最终定义不能完全交给IT。

例如：工程部门应参与产品型号与配置身份判定；财务、法务或采购可能参与供应商及法人身份确认。

SEO团队负责网站内容实体关联，但不应独自决定工程产品是否属于同一型号。

所以：

Identity Authority必须与实体的业务性质匹配。

三十四、中小型B2B企业如何用30天完成第一版MDM？

对于已经使用WordPress、PIM、ERP、CRM和基础自动化工具的企业，不建议立即建设复杂的Enterprise MDM Platform。

可以先从产品数据或客户组织数据入手。

第1周：建立Entity Identity Standard

确定优先治理的实体类型，明确Entity Granularity，建立Identity Namespace，制定Canonical ID分配规则，定义关键Hard Constraint。

交付：

Entity Identity Standard V1。

第2周：建立Identity Mapping Registry

收集PLM、PIM、CMS及其他系统中的来源标识。

执行名称标准化，生成潜在重复候选，核实关键身份依据，将Verified和Possible Match分开管理。

交付：

Identity Mapping Registry V1。

第3周：建立Golden Record Policy

选择重要属性，确定Attribute-level Source of Truth，配置Survivorship Rule，建立冲突状态与审核流程，保留字段级Evidence和Provenance。

交付：

Golden Record Policy V1。

第4周：接入生产系统

在WordPress相关记录中保存Canonical Entity ID。

为RAG Document和Chunk增加实体身份。

建立基础Identity Gate，执行一次False Merge模拟演练，验证错误身份能否被拆分、回滚及修复。

交付：

Entity Identity Governance Gate V1。

30天的目标不是完成全公司全部主数据治理，而是让一个关键业务流程具备稳定身份、可信映射、可验证规则和异常恢复能力。

三十五、SEO / GEO Entity Identity & Master Data实施规范

以下要求属于本系列提出的企业工程实施标准，不代表ISO、GS1、GLEIF、W3C或Google联合发布了SEO/GEO MDM强制标准。

MUST｜必须

MUST-01：关键业务实体必须明确Entity Type与Identity Scope。

MUST-02：关键实体必须具有稳定、唯一且不随意复用的Canonical Entity ID。

MUST-03：名称相似或标准化后相同，不得单独作为自动合并依据。

MUST-04：关键身份映射必须记录来源系统、来源标识、命名空间及身份判定依据。

MUST-05：关键身份冲突不得通过相似度平均分直接裁决。

MUST-06：未经充分验证的Possible Match不得直接晋升为Verified Identity。

MUST-07：Golden Record必须基于适用的Attribute Authority与Survivorship Policy生成。

MUST-08：关键属性必须能够关联来源与Evidence。

MUST-09：关键实体合并必须保留审计记录，并具备错误合并修复方案。

MUST-10：RAG不得仅依赖相似名称，将不同实体的关键事实直接合并。

MUST-11：SEO Canonical URL不得被直接等同于企业Canonical Entity ID。

MUST-12：不得编造GTIN、LEI等外部身份标识。

SHOULD｜建议

建立统一Entity Registry、Identifier Registry与Identity Mapping Registry。

为不同Entity Type分别建立匹配规则。

保留身份关系及其有效时间。

建立定期Identity Quality Review。

将实体身份映射传播到WordPress、CRM和RAG。

将Identity Violation纳入Data Quality Incident管理。

保留实体合并与拆分的历史证据。

MAY｜可选

企业可以根据规模逐步采用：Enterprise MDM Platform、Entity Resolution Engine、Probabilistic Record Linkage、Identity Graph、Knowledge Graph、Golden Record Automation、Human-in-the-loop Matching、Entity-aware Retrieval、Automated Merge Rollback、Cross-system Identity Observability。

技术选型应以实际数据规模、误合并成本、业务复杂度和维护能力为依据。

三十六、正式上线前的Entity Identity验收清单

在允许关键实体进入CMS、报价或AI知识系统前，至少回答：

• Entity Type是否明确？
• Identity Scope是否明确？
• 是否拥有有效Canonical ID？
• 是否使用正确的Identifier Namespace？
• 是否确认来源记录身份？
• 是否存在已知Hard Constraint冲突？
• 是否错误地将相关实体当成相同实体？
• 是否存在未经裁决的Possible Match？
• Identity Mapping是否有效？
• Golden Record是否使用正确的Attribute Authority？
• 关键属性是否保留Evidence和有效时间？
• WordPress页面是否关联正确实体？
• JSON-LD是否描述页面中的实际对象？
• RAG是否能够区分同名但不同的实体？
• 是否存在未关闭的Critical Identity Incident？
• 错误合并以后能否执行Entity Split？
• 下游修复后能否重新验证？

这形成了第一版：

SEO / GEO Entity Identity Admission Checklist。

对于高风险实体，上述检查不能被简单的总体匹配分数覆盖。

三十七、一个完整的端到端应用案例

最后，将本文讨论的机制放回最初的业务场景。

企业拥有以下记录：

PLM:
Manufacturer A / FW-30

CRM:
Manufacturer B / FW30

WordPress:
Manufacturer A / FW-30

第一步，系统执行Name Normalization，三条记录得到相同的规范化型号表达。

第二步，进入Candidate Generation，系统识别这些记录可能有关联。

第三步，检查Entity Type和Identifier Namespace，发现CRM记录属于Manufacturer B，而其他记录属于Manufacturer A。

第四步，执行Hard Constraint。由于存在经过核验的制造商身份冲突，CRM记录被阻止进入同一自动合并流程。

第五步，为Manufacturer A的相关记录建立正式Canonical Entity：

PRODUCT-MODEL-A-000184

Manufacturer B的产品保留独立身份：

PRODUCT-MODEL-B-000285

第六步，依据Identity Mapping关联各自来源记录。

第七步，分别按照Attribute Authority生成Golden Record。

第八步，将Canonical Entity ID及相应Context传播到WordPress、CRM和RAG。

第九步，执行发布前Entity Identity Gate。

第十步，通过正式验证后，允许相应内容进入网站与AI知识库。

最终形成：

Source Records
      ↓
Name Normalization
      ↓
Candidate Generation
      ↓
Identity Verification
      ↓
Canonical Entity ID
      ↓
Identity Mapping
      ↓
Attribute Survivorship
      ↓
Golden Record
      ↓
Publication & Retrieval Gate
      ↓
WordPress / CRM / RAG

如果后来发现身份映射错误，则应通过Identity Incident启动拆分与下游修复，而不是直接删除历史证据。

这就是一条从数据采集、身份识别、主数据生成到生产应用的完整实体治理链路。

三十八、从数据准确到对象准确，SEO/GEO知识体系需要升级什么？

前九篇建立了数据本身的可靠性。

第十篇进一步保证：

可靠数据应当被放到正确的对象上。

整个治理体系可以表达为：

Source Governance
        ↓
Data Provenance
        ↓
Metadata & Semantics
        ↓
Data Contract
        ↓
Data Quality
        ↓
Entity Identity
        ↓
Golden Record
        ↓
Entity Relationships
        ↓
Governed Knowledge
        ↓
SEO Content / Analytics / RAG

这是一张治理能力关系图，不意味着所有企业必须严格按照单一线性顺序部署。

例如，Entity Identity可能需要在采集、清洗、整合和发布阶段反复确认。

Metadata与Data Quality也应贯穿整个生命周期。

关键是：

任何关键事实进入正式知识系统之前，都应当具有明确、经过验证的实体身份。

写在最后：正确事实放在错误实体上，仍然是错误知识

一条准确的工程参数，如果被关联到错误型号，就会变成错误的产品信息。

一份真实企业资料，如果被关联到另一家法人，就会生成错误组织信息。

一条有效的客户记录，如果被错误合并，就可能影响销售与财务判断。

一份可靠技术文档，如果被当成其他产品的依据，就会失去适用性。

因此：

Data Accuracy ≠ Entity Accuracy。

Name Similarity ≠ Identity Equivalence。

Golden Record ≠ Unverified Data Merge。

企业不能只管理字段值、数据来源和接口格式。

还必须管理：

每条数据究竟属于哪个对象。

不同对象之间是什么关系。

哪些来源有权解释该对象的属性。

身份如何产生、变更、合并、拆分及退役。

本篇的核心结论是：

Entity Identity确保企业知道数据描述的是哪个真实业务对象；Master Data Management通过统一身份、来源映射、属性权威、证据和生命周期管理，使多个系统能够围绕正确对象建立可靠、可追溯、可持续修正的知识。

对SEO而言，实体治理为产品页面、组织信息、内部链接和结构化数据提供一致的业务身份基础。

对GEO与RAG而言，它有助于减少不同实体事实混用、错误归属和身份推断失真。

对数字营销而言，它能够改善客户、产品、组织和指标对象的统一管理。

这些能力不会直接保证排名、AI引用或转化。

但它们决定企业能否长期输出正确的知识，并在错误发生时及时识别和修复。

真正可靠的数据体系，不仅要知道某条事实是什么，还必须知道它属于谁。

下一篇

《SEO / GEO 数据治理与规范标准细则（十一）：Knowledge Representation & Semantic Relationships——为什么识别了实体，AI仍然可能误解实体之间的关系？》

第十篇解决实体身份。

第十一篇将进一步解决实体之间的知识表达问题。

研究重点包括：Knowledge Representation、Ontology、Relation Semantics、Knowledge Graph、Claim–Evidence Graph、关系的有效时间与来源、显式事实与推断结果的区别、Semantic Constraints、Graph Quality Gate，以及这些结构如何应用到SEO内容架构、Schema.org、RAG与AI Agent。

参考依据与标准边界

1. ISO 8000-110:2021 — Master data exchange

主数据特征信息交换中的形式语法、语义编码与数据规范符合性要求。

https://www.iso.org/standard/78501.html

2. ISO 8000-115:2024 — Exchange of quality identifiers

主数据交换中的质量标识符要求，包括标识符语义及解析原则。

https://www.iso.org/standard/88847.html

3. GS1 — GTIN Management Standard

贸易项目编号及相关变化时的GTIN分配规则。

https://ref.gs1.org/standards/gtin-management/

4. GLEIF — Legal Entity Identifier

法律实体身份标识体系。

https://www.gleif.org/en/organizational-identity/introducing-the-legal-entity-identifier-lei

5. W3C — OWL Web Ontology Language Reference

包括owl:sameAs等本体语义与身份表达。

https://www.w3.org/TR/owl-ref/

6. W3C — PROV-O

数据来源、活动、实体与代理关系的标准表达。

https://www.w3.org/TR/prov-o/

7. Google Search Central — Organization Structured Data

组织结构化数据和身份相关属性的适用要求。

https://developers.google.com/search/docs/appearance/structured-data/organization

8. Google Search Central — Product Variant Structured Data

ProductGroup、Product及受支持的商品变体标记要求。

https://developers.google.com/search/docs/appearance/structured-data/product-variants

9. Google Search Central — Canonical URL

网页规范化信号及Google规范网址选择机制。

https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

10. Google Search Central — Product Structured Data

产品结构化数据的技术与内容要求。

https://developers.google.com/search/docs/appearance/structured-data/product

本系列自定义实施规范

本文提出的Canonical Entity ID Policy、Identity Namespace、Entity Resolution Workflow、Identity Mapping Registry、Attribute Survivorship Policy、Golden Record Governance、Entity Identity Gate、Merge Rollback、MUST / SHOULD / MAY规则和30天实施路径，均属于本系列面向企业SEO/GEO与数字营销的数据治理实施模型。

这些方法以公开标准为参考，但不代表上述标准组织联合发布了SEO/GEO Master Data Management强制规范。

实体治理能力应通过实际的匹配测试、冲突处置、下游验证和持续质量测量来评价，而不能通过平台部署数量或登记字段数量来证明。