1、基于提示词的零样本方案（识别指代词和实体）

"GPT-4通过指令模板（如“解析当前指代..."点击查看元宝的回答
https://yuanbao.tencent.com/bot/app/share/chat/T4gUKc6bzbpc

GPT-4 通过指令模板实现零样本指代消解的能力，是其上下文理解与推理能力的直接体现。以下结合具体案例和技术细节，说明其实现原理及性能优势：

---

一、​​技术实现原理​​

1. ​​指令模板驱动​​

   GPT-4 通过特定指令模板（如“解析当前指代词对应实体”）将指代消解转化为文本生成任务。模型基于对话历史和当前语句，识别代词（如“它”、“他们”）并关联上下文中的实体。

   ​​示例指令​​：

   "对话历史：{对话文本}；当前轮次：{用户输入}；识别指代词及对应实体"

   输出格式强制要求为 {"指代词": "实体名称"}，确保结构化解析。

2. ​​零样本学习机制​​

   无需额外训练数据或微调，仅依赖预训练语言知识和上下文推理能力。例如，在对话中识别“他们”指向前文出现的多个实体时，模型通过语义相似度与位置优先级综合判断。

---

二、​​具体案例解析​​

​​

在多轮对话系统中，指代消解（Coreference Resolution）是确保对话连贯性的关键技术，主要用于解析用户问题中代词或省略词所指代的具体对象（如实体、事件、时间等）。以下是常见的指代消解形式及其案例：

---

2.1、​​人称代词指代​​

​​形式​​：使用“他/她/它/他们”等代词指代前文提到的实体。

​​案例​​：

• 用户Q1：“张三是谁？” → 系统回答张三的身份。

• 用户Q2：“​​他​​的联系方式是什么？” → “他”指代张三，系统需补全为“张三的联系方式是什么？”。

  ​​难点​​：需区分多个实体的性别或角色（如“他”可能指代前文最后提及的男性实体）。

---

2.2、​​指示代词指代​​

​​形式​​：用“这/那/这些/那些”指代前文的事件或对象。

​​案例​​：

• 用户Q1：“2023年大模型应用场景分为生成和决策两类。”

• 用户Q2：“​​它们​​有什么区别？” → “它们”指代生成和决策场景，系统需补全为“生成和决策场景有什么区别？”。

  ​​难点​​：需识别抽象概念（如“应用场景”）而非具体实体。

---

2.3、​​实体属性指代​​

​​形式​​：用“其/的”关联实体的属性（如职业、地点等）。

​​案例​​：

• 用户Q1：“Abraham Lincoln的出生日期？”

• 用户Q2：“​​他的​​家乡是哪里？” → “他的”指代Abraham Lincoln，系统需补全为“Abraham Lincoln的家乡是哪里？”。

  ​​难点​​：需处理所有格变形（如“他的家乡”需替换为“Abraham Lincoln的家乡”）。

---

2.4、​​跨句实体指代​​

​​形式​​：代词指代跨越多个轮次的实体。

​​案例​​：

• 用户Q1：“GPT-3是什么？” → 系统解释GPT-3。

• 用户Q2：“GPT-4发布时间？” → 系统回答2023年。

• 用户Q3：“​​二者​​有什么区别？​​后者​​的优势？” → “二者”指GPT-3和GPT-4，“后者”指GPT-4，系统需补全为“GPT-3和GPT-4有什么区别？GPT-4的优势？”。

  ​​难点​​：需追踪长上下文中的多个实体顺序（如“后者”通常指最后提及的实体）。

---

2.5、​​时间/事件指代​​

​​形式​​：用“这一年/当时”指代前文时间或事件。

​​案例​​：

• 用户Q1：“GPT-4在2023年发布。”

• 用户Q2：“​​这一年​​计算机视觉有哪些进展？” → “这一年”指2023年，系统需补全为“2023年计算机视觉有哪些进展？”。

  ​​难点​​：需关联时间信息至具体年份或事件。

---

2.6、​​零指代（省略主语）​​

​​形式​​：直接省略主语（常见于中文对话）。

​​案例​​：

• 用户Q1：“如何办理社保卡？”

• 用户Q2：“需要哪些材料？” → 主语省略，系统需补全为“办理社保卡需要哪些材料？”。

  ​​难点​​：需依赖动作连贯性推断主语。

---

2.7、指代类型对比与解决方案

​​指代类型​​	​​案例形式​​	​​解决难点​​	​​典型解决技术​​
人称代词	“他/她/它”	多实体歧义	实体聚类（如NeuralCoref）
指示代词	“这/这些”	抽象概念关联	Few-shot Prompt工程
时间指代	“这一年”	时间实体映射	条件层规范化模型
零指代	省略主语（“需要材料？”）	动作连贯性推理	序列标注与语义补全

---

2.7、​​技术挑战与优化方向​​

1. ​​复杂指代组合​​：

   • 如“后者有什么优势？”需同时识别“后者”指代对象及“优势”的属性关联。

2. ​​长上下文依赖​​：

   • 当对话轮次超过5轮时，传统NLP模型（如spacy）准确率显著下降，需结合LLM的上下文理解能力。

3. ​​中英文差异​​：

   • 中文零指代更普遍（如“联系方式？”），需依赖动词推断主语，而英文依赖代词结构。

---

---

三、​​性能优势分析​​

1. ​​CoNLL-2012 数据集表现​​

   • ​​F1 分数 81.5​​：较传统端到端模型（如 CorefQA 的 83.1）差距仅 1.6%，但无需标注数据训练。

   • ​​15% 提升来源​​：

     • ​​语义泛化能力​​：解决传统模型依赖规则的问题（如性别/数的一致性）。

     • ​​长距离依赖处理​​：在跨段落指代中，GPT-4 通过注意力机制捕捉远距离关联，而传统模型（如 SpanBERT）在超过 10 句的文本中准确率骤降 20%。

2. ​​多轮对话场景实测​​

   • ​​内部测试集（1000 样本）​​：

     指标	GPT-4	传统模型
     简单指代准确率	97%	82%
     复杂指代准确率	89%	73%
     平均响应延迟	<100ms	300ms

   • ​​优化机制​​：

     • ​​动态实体缓存​​：单会话内存占用 <1MB，支持千级并发。

     • ​​批处理优化​​：GPU 并行计算吞吐量提升 32 倍。

---

四、​​技术演进：GPT-4.1 的增强​​

1. ​​长上下文指代消解（OpenAI-MRCR 基准）​​

   • ​​能力升级​​：支持 100 万 token 上下文，在长文档中插入相似实体（如法律条款多次引用“第X条”）时，仍能精准区分不同版本。

   • ​​案例​​：

     输入 50 页合同文档，查询：“第 3.2 条款中‘甲方义务’是否覆盖了附件二的例外情况？”

     GPT-4.1 准确关联“甲方义务”在正文第 8 节的定义，并对比附件二的例外条款。

2. ​​工具调用集成​​

   • ​​与知识图谱协同​​：

     当指代依赖外部知识（如“它”指向“Milvus 数据库”），模型调用工具 get_entity_description("Milvus")补充语义，消解准确率提升 12%。

---

五、​​与传统模型对比的局限性​​

1. ​​依赖提示工程​​：

   • 若指令模糊（如“解释这句话”而非明确要求指代消解），模型可能直接生成答案而非解析实体，需通过少样本示例（Few-shot）约束输出格式。

2. ​​数字与时间敏感度​​：

   • 在查询“今年发布的技术中，哪些改进了它？”时，若历史未明确“今年”对应年份（如 2025），GPT-4 可能忽略时间指代（案例失败率 18%）。

---

总结

GPT-4 的零样本指代消解能力，核心在于​​指令模板的结构化引导​​与​​对话状态的隐式建模​​。其 81.5 的 F1 分数和 15% 的性能提升，在工业级对话系统（如客服、代码助手）中已显著降低人工标注成本并提升交互流畅性。随着 GPT-4.1 在长上下文和工具调用方向的增强，指代消解正从“上下文感知”迈向“知识增强推理”的新阶段。

2、基于上下文对指代问题进行改写（构建多个查询也值得参考）

参考：多轮问答与指代消解-CSDN博客

RAG下的多轮对话
当是多轮的时候，我们会面临着一个多轮问题的匹配召回问题。比如，我们的问题Q1是“南京的特产是什么？”，那么正常一轮是拿Q1去做召回匹配，没问题，召回后模型总结输出，假设模型响应A1是“南京的特产是盐水鸭”。
但是我们要是支持多轮的话，那么用户接下来连着的第二个问题Q2很可能是“它真的很好吃吗？”。那么根据我们的RAG架构流程，自然此时会拿Q2去作匹配召回，结果可想而知，召回的知识库肯定会不符合我们的诉求，因为它的主体没了，知识库资料相似度召回肯定偏得离谱。我们知道，在一个非常依赖RAG外部知识库的垂直业务系统中失去知识库内容的召回这将是致命的。

我们需要如何解决这个问题呢？

事实上，LangChain已经为我们想好了这个问题的解决方案，可以阅读《LangChain与Agent实现》 这篇文章的 “LangChain MultiQueryRetriever通过自动生成多个查询视角来增强检索效果“部分。

在人工智能和自然语言处理领域，高效准确的信息检索一直是一个关键挑战。传统的基于距离的向量数据库检索方法虽然广泛应用，但仍存在一些局限性。一种创新的解决方案：MultiQueryRetriever，它通过自动生成多个查询视角来增强检索效果，提高结果的相关性和多样性。该方案可以解决RAG里前半部分中对问题相识度匹配的局限性，可以更加精准匹配知识库，取出更全面的参考资料给与大模型总结。

MultiQueryRetriever 的核心思想是利用语言模型（LLM）为单个用户查询生成多个不同视角的查询。这种方法有效地自动化了提示工程的过程，克服了传统向量检索中由于查询措辑微小变化或嵌入语义捕获不佳而导致的结果不稳定问题。

注意：MultiQueryRetriever值得参考，或者直接调用这个库

所以说现在的小孩是多么得幸福，啥都有了。

啊？！不对，再来。这个貌似是重点解决问题多样性衍生匹配的，不是针对指代消解场景的。搞错了。

算了，那如果我们要是自己来解决RAG多轮问答问题该如何解决呢？

这里的核心问题是，我们最新的问题Q2没办法通过相似度匹配找到我们想要的答案辅助材料。因此，我们要想办法将Q2进行指代消解处理，通过指代消解将它还原出来本来的问题意思，即Q2处理完应该是Q2.1为“盐水鸭真的很好吃吗？”。这种消除了指代的问题描述就能很好支持知识库召回匹配了。

好了，我们的问题已经转变为如何通过Q１、A1、Q2 转化出Q2.1。这就是典型的指代消解问题，我们的大模型不是正好具备这块能力吗，那就安排上。于是我们的prompt案例是这样的。
 

#prompt

请一步步思考：
根据用户的历史问答，判断当前问题是否需要做指代消解或省略补全？
用一个单词回答：[是]或[否]。
如果回答[是]，则对当前问题进行指代消解或省略补全，然后输出处理后的问题。
如果回答[否]，则输出当前问题的原始内容。
按照json格式输出：{"replace":"[是]或[否]","result":"问题"}
历史问答：{
Q：南京的特产是什么
A：南京的特产是盐水鸭
Q：它真的很好吃吗
A：整体味道还不错，就是有点咸。
Q：有什么食用建议呢？
A：建议配着米饭吃。
}
当前问题：{那米饭需要用五常大米做吗？}
回答是：

这个时候，模型一般会输出：

{"replace": "是", "result": "盐水鸭需要配着用五常大米做的米饭吃吗？"}

注意：

（1）这里同时做了两件事，指代判断，指代改写。这样能减少误改写的情况

（2）动态Prompt重构​​：历史问答总结为简洁提示（如“用户偏好：五常大米”），避免上下文窗口溢出

至此，我们已经顺利拿到Q2.1，将Q2.1进行RAG的流程就能得到最终答案啦。问题解决啦！

理是这么个理，而事实上，很多模型的指代消解能力并不是我们想的这么理想，特别还是在垂直业务下的话效果再次减弱。于是我们可以对模型这块指代消解能力的特定任务微调。不懂如何微调模型的同学可以参考这里《模型微调（Fine-tuning）实践》。

实际场景中历史数据拼接prompt的时候可能还面临着历史数据对模型上下文窗口长度的挑战，注意把控轮数，做好理论和实际之间的平衡。

3、状态管理器DST

参考：虚拟零售智能客服架构设计：如何用大模型实现多轮对话与精准推荐？_大模型智能客服技术架构-CSDN博客

LLM作为DST编码器（直接生成状态）

原理： 将对话历史（用户和系统的轮次 utterance）和当前用户输入拼接成Prompt，要求LLM直接输出结构化的对话状态表示（如JSON格式）。

任务：跟踪用户与电商客服对话的状态。对话状态应包含用户当前的活跃意图和已提供的关键信息（槽位）。
请以JSON格式输出，键包括"active_intent"和"slots"，"slots"是一个键值对对象。
如果意图不明确，active_intent为"unknown"；如果某个槽位信息未提及，不包含该键或值为空。

可能的意图包括：商品咨询、价格咨询、库存查询、购买。
可能的槽位包括：商品名称、尺码、颜色、数量。

对话历史：
用户：你好，在吗？
客服：您好！很高兴为您服务，有什么可以帮到您的吗？
用户：我想看看连衣裙。
客服：好的，我们有很多款式的连衣裙，您喜欢什么风格或者颜色的呢？
用户：黑色的，最好是A字裙。

当前对话状态：{"active_intent": "商品咨询", "slots": {"商品名称": "连衣裙", "颜色": "黑色", "风格": "A字裙"}}

新的用户输入：我想问一下，这种裙子XL码还有货吗？

更新后的对话状态：

LLM可能会输出：{"active_intent": "库存查询", "slots": {"商品名称": "连衣裙", "颜色": "黑色", "风格": "A字裙", "尺码": "XL"}}
优点： 方法直接，无需复杂的状态更新逻辑，对新槽位、新意图的适应性强（通过Prompt定义）。
挑战：
        输出格式的稳定性： LLM可能会生成不符合预期格式的文本，需要进行格式校验和错误处理。可以通过在Prompt中强调格式要求、提供格式示例、甚至使用工具调用（Function Calling）的方式强制结构化输出。
        长对话的上下文窗口限制： 当对话轮次很多时，完整对话历史可能超出LLM的上下文窗口。解决方案包括对话历史摘要（用LLM自身总结历史）、仅保留最近几轮对话、或使用支持更长上下文窗口的模型。
        准确性： 对于非常复杂的状态转换，纯生成式DST的准确性可能不如专门训练的DST模型。

LLM辅助的DST（结合传统状态更新机制）：

原理： 将LLM的输出（如识别的意图、抽取的实体、对上下文的理解）作为传统DST模块的输入，由DST模块根据预定义的规则或逻辑进行状态更新。
示例流程：
        LLM识别新用户输入的意图为“库存查询”，并抽取实体“尺码: XL”。
        DST模块检查当前对话状态：已有意图“商品咨询”，槽位“商品名称: 连衣裙”，“颜色: 黑色”，“风格: A字裙”。
        DST模块根据规则更新状态：将active_intent更新为“库存查询”，并将新抽取的“尺码: XL”添加到slots中。
        优点： 状态更新逻辑更可控、更透明，准确性和可靠性更高，尤其适合业务规则复杂的场景。
        挑战： 需要设计清晰的状态更新规则，模块间交互增加。

3、​​长上下文压缩​（模型层）

"QwenLong-CPRS"点击查看元宝的回答
https://yuanbao.tencent.com/bot/app/share/chat/W2bCycUEHd3K

其他介绍资料：阿里Qwen-Doc团队推出QWENLONG-CPRS，即插即用！全模型“无限上下文能力”触手可及！

备注：这是一项非常实用非常有前景的技术，值得持续探索，TODO 补充实际应用场景

4、前沿论文方向（框架层）

微软CoLLabLLM框架​

有空可以研究下具体技术实现​

​