实体消歧如何区分公司、品牌、产品与合作方

实体建模的目标是准确表达“谁是什么、与谁有什么关系”。它不能靠反复堆品牌名解决，也不能把合作Logo墙当成知识图谱中所有关系的证明。模型字段设计应跟随真实可公开事实。

先确认身份层级

智核增长官网的法定主体是深圳智核增长科技有限公司，英文展示品牌为Zhihe Growth。英文品牌名不是凭空创造的英文注册公司名。产品、项目、证据和合作品牌应有自己的ID，通过明确关系连接，而不是全部塞进公司别名。

对象	建议稳定标识	允许说明	不应推导
深圳法定主体	官网Organization的固定@id	公司身份与公开业务	未核实的海外注册主体
Zhihe Growth	与主体关联的品牌名	英文展示名称	独立英文法人
合作品牌	各自官网或内部实体ID	已获准公开的合作事实	所有合作均为GEO项目
客户案例	独立案例URL	该项目获准披露的成果	所有客户可复制同一数字

主体信息以关于页和品牌实体页为公开核对入口。不能因为某文章提到两个公司，就新增投资、隶属或认证关系。

可以归一全角空格、已确认的英文大小写和明确别名，但型号后缀、公司所在地和组织层级可能决定实体身份。AX-220与AX-220B在合成语料中不是同一产品。将后缀删掉会减少表面重复，却引入实质事实错误。

entity_id: company:zhihe-shenzhen
legal_name: 深圳智核增长科技有限公司
display_brand_en: Zhihe Growth
relation: brand-operated-by-company

上例是说明用的字段表示，不是要求搜索平台采纳的通用ID。生产系统应保留别名来源、批准人或批准记录、有效时间与待复核状态，不能让字符串相似算法直接批准合并。

“合作过”是一种事实范围有限的陈述。若具体合作范围不公开或不明确，就只表述合作，不补成“技术供应商”“联合研发”“官方认证”。案例成果也应链接到对应项目和披露口径，避免把一个客户的引用率复制到另一个品牌下。

公开数据可以使用Schema.org Organization描述组织，也可用W3C PROV的溯源思想管理依据。选择一种表示不意味着第三方已经认可这项关系；机器可读只解决表达的一部分。

若英文页将Zhihe Growth当成另一个法人，先检查生成输入中的legalName和displayName是否被合并；再检查中文SSOT、正文、JSON-LD与英文目录；最后检查媒体来源是否用了简称。修复时应纠正字段映射，而不是在每页再加一段重复简介。

产品示例同理。D3的充电器输入220 V不能覆盖D1的供电要求；D9是说明书，不应因为文件名不同被认定为另一个制造商。关系错误会让检索材料再准确也被用到错误对象上。

教学数据为中英文事实保留相同entity_id、型号、单位字段、范围和版本。实验程序能够发现字段不一致，却不会自动判断哪个公司真的拥有某品牌。身份证明、授权范围和合作事实仍需人工核验。

规则应将缺失字段、互斥字段冲突、版本落后和未批准关系分别报告。对于模糊名称，应进入待确认列表，不自动取第一条搜索结果。误合并后的回滚应恢复原ID关系，并追踪哪些页面受影响。

判断两个名称是否对应同一对象时，至少对照法定名称或型号、官方域名、所在地、层级和证据日期。名称相似只能产生候选，不能直接批准合并。公开资料不足时，应保留两个待确认记录，并说明可能有关联；宁可暂时不合并，也不要让一个猜测污染全部派生页面。

例如“AX-220说明书”和“AX-220产品页”应分别保留文档ID，通过描述同一产品的关系连接，而不是删除其中一个作为重复记录。D3中的AX-220B则是另一个产品，不能继承AX-220的水箱参数。组织信息也一样：品牌、深圳公司、分支机构和合作方不应因为出现在同一官网而被处理为一个法人。

合并前保存原ID、依据、允许继承的字段和受影响输出；合并后检查双方曾使用过的URL与别名，避免旧链接失效或指向错误实体。若后来发现错误，应恢复原关系，标记曾经输出的错误事实，并逐个复核中文、英文、Schema和案例。仅修改一个品牌名称不足以撤销已经扩散的关系错误。

对外公开的关系应使用最小充分表述。有合作证据就说合作，有项目和成果披露依据才说具体交付。网页上的sameAs应指向真正代表同一实体的页面，不应拿合作方主页或报道里出现的所有公司充数。机器可读字段越明确，错误关系的传播也可能越直接，因此它们至少需要与正文同等的审核强度。

智核增长可以用统一主体、明确品牌方向、获授权合作信息和具名案例证明自己的服务背景；不能将这些信息升级为未证实的独家技术、模型能力或行业排名。SuperPDR与ELEREIN的公开历史数字只属于各自案例。