用Langchain-Chatchat将PDF、Word转为可问答的知识库

用Langchain-Chatchat将PDF、Word转为可问答的知识库

在企业日常运营中，知识散落在成百上千份合同、制度文档和产品手册里，员工常常为了查一条年假政策翻遍整个共享文件夹。更糟的是，当新员工提问“我们和某供应商的付款周期是多久？”时，没人能立刻给出准确答案——不是没有记录，而是信息太难找。

这正是智能知识库要解决的问题。与其让用户去“搜索”文档，不如让系统直接“回答”问题。而 Langchain-Chatchat 正是这样一套能让 PDF、Word 自动变身 AI 助手的技术方案。它不依赖云端服务，所有处理都在本地完成，特别适合对数据安全敏感的金融、医疗或政企单位。

这套系统的核心思路并不复杂：先把文档拆解成小段落，用嵌入模型（Embedding）把每一段变成一个高维向量，存进向量数据库；当你提问时，系统会把你的话也转成向量，在数据库里找出最相关的几段文字，再交给本地大模型生成自然语言回答。整个过程就像给一堆纸质档案装上了会思考的大脑。

比如你上传了一份《劳动合同范本》，然后问：“试用期最长可以约定几个月？”系统不会返回整页内容，而是精准提取出“劳动合同期限三个月以上不满一年的，试用期不得超过一个月……”这一条，并组织成通顺的回答。更重要的是，它还能告诉你这句话来自哪份文件、第几页，方便溯源验证。

实现这个功能的关键在于几个技术模块的协同工作。首先是文档解析能力。Langchain-Chatchat 支持.txt、.pdf、.docx、.md等多种格式，背后整合了PyPDF2、python-docx、pandoc等开源工具。对于扫描版 PDF，还可以启用 OCR 功能识别图像中的文字，确保信息不遗漏。

拿到原始文本后，不能直接丢给模型——长文档需要切分成语义完整的“文本块”（chunk）。如果切得太碎，上下文就断了；切得太大，又会影响检索精度。实践中通常设置chunk_size=500~800tokens，重叠部分保留50~100tokens，这样既能保持句子完整性，又能避免关键信息被截断。例如一段关于报销流程的文字，应该完整保留在一个块中，而不是被拆到两处。

接下来是向量化环节。系统使用如 BGE 或 text2vec 这类中文优化的嵌入模型，将每个文本块编码为向量。这些向量不是随机数字，而是承载着语义的空间坐标——意思相近的句子在向量空间中距离更近。比如“离职需提前30天申请”和“辞职要提前三十日通知”，虽然用词不同，但向量位置非常接近。

这些向量会被存入 FAISS 或 ChromaDB 这样的本地向量数据库。FAISS 是 Facebook 开发的高效相似性搜索库，支持 HNSW 算法，在百万级数据下检索延迟也能控制在 50ms 以内。你可以把它想象成一本按“意思”排序的索引书：不再按关键词字母排列，而是按照语义相关性组织。

当用户提出问题时，系统首先将问题本身向量化，然后在向量库中查找最相似的 Top-K 文本块作为上下文。假设你问“项目立项需要哪些材料？”，系统可能找到三段相关内容：一份立项审批表模板说明、一个内部流程图描述、以及财务部发布的预算编制指南节选。

最后一步是答案生成。这些检索到的上下文会被拼接成 Prompt，输入到本地部署的大语言模型中，比如 ChatGLM3、Qwen 或 Baichuan。这类模型不需要联网调用 API，完全运行在你的服务器或笔记本上，真正实现数据不出内网。生成的答案不仅流畅自然，还会附带引用来源，增强可信度。

from langchain_community.document_loaders import PyPDFLoader, Docx2txtLoader 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 ChatGLM # 1. 加载文档 loader_pdf = PyPDFLoader("example.pdf") loader_docx = Docx2txtLoader("example.docx") documents = loader_pdf.load() + loader_docx.load() # 2. 文本分块 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_documents(documents) # 3. 初始化嵌入模型并构建向量库 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = FAISS.from_documents(texts, embeddings) # 4. 初始化本地大模型（假设已启动 API 服务） llm = ChatGLM( endpoint_url="http://127.0.0.1:8000", model_kwargs={"temperature": 0.7} ) # 5. 构建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 6. 执行查询 query = "这份合同的主要履约条款是什么？" result = qa_chain.invoke({"query": query}) print("答案:", result["result"]) print("来源:", [doc.metadata for doc in result["source_documents"]])

上面这段代码虽然简洁，却完整体现了整个 RAG（检索增强生成）流程。其中RecursiveCharacterTextSplitter按段落、句子优先进行递归切分，比简单按字符数切割更能保留语义结构。HuggingFaceEmbeddings调用的是本地下载的 BGE 中文小模型，体积轻量且效果出色。而RetrievalQA则封装了从检索到生成的全过程，开发者无需手动拼接提示词。

这一切都建立在 LangChain 框架的强大抽象之上。LangChain 并不是一个具体的产品，而是一套用于构建 LLM 应用的“乐高积木”。它把文档加载、文本分割、向量存储、模型调用等功能都标准化为可插拔模块。你在 Langchain-Chatchat 中看到的一切，本质上都是 LangChain 组件的组合与封装。

它的价值在于大幅降低了开发门槛。以前你要自己写代码对接不同的模型接口、处理各种文档格式、管理提示词模板；现在只需要几行配置就能完成集成。而且它支持异步调用、回调监控、性能追踪等高级特性。例如通过CallbackHandler，你可以实时查看每个环节的耗时和资源消耗，快速定位瓶颈。

典型的部署架构通常是这样的：

+------------------+ +---------------------+ | 用户界面 |<----->| FastAPI 后端服务 | | (Web UI / API) | | (langchain-chatchat)| +------------------+ +----------+----------+ | +-------------v-------------+ | 文档处理流水线 | | - 加载 -> 分块 -> 向量化 | +-------------+-------------+ | +---------------v------------------+ | 向量数据库 (FAISS/Chroma) | +---------------+------------------+ | +----------------v-------------------+ | 本地大语言模型 (ChatGLM/Qwen) | +-------------------------------------+

前端提供网页界面供用户上传文档和提问，后端通过 FastAPI 暴露 REST 接口协调各模块运行。文档处理流水线负责 ETL 流程，生成的向量索引持久化保存，后续查询可直接复用。LLM 推理服务可通过 llama.cpp、transformers 或 vLLM 等框架部署，甚至能在消费级显卡上运行量化模型。

这种设计带来了几个显著优势。一是安全性极高——从文档上传到答案生成全程离线，彻底规避数据泄露风险。二是维护成本低。传统知识系统一旦更新内容就得重新训练模型，而这里只需新增文档即可，系统自动将其纳入检索范围。三是扩展性强。你可以轻松更换嵌入模型、切换不同大模型、或是接入新的文档类型。

不过实际落地时也有一些细节需要注意。比如表格类内容的处理，常规文本切分容易把一行数据拆到两个块中，导致信息残缺。建议对表格区域做整体保留，或者转换为 Markdown 格式再分块。再如嵌入模型的选择，中文场景下推荐使用专为中文训练的 BGE 或 text2vec 系列，它们在语义匹配任务上的表现远超通用英文模型。

硬件资源方面，若受限于 GPU 显存，可采用 GGUF 量化模型配合 llama.cpp 运行，4GB 显存即可流畅推理 7B 参数模型。向量数据库也可启用内存映射机制，减少 RAM 占用。对于高频问题，还可加入缓存层，将常见问答结果预存，提升响应速度。

更进一步，这套系统还能演化为企业级知识中枢。比如连接内部 Wiki、邮件归档、会议纪要等多源数据，统一索引后实现跨文档联合查询。销售团队可以问：“去年Q3华东区哪个客户提到了交付延迟？”客服人员可以直接获取产品故障的官方解决方案，而不必层层上报。

Langchain-Chatchat 的意义不仅在于技术实现，更在于它代表了一种新的知识管理范式：知识不再是静态的文档集合，而是可交互、可演进的动态资产。它让组织沉淀的经验真正“活”了起来，每个人都能以最自然的方式获取所需信息。

随着本地推理效率和嵌入模型质量的持续提升，这类系统正从实验项目走向生产环境。未来的企业或许不再需要庞大的培训体系，因为每一位员工身边都会有一个懂公司所有文档的 AI 助手。而今天的技术积累，正是通往那个未来的起点。