使用Langchain-Chatchat实现PDF、TXT、Word文档智能问答

使用Langchain-Chatchat实现PDF、TXT、Word文档智能问答

在企业知识管理日益复杂的今天，一个常见的痛点是：新员工入职后想了解“年假如何申请”，却要在十几个分散的PDF和Word文件中反复翻找；医生查阅最新诊疗指南时，面对上百页文献无从下手；客服人员回答客户问题，常常因为无法访问内部技术手册而束手无策。这些问题背后，其实是非结构化文档与高效信息获取之间的巨大鸿沟。

传统的关键词搜索早已力不从心——它看不懂“休假流程”和“年假规定”其实是同一类问题。而直接调用大模型又容易“一本正经胡说八道”，给出看似合理但毫无依据的答案。有没有一种方式，既能理解语义，又能确保答案有据可依？这正是Langchain-Chatchat这类本地化知识库问答系统崛起的核心驱动力。

这个由中文社区主导开发的开源项目，如今已被誉为“国产私有知识库问答的标杆”。它不像云端AI那样把数据传到远方服务器，而是将整个智能问答链条部署在企业内网中，真正实现了“数据不出门、安全有保障”。

从一份PDF说起：智能问答是如何炼成的？

设想这样一个场景：你上传了一份公司《员工手册》PDF，然后问：“哺乳期女职工每天可以享受多长的哺乳时间？” 系统几秒后返回答案，并附上原文出处。这个过程看似简单，实则经历了一场精密协作的技术旅程。

首先，系统会通过PyPDF2或Unstructured工具将PDF中的文字提取出来。接着，这段长达数万字的内容会被切分成一个个小块（chunk），比如每500个字符一段，且前后重叠100字符以避免语义断裂。这些文本块随后被送入像BGE-small-zh-v1.5这样的中文嵌入模型，转化为768维的向量数字——你可以把它想象成每个段落的“数字指纹”。

这些指纹被批量存入FAISS向量数据库，建立起高效的索引结构。当你提问时，你的问题也会被同样的模型编码成向量，系统就在数据库里快速找出最相似的3~5个段落作为上下文。最后，这些相关段落连同问题一起组成提示词（Prompt），输入给本地部署的大模型如ChatGLM3-6B或Qwen-7B，生成自然语言回答。

整个流程遵循的是当前主流的检索增强生成（RAG）架构。它的精妙之处在于：既利用了大模型强大的语言组织能力，又通过外部知识库为其提供了事实依据，有效遏制了“幻觉”现象。

from langchain.document_loaders import UnstructuredFileLoader 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 HuggingFacePipeline # 1. 加载文档 loader = UnstructuredFileLoader("knowledge_base/sample.pdf") documents = loader.load() # 2. 文本分块 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_documents(documents) # 3. 初始化嵌入模型（以BGE为例） embeddings = HuggingFaceEmbeddings(model_name="bge-small-zh-v1.5") # 4. 构建向量数据库 vectorstore = FAISS.from_documents(texts, embeddings) # 5. 加载本地大模型（示例使用HuggingFace格式的ChatGLM3） llm = HuggingFacePipeline.from_model_id( model_id="THUDM/chatglm3-6b", task="text-generation", device=0 # GPU编号 ) # 6. 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 7. 执行查询 query = "这份文档的主要内容是什么？" result = qa_chain({"query": query}) print("答案:", result["result"]) print("来源文档:", result["source_documents"])

这段代码虽然简洁，但它浓缩了整个系统的灵魂。值得注意的是，尽管 Langchain-Chatchat 已封装为完整应用，其底层仍高度依赖 LangChain 提供的模块化抽象。这种设计让开发者无需重复造轮子，也使得模型替换变得异常灵活——你想换 M3E 做嵌入？改一行配置就行；想试试通义千问而不是 ChatGLM？只要支持 HuggingFace 接口即可接入。

LangChain：不只是胶水框架

很多人误以为 LangChain 只是一个“拼接组件”的工具，其实不然。它的真正价值在于对复杂 AI 应用的工程化抽象。

试想一下，如果没有 LangChain，你要手动处理文档加载、分词逻辑、向量计算、数据库交互、提示词构造、模型调用、错误重试……每一个环节都可能因模型或库的版本差异而崩溃。而 LangChain 通过统一接口屏蔽了这些细节。无论是 OpenAI 还是本地部署的百川模型，调用方式几乎一致。

更重要的是，它支持链式编程（Chains）。例如RetrievalQA链本质上是一个“先检索、后生成”的复合操作。你还可以构建更复杂的逻辑，比如加入条件判断：如果检索不到相关内容，则触发默认回复；或者串联多个工具，形成 Agent 自主决策流。

from langchain.prompts import PromptTemplate prompt_template = """ 你是一个专业的问答助手，请根据以下上下文回答问题。 如果无法从中得到答案，请说“我不知道”。 上下文： {context} 问题： {question} 答案： """ PROMPT = PromptTemplate(template=prompt_template, input_variables=["context", "question"]) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(), chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True )

上面这段自定义提示模板就是一个典型例子。通过明确指令“根据上下文作答”“不知道就说我不知道”，我们可以显著降低模型编造答案的概率。这种细粒度控制能力，正是高质量问答系统不可或缺的一环。

向量检索：让机器真正“理解”语义

传统搜索引擎靠的是关键词匹配。你搜“肺癌治疗”，它就去找包含这两个词的文档。但如果你问“肺部恶性肿瘤该怎么治？”，很可能一无所获——尽管意思完全一样。

而基于向量的语义检索打破了这一局限。它的核心是嵌入模型（Embedding Model），比如 BGE 或 M3E。这类模型经过大量中文语料训练，能将语义相近的句子映射到向量空间中相近的位置。于是，“肺癌治疗方案”和“肺部恶性肿瘤的治疗方法”即使用词不同，它们的向量距离也很近。

实际部署中，有几个关键参数直接影响效果：

• 分块大小（chunk size）：太大会混入无关内容，太小则丢失上下文。实践中 500~800 字符较为平衡；
• 重叠长度（overlap）：设置 50~100 字符的滑动窗口，防止一句话被硬生生切断；
• Top-K 检索数量：通常取 3~5 个最相关段落，足够支撑生成又不至于拖慢响应；
• 相似度阈值：低于 0.6 的结果可视为噪声，直接过滤，避免干扰模型判断。

FAISS 作为 Facebook 开源的向量检索库，在这方面表现尤为出色。它支持 GPU 加速和量化压缩，即使百万级向量也能做到毫秒级响应。相比 Elasticsearch + 插件的重型方案，FAISS 更轻量，更适合中小企业甚至单机部署。

不过也要注意陷阱：不要用仅在英文上训练的嵌入模型（如 OpenAI 的 Ada-002）来处理中文文档，否则语义表达能力会大打折扣。优先选择专为中文优化的模型，如 BGE-ZH、M3E 或智谱的text2vec系列。

落地实践：不只是技术选型，更是架构思维

一个能真正用起来的系统，光有算法还不够。Langchain-Chatchat 的典型部署架构清晰地体现了这一点：

+------------------+ +---------------------+ | 用户终端 |<--->| Web UI (Gradio) | +------------------+ +----------+----------+ | +--------------v---------------+ | 问答服务主程序 (FastAPI) | +--------------+---------------+ | +-----------------------v------------------------+ | LangChain 核心引擎 | | - Document Loaders - Text Splitters | | - Prompt Templates - Chains (RetrievalQA) | +-----------------------+-------------------------+ | +-----------------------v-------------------------+ | 本地模型与数据存储层 | | - LLM (e.g., ChatGLM3) | | - Embedding Model (e.g., BGE) | | - Vector DB (e.g., FAISS) → 存储路径: ./vector_db | +---------------------------------------------------+

所有组件运行在同一台高性能主机上，推荐配置包括 RTX 3090/4090 显卡（24GB 显存）、32GB 内存和 1TB SSD。这样的硬件足以支撑中小规模企业的日常使用。

但在真实环境中，还需考虑更多工程细节：

• 知识库更新机制：新增文档后必须重新构建索引，否则查不到。可以设置定时任务每日同步共享盘资料；
• 性能优化：对高频问题启用 Redis 缓存；使用 GGUF 量化模型减少显存占用；
• 安全性加固：限制上传类型防止脚本注入；添加 JWT 认证控制访问权限；
• 可维护性设计：提供可视化界面管理文档增删，输出检索日志用于审计分析。

曾有客户反馈初期频繁出现“未找到相关文档”的情况。排查发现是因为分块策略过于激进，导致关键信息被割裂。调整为按段落边界切分并增加重叠长度后，召回率明显提升。这说明：再先进的模型，也需要合理的数据预处理配合。

当每个组织都拥有自己的“AI大脑”

Langchain-Chatchat 的意义远不止于技术实现。它代表了一种新的可能性：让每个组织都能构建专属的智能知识中枢。

在金融行业，合规专员可以随时查询最新监管政策；医院里，医生能快速定位某药物的禁忌症说明；教育机构中，教师可通过自然语言检索历年教学案例。这一切都不需要联网，也不必担心敏感数据外泄。

相比调用百度文心一言或阿里云通义千问等云端API，本地部署的优势显而易见：

维度	云端API	Langchain-Chatchat（本地）
数据安全	数据上传至第三方	完全本地处理，零泄露风险
成本	按调用量计费，长期昂贵	一次性投入，后期仅耗电
定制性	接口受限	可深度定制解析、排序、生成逻辑
中文支持	良好	更优（专为中文优化的模型与分词）
离线能力	必须联网	支持完全断网运行

更重要的是，这种模式赋予了企业真正的自主权。你可以根据业务特点微调提示词、更换更适合领域知识的嵌入模型、甚至接入专业数据库作为补充知识源。这不是简单的“拿来主义”，而是一条可持续演进的智能化路径。

当我们在谈论AI落地时，往往忽略了最重要的一点：技术必须服务于具体场景，而不是反过来让人去适应技术。Langchain-Chatchat 正是以极低的使用门槛，将前沿的大模型能力转化为了实实在在的生产力工具。它的成功也印证了一个趋势：未来的智能系统，不再是少数巨头的专利，而是每一个组织都可以拥有的“数字员工”。

这种高度集成且开放的设计思路，正在引领企业级AI应用向更安全、更可控、更高效的方向演进。