企业官网建设流程全解析

1. 为什么我最终选了 Ollama 这条路

1.1 本地部署这件事，绕不开的三个现实问题

先说结论：如果你只是想在自己电脑上跑一个能对话、能查资料、能离线用的模型，Ollama 加本地知识库这套组合，目前是门槛最低、踩坑最少的一条路。我自己前前后后折腾过不少方案，从直接调云端接口，到自己用推理框架手动加载权重，再到容器化编排，最后稳定下来的还是 Ollama 打底。

为什么？因为本地部署绕不开三个现实问题。第一是硬件成本，不是每个人都有多张显卡的服务器，大部分人的起点是一台带独显的笔记本或者一台家用台式机，显存往往只有 8G 到 24G。第二是网络依赖，很多人需要的是断网也能用、数据不出本机的方案，尤其是处理一些内部文档、个人笔记的时候。第三是维护成本，你不可能每天花两小时去调环境，模型加载、版本切换、接口暴露这些事最好一次配好就别再动。

Ollama 恰好把这三件事都压到了一个很低的水平。它把模型权重的下载、量化格式的适配、推理引擎的调度、本地 API 的暴露全部打包成一个命令行工具，你敲一行ollama run就能跑起来。这背后其实是 llama.cpp 那套推理内核在支撑，Ollama 做的是工程化的封装。理解这一点很重要，因为它决定了你后面遇到报错时该往哪个方向排查——大部分问题不是模型本身的问题，而是环境、路径、显存、端口这些工程层面的问题。

1.2 知识库为什么必须配 RAG，而不是指望模型自己记住

很多人一开始的误区是：我本地跑一个大模型，把资料喂给它不就行了？实测下来这条路走不通。原因有两个，一是上下文窗口有限，就算模型支持 32K 甚至 128K 的上下文，你把几百页文档全塞进去，推理速度会慢到无法接受，而且显存直接爆掉。二是模型不会真的"记住"，你这次对话喂进去的内容，下次对话就没了，它不像人一样有长期记忆。

所以知识库的正确做法是RAG，也就是检索增强生成。简单说就是：把你的文档切碎、转成向量、存进向量数据库；用户提问时，先把问题也转成向量，去数据库里找出最相关的几段原文；然后把这几段原文和问题一起塞给模型，让模型基于这些原文来回答。这样模型不需要记住任何东西，它只需要做一件事——根据你给的资料组织语言。

这里有个生活化的类比：模型是一个很聪明但没看过你资料的实习生，RAG 就是你每次提问前，先让图书管理员从你的资料库里找出最相关的几页，递给这个实习生，让他照着这几页回答你。实习生不需要背下整个图书馆，他只需要会读你递过去的那几页。

1.3 这套方案适合谁，不适合谁

适合的人群很明确：有本地数据隐私需求的人、想离线使用的人、预算有限但想体验完整 RAG 流程的人、以及想搞明白知识库底层原理的开发者。不适合的人群也说清楚：如果你追求极致的推理速度和大并发，那得上专业的推理服务框架；如果你要处理的是海量文档、千万级向量检索，那单机方案会吃力，需要考虑分布式向量库。

我下面讲的这套流程，核心是Ollama 负责模型推理，Dify 负责知识库流水线和应用编排。Dify 是一个开源的应用开发平台，它把 RAG 的整个流程——文档上传、切分、向量化、检索、拼装提示词——都做成了可视化配置，你不需要自己写代码去串这些环节。对于想快速跑通、又不想深陷代码的人来说，这是性价比最高的选择。

2. 环境准备与 Ollama 安装的实操细节

2.1 硬件与系统的最低门槛

在动手之前，先对一下自己的机器。模型能不能跑起来，核心看显存。以 7B 到 8B 参数的模型为例，4-bit 量化后大概需要 5G 到 6G 显存，加上上下文缓存，建议留出 8G 显存比较稳妥。14B 的模型 4-bit 量化后大概需要 9G 到 10G，建议 12G 以上显存。如果你只有核显或者显存小于 6G，也不是完全没戏，可以用 CPU 推理，但速度会明显慢下来，7B 模型在普通 CPU 上大概每秒几个 token，能用的程度。

内存方面，建议至少 16G，因为模型加载、向量化、Dify 服务本身都要吃内存。硬盘方面，模型文件动辄几个 G 到十几个 G，加上向量库和文档，建议预留 50G 以上空间。系统上，Windows、macOS、Linux 都支持，Windows 建议用 WSL2 或者直接装 Windows 版，macOS 用 Apple Silicon 芯片的体验反而很好，因为统一内存架构让显存和内存共享。

提示：如果你打算把模型装到非系统盘，一定要在安装前就规划好路径，装完再迁移会麻烦很多，后面我会专门讲怎么改存储路径。

2.2 Ollama 安装与国内下载慢的应对

Ollama 的安装本身很简单，官网下载对应系统的安装包，一路下一步就行。Linux 上可以用一行脚本安装。但真正卡住大多数人的是模型下载慢这个问题，因为默认的模型仓库在境外，拉取几个 G 的模型经常断流或者龟速。

应对办法有几个方向。第一是配置国内镜像源，Ollama 支持通过环境变量指定模型仓库地址，把它指向国内的镜像站点，下载速度会有质的提升。第二是手动下载模型文件再导入，如果你能找到模型的离线安装包，下载下来后用ollama create命令从本地文件创建模型，完全绕开在线拉取。第三是错峰下载，这个不用多解释。

具体操作上，设置镜像源的环境变量在 Linux 和 macOS 上是这样的：

export OLLAMA_HOST=0.0.0.0 export OLLAMA_MODELS=/your/custom/path

Windows 上则是在系统环境变量里添加。注意OLLAMA_MODELS这个变量就是用来改模型存储路径的，很多人 C 盘爆了就是因为没设这个。改完之后重启 Ollama 服务，新下载的模型就会落到你指定的目录。

2.3 验证安装与拉取第一个模型

安装完成后，打开终端敲ollama --version，能输出版本号就说明装好了。然后拉一个模型试试：

ollama pull deepseek-r1:7b

这里说明一下，DeepSeek 系列有多个尺寸，7B 适合显存有限的机器，14B 和 32B 效果更好但要求更高。拉取完成后用ollama run deepseek-r1:7b进入对话，能正常回复就说明推理链路通了。

注意：第一次运行模型时会有加载过程，显存不足的话会报错或者自动回退到 CPU，这时候要留意终端的输出信息，它会告诉你实际用的是什么设备。

3. Dify 知识库流水线的搭建与配置

3.1 Dify 的部署方式选择

Dify 的部署有两种主流方式，一种是 Docker Compose 一键拉起，另一种是源码部署。对于绝大多数人，我强烈建议用 Docker Compose，因为它把数据库、缓存、后端、前端全部编排好了，你只需要一条命令。源码部署适合要二次开发的人，但环境依赖会让你多花不少时间。

Docker Compose 部署的核心步骤是：克隆仓库、复制环境变量文件、修改配置、启动。这里有个关键点，Dify 默认的模型供应商里没有直接对接本地 Ollama 的选项，你需要确认你的 Dify 版本支持 Ollama 接入。较新的版本在模型供应商里已经内置了 Ollama，配置时填上 Ollama 的服务地址就行。

如果你是把 Ollama 和 Dify 都装在同一台机器上，Ollama 的地址填http://host.docker.internal:11434或者宿主机的局域网 IP。这里有个坑：Docker 容器内部访问宿主机的localhost是不通的，必须用host.docker.internal这个特殊域名，或者直接用宿主机的实际 IP。

3.2 把 Ollama 接入 Dify 的模型供应商

进入 Dify 后台，找到模型供应商设置，选择 Ollama。需要填两个东西：模型名称和服务地址。模型名称要和你ollama list里看到的完全一致，比如deepseek-r1:7b。服务地址填 Ollama 的 API 地址，默认端口是 11434。

填完之后点测试，如果提示连接成功，就说明 Dify 能调通 Ollama 了。如果失败，先检查 Ollama 服务有没有在跑，再检查端口有没有被防火墙拦，最后检查地址写法对不对。这一步是整个链路的关键节点，通了后面就顺了。

3.3 知识库的创建与文档处理

在 Dify 里创建知识库，本质上是创建一个向量索引。你需要选择嵌入模型，这个模型负责把文本转成向量。嵌入模型可以用 Ollama 里的模型，也可以用 Dify 内置的。这里有个经验：嵌入模型和生成模型是两回事，嵌入模型专门做向量化，通常用小模型就够了，比如 bge 系列，没必要用大模型做嵌入，又慢又浪费。

文档上传后，Dify 会走一遍流水线：解析文档、切分文本、向量化、存入向量库。切分这一步很关键，切得太碎会丢失上下文，切得太大检索精度会下降。Dify 默认的切分策略是按固定长度加重叠，你可以根据文档类型调整。比如技术文档适合按段落切，小说适合按章节切。

提示：如果你的文档里有图片，纯文本的 RAG 是处理不了的。图片需要先做 OCR 转成文字，或者用支持多模态的模型单独处理。这一点后面常见问题里会展开。

4. 三个高频报错的排查与解决

4.1 报错一：模型拉取失败或下载中断

这个报错的表现是ollama pull卡在某个百分比不动，或者直接报连接超时。根本原因是网络到模型仓库的链路不稳定。解决办法前面提过，配镜像源是最直接的。如果镜像源也不行，就找离线安装包，下载后用ollama create从本地 Modelfile 创建。

还有一种情况是磁盘空间不足导致的失败，报错信息里会提到写入失败。这时候检查一下OLLAMA_MODELS指向的目录还剩多少空间。我遇到过有人把模型目录设在了一个小分区上，拉一半就满了。

排查顺序建议是：先看报错原文，区分是网络问题还是磁盘问题；网络问题换源或离线导入，磁盘问题改路径或清理空间。

4.2 报错二：Dify 连接 Ollama 失败

这个报错在 Dify 的模型供应商测试环节最常见，提示连接被拒绝或者超时。原因通常有三个：一是 Ollama 没有监听外部地址，默认它只监听127.0.0.1，Docker 容器访问不到；二是端口没开放；三是地址写错。

第一个原因的解决办法是设置OLLAMA_HOST=0.0.0.0，让 Ollama 监听所有网卡，然后重启服务。第二个原因检查防火墙规则，把 11434 端口放行。第三个原因就是仔细核对地址，容器内访问宿主机用host.docker.internal，跨机器访问用实际 IP。

我踩过的一个坑是：改了OLLAMA_HOST之后忘了重启服务，结果一直连不上，排查了半天才发现是没生效。所以改完环境变量一定要重启 Ollama 进程。

4.3 报错三：知识库检索结果为空或答非所问

这个不是硬报错，但比报错更让人头疼。表现是文档明明上传成功了，提问时模型却说"没有找到相关信息"，或者答的内容和文档对不上。原因一般出在检索环节。

第一个可能是嵌入模型和生成模型不匹配，比如嵌入用的是中文模型，生成用的是英文为主的模型，语义空间对不上。第二个可能是切分参数不合理，文档被切得太碎，检索出来的片段没有完整语义。第三个可能是相似度阈值设得太高，导致本来相关的片段被过滤掉了。

解决办法是：先确认嵌入模型选对，中文文档用中文嵌入模型；再调整切分长度和重叠；最后适当降低相似度阈值，或者增加召回数量。Dify 的检索设置里可以调这些参数，建议先用默认值跑通，再逐步微调。

5. 几个容易被忽略的实操心得

5.1 模型存储路径一定要提前规划

这件事我在前面提过，但值得单独说。Ollama 默认把模型存在用户目录下，Windows 是C:\Users\你的用户名\.ollama，Linux 是~/.ollama。模型动辄十几个 G，C 盘很快就红了。正确做法是安装后第一件事就设OLLAMA_MODELS环境变量，指向一个大分区。

改路径的时机很重要，最好在拉第一个模型之前就设好。如果已经拉了一堆模型再改，需要手动把旧目录的文件移过去，否则 Ollama 会重新下载。移动的时候注意保持目录结构一致。

5.2 小模型做知识库到底行不行

经常有人问，7B 这种小模型做 RAG 够不够用。我的实测结论是：检索质量比模型大小更重要。RAG 的效果，七成取决于检索准不准，三成取决于模型会不会组织语言。如果检索出来的原文就是对的，7B 模型完全能给出像样的回答。反过来，如果检索出来的内容是错的，再大的模型也是胡说八道。

所以与其纠结模型大小，不如把精力花在文档质量、切分策略、嵌入模型选择上。当然，如果显存允许，14B 在语言组织上确实比 7B 更顺，尤其是处理长文档总结的时候。

5.3 知识库里的图片怎么处理

这是很多人卡住的地方。纯文本 RAG 处理不了图片，因为向量化只针对文字。图片有两条处理路径：一是用 OCR 把图片里的文字提取出来，当成文本处理；二是用多模态模型直接理解图片内容，生成图片描述，再把描述存进知识库。

第一条路径适合扫描件、截图这类以文字为主的图片。第二条路径适合图表、流程图这类以视觉信息为主的图片。目前 Dify 的知识库对图片的原生支持有限，通常需要你在上传前先做预处理。如果图片量大，建议写个脚本批量处理。

5.4 关于离线安装包的获取思路

离线安装包的核心价值是绕开在线下载。获取思路是：在一台网络通畅的机器上把模型拉下来，然后打包OLLAMA_MODELS目录，拷贝到目标机器上，设置好环境变量指向这个目录，Ollama 就能识别。注意模型文件的目录结构不能乱，每个模型一个子目录，里面有 manifest 和 blob 文件。

这个办法在完全断网的环境里特别有用，比如内网机器。打包的时候注意压缩，模型文件压缩率不高，但能省一点空间。

6. 后续可以怎么扩展这套方案

跑通基础流程之后，有几个方向可以继续深挖。一是接入更多数据源，比如把笔记软件、文档系统里的内容自动同步到知识库，Dify 支持 API 方式导入，可以写个定时任务。二是优化检索策略，比如引入重排序模型，先粗召回再精排，能明显提升准确率。三是多模型组合，用一个小模型做意图识别和路由，把不同类型的问题分发给不同的模型处理。

还有一个方向是把知识库封装成 API 对外提供服务，Dify 本身就支持把应用发布成 API，这样你的其他工具、脚本都能调用这个知识库。这一步做完，它就不只是一个玩具，而是一个真正能嵌入工作流的组件了。

我自己在实际操作中的体会是，本地部署这件事，第一次跑通最费时间，因为要踩各种环境坑。但一旦跑通，后面换模型、加文档、调参数都是几分钟的事。所以别被前面的报错吓退，把环境理顺了，剩下的就是享受离线可用的便利。