企业官网建设流程全解析

1. 为什么要在本地跑DeepSeek加知识库

把DeepSeek装进自己电脑，再挂一个本地知识库，这件事我从去年折腾到现在，前后重装过四五次环境，踩过的坑比写过的代码还多。最开始的想法很简单：手头有一堆技术文档、项目笔记、会议纪要，散落在各个文件夹里，想查个东西得靠系统搜索一个个翻，效率低得让人抓狂。后来用上了在线大模型，确实方便，但把公司内部资料往上传，心里总是不踏实。于是就有了这套方案——Ollama负责跑模型，DeepSeek负责理解内容，知识库负责存资料，三者串起来就是一个完全离线的私人问答系统。

这套东西能做什么？你可以把PDF、Word、Markdown、TXT这些文件丢进去，然后用自然语言提问，比如“上个月那个接口文档里超时时间设的多少”“项目复盘里提到的三个风险点是什么”，它能把相关段落找出来，再让DeepSeek组织成一段通顺的回答。整个过程不联网，数据不出本机，适合对隐私有要求、又不想花大价钱买在线API额度的朋友。零基础也能跟着做，我会把每一步的命令和参数都写清楚，包括我遇到的那三个报错是怎么解决的。

适合谁看？如果你是开发者、运维、产品经理，或者只是对本地大模型感兴趣的技术爱好者，这篇文章都能帮你省下至少一个周末的折腾时间。我尽量不堆术语，用“人话”把原理讲明白，再配上可直接复制的命令。下面进入正题。

2. 整体方案设计与选型思路

2.1 为什么是Ollama而不是其他推理框架

市面上本地跑模型的工具不少，llama.cpp、vLLM、Text Generation WebUI各有各的用法。我选Ollama，核心原因就三个字：省事。它把模型下载、量化、显存调度、API服务全打包好了，一条ollama run就能跑起来，不用自己编译CUDA内核，也不用折腾Python依赖冲突。对于我这种只想快点用上、不想在环境配置上耗一整天的人来说，Ollama的性价比最高。

当然它也有代价。Ollama默认的并发能力弱，适合个人或小团队，不适合高并发生产环境。但本地知识库场景本来就是单人或者几个人用，这个短板可以接受。另外Ollama对模型格式有要求，必须是GGUF或者它自己转换过的格式，好在DeepSeek的蒸馏版本在社区里都有现成的GGUF文件，直接拉就行。

2.2 DeepSeek模型版本怎么挑

DeepSeek家族型号很多，满血版671B显然不是普通人能本地跑的。实际落地时，我推荐从DeepSeek-R1-Distill-Qwen系列入手，常见的有1.5B、7B、14B、32B几个规格。选哪个取决于你的显存：

我自己的机器是16GB显存的卡，跑14B的Q4量化版很流畅，32B就有点吃力，回答速度会掉到每秒三四个字。如果你显存只有8GB，老老实实上7B，别硬撑，否则模型加载到一半就OOM（显存溢出）了。这里有个经验：显存占用大约是模型文件大小的1.2倍，因为推理时还要留出KV Cache的空间。比如7B的Q4文件约4.5GB，实际运行要占5.5GB左右。

2.3 知识库方案为什么选Dify

知识库这块，可选的有LangChain手搓、FastGPT、Dify、RAGFlow等。我最终用Dify，理由是它把文档解析、切片、向量化、检索、重排整条流水线都做成了可视化界面，不用写代码就能调参数。对于不熟悉RAG（检索增强生成）细节的人来说，Dify的上手成本最低。

Dify的知识库流水线大致是这样：上传文档后，先做文本提取，再按设定长度切片，然后调用Embedding模型把每片转成向量存进向量数据库，提问时把问题也转成向量，做相似度检索，把最相关的几片喂给DeepSeek生成答案。整个链路里，Embedding模型的选择很关键，我后面会细说。

2.4 三者如何串起来

整体架构分三层：Ollama作为模型服务层，对外暴露一个兼容OpenAI格式的API；Dify作为应用层，负责知识库管理和对话界面；DeepSeek作为推理层，被Ollama加载后供Dify调用。数据流向是：你在Dify界面提问 → Dify检索知识库 → 把检索结果和问题拼成Prompt → 通过API发给Ollama → Ollama调用DeepSeek生成回答 → 返回给Dify展示。

这个设计的好处是解耦。模型可以换，知识库可以换，界面也可以换，只要API协议对得上就行。我试过把Ollama换成vLLM，Dify那边只改一个Base URL就切换成功了，非常灵活。

3. 环境准备与Ollama安装实操

3.1 硬件与系统的最低要求

先说底线配置。CPU至少四核，内存16GB起步，硬盘留出50GB空间（模型文件加向量库加日志）。显卡不是必须的，纯CPU也能跑，但7B模型在CPU上大概每秒出两三个字，体验很差。有N卡最好，显存6GB以上就能跑7B。系统方面，Windows 10/11、macOS、Linux都行，我下面以Windows和Linux为主，macOS命令基本一致。

有个细节容易被忽略：Ollama默认把模型存在C盘（Windows）或用户主目录（Linux），模型动辄几个GB，C盘很快就红了。所以安装前最好先规划好存储路径，后面我会讲怎么改。

3.2 Ollama下载与安装的加速技巧

Ollama官网下载安装包，Windows是exe，Linux是一行脚本，macOS是dmg。国内直接下可能会很慢，我实测用迅雷或者IDM多线程下载能快不少。Linux用户如果curl脚本卡住，可以先把安装脚本下载到本地再执行：

curl -fsSL https://ollama.com/install.sh -o ollama_install.sh bash ollama_install.sh

如果连脚本都下不动，那就找一台网络好的机器下好安装包，再用U盘拷过去，这就是所谓的离线安装包思路。安装完成后，终端输入ollama --version，能显示版本号就说明装好了。

3.3 修改模型存储路径的正确姿势

这一步强烈建议在拉模型之前做，否则后面迁移很麻烦。Windows下，Ollama的模型默认在C:\Users\你的用户名\.ollama\models。改路径的方法是设置环境变量OLLAMA_MODELS：

1. 右键“此电脑” → 属性 → 高级系统设置 → 环境变量
2. 新建系统变量，变量名OLLAMA_MODELS，变量值填你想要的路径，比如D:\ollama\models
3. 重启Ollama服务（任务管理器里结束ollama进程，再重新启动）

Linux下更简单，编辑systemd服务文件：

sudo systemctl edit ollama.service

在打开的编辑器里加入：

[Service] Environment="OLLAMA_MODELS=/data/ollama/models"

保存后执行sudo systemctl daemon-reload && sudo systemctl restart ollama。验证是否生效，可以拉一个小模型，看文件是不是出现在新路径下。

3.4 拉取DeepSeek模型的命令与参数

路径改好后，开始拉模型。以7B的Q4量化版为例：

ollama pull deepseek-r1:7b

这个命令会从官方仓库下载。如果下载慢，可以配置国内镜像源。Ollama本身没有内置镜像设置，但可以通过设置OLLAMA_HOST指向镜像服务，或者手动下载GGUF文件后用ollama create导入。手动导入的方式更可控：

# 先写一个Modelfile echo 'FROM ./deepseek-r1-7b-q4.gguf' > Modelfile ollama create my-deepseek -f Modelfile

拉完后用ollama list查看，能看到模型名和大小就对了。第一次运行ollama run deepseek-r1:7b会加载模型，看到>>>提示符就可以对话了。测试一句“你好”，如果几秒内出字，说明推理正常。

4. Dify知识库搭建与DeepSeek对接

4.1 Dify的部署方式选择

Dify有两种用法：云端版和本地版。既然我们追求数据不出本机，肯定选本地部署。官方推荐用Docker Compose，一条命令拉起所有依赖：

git clone https://github.com/langgenius/dify.git cd dify/docker docker compose up -d

等几分钟，浏览器打开http://localhost:3000，设置管理员账号就能用了。这里有个坑：Dify默认会拉一堆镜像，包括PostgreSQL、Redis、Weaviate等，国内网络下可能卡在拉取环节。解决办法是给Docker配置镜像加速，或者提前把镜像下好。我实测整个Dify栈占内存约4GB，加上Ollama跑的模型，16GB内存的机器刚好够用，建议32GB更从容。

4.2 在Dify中接入Ollama的DeepSeek

Dify装好后，进入“设置” → “模型供应商”，找到Ollama，点添加模型。关键参数有三个：

• Base URL：填http://host.docker.internal:11434（Docker内部访问宿主机Ollama的地址）
• 模型名称：填你ollama list里看到的名字，比如deepseek-r1:7b
• 模型类型：选LLM

填完点保存，Dify会发一个测试请求，如果Ollama在运行，就能看到绿色的成功提示。如果报连接错误，八成是Base URL写错了，或者Ollama没监听外部请求。Ollama默认只监听127.0.0.1，Docker容器访问不到，需要设置环境变量OLLAMA_HOST=0.0.0.0再重启服务。

4.3 Embedding模型的选择与配置

知识库检索的质量，一半取决于Embedding模型。Dify默认用OpenAI的Embedding，但我们要离线，所以得换成本地的。Ollama可以拉Embedding模型，比如nomic-embed-text：

ollama pull nomic-embed-text

然后在Dify的模型供应商里，同样用Ollama接入这个模型，类型选“Text Embedding”。配置好后，新建知识库时就能选它作为向量化模型。这里提醒一句：Embedding模型一旦选定，知识库建好后就不要换，因为不同模型生成的向量维度不同，换了会导致检索全乱，只能重建知识库。

4.4 知识库创建与文档上传的细节

新建知识库，选“通用”类型，分段设置里有两个关键参数：分段标识符和分段最大长度。默认按换行分段，最大长度500字符。我的经验是，技术文档按500到800字符切比较合适，太小会丢上下文，太大检索精度下降。重叠长度设50到100，保证切片之间有连续性。

上传文档时，Dify支持PDF、Word、Markdown、TXT等。PDF如果是扫描件，提取出来是乱码，需要先做OCR。图片里的文字，Dify本身不处理，得先用OCR工具转成文本再上传。这就是热词里“rag知识库能存储图片嘛”的答案：能存图片文件，但检索时只能匹配到图片的描述文本，图片内容本身不参与语义检索，除非你额外做多模态处理。

5. 三个报错的完整排查过程

5.1 报错一：Ollama拉模型卡在pulling manifest

这个报错我遇到不下五次，表现是ollama pull执行后一直停在pulling manifest，进度条不动。原因通常是网络到官方仓库的连接不稳定。解决办法有三个层次：

第一，换时间段重试，凌晨或清晨成功率更高。第二，配置HTTP代理，在终端里设置export HTTPS_PROXY=http://你的代理地址:端口，注意这里只是让下载走代理，不涉及其他用途。第三，手动下载GGUF文件再导入，这是最稳的方式。GGUF文件可以在一些模型社区找到，下载后用前面说的ollama create导入。

我个人的习惯是，常用模型提前下好GGUF存到移动硬盘，换机器时直接拷过去导入，省得每次重新拉。

5.2 报错二：Dify调用Ollama报Connection refused

Dify里测试模型时提示Connection refused，或者对话时报Failed to connect to Ollama。这个问题的根源是Docker容器和宿主机之间的网络隔离。容器里的localhost指的是容器自己，不是宿主机。所以Base URL不能写http://localhost:11434，要写http://host.docker.internal:11434。

如果写了还是不通，检查Ollama是否监听所有网卡。Linux下执行ss -tlnp | grep 11434，如果显示127.0.0.1:11434，说明只监听本地。设置OLLAMA_HOST=0.0.0.0后重启，再查应该变成0.0.0.0:11434。Windows下则是检查防火墙有没有拦11434端口，临时关闭防火墙测试一下就能定位。

5.3 报错三：知识库检索结果答非所问

这个不算硬报错，但比报错更让人头疼。表现是提问后，DeepSeek给出的答案跟问题不相关，或者明明文档里有答案却检索不到。排查思路分三步：

先看切片质量。打开知识库的“分段”列表，随机点几段看看，如果切片把一句话从中间截断，或者把标题和正文切散了，那检索肯定不准。调整分段长度和重叠度重新索引。

再看Embedding模型。如果用的是很老的模型，语义理解能力弱，同义词匹配不上。换成nomic-embed-text或者bge-m3这类较新的模型，效果提升明显。

最后看检索参数。Dify默认的相似度阈值是0.5，Top K是3。如果文档多、问题细，可以把Top K调到5到8，阈值降到0.3，让更多候选片段进入重排。重排模型（Rerank）如果开了，效果会更好，但会多占一点显存。

5.4 常见问题速查表

6. 实操心得与性能调优建议

6.1 让回答更准的几个参数微调

Dify的对话应用里，有几个参数直接影响输出质量。**温度（Temperature）**建议设0.1到0.3，知识库问答要的是准确，不是创意，温度高了模型容易自由发挥。最大Token数设1024到2048，太短答案被截断，太长浪费显存。上下文条数指的是把几轮对话历史带给模型，知识库场景设3到5轮就够，太多会稀释检索结果的重要性。

还有一个隐藏技巧：在Prompt里明确要求“只根据提供的参考资料回答，不要编造”。DeepSeek本身比较听话，加上这句约束后，幻觉明显减少。我试过不加这句，问一个文档里没有的问题，它会自己编一个看似合理的答案，加了之后就老实说“资料中未提及”。

6.2 显存不够时的降级方案

显存紧张时，除了换小模型，还有两个办法。一是调整Ollama的并行数，设置OLLAMA_NUM_PARALLEL=1，减少同时处理的请求数，省显存。二是启用量化KV Cache，Ollama支持OLLAMA_KV_CACHE_TYPE=q8_0，把缓存从FP16降到8位，能省一半缓存显存，代价是精度略降，实测对问答质量影响很小。

如果实在跑不动，可以把Embedding和重排放到CPU上跑，只让DeepSeek用GPU。Dify里可以分别配置不同模型的运行设备，灵活组合。

6.3 知识库长期维护的经验

知识库不是建完就完事，得定期维护。我的做法是按项目或主题分库，不要把所有文档塞进一个库。库越大，检索噪声越多。每个库单独调分段参数，技术文档和会议纪要的切法不一样。

另外，文档更新后要及时重新索引。Dify支持增量更新，但有时候旧向量没清干净，会出现新旧内容同时被检索到。遇到这种情况，删掉旧文档重新上传最保险。我一般每个月做一次全量重建，顺便清理过时资料。

6.4 关于离线与数据安全的补充

整套方案跑通后，我特意拔掉网线测试，所有功能正常，说明确实做到了完全离线。数据方面，文档存在本地PostgreSQL和向量库里，模型文件在本地磁盘，对话记录也在本地，没有任何数据外传。对于处理敏感资料的朋友，这一点是刚需。

需要提醒的是，Ollama的API默认没有鉴权，局域网内其他机器能直接访问。如果机器在公共网络，记得设置OLLAMA_HOST=127.0.0.1只允许本机访问，或者在前端加一层反向代理做认证。这个细节很多人忽略，等到发现别人能随便调用你的模型才后悔。

7. 后续可以怎么扩展

这套本地DeepSeek加知识库的架子搭好后，能玩的花样不少。比如把Dify的API接到自己的笔记软件里，写东西时随时问一句；或者接一个语音转文字的前端，做成语音问答；再或者把多个知识库组合成一个工作流，先查技术文档再查会议纪要，最后让模型综合回答。

我最近在试的是把知识库和代码仓库联动，提交代码时自动把变更说明索引进库，以后查“这个函数为什么这么改”就能直接问出来。这个还在折腾中，跑通了再单独写一篇。如果你也跟着这篇把环境搭起来了，遇到新的报错，欢迎按上面的排查思路先自己走一遍，大部分问题都能定位到。