简介面向开发者与科研人员的本地私有化智能问答助理示例项目使用Gradio图形界面库搭建交互界面并结合向量检索与句子嵌入模型实现文档上传、知识库构建、语义匹配和自动回答适合快速搭建内部知识问答系统或学习检索增强生成技术。压缩包共十八个文件大小仅三百三十六千字节包含五个源代码、五个文本说明、两个配置文件、一个依赖库、一个安装脚本以及办公文档、表格、电子文档等参考材料和加密证书目录结构清晰便于逐模块研读。目前已有一百三十九人学习下载。通过该项目可以掌握从文档解析、文本向量化、相似度检索到答案生成的完整流程还能了解本地私有化部署中的证书配置、依赖管理和启动脚本等实战细节具有较好的工程参考与二次开发价值。 直接开始写。先盘点一下这套东西到底解决了什么问题。我在本地部署私有化智能问答助理之前处理内部资料靠翻文件夹、问当事人、翻聊天记录效率低不说很多信息散落在不同人脑子里。后来把一套基于大模型的问答系统落到内网服务器上配合知识库把制度文档、项目记录、技术手册喂进去团队现在就把它当内部“第二大脑”用。整套方案核心就四个字数据不出内网问答随时可用。这套组合选型是 Dify Ollama 开源大模型Qwen / DeepSeek 系列部署流程不复杂但对硬件有一定要求。如果你想给团队自己的数据搭一套私有问答系统或者纯粹想折腾一下本地大模型这篇文章能帮你省不少弯路。下面按实际踩坑顺序从头到尾拆一遍。1. 为什么非要用本地私有化方案1.1 数据隐私不是口号是死线很多企业内部资料有一个特点不能上传到公网服务。比如要做一个智能问答助理来回答员工关于报销制度、项目流程、技术规范的问题这些文档里有真实的组织架构、业务数据、客户信息。用云端大模型 API 的话把文档内容embedding之后传到对方服务器这个动作本身就突破了数据边界。合规角度说很多制度就不允许实际操作上老板也不会同意核心资料躺在别人的数据库里面。本地部署之后模型权重、知识库、推理过程全部跑在内网网络出口甚至可以物理断开。这个价值没法用钱衡量属于“不做不行”的需求。这也是我推荐任何对数据有要求的企业或小团队优先考虑本地化的原因。1.2 离线可用和成本可控是隐性收益还有一个经常被忽略的点离线可用。内部网络不是什么时候都畅通云端 API 一断整个问答系统就瘫痪。本地部署之后断网了照样查资料回答问题稳定性反而更高。成本方面云端 API 是按 token 计费问答多了费用跟着涨本地部署的账很简单一次性硬件投入加电费之后就没有边际成本了。团队十几个人高频使用大概两三个月就把 API 的钱抵回来了。对大模型使用频率高的团队来说这个账很好算。1.3 不是替代云端是数据主权问题说清楚一个认知本地私有化部署不是为了在回答质量上颠覆云端大模型而是要拿回数据主权。7B、14B 的模型和云端几百 B 的模型比知识储量肯定有差距但在垂直领域里配合知识库检索增强回答的准确率反而可能更高。为什么因为云端大模型没有你公司的内部文档而本地方案可以把这些资料精确检索后推给模型它回答的依据是你自己的数据。2. 技术选型为什么是 Dify Ollama 开源模型2.1 Ollama 的角色与选型理由Ollama 的角色是“模型运行时”负责把开源大模型跑起来暴露一个 OpenAI 兼容的 API。选它原因就三个极简安装、原生支持 GGUF 量化格式、自带模型管理命令。你可能听说过 vLLM、llama.cpp、Xinference 这些更“专业”的推理框架它们性能更强、支持高并发但配置麻烦对普通团队不友好。Ollama 适合的是“要快速跑起来、不想折腾编译环境、并发不高”的场景——正好匹配内部辅助工具的定位。如果后续并发上去了再切 vLLM 也不迟因为 Dify 接模型走的是标准 API底层换掉不影响上层。另一个细节Ollama 对显存的管理比较聪明模型默认常驻显存空闲一段时间后自动卸载这个特性在多人共用的服务器上很实用。另外它支持通过OLLAMA_HOST环境变量绑定 IP让同网段其他机器也能访问方便团队共享这套问答能力。2.2 Dify 的角色把模型变成业务系统Dify 是一个 LLM 应用开发平台核心能力是可视化编排把模型、知识库、提示词、工作流串成一个可用的应用。没有 Dify 的话你得自己写 FastAPI 服务、管理会话、做知识库切分和向量检索工作量一下就上去了。有了 Dify这些都有现成模块鼠标点一点就能搭出一个带对话界面、知识库引用、管理后台的问答系统。选它的原因还有一个开源可自托管社区活跃度也高。你可以直接拉代码部署也能用 Docker Compose 一键起全套服务API 服务、Worker、Web 前端、PostgreSQL、Redis、向量数据库对个人和团队都很友好。新版本还带了 Agent 能力后续想从“问答机器人”升级成“能执行任务的智能体”不用换平台。2.3 模型选型硬件的尺子量一量模型选型是整个方案里最需要动脑的一步既要考虑效果也要考虑显存。我实测下来比较适合本地问答的模型是这两种模型参数量量化版本显存需求约适用场景Qwen2.5-7B-Instruct7BQ4_K_M5-6 GB日常问答、资料检索、轻量助手Qwen2.5-14B-Instruct14BQ4_K_M9-10 GB长文本理解、复杂推理、知识库问答DeepSeek-R1-Distill-Qwen-7B7BQ4_K_M5-6 GB逻辑推理、数学问题、代码分析DeepSeek-R1-Distill-Qwen-14B14BQ4_K_M9-10 GB强推理需求、复杂业务分析注意一个关键点Q4_K_M这种量化格式在推理时需要额外的 KV Cache 显存上下文越长占用越多。所以上面标注的“显存需求”只是模型权重本身实际使用建议再留 20%-30% 余量。比如 7B 模型理论只要 5-6GB但跑长上下文时占用可能冲到 8GB所以显卡显存 8GB 是起步16GB 比较舒服。还要解释一下量化是什么就是把模型权重从 16 位浮点数压缩到 4 位整数体积缩小 4 倍左右速度更快换来少量精度损失。实测 Q4_K_M 在问答场景损失很小但换来的显存大幅下降非常值。2.4 向量模型与 rerank 模型的补充知识库问答还有个隐藏组件Embedding 模型它的作用是把文本转成向量让系统能“理解”语义相似度。Dify 默认可以用 OpenAI 的 embedding但本地部署就建议也走 Ollama用bge-m3这类开源向量模型。它只有几百 MB对显存要求极低可以长期驻留。如果你追求检索精准度还可以额外加一个 rerank 模型比如bge-reranker-v2-m3。它的作用是先用向量检索召回 Top 20 片段再用 rerank 模型精排输出 Top 3-5 给大模型效果提升非常明显。代价是多占一点显存和多几十毫秒延迟但换来的是答案准确率大幅提升很值得。3. 环境准备硬件和系统的底线在哪3.1 硬件配置参考我自己的部署环境是这样的一台 Ubuntu 22.04 服务器CPU 是 8 核 16 线程内存 64GB显卡是 RTX 4090 24GB。这个配置跑 14B 模型很轻松同时启动多个模型都没问题。但如果你手头机器配置没这么高可以参考这个底线使用场景CPU内存显卡显存推荐模型纯 CPU 环境8 核以上32GB 以上无Qwen2.5-3B 或 7B慢但能用入门 GPU 环境4 核以上16GB 以上6-8GBQwen2.5-7B Q4标准 GPU 环境8 核以上32GB 以上12-16GBQwen2.5-14B Q4富裕 GPU 环境8 核以上64GB 以上24GB 以上Qwen2.5-32B Q4 或 14B 多模型并发没有 NVIDIA 显卡的话可以看看 Mac 的 M 系列芯片统一内存跑模型其实很能打M1 Pro 32GB 跑 14B Q4 没压力。Ollama 官方对 macOS 支持很好如果你手头有 Mac Studio当作团队问答服务器也是不错的选择。3.2 系统层面的注意事项LinuxUbuntu 20.04/22.04是首选部署系统原因无他Docker 支持最好驱动问题少。Windows 环境也能跑但建议用 WSL2 来装 Docker原生 Windows Docker 在挂载目录和 GPU 透传上容易踩坑。macOS 用户可以直接跑 Docker Desktop相对简单一些。磁盘规划也要提前想清楚。模型文件叠加起来体积不小Qwen2.5-14B Q4 大概 9GBEmbedding 模型 1-2GBDify 的镜像和容器数据又占 10-20GB知识库的向量化数据会随文档量增长。建议给这套系统预留至少 100GB 可用空间不然用一段时间就会发现磁盘告急。网络环境方面如果你是想让局域网内多个用户同时用部署机器的防火墙要放行 3 个端口Dify 的 Web 端口默认 80/443 或自定义 8080、Ollama 的 API 端口11434、PostgreSQL 和 Redis 等 Dify 内部端口这些端口只需在 Docker 内网可访问不用暴露到外部。我习惯只暴露 Dify 的 Web 端口到内网Ollama 端口只允许 Dify 容器访问减少暴露面。4. 实操部署从零到能用的完整过程4.1 安装 Ollama 并用命令行验证模型可跑安装 Ollama 在 Linux 上就一条命令curl -fsSL https://ollama.com/install.sh | shWindows 和 macOS 用户直接去官网下载安装包即可。装完验证一下服务状态systemctl status ollama # Linux 系统检查服务是否启动 ollama --version # 查看版本号然后把模型拉下来。以 Qwen2.5-14B-Instruct Q4 量化版为例ollama pull qwen2.5:14b-instruct-q4_K_M拉取过程取决于网速14B 大概 9GB 大小耐心等着就行。拉完可以启动进入交互式对话验证一下ollama run qwen2.5:14b-instruct-q4_K_M 你好请简单介绍一下自己。能正常回复就说明模型没问题。按/bye退出对话。这个验证很关键排除了模型损坏或驱动问题后面接入 Dify 出问题就好排查。还需要拉取 Embedding 模型。这里我推荐用bge-m3中文效果在开源模型里是第一梯队ollama pull bge-m3注意Dify 对接 Ollama 时一个模型供应商配置只能填一个模型名但 Dify 里可以创建多个 Ollama 供应商配置填不一样的模型名来分别使用聊天模型和 Embedding 模型。4.2 部署 Dify一键起全套服务Dify 官方推荐用 Docker Compose 部署。先把代码和配置拉下来git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env然后编辑.env重点检查这几项# 端口设置避免和现有服务冲突 EXPOSE_NGINX_PORT80 # 如果需要暴露到局域网EXPOSE_NGINX_PORT 保持 80 即可不用改 127.0.0.1 # 密钥和数据库密码建议改成自己的强密码 SECRET_KEY请改成随机长字符串 POSTGRES_PASSWORD请改成强密码启动docker compose up -d第一次启动会拉很多镜像PostgreSQL、Redis、Weaviate、API、Worker、Web 等大概十几分钟。启动完用docker compose ps查看状态全部running就说明起来了。浏览器访问http://服务器IP就能看到 Dify 初始化页面创建管理员账号进入主界面。这里有个经验如果EXPOSE_NGINX_PORT用 80 端口访问时不需要加端口号如果改成其他值访问时要记得带上比如http://IP:8080。4.3 配置模型供应商让 Dify 认识 Ollama进入 Dify 后台后点右上角头像进入“设置”找到“模型供应商”页面选择 Ollama。这里有几个关键配置项配置项填写内容说明模型名称qwen2.5:14b-instruct-q4_K_M必须和ollama list里完全一致Base URLhttp://host.docker.internal:11434Mac/Windows或http://172.17.0.1:11434LinuxDify 容器内部访问宿主机的地址模型类型对话助手 / Embeddings聊天模型选对话Embedding 模型单独再配一个这个 Base URL 是新手最容易出错的地方。Dify 的 API 容器跑在 Docker 里它访问宿主机上的 Ollama不能用localhost要用 Docker 的宿主机网关地址。Linux 上一般是172.17.0.1也可以用host.docker.internal新版 Docker 在 Linux 上也支持。配好之后点“测试”能通过就说明模型通了。如果要用 Ollama 同时跑 embedding按同一路径再配一个“模型类型”为 Embeddings 的配置模型名填bge-m3。4.4 创建知识库把你的文档变成答案来源私有化问答助理的灵魂在知识库。Dify 的“知识库”模块支持上传 PDF、Word、Markdown、TXT 等格式。上传前有两点注意一是建议按主题拆分文档比如“人事制度”“财务流程”“技术文档”分开建库方便后续权限控制二是文档内容质量要高乱码、扫描件会严重影响检索效果。上传后 Dify 会要求设置分段方式。默认“自动分段”就行但要做两处调整分段长度建议 300-500 个字符因为太短会丢失上下文太长则导致检索命中不精准分段重叠长度设置 50 字左右避免关键句正好被切在边界上。索引方式选择“高质量模式”用向量索引。Embedding 模型选刚才配好的bge-m3。知识库处理完成之后在“文档”列表里能看到每个分段的详细内容和向量状态。绿点就代表可用了。4.5 创建聊天助手把知识库串起来回到“应用”页面创建一个“聊天助手”类型的应用。在编排页面左侧把已创建的知识库关联进来。在“上下文”里选择对应知识库这样模型在回答时会先检索知识库内容作为参考。提示词编排建议直接套用这个模板你是 {公司名} 的内部智能问答助理请严格根据提供的知识库内容回答用户问题。 如果知识库中没有相关信息请直接说明“知识库中暂无相关内容”不要编造答案。 回答时请引用你参考的知识库段落编号方便用户核对原文。这里有几个关键参数经验Temperature温度调成 0.1-0.3内部知识问答要求事实准确不需要创造性Top P保持默认或调低到 0.7Max Tokens根据问题复杂度设置 500-1000防止回答过长。这些参数的意义在于控制随机性——温度越低模型越倾向于选概率最高的词答案越保守准确温度越高回答越发散有“创意”但容易跑偏。发布应用后Dify 会生成一个 Web App 的访问链接发给团队就能用了。Dify 还支持发布到微信公众号、企业微信、钉钉等渠道也可以调用 API 接入自己的系统。5. 实测效果与调优记录5.1 一次真实问答的表现我拿公司内部的知识库做了一批测试。比如问“公司年假制度中入职满一年但不满三年的员工可休几天年假”在正确配置了知识库后系统能准确从“人事制度.md”里检索到对应段落并给出答案同时附上引用片段编号。而如果知识库没配好或者没有关联上下文模型就会进入“自由发挥”模式编出一个看起来合理但完全错误的答案——这是本地部署问答最容易翻车的点。5.2 实测下来的体验数据在 RTX 4090 上跑 Qwen2.5-14B Q4单用户问答的首次响应延迟在 2-5 秒之间取决于文档检索速度和模型首 token 生成速度连续对话时每个 token 生成速度约 20-40 tokens/s。这个速度日常使用完全没问题。如果用的是 7B 模型延迟还能再降一半。多人同时用还没测出明显瓶颈因为日常问答的并发其实很有限。5.3 对比纯云端 API 的差距因为在同一批知识库语料上做过对比我说说主观感受本地 14B 模型在回答的完整性和语言流畅度上确实不如云端大模型偶尔会漏掉一些隐含逻辑。但在垂直知识库范围内它给的信息基本准确引用来源清晰已经是“可用”的状态了。对内部工具来说够用就行追求“惊艳”反而是多余的。6. 常见问题与排查6.1 模型供应商测试不通过这个错误出现的频率最高。先检查 Base URL 是否填对在 Dify 容器内执行curl http://172.17.0.1:11434/api/tags能返回模型列表就说明网络是通的。然后确认模型名和ollama list输出完全一致一个字符都不能差。最后看看 Ollama 服务是否在监听0.0.0.0而不仅是127.0.0.1如果只监听本地外部访问会被拒绝。6.2 知识库生效但回答不引用多半是应用没关联知识库或者关联了但上下文里没激活。还有一个容易被忽视的点知识库分段太长。如果整份文档被切成了几个大段检索命中之后模型拿到的是一片大杂烩很难提取出准确答案。分段长度别超过 500 字符。6.3 回答明显错误先别怪模型大概率是知识库文档本身有歧义或版本不统一。我排查过几次最后发现是知识库里同时存在新旧两版制度文件模型在检索时拿到的可能是旧版本内容。建议定期清理过期文档并且在提示词里强调“如果知识库有冲突信息以最近更新日期为准”。6.4 推理速度慢显存不够时模型会退化成 CPU 计算速度断崖式下降。用ollama ps查看模型实际跑在什么设备上如果显示CPU说明显存不够用换个更小参数的模型或更高压缩比的量化版本。另一种情况是并发对话太多显存被多个会话的 KV Cache 挤占这时限制同时会话数或者干脆换更大显存的卡。6.5 服务器重启后服务没起来Docker 容器默认在 Docker 重启后会自动拉起但 Ollama 服务在 Linux 上如果不是通过 systemd 安装的重启后不会自动启动。建议执行systemctl enable ollama把它设为开机自启。Dify 方面确认.env里RESTART_POLICY是unless-stopped即可。7. 下一步可以怎么扩展这套基础架构跑通之后能扩展的方向很多。第一个建议是接入 Agent 能力Dify 新版本支持 Agent 节点可以让问答助理在回答“报销单怎么填”之后自动生成一份填写指引文档甚至把相关表格也调出来第二个建议是在知识库基础上加上权限分组不同部门只能检索各自的知识空间第三个建议是优化检索链路引入预检索查询改写和多路召回会让回答质量再上一个台阶。我个人实际折腾下来还有一个体会本地部署这套系统价值不在模型本身而在“基础设施”的成熟度。Ollama 和 Dify 这两个项目已经把复杂的大模型工程问题封装得很好了我们更重要的是把知识库内容管理好、把使用场景定义清楚。工具会迭代但没有知识积累再强的模型也答不出你公司的问题。本文还有配套的精品资源点击获取 本地私有化智能问答系统搭建指南：Dify+Ollama+开源大模型实战
简介面向开发者与科研人员的本地私有化智能问答助理示例项目使用Gradio图形界面库搭建交互界面并结合向量检索与句子嵌入模型实现文档上传、知识库构建、语义匹配和自动回答适合快速搭建内部知识问答系统或学习检索增强生成技术。压缩包共十八个文件大小仅三百三十六千字节包含五个源代码、五个文本说明、两个配置文件、一个依赖库、一个安装脚本以及办公文档、表格、电子文档等参考材料和加密证书目录结构清晰便于逐模块研读。目前已有一百三十九人学习下载。通过该项目可以掌握从文档解析、文本向量化、相似度检索到答案生成的完整流程还能了解本地私有化部署中的证书配置、依赖管理和启动脚本等实战细节具有较好的工程参考与二次开发价值。 直接开始写。先盘点一下这套东西到底解决了什么问题。我在本地部署私有化智能问答助理之前处理内部资料靠翻文件夹、问当事人、翻聊天记录效率低不说很多信息散落在不同人脑子里。后来把一套基于大模型的问答系统落到内网服务器上配合知识库把制度文档、项目记录、技术手册喂进去团队现在就把它当内部“第二大脑”用。整套方案核心就四个字数据不出内网问答随时可用。这套组合选型是 Dify Ollama 开源大模型Qwen / DeepSeek 系列部署流程不复杂但对硬件有一定要求。如果你想给团队自己的数据搭一套私有问答系统或者纯粹想折腾一下本地大模型这篇文章能帮你省不少弯路。下面按实际踩坑顺序从头到尾拆一遍。1. 为什么非要用本地私有化方案1.1 数据隐私不是口号是死线很多企业内部资料有一个特点不能上传到公网服务。比如要做一个智能问答助理来回答员工关于报销制度、项目流程、技术规范的问题这些文档里有真实的组织架构、业务数据、客户信息。用云端大模型 API 的话把文档内容embedding之后传到对方服务器这个动作本身就突破了数据边界。合规角度说很多制度就不允许实际操作上老板也不会同意核心资料躺在别人的数据库里面。本地部署之后模型权重、知识库、推理过程全部跑在内网网络出口甚至可以物理断开。这个价值没法用钱衡量属于“不做不行”的需求。这也是我推荐任何对数据有要求的企业或小团队优先考虑本地化的原因。1.2 离线可用和成本可控是隐性收益还有一个经常被忽略的点离线可用。内部网络不是什么时候都畅通云端 API 一断整个问答系统就瘫痪。本地部署之后断网了照样查资料回答问题稳定性反而更高。成本方面云端 API 是按 token 计费问答多了费用跟着涨本地部署的账很简单一次性硬件投入加电费之后就没有边际成本了。团队十几个人高频使用大概两三个月就把 API 的钱抵回来了。对大模型使用频率高的团队来说这个账很好算。1.3 不是替代云端是数据主权问题说清楚一个认知本地私有化部署不是为了在回答质量上颠覆云端大模型而是要拿回数据主权。7B、14B 的模型和云端几百 B 的模型比知识储量肯定有差距但在垂直领域里配合知识库检索增强回答的准确率反而可能更高。为什么因为云端大模型没有你公司的内部文档而本地方案可以把这些资料精确检索后推给模型它回答的依据是你自己的数据。2. 技术选型为什么是 Dify Ollama 开源模型2.1 Ollama 的角色与选型理由Ollama 的角色是“模型运行时”负责把开源大模型跑起来暴露一个 OpenAI 兼容的 API。选它原因就三个极简安装、原生支持 GGUF 量化格式、自带模型管理命令。你可能听说过 vLLM、llama.cpp、Xinference 这些更“专业”的推理框架它们性能更强、支持高并发但配置麻烦对普通团队不友好。Ollama 适合的是“要快速跑起来、不想折腾编译环境、并发不高”的场景——正好匹配内部辅助工具的定位。如果后续并发上去了再切 vLLM 也不迟因为 Dify 接模型走的是标准 API底层换掉不影响上层。另一个细节Ollama 对显存的管理比较聪明模型默认常驻显存空闲一段时间后自动卸载这个特性在多人共用的服务器上很实用。另外它支持通过OLLAMA_HOST环境变量绑定 IP让同网段其他机器也能访问方便团队共享这套问答能力。2.2 Dify 的角色把模型变成业务系统Dify 是一个 LLM 应用开发平台核心能力是可视化编排把模型、知识库、提示词、工作流串成一个可用的应用。没有 Dify 的话你得自己写 FastAPI 服务、管理会话、做知识库切分和向量检索工作量一下就上去了。有了 Dify这些都有现成模块鼠标点一点就能搭出一个带对话界面、知识库引用、管理后台的问答系统。选它的原因还有一个开源可自托管社区活跃度也高。你可以直接拉代码部署也能用 Docker Compose 一键起全套服务API 服务、Worker、Web 前端、PostgreSQL、Redis、向量数据库对个人和团队都很友好。新版本还带了 Agent 能力后续想从“问答机器人”升级成“能执行任务的智能体”不用换平台。2.3 模型选型硬件的尺子量一量模型选型是整个方案里最需要动脑的一步既要考虑效果也要考虑显存。我实测下来比较适合本地问答的模型是这两种模型参数量量化版本显存需求约适用场景Qwen2.5-7B-Instruct7BQ4_K_M5-6 GB日常问答、资料检索、轻量助手Qwen2.5-14B-Instruct14BQ4_K_M9-10 GB长文本理解、复杂推理、知识库问答DeepSeek-R1-Distill-Qwen-7B7BQ4_K_M5-6 GB逻辑推理、数学问题、代码分析DeepSeek-R1-Distill-Qwen-14B14BQ4_K_M9-10 GB强推理需求、复杂业务分析注意一个关键点Q4_K_M这种量化格式在推理时需要额外的 KV Cache 显存上下文越长占用越多。所以上面标注的“显存需求”只是模型权重本身实际使用建议再留 20%-30% 余量。比如 7B 模型理论只要 5-6GB但跑长上下文时占用可能冲到 8GB所以显卡显存 8GB 是起步16GB 比较舒服。还要解释一下量化是什么就是把模型权重从 16 位浮点数压缩到 4 位整数体积缩小 4 倍左右速度更快换来少量精度损失。实测 Q4_K_M 在问答场景损失很小但换来的显存大幅下降非常值。2.4 向量模型与 rerank 模型的补充知识库问答还有个隐藏组件Embedding 模型它的作用是把文本转成向量让系统能“理解”语义相似度。Dify 默认可以用 OpenAI 的 embedding但本地部署就建议也走 Ollama用bge-m3这类开源向量模型。它只有几百 MB对显存要求极低可以长期驻留。如果你追求检索精准度还可以额外加一个 rerank 模型比如bge-reranker-v2-m3。它的作用是先用向量检索召回 Top 20 片段再用 rerank 模型精排输出 Top 3-5 给大模型效果提升非常明显。代价是多占一点显存和多几十毫秒延迟但换来的是答案准确率大幅提升很值得。3. 环境准备硬件和系统的底线在哪3.1 硬件配置参考我自己的部署环境是这样的一台 Ubuntu 22.04 服务器CPU 是 8 核 16 线程内存 64GB显卡是 RTX 4090 24GB。这个配置跑 14B 模型很轻松同时启动多个模型都没问题。但如果你手头机器配置没这么高可以参考这个底线使用场景CPU内存显卡显存推荐模型纯 CPU 环境8 核以上32GB 以上无Qwen2.5-3B 或 7B慢但能用入门 GPU 环境4 核以上16GB 以上6-8GBQwen2.5-7B Q4标准 GPU 环境8 核以上32GB 以上12-16GBQwen2.5-14B Q4富裕 GPU 环境8 核以上64GB 以上24GB 以上Qwen2.5-32B Q4 或 14B 多模型并发没有 NVIDIA 显卡的话可以看看 Mac 的 M 系列芯片统一内存跑模型其实很能打M1 Pro 32GB 跑 14B Q4 没压力。Ollama 官方对 macOS 支持很好如果你手头有 Mac Studio当作团队问答服务器也是不错的选择。3.2 系统层面的注意事项LinuxUbuntu 20.04/22.04是首选部署系统原因无他Docker 支持最好驱动问题少。Windows 环境也能跑但建议用 WSL2 来装 Docker原生 Windows Docker 在挂载目录和 GPU 透传上容易踩坑。macOS 用户可以直接跑 Docker Desktop相对简单一些。磁盘规划也要提前想清楚。模型文件叠加起来体积不小Qwen2.5-14B Q4 大概 9GBEmbedding 模型 1-2GBDify 的镜像和容器数据又占 10-20GB知识库的向量化数据会随文档量增长。建议给这套系统预留至少 100GB 可用空间不然用一段时间就会发现磁盘告急。网络环境方面如果你是想让局域网内多个用户同时用部署机器的防火墙要放行 3 个端口Dify 的 Web 端口默认 80/443 或自定义 8080、Ollama 的 API 端口11434、PostgreSQL 和 Redis 等 Dify 内部端口这些端口只需在 Docker 内网可访问不用暴露到外部。我习惯只暴露 Dify 的 Web 端口到内网Ollama 端口只允许 Dify 容器访问减少暴露面。4. 实操部署从零到能用的完整过程4.1 安装 Ollama 并用命令行验证模型可跑安装 Ollama 在 Linux 上就一条命令curl -fsSL https://ollama.com/install.sh | shWindows 和 macOS 用户直接去官网下载安装包即可。装完验证一下服务状态systemctl status ollama # Linux 系统检查服务是否启动 ollama --version # 查看版本号然后把模型拉下来。以 Qwen2.5-14B-Instruct Q4 量化版为例ollama pull qwen2.5:14b-instruct-q4_K_M拉取过程取决于网速14B 大概 9GB 大小耐心等着就行。拉完可以启动进入交互式对话验证一下ollama run qwen2.5:14b-instruct-q4_K_M 你好请简单介绍一下自己。能正常回复就说明模型没问题。按/bye退出对话。这个验证很关键排除了模型损坏或驱动问题后面接入 Dify 出问题就好排查。还需要拉取 Embedding 模型。这里我推荐用bge-m3中文效果在开源模型里是第一梯队ollama pull bge-m3注意Dify 对接 Ollama 时一个模型供应商配置只能填一个模型名但 Dify 里可以创建多个 Ollama 供应商配置填不一样的模型名来分别使用聊天模型和 Embedding 模型。4.2 部署 Dify一键起全套服务Dify 官方推荐用 Docker Compose 部署。先把代码和配置拉下来git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env然后编辑.env重点检查这几项# 端口设置避免和现有服务冲突 EXPOSE_NGINX_PORT80 # 如果需要暴露到局域网EXPOSE_NGINX_PORT 保持 80 即可不用改 127.0.0.1 # 密钥和数据库密码建议改成自己的强密码 SECRET_KEY请改成随机长字符串 POSTGRES_PASSWORD请改成强密码启动docker compose up -d第一次启动会拉很多镜像PostgreSQL、Redis、Weaviate、API、Worker、Web 等大概十几分钟。启动完用docker compose ps查看状态全部running就说明起来了。浏览器访问http://服务器IP就能看到 Dify 初始化页面创建管理员账号进入主界面。这里有个经验如果EXPOSE_NGINX_PORT用 80 端口访问时不需要加端口号如果改成其他值访问时要记得带上比如http://IP:8080。4.3 配置模型供应商让 Dify 认识 Ollama进入 Dify 后台后点右上角头像进入“设置”找到“模型供应商”页面选择 Ollama。这里有几个关键配置项配置项填写内容说明模型名称qwen2.5:14b-instruct-q4_K_M必须和ollama list里完全一致Base URLhttp://host.docker.internal:11434Mac/Windows或http://172.17.0.1:11434LinuxDify 容器内部访问宿主机的地址模型类型对话助手 / Embeddings聊天模型选对话Embedding 模型单独再配一个这个 Base URL 是新手最容易出错的地方。Dify 的 API 容器跑在 Docker 里它访问宿主机上的 Ollama不能用localhost要用 Docker 的宿主机网关地址。Linux 上一般是172.17.0.1也可以用host.docker.internal新版 Docker 在 Linux 上也支持。配好之后点“测试”能通过就说明模型通了。如果要用 Ollama 同时跑 embedding按同一路径再配一个“模型类型”为 Embeddings 的配置模型名填bge-m3。4.4 创建知识库把你的文档变成答案来源私有化问答助理的灵魂在知识库。Dify 的“知识库”模块支持上传 PDF、Word、Markdown、TXT 等格式。上传前有两点注意一是建议按主题拆分文档比如“人事制度”“财务流程”“技术文档”分开建库方便后续权限控制二是文档内容质量要高乱码、扫描件会严重影响检索效果。上传后 Dify 会要求设置分段方式。默认“自动分段”就行但要做两处调整分段长度建议 300-500 个字符因为太短会丢失上下文太长则导致检索命中不精准分段重叠长度设置 50 字左右避免关键句正好被切在边界上。索引方式选择“高质量模式”用向量索引。Embedding 模型选刚才配好的bge-m3。知识库处理完成之后在“文档”列表里能看到每个分段的详细内容和向量状态。绿点就代表可用了。4.5 创建聊天助手把知识库串起来回到“应用”页面创建一个“聊天助手”类型的应用。在编排页面左侧把已创建的知识库关联进来。在“上下文”里选择对应知识库这样模型在回答时会先检索知识库内容作为参考。提示词编排建议直接套用这个模板你是 {公司名} 的内部智能问答助理请严格根据提供的知识库内容回答用户问题。 如果知识库中没有相关信息请直接说明“知识库中暂无相关内容”不要编造答案。 回答时请引用你参考的知识库段落编号方便用户核对原文。这里有几个关键参数经验Temperature温度调成 0.1-0.3内部知识问答要求事实准确不需要创造性Top P保持默认或调低到 0.7Max Tokens根据问题复杂度设置 500-1000防止回答过长。这些参数的意义在于控制随机性——温度越低模型越倾向于选概率最高的词答案越保守准确温度越高回答越发散有“创意”但容易跑偏。发布应用后Dify 会生成一个 Web App 的访问链接发给团队就能用了。Dify 还支持发布到微信公众号、企业微信、钉钉等渠道也可以调用 API 接入自己的系统。5. 实测效果与调优记录5.1 一次真实问答的表现我拿公司内部的知识库做了一批测试。比如问“公司年假制度中入职满一年但不满三年的员工可休几天年假”在正确配置了知识库后系统能准确从“人事制度.md”里检索到对应段落并给出答案同时附上引用片段编号。而如果知识库没配好或者没有关联上下文模型就会进入“自由发挥”模式编出一个看起来合理但完全错误的答案——这是本地部署问答最容易翻车的点。5.2 实测下来的体验数据在 RTX 4090 上跑 Qwen2.5-14B Q4单用户问答的首次响应延迟在 2-5 秒之间取决于文档检索速度和模型首 token 生成速度连续对话时每个 token 生成速度约 20-40 tokens/s。这个速度日常使用完全没问题。如果用的是 7B 模型延迟还能再降一半。多人同时用还没测出明显瓶颈因为日常问答的并发其实很有限。5.3 对比纯云端 API 的差距因为在同一批知识库语料上做过对比我说说主观感受本地 14B 模型在回答的完整性和语言流畅度上确实不如云端大模型偶尔会漏掉一些隐含逻辑。但在垂直知识库范围内它给的信息基本准确引用来源清晰已经是“可用”的状态了。对内部工具来说够用就行追求“惊艳”反而是多余的。6. 常见问题与排查6.1 模型供应商测试不通过这个错误出现的频率最高。先检查 Base URL 是否填对在 Dify 容器内执行curl http://172.17.0.1:11434/api/tags能返回模型列表就说明网络是通的。然后确认模型名和ollama list输出完全一致一个字符都不能差。最后看看 Ollama 服务是否在监听0.0.0.0而不仅是127.0.0.1如果只监听本地外部访问会被拒绝。6.2 知识库生效但回答不引用多半是应用没关联知识库或者关联了但上下文里没激活。还有一个容易被忽视的点知识库分段太长。如果整份文档被切成了几个大段检索命中之后模型拿到的是一片大杂烩很难提取出准确答案。分段长度别超过 500 字符。6.3 回答明显错误先别怪模型大概率是知识库文档本身有歧义或版本不统一。我排查过几次最后发现是知识库里同时存在新旧两版制度文件模型在检索时拿到的可能是旧版本内容。建议定期清理过期文档并且在提示词里强调“如果知识库有冲突信息以最近更新日期为准”。6.4 推理速度慢显存不够时模型会退化成 CPU 计算速度断崖式下降。用ollama ps查看模型实际跑在什么设备上如果显示CPU说明显存不够用换个更小参数的模型或更高压缩比的量化版本。另一种情况是并发对话太多显存被多个会话的 KV Cache 挤占这时限制同时会话数或者干脆换更大显存的卡。6.5 服务器重启后服务没起来Docker 容器默认在 Docker 重启后会自动拉起但 Ollama 服务在 Linux 上如果不是通过 systemd 安装的重启后不会自动启动。建议执行systemctl enable ollama把它设为开机自启。Dify 方面确认.env里RESTART_POLICY是unless-stopped即可。7. 下一步可以怎么扩展这套基础架构跑通之后能扩展的方向很多。第一个建议是接入 Agent 能力Dify 新版本支持 Agent 节点可以让问答助理在回答“报销单怎么填”之后自动生成一份填写指引文档甚至把相关表格也调出来第二个建议是在知识库基础上加上权限分组不同部门只能检索各自的知识空间第三个建议是优化检索链路引入预检索查询改写和多路召回会让回答质量再上一个台阶。我个人实际折腾下来还有一个体会本地部署这套系统价值不在模型本身而在“基础设施”的成熟度。Ollama 和 Dify 这两个项目已经把复杂的大模型工程问题封装得很好了我们更重要的是把知识库内容管理好、把使用场景定义清楚。工具会迭代但没有知识积累再强的模型也答不出你公司的问题。本文还有配套的精品资源点击获取