你在搜索框敲下“苹果”，是想买手机，还是找水果批发价？系统要是把这两个混在一起，体验就崩了。实体链接与消歧，干的就是给每个名字找到正确身份这件事。
先看它到底在忙什么
文本里出现“小米”，机器面前通常摆着一堆候选：小米科技、小米这种粮食、小米电视、甚至某个人名。实体链接负责把“小米”这个词，连到知识库里的某个具体条目；消歧负责从候选里挑出那个对的。
听着像小儿科？真不是。比如用户写“朝阳区天气”，这里的“朝阳”是北京朝阳区。用户写“朝阳演的电影”，可能指演员。同一个词，两套答案。
常见落地场景包括搜索引擎、推荐系统、知识图谱构建、电商商品归一、客服工单分类。你在电商搜“苹果 14”，系统如果连到水果，那推荐就会离谱。
这里有个容易混淆的点：命名实体识别，也就是 NER，只负责标出“这是一个人名/地名/机构名”。实体链接还要进一步说清“它是哪个人、哪个地”。消歧则是链接过程中的关键判断。
真正难的地方，往往不在模型
从实操角度看，候选实体生成决定了天花板。候选里没有正确实体，后面排序再花哨也没用。常见做法是别名词典、别名表、搜索召回、向量召回一起上。
接着是上下文。短文本特别难。“苹果好吃”和“苹果发布会”只差几个字，指向完全不同。长文本也不轻松，代词、省略、反讽都会干扰。
还有个坑：实体是活的。公司会改名，人物会换头衔，新产品会冒出来。别名表如果半年不更新，准确率就可能往下掉。这个维护周期，通常要看业务变化速度。新闻、电商这类领域，更新频率往往要更高。
误区也不少。只靠字符串直接匹配，遇到简称就抓瞎。忽略领域，把通用知识库直接搬进医疗或法律场景，也容易出错。比如“朝阳”在地址场景和文娱场景，候选排序差很多。
那要不要一上来就上大模型？可以，但别急。规则加词典加轻量分类器，在很多垂直场景已经够用，而且可解释、好排查。大模型适合处理长尾和零样本，但成本、延迟、稳定性要一起算。
据一些用户反馈，中文简称和口语化表达多，消歧结果波动会比较大。比如“北大”通常指北京大学，但在某些本地生活语境里，也可能指北大医院或某条路。你不加场景特征，模型也懵。
它和搜索、RAG 有什么关系
做检索增强生成时，如果查询里的实体没消歧，召回文档可能跑偏。用户问“特斯拉财报”，系统却召回“尼古拉·特斯拉”的资料，答案就会奇怪。实体链接与消歧相当于给检索加了一层身份校验。
评估时，别只看一个总数。分领域看准确率、召回率，再看错误类型：是候选没召回，还是排序错了，还是知识库缺实体。不同错法，修法不同。
行业里较常见的一种组合是：先做实体识别，再做候选生成，然后用上下文加实体流行度排序，后面接人工审核闭环。遇到高风险场景，比如金融、医疗，人工确认环节通常不能省。
有意思的是，很多团队把精力花在换模型上，却忽略了别名表和知识库更新。说实话，这部分脏活累活，往往影响更大。
您在实际使用中还遇到过哪些情况？欢迎结合具体场景继续探讨。
