多轮对话调优

仅靠 LangChain 提供的“开箱即用”组件构建多轮 RAG 对话系统，往往在真实场景中效果不佳。

原因包括：

• 对话历史冗余或噪声累积：越聊越长，LLM 注意力被分散；
• 检索 query 不准确：后续问题依赖上下文（如“他指的是谁？”），但原始 query 无法独立检索；
• 上下文窗口限制：LLM 输入长度有限，无法塞入全部历史 + 检索结果；
• 幻觉增强：错误的历史理解会误导后续回答；
• LangChain 默认链式结构较“线性”，缺乏对多轮语义状态的显式建模。

问题	工程化解决方案
1. 历史太长 → LLM 上下文溢出	使用 对话摘要（Summary） 或 滑动窗口（Window） 管理历史
2. 后续问题指代模糊（如“它”、“上文提到的…”）	引入 查询重写（Query Rewriting / Coreference Resolution）
3. 检索结果与当前意图不匹配	使用 HyDE（Hypothetical Document Embeddings） 或 多阶段检索
4. 回答偏离事实或产生幻觉	加入 答案验证（Answer Validation） 或 引用溯源（Citation）
5. 多轮语义状态丢失	引入 对话状态跟踪（DST）轻量版，如关键词/意图缓存

1. **智能查询重写（**Query Rewriting）——最关键！

目标：把模糊的后续问题（如“那怎么用？”）改写成可独立检索的完整问题（如“RAG 怎么使用？”）

# 使用 create_history_aware_retriever（LangChain 内置）
from langchain.chains import create_history_aware_retriever

query_rewrite_prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一个助手，负责将用户当前的问题改写成一个独立、完整、可用于检索的问题。"),
    MessagesPlaceholder("chat_history"),
    ("human", "当前问题：{input}\n\n改写后的问题：")
])

history_aware_retriever = create_history_aware_retriever(
    llm, base_retriever, query_rewrite_prompt
)

2. 对话历史压缩（History Compression）

方案 A：滑动窗口（推荐简单场景）

from langchain.memory import ConversationBufferWindowMemory
memory = ConversationBufferWindowMemory(k=3, return_messages=True)  # 只保留最近3轮

方案 B：动态摘要（适合长对话）

from langchain.memory import ConversationSummaryBufferMemory

memory = ConversationSummaryBufferMemory(
    llm=llm,
    max_token_limit=500,  # 超出后自动摘要
    return_messages=True
)

3. 上下文注入策略优化

不要简单拼接所有 retrieved docs + 全部 history。建议：

• 只保留与当前问题最相关的 top-k 文档（如 k=3~5）
• 对文档做 chunk 重排序或过滤（如用 LLM 判断相关性）
• 在 prompt 中明确区分“历史”和“检索上下文”

[系统指令]
你是一个专业助手，请基于以下【检索文档】和【最近对话】回答问题。
若文档未提及，请说“我不知道”，不要编造。

【检索文档】
{context}

【最近对话】
{chat_history}

【用户问题】
{input}

4. 引入“反思”或“自验证”机制（减少幻觉）

在生成答案后，让 LLM 自己检查是否与文档一致：

5. Session 级缓存与状态管理

对于同一会话，可以缓存：

• 用户意图（如“正在咨询 RAG 部署”）
• 关键实体（如“用户提到的模型是 Llama3”）
• 已检索过的文档 ID（避免重复）

LangChain 是工具，不是解决方案。 多轮 RAG 的效果瓶颈不在框架，而在对话状态建模 + 检索-生成协同设计。

你需要在 LangChain 之上做：

• 查询重写（必须）
• 历史管理（滑动 or 摘要）
• 上下文精炼
• 答案校验
• 日志与评估闭环