Langchain-Chatchat 支持哪些文件格式？一文讲清输入源配置

在企业知识管理日益复杂的今天，如何让堆积如山的PDF、Word文档和内部手册“开口说话”，成了智能化落地的关键一步。很多团队尝试引入大模型来构建智能问答系统，却发现通用AI虽然能说会道，却对公司的私有资料一无所知——这正是本地知识库系统的用武之地。

Langchain-Chatchat 作为当前开源社区中最具代表性的本地化RAG（检索增强生成）框架之一，正被越来越多开发者用于搭建企业级私有知识助手。它最大的吸引力在于：所有数据处理都在本地完成，无需上传云端，真正实现安全可控。而要让这套系统“读懂”你的文档，第一步就是搞清楚它到底支持哪些文件类型，以及背后是如何工作的。

---

说到支持格式，很多人第一反应是“是不是只要把文件扔进去就行？”但实际情况远比想象复杂。不同格式的文档结构差异巨大，有的像TXT那样纯文本直白清晰，有的如扫描版PDF根本没文字层，还有的Word文件嵌套了表格、页眉页脚、批注等复杂元素。如果解析不当，轻则信息错乱，重则整段内容丢失。

Langchain-Chatchat 并非自己从零造轮子，而是巧妙地整合了 LangChain 生态中成熟的文档加载器（Document Loader），通过调用不同的底层解析库，实现了对多种主流格式的支持。目前可稳定处理的包括：

• .txt：纯文本文件
• .pdf：原生可编辑PDF（含部分扫描件配合OCR）
• .docx：Office Word 文档
• .md：Markdown 格式
• .html：网页或导出的HTML文档

这些加载器各司其职，比如 PyPDFLoader 负责逐页读取PDF并保留页码元数据，Docx2txtLoader 提取Word正文与表格内容，而 UnstructuredMarkdownLoader 则能较好还原Markdown中的标题层级和代码块结构。整个流程可以概括为：

原始文件 → 加载器解析 → 提取文本 + 元数据 → 输出 Document 对象列表

每个 Document 是一个结构化对象，包含两个核心字段：
- page_content：提取出的文本内容；
- metadata：来源文件名、路径、页码等附加信息，便于后续溯源。

下面这段代码展示了如何根据扩展名动态选择合适的加载器：

from langchain.document_loaders import (
    TextLoader,
    PyPDFLoader,
    Docx2txtLoader,
    UnstructuredMarkdownLoader,
    UnstructuredHTMLLoader
)

def load_document(file_path: str):
    if file_path.endswith(".txt"):
        loader = TextLoader(file_path, encoding="utf-8")
    elif file_path.endswith(".pdf"):
        loader = PyPDFLoader(file_path)
    elif file_path.endswith(".docx"):
        loader = Docx2txtLoader(file_path)
    elif file_path.endswith(".md"):
        loader = UnstructuredMarkdownLoader(file_path)
    elif file_path.endswith(".html"):
        loader = UnstructuredHTMLLoader(file_path)
    else:
        raise ValueError(f"Unsupported file format: {file_path}")

    documents = loader.load()
    return documents

这里有几个细节值得注意。首先是编码问题——中文环境下的 .txt 文件常因编码不一致导致乱码，必须显式指定 encoding="utf-8" 或 "gbk"；其次是PDF类型，如果是扫描图像转PDF且无文本层，PyPDFLoader 将无法提取任何内容，此时需前置OCR模块进行识别；最后是Word文档的排版复杂性，某些带有分栏、文本框或水印的 .docx 可能出现段落顺序错乱，建议提前转换为Markdown或纯文本再导入。

---

解决了“读得进”的问题后，下一个挑战是“处理得了”。大多数语言模型都有上下文长度限制，例如 Qwen 最多支持32768个token，ChatGLM3为8192，更常见的BGE类embedding模型则通常限制在512 token以内。面对一本上百页的制度手册，显然不能一股脑塞进去。

这就引出了 文本分割器（Text Splitter） 的作用。它的任务是将长文档切分成适合模型处理的小块，同时尽可能保持语义完整。Langchain-Chatchat 默认采用 RecursiveCharacterTextSplitter，这是一种递归式字符分割策略，优先按自然断点切分：

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    length_function=len,
    separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""]
)

这个配置的意思是：先尝试以双换行符（\n\n）分割段落，若仍过长则按单换行拆分，再不行就看句号、感叹号等中文标点。这种层级式的分隔逻辑能有效避免把一句话从中腰斩。

参数方面，chunk_size 设定每块最大长度，默认500字符已能满足多数场景；chunk_overlap 设置相邻块之间的重叠量（如50字符），防止关键信息刚好落在边界上被遗漏。这种“滑动窗口”式的设计，在实际检索中显著提升了召回率。

值得一提的是，这里的长度单位默认是“字符数”，对于中文来说大致等价于token数（平均1.3~1.8字符/token）。若追求更高精度，也可替换为基于tokenizer的计数方式，例如使用 tiktoken 计算OpenAI模型的真实token消耗。

---

文本切好之后，下一步就是让它“变得可搜索”。传统关键词检索依赖倒排索引，用户必须准确输入“报销流程”才能命中相关条目，一旦换成“怎么申请差旅费”就可能失效。而 Langchain-Chatchat 采用的是 向量语义检索，从根本上改变了匹配逻辑。

其核心思想是：将每一段文本和用户的提问都转化为高维向量，语义越接近的文本，向量空间中的距离就越近。这一过程依赖于预训练的嵌入模型（Embedding Model），项目推荐使用专为中文优化的 BGE 系列模型（如 BAAI/bge-small-zh-v1.5），它在多个中文NLP任务中表现优异。

具体实现如下：

from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS

embedding_model = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5")
vectorstore = FAISS.from_documents(split_docs, embedding_model)

query = "如何报销差旅费用？"
retrieved_docs = vectorstore.similarity_search(query, k=3)

短短几行代码完成了整个语义检索链路：模型将问题编码为向量，在FAISS数据库中查找最相似的Top-K文档片段，并返回给LLM作为上下文。相比Elasticsearch这类全文搜索引擎，这种方式具备更强的泛化能力——即使用户问的是“出差花的钱怎么报？”，也能精准匹配到“差旅费用报销流程”相关内容。

FAISS 由 Facebook 开发，擅长处理百万级以下的向量数据，支持GPU加速，毫秒级响应完全满足实时交互需求。更重要的是，整个过程无需联网调用API，所有计算均在本地完成，彻底规避了数据外泄风险。

---

整个系统的运作其实是一个闭环流程。假设某公司IT部门上传了一份《员工考勤管理制度.docx》，系统会自动触发以下步骤：

1. 使用 Docx2txtLoader 解析文档，提取正文与章节标题；
2. 通过 RecursiveCharacterTextSplitter 按段落切分为若干文本块；
3. 调用本地部署的 BGE 模型生成向量，并存入 FAISS 数据库；
4. 当员工提问“年假怎么休？”时，系统将其向量化后检索出三条最相关的政策条款；
5. 将问题与这三条上下文拼接成prompt，送入本地运行的 Qwen 或 ChatGLM 模型生成回答；
6. 最终输出不仅包含答案，还会附带原文出处，提升可信度。

这种端到端的设计，使得企业原有的静态文档真正“活了起来”。无论是财务制度、法律合同还是技术手册，都能通过自然语言接口被快速访问。尤其在金融、医疗、法律等对数据安全要求极高的行业，这种完全离线的能力极具价值。

不过，在实际部署中仍有几个关键点需要权衡：

首先是 文件命名规范。建议统一采用 部门_文档类型_版本.pdf 这类结构化命名，方便后期分类管理和权限控制。其次是 索引更新机制，可通过定时任务每日扫描新增或修改文件，自动同步至向量库，确保知识时效性。

再者是 混合检索策略。单纯依赖向量检索有时会漏掉一些关键词明确但语义偏离的内容，可结合BM25等稀疏检索方法，采用RRF（Reciprocal Rank Fusion）融合排序，进一步提升整体准确率。

此外，日志监控也不容忽视。记录每次检索的耗时、命中情况和用户反馈，有助于持续优化 chunk_size、重叠比例、embedding模型等参数。对于大量扫描件，则应集成 PaddleOCR 或 EasyOCR 模块，在加载阶段先行文字识别。

---

回到最初的问题：Langchain-Chatchat 到底支持哪些文件格式？表面上看只是几个扩展名的列举，但背后涉及的是整套文档理解与知识转化的技术链条。从加载、清洗、切分到向量化存储，每一个环节都直接影响最终的问答质量。

更重要的是，这套方案提供了一种可复制的知识工程范式——不再依赖人工整理FAQ，而是直接将现有文档资产自动化接入AI系统。无论你是初创团队想做个产品帮助文档机器人，还是大型企业要建智能客服中枢，掌握这套输入源配置逻辑，都是迈向高效本地化AI助手的第一步。

未来，随着多模态模型的发展，我们或许还能让系统“看懂”图片中的流程图、“听懂”会议录音里的决策要点。但在当下，先把PDF和Word文档读懂、读准，就已经为企业带来了实实在在的价值跃迁。