基于RAG的本地知识库问答系统：从原理到ChatPDF实战部署

1. 项目概述与核心价值

最近在折腾本地知识库问答系统，发现了一个挺有意思的开源项目——ChatPDF。这名字听起来像是专门处理PDF的，但实际上它的能力远不止于此。它是一个基于本地大语言模型（LLM）的检索增强生成（RAG）系统，支持PDF、Word、Markdown、TXT等多种格式的文档。简单来说，你可以把它理解为一个能“读懂”你本地文档，并基于这些文档内容和你进行智能对话的私人AI助手。

我之所以花时间研究它，是因为在很多实际场景下，我们手头有成堆的技术手册、内部文档、研究报告，但想快速找到某个具体问题的答案却非常困难。传统的全文搜索只能匹配关键词，而ChatPDF这类RAG系统，能理解问题的语义，并从文档中精准定位相关信息，生成一个连贯、准确的回答。更关键的是，这个项目主打“本地部署”，这意味着你的文档数据完全不用上传到任何第三方服务器，隐私和安全得到了最大程度的保障。对于处理敏感数据的企业或个人开发者来说，这一点极具吸引力。

这个项目由 shibing624 团队维护，整体架构清晰，不仅实现了基础的RAG流程，还做了一系列针对中文场景和准确率提升的优化。它支持多种开源LLM（如Qwen、DeepSeek）和Embedding模型，甚至集成了更高级的GraphRAG（基于知识图谱的检索）实验性功能。无论你是想快速搭建一个本地知识问答机器人，还是想深入学习RAG技术的工程实现细节，这个项目都是一个非常不错的起点。

2. 核心原理与架构拆解

要玩转ChatPDF，首先得理解RAG（Retrieval-Augmented Generation，检索增强生成）到底是怎么一回事。你可以把它想象成一个拥有超强记忆力和理解力的研究员。当研究员（LLM）被问到一个问题时，他不会凭空捏造答案，而是会先跑去一个庞大的资料库（你的文档集合）里，快速找到最相关的几份资料（检索），然后阅读、理解这些资料（增强），最后组织语言给出答案（生成）。

ChatPDF的整个工作流程，就是对这个过程的工程化实现。其核心架构可以分解为几个关键环节：

文档加载与预处理：这是第一步。系统支持多种格式，背后依赖PyPDF2、python-docx、markdown等库来解析文件，将非结构化的文档内容转化为纯文本。

文本分块（Chunking）：这是影响RAG效果的关键步骤之一。你不能把一整本书扔给模型去检索，那样效率极低。ChatPDF在这里做了优化，特别是针对中英文混合文档。它采用了智能分块策略，比如按段落、按固定字符数（结合语义边界）进行切割，确保每个“块”（Chunk）在语义上是相对完整的，同时又不会过大，以便后续的向量化表示。

向量化与索引（Embedding & Indexing）：预处理后的文本块，需要通过一个Embedding模型转化为计算机能理解的“向量”（一组高维数字）。ChatPDF支持多种Embedding方式，包括调用OpenAI的API、使用本地的text2vec模型、或者Hugging Face上的sentence-transformers模型。这些向量会被存储到一个向量数据库（项目中默认使用Chroma或FAISS）中，建立索引，以便后续快速进行相似度搜索。

检索与重排序（Retrieval & Reranking）：当用户提出一个问题（Query）时，系统首先将问题也转化为向量，然后在向量数据库中进行相似度搜索，找出最相关的N个文本块。为了提高准确率，ChatPDF引入了多重检索策略：

1. 语义检索：基于向量相似度（如余弦相似度），找到语义上最接近的文本块。
2. 字面检索：引入jieba分词和rank_BM25算法，加强了对问题中关键词的字面匹配能力。这对于一些专有名词、产品型号的精确查找特别有效。
3. 混合加权：将语义相似度和字面匹配分数进行加权融合，得到一个更全面的候选集。
4. 重排序（Reranker）：这是进一步提升精度的“杀手锏”。用一个更精细但通常也更小的模型（如bge-reranker），对初步检索到的Top N个候选块进行再次排序，筛选出最相关的前K个。这能有效过滤掉一些语义相关但实际不匹配的“干扰项”。

提示工程与答案生成（Prompting & Generation）：将经过重排序筛选出的最相关文本块，与用户的问题一起，按照预设的提示模板（Prompt Template）组装成一个完整的提示，发送给大语言模型（LLM）。ChatPDF支持本地部署的模型（通过Ollama）、国内大模型API（如DeepSeek）或OpenAI API。LLM会根据“已知信息”（检索到的文本块）来生成最终答案，并在答案中注明引用来源，增强了可信度。

GraphRAG模式：这是项目的进阶功能。不同于传统的基于向量相似度的“平面”检索，GraphRAG会尝试从文档中提取实体（如人物、地点、概念）和关系，构建一个知识图谱。当用户提问时，系统可以在图谱中进行多跳推理，找到更深层、更间接相关的信息。这对于处理复杂、关联性强的文档（如长篇报告、学术论文）有潜在优势，但构建图谱的计算开销也更大。

整个流程通过异步编程实现，支持并发处理多个用户请求，提升了Web服务的响应效率。其架构设计在保证基础功能可用的前提下，为每个环节都预留了扩展和优化的接口，体现了很好的工程性。

3. 环境部署与依赖安装详解

动手实践的第一步是把环境搭起来。ChatPDF是一个Python项目，所以你需要一个Python环境（建议3.8及以上版本）。以下是我在Linux系统（Ubuntu 20.04）上从零开始部署的完整过程，Windows用户强烈建议使用WSL2以获得接近Linux的体验。

3.1 基础环境与CUDA配置

如果你打算用GPU来加速Embedding和LLM推理（这几乎是必须的，否则速度会慢到无法忍受），那么CUDA是前提。我的机器有一张RTX 4090，以下是我的配置步骤：

1. 检查CUDA驱动：在终端运行nvidia-smi，查看驱动版本和CUDA兼容版本。例如，输出显示“CUDA Version: 12.4”，这意味着最高可安装CUDA 12.4的工具包。
2. 安装PyTorch：前往 PyTorch官网 ，根据你的CUDA版本选择安装命令。例如，对于CUDA 12.1，我选择的命令是：

   pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

   这一步非常关键，必须确保PyTorch的CUDA版本与你系统驱动的兼容版本匹配，否则无法调用GPU。
3. 验证GPU可用性：安装后，打开Python解释器，运行：

   import torch print(torch.cuda.is_available()) # 应返回 True print(torch.cuda.get_device_name(0)) # 应显示你的GPU型号

注意：如果你的机器没有NVIDIA GPU，或者不想折腾CUDA，后续可以选择完全使用CPU模式，或者选择调用在线的API（如DeepSeek API）来绕过本地模型推理，但Embedding步骤可能仍然较慢。

3.2 项目依赖安装

克隆项目并安装依赖是标准操作。这里有个小技巧，国内用户直接pip install可能会因为网络问题非常慢甚至失败。

1. 克隆代码：

   git clone https://github.com/shibing624/ChatPDF.git cd ChatPDF

2. 配置pip镜像源：永久修改pip源可以一劳永逸。创建或编辑~/.pip/pip.conf文件（Linux/Mac）或C:\Users\你的用户名\pip\pip.ini文件（Windows），加入以下内容：

   [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

   这样后续所有pip install命令都会从清华镜像站下载，速度飞快。

3. 安装项目依赖：

   pip install -r requirements.txt

   requirements.txt文件定义了项目运行所需的所有Python包，包括gradio（用于Web界面）、chromadb（向量数据库）、sentence-transformers（Embedding模型）、jieba（中文分词）等。

4. 处理可能的依赖冲突：有时候，requirements.txt中的某些包版本可能会与你现有环境或其他包的依赖冲突。如果安装或运行时报错，可以尝试创建独立的Python虚拟环境。

   # 安装虚拟环境工具 pip install virtualenv # 创建名为‘chatpdf_env’的虚拟环境 virtualenv chatpdf_env # 激活虚拟环境 (Linux/Mac) source chatpdf_env/bin/activate # 激活虚拟环境 (Windows) # chatpdf_env\Scripts\activate

   在激活的虚拟环境中，重新执行步骤3安装依赖。这样可以保证环境隔离，避免污染系统Python环境。

3.3 模型下载与配置

ChatPDF的强大之处在于支持多种模型，但模型文件通常很大（几GB到几十GB），需要提前下载或配置。

1. Embedding模型：项目默认或推荐使用text2vec系列的模型，例如shibing624/text2vec-base-chinese。当你第一次运行程序时，它会自动从Hugging Face Hub下载。如果网络不畅，你可以手动下载。

   • 访问 https://huggingface.co/shibing624/text2vec-base-chinese
   • 使用git lfs clone下载所有文件到本地目录，例如./models/text2vec-base-chinese。
   • 在代码或配置中，将模型路径指向这个本地目录，而不是通过名称在线加载。

2. 大语言模型（LLM）：这是核心。你有几种选择：

   • 本地模型（Ollama）：这是最符合“本地部署”精神的方式。你需要先安装 Ollama 。安装后，在终端拉取一个模型，例如强大的Qwen2.5 7B模型：

     ollama pull qwen2.5:7b

     运行后，Ollama会在本地启动一个API服务（默认端口11434）。ChatPDF可以通过配置连接到这个服务。
   • 国内API（DeepSeek）：如果你没有足够的GPU显存运行本地大模型，DeepSeek的API是一个性价比很高的选择。你需要去DeepSeek官网注册账号，获取API Key。然后在运行ChatPDF前，设置环境变量：

     export DEEPSEEK_API_KEY="你的sk-xxx密钥"

   • OpenAI API：如果你有海外资源，也可以使用。同样需要设置环境变量OPENAI_API_KEY。

3. 重排序模型（Reranker）：这是可选项，但强烈建议开启以提升精度。常用的有BAAI/bge-reranker-base或BAAI/bge-reranker-large。同样，你可以从Hugging Face下载到本地，以加速加载并避免网络问题。

完成以上步骤，你的基础环境就准备好了。接下来就是让整个系统跑起来，并理解如何配置它以适应你的具体需求。

4. 核心配置与实战操作指南

环境搭好，模型备齐，现在我们来让ChatPDF真正工作起来。项目的入口主要是两个脚本：rag.py用于命令行交互测试，webui.py用于启动图形化Web服务。但在此之前，我们需要深入了解一下核心配置文件，这是定制化你专属知识库的关键。

4.1 配置文件解析与定制

ChatPDF的核心参数集中在configs/目录下的配置文件中（如configs/model_config.py），或者你可以在运行脚本时通过命令行参数覆盖。理解这些参数，你就能驾驭整个系统。

模型相关配置：

• embedding_model_name_or_path: 指定Embedding模型。例如，设为"shibing624/text2vec-base-chinese"使用在线模型，或设为"/home/user/models/text2vec-base-chinese"使用本地路径。实操心得：对于中文场景，text2vec系列和BAAI/bge系列是经过验证的好选择。如果追求极致速度且文档以中文为主，可以尝试更小的模型，如text2vec-small。
• generate_model_name_or_path: 指定用于生成答案的LLM。格式取决于后端：
  • 对于Ollama：设为"ollama"，并在代码中指定具体的Ollama模型名（如qwen2.5:7b）。
  • 对于API：设为"deepseek-chat"或"gpt-3.5-turbo"，同时确保对应的API密钥环境变量已设置。
• rerank_model_name_or_path: 指定重排序模型。例如"BAAI/bge-reranker-base"。注意事项：开启Reranker会显著增加检索阶段的时间，因为它需要对Top N个候选逐一计算相关性得分，但换来的精度提升通常是值得的，尤其是在候选文档很多、相似度很高时。

检索相关配置：

• chunk_size: 文本分块的大小（字符数）。默认值如512或1024。这是最重要的参数之一。太小会导致上下文碎片化，模型看不到完整信息；太大会降低检索精度，且可能超出模型的上下文窗口。对于技术文档，我通常设置在800-1200之间，并让chunk_overlap（块间重叠字符数）在100-200，以保证语义的连续性。
• top_k: 初次向量检索返回的候选块数量。例如设为10。
• rerank_top_k: 经过重排序后，最终保留并送入LLM的文本块数量。例如设为3或4。LLM的上下文长度有限，这个数不宜过大。
• num_expand_context_chunk: 这是一个很实用的功能。当检索到一个相关块时，系统会自动将其前后相邻的块也一并纳入上下文。例如设为2，那么最终送入LLM的将是“命中块”及其前后各2个块的内容。这有助于模型理解更完整的语境，避免断章取义。
• score_threshold: 相似度得分阈值。低于此阈值的候选块将被直接过滤掉，不参与后续重排序和生成。可以用于初步的质量控制。

运行与硬件配置：

• device: 指定模型运行设备，如"cuda:0"或"cpu"。
• CUDA_VISIBLE_DEVICES: 在命令行中指定使用的GPU编号，如CUDA_VISIBLE_DEVICES=0。

4.2 命令行模式实战

我们先通过命令行脚本rag.py来快速验证流程。这是调试和了解系统内部工作的最佳方式。

1. 准备测试文档：在项目根目录下创建一个docs文件夹，放入你的测试PDF或TXT文件。例如，我放了一份关于“机器学习简介”的PDF。

2. 运行知识库构建与问答：在终端执行以下命令。这里我假设使用Ollama本地模型和本地Embedding模型。

   # 设置环境变量，指定使用第一块GPU export CUDA_VISIBLE_DEVICES=0 # 运行脚本，并指定文档目录和模型 python rag.py \ --file_path ./docs \ --embedding_model /path/to/your/text2vec-model \ --generate_model ollama \ --ollama_model_name qwen2.5:7b \ --rerank_model /path/to/your/bge-reranker \ --top_k 10 \ --rerank_top_k 3 \ --chunk_size 1024 \ --chunk_overlap 200

   程序首先会加载并解析./docs下的所有文档，进行分块、向量化，并构建向量数据库索引。这个过程可能会花费一些时间，取决于文档数量和大小。完成后，会进入一个交互式命令行界面。

3. 进行问答测试：在交互界面中，你可以直接输入问题。

   请输入您的问题 (输入‘exit’退出): 什么是监督学习？

   程序会展示检索到的相关文本块（带来源和相似度分数），以及LLM生成的最终答案。输出会清晰地分为“已知信息”和“回答”两部分，答案中还会引用相关块的编号，非常直观。

踩坑记录：第一次运行时，可能会遇到transformers库的某个模型找不到对应的tokenizer.json文件的错误。这通常是因为Hugging Face模型缓存不完整或网络问题。解决方法就是如前所述，手动将整个模型文件夹（包含config.json,pytorch_model.bin,tokenizer.json等所有文件）下载到本地，然后在配置中指定这个本地文件夹的绝对路径。

4.3 启动Web图形界面

命令行测试通过后，就可以启动更友好的Web界面了。webui.py基于Gradio库，能快速搭建一个带有文件上传、对话历史等功能的界面。

1. 启动服务：

   python webui.py

   默认情况下，服务会运行在http://localhost:8082。你可以通过--server_port参数修改端口。

2. 界面功能详解：打开浏览器访问上述地址，你会看到一个简洁的界面，通常包含以下区域：

   • 文件上传区：可以拖拽或点击上传PDF、DOCX等文件。上传后，点击“加载文档”或类似按钮，后台会开始处理并构建索引。
   • 对话历史区：显示当前会话的问答历史。
   • 问题输入区：输入你的问题。
   • 参数调整区（可能折叠）：高级用户可以通过这里实时调整top_k、chunk_size等参数，无需重启服务。
   • 回答显示区：流式显示模型生成的答案，并高亮或列出引用的文档片段。

3. 多文档管理与会话：一个很实用的特性是，Web界面通常支持在同一个会话中加载多个文档，系统会将所有文档内容统一构建到一个索引中，实现跨文档的知识问答。你可以通过“新建会话”或“清空历史”来开始一轮全新的对话。

性能调优建议：

• 首次加载慢：首次启动或加载新文档时，需要下载模型和进行向量化，耗时较长。耐心等待即可，后续问答会很快。
• GPU内存不足：如果同时加载Embedding模型、Reranker模型和大语言模型，对GPU显存要求很高。可以尝试：
  • 使用量化版本的LLM（如通过Ollama运行qwen2.5:7b-q4_K_M）。
  • 将Embedding或Reranker模型切换到CPU（在配置中设置device='cpu'），但这会降低速度。
  • 升级硬件或使用API方案。
• 回答速度慢：除了模型本身推理速度，检索阶段的top_k和是否开启rerank对延迟影响很大。在精度可接受的前提下，适当调小这些值。

5. 高级功能：GraphRAG探索与集成

ChatPDF项目还提供了一个graphrag_demo.py，展示了GraphRAG的初步集成。GraphRAG与传统RAG的核心区别在于信息组织方式：从“扁平的”向量列表，升级为“图结构的”知识网络。

GraphRAG的基本流程：

1. 实体与关系抽取：使用LLM或专用模型，从文档中提取出实体（如“Transformer模型”、“注意力机制”、“Google”）和关系（如“提出于”、“基于”、“由...开发”）。
2. 知识图谱构建：将抽取出的实体和关系存储为图数据库中的节点和边，形成一个结构化的知识网络。
3. 图检索：当用户提问时，系统首先理解问题中的核心实体，然后在知识图谱中进行遍历和查询。例如，问题“注意力机制是谁提出的？”，系统会找到“注意力机制”这个节点，然后查找“提出”这条边所连接的实体节点，从而得到答案。
4. 答案生成：将检索到的子图信息（可能包含多跳关系）作为上下文，送给LLM生成最终答案。

运行GraphRAG示例： 根据项目README，运行前需要设置OpenAI API Key（因为示例中可能默认调用了GPT-4进行实体关系抽取）。如果你没有，可以查看graphrag/_model.py文件，将其修改为使用本地Ollama模型。

export OPENAI_API_KEY="sk-..." # 如果使用OpenAI python graphrag_demo.py

这个示例会更复杂，可能会输出构建的图谱结构，并演示基于图谱的问答。

GraphRAG的优缺点分析：

• 优点：
  • 深度推理：能回答涉及多步关系、需要推理的问题。例如，“文档中提到的A公司的产品，使用了哪所大学的研究成果？”传统RAG可能难以直接找到关联，而GraphRAG可以通过“A公司产品->基于->B技术->由->C大学研发”这条路径找到答案。
  • 可解释性更强：答案的推导路径在图谱上是可视化的，更容易追溯和验证。
  • 结构化查询：支持更复杂的查询，如“找出所有与‘碳中和’相关，并且由‘中国’提出的‘政策’实体”。
• 缺点与挑战：
  • 构建成本高：实体关系抽取的准确性直接影响图谱质量，且构建过程计算量大、耗时。
  • 覆盖面可能不全：图谱只包含了被抽取出的实体和关系，一些未被抽取的文本细节会丢失。
  • 工程复杂度高：需要维护图数据库，检索算法也更复杂。

当前定位：在ChatPDF项目中，GraphRAG更像是一个实验性的、前瞻性的功能。对于大多数文档问答场景，尤其是文档结构清晰、问题直接的场景，经过优化的传统RAG（结合了语义、字面匹配和重排序）已经能提供非常出色的效果，且更稳定、高效。GraphRAG更适合作为对复杂分析型需求的补充探索。

6. 效果优化与避坑实战经验

部署和运行只是第一步，要让ChatPDF在实际应用中真正“好用”，还需要一系列的调优和问题排查。以下是我在多次实践中总结出的核心经验和常见问题的解决方法。

6.1 提升问答准确率的“组合拳”

RAG的准确率 = 检索精度 * 生成质量。两者缺一不可。

检索精度优化：

1. 分块策略是根基：如果分块不合理，后续再强的模型也无力回天。对于技术文档，可以尝试按“章节标题”或“子章节”进行分块，而不是简单的固定字符数。ChatPDF支持自定义分块函数，你可以根据文档的HTML标签或Markdown标题级别来切分。
2. Embedding模型选型：对于中文，text2vec-base-chinese和BAAI/bge-large-zh都是顶级选择。如果想进一步压缩体积和提升速度，可以尝试它们的量化版本或更小的变体（如bge-small-zh），并在你的业务数据上做一个简单的相似度匹配测试，选择表现最好的。
3. 混合检索与权重调整：务必开启字面匹配（BM25）。对于包含精确术语、代码、型号的问题，BM25的效果往往比纯语义检索更好。在configs中调整similarity_score_weight（语义权重）和keyword_score_weight（字面权重）的比例，例如从默认的0.7:0.3调整为0.5:0.5，观察效果变化。
4. 重排序模型的威力：不要省略Reranker。即使它增加了100-200毫秒的延迟，但将送入LLM的垃圾信息过滤掉，能极大提升最终答案的质量和可靠性。BAAI/bge-reranker-base是一个不错的起点。
5. 上下文扩展的妙用：合理设置num_expand_context_chunk（如2或3）。这相当于给模型提供了更宽的“阅读视野”，能有效避免因分块割裂导致的上下文缺失问题。

生成质量优化：

1. 提示词工程：ChatPDF内置的提示模板已经不错，但你可以根据你的文档类型微调。例如，对于法律文档，可以在提示词中强调“严格依据已知信息，不得自行发挥”；对于创意写作，则可以鼓励“在已知信息的基础上进行合理的拓展”。修改prompts目录下的模板文件即可。
2. LLM模型的选择：本地部署下，Qwen2.5-7B、Qwen2.5-14B都是综合能力很强的选择。如果使用API，GPT-4、DeepSeek-V3的生成质量通常更高。一个关键技巧：在提示词中明确要求模型“如果已知信息中没有足够依据，就回答‘根据已知信息无法回答该问题’”，这能有效减少模型“胡编乱造”（幻觉）的情况。
3. 温度参数：在生成答案时，将温度（Temperature）调低（如0.1或0.2），可以使模型的输出更加确定和聚焦于检索到的内容，减少随机性和废话。

6.2 常见问题与排查指南

在实际运行中，你可能会遇到以下问题：

问题一：程序报错ModuleNotFoundError: No module named ‘chromadb’或类似错误。

• 原因：依赖未正确安装，或者虚拟环境未激活。
• 解决：
  1. 确认已进入项目目录。
  2. 激活你的虚拟环境：source your_env/bin/activate。
  3. 重新安装依赖：pip install -r requirements.txt。
  4. 如果某个包安装失败，尝试单独安装：pip install chromadb。

问题二：加载模型时卡住或报网络错误。

• 原因：从Hugging Face下载模型网络超时。
• 解决：
  1. 最佳实践：如前所述，提前将所需模型（Embedding, Reranker）下载到本地硬盘。
  2. 在代码或配置中，将所有model_name_or_path的参数从在线名称（如"BAAI/bge-reranker-base"）改为本地绝对路径（如"/home/models/bge-reranker-base"）。
  3. 对于LLM，如果使用Ollama，确保模型已通过ollama pull拉取到本地。

问题三：问答时，答案明显与文档无关，或出现“幻觉”。

• 原因：检索阶段没有找到真正相关的内容，LLM只能基于无关上下文或自身知识生成。
• 排查步骤：
  1. 检查检索结果：在rag.py命令行模式下，观察系统输出的“已知内容”部分。看看它到底检索到了什么。如果检索到的内容完全不相关，问题出在检索环节。
  2. 调整检索参数：尝试增大top_k（例如从10到20），让更多候选进入重排序环节。检查score_threshold是否设得过高，过滤掉了有用的低分内容（可以暂时设为0关闭过滤）。
  3. 优化分块：如果文档是长段落，尝试减小chunk_size（如从1024降到512）。如果文档是短句列表（如QA对），尝试增大chunk_size或改变分块逻辑。
  4. 检查Embedding模型：确保使用的Embedding模型与你的文档语言（中/英）匹配。用中文模型处理英文文档效果会打折扣。
  5. 开启重排序：确保rerank_model_name_or_path已正确设置，并且rerank_top_k大于0。

问题四：回答速度非常慢。

• 原因：可能是模型加载在CPU上，或者检索参数设置过大。
• 解决：
  1. 确认device参数设置为"cuda"。
  2. 在终端使用nvidia-smi命令查看GPU是否被占用，利用率如何。
  3. 调低top_k（如从10降到5）和rerank_top_k（如从4降到2）。
  4. 如果使用本地LLM，考虑换用更小的量化模型（如7B的int4量化版）。

问题五：处理大量文档时，内存或显存不足。

• 原因：向量索引和模型同时加载，占用大量资源。
• 解决：
  1. 索引持久化：ChatPDF通常会在运行目录下生成向量数据库的持久化文件（如chroma.sqlite3和chroma-embeddings目录）。首次构建索引后，后续运行可以直接加载，无需重新向量化。确保你没有每次运行都删除这些文件。
  2. 分批处理：如果文档总量极大，可以考虑将其分成多个子集，分别构建索引，然后通过一个路由机制来查询对应的索引。
  3. 使用更高效的向量库：可以尝试将后端从Chroma切换到FAISS，FAISS在处理大规模向量搜索时，特别是在GPU上，效率可能更高。这通常需要修改项目中的向量库初始化代码。

经过以上步骤的精心调优和问题排查，你的ChatPDF系统应该能够稳定、准确、高效地运行，成为你处理本地文档的得力助手。这个项目就像一个功能强大的工具箱，提供了丰富的组件和接口，剩下的就是根据你的具体数据和需求，去组合和打磨这些工具，构建出最适合你的那个知识问答系统。