Langchain-Chatchat部署教程：从零搭建支持PDF、TXT、Word的AI问答系统

从零搭建支持PDF、TXT、Word的AI问答系统：Langchain-Chatchat实战部署

在企业知识管理日益复杂的今天，员工查找一份制度文件可能要翻遍多个共享文件夹；客服面对客户提问，常常需要手动查阅厚厚的产品手册。尽管通用大模型已经能流畅对话，但它们对私有文档“视而不见”，更别提保障敏感信息不外泄了。

有没有一种方案，能让AI真正读懂你上传的每一份PDF合同、Word报告和TXT日志，并基于这些内容准确作答？答案是肯定的——Langchain-Chatchat正是为此而生。它不是一个简单的聊天机器人，而是一套完整的本地化知识库问答系统，能够将你的文档变成AI可理解的知识源，在完全离线的环境中提供智能服务。

这套系统的魔力在哪？简单来说：你丢进去一堆公司内部资料，然后问“年假怎么申请？”、“项目验收标准是什么？”，它就能像老员工一样精准告诉你答案出处。更重要的是，所有数据都留在你自己的服务器上，不会上传到任何第三方平台。

要实现这样的能力，背后其实是三大核心技术的协同作战：LangChain 框架负责流程调度，大型语言模型（LLM）担当推理引擎，向量数据库则充当记忆中枢。接下来我们就拆开来看，这个系统到底是怎么跑起来的。

先看最核心的部分——LangChain。你可以把它想象成一个智能指挥官，把文档加载、文本切片、语义编码、检索匹配和回答生成这些任务串联成一条自动化流水线。它的设计理念很清晰：把大模型当作计算图中的一个节点，而不是唯一主角。

整个问答流程其实非常直观：
1. 用户输入问题；
2. 系统用相同的嵌入模型将问题转为向量；
3. 在向量库中找出与该向量最相似的几个文档片段；
4. 把问题和这些“相关段落”拼成一段提示词（Prompt），喂给本地部署的大模型；
5. 模型结合上下文生成回答，返回结果。

这正是当前最主流的RAG（Retrieval-Augmented Generation，检索增强生成）架构。相比于让模型凭空“编造”答案，RAG 让每一次回复都有据可依，极大提升了事实准确性。

LangChain 的强大之处在于其模块化设计。比如文档加载器（Document Loaders），它支持几十种格式，无论是 PDF、DOCX 还是网页 HTML，都能统一转化为纯文本处理。再比如文本分割器（Text Splitter），由于大多数语言模型有上下文长度限制（如 2048 token），我们必须把长文档切成小块。常用的RecursiveCharacterTextSplitter会按字符递归切分，同时保留一定的重叠部分（chunk_overlap），防止一句话被硬生生截断。

下面这段代码就展示了如何用 LangChain 快速搭建一个基础问答链：

from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from langchain.chains import RetrievalQA from langchain.llms import CTransformers # 1. 加载并解析 PDF loader = PyPDFLoader("company_policy.pdf") docs = loader.load() # 2. 文本分块（建议中文使用较小 chunk_size） text_splitter = RecursiveCharacterTextSplitter( chunk_size=400, # 中文建议 300~500 chunk_overlap=50 # 避免语义断裂 ) texts = text_splitter.split_documents(docs) # 3. 使用中文嵌入模型（关键！） embeddings = HuggingFaceEmbeddings( model_name="shibing624/text2vec-base-chinese" ) # 4. 构建本地向量库 db = FAISS.from_documents(texts, embeddings) # 5. 加载轻量化本地 LLM（适合消费级 GPU） llm = CTransformers( model="models/llama-2-7b-chat.Q4_K_M.gguf", model_type="llama", config={ "max_new_tokens": 512, "temperature": 0.3, "context_length": 2048 } ) # 6. 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=db.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 7. 开始提问 query = "员工生育津贴如何申领？" response = qa_chain(query) print("回答:", response["result"]) print("来源页码:", [doc.metadata.get("page", "未知") for doc in response["source_documents"]])

这里有几个工程实践中容易踩坑的地方值得强调：

• 嵌入模型必须匹配语言场景：如果你处理的是中文文档，千万别直接用英文的all-MiniLM-L6-v2。推荐使用专门训练的中文模型，如text2vec-base-chinese或paraphrase-multilingual-MiniLM-L12-v2，否则检索效果会大打折扣。

• chunk_size 要合理设置：太大会导致检索不精确，太小又可能丢失上下文。对于中文，我们通常设为 300~500 字符，配合 50~100 的 overlap，既能保证语义完整，又能提高召回率。

• chain_type 的选择影响性能与质量：stuff是最简单的模式，把所有检索结果拼接后一次性输入模型；如果文档较长，可以考虑map_reduce，先对每个片段分别生成局部答案，最后汇总。虽然更耗时，但更适合复杂问题。

说到模型本身，LLM 在这套系统中并不是靠记忆回答问题，而是作为一个“上下文感知”的生成器。它并不需要事先学过你的公司制度，只要在推理时看到相关内容，就能据此组织语言输出。这也是为什么我们可以在本地运行一个参数量适中的模型（如 7B 级别的 LLaMA 或 ChatGLM），依然获得高质量的回答。

目前主流的开源模型中，Qwen、ChatGLM3、Baichuan2 和 LLaMA2都是不错的选择。如果你的设备资源有限，建议使用 GGUF 格式的量化模型（通过 llama.cpp 加载），这样即使没有高端 GPU，也能在 CPU 上流畅运行。

例如上面代码中的CTransformers就是基于llama.cpp的 Python 接口，支持多种量化等级（如 Q4_K_M）。这种低精度版本虽然略有性能损失，但在问答这类任务中几乎不影响实际体验，却能将显存占用降低一半以上。

至于向量数据库，为什么大家都爱用FAISS？

因为它足够轻量、足够快。Facebook 开发的这个库专为高效相似性搜索设计，支持 IVF、HNSW 等近似最近邻算法（ANN），能在百万级向量中实现毫秒级响应。而且它是纯本地运行的，不需要额外部署服务，非常适合中小企业或个人开发者快速上线。

相比之下，传统关键词检索工具（如 Elasticsearch）只能做字面匹配，遇到同义词或表述差异就束手无策。而 FAISS 基于语义向量进行匹配，哪怕用户问“报销流程”，系统也能找到标题写着“费用结算操作指南”的文档。

我们可以稍微深入一点看看 FAISS 的工作原理：

import faiss import numpy as np from langchain.embeddings import HuggingFaceEmbeddings # 初始化中文嵌入模型 embedding_model = HuggingFaceEmbeddings(model_name="shibing624/text2vec-base-chinese") # 假设 texts 是已经分好的文本块列表 text_contents = [t.page_content for t in texts] text_vectors = np.array(embedding_model.embed_documents(text_contents)) # 创建 FAISS 索引（使用 L2 距离） dimension = text_vectors.shape[1] index = faiss.IndexFlatL2(dimension) index.add(text_vectors) # 查询示例 query = "差旅费标准是多少？" query_vector = np.array([embedding_model.embed_query(query)]) D, I = index.search(query_vector, k=3) # 返回 Top-3 相似结果 for idx in I[0]: print(f"匹配内容: {texts[idx].page_content[:100]}...")

虽然 LangChain 已经封装了大部分细节，但了解底层机制有助于后续优化。比如当数据量超过十万条时，应改用IndexIVFFlat或IndexHNSW来提升检索速度；若内存紧张，还可以启用乘积量化（PQ）压缩存储。

整个系统的典型架构如下：

+------------------+ +--------------------+ | 用户界面 |<----->| LangChain 框架 | | (Web/API/CLI) | | - Document Loader | +------------------+ | - Text Splitter | | - Embedding Client | | - Vector Store (FAISS)| | - LLM Interface | +----------+-----------+ | +---------------v------------------+ | 外部资源 | | - 私有文档库 (PDF/TXT/DOCX) | | - 本地 LLM 模型 (GGUF/GGML) | | - 嵌入模型 (Sentence-BERT) | +----------------------------------+

部署方式也非常灵活：可以直接在单机运行，也可以用 Docker 容器化打包。前端可以用 Streamlit 快速搭个 Web 页面，或者通过 FastAPI 暴露 REST 接口供其他系统调用。

在实际应用中，这套系统解决了不少企业痛点：

• 打破知识孤岛：把散落在各个部门的非结构化文档集中索引，新人入职再也不用到处问人。
• 规避数据风险：财务报表、客户合同等敏感资料无需上传云端，彻底杜绝泄露隐患。
• 统一回答口径：每次回答都能附带原文引用，避免不同员工解释不一。
• 降低培训成本：自助式查询替代大量重复答疑，HR 和 IT 支持压力显著减轻。

当然，要想长期稳定运行，还需要一些运维层面的设计考量：

1. 支持增量更新：不要每次新增文件就重建整个索引。可以通过记录文件哈希值判断是否变更，仅对新/改文件重新处理。
2. 元数据标注：除了页码，还可以加入文档名称、创建时间、所属部门等字段，便于过滤检索范围。
3. 硬件配置建议：
   - 若本地运行 LLM，至少配备 8GB 显存（如 RTX 3070）；
   - 向量库建议部署在 SSD 上，提升 IO 效率；
   - 内存建议 16GB 以上，避免大文件处理时崩溃。
4. 定期评估效果：可通过人工抽检或构建测试集来衡量召回率（Recall@K）和回答准确率，持续优化参数。

Langchain-Chatchat 的价值远不止于技术演示。它代表了一种新的可能性：让大模型真正服务于你自己的数据，而不是让你去适应大模型的知识边界。未来随着小型化模型不断进步，这类本地化 AI 助手将在更多场景落地——从法律文书辅助审查，到医疗文献智能检索，再到教育领域的个性化答疑。

这种高度集成且安全可控的设计思路，正在引领企业智能化转型的新方向。