对话系统的核心难点从来不在单轮理解，而在于多轮交互中语言表达的高度省略性。当一个用户连续提问时，后续句子往往大量依赖前文来补全省略的信息，这种依赖关系如果处理不当，系统就会做出错误的回答。以电商客服场景为例，用户先说“我买的那个蓝牙耳机连接不稳定”，客服系统追问具体型号后，用户只回了三个字“就那个啊”。这里的“那个”指向的是用户最初提到的蓝牙耳机，但如果没有把对话历史中的实体信息保存下来，系统根本无法解析出“那个”到底指什么。解决这一问题的技术路线可以拆成两个关键环节：一是上下文建模，即把对话历史的语义信息以结构化或向量化形式保存下来；二是指代消解，即在当前轮次中识别出代词、指示词或省略表达，并把它们链接到上下文中正确的实体上。
上下文建模和指代消解并不是彼此独立的两件事。上下文建模的精度直接决定了指代消解的上限，因为无论后续算法多先进，如果历史信息没有被准确记录，消解算法就缺少了参照对象。比如一个对话状态中只保存了实体的名称而丢掉了属性信息，当用户后续问“它多少钱”时，系统虽然知道“它”指的是某个商品，却未必能给出价格。因此，一个健壮的对话系统通常会把上下文表示和指代消解放在同一个技术框架中协同设计，而不是孤立地优化某一个模块。
对话歧义的类型与上下文依赖关系
对话中的歧义大致可以分成三类。第一类是词汇歧义，同一个词在不同上下文中表达完全不同的含义，例如“苹果”可能指水果也可能指手机品牌，这种歧义通常可以在单轮内通过句内语义来消解。第二类是结构歧义，句子的语法结构存在多种解析方式，比如“我想买一个手机壳和充电器”可以理解为“手机壳和充电器各买一个”，也可以理解为“一个手机壳和一个充电器”。第三类则是指代歧义，也是多轮对话中最常见的歧义类型，表现为代词、指示词、零指代等表达方式在语境中指向不明确。比如“它坏了”中的“它”，或者“再便宜一点”中隐含的“那个商品”。
指代歧义的特殊之处在于，它的消解信息往往不在当前句子内部，而在对话历史中。用户说“它坏了”时，当前句本身无法提供“它”的所指对象，系统必须回溯到上文去找候选实体。这一特征决定了指代消解必须与上下文建模紧密配合。上下文建模的任务就是把过去几轮对话中的实体、属性、意图等信息组织成可查询的结构，而指代消解则相当于在这个结构上执行一次检索和匹配操作。如果上下文信息是零散的、没有按实体维度聚合的，检索效率就会很低，消解准确率也随之下降。
从实际工程角度来看，指代歧义还常常与对话状态更新交织在一起。假设用户在一个订餐对话中先说“帮我订一份宫保鸡丁”，然后又说“饮料要冰的”。第二句话中并没有出现显式代词，但它隐含了一个未说出的主语，即“饮料”这个实体。系统需要识别出这是一个新的实体被引入对话，而不是对已有实体的修饰。这种隐含指代比显式代词更难处理，因为它要求系统能够区分“引入新信息”和“指代旧信息”两种完全不同的对话行为。
上下文建模的常用技术路线
早期的对话系统普遍采用基于槽位填充的上下文建模方法。工程师预定义一个槽位集合，例如在订餐场景中定义菜品、数量、口味、配送地址等槽位，系统在每一轮对话中从用户输入里提取槽值，并更新到一个全局的对话状态对象中。这种方法的优点是结构清晰、易于调试，每个槽位的值都可以直接追踪。局限性也很明显：槽位集合是人工设定的，难以覆盖开放域对话中的各种实体类型；而且这种建模方式无法捕捉实体之间的语义关系，比如当用户说“换个和上次一样的”时，系统只能看到“上次”这个模糊表达，却无法从槽位结构中找到对应的历史订单信息。
随着预训练语言模型的广泛应用，基于向量表示的上下文建模逐渐成为主流。基本做法是把对话历史中每一轮的发言拼接起来，输入到BERT或类似模型中得到一个固定维度的上下文向量，然后让下游任务从这个向量中提取所需信息。这种表示方式的优势是无需手工设计槽位，模型可以自动学习对话中的语义关联。但concat拼接方式在轮次较多时会带来两个问题：一是输入序列长度会达到预训练模型的上限，二是不同轮次之间的信息权重无法被区别对待，较远的历史信息容易被淹没。针对这些问题，研究者提出了记忆网络、层次化编码等技术，把对话历史建模成多层的表示结构，在保持语义完整性的同时让模型能够选择性关注与当前轮次最相关的历史片段。
在工业落地中，一个折中且效果稳定的方案是混合建模。系统一方面维护结构化的对话状态字典，用来保存关键实体和属性值，另一方面使用文本向量来捕捉结构无法覆盖的语义信息。结构化部分负责回答“对话中出现了哪些实体以及它们的属性”，向量部分负责回答“这些实体之间的语义相似度如何”。当指代消解模块需要判断某个代词指向哪个候选实体时，可以先通过结构化字典筛出候选集合，再用向量相似度进行细粒度排序，从而兼顾效率和准确率。
指代消解的算法设计与实现
指代消解的实现方式可以大致分为三类。第一类是基于规则的方法，核心思想是利用代词与候选实体之间的语法特征和距离信息来打分。例如在中文对话中，代词“它”通常指代最近提到的非人物体，“他”则指代最近提到的男性人物。基于规则的方法虽然简单，但在候选实体较少且对话结构规范的场景中效果并不差。下面给出一个简化的规则型指代消解实现，用于在对话历史中定位代词所指的候选实体。
import re
from typing import List, Optional
# 对话历史中的实体记录，每个实体包含名称、类型和出现的轮次
class Entity:
def __init__(self, name: str, entity_type: str, turn_index: int):
self.name = name
self.entity_type = entity_type
self.turn_index = turn_index
# 简化的规则型指代消解：根据代词类型和距离选择候选实体
def rule_based_resolution(pronoun: str, entities: List[Entity]) -> Optional[Entity]:
pronoun_type_map = {
'他': 'person',
'她': 'person_female',
'它': 'object',
'他们': 'person_group',
'它们': 'object_group'
}
expected_type = pronoun_type_map.get(pronoun)
if expected_type is None:
return None
# 筛选与代词类型匹配的实体
candidates = [e for e in entities if e.entity_type == expected_type]
if not candidates:
return None
# 取距离当前轮次最近的候选实体
candidates.sort(key=lambda e: e.turn_index, reverse=True)
return candidates[0]
# 示例：对话历史中记录了两个实体
entity_list = [
Entity('蓝牙耳机', 'object', 1),
Entity('客服小张', 'person', 2)
]
result = rule_based_resolution('它', entity_list)
if result:
print('消解结果:', result.name)
else:
print('未找到匹配实体')
第二类方法是基于特征工程配合机器学习模型。思路是从对话上下文中提取一系列特征，比如代词与候选实体之间的距离、候选实体在对话中出现的频率、候选实体的句法角色、两者之间是否存在其他干扰实体等，然后将这些特征输入到一个分类器或排序模型中，学习出最优的消解决策。这种方法比纯规则更加灵活，能够处理一些规则覆盖不到的场景，但它依赖大量标注数据进行训练，且特征设计的质量直接决定了模型上限。
第三类方法是端到端的神经网络模型。较为常见的是将指代消解与上下文编码结合，把对话历史送入预训练编码器后，在输出层对代词与候选实体分别做表示，再用注意力机制计算两者之间的关联得分。这种方式的优势是不需要手工设计特征，模型可以在训练过程中自动学习到代词与实体之间的语义匹配关系。缺点是训练成本较高，而且在实际部署中需要额外的推理优化手段。对于大多数业务场景来说，先用规则方法快速搭建基线，再逐步引入模型做增量优化，是一条性价比更高的路线。
联合优化与工程落地思路
把上下文建模和指代消解拆成两个独立模块来开发，虽然在工程上分工更清晰，但往往会遇到误差传导的问题。上下文建模产生的实体表示如果不够准确，指代消解模块就会在错误的候选集上做判断，最终错误被放大。为了缓解这一问题，一种常见的做法是在训练阶段对两个模块做联合微调，让指代消解的损失函数能够反向传播到上下文编码器的参数上。这样上下文表示会在训练过程中被逐渐塑造成更适合指代消解任务的形式，而不是一个通用的语义表示。
在具体工程实现上，对话状态的维护方式也值得仔细设计。建议采用增量更新的数据结构，每一轮对话结束后只更新发生变化的部分，而不是重新构建整个状态对象。比如用户说“改成大杯的”，系统只需要更新当前饮品实体的规格属性，而不需要重新解析整个历史。这种增量方式既降低了计算开销，也能减少因重复解析历史语句而引入的误差。对于指代消解模块来说，它需要访问的是一个持续维护的实体列表，这个列表中的每个实体都有唯一标识符、类型标签、属性字典以及最近被提及的轮次信息。
还有一个容易被忽略的工程细节是对话轮次的权重衰减。在多轮对话中，较远的实体被指代的概率通常低于较近的实体，但也并非绝对。如果用户在整个对话过程中反复提到某个商品，即使中间插入了其他话题，这个商品仍然可能是后续代词的指代对象。因此，实体的提及频率和首次出现位置等信息也应该纳入消解判断的依据中，而不是仅仅依赖距离。将这些因素统一编码到上下文表示中，再配合合理的候选筛选策略，能够显著提升整体消解效果。
整体来看，对话歧义的解决不是一个可以靠单一算法完成的孤立任务。它需要上下文建模提供高质量的对话历史表示，需要指代消解模块在候选实体中做出准确判断，还需要对话状态管理在轮次之间保持信息的一致性。把这几个环节作为一个整体来设计，才能让系统在多轮交互中真正理解用户到底在说什么。