langchain-chatchat部署与多模型测试实战

Langchain-Chatchat 部署与多模型测试实战

在企业级 AI 应用日益普及的今天，如何构建一个既安全又高效的本地知识库问答系统，成为许多技术团队关注的核心问题。尤其是在涉及敏感数据、合规要求严格的场景下，将大模型能力“私有化”部署的需求愈发迫切。Langchain-Chatchat正是在这一背景下脱颖而出的开源项目——它不仅支持主流大模型本地运行，还能无缝对接各类文档格式，实现真正意义上的离线智能问答。

本文基于真实生产环境下的部署经验，结合对 Qwen 系列多个规模模型的实测对比，深入剖析从环境搭建到性能调优的全流程，并分享在双卡 A6000 上启用多卡并行、AWQ 量化实践等关键环节中的踩坑与解决方案。如果你正计划为企业搭建一套可落地的知识助手系统，这篇实战记录或许能帮你少走弯路。

从零开始：部署不是复制粘贴那么简单

很多人以为，只要git clone下来、装上依赖就能跑起来。实际上，真正的挑战往往藏在细节里。

我们选择的是 Ubuntu 22.04 + CUDA 12.1 + PyTorch 2.3 的组合，硬件为双 NVIDIA A6000（每张 48GB 显存），这在当前属于中高端配置。创建虚拟环境时建议使用 Conda：

conda create -n chatchat python=3.10 conda activate chatchat

接着克隆项目并安装依赖：

git clone https://github.com/chatchat-space/Langchain-Chatchat.git cd Langchain-Chatchat pip install -r requirements.txt

⚠️ 特别提醒：部分依赖版本存在冲突风险，尤其是transformers和langchain的兼容性问题。强烈建议不要随意升级包，优先使用官方锁定的版本号。

如果需要处理.docx、.pptx或复杂 PDF 表格，还需额外补充工具链：

pip install python-docx pptx PyPDF2 unstructured pymupdf4llm

这些库直接影响后续文档解析的质量，特别是表格内容提取的完整性。

配置文件怎么改？这才是决定效果的关键

很多用户忽略了configs/目录下的两个核心文件：model_config.py和server_config.py。它们不仅仅是路径设置，更是整个系统的“神经中枢”。

首先是模型路径注册。假设你已经下载了 Qwen-14B-Chat-Int4 模型，应确保其路径正确挂载：

MODEL_PATH = { "qwen-14b": "/models/Qwen-14B-Chat-Int4", "qwen-32b": "/models/Qwen-32B-Chat-Int4", }

其次是 embedding 模型的选择。中文任务强烈推荐替换默认模型为bge-small-zh-v1.5，它在语义相似度匹配上的表现远超通用英文模型：

EMBEDDING_MODEL = "bge-small-zh-v1.5"

最后是 GPU 加速开关。哪怕有显卡，也不代表自动启用：

USE_CUDA = True DEVICE = "cuda"

只有这几项都配妥当了，后端才能真正发挥硬件潜力。

启动服务也很简单，但必须分两步走：

# 后端 API（向量库、模型加载） python server.py # 前端界面 streamlit run webui.py

访问http://127.0.0.1:8501/即可进入交互页面。Swagger 接口文档位于:7861/docs，方便做自动化集成。

支持哪些模型？本地加载其实很灵活

Langchain-Chatchat 的一大优势就是模型兼容性强。只要是 HuggingFace 格式的 Causal LM，基本都能接入。以下是我们在实际测试中验证过的主流系列：

要让新模型出现在前端下拉框中，只需在llm_model_dict中注册：

llm_model_dict = { "qwen-14b-chat-int4": { "name": "qwen-14b-chat-int4", "pretrained_model_name_or_path": "/models/Qwen-14B-Chat-Int4", "tokenizer_name_or_path": "/models/Qwen-14B-Chat-Int4", } }

然后刷新前端即可看到选项。切换模型会触发卸载与重载过程，因此频繁切换时建议预留足够显存或控制操作频率。

对于资源有限的用户，Int4 量化模型几乎是必选项。以 Qwen 系列为例如下：

• Qwen-14B-Int4：约 12~13.5GB 显存
• Qwen-32B-Int4：约 20~22GB
• Qwen-72B-Int4：需双卡协作（单卡无法承载）

这意味着一张 A6000 就足以运行 32B 级别的模型，性价比极高。

实战测评：Qwen-14B 到 72B，谁更适合你的业务？

我们的测试集包含多种类型文档：技术白皮书、含表格的 Word 文件、LaTeX 学术片段、Markdown 产品需求说明等，总数据量约 80MB。评估维度包括准确性、响应速度、显存占用和上下文理解能力。

Qwen-14B（Int4）：轻量级选手，够用但有局限

在常规文本检索任务中表现稳定。例如从一份 50 页 PDF 中查找某协议参数，在合理分块策略下能准确命中，平均响应时间约 8 秒，显存占用 13.5GB 左右。

但在处理表格类问题时暴露出短板。上传一个 20 行的成绩表，提问“有多少人总成绩超过 80？”初始回答错误——原因在于向量化切片导致聚合信息丢失。调整chunk_size=50、overlap=20并提高top_k=15后才恢复正常。

长文档方面，原始按固定长度分割容易遗漏跨段落信息。后来改用MarkdownHeaderTextSplitter按章节划分，召回率显著提升。结论是：适合中小型企业日常问答，但需精细调参才能应对复杂结构文档。

Qwen-32B（v1.5, Int4）：质变的起点

显存峰值约 21.8GB，单轮对话平均延迟 12 秒，加载时间约 90 秒。虽然数字看起来不如 14B 快，但在语义理解和推理连贯性上明显更胜一筹。

最具代表性的是跨文档分析任务：“结合三份不同文档的内容，总结公司当前 AI 战略方向。”
模型成功整合分散信息，输出结构完整、逻辑清晰的战略摘要，具备初步的“决策支持”能力。

这类任务正是中大型组织真正需要的——不再是简单查文档，而是辅助思考。如果你的场景涉及政策解读、报告生成或知识融合，32B 是值得投资的门槛模型。

Qwen-72B（Int4）：精度之王，代价也高

盲测评分结果显示，其准确率达到 94%，信息完整性和语言流畅度均为最高水平。面对“根据财务报表和市场报告预测下季度营收增长率”的复合问题，能引用具体数据点并给出合理区间（+12% ~ +15%），展现出接近专家级的分析能力。

然而硬伤同样突出：输出延迟高达 6~8 秒/字，完整回复动辄两三分钟，用户体验极差。即便开启 streaming 输出缓解等待焦虑，也无法改变交互迟滞的本质。

所以我的判断很明确：72B 适用于非实时的专业分析场景，比如周报自动生成、研报初稿撰写，而不适合客服、即时问答等高频交互用途。

多卡优化：别让第二张 A6000 闲置

我们最初只用单卡跑 Qwen-32B，结果第一张卡显存占满，第二张却完全空转。更糟的是，系统被迫启用 CPU offload，导致推理时间飙升至 30 秒以上，效率极其低下。

解决办法是启用device_map="auto"，让 Transformers 自动分配模型层到多张 GPU 上。

修改model_config.py中的关键参数：

"device_map": "auto", "trust_remote_code": True, "low_cpu_mem_usage": True,

前提是你使用的transformers版本 ≥ 4.37，否则不支持自动设备映射。

启用后效果立竿见影：

两张 A6000 均达到约 20GB 显存占用，负载均衡良好。对于 32B 及以上模型，多卡不仅是锦上添花，更是必要条件。

AWQ 量化实战：省显存了吗？体验牺牲了多少？

既然 GPTQ 已经很成熟，为何还要尝试 AWQ？因为后者在某些架构上理论压缩效率更高，尤其适合边缘部署。

安装过程可谓一波三折。直接pip install autoawq经常报错：

ModuleNotFoundError: No module named 'triton'

这是因为在 Windows 下 Triton 不可用，而旧版autoawq强依赖它。解决方案很简单：换 Linux 环境（WSL2 也可），或直接安装新版：

pip install autoawq==0.2.5

同时保证配套组件版本一致：

transformers==4.40.1 torch==2.3.0+cu121

量化脚本本身不复杂：

from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path = "/models/Qwen-14B-Chat" quant_path = "/models/Qwen-14B-Chat-AWQ" quant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM" } model = AutoAWQForCausalLM.from_pretrained(model_path) tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model.quantize(tokenizer, quant_config=quant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)

耗时约 40 分钟（14B 模型）。完成后将其注册进model_config.py：

"qwen-14b-awq": { "name": "qwen-14b-awq", "pretrained_model_name_or_path": "/models/Qwen-14B-Chat-AWQ", "tokenizer_name_or_path": "/models/Qwen-14B-Chat-AWQ", "device_map": "auto", "trust_remote_code": True, }

注意：AWQ 模型需通过专用后端推理，不能直接走标准 generate 流程。项目中已提供qwen_awq.py封装支持。

但实测发现一个严重问题：输出速度极慢，每字间隔达 5~10 秒，几乎不可用。

排查后怀疑是autoawq的 generate 方法未充分优化流式输出，可能与 Streamlit 的异步机制冲突。目前临时方案是退回 GPTQ + ExLlamaV2 组合，等待autoawq后续更新。

那些你一定会遇到的问题，我们都踩过了

小模型总是找不到关键信息？

这通常不是模型“笨”，而是分块策略不当。chunk_size 过大会切断句子，阈值设太高（如 >1.5）则过滤掉相关段落。

建议：
- 缩小 chunk_size 至 100~150 字
- 使用更强的 embedding 模型（如bge-large-zh-v1.5）
- 提高 top_k 至 10~20，扩大检索范围

表格问答老是出错？

根本原因是表格在转文本时结构失真。解决方案有两个方向：

1. 预处理阶段增强结构保留：使用Unstructured或pymupdf4llm更精准提取，加入[ROW][COL]标记；
2. 提示词层面引导统计行为：在 prompt 中明确要求“请遍历所有行进行汇总计算”。

如何提高整体召回率？

单一向量检索总有盲区。我们上线了混合检索方案：

• BM25 + 向量检索：兼顾关键词匹配与语义相似性
• 查询扩展：自动添加同义词、提取关键词补全意图
• Reranker 二次排序：用bge-reranker对候选结果重新打分

这些功能已在hybrid_retriever.py中实现，大幅提升了复杂问题的命中率。

能不能指定某个文件来问答？

原生知识库模式不支持强制限定文件源。但有两种替代方式：

• 使用“文件对话模式”：单独上传目标文件进行独立问答；
• 在提问时带上文件名提示：“请根据《XXX.docx》中的内容回答……”

后者依赖模型注意力机制，效果不稳定，仅作辅助。

Latex 公式和图表能识别吗？

测试表明，模型可以理解 LaTeX 数学表达式的含义，也能从 TikZ 或 Markdown 表格代码中提取数值关系。例如输入积分公式：

\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}

Qwen-32B 不仅能解释其意义，还能推导高斯分布性质。

但对于图表布局、图形样式等视觉信息，则完全无法还原。目前仍停留在纯文本理解层面，不具备多模态输出能力。

写在最后：选型没有银弹，只有权衡

经过多轮测试与调优，我们可以给出如下建议：

最佳实践总结：

1. 部署层面：
   - 优先使用 Int4 量化节省显存；
   - 32B 以上务必配置多卡（A6000×2 或更好）；
   - 模型存储建议用 SSD，加快加载速度。

2. 应用层面：
   - 结构化内容（表格/公式）需加强预处理；
   - 关键业务搭配 reranker 提升准确率；
   - 高频问题可做缓存降本增效。

3. 未来期待：
   - 集成多模态模型（如 Qwen-VL）以支持图像输入；
   - 支持动态模型切换与常驻缓存池；
   - 插件系统正在开发，有望接入数据库、API 等外部系统。

Langchain-Chatchat 作为国产开源项目的佼佼者，展现了强大的工程落地能力。只要选型得当、调优到位，完全可以在企业内部构建起一个安全、可控、智能的知识中枢。这条路虽有坑，但也正因如此，每一步前进才更有价值。