摘要

Entity Resolution 解决的是实体识别问题：当品牌、公司、产品或人物名称出现在网页、知识库与用户 Query 中时，系统需要判断这些 Mention 究竟对应现实世界中的哪个对象。

但对于企业 GEO 而言，一次正确的实体解析并不足以建立稳定的 Identity Layer。

企业实体并不是静态数据。公司会更名，品牌与公司之间的关系会变化，产品会迭代，不同市场可能具有不同的运营关系；与此同时，历史网页、旧新闻、第三方页面和搜索索引中的旧信息并不会随着企业内部更新而同步消失。这意味着，同一个 Entity 在公开信息环境中可能长期对应多个名称、多个版本以及相互冲突的 Relation。

因此，Entity Resolution 之后还需要进入一个持续性的治理问题：企业如何维护 Canonical Entity，如何处理 Alias 与 Entity Boundary，如何管理 Relation 及其时间、市场和版本边界，如何为重要 Claim 建立 Evidence 与 Provenance，以及如何在知识发生变化以后持续发现、验证和修正错误。

本文将这一过程抽象为Entity Governance System。它不是某个生成式 AI 平台公开的内部架构，而是一套面向企业 GEO 的知识治理方法。其核心目标，是将 Entity、Relation、Qualifier、Claim、Evidence、Conflict 与 Version 组织为可验证、可更新和可追溯的身份知识，使企业从一次性的“实体清洗”进一步进入长期的 Identity Governance。

关键词：GEO；Entity Resolution；Entity Linking；Entity Governance；Knowledge Graph；Provenance；Claim；Evidence；Identity Layer

一、问题定义：Entity Resolution 为什么不能停留在“识别正确”

Entity Linking 与 Entity Resolution 并不是新的研究问题。

Shen、Wang 与 Han 将 Entity Linking 定义为将文本中的 entity mention 链接到知识库中相应实体的任务，并指出名称变体和实体歧义是其中最核心的挑战之一 [1]。Wu 等人在 BLINK 中进一步采用“候选检索 + 重排序”的两阶段方法处理大规模实体链接问题 [2]。

在传统 Entity Resolution 研究中，问题也不仅限于字符串匹配。Benjelloun 等人在 Swoosh 中讨论的是不同记录是否代表同一个现实世界实体，以及匹配之后如何完成合并 [3]；Bhattacharya 与 Getoor 则进一步说明，在关系数据环境中，实体之间的关系本身也能够成为 Entity Resolution 的重要信息 [4]。

这些研究共同说明了一件事：

Entity Identity 不是由名称相似度单独决定的。

当这一问题进入企业 GEO 场景后，复杂度会进一步增加。

用户询问一个品牌时，生成式系统可能同时接触企业官网、新闻媒体、产品页面、电商平台、历史材料和第三方数据库。同一个品牌名称可能对应 Brand Entity，也可能与 Company、Trademark、Product Line 或其他组织名称高度相似。

即使某一次 Entity Resolution 已经得到正确结果，也仍然存在另一个问题：

这个正确结果能够维持多久？

例如，一家公司今天使用名称 A，明年更名为 B；某个品牌今天由 Company X 运营，未来可能发生主体变化。企业内部数据库可以更新，但旧网页和旧报道不会自动消失。

因此，企业 GEO 面临的实际上是两个不同层次的问题：

Entity Resolution 解决当前识别；Entity Governance 解决身份知识随时间变化以后如何继续保持正确。

可以把两者之间的关系简化为：

Entity Resolution→Entity Governance→Identity Layer\mathrm{Entity\ Resolution}\rightarrow\mathrm{Entity\ Governance}\rightarrow\mathrm{Identity\ Layer}EntityResolution→EntityGovernance→IdentityLayer

这里所谓 Entity Governance，并不是要重新发明 Entity Resolution 算法，而是把实体解析结果放入一个能够持续维护的知识生命周期。

这一步非常重要，因为企业真正需要的不是“AI 今天有没有认对”，而是：

当 Entity、Relation 和信息环境不断变化时，企业有没有能力知道什么仍然正确、什么已经过期、什么存在冲突，以及这些判断依据来自哪里。

二、理论基础：从 Entity Linking 走向 Knowledge Graph Governance

如果只从 Entity Linking 的角度观察问题，核心对象通常是 Mention 与 Entity 之间的映射。

可以简单表示为：

m→em\rightarrow em→e

其中，mmm表示文本中的 Mention，eee表示知识库中的目标 Entity。

但企业身份知识并不是一个孤立的 Entity 集合。

现实中的品牌通常处在一张关系网络中：Brand 与 Company 存在关系，Company 与 Person 存在关系，Brand 与 Product 存在关系，Product 又可能与 Manufacturer、Market 和 Version 发生关系。

因此，当 Entity Resolution 进入企业场景后，更合理的数据结构不是一张名称映射表，而是一张知识图谱。

Hogan 等人在对 Knowledge Graph 的系统综述中，将知识图谱讨论扩展到 graph-based data model、schema、identity、context、querying 和 validation 等多个层面 [5]。这意味着，一个 Entity 的意义不仅来自自身属性，也来自它与其他 Entity 所形成的结构和上下文。

可以把企业 Identity Graph 抽象为：

G=(V,R)G=(V,R)G=(V,R)

其中，VVV表示 Entity 集合，RRR表示 Entity 之间的 Relation 集合。

例如：

Brand A 与 Company B 同时出现，并不能直接推出：

Brand A OWNED_BY Company B

它们还可能是：

Brand A OPERATED_BY Company B

或者：

Brand A DISTRIBUTED_BY Company B

甚至可能没有直接关系。

因此，Entity Identity 与 Relation 必须分开治理。

进一步的问题是，知识图谱本身也并不天然正确。

Paulheim 在 Knowledge Graph Refinement 的综述中指出，大规模知识图谱需要在 completeness 与 correctness 之间不断进行修正，包括发现缺失知识以及识别错误知识 [6]。

这一点对于 GEO 尤其重要。

因为企业 Identity Layer 一旦建立，并不意味着以后不再需要修改。相反，它需要持续进入：

发现 → 验证 → 更新 → 冲突处理 → 再验证

的循环。

因此，从知识工程角度看，企业真正需要维护的对象不是“品牌名称”，而是一组不断变化的身份事实。

三、Entity Governance 的核心模型：Identity、Relation、Qualifier 与 Evidence

一个企业身份事实如果只保存成自然语言，例如：

Brand A 由 Company B 运营。

从知识治理角度看仍然过于粗糙。

因为至少还有三个问题没有回答：

这个 Relation 适用于哪个市场？

它从什么时候开始成立？

凭什么确认这个关系成立？

因此，一个更加完整的身份事实可以抽象为：

F=(s,p,o,q,e)F=(s,p,o,q,e)F=(s,p,o,q,e)

其中：

sss表示 Subject；

ppp表示 Predicate；

ooo表示 Object；

qqq表示 Qualifier；

eee表示 Evidence。

例如，某个完整事实可能表达为：

Subject = Brand A

Predicate = OPERATED_BY

Object = Company B

Qualifier = Market A，Valid From = T1

Evidence = Source X

这里真正重要的变化是：

事实不再只是一个三元关系，而开始带有适用边界和证据来源。

对于企业 GEO，这两个附加层尤其重要。

3.1 Qualifier 决定事实边界

真实商业关系通常具有明显的时间、市场和版本属性。

同一个品牌在 Market A 与 Market B 可能存在不同运营关系；同一个 Product Name 在 Version 1 与 Version 2 中可能对应不同规格；某个人过去是 CEO，并不意味着这个关系当前仍然成立。

如果这些上下文在进入知识库时被删除，一个原本正确的局部事实就可能变成错误的全局事实。

例如：

“Company B 负责 Brand A 在 Market A 的运营。”

如果 Market 信息丢失，就可能被重新生成成：

“Company B 是 Brand A 的运营主体。”

后一句并不一定完全虚构，但它扩大了原事实的适用范围。

这类问题的本质并不是 Entity Hallucination，而是Qualifier Loss。

因此，在企业 Identity Layer 中，Time、Market、Version 和 Scope 不应该作为备注存在，而应该作为事实模型的一部分。

3.2 Evidence 决定事实能否被验证

仅仅把 Relation 结构化仍然不够。

企业还需要知道：

这条 Relation 为什么成立？

这一问题实际上属于 Provenance。

Cheney、Chiticariu 与 Tan 对数据库 Provenance 的综述将 provenance 与数据来源、查询结果解释、更新、调试等问题联系起来 [7]。对于企业知识治理，这种思想同样重要：每一个关键身份事实都应该能够追溯其来源及形成过程。

因此，Evidence 不是文章末尾随手放几个链接。

它应该成为 Claim 的结构化组成部分。

一个 Source 是否真实存在，与它能否支持某个 Claim，是两个不同的问题。

例如，一份生产资料可以证明某个 Product 的生产主体，但不能因此证明生产企业拥有该品牌。

所以企业真正应该建立的是：

Claim–Evidence Mapping。

也就是明确记录：

哪一个 Evidence，可以支持哪一条 Claim。

四、从静态知识库到 Entity Governance Lifecycle

Entity Governance 真正困难的地方，并不是第一次把数据整理出来，而是如何让它持续有效。

传统知识库建设经常采用一种静态思路：

收集资料，整理字段，审核一次，然后发布。

这种方法适合相对稳定的内容，却不适合 Entity。

因为 Entity 本身存在生命周期。

一个更合理的治理过程应该包含以下几个连续阶段：

Entity Discovery、Canonicalization、Relation Validation、Evidence Binding、Conflict Resolution、Version Update、Publication 和 Monitoring。

这些阶段不是彼此独立的模块，而是同一个 Identity Lifecycle 的不同状态。

Entity Discovery 与 Canonicalization

首先需要确定真实世界中有哪些对象值得建立独立 Entity。

并不是企业中的每一个名词都需要变成节点。一个对象是否需要独立治理，可以判断它是否具有独立身份、是否可能被用户单独询问，以及是否具有自己的 Relation 或 Evidence。

完成 Entity Inventory 之后，需要建立稳定的 Canonical ID。

一个基础 Entity Record 可以表示为：

Ei=(idi,typei,namei,Ai,statusi)E_i=(id_i,type_i,name_i,A_i,status_i)Ei​=(idi​,typei​,namei​,Ai​,statusi​)

其中，AiA_iAi​表示 Alias 集合。

这里最重要的是：

Name 可以改变，但 ID 尽量不要改变。

例如，一个知识系统中出现 Brand1024studio、Company A 与 Product X。第一步不应该根据名称直接推断三者关系，而应该先确认它们分别对应哪些独立 Entity，并为其建立稳定 ID。

这就是 Canonicalization 的意义。

Alias 不只是同义词，而是 Identity Boundary

同一个 Entity 可能拥有正式名称、简称、历史名称、不同语言名称以及常见变体。

因此：

A(E)={a1,a2,…,an}A(E)=\{a_1,a_2,\ldots,a_n\}A(E)={a1​,a2​,…,an​}

但企业不能只维护“正确 Alias”。

更重要的是记录：

哪些高度相似的名称并不属于当前 Entity。

因为在真实互联网环境中，模型面对的不只是正确名称，还包括历史称谓、误写、相似公司以及其他高混淆对象。

因此，一个成熟的 Alias Dictionary 应该能够区分：

Current Alias、Historical Alias、Deprecated Alias、Invalid Alias。

从这个意义上说，Alias Governance 真正定义的是 Entity Boundary。

五、Relation、Conflict 与 Version：Entity Governance 真正的难点

Entity Resolution 项目很容易把精力集中在“名字是不是同一个”，但企业知识中更高风险的问题往往是 Relation。

系统可能正确识别 Brand A，也正确识别 Company B，但最终仍然输出错误关系。

因此，企业必须建立独立的 Relationship Matrix。

这张表最重要的不是格式，而是它迫使企业回答三个问题：

第一，这两个 Entity 之间到底是什么 Relation？

第二，这个 Relation 在什么条件下成立？

第三，谁能够证明它？

如果三者中的任何一个无法回答，这条边就不应该直接进入稳定知识层。

Conflict 不应该被删除，而应该被管理

真实企业数据中经常同时存在多个版本。

旧官网可能写 Company A，新官网已经更新为 Company B；某份历史文件仍然使用旧品牌名，第三方文章又引用了更早版本。

传统内容管理的做法往往是：

找到正确答案，然后覆盖旧值。

但对于 GEO，这种方法会丢失重要信息。

因为旧值仍然可能存在于互联网中，并继续影响搜索和生成结果。

所以 Entity Governance 应该保留 Conflict。

至少需要区分：

Current、Historical、Deprecated、Incorrect、Conflicted 与 Unknown。

其中 Historical 与 Incorrect 尤其不能混为一谈。

Historical 表示某条 Relation 过去真实成立，但现在已经结束。

Incorrect 表示这条 Relation 本身缺少可靠事实支持。

这两种信息未来都可能被 AI 检索出来，但修正策略完全不同。

Version Control 是 Identity Governance 的时间轴

如果没有 Version Control，企业只能知道：

AI 回答错了。

有了 Version History，企业才可能继续判断：

AI 返回的是哪个历史版本；

这个版本什么时候失效；

哪些旧 Source 仍然存在；

哪些公开节点没有完成更新。

因此，Entity Governance 的实际运行过程更接近：

Change→Validate→Update→Publish→Observe→Correct\mathrm{Change}\rightarrow\mathrm{Validate}\rightarrow\mathrm{Update}\rightarrow\mathrm{Publish}\rightarrow\mathrm{Observe}\rightarrow\mathrm{Correct}Change→Validate→Update→Publish→Observe→Correct

这才是一个真正的治理闭环。

六、从 Ground Truth 到 Public Knowledge：企业为什么需要两层知识体系

一个常见误区是：

既然 GEO 需要让 AI 获得企业知识，就应该把所有内部资料公开。

这并不成立。

Entity Governance 更合理的结构，是明确区分：

Internal Governance Layer

和

Public Knowledge Layer。

Internal Governance Layer 保存完整事实，包括：

Canonical Entity、Relation、Qualifier、Evidence、历史版本、Conflict 和审核状态。

其中一部分 Evidence 可能来自合同、授权文件或其他不适合公开的材料。

Public Knowledge Layer 则负责输出：

已经核验并允许公开的 Claim。

两层之间的关系可以表示为：

Internal Ground Truth→Validated Claim→Public Knowledge\mathrm{Internal\ Ground\ Truth}\rightarrow\mathrm{Validated\ Claim}\rightarrow\mathrm{Public\ Knowledge}InternalGroundTruth→ValidatedClaim→PublicKnowledge

这个机制非常重要。

因为“Evidence 不公开”并不等于“Fact 不需要 Evidence”。

企业完全可以在内部完成证据验证，然后只向外部公开经过审核的事实结论。

这也意味着，官网、FAQ、品牌知识页、产品页、结构化数据和公开知识库不应该各自维护一套独立事实。

它们应该尽可能成为同一 Ground Truth 的不同发布接口。

否则，信息冲突会从源头重新产生。

七、Query Test：Entity Governance 最终必须接受外部验证

内部知识正确，并不代表外部 AI 已经正确理解。

因此，一个完整的 Entity Governance System 必须包含 Validation。

但 Query Test 不应该依靠测试人员随意提几个问题。

测试集应该从 Entity Graph 与 Relationship Matrix 中派生。

例如，如果知识图谱中存在：

Brand → OPERATED_BY → Company

那么就应该测试：

运营主体是谁；

错误候选是不是运营主体；

历史主体当前是否仍然有效；

不同 Market 是否返回不同 Relation。

如果存在 Historical Alias，就应该加入旧名称测试。

如果存在高混淆实体，就需要加入 Ambiguous Query。

因此：

Entity Graph→Testable Claims→Query Set\mathrm{Entity\ Graph}\rightarrow\mathrm{Testable\ Claims}\rightarrow\mathrm{Query\ Set}EntityGraph→TestableClaims→QuerySet

一个较完整的 Identity Test Set 至少应该同时包含：

Positive Query、Negative Query、Ambiguous Query、Temporal Query 与 Market-specific Query。

这里尤其需要加入 Negative Query。

因为如果测试集只有“标准名称 + 标准问题”，最终得到的准确率通常没有太大意义。

现实世界中的 Entity Resolution 正是在多个候选、相似名称和不完整上下文之间发生的。

所以测试的目的不是证明系统“多数时候能答对”，而是主动寻找：

它在什么条件下会认错。

八、Monitoring 应该是一套 Debugging System，而不是排名系统

企业建立 GEO Dashboard 后，很容易希望最终获得一个简单数字：

Identity Score = 90。

但一个综合分数可能会掩盖最关键的问题。

假设 Brand Name 识别率非常高，但 Ownership Relation 经常错误。那么把两者平均成一个“85 分”，对于修复系统几乎没有帮助。

Entity Governance 更合理的 Monitoring 方式是错误分层。

例如：

如果 Entity 完全未被识别，可能是 Discovery 或 Retrieval 问题；

如果识别到了错误 Entity，可能是 Candidate Generation 或 Disambiguation 问题；

如果 Entity 正确但 Relation 错误，则需要检查 Relationship Matrix；

如果 Relation 使用了过去版本，则属于 Temporal / Freshness 问题；

如果 Market 被错误扩大，则属于 Qualifier 问题；

如果回答正确但 Evidence 不支持 Claim，则属于 Provenance / Citation 问题。

这种错误诊断思路，与 Knowledge Graph Refinement 的目标是一致的：知识系统不仅需要增加缺失事实，还必须识别和修正错误事实 [6]。

因此，Entity Monitoring 更接近软件工程中的 Debugging，而不是内容运营中的 Ranking。

企业真正需要的不是知道：

我们今天是 82 分还是 86 分。

而是知道：

哪一种错误正在发生，它来自哪一层，以及应该回到哪个数据对象进行修复。

九、组织治理：Entity Governance 为什么最终是一个责任机制

即使数据模型设计正确，Entity Governance 仍然可能失败。

因为企业知识不是由一个部门生产的。

品牌名称可能由 Brand Team 管理；

Legal Entity 和 Trademark Relation 需要 Legal 确认；

产品名称与版本属于 Product Team；

生产关系可能来自 Supply Chain；

地区运营关系则可能由 Regional Team 维护。

因此，Identity Layer 不能只有一个“知识库管理员”。

它需要Fact Owner。

Fact Owner 指的是：

对某一类事实拥有最终确认责任的角色或部门。

这和普通的数据录入权限完全不同。

如果 Fact Owner 不明确，就会出现一种非常典型的企业信息结构：

品牌部门使用一种名称；

法务部门使用另一种名称；

产品团队维护自己的版本；

内容团队为了传播进行简化；

历史材料又继续保留过去表达。

AI 最终出现矛盾，并不一定是模型凭空制造了问题。

它可能只是重新组合了企业本身已经存在的多个事实版本。

所以 Entity Governance 从表面上看是 GEO 或 Knowledge Graph 项目，最终却会进入一个更传统、也更困难的问题：

企业内部究竟谁对事实负责？

十、不要从“最大知识图谱”开始

Entity Governance 还有一个常见失败模式：过度追求完整。

企业第一次建立知识图谱时，很容易希望一次性覆盖所有公司、品牌、产品、人物、合作伙伴、市场和历史关系。

但 Knowledge Graph 节点更多，并不意味着 Identity Quality 更高。

更合理的方法，是先建立一个最小可运行 Identity Layer。

第一阶段优先处理少量高价值 Entity，例如 Brand、Company、Product / Product Line 和 Key Person；同时优先确认 OWNED_BY、OPERATED_BY、PART_OF、PRODUCED_BY、FOUNDED_BY 等高风险 Relation。

然后再补充：

Canonical ID、Alias、Qualifier、Evidence、Conflict、Version 和 Query Test。

只有当这一层稳定以后，再逐步扩展更多 Entity Type。

这种方法的核心不是为了少做工作，而是为了避免一个非常现实的问题：

在 Ground Truth 尚未稳定之前，系统规模越大，错误传播范围也越大。

Knowledge Graph Engineering 最终追求的不是节点数量，而是可用性、正确性和可维护性。

十一、一个可长期运行的 Entity Governance Loop

将前面的结构整合起来，可以得到一条完整的企业 Entity Governance Loop：

Entity→Relation→Qualifier→Claim→Evidence→Publish→Test→Monitor→Correct\mathrm{Entity}\rightarrow\mathrm{Relation}\rightarrow\mathrm{Qualifier}\rightarrow\mathrm{Claim}\rightarrow\mathrm{Evidence}\rightarrow\mathrm{Publish}\rightarrow\mathrm{Test}\rightarrow\mathrm{Monitor}\rightarrow\mathrm{Correct}Entity→Relation→Qualifier→Claim→Evidence→Publish→Test→Monitor→Correct

Entity 解决“谁”。

Relation 解决“与谁是什么关系”。

Qualifier 解决“在什么条件下成立”。

Claim 解决“如何表达”。

Evidence 解决“为什么相信”。

Publish 解决“正确知识如何进入可控公开信息层”。

Test 解决“AI 是否能够正确解析”。

Monitor 解决“错误是否重新出现”。

Correct 则把问题重新送回知识治理层。

真正需要注意的是：

这不是一条有终点的流水线。

Correction 之后，新的结果还会再次进入 Entity、Relation、Qualifier 和 Evidence。

因此，Entity Governance 的本质是一种循环系统。

如果企业只完成前半段：

Entity → Relation → Claim → Evidence

那仍然只是知识库建设。

如果只完成后半段：

Query → Monitor → Dashboard

那只是 AI 测试。

只有两者真正连接起来以后，企业才拥有一个能够长期运行的 GEO Identity Layer。

十二、结论

Entity Resolution 解决的是：

一个 Mention 当前应该对应哪个 Entity。

但企业 GEO 真正困难的问题是：

当 Entity、Relation、时间、市场和外部信息环境不断变化以后，如何让这个答案继续保持正确。

因此，Entity Governance 不应该被理解成“把公司名、品牌名和产品名整理统一”。

它真正管理的是一组具有生命周期的身份事实：

Entity 需要稳定 ID；

Alias 需要明确边界；

Relation 需要准确语义；

Qualifier 需要保存时间、市场和版本；

Claim 需要能够被明确表达；

Evidence 需要支持对应 Claim；

Conflict 需要被保留和处理；

Version 需要能够回溯；

Fact Owner 需要对事实负责；

Query Test 与 Monitoring 则负责验证这些知识进入生成式系统以后是否仍然成立。

从这个角度看，企业 GEO 的发展路径也会变得更加清晰。

最早阶段关注的是：

AI 有没有看到品牌。

进入工程化阶段以后，问题逐渐变成：

AI 看到的是不是正确的 Entity。

再继续往下，真正重要的问题则是：

企业有没有能力持续维护 AI 所依赖的那套身份事实。

这也是 Entity Governance 与普通内容优化最大的区别。

Content Management 关注的是：

企业发布了什么内容。

而 Entity Governance 关注的是：

这些内容背后代表什么事实，这些事实属于哪个 Entity，它们之间存在什么 Relation，以及这些关系是否能够长期被验证和维护。

因此，Entity Resolution 可以被视为 GEO Identity Layer 的识别机制，而 Entity Governance 则是维持这个 Identity Layer 长期可靠运行的治理机制。

Identity 不是一次解析的结果，而是一项持续的企业知识治理能力。

参考文献

[1] Shen, W., Wang, J., & Han, J.Entity Linking with a Knowledge Base: Issues, Techniques, and Solutions.IEEE Transactions on Knowledge and Data Engineering, 27(2), 443–460, 2015. DOI: 10.1109/TKDE.2014.2327028.

[2] Wu, L., Petroni, F., Josifoski, M., Riedel, S., & Zettlemoyer, L.Scalable Zero-shot Entity Linking with Dense Entity Retrieval.Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), 6397–6407, 2020. DOI: 10.18653/v1/2020.emnlp-main.519.

[3] Benjelloun, O., Garcia-Molina, H., Menestrina, D., Su, Q., Whang, S. E., & Widom, J.Swoosh: A Generic Approach to Entity Resolution.The VLDB Journal, 18(1), 255–276, 2009. DOI: 10.1007/s00778-008-0098-x.

[4] Bhattacharya, I., & Getoor, L.Collective Entity Resolution in Relational Data.ACM Transactions on Knowledge Discovery from Data, 1(1), Article 5, 2007. DOI: 10.1145/1217299.1217304.

[5] Hogan, A., Blomqvist, E., Cochez, M., d’Amato, C., de Melo, G., Gutierrez, C., Kirrane, S., Labra Gayo, J. E., Navigli, R., Neumaier, S., Ngonga Ngomo, A.-C., Polleres, A., Rashid, S. M., Rula, A., Schmelzeisen, L., Sequeda, J., Staab, S., & Zimmermann, A.Knowledge Graphs.ACM Computing Surveys, 54(4), Article 71, 2021. DOI: 10.1145/3447772.

[6] Paulheim, H.Knowledge Graph Refinement: A Survey of Approaches and Evaluation Methods.Semantic Web, 8(3), 489–508, 2017. DOI: 10.3233/SW-160218.

[7] Cheney, J., Chiticariu, L., & Tan, W.-C.Provenance in Databases: Why, How, and Where.Foundations and Trends in Databases, 1(4), 379–474, 2009. DOI: 10.1561/1900000006.

研究说明

本文中的Entity Governance System是在 Entity Resolution、Entity Linking、Knowledge Graph、Knowledge Graph Refinement 与 Data Provenance 等研究基础上，结合企业 GEO 场景形成的工程化治理框架。

文中的 Entity Governance Loop、Fact Owner、Identity Boundary 等术语用于描述企业知识治理过程，并不代表现有研究中已经存在完全一致的统一行业模型，也不代表任何生成式 AI 平台公开的内部实现。