LangChain与ChromaDB问答优化技巧

本文针对LangChain与ChromaDB构建的检索增强生成（RAG）系统在面对复杂查询时，响应内容不完整的问题，提出了优化策略。文章深入探讨了文本分割策略（`chunk_size`、`chunk_overlap`）和检索器配置（`k`值）对响应完整性的关键影响，指出不当的文本分割和过低的k值是导致信息缺失的主要原因。针对这些问题，本文提供了具体的优化方案和代码示例，包括调整`RecursiveCharacterTextSplitter`的参数，以及通过`vectordb.as_retriever()`增加检索器返回的文档数量。强调了根据文档类型、查询模式和LLM模型进行迭代测试和调优的重要性，以确保系统能够从源文档中提取并生成更全面、准确的答案，从而提升RAG系统的用户体验和性能。

本文旨在解决基于LangChain和ChromaDB构建的检索增强生成（RAG）系统在面对复杂查询时，响应内容不完整的问题。我们将深入探讨文本分割策略（`chunk_size`、`chunk_overlap`）和检索器配置（`k`值）对响应完整性的关键影响，并提供优化方案和代码示例，以确保系统能够从源文档中提取并生成更全面、准确的答案。

引言：RAG系统响应不完整性挑战

在构建基于大型语言模型（LLM）的检索增强生成（RAG）系统时，一个常见的问题是系统返回的答案可能不够完整，无法充分涵盖源文档中的相关信息。这通常发生在处理多页PDF文档或包含大量细节的文本时。当用户期望一个全面的摘要或详细解释，而系统只提供片段时，用户体验会大打折扣。本文将针对LangChain与ChromaDB结合的RAG管道，探讨导致响应不完整性的核心原因，并提供切实可行的优化策略。

核心概念回顾

在深入解决方案之前，我们先回顾RAG系统中的几个关键组件及其作用：

1. 文档加载与分割（Document Loading & Splitting）：
   • DirectoryLoader：用于从指定目录加载各种类型的文档（如PDF）。
   • RecursiveCharacterTextSplitter：一种智能的文本分割器，能够将长文档递归地分割成更小的、可管理的文本块（chunks），同时尽量保持语义完整性。其关键参数是chunk_size（每个文本块的最大字符数）和chunk_overlap（相邻文本块之间的重叠字符数）。
2. 嵌入（Embeddings）：
   • 将文本块转换为高维向量的过程。这些向量能够捕捉文本的语义信息，使得相似的文本块在向量空间中距离更近。
   • OpenAIEmbeddings 或 HuggingFaceEmbeddings 是常用的嵌入模型。
3. 向量数据库（Vector Database）：
   • 如ChromaDB，用于存储嵌入向量及其对应的原始文本块。它能高效地根据查询向量检索出最相关的文本块。
   • Chroma.from_documents() 方法用于从文档创建或加载向量数据库。
4. 检索问答链（RetrievalQA Chain）：
   • LangChain的核心组件，它协调了检索（从向量数据库获取相关文本块）和生成（LLM根据检索到的文本块生成答案）两个阶段。
   • retriever=vectordb.as_retriever()：将向量数据库转换为一个检索器，该检索器负责根据用户查询获取相关文档块。
   • chain_type="stuff"：一种链类型，它将所有检索到的文档块“填充”（stuff）到一个单独的提示中，然后发送给LLM进行处理。

响应不完整性的原因分析

导致RAG系统响应不完整的主要原因通常在于以下两点：

1. 不当的文本分割策略：
   • chunk_size过小：如果单个答案或关键信息跨越了多个文本块，而每个文本块又太小，LLM在生成答案时可能无法获得完整的上下文。
   • chunk_overlap不足：如果文本块之间没有足够的重叠，重要的上下文信息可能在分割边界处丢失，导致语义断裂。
2. 检索器配置不当：
   • k值过低：检索器默认或配置为只返回少数（例如，默认k=4）最相关的文本块。如果完整的答案需要更多文本块才能拼凑出来，那么LLM将无法获得所有必要的信息。

优化策略与代码实践

为了提升RAG系统的响应完整性，我们将重点优化文本分割和检索器配置。

1. 优化文本分割策略

选择合适的chunk_size和chunk_overlap至关重要。chunk_size应足够大，以包含一个相对完整的语义单元，但又不能太大，以免超出LLM的上下文窗口限制或导致检索效率降低。chunk_overlap则用于弥补分割可能造成的语义断裂，确保相邻块之间有足够的上下文。

以下是一个优化的文档加载和分割示例：

from langchain.document_loaders import PyPDFLoader, DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings # 或 HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI
import os

# 确保设置了OpenAI API Key
# os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

def load_and_split_documents(directory_path: str, chunk_size: int = 1000, chunk_overlap: int = 100):
    """
    加载指定目录下的PDF文档，并进行递归字符分割。

    Args:
        directory_path (str): 包含PDF文件的目录路径。
        chunk_size (int): 每个文本块的最大字符数。
        chunk_overlap (int): 相邻文本块之间的重叠字符数。

    Returns:
        list: 分割后的文档文本块列表。
    """
    print(f"Loading documents from: {directory_path}")
    loader = DirectoryLoader(directory_path, glob="./*.pdf", loader_cls=PyPDFLoader)
    documents = loader.load()

    print(f"Splitting documents into chunks (size={chunk_size}, overlap={chunk_overlap})...")
    text_splitter = RecursiveCharacterTextSplitter(chunk_size=chunk_size, chunk_overlap=chunk_overlap)
    texts = text_splitter.split_documents(documents)
    print(f"Total {len(texts)} chunks generated.")
    return texts

def create_or_load_vectordb(texts: list, persist_directory: str = './ChromaDb'):
    """
    创建或加载ChromaDB向量数据库。

    Args:
        texts (list): 待嵌入的文本块列表。
        persist_directory (str): 向量数据库的持久化目录。

    Returns:
        Chroma: ChromaDB向量数据库实例。
    """
    embeddings = OpenAIEmbeddings() # 可以替换为HuggingFaceEmbeddings

    # 检查持久化目录是否存在，如果存在则加载，否则创建
    if os.path.exists(persist_directory) and os.listdir(persist_directory):
        print(f"Loading existing ChromaDB from: {persist_directory}")
        vectordb = Chroma(persist_directory=persist_directory, embedding_function=embeddings)
    else:
        print(f"Creating new ChromaDB at: {persist_directory}")
        vectordb = Chroma.from_documents(documents=texts, embedding=embeddings, persist_directory=persist_directory)
        vectordb.persist()
        print("ChromaDB created and persisted.")
    return vectordb

在上述代码中，我们将chunk_overlap从原始示例的50增加到100，这有助于在块边界处保留更多上下文。chunk_size的1000是一个常用的起始值，但具体数值应根据文档内容和LLM的上下文窗口进行调整。

2. 配置检索器以获取更多相关文档

这是解决响应不完整问题的关键一步。默认情况下，vectordb.as_retriever()可能只返回少数（例如4个）最相关的文本块。如果完整的答案需要更多上下文，这些数量是远远不够的。我们需要通过search_kwargs参数来增加检索器返回的文档数量（k值）。

def setup_qa_chain(vectordb: Chroma, k_value: int = 8):
    """
    设置RetrievalQA链。

    Args:
        vectordb (Chroma): ChromaDB向量数据库实例。
        k_value (int): 检索器返回的最相关文档块数量。

    Returns:
        RetrievalQA: 配置好的RetrievalQA链。
    """
    llm = OpenAI(temperature=0, model_name="text-davinci-003") # 也可以使用gpt-3.5-turbo等

    # 配置检索器，增加返回的文档数量
    retriever = vectordb.as_retriever(search_kwargs={"k": k_value})

    # 注意：如果chain_type_kwargs包含与retriever冲突的参数，可能会导致问题
    # 确保chain_type_kwargs是适合stuff链的
    # 例如，可以用于设置prompt模板等
    # chain_type_kwargs = {"prompt": YOUR_CUSTOM_PROMPT_TEMPLATE} 

    qa_chain = RetrievalQA.from_chain_type(
        llm=llm,
        retriever=retriever,
        chain_type="stuff", # "stuff"会将所有检索到的文档拼接起来
        # chain_type_kwargs=chain_type_kwargs, # 如果有自定义prompt，可以在这里传入
        return_source_documents=True # 方便调试，查看哪些文档被检索到
    )
    print(f"RetrievalQA chain setup with k={k_value} for retriever.")
    return qa_chain

# 主运行逻辑
if __name__ == "__main__":
    UPLOAD_DIR = './static/upload/' # 确保此目录存在并包含PDF文件
    PERSIST_DIR = './ChromaDb'

    # 1. 加载和分割文档
    # 尝试更大的chunk_size和chunk_overlap以捕获更多上下文
    texts = load_and_split_documents(UPLOAD_DIR, chunk_size=1500, chunk_overlap=150) 

    # 2. 创建或加载向量数据库
    vectordb = create_or_load_vectordb(texts, PERSIST_DIR)

    # 3. 设置QA链，并增加检索的k值
    # k值应根据期望的响应长度和LLM的上下文窗口进行调整
    # 例如，如果每个chunk 1500字，k=8，总上下文将是12000字，需要LLM支持
    qa_chain = setup_qa_chain(vectordb, k_value=8) 

    # 4. 提问并获取响应
    query = "请总结这篇文档的主要内容" # 替换为你的具体查询
    print(f"\nQuerying: '{query}'")
    response = qa_chain({"query": query})

    print("\n--- Full Response ---")
    print(response["result"])

    print("\n--- Source Documents ---")
    for i, doc in enumerate(response["source_documents"]):
        print(f"Document {i+1} (Page {doc.metadata.get('page', 'N/A')}):")
        print(doc.page_content[:500] + "...") # 打印前500字
        print("-" * 20)

在setup_qa_chain函数中，我们通过vectordb.as_retriever(search_kwargs={"k": k_value})将检索器配置为返回k_value个最相关的文档块。将k_value从默认值（通常为4）增加到8或更高，可以显著提高LLM获得完整上下文的可能性。然而，需要注意的是，k_value的增加会直接影响发送给LLM的总令牌数，这可能导致：

• 超出LLM的上下文窗口限制：如果检索到的文档块总长度超过LLM的最大输入令牌数，链会失败或截断。
• 增加成本和延迟：处理更长的上下文会消耗更多的计算资源和时间。

因此，k_value的选择需要权衡响应完整性、LLM能力和系统性能。

注意事项与最佳实践

1. 迭代调优：chunk_size、chunk_overlap和k_value没有一劳永逸的最佳值。它们需要根据你的具体文档类型、查询模式和LLM模型进行迭代测试和调优。
   • 从小到大调整k值：逐步增加k值，直到响应完整性达到满意水平，同时监控LLM的上下文窗口限制和性能。
   • 调整chunk_size：如果答案通常很长，考虑增加chunk_size。如果文档结构复杂，包含许多小节，可能需要较小的chunk_size以保持检索的精确性。
2. LLM上下文窗口：确保你的LLM（如text-davinci-003或gpt-3.5-turbo）有足够大的上下文窗口来处理所有检索到的文档块。如果上下文过长，可以考虑使用map_reduce或refine等链类型，它们能够处理更长的文档，但可能更复杂或更耗时。
3. 调试：始终将return_source_documents=True设置为RetrievalQA链的参数。这可以让你查看哪些原始文档块被检索到，从而更好地理解为什么响应会不完整或不准确。
4. 数据质量：高质量的源文档和准确的文本提取是RAG系统性能的基础。确保PDF加载器能够正确解析文档内容。

总结

提升LangChain与ChromaDB RAG系统响应完整性，关键在于精细化文本分割策略和优化检索器配置。通过合理设置RecursiveCharacterTextSplitter的chunk_size和chunk_overlap，并调整vectordb.as_retriever()中的k值，可以确保LLM在生成答案时获得更全面、连贯的上下文信息。在实践中，需要根据具体应用场景进行迭代测试和调优，以在响应质量、性能和成本之间找到最佳平衡点。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~