Langchain-Chatchat与Docker Compose编排：一键启动全套服务

Langchain-Chatchat 与 Docker Compose 编排：构建可落地的本地知识库系统

在企业智能化转型的浪潮中，一个现实问题日益凸显：大量关键知识散落在 PDF、Word 和内部文档中，员工查找信息耗时费力，而通用大模型又无法准确回答公司特有的流程或政策。更棘手的是，把敏感文件上传到云端存在合规风险。

有没有一种方式，既能享受 AI 的语义理解能力，又能确保数据不出内网？答案是肯定的——Langchain-Chatchat + Docker Compose的组合正在成为这一需求的标准解法。

这套方案的核心思路很清晰：用“检索增强生成”（RAG）替代微调，通过向量数据库记住企业文档内容，再由本地部署的大模型基于这些内容作答。整个过程不依赖外部服务，所有计算都在你自己的服务器上完成。

要理解它的价值，先得明白它解决了哪些传统方法难以克服的问题。

过去我们面对私有知识问答，通常有三种选择：用关键词搜索工具查文档、训练专属大模型，或者直接问 ChatGPT。但每种都有明显短板。搜索引擎看不懂“年假怎么请”和“带薪休假申请流程”其实是同一个意思；微调模型成本高、周期长，且一旦文档更新就得重新训练；而把合同、制度发给第三方 API，安全红线绝不允许。

Langchain-Chatchat 换了个思路：我不训练模型，而是教会它“查资料”。就像一位新员工入职后先花几天读完所有手册，之后你问他问题，他能快速翻找对应章节给出答案。这种模式不仅响应快、准确性高，还能随时同步最新文档，真正做到了“活的知识库”。

其底层技术架构围绕 RAG 流程展开。用户上传一份《员工手册》PDF 后，系统首先使用 PyPDFLoader 或类似的解析器提取文本。接着，为了避免整篇文档被当作单一上下文处理，会通过 RecursiveCharacterTextSplitter 将内容切分为 500 字左右的片段，并保留 50 字的重叠部分以维持语义连贯性。

下一步是“记忆化”——每个文本块被送入嵌入模型（如 BGE 或 m3e），转换为高维向量并存入 FAISS、Chroma 等向量数据库。当你提问“出差报销标准是多少？”时，问题本身也会被同一模型向量化，然后在库中寻找最相似的几个段落作为上下文，拼接到提示词中传给语言模型生成最终回答。

这个设计巧妙之处在于，它把“知识存储”和“语言理解”两个任务解耦。你可以自由更换更强的 LLM 而不影响已有知识索引，也可以随时增删文档而不必重新训练整个系统。更重要的是，所有环节均可离线运行，只需提前下载好模型权重即可。

from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain.chains import RetrievalQA from langchain_community.llms import HuggingFaceHub # 加载文档 loader = PyPDFLoader("company_policy.pdf") pages = loader.load() # 文本切分 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) docs = text_splitter.split_documents(pages) # 向量化 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5") db = FAISS.from_documents(docs, embeddings) # 构建问答链 llm = HuggingFaceHub(repo_id="THUDM/chatglm3-6b", model_kwargs={"temperature": 0}) qa_chain = RetrievalQA.from_chain_type(llm, retriever=db.as_retriever()) # 查询 query = "员工请假流程是什么？" result = qa_chain.invoke({"query": query}) print(result["result"])

上面这段代码虽然只是简化版逻辑，却完整体现了系统的分层思想。实际项目中，Langchain-Chatchat 对这些组件做了深度封装和性能优化，比如支持多线程批量嵌入、增量索引更新、对话历史管理等，但核心路径依然一致。

然而，光有功能还不够。一套涉及前端、后端、向量库、模型服务的系统，如果每次部署都要手动配置 Python 环境、安装 CUDA 驱动、调试端口冲突，那只会让运维人员望而却步。

这正是 Docker Compose 发挥作用的地方。

设想一下，你只需要在一个目录下放好docker-compose.yml文件，执行一条命令docker-compose up -d，几分钟后整个系统就自动拉起：数据库启动了，嵌入模型服务就绪了，API 接口开放了，前端页面也能访问了。这一切是如何实现的？

Docker Compose 的本质是一个声明式编排工具。你不再需要写一堆 shell 脚本去逐个启动容器，而是用 YAML 文件描述“我想要什么”，而不是“该怎么一步步做”。系统会根据依赖关系自动决定启动顺序，确保 Chroma 数据库先于 API 服务运行，前端在后端可用后再加载。

version: '3.8' services: chroma: image: chromadb/chroma:latest ports: - "8000:8000" volumes: - ./data/chroma:/chroma restart: unless-stopped embedder: image: ghcr.io/shibing624/text2vec-api:latest environment: - MODEL_NAME=m3e-base ports: - "9000:9000" depends_on: - chroma restart: unless-stopped api-server: image: chatchat/langchain-chatchat:latest ports: - "7860:7860" environment: - EMBEDDING_MODEL=m3e-base - VECTOR_SEARCH_TOP_K=5 - CHUNK_SIZE=500 volumes: - ./knowledge_base:/app/knowledge_base - ./models:/models depends_on: - chroma - embedder restart: unless-stopped web: image: chatchat/web:latest ports: - "8501:8501" depends_on: - api-server restart: unless-stopped

这份配置文件定义了四个服务，各自职责分明：

• Chroma作为轻量级向量数据库，适合中小规模知识库存储；
• Embedder提供统一的 REST 接口调用嵌入模型，避免每个服务重复加载；
• API Server是业务中枢，处理文档解析、索引构建、问答调度等核心逻辑；
• Web 前端基于 Streamlit 实现，非技术人员也能轻松操作。

通过volumes挂载，./knowledge_base目录中的文档会被持久化保存，即使容器重启也不会丢失；模型缓存也放在宿主机指定路径，避免每次重建镜像都重新下载。而restart: unless-stopped策略则提升了系统稳定性，意外中断后能自动恢复。

更进一步，如果你有 GPU 资源，只需在配置中加入设备声明，就能启用硬件加速：

deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]

前提是宿主机已安装 NVIDIA Container Toolkit。这样，嵌入和推理任务将自动利用 GPU 计算能力，显著提升响应速度。

从架构上看，整个系统形成了一个闭环：

+------------------+ +---------------------+ | Web Browser | <---> | Frontend (Web) | +------------------+ +----------+----------+ | v +---------+---------+ | API Server | | (Langchain-Chatchat)| +----+----+-----------+ | | +-----------------------+ +----------------------+ | | v v +--------+---------+ +---------+----------+ | Vector Database | | Embedding Model | | (Chroma) | | (m3e/bge) | +------------------+ +--------------------+ +----------------------------------+ | Local LLM (optional) | | e.g., ChatGLM3, Qwen, etc. | +----------------------------------+

所有数据流转均发生在本地网络内，彻底规避了外泄风险。当用户问出一个问题时，系统不会凭空编造，而是必须找到依据才能作答。如果没有匹配的内容，正确的回应应该是“未找到相关信息”，而非胡诌一段看似合理的谎言——这一点对于金融、医疗等高可靠性场景尤为重要。

实践中还需要注意一些关键细节：

首先是文本切分策略。chunk_size设得太小，可能割裂完整语义；设得太大，则影响检索精度。建议初始设置为 500 字符，配合 50 字符重叠，在多数中文文档上表现良好。可根据实际测试效果微调。

其次是嵌入模型的选择。英文场景常用 Sentence-BERT，但中文推荐使用专为汉语优化的模型，如bge-large-zh或m3e。它们在中文语义相似度任务上的表现远超通用模型，能有效提升召回率。

此外，定期备份不可忽视。./knowledge_base和./data/chroma应纳入自动化备份计划，防止因磁盘故障导致知识资产损失。简单的 tar 压缩加异地同步即可满足大多数场景需求。

最后是并发控制。大模型服务资源消耗大，若不限流，多个并发请求可能导致内存溢出。可在 Nginx 层添加限速规则，或在应用内部集成限流中间件，保障系统稳定运行。

对比来看，这套方案的优势非常明显。它不像传统搜索那样依赖关键词匹配，能够理解语义相近的表达；也不像微调模型那样成本高昂、更新困难；更不同于公有云 API 存在隐私隐患。它在安全性、准确性与可维护性之间找到了最佳平衡点。

可以预见，随着 MoE 架构、模型量化等技术的发展，这类本地化智能系统的运行门槛将进一步降低。未来甚至可以在普通笔记本电脑上流畅运行完整的知识库问答服务。而对于企业而言，这样的平台不仅是效率工具，更是组织智慧的沉淀载体——每一次问答都在强化企业的认知资产。

Langchain-Chatchat 与 Docker Compose 的结合，不只是技术选型的胜利，更是一种工程哲学的体现：复杂系统的价值不在于炫技，而在于能否被稳定、低成本地复制和交付。当一个 AI 应用能做到“一键启动、开箱即用”，它才真正具备了大规模落地的可能性。