基于LangChain的会话历史感知RAG问答系统构建

1. 项目概述：构建具备会话历史感知的RAG智能问答系统

在当今信息爆炸的时代，如何从海量数据中快速准确地获取所需信息成为一大挑战。检索增强生成（Retrieval-Augmented Generation，简称RAG）技术应运而生，它结合了信息检索和大型语言模型的优势，能够基于特定知识库生成精准回答。然而，传统RAG系统存在一个明显短板——无法理解多轮对话中的上下文关联，导致面对用户模糊追问时表现不佳。

本项目基于LangChain框架，构建了一个具备会话历史感知能力的RAG智能问答系统。与普通RAG系统相比，它的核心创新在于能够理解并利用对话历史上下文，将用户的模糊追问（如"它的常见方法有哪些？"）智能重构为完整可检索的问题（如"Task Decomposition的常见方法有哪些？"）。这种能力使得系统在多轮对话场景下仍能保持高准确率，大大提升了用户体验。

系统工作流程可分为三个主要层次：

1. 数据层：从指定网页爬取文本内容，经过清洗和切割后转换为向量表示，存入Chroma轻量级向量数据库
2. 检索层：构建历史感知检索器，结合对话上下文理解用户真实意图
3. 问答层：整合检索结果和对话历史，生成精准、连贯的回答

2. 系统架构与核心组件

2.1 整体架构设计

系统的整体架构遵循模块化设计原则，各组件职责明确，便于维护和扩展。下图展示了主要组件及其交互关系：

code复制用户提问 → [历史感知检索器] → [向量数据库] → [问答生成模块] → 回答输出
            ↑               ↓
        [对话历史管理] ← [会话存储]

这种架构设计具有以下优势：

• 解耦检索与生成过程，便于单独优化各模块
• 通过中间件管理对话状态，支持多用户并发访问
• 模块化设计便于替换底层组件（如更换向量数据库或LLM模型）

2.2 关键组件解析

2.2.1 数据加载与处理组件

WebBaseLoader是系统的数据入口，负责从指定URL抓取网页内容。在本项目中，我们配置它专门抓取Lilian Weng关于Agent技术的博客文章。通过bs4库的解析功能，我们能够精准定位并提取文章正文，过滤掉导航栏、广告等无关内容，确保数据质量。

python复制loader = WebBaseLoader(
    web_paths=['https://lilianweng.github.io/posts/2023-06-23-agent/'],
    bs_kwargs=dict(
        parse_only=bs4.SoupStrainer(class_=('post-header', 'post-title', 'post-content'))
    )
)

2.2.2 文本分割策略

RecursiveCharacterTextSplitter负责将长文档分割为适合处理的短片段。这里有两个关键参数需要特别注意：

• chunk_size=1000：每个文本片段的最大字符数，这个值需要根据使用的嵌入模型和语言模型的上下文窗口大小来调整
• chunk_overlap=200：相邻片段的重叠字符数，这个设置可以防止完整的句子或概念被生硬地分割到两个片段中

提示：文本分割是RAG系统中容易被忽视但极其重要的一环。不合理的分割会导致检索结果支离破碎，影响最终回答质量。建议在实际应用中通过AB测试确定最佳分割参数。

2.2.3 向量存储与检索

Chroma作为轻量级向量数据库，在本项目中承担着存储文本嵌入和高效检索的重任。我们使用OpenAI的text-embedding-ada-002模型将文本转换为1536维的向量表示。这种向量化处理使得系统能够通过计算向量相似度来找到语义上最相关的文档片段。

python复制vectorstore = Chroma.from_documents(documents=splits, embedding=OpenAIEmbeddings())
retriever = vectorstore.as_retriever()

3. 历史感知检索器的实现原理

3.1 传统RAG的局限性

传统RAG系统在处理多轮对话时存在明显缺陷。当用户提出像"What are common ways of doing it?"这样的模糊问题时，系统无法理解"it"具体指代什么，导致检索结果不相关。这是因为标准检索器只能处理独立的查询，无法利用对话历史中的上下文信息。

3.2 历史感知的实现方案

本项目通过create_history_aware_retriever组件解决了这一难题。它的工作原理可分为三步：

1. 接收用户当前问题和对话历史
2. 使用语言模型将模糊问题重构为完整的独立问题
3. 用重构后的问题执行向量检索

对应的提示模板设计如下：

python复制contextualize_q_system_prompt = """Given a chat history and the latest user question 
which might reference context in the chat history, 
formulate a standalone question which can be understood 
without the chat history. Do NOT answer the question, 
just reformulate it if needed and otherwise return it as is."""

3.3 重构过程示例

让我们通过一个具体例子说明历史感知检索器的工作过程：

对话历史：

• 用户：What is Task Decomposition?
• 系统：Task Decomposition is...

当前问题：

• 用户：What are common ways of doing it?

重构后的问题：

• What are common ways of Task Decomposition?

这种重构使得检索器能够准确理解用户意图，返回与Task Decomposition方法相关的文档片段，而非无关内容。

4. 会话管理与问答生成

4.1 多用户会话隔离

在实际应用中，系统需要同时服务多个用户，因此必须确保不同用户的对话历史互不干扰。本项目通过session_id机制实现这一目标：

python复制store = {}

def get_session_history(session_id: str):
    if session_id not in store:
        store[session_id] = ChatMessageHistory()
    return store[session_id]

每个session_id对应一个独立的ChatMessageHistory实例，存储该用户的所有对话记录。当处理新请求时，系统会根据session_id加载对应的对话历史，确保上下文相关性。

4.2 问答生成链

系统的问答生成链由三个主要部分组成：

1. 历史感知检索器：如前所述，负责理解上下文并检索相关文档
2. 提示模板：指导语言模型如何利用检索结果生成回答
3. 语言模型：本项目使用gpt-4-turbo，负责最终的回答生成

提示模板的设计尤为关键，它明确要求模型：

• 仅基于提供的上下文回答问题
• 不知道答案时如实告知
• 保持回答简洁（最多三句话）

python复制system_prompt = """You are an assistant for question-answering tasks. 
Use the following pieces of retrieved context to answer 
the question. If you don't know the answer, say that you 
don't know. Use three sentences maximum and keep the answer concise.\n

{context}
"""

5. 系统部署与测试

5.1 环境配置要点

在部署系统时，有几个关键配置需要注意：

1. 网络代理设置：确保能够稳定访问OpenAI API
2. LangChain Tracing：开启后可以可视化整个处理流程，便于调试
3. API密钥管理：妥善保管LangChain和OpenAI的API密钥

python复制os.environ['http_proxy'] = '127.0.0.1:7890'
os.environ['https_proxy'] = '127.0.0.1:7890'
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = 'your_api_key_here'

5.2 测试案例与分析

我们设计了两轮对话来测试系统功能：

第一轮对话（基础问答）：

python复制resp1 = result_chain.invoke(
    {'input': 'What is Task Decomposition?'},
    config={'configurable': {'session_id': 'zs123456'}}
)

第二轮对话（上下文相关问答）：

python复制resp2 = result_chain.invoke(
    {'input': 'What are common ways of doing it?'},
    config={'configurable': {'session_id': 'ls123456'}}
)

测试结果表明，系统能够：

1. 准确回答直接提问（Task Decomposition的定义）
2. 理解上下文相关的模糊提问（"it"指代Task Decomposition）
3. 保持不同会话的隔离（zs123456和ls123456的历史互不影响）

6. 性能优化与实践经验

6.1 文本分割的最佳实践

经过多次实验，我们总结了以下文本分割经验：

1. 技术文档：chunk_size=800-1200，chunk_overlap=200-300
2. 对话记录：chunk_size=500-800，chunk_overlap=100-150
3. 新闻文章：chunk_size=1000-1500，chunk_overlap=200

分割后应检查：

• 是否保留了完整的句子
• 关键概念是否被分割到多个片段中
• 检索结果是否连贯

6.2 检索器调优技巧

为了提高检索准确率，可以尝试：

1. 调整检索返回的结果数量（默认k=4）

python复制retriever = vectorstore.as_retriever(search_kwargs={"k": 6})

2. 使用混合搜索策略（结合相似度和关键词匹配）
3. 对检索结果进行重排序（reranking）

6.3 常见问题排查

在实际部署中可能会遇到以下问题：

1. 检索结果不相关：

• 检查文本分割是否合理
• 验证嵌入模型是否适合当前领域
• 调整检索参数（k值、相似度阈值）

2. 回答不符合预期：

• 检查提示模板是否明确
• 验证语言模型是否遵循指令
• 确保检索到的上下文质量

3. 性能瓶颈：

• 考虑缓存常用查询结果
• 对向量数据库进行索引优化
• 批量处理请求提高吞吐量

7. 扩展应用与未来改进

7.1 潜在应用场景

本系统的技术方案可应用于多种场景：

1. 企业知识库问答：处理员工关于公司政策、产品文档的查询
2. 教育辅助：基于课程材料的智能辅导系统
3. 客服机器人：理解多轮对话上下文，提供精准支持
4. 研究助手：帮助学者快速定位文献中的相关信息

7.2 可能的改进方向

1. 多模态扩展：支持图像、表格等非文本内容的检索与生成
2. 动态知识更新：定期自动更新向量数据库中的内容
3. 个性化适配：根据用户历史偏好调整回答风格
4. 混合检索策略：结合语义检索和关键词检索的优势
5. 反馈学习：根据用户对回答的评价持续优化系统

在实际项目中，我发现历史感知检索器对提升多轮对话质量效果显著，但同时也增加了系统复杂度。一个实用的建议是，在简单应用场景中可以先尝试基础RAG，当确实需要处理复杂对话时再引入历史感知机制。此外，保持提示模板的简洁明确对系统稳定性至关重要——过于复杂的提示往往会导致意想不到的模型行为。