企业官网建设流程全解析

1. 为什么要在本地跑DeepSeek：从数据边界到响应速度的取舍

把大模型跑在自己机器上这件事，最早吸引我的并不是什么技术情怀，而是一次很具体的尴尬。当时我在整理一批内部技术文档，想让模型帮忙做摘要和问答，结果发现只要走在线接口，文档内容就得先上传到别人的服务器。哪怕对方承诺不留存，从流程合规的角度看，这一步就已经过不去了。后来我干脆花了一个周末，把DeepSeek的蒸馏版本拉到本地，用Ollama跑起来，再挂一个知识库，整套链路完全离线，这才算把心里的石头放下。

本地部署DeepSeek这件事，核心价值其实就三条：数据不出本机、响应不受网络波动影响、调用成本可控。前两条不用多解释，第三条很多人会忽略——在线API按token计费，你如果只是做内部文档检索问答，一天几百次调用下来费用并不低，而本地跑一次推理的电费几乎可以忽略。当然代价也明显：本地能跑的通常是7B、8B这类蒸馏或小参数版本，推理能力和满血版有差距，复杂逻辑推理会露怯。所以我的定位很明确：本地版负责"基于我的资料回答问题"，不负责"替我写复杂代码或做深度推理"。

Ollama在这个链路里扮演的角色，是把模型下载、量化格式、推理引擎、API服务这几件麻烦事打包成一个命令行工具。你不用去折腾CUDA版本、不用手动转GGUF、不用自己写HTTP服务，一条ollama run就能对话，一条ollama serve就能对外提供兼容OpenAI的接口。对于不是专门做推理优化的人来说，这个抽象层级刚刚好。

知识库这一层，解决的是"模型不知道我的私有资料"的问题。DeepSeek本身的知识截止到训练时间，你问它公司内部某个项目的接口定义，它只能瞎编。RAG（检索增强生成）的思路是：把你的文档切块、向量化、存进向量库，用户提问时先检索出最相关的几段，拼进提示词里再让模型回答。这样模型不需要"记住"你的资料，只需要"读懂"检索出来的片段。

适合读这篇内容的人，我大致分三类：一是想把内部文档做成问答系统但卡在部署环节的开发者；二是对本地大模型好奇、想先跑通一个最小可用demo的技术爱好者；三是已经在用Ollama但知识库那一步一直没跑通、被各种报错劝退的人。下面我会按"装Ollama→拉模型→搭知识库→修报错"的顺序讲，重点放在那些文档里不会写、但实际一定会遇到的坑上。

2. Ollama的安装与模型拉取：那些下载慢和路径爆盘的细节

2.1 安装本身很快，慢的是模型下载

Ollama的安装包在官网直接下，Windows和macOS都是双击下一步，Linux一行脚本搞定。真正让人抓狂的是装完之后拉模型那一步。DeepSeek的蒸馏版动辄4到8个G，网络稍微抖一下就可能卡在某个百分比不动，或者直接超时重来。我最早在晚上高峰期拉deepseek-r1:7b，下了四十分钟才到60%，最后还断了。

这里有个很多人不知道的点：Ollama的模型下载是支持断点续传的，你中断之后重新执行ollama pull，它会从上次的进度继续，不会从头再来。所以遇到卡住不要慌，Ctrl+C掉重新拉就行。另外如果你所在网络对某些域名访问不稳定，可以考虑配置镜像源，把拉取地址指向国内可访问的镜像，速度会有明显改善。具体做法是设置环境变量OLLAMA_HOST指向镜像服务，或者在Ollama的配置里改registry地址，不同版本配置方式略有差异，建议以你安装版本的官方说明为准。

还有一个容易被忽略的细节：模型默认存在系统盘。Windows下默认在C:\Users\你的用户名\.ollama\models，Linux在/usr/share/ollama/.ollama/models或用户目录下。一个7B模型加上后续可能拉的embedding模型，轻松吃掉十几个G。如果你的系统盘本来就紧张，拉到一半报"no space left on device"是很常见的。解决办法是提前改存储路径：

# Linux/macOS，设置环境变量后重启ollama服务 export OLLAMA_MODELS=/data/ollama/models # Windows，在系统环境变量里新增 OLLAMA_MODELS=D:\ollama\models

改完之后记得把之前下了一半的模型目录清掉，否则Ollama可能还在旧路径找文件，出现"模型存在但加载失败"的诡异现象。

2.2 选哪个DeepSeek版本：别一上来就冲最大的

Ollama上的DeepSeek有多个规格，常见的有1.5B、7B、8B、14B、32B等蒸馏版本。我的建议是先看你显存：8G显存跑7B的量化版（Q4）比较舒服，16G可以上14B，32B基本要24G以上显存或者靠内存硬扛（速度会很慢）。

很多人一上来就想拉最大的，结果跑起来一个字一个字往外蹦，体验极差。我的实测经验是：7B在消费级显卡上做知识库问答已经够用，因为RAG场景下模型的主要任务是"根据给定片段组织答案"，而不是"从零推理"，对参数量的要求没那么高。真正影响回答质量的是检索质量，这个后面会重点讲。

拉模型的命令很简单：

ollama pull deepseek-r1:7b

拉完之后用ollama list确认，然后ollama run deepseek-r1:7b进去聊两句，确认模型本身没问题。这一步很重要，先把模型单独跑通，再去接知识库，否则后面出问题你分不清是模型的问题还是知识库的问题。

2.3 让Ollama对外提供服务

知识库框架要调用Ollama，靠的是它的HTTP接口。默认Ollama监听11434端口，启动服务：

ollama serve

如果你是在Docker里跑知识库框架，而Ollama跑在宿主机上，要注意容器内访问宿主机需要用宿主机的内网IP或者host.docker.internal（Docker Desktop支持），直接写localhost是访问不到的，这是新手最常踩的坑之一。另外如果Ollama装在另一台机器上，需要设置OLLAMA_HOST=0.0.0.0让它监听所有网卡，否则只监听本地回环，外部连不上。

提示：开放Ollama端口到局域网之前，想清楚你的网络环境是否可信。Ollama本身没有鉴权机制，任何能访问到端口的人都能调用你的模型。生产环境建议在前面加一层带鉴权的反向代理。

3. 知识库框架选型与Dify流水线搭建

3.1 为什么我最后选了Dify

搭本地知识库的框架不少，有纯代码的LangChain方案，有轻量的AnythingLLM，也有Dify这种带可视化界面的。我一开始用LangChain手写，灵活是灵活，但每次调切块参数、换embedding模型都要改代码重启，调试效率太低。后来换成Dify，最大的好处是知识库的整个流水线是可视化的：上传文档、切块、向量化、检索测试，每一步都能在界面上看到结果，调参非常直观。

Dify的部署用Docker Compose最省事，官方仓库clone下来，改一下.env，docker compose up -d就起来了。这里有个关键配置：要把模型供应商指向你本地的Ollama。在Dify的"设置→模型供应商"里选Ollama，填上Ollama的地址（注意容器网络问题，见上一节），然后就能看到你本地拉好的DeepSeek模型列表。

3.2 知识库流水线里每一步在干什么

Dify的知识库处理流程大致是：文档上传→文本提取→切块→向量化→存入向量库→检索。每一环都有坑。

文本提取阶段，PDF是最麻烦的。扫描版PDF提取出来是空白，因为它是图片不是文字，需要OCR。带复杂表格的PDF提取出来格式会乱，表格内容变成一堆错位的文字。我的经验是：能用Markdown或纯文本就别用PDF，如果必须用PDF，优先选文字版而非扫描版，表格多的文档单独处理。

切块阶段，Dify默认的切块大小是分段标识加最大长度。切太大，检索出来的片段包含太多无关信息，模型容易被干扰；切太小，一个完整的逻辑被切断，模型拿到的上下文不完整。我一般把最大长度设在500到800字符之间，重叠设50到100字符，保证跨块的语义连续性。这个值没有标准答案，要拿你的实际文档测。

向量化阶段需要embedding模型。这里有个常见误区：很多人以为DeepSeek的对话模型能直接做embedding，其实不行。对话模型和embedding模型是两回事，你需要单独拉一个embedding模型，比如nomic-embed-text或者bge-m3。在Dify里配置好embedding模型后，知识库才能正常向量化。

# 拉一个embedding模型 ollama pull nomic-embed-text

检索阶段，Dify支持向量检索、全文检索和混合检索。混合检索通常效果最好，因为它同时考虑语义相似度和关键词匹配，对于包含大量专有名词的技术文档尤其明显。纯向量检索遇到"MySQL 1064错误"这种具体错误码时，可能因为语义泛化而漏掉精确匹配的片段。

3.3 知识库里能不能放图片

这是被问得很多的一个问题。严格说，传统RAG知识库处理的是文本，图片本身不参与向量化。但有两种变通做法：一是用多模态模型对图片生成文字描述，把描述存进知识库；二是用支持图文混合检索的框架，把图片和对应文本一起索引。Dify目前对图片的处理主要是提取其中的文字（OCR），图片的视觉内容本身不进检索。所以如果你有一堆架构图、流程图，指望模型"看懂图"是不现实的，得先把图里的信息转成文字。

4. 三个高频报错的完整排查链路

4.1 报错一：连接Ollama失败（connection refused）

这个报错通常出现在Dify配置好模型后，测试连接时提示无法连接到Ollama。排查链路我一般这么走：

第一步，确认Ollama服务在跑。ollama list能列出模型说明服务正常，如果这条命令都报错，那是Ollama本身没启动，先ollama serve。

第二步，确认端口和地址。在宿主机上curl http://localhost:11434/api/tags，能返回JSON说明接口通。如果这条不通，检查Ollama是不是只监听了回环地址。

第三步，如果是Docker里的Dify连宿主机的Ollama，这是重灾区。容器里的localhost指的是容器自己，不是宿主机。Linux下要用宿主机的内网IP（ip addr查），Docker Desktop下可以用host.docker.internal。改完地址后记得在Dify里重新测试连接。

第四步，检查防火墙。宿主机防火墙可能拦了11434端口，尤其是Windows的防火墙，第一次启动Ollama时会弹窗询问是否允许，如果当时点了拒绝，后面就一直连不上，需要手动去防火墙规则里放行。

我遇到过一次特别隐蔽的：Ollama地址配对了，端口也通，但Dify就是连不上。最后发现是Dify的容器和Ollama不在同一个Docker网络里，容器间通信被隔离了。解决办法是把Ollama也用Docker跑，和Dify放同一个compose网络里，用服务名互相访问。

4.2 报错二：模型加载失败或显存不足（out of memory）

这个报错的表现是：模型明明拉下来了，但一调用就报错，或者进程直接崩掉。根因基本是显存不够。

先算一笔账：一个7B模型用Q4量化，权重大约占4到5G显存，但推理过程中还需要额外的KV Cache和中间激活值，实际占用会到6到8G。如果你的显卡是8G，跑7B刚好卡在边缘，稍微长一点的上下文就会OOM。

排查和解决思路：

• 用nvidia-smi看显存占用，确认是不是真的爆了。
• 换更小的量化版本，比如从Q4换成Q3，或者直接换更小的模型（1.5B）。
• 减少上下文长度，Dify里可以设置传给模型的上下文token上限，调小一点能显著降低显存压力。
• 如果实在显存不够，Ollama支持部分层跑在CPU上（num_gpu参数控制），速度会慢但能跑起来。

注意：不要同时加载对话模型和embedding模型到显存里还指望够用。如果显存紧张，embedding模型可以设成CPU推理，它计算量小，CPU跑也能接受。

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

这个不算传统意义的"报错"，但比报错更让人抓狂——系统不报错，就是回答不对。排查链路：

首先确认文档真的向量化成功了。Dify的知识库界面能看到每个文档的处理状态和分块数量，如果分块数是0，说明文本提取失败，多半是PDF格式问题。

其次测试检索。Dify有"召回测试"功能，输入一个问题，看它检索出哪些片段。如果检索出来的片段和问题完全不相关，那是embedding模型的问题——可能你用的embedding模型对中文支持不好，换bge-m3这类中文友好的模型试试。

如果检索片段相关但回答还是不对，那是提示词的问题。Dify的默认提示词可能不够明确，我会在提示词里强调"只根据提供的上下文回答，上下文没有的信息就说不知道"，避免模型自由发挥。

还有一个隐蔽的坑：切块把关键信息切断了。比如一个接口的参数说明跨了两个块，检索只召回其中一块，模型就答不全。解决办法是增大切块重叠，或者调整分段标识，让切块尽量在自然段落边界断开。

5. 让本地知识库真正好用的几个调优经验

5.1 文档预处理比调参更重要

我花在文档预处理上的时间，比调模型参数多得多。原始文档里全是页眉页脚、页码、无关的导航文字，这些噪声进了知识库就是干扰。我的做法是：入库前先清洗，去掉页眉页脚、统一标题层级、把表格转成Markdown、把图片里的关键信息用文字补在旁边。清洗过的文档，检索准确率能提升一大截，比你在检索参数上抠半天有效得多。

5.2 给知识库分门别类，别一锅炖

把所有文档塞进一个知识库，检索时容易串味。比如你问"部署步骤"，结果召回了"故障排查"里的内容。我的做法是按主题拆成多个知识库，或者用Dify的标签功能做分类，检索时限定范围。这样召回精度会高很多。

5.3 定期更新和清理

知识库不是建完就不管了。文档更新了，旧版本还留在库里，检索时可能召回过期信息。我一般每个月过一遍知识库，删掉废弃文档，重新向量化更新过的文档。Dify支持对单个文档重新处理，不用整个库重建。

5.4 关于小模型能不能做知识库

经常有人问，1.5B这种小模型能不能撑起知识库问答。我的实测结论是：能，但要看场景。如果知识库内容结构化程度高、问题比较固定（比如FAQ式的问答），小模型配合好的检索完全够用，而且速度快、显存占用低。但如果问题需要多步推理、需要综合多个片段的信息，小模型就容易答非所问。所以选模型规模，取决于你的问题复杂度，不是越大越好。

6. 我踩过的那些坑和最后的体会

回过头看，这套本地DeepSeek加知识库的链路，技术门槛其实不高，真正耗时间的是各种环境问题和细节调优。我印象最深的一次，是折腾了一晚上连接问题，最后发现只是Docker网络没配对。还有一次知识库检索一直不准，查了半天以为是模型问题，结果是PDF提取出来的文字全是乱码，向量化出来的东西根本没意义。

如果让我给准备上手的人一句建议，那就是：分步验证，别想着一步到位。先把Ollama跑通，确认模型能对话；再接Dify，确认能调用到模型；再传一个最简单的txt文档，确认检索链路通；最后才上你的真实文档。每一步都确认没问题再往下走，出问题时你才知道是哪一环的锅。反过来，如果你一上来就把所有东西配好然后发现不对，排查起来就是一团乱麻。

另外，本地部署这套东西，硬件是硬约束。别指望用一台办公本来跑32B模型还想要流畅体验，那不现实。根据自己的硬件选合适的模型规模，把精力放在文档质量和检索调优上，收益比死磕模型参数大得多。我现在这套7B加Dify的组合，在一台带8G显存的机器上跑内部文档问答，响应速度和准确率都够用，日常维护也简单，这才是我认为最务实的方案。