历史上下文融合

在真实对话场景中，用户的问题往往不是孤立存在的。比如：

• 用户先问：“产品A的保修期是多久？”

接着问：“那故障报修需要什么凭证？”

第二个问题中的“那”指代的是产品A，而“故障报修”是延续上一轮话题的追问。如果系统只根据当前问题去检索，很可能会丢失关键背景，导致答非所问。

为什么需要融合历史上下文

单轮问答假设每次提问都是独立的。但实际使用中，用户很少一次性把所有信息说清楚，而是通过多轮交互逐步逼近真实需求。如果不能理解对话历史中包含的实体、意图和约束，系统就只能机械地匹配字面问题，忽略指代和隐含信息，让对话显得很“蠢”。

例如，在没有上下文的情况下，“那怎么取消？”这个问题几乎无法回答——取消什么、取消哪个订单的业务背景都来自前几轮的对话。

如何将历史信息融入 RAG 流程

历史上下文的融合通常发生在两个关键环节：问题改写和检索增强。

1. 利用大模型对当前问题做上下文改写

最常用的手法是，在检索之前，将最近的对话历史（通常是最近几轮的问答）连同当前用户新问题一起，送入一个轻量级提示词，要求模型输出一个完整、自包含的新查询。

示例提示设计：

根据以下对话历史，将用户最新问题改写为一个独立完整的查询，以便检索相关文档。

对话历史：
用户：产品A的保修期是多久？
助手：产品A的保修期为两年。
用户：那故障报修需要什么凭证？

改写后的查询：
产品A故障报修需要准备的凭证

改写后的查询被用作文本向量化的输入，去向量数据库中检索相关片段。这样即便原始问题包含指代词或省略内容，也能检索到正确信息。

这种方法简单有效，成本也低，因为上下文改写只需要调用一次轻量模型（甚至可以复用最终生成用的大模型），且不需要对检索流程做根本性改动。

2. 在检索阶段整合上下文特征（高级用法）

更精细的做法是将历史上下文融入到向量检索本身。例如：

• 上下文感知检索：除了当前问题的向量，还将对话中最近提到的实体、主题词作为额外条件参与相似度计算，提高相关性。
• 结果重排序：先用当前问题召回一批候选片段，再结合对话历史中的约束条件（如地区、产品线、用户身份等）用规则或小模型对结果进行重新打分，把更贴合全对话背景的片段排在前面。

这种做法需要一定的工程改造，适合对检索精度要求很高、且对话上下文频繁改变检索侧重点的业务场景（如多产品线技术支持）。

3. 在生成阶段显式注入历史信息

还有一种直接的方法，就是把对话历史本身（或摘要）作为额外上下文，一并放入最终给大模型的提示词中，和检索到的知识片段一起供模型参考。

例如：

对话历史摘要：用户正在咨询产品A的保修和故障处理。
检索到的知识：
[文档片段1] ……
[文档片段2] ……
请根据以上信息回答用户问题：“需要哪些凭证？”

这样做的好处是模型能直接感知前情，生成的回答更具延续性，也能主动联系用户之前提到的细节（比如提醒“您之前提到的产品A在保修期内，报修时无需额外费用”），提升对话的自然度和专业感。

实践建议

1. 明确保留轮次：通常保留最近3-5轮的对话历史，既能覆盖大部分指代与省略，又不会让上下文过长、增加推理开销和延迟。
2. 对历史做摘要而非原始保留：当对话跨度较长时，可先生成对话摘要（替代原始逐字记录）以压缩 token 用量，效果往往相当。
3. 改写优先级：对于大多数 RAG 应用，在查询前对问题进行上下文改写是性价比最高的融合策略，实施简单、效果明显。
4. 注意隐私与安全：在融合历史上下文时，如果对话中包含敏感信息，需要确保清洗或脱敏后再用于检索和生成，避免将 PII 泄露到查询流程中。

通过合理融合历史上下文，RAG 系统能够从“一问一答的工具”升级为“理解对话进程的助手”，显著提升复杂咨询、排查场景中的解决问题的能力，让交互体验更贴近真人专家的沟通方式。