1. 从一个被低估的难题说起：为什么“他”到底指谁这么难
如果你做过文本分析、信息抽取或者对话系统，大概率遇到过这种让人抓狂的情况：一段话里出现了“张三”“李四”“他”“这个人”“那位负责人”，人类一眼就能看明白谁是谁，但机器读完之后给出的结果却是一团乱麻。更麻烦的是，这种混乱不会在单句里暴露，而是藏在跨句、跨段落的语义链条中。共指消解要解决的，正是这个“代词和名词短语到底指向哪个实体”的问题。
我在实际项目里第一次真正重视共指消解，是在做一个多轮对话摘要功能的时候。当时模型把“客户反馈产品有问题，他要求退款”里的“他”错误地绑定到了客服身上，导致整条摘要的语义完全反了。那次之后我才意识到，共指消解不是一个“锦上添花”的模块，而是很多下游任务的隐形地基。地基没打好，上层建筑再漂亮也会塌。
这篇文章是共指消解系列的第一篇，主要面向有一定自然语言处理基础、但还没有系统接触过共指消解任务的开发者。我会从任务定义、核心难点、常见方案、数据标注、评测指标到实操踩坑，完整地拆一遍。读完你应该能自己判断：什么场景下必须上共指消解，什么场景下可以用更轻量的规则先顶一顶，以及第一次做这个任务时最容易掉进哪些坑。
2. 共指消解到底在解决什么问题：任务边界与核心概念
2.1 指代、共指、回指：三个容易混淆的概念
很多人刚接触时会把这几个词混着用，但在工程实现里它们的边界直接影响你的标注规范和模型设计。
指代是一个更宽泛的概念，指的是用一个语言单位去指称另一个语言单位或现实世界中的对象。比如“苹果”可以指水果，也可以指某家科技公司，这属于词义层面的指代。共指则更具体：两个或多个语言单位在同一个语境下指向同一个实体。比如“张三昨天来了，他说他很累”，这里的“张三”和“他”就是共指关系。回指是共指的一种特殊形式，特指后面的语言单位指向前面的语言单位，通常代词回指名词的情况最多。
在工程上，我们通常只关心共指关系，因为指代和回指的很多子类要么太泛，要么已经被其他任务覆盖。你可以在标注规范里明确写清楚：只标注指向同一实体的名词短语和代词，不处理同形异义和隐喻指代。
2.2 共指链：把散落的提及串成一条线
共指消解的输出通常是一组共指链，每条链代表一个实体，链上的每个元素叫做提及。比如下面这段话：
张三是某公司的技术负责人。他昨天在会议上提出了一个新方案。这个方案后来被采纳了。张三说，这是他今年最满意的作品。
这里至少有两条共指链。第一条是“张三”“他”“张三”“他”，第二条是“一个新方案”“这个方案”“这”。注意“这”在最后一句话里指代的是“作品”还是“方案”，需要结合语境判断，这就是共指消解的难点之一。
在实际系统中，共指链的表示方式通常有两种：一种是每个提及指向链头的指针结构，另一种是直接输出集合。前者更适合增量处理，后者更适合批量推理。选哪种取决于你的业务场景是否需要流式处理。
2.3 和实体链接、指代消解的区别
很多人会把共指消解和实体链接搞混。实体链接是把文本中的提及映射到知识库中的实体，比如把“苹果”链接到某个具体的公司条目。共指消解不要求你有外部知识库，它只关心文本内部的一致性。两者可以串联使用：先做共指消解把同一实体的提及聚在一起，再对每个链的代表提及做实体链接。
指代消解的范围更窄，通常只处理代词和它的先行词之间的关系，而共指消解要处理所有类型的提及，包括名词短语、专有名词、代词甚至零代词。所以在标注成本上，共指消解明显更高。
3. 为什么共指消解这么难：四个绕不开的核心挑战
3.1 语言表达的多样性让规则系统很快触顶
同一个实体在文本里可以有无数种表达方式。以“某公司的技术负责人张三”为例，后面可能出现的提及包括“张三”“他”“这位负责人”“该技术负责人”“张先生”“老张”“此人”等等。如果你用规则去枚举，很快就会遇到边界问题：什么时候“负责人”指的是张三，什么时候指的是另一个人？
我试过用纯规则做一个初版，针对特定领域的文档，准确率能到七成左右，但召回率只有四成多。漏掉的大部分是零代词和嵌套指代。后来加了统计模型，召回率才上来。所以我的经验是：规则可以用来做高置信度的预处理，但不要指望它单独扛起整个任务。
3.2 长距离依赖和跨段落指代
共指关系可以跨越很长的距离。在一篇技术文档里，第一章定义的术语可能在第五章才被再次提及，中间隔了几千个字。传统的滑动窗口方法很难覆盖这种距离，而全文档建模又会带来计算量的问题。
更麻烦的是跨段落指代。段落边界往往意味着话题转换，但有时候作者会在新段落里继续用代词指代上一段的主体。模型需要学会区分“话题转换后的新实体”和“话题延续的旧实体”。这个判断对人类来说很自然，对模型来说却需要大量的上下文信息。
3.3 零代词和省略：中文场景下的特殊难题
中文里零代词非常常见。比如“我昨天买了本书，看完之后觉得不错”，第二句的主语被省略了，但人类知道是“我”。英文里这种情况少一些，所以很多在英文上表现不错的模型直接搬到中文上会明显掉点。
处理零代词通常需要专门的零代词检测模块，先判断哪里存在省略，再预测省略的成分是什么。这一步的误差会传播到后续的共指消解，所以端到端训练在这个场景下优势更明显。
3.4 标注一致性和数据稀缺
共指消解的标注成本很高。一个标注员需要通读全文，找出所有提及，然后判断哪些提及指向同一实体。不同标注员对“哪些算提及”和“什么时候算共指”的理解可能不一致。比如“某公司的技术负责人”和“该公司的技术负责人”算不算同一个提及？如果算，是合并成一个还是保留两个？
我参与过的一个标注项目里，我们花了大量时间在标注规范上，最后发现即使经过培训，标注员之间的一致性也只有八成左右。这意味着模型的上限可能就在那里。所以如果你要做共指消解，一定要先小规模试标，算一下一致性指标，再决定是否值得投入。
4. 主流技术路线拆解：从规则到端到端模型
4.1 基于规则和启发式的方法
早期系统大量使用规则，比如“代词优先指向最近的名词短语”“同性别、同数的名词短语优先”等。这些规则在简单句里有效，但遇到复杂结构就很容易出错。
我整理了一个规则系统的常见优先级顺序，供你参考：
| 优先级 | 规则类型 | 示例 | 适用场景 |
|---|---|---|---|
| 1 | 句法约束 | 代词不能指向句法上不兼容的成分 | 简单主从复合句 |
| 2 | 距离优先 | 优先选择距离最近的候选 | 短文本、对话 |
| 3 | 性别和数一致 | 他和她不能共指 | 有明确性别标记的语言 |
| 4 | 语义类别一致 | 人和机构不能共指 | 领域受限文本 |
| 5 | 重复提及优先 | 相同字符串优先共指 | 术语密集文档 |
规则系统的优点是可控、可解释，缺点是维护成本高，换一个领域就要重新调。如果你的业务场景非常固定，比如只处理某种合同文本，规则系统加上少量统计模型可能就够了。
4.2 基于统计机器学习的方法
在深度学习普及之前，共指消解的主流是特征工程加分类器。每个提及对提取大量特征，包括字符串匹配、距离、句法路径、语义类别等，然后用最大熵或SVM分类。
这种方法的瓶颈在于特征设计。好的特征需要领域知识，而且很难覆盖所有情况。我试过用这种方法做一个法律文书的共指消解，特征工程花了两个月，最后F1值卡在七十五左右上不去。后来换成神经网络模型，同样的数据，F1值直接到了八十三。
4.3 基于神经网络的端到端模型
现在主流方案基本是端到端的神经网络。核心思路是：先用编码器把每个提及的上下文编码成向量，然后计算提及对之间的相似度，最后聚类成共指链。
常见的编码器包括LSTM、CNN和Transformer。Transformer在大规模预训练之后优势明显，尤其是BERT类模型，在很多公开数据集上都能拿到不错的结果。但直接用BERT做共指消解有一个问题：它擅长编码单句或短文本，对长文档的建模能力有限。所以后续有很多工作在做长文档的改进，比如用滑动窗口加跨窗口注意力，或者用层次化编码。
4.4 基于提示和生成式的方法
最近两年，生成式方法开始进入共指消解领域。思路是把共指消解转化成序列生成任务，比如让模型直接输出共指链的文本表示。这种方法的优点是统一了框架，可以和其它生成任务共享模型。缺点是推理速度慢，而且对长文档的输出控制比较难。
我在一个小规模实验里对比过生成式方法和传统分类方法，在短文本上生成式方法略好，但在长文档上传统方法更稳。所以如果你要做的是实时系统，建议还是先用分类框架。
5. 数据标注：决定项目成败的隐形战场
5.1 标注规范怎么定才不坑自己
标注规范是共指消解项目里最重要的文档，没有之一。我见过太多项目因为规范模糊，导致标注数据质量差，模型怎么调都上不去。
规范里至少要明确这几件事：什么算一个提及（名词短语、代词、零代词是否都标）、提及的边界怎么切（“某公司的技术负责人张三”是一个提及还是两个）、共指链的粒度（“张三”和“张先生”算不算同一条链）、以及特殊情况的处理（嵌套提及、并列结构、否定语境）。
我的建议是：第一版规范尽量简单，只标最明确的共指关系。等标注员熟悉之后，再逐步增加复杂度。不要一开始就追求大而全，否则标注员会被吓退，一致性也会很差。
5.2 标注工具选型和效率技巧
常用的标注工具包括brat、INCEpTION和Label Studio。brat适合小规模、高精度的标注，INCEpTION支持多人协作和更复杂的标注模式，Label Studio的优点是部署简单、界面友好。
效率方面，我总结了几条实操经验。第一，先做预标注，用规则或模型跑一遍，标注员只做修正，能省一半时间。第二，把长文档切成小段，每段不超过五百字，标注员不容易疲劳。第三，定期做一致性检查，发现分歧大的地方及时讨论，更新规范。
5.3 一致性评估和常见分歧处理
一致性评估通常用Kappa系数或F1值。Kappa在零点八以上算很好，零点六到零点八算可接受，低于零点六就需要重新培训或修改规范。
常见的分歧点包括：代词指代不明时怎么标、并列名词短语是否拆开、以及跨段落指代是否标注。我的处理原则是：如果两个标注员都认为有共指关系，只是边界不同，就统一到更宽的那个边界；如果一个人认为有共指，另一个人认为没有，就提交给第三方仲裁，并把案例写进规范。
6. 评测指标与实验设计：别被高分蒙蔽
6.1 MUC、B³、CEAF和BLANC的区别
共指消解的评测指标有好几个，每个侧重点不同。MUC关注链接的召回率，B³关注每个提及的准确率和召回率，CEAF关注实体级别的对齐，BLANC综合了共指和非共指的判断。
| 指标 | 侧重点 | 优点 | 缺点 |
|---|---|---|---|
| MUC | 链接召回 | 对长链友好 | 忽略单提及实体 |
| B³ | 提及级别 | 平衡准确和召回 | 对长链不敏感 |
| CEAF | 实体对齐 | 考虑全局 | 计算复杂 |
| BLANC | 综合 | 兼顾非共指 | 对数据分布敏感 |
实际项目中，我通常以B³为主，辅以MUC和CEAF。如果只报一个指标，很容易被误导。比如一个模型把所有提及都串成一条链，MUC可能很高，但B³会很低。
6.2 怎么设计对比实验才靠谱
对比实验要控制变量。编码器、特征、聚类方法、超参数都要逐一对比。我见过一些论文只换了一个组件就宣称大幅提升，但仔细看发现其它设置也变了，这种结果不可信。
我的做法是：先固定一个强基线，然后每次只改一个因素，记录变化。如果提升超过两个点，就重复跑三次取平均，排除随机波动。另外，一定要在多个数据集上验证，单一数据集上的提升可能是过拟合。
6.3 错误分析：从bad case里找方向
错误分析比调参更重要。我通常会把错误分成几类：漏标、错标、边界错误、长距离错误、零代词错误。然后统计每类的占比，优先解决占比最高的那类。
有一次我发现长距离错误占了四成，于是专门优化了跨段落编码，F1值直接涨了三个点。如果当时盲目调参，可能花同样时间只能涨零点几个点。
7. 实操踩坑记录：那些文档里不会写的事
7.1 预处理做不好，后面全白搭
分词和词性标注的误差会直接传播到共指消解。中文分词尤其容易出问题，比如“某公司的技术负责人”可能被切成“某公司”“的”“技术”“负责人”，导致提及边界错误。
我的经验是：不要直接用通用分词工具的输出，而是针对你的领域做定制。如果领域术语多，可以先用领域词典做强制分词，再跑通用分词。另外，词性标注要特别关注代词和名词的区分，因为很多规则依赖这个信息。
7.2 模型训练中的不稳定因素
神经网络训练本身就有随机性，共指消解因为涉及聚类，不稳定性更明显。我遇到过同样数据、同样参数，两次训练结果差两个点的情况。
缓解方法包括：固定随机种子、使用交叉验证、以及用模型集成。如果资源允许，训练三到五个模型做投票，通常能稳定提升一到两个点。另外，学习率预热和梯度裁剪对稳定性也有帮助。
7.3 推理速度和生产环境的妥协
学术模型往往不考虑推理速度，但在生产环境里，延迟是硬指标。一个BERT-base的共指消解模型，在GPU上处理一千字可能需要几百毫秒，如果文档更长，延迟会线性增长。
我的妥协方案是：先用轻量模型做粗筛，把可能的共指对筛出来，再用大模型精排。这样可以在保证精度的同时控制延迟。另外，如果业务允许，可以把共指消解做成异步任务，不阻塞主流程。
7.4 和下游任务的联调
共指消解的输出格式要和下游任务对齐。比如信息抽取任务可能只需要每个实体的代表提及，而摘要任务可能需要完整的共指链。如果格式不匹配，联调时会浪费大量时间。
我的建议是：在项目初期就定义好接口格式，最好用JSON Schema约束。另外，要留一个开关，可以控制是否输出中间结果，方便调试。
8. 从零搭建一个基线系统：可复现的步骤
8.1 环境准备和依赖安装
假设你用Python做开发，基础环境需要PyTorch、Transformers和spaCy。下面是一个最小化的依赖列表：
pip install torch transformers spacy python -m spacy download zh_core_web_sm如果你要用中文预训练模型，可以选BERT-base-chinese或RoBERTa-wwm-ext。后者在中文任务上通常更好，但模型更大，推理更慢。
8.2 数据预处理和提及抽取
提及抽取可以用spaCy的词性标注和依存句法。基本规则是：名词短语、专有名词和代词都作为候选提及。下面是一个简化的抽取逻辑：
import spacy nlp = spacy.load("zh_core_web_sm") def extract_mentions(text): doc = nlp(text) mentions = [] for token in doc: if token.pos_ in ("NOUN", "PROPN", "PRON"): # 简单策略：以名词为中心扩展 span = doc[token.left_edge.i : token.right_edge.i + 1] mentions.append({ "text": span.text, "start": span.start_char, "end": span.end_char }) return mentions这个逻辑很粗糙，实际项目中需要处理嵌套提及和并列结构。但作为基线，先跑通再说。
8.3 模型搭建和训练
用BERT做提及编码，然后计算提及对的相似度。损失函数可以用二元交叉熵，正样本是共指的提及对，负样本是非共指的提及对。
import torch import torch.nn as nn from transformers import BertModel, BertTokenizer class CorefModel(nn.Module): def __init__(self, model_name="bert-base-chinese"): super().__init__() self.bert = BertModel.from_pretrained(model_name) self.classifier = nn.Linear(self.bert.config.hidden_size * 2, 1) def forward(self, input_ids, attention_mask, mention_spans): outputs = self.bert(input_ids, attention_mask=attention_mask) hidden = outputs.last_hidden_state # 取每个提及的表示，这里简化为取首token mention_reprs = [] for start, end in mention_spans: mention_reprs.append(hidden[:, start, :]) # 计算提及对相似度 pairs = [] for i in range(len(mention_reprs)): for j in range(i + 1, len(mention_reprs)): pair = torch.cat([mention_reprs[i], mention_reprs[j]], dim=-1) pairs.append(pair) if not pairs: return torch.tensor([]) pair_tensor = torch.stack(pairs, dim=1) logits = self.classifier(pair_tensor).squeeze(-1) return logits训练时要注意正负样本平衡。共指对通常远少于非共指对，所以需要负采样或调整损失权重。
8.4 聚类和后处理
模型输出的是提及对的分数，还需要聚类成共指链。简单的方法是层次聚类，或者用贪心策略：按分数从高到低合并提及对，直到没有分数超过阈值的对为止。
后处理包括：合并单提及链、处理传递性冲突、以及过滤低置信度的链。这些步骤对最终指标影响很大，不要跳过。
9. 效果验证与迭代方向
9.1 在公开数据集上跑通
中文共指消解常用的公开数据集包括OntoNotes和CoNLL-2012的中文部分。这些数据集标注质量高，适合做基线对比。但要注意，公开数据集的领域和你的业务领域可能差别很大，直接迁移效果会打折扣。
我的做法是：先在公开数据集上验证模型实现是否正确，然后在业务数据上做微调。微调时至少需要几百条标注数据，否则容易过拟合。
9.2 业务场景下的定制优化
业务场景的优化方向通常包括：领域词典注入、规则后处理、以及和下游任务的联合训练。比如在医疗领域，疾病名称和药物名称的共指关系有很强的模式，可以用规则补充。
另外，如果业务对延迟敏感，可以考虑模型蒸馏或量化。把BERT蒸馏到小模型，推理速度能提升三到五倍，精度损失通常在一到两个点以内。
9.3 什么时候该放弃共指消解
不是所有场景都需要共指消解。如果你的文本很短，比如单句或微博，共指关系很少，投入产出比不高。如果下游任务对共指不敏感，比如关键词提取，也可以先不做。
我判断的标准是：如果共指错误会导致下游任务的核心指标下降超过五个点，那就值得做。否则，先用规则顶一顶，把资源投到更关键的地方。
10. 一些个人体会和后续计划
共指消解是一个典型的“看起来简单、做起来复杂”的任务。我最大的体会是：不要一上来就追求端到端的大模型，先把数据标注和评测体系搭好，再逐步迭代模型。很多项目失败不是因为模型不够强，而是因为数据质量太差，导致模型学不到正确的模式。
另外，共指消解和实体链接、关系抽取、事件抽取等任务有很强的关联。如果后续要做信息抽取的全链路，共指消解可以作为中间层，把散落的提及聚合成实体，再往上做关系判断。这样整个系统的可维护性会好很多。
这个系列后续我会继续写共指消解的进阶内容，包括零代词处理、跨文档共指、以及和大语言模型的结合。如果你正在做相关项目，欢迎一起交流踩坑经验。
