摘要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。关键词GEOEntity ResolutionEntity LinkingEntity GovernanceKnowledge GraphProvenanceClaimEvidenceIdentity 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表示文本中的 Mentioneee表示知识库中的目标 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表示 Subjectppp表示 Predicateooo表示 Objectqqq表示 Qualifiereee表示 Evidence。例如某个完整事实可能表达为Subject Brand APredicate OPERATED_BYObject Company BQualifier Market AValid From T1Evidence 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 LifecycleEntity 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 与 VersionEntity Governance 真正的难点Entity Resolution 项目很容易把精力集中在“名字是不是同一个”但企业知识中更高风险的问题往往是 Relation。系统可能正确识别 Brand A也正确识别 Company B但最终仍然输出错误关系。因此企业必须建立独立的 Relationship Matrix。SubjectRelationObjectQualifierEvidenceStatusBrand AOPERATED_BYCompany BMarket AEVD-01CurrentBrand AOWNED_BYCompany CCurrentEVD-02CurrentProduct XPRODUCED_BYCompany DVersion 2EVD-03Current这张表最重要的不是格式而是它迫使企业回答三个问题第一这两个 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 TestEntity 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 LoopEntity→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→CorrectEntity 解决“谁”。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 需要稳定 IDAlias 需要明确边界Relation 需要准确语义Qualifier 需要保存时间、市场和版本Claim 需要能够被明确表达Evidence 需要支持对应 ClaimConflict 需要被保留和处理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 平台公开的内部实现。
