问 AI 一家公司是做什么的,答案里把它和另一家名字相近的公司混在一起;或者成立年份差了几年,总部城市写成了分公司所在地。这类错误看起来是模型在胡说,根子上往往是另一件事:这个品牌作为一个实体,在模型能读到的材料里没有立稳。
品牌实体是什么,和品牌词有什么不同
实体指的是一个具体、可识别的对象,一家公司、一个人、一个产品,区别于用来称呼它的那几个字。品牌词是字符串,实体是字符串背后的那个东西。两家公司名字只差一个字,是两个实体;一家公司有全称、简称、英文名三种叫法,是同一个实体。
这个区分在搜索领域并不新。谷歌在 2012 年推出知识图谱时,用的说法就是「things, not strings」,要理解的是事物,而不只是匹配字符串。当时公布的规模是 5 亿个对象、35 亿条关于这些对象及其关系的事实。
Hogan 等人发表在 ACM Computing Surveys 的综述,把知识图谱作为一个研究领域做了系统梳理:它用图的结构存储实体和实体之间的关系,服务于需要整合多样、动态、大规模数据的场景。对品牌来说,知识图谱里有没有自己、关于自己的事实对不对,决定了系统在看到这个名字时能联想到什么。
为什么中小品牌更依赖被检索到的材料
大模型自己记住了多少关于某个品牌的事实,和这个品牌有多出名密切相关。Mallen 等人在 ACL 2023 发表的研究构建了 PopQA 数据集,约 14000 个问题,专门考察模型对不同热度实体的事实掌握。结论是:模型在热度较低的长尾事实上表现明显较差,单纯把模型做大,对这部分帮助有限;引入外部检索之后,这类问题的表现显著改善。
绝大多数中小品牌都处在长尾那一端。这意味着模型回答关于它们的问题时,自身记忆靠不住,主要依赖回答当下检索到的材料。材料是否一致、是否准确,直接决定答案是否准确。
检索到的材料互相矛盾时会怎样,Xu 等人在 EMNLP 2024 发表的知识冲突综述里有专门讨论。他们把检索到的多份材料之间的矛盾归为一类冲突,并指出这类冲突会明显影响模型输出的可信度。官网写成立于某年,百科写的是另一年,某篇旧报道又是第三个年份,模型拿到的就是一组互相打架的事实。
哪些事实最能帮 AI 认出一个品牌
最有用的是能在公开系统里核对的事实。法定全称、统一社会信用代码、注册地址、联系电话,这些信息有官方登记可查,不同来源之间可以互相印证。
统一社会信用代码尤其适合作为锚点。按国家标准 GB 32100-2015,它由 18 位阿拉伯数字或大写英文字母组成,包括登记管理部门代码、机构类别代码、登记管理机关行政区代码、主体标识码和校验码五个部分。它是一串编码而不是名称,不存在简称、音译、错别字这类变体,这正是名称做不到的地方。
谷歌搜索中心关于 Organization 结构化数据的文档说明,这类标记帮助谷歌理解机构的管理信息,并在搜索结果中消除歧义。文档明确写着没有必填属性,建议尽可能添加相关属性,推荐的属性里专门有一组商业标识符,包括 taxID、vatID、iso6523Code、duns 和 leiCode,此外还有 legalName、alternateName、address、sameAs 等。
| 事实 | 可以在哪里核对 | 在官网上怎么呈现 |
|---|---|---|
| 法定全称 | 企业登记信息 | 关于页正文与 legalName 属性 |
| 统一社会信用代码 | 企业登记信息 | 关于页或页脚正文,并按文档选择合适的标识符属性 |
| 简称、英文名、曾用名 | 企业自行声明 | 关于页正文与 alternateName 属性 |
| 注册地址与办公地址 | 企业登记信息与地图平台 | 分开写明,与地图资料一致 |
| 官方账号 | 各平台的认证资料 | sameAs 属性列出企业自己控制的主页 |
需要说清楚的是,这份文档是谷歌的。国内各家 AI 平台是否读取、如何使用 Organization 标记,没有公开说明。标记本身成本很低,值得做,但不应期待它单独解决问题。
实体优化的具体做法
实体优化的核心不是写新内容,而是让已有的事实在所有渠道上说同一句话。
第一步是做一张事实表:法定全称、简称、英文名、曾用名、统一社会信用代码、成立时间、注册地址、办公地址、电话、服务范围。每一项只保留一个正确版本,由专人维护。
第二步是拿这张表去逐个渠道比对:官网各页面、百科词条、地图平台、公众号简介、招聘平台、行业目录。发现不一致的,改成表里的版本。这一步很枯燥,但它消除的正是模型检索时会撞上的矛盾。按上面知识冲突研究的思路,在材料互相打架的情况下,再多发一份新材料并不能解决问题,先把旧的对齐更对症。
第三步是在官网上把这些事实写成正文,而不是只放在图片或页脚的小字里,再配上相应的结构化数据。内容生产与信源投放里提到的百科词条和行业信源,也要以这张表为准,不能各写各的。
第四步针对同名混淆。如果已知有一家名字相近的公司,官网上可以直接写明两者的区别:所在城市不同、业务不同、没有关联关系。这类说明看起来多余,对模型却是少有的明确消歧材料。同样值得写明的是自己不做的业务,模型在材料不足时可能把相邻业务安到品牌头上,一句明确的否定能堵住这个口子。
实体优化做不到什么
它不能让一个品牌被推荐。实体立稳,只是让模型在提到这个名字时知道说的是谁、说得对不对;在「哪家好」这类问题里被点名,还取决于有多少可信来源支持这个品牌,那是另一层工作。
它也不能强行把品牌加进某个知识图谱。谷歌、百度这类系统收录谁、怎样呈现,由平台决定,企业能做的是把可核对的事实准备好,放在它们会读取的地方。
已经进入模型训练数据的旧信息,也不会因为网页改了就立刻消失。事实统一之后,变化要靠后续几轮复测来确认,而不是改完第二天去问一次。
参考来源
- Singhal, A. (2012). Introducing the Knowledge Graph: things, not strings. Google.
- Hogan, A., Blomqvist, E., Cochez, M., et al. (2021). Knowledge Graphs. ACM Computing Surveys.
- Mallen, A., Asai, A., Zhong, V., Das, R., Khashabi, D., & Hajishirzi, H. (2023). When Not to Trust Language Models: Investigating Effectiveness of Parametric and Non-Parametric Memories. Proceedings of ACL 2023.
- Xu, R., Qi, Z., Guo, Z., Wang, C., Wang, H., Zhang, Y., & Xu, W. (2024). Knowledge Conflicts for LLMs: A Survey. Proceedings of EMNLP 2024.
- Google Search Central (2026). Organization structured data. Google for Developers.
- 国家市场监督管理总局、国家标准化管理委员会 (2015). GB 32100-2015 法人和其他组织统一社会信用代码编码规则. 国家标准全文公开系统.
- 重庆市九龙坡区人民政府 (2016). 《GB 32100-2015法人和其他组织统一社会信用代码编码规则》. 重庆市九龙坡区人民政府网站.