简介面向人工智能与机器学习开发者的一套本地部署私有化智能问答助理示例项目基于Gradio构建交互式上传与问答界面结合FAISS与Sentence-Transformers实现文档向量化检索并支持接入ChatGLM等大模型完整演示了从文件上传、向量索引到答案生成的RAG工作流程。资源打包为zip共18个文件、约336KB包含5个Python源文件主程序与多个迭代版本、5个TXT配置与执行说明、2个YAML环境文件、1个Windows依赖WHL包、1个Shell更新脚本以及DOCX/XLSX/PDF示例资料和PEM证书覆盖环境准备、依赖安装、模型加载与推理测试全链路。项目利用FAISS进行大规模向量聚类与相似性搜索通过Sentence-Transformers将文档和用户问题映射到同一向量空间在本地知识库中快速定位最相关片段同时多版本代码清晰呈现了问答逻辑的优化演进便于开发者对比学习。本地部署无需外部服务器既能保障数据隐私与交互安全也可按业务术语定制训练实际应用中通过Gradio上传文档即可直接对话适用于客户服务、技术支持、教育培训等场景并支持灵活调整检索阈值与模型版本。资源已有140人学习下载开发者可基于该示例快速搭建属于自己的私有知识库问答系统结合内置示例文档、证书配置和Shell脚本完成系统级联调也可进一步扩展文件格式与问答策略。1. 本地部署私有化智能问答助理先把数据关在自己机房再谈智能企业想用 ChatGLM 这类大语言模型做内部智能问答第一反应往往是调 API。但 API 这条路在涉及合同条款、财务数据、研发文档时根本走不通——数据出境这一条就卡死大半需求。我在交付过的项目里看到最典型的场景是某制造企业想把设备维修手册做成问答系统让车间工人直接问「二号产线液压站报警代码 E-204 怎么处理」这类数据本身带商业敏感性和现场关联性不可能传到外部服务。本地部署私有化智能问答助理的价值就在这里模型权重、向量库、问答日志全部落在自己服务器上网络断开照样能用。它适合有 GPU 服务器或高性能工作站的团队也适合对数据主权有硬性要求的企业。本文会从模型选型、部署工具链、知识库构建到排查踩坑完整走一遍直接给可复现的操作路径。2. 技术选型ChatGLM 只是起点配套组件决定成败2.1 模型选型为什么 ChatGLM 系列适合私有化而不是一味追最大参数在做本地部署选型时我先说结论ChatGLM 系列是目前中文场景下性价比最高的私有化候选之一。原因有三点。第一中文语料覆盖度好对于企业内部文档中常见的中文表达、专业术语ChatGLM 的 tokenizer 切分效率和理解准确性明显优于同量级的英文模型。第二显存门槛适中量化后的 6B 模型在 8GB 显存上可运行16GB 显存能跑 FP16 半精度这个门槛对大多数企业的单卡工作站是友好的。第三商用协议明确企业自用部署不涉及复杂的授权争议。注意不要盲目追求 130B 甚至更大参数版本。私有化部署不是打榜而是解决实际业务问题。我在实际项目中遇到过客户坚持要 130B结果两张 A100 才勉强跑起来推理延迟 8 秒以上工人根本不愿意等。后来换成 6B 量化版延迟降到 1.5 秒配合 RAG 检索回答质量反而因为能实时检索到准确文档而大幅提升。选型时必须先问自己三个问题并发量多大、响应时间容忍度多少、知识库文档量级是几百篇还是几万篇。这三个答案直接决定你要部署 6B、32B 还是更大的模型。2.2 部署工具链对比Ollama 与 FastGPT 的分工逻辑当前本地部署大语言模型的主流做法是「模型运行时 问答编排框架」两层结构。模型运行时负责加载模型权重并执行推理常见选项有 Ollama、vLLM、Text-generation-inference。问答编排框架负责任务编排、提示词管理、知识库召回和对话历史维护常见选项有 FastGPT、Dify、Quivr。这套主流组合里我在生产环境中更倾向于 Ollama FastGPT 的组合。原因是两者各司其职且接口成熟Ollama 负责把 ChatGLM 的模型权重变成 HTTP API 服务FastGPT 负责把用户提问变成带知识库上下文的完整请求。FastGPT 本身不自带模型推理能力需要对接外部模型服务Ollama 恰恰补上了这一环。FastGPT 内置的知识库分段、向量化、召回逻辑也省去了自研 RAG 的工程量。组件职责现任选择为什么选它模型运行时加载模型、执行推理、暴露 APIOllama安装简单、量化支持好、默认 OpenAI 兼容接口问答编排对话管理、知识库召回、提示词组织FastGPT可视化编排、多知识库管理、免前端开发向量库文档向量化存储与检索FastGPT 内置默认 pgvector中小规模知识库够用无需额外部署2.3 硬件规划显存、内存、磁盘的黄金比例本地部署 ChatGLM-6B 的硬件底线不难满足但生产可用需要预留余量。常见做法是给这三块分别做预算。显存方面FP16 半精度需要约 13GB 显存4bit 量化需要约 7GB 显存但量化后推理速度会有轻微下降。如果同时开 3 个并发对话建议显存至少 16GB对应 RTX 4080 或 A10 级别。内存方面模型加载时需要把权重文件读入内存再映射到显存建议系统内存不低于 32GB。磁盘方面模型文件本身 4-12GB知识库文档和向量库按文档量级预留建议至少留出 50GB 空余给日志和向量数据。这里给一个具体配置参考单张 RTX 4080 16GB AMD Ryzen 9 64GB 内存 1TB SSD可以稳定支撑 6B 模型 FP16 部署、知识库文档量级在 5000 篇以内的小团队使用。如果预算有限租用云 GPU 服务器也可以但注意「私有化」与「云上私有化」的区别——云上部署数据仍然经过云厂商机房敏感数据需要评估合规性。3. 部署实操从零把 Ollama ChatGLM 跑通3.1 环境准备Docker 安装与 NVIDIA 容器工具链先说环境。生产环境服务器多半是 Ubuntu 22.04 LTS推荐用 Docker 部署 FastGPT模型运行时直接装在宿主机上。原因很简单FastGPT 依赖 Node.js、PostgreSQL、向量插件等多个组件Docker 编排能避免环境污染而 Ollama 直接装宿主机反而是最简路径它自带的守护进程把端口暴露给 FastGPT 容器访问即可。第一步安装 Docker 和 NVIDIA 容器工具包# 安装 Docker 官方源 curl -fsSL https://get.docker.com | sh sudo systemctl enable --now docker # 配置 NVIDIA 容器运行时务必先装好驱动 sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker # 验证 GPU 是否对容器可见 docker run --rm --gpus all nvidia/cuda:12.1-base-ubuntu22.04 nvidia-smi逻辑说明第一段命令安装 Docker 并设置开机自启第二段安装 NVIDIA 容器工具包让容器内程序能访问宿主机 GPU第三段用 CUDA 镜像验证 GPU 透传是否成功。参数说明--gpus all表示把宿主机全部 GPU 透传给容器如果机器有多卡但只想用其中一张可以改成--gpus device0。注意nvidia-ctk runtime configure这步很容易漏漏了之后容器内 nvidia-smi 会报错「could not select device driver with capabilities: gpu」。常见做法是在安装完 NVIDIA 容器工具包后检查/etc/docker/daemon.json中是否出现了nvidia运行时配置。3.2 部署 Ollama 并拉取 ChatGLM 模型Ollama 的安装和模型拉取是整套流程中最顺的环节但有一个参数值得提前定好OLLAMA_HOST。默认监听 127.0.0.1只能本机访问FastGPT 跑在 Docker 容器里时要从容器内访问宿主机 IP所以要把监听地址改成 0.0.0.0或者让 FastGPT 容器走宿主机 IP。推荐前者省去容器网络配置的麻烦。# 安装 Ollama官方脚本 curl -fsSL https://ollama.com/install.sh | sh # 配置监听地址与模型存储目录 sudo mkdir -p /data/ollama-models echo export OLLAMA_HOST0.0.0.0:11434 /etc/profile.d/ollama-env.sh echo export OLLAMA_MODELS/data/ollama-models /etc/profile.d/ollama-env.sh source /etc/profile.d/ollama-env.sh # 重启 Ollama 服务 sudo systemctl restart ollama # 拉取 ChatGLM 系列模型以 6B 为例 ollama pull chatglm3:6b逻辑说明OLLAMA_HOST控制服务监听地址改完后局域网内其他机器也能访问 11434 端口的模型服务OLLAMA_MODELS指定模型权重存放路径避免系统盘被大文件填满。参数说明chatglm3:6b是 Ollama 仓库中的标签名如果网络环境拉取慢可以在另一台机器上先拉好再拷贝OLLAMA_MODELS目录这是离线机房最常见的做法。拉取完成后可以用一行命令验证服务是否就绪curl http://localhost:11434/api/generate -d {model: chatglm3:6b, prompt: 你好}能返回 JSON 文本即可。注意首次推理会自动加载模型到显存如果显存不足会报显存溢出错误此时要么换更小量化等级要么加OLLAMA_NUM_GPU相关环境变量限制层数。3.3 FastGPT 初始化Docker Compose 编排与模型对接FastGPT 官方提供 Docker Compose 编排文件核心组件包括 FastGPT 应用容器、PostgreSQL存储用户、对话记录、知识库元数据、pgvector 插件向量检索。初始化时最关键的配置文件是config.json里面定义了对话模型和向量模型的 API 地址。# docker-compose.yml生产环境精简版 version: 3.3 services: pg: image: ankane/pgvector:v0.5.0 environment: POSTGRES_USER: fastgpt POSTGRES_PASSWORD: your_strong_password POSTGRES_DB: fastgpt volumes: - ./pgdata:/var/lib/postgresql/data networks: - fastgpt_net fastgpt: image: registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt:v4.8 ports: - 3000:3000 environment: DB_HOST: pg DB_PORT: 5432 DB_NAME: fastgpt DB_USER: fastgpt DB_PASSWORD: your_strong_password volumes: - ./config.json:/app/data/config.json depends_on: - pg networks: - fastgpt_net networks: fastgpt_net: driver: bridge逻辑说明ankane/pgvector镜像自带向量检索扩展FastGPT 的向量索引默认建在 PostgreSQL 中省去独立部署 Milvus 的运维成本。config.json挂载进容器后FastGPT 启动时会读取其中的模型网关配置。参数说明DB_PASSWORD务必改成强密码FastGPT 容器和 PostgreSQL 容器在同一个 bridge 网络内通过服务名pg互相访问不需要暴露 5432 到公网。3.4 对话模型与向量模型接入config.json 的关键结构FastGPT 需要同时配置两类模型对话模型负责生成回答向量模型负责把文档片段转成向量。对话模型对接 Ollama 的 OpenAI 兼容接口向量模型可以用 FastGPT 内置的 embedding 服务也可以对接本地部署的 bge-m3 模型。这里给出对话模型部分的配置示例{ ChatModels: [ { model: chatglm3:6b, name: 本地ChatGLM3, maxContext: 8000, maxResponse: 2000, quoteMaxToken: 1500, maxTemperature: 1.0, inputPrice: 0, outputPrice: 0, requestUrl: http://宿主IP:11434/v1/chat/completions, apiKey: ollama, isActive: true } ] }逻辑说明requestUrl指向 Ollama 的 OpenAI 兼容端点/v1/chat/completions是 FastGPT 与模型之间通信的标准路径apiKey填任意非空字符串即可因为 Ollama 默认不校验密钥但 FastGPT 会要求这个字段非空。参数说明maxContext决定了模型能看到的上下文总长度ChatGLM3-6B 的上下文窗口是 8192 token这里设 8000 留有余量temperature控制回答随机性企业内部问答建议 0.3-0.5太低显得机械太高容易跑题。如果向量模型也用 Ollama 部署再把 EmbeddingModels 数组里填上bge-m3对应的 URL两行配置即可。3.5 启动验证没有日志报错不等于能回答好问题一切配置完成后用docker-compose up -d启动服务。打开http://服务器IP:3000用管理员账号登录 FastGPT 控制台先不做任何知识库配置直接发起对话测试。如果模型返回正常说明 Ollama 到 FastGPT 的链路已经通了。此时我一般会连续问三个问题一个常规问题、一个长问题超过 500 字、一个知识库外的问题用来观察模型幻觉情况。这三个问题分别验证基础生成能力、上下文截断处理、拒答策略。4. 私有知识库构建让智能问答真正回答「你们家」的问题4.1 文档接入与分段策略分段粒度直接影响回答质量裸跑的 ChatGLM 只能回答通用知识要让它懂企业内部文档必须走 RAG 路线。FastGPT 的知识库模块支持导入 PDF、Word、Markdown、TXT 等格式系统会自动完成分段和向量化。但自动分段的效果经常不理想需要手动调整分段参数。# FastGPT 分段参数参考在知识库配置中设置 # 分段长度400 字符 # 重叠长度50 字符 # 分段标识符换行符优先句子边界兜底逻辑说明分段长度定在 400 字符是经验值。太短了语义不完整太长则一个片段可能包含多个主题向量检索时容易命中「半对」的内容。重叠长度 50 字符保证了跨段语义的连贯性比如段落末尾讲了一半的事故处理步骤下一段开头能接上。参数说明如果文档是规范性的技术手册每条操作独立成条可以把分段长度降到 200如果是连续叙事类文档如故障分析报告可以升到 600。这里没有绝对正确必须在自己数据上试。4.2 向量化与检索参数召回率与准确率的平衡点向量化是整个知识库的地基。FastGPT 默认的向量化接口会对每个分段生成一个 1024 维向量存在 pgvector 中。检索时根据用户问题的向量与库中向量的余弦相似度排序取 Top-K 片段拼入上下文。这里的核心调参是召回数量和相似度阈值。参数建议值调高时的影响调低时的影响召回数量 Top-K5-8上下文信息多但易混入无关片段回答精准但可能漏掉关键信息相似度阈值0.2-0.3更少片段进入上下文回答可能「无据可依」更多片段进入模型可能被噪声带偏引用文本长度800-1200 字符模型参考信息充足回答更详细节省 token但回答可能过于简略这里有个常见误区认为相似度阈值越高越好。实际上设到 0.6 会导致大量合法文档被过滤模型只能靠自身知识回答幻觉率飙升。正确做法是先设低阈值 0.15观察哪些低分片段是「误伤」哪些是「真相关但表达差异大」再逐步上调。我在项目里最终稳定在 0.25 左右但这是针对技术文档场景的值法律合同类文档可能需要 0.3 以上。4.3 应用编排把知识库接入对话流FastGPT 的核心优势是可视化编排。在「应用」页面新建应用拖拽配置如下流程用户输入 → 知识库检索 → 组合提示词 → 调用 ChatGLM 生成回答。这一步有几个参数值得细调。{ promptTemplate: 你是企业内部智能助手。请严格基于以下【参考文档】回答用户问题。如果参考文档没有相关信息明确回答「知识库中未找到该信息」。\n\n【参考文档】\n{{quote}}\n\n【用户问题】\n{{question}}, quoteConfig: { simThreshold: 0.25, topK: 6, maxToken: 1500 } }逻辑说明提示词模板中强制要求模型「严格基于参考文档」回答并在无信息时明确拒答这是抑制幻觉的关键手段。{{quote}}是检索到的文档片段占位符{{question}}是用户原始问题。参数说明maxToken限制了注入上下文的文档片段总长度超出部分会自动截断。如果知识库文档是技术标准类措辞精确推荐把 simThreshold 提到 0.35宁可漏检也不让模型被无关内容带偏。4.4 知识库更新与增量维护不要每次全量重建企业文档是持续更新的如果每次更新都全量重新向量化不仅慢而且浪费算力。常见做法是增量更新FastGPT 对知识库内的每个文档有独立状态只替换修改过的文档。实际操作时在知识库文档列表中点击「更新」按钮系统只对变更文件重新分段和向量化。目前 FastGPT 对单个文件更新支持较好批量更新时建议一次不要超过 50 个文件否则 pgvector 的索引重建会产生较大 I/O 压力。5. 常见问题排查与避坑五个最常见的翻车现场5.1 模型加载极慢请求要等 30 秒才回复现象第一次提问后整个对话卡住后端日志显示模型加载耗时长后续提问恢复正常。原因Ollama 默认在首次请求时才把模型权重读入显存且默认不保持常驻。如果服务器内存带宽低或者模型文件在 HDD 上加载耗时会被放大。解决修改 Ollama 的OLLAMA_KEEP_ALIVE环境变量为-1让模型常驻显存。同时在/etc/systemd/system/ollama.service中把TimeoutStartSec调大到 300避免服务启动时被误判超时。5.2 知识库能检索到文档但回答完全没引用知识库内容现象测试知识库问答时模型回答得「风马牛不相及」既不像来自知识库也不像用户问的问题。原因知识库检索命中了空结果但提示词模板中没有设置拒答机制。FastGPT 默认在检索结果为空时会放行让模型自由发挥。解决检查知识库检索测试中的命中率确认分段确实向量化成功同时在提示词中加入「如果参考文档没有相关信息明确回答未找到」的兜底指令。另外检查是否在应用编排中把「引用」开关打开了没打开的话检索结果不会传给模型。5.3 Docker 容器内访问宿主机 Ollama 超时现象FastGPT 容器日志报connect: connection refused但宿主机直连curl localhost:11434正常。原因Docker 容器内localhost指向容器自身不是宿主机。Ollama 的监听地址如果还是 127.0.0.1容器根本无法访问到宿主机。解决先把 Ollama 的OLLAMA_HOST改为0.0.0.0:11434并重启服务。然后 FastGPT 配置文件里的requestUrl填宿主机内网 IP不要填localhost。如果你的 Docker 走 host 网络模式才可以直接用localhost。5.4 显存溢出CUDA out of memory但 nvidia-smi 显示显存足够现象加载 ChatGLM-6B 时提示显存不够但nvidia-smi显示显存使用率很低。原因Ollama 在 GPU 显存不足时会自动切回 CPU 推理但不会明确告诉用户。如果系统内存也不够进程直接崩溃。另一个隐藏原因是其他进程如 FastGPT 的向量化线程占用了部分显存。解决先查看 OLLAMA 日志确认是否所有层都卸载到 GPU。执行ollama ps查看模型驻留状态对比nvidia-smi中的进程占用量。如果模型实际跑在 CPU 上最简单的处理是关闭所有其他 GPU 进程并给 Ollama 指定OLLAMA_GPU_LAYERS环境变量手动控制卸载层数。我一般建议直接换 4bit 量化版本一劳永逸。5.5 FastGPT 后台报错数据集训练失败或向量化失败现象在知识库中导入 PDF 后文档状态一直停在「训练中」或直接变为「错误」。原因大多数情况下是 PDF 解析失败。FastGPT 默认的文本抽取对扫描版 PDF 无能为力或者文档里有特殊字符导致读取中断。解决先用外部工具把 PDF 转成纯文本建议用pdftotext或 Adobe Acrobat 的 OCR 功能。然后在 FastGPT 中把纯文本以 TXT/Markdown 格式重新导入。如果多个文档都有问题检查是不是向量模型的 API 地址配置错误——这部分在日志中表现为调用 embedding API 返回 404。6. 性能验证与进阶调优把问答从「能用」做到「好用」6.1 三个维度量化验证系统质量部署完成后先别急着推广用一套固定测试集跑三轮。第一轮测「检索质量」准备 20 个真实业务问题逐一在知识库检索页查看 Top-5 命中片段是否相关计算命中率。第二轮测「回答正确率」让 2-3 个业务人员对回答做打分分「完全正确、部分正确、错误、无法回答但应该能答」四档把错误样本集中分析。第三轮测「性能压力」用模拟并发脚本连续发 50 个请求记录平均响应时间和最大响应时间算一下是否满足业务要求。# 用 curl 模拟并发请求的简化脚本 for i in $(seq 1 20); do curl -s -X POST http://localhost:3000/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model: chatglm3:6b, messages: [{role: user, content: 设备报警代码 E-204 的处理流程是什么}], temperature: 0.3} \ -w 请求$i: %{time_total}s\n -o /dev/null done wait逻辑说明这是最简单的并发验证脚本20 个并发请求同时发出观察每个请求的完成时间和是否有错误返回。参数说明%{time_total}是 curl 输出的总耗时字段包含连接、传输、生成整个链路的时间-o /dev/null丢弃响应体只关心耗时和状态码。如果并发生成时间超过 15 秒说明模型推理排队严重需要升级硬件或改用更低量化精度。6.2 调优技巧温度、系统提示词、多知识库拆分性能达标后最耗精力的其实是回答质量的「体感」。这里给三个低成本高收益的调优手段。第一把温度从默认 0.7 降到 0.3企业知识问答场景下低温度能显著减少编造。第二在 FastGPT 的「系统提示词」中注入企业背景信息比如「你是 XX 公司设备维修助手回答时优先引用《维修手册》中的原话」这比在问题里重复强调公司名有效得多。第三把知识库按部门或文档类型拆成多个子库检索时精确指定到子库能避免工程部和采购部文档互相干扰。6.3 长期维护模型版本升级与监控告警最后说一个容易忽略的长期维护问题。本地部署不是一次性的模型和知识库都需要持续维护。我现在的习惯是每季度固定花半天做一次全面检查。检查模型权重是否有新版本Ollama 中用ollama list对比当前版本、知识库文档是否有过期内容对比业务系统的更新记录、查看 Ollama 和 FastGPT 的日志中是否有反复出现的错误。同时部署一个简单的监控脚本每天检测 11434 端口和 3000 端口的连通性挂掉自动发通知到企业微信群。这个习惯是有了多次「周末被叫醒处理模型假死」的血泪教训后养成的。从那以后我每次交付私有化问答项目都会强制要求客户保留管理员账号权限并把监控脚本和部署文档放进交付物清单。希望帮到你少走一趟我走过的弯路。本文还有配套的精品资源点击获取