企业官网建设流程全解析

简介：DeepSeek+Dify本地部署知识库是一份面向大模型爱好者、开发者和企业IT人员的实操型图文笔记，旨在帮助不具备深厚技术背景的用户快速完成AI知识库的本地搭建与运行。整个资源仅含1个PDF文档，压缩后大小约1.47MB，但内容密度较高：文档以Windows 11为运行环境，完整梳理了从系统环境变量OLLAMA_MODELS配置到Ollama安装、DeepSeek-R1 8B及embedding模型bge-m3拉取，再到Docker Desktop设置和Dify开源应用平台接入的部署链路，每一步都配有界面截图与可复制的命令，方便读者边看边做。目前已有2338人学习下载，属于社区验证过的高热度资料。对于希望摆脱云端依赖、在本地构建私有AI知识库的初学者和进阶用户而言，这份笔记既能提供全局部署思路，也能作为具体操作时的查错手册，能有效降低本地部署门槛、节省摸索时间。

1. 把 DeepSeek 本地部署下来，再接上 Dify 搭一套知识库问答，第一反应大多是“省 API 费”

但真在制造、政务、金融内网里待过的人会明白：省的是钱，要的是文档不出内网。RAG 知识库本质是“文档切碎—向量化—检索—让大模型照着说”的流水线，DeepSeek 负责生成，Dify 负责把流水线编排成可维护的系统，本地部署则是把整套东西圈在自己机房或工作站里。这套方案适合两类人：一是文档涉密、网络受限的企业 IT，二是被碎片化工具搞得疲惫的自建玩家。下面按选型、最小系统、调参、避坑、进阶的顺序走，照着做完能跑通，坑也一次性列给你。

2. 选型先立住：DeepSeek、Dify、向量库三者怎么分工不打架

很多新手上来就docker compose up，结果模型装了三套，知识库却谁都连不上。选型顺序错是最大的坑。我习惯先把三个角色定义清楚：DeepSeek 是生成模型，负责把检索到的片段组织成答案；Dify 是编排平台，负责文档解析、分段、向量化、检索、提示词组装；向量库是检索底板，负责把文档片段存成向量并快速比对。三者是流水线关系，不是叠加关系。

2.1 本地部署大语言模型的两种路径：Ollama 适合起步，vLLM 适合扛并发

本地部署 DeepSeek 的主流方式有两类。单机试验、知识库规模在几千份文档以内、并发个位数，用 Ollama 最省事；要对公网或内部多人同时提供服务、要求高吞吐低延迟，就要上 vLLM 这类推理引擎。Ollama 的本质是把模型量化、显存调度、API 服务打包成一个黑匣子，一条命令就能把模型跑起来；vLLM 则给你 PagedAttention、连续批处理这些优化手段，代价是配置复杂度明显上升。

# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取 DeepSeek-R1 7B 量化版 ollama pull deepseek-r1:7b # 拉取一个本地 embedding 模型 ollama pull bge-m3 # 验证模型是否能正常对话 ollama run deepseek-r1:7b "你好，用一句话介绍你自己"

这条命令隐含两个重要参数：deepseek-r1:7b里的7b表示 70 亿参数，Ollama 默认拉取的是 Q4_K_M 量化版本，体积约 4.7GB，显存占用在 6GB 左右。如果你的显卡只有 8GB 显存，这个版本是安全起点；有 16GB 以上显存再考虑deepseek-r1:14b，回答质量会有可感知的提升。bge-m3是给后面知识库做 embedding 用的，不要漏装。

选 Ollama 还是 vLLM，我一般按这张表拍板：

别一上来就上 vLLM，我见过太多人在环境依赖里耗掉一晚上。先用 Ollama 把业务跑通，再评估是否要换推理引擎。

2.2 Dify 知识库流水线：从 PDF 到可检索片段要过六道闸

Dify 的知识库模块把 RAG 流程做成了可视化流水线，你要理解的不是界面按钮，而是背后六个环节：文件解析、内容清洗、分段切分、向量化、写入向量库、检索召回。文件解析把 PDF、DOCX、Markdown 转成纯文本；内容清洗去掉页眉页脚和多余空行；分段切分按固定长度或分隔符把长文切成块；向量化用 embedding 模型把每个块变成一维数组；写入向量库后，每次问答先做相似度检索，再交给 DeepSeek 组织答案。

格式复杂的 PDF，特别是扫描件和双栏论文，直接让 Dify 解析会丢结构。常见做法是先用 MinerU 这类版面解析工具把 PDF 转成 Markdown 再入库，分段质量会明显提升。这一条建议刻在你团队的知识库维护手册里。

2.3 Embedding 模型与向量库怎么选：别让 1024 维拖垮检索速度

很多人把精力全花在选大模型上，embedding 随便挑一个，结果检索结果永远不对。本地部署场景里，embedding 模型决定了“文档被理解到什么程度”。我常用bge-m3，它是 1024 维输出，支持中文、英文和跨语言检索，在 Dify 里可以直接挂到 Ollama 上，不需要额外起服务。别再选那些需要在线调用的云端 embedding，那就违背了本地部署的初衷。

向量库的选择更简单：文档量在百万级以内，直接用 Dify 默认的 Weaviate 就够；想省内存换成 Qdrant 也可以；数据量再大才需要考虑 Elasticsearch。你在配置界面看到的“高质量索引方式”就是指用 embedding 模型做向量检索，而“经济索引方式”是关键词倒排，两者可以混合用。

3. 跑通最小系统：Ollama、Dify、DeepSeek 一次串起来

选型定下来后，落地路径就很清晰了。我建议你在同一台机器上先跑通最小系统：一台带 NVIDIA 显卡的 Linux 主机，装上 Ollama 和 Dify，再把知识库挂上去。整个流程四步：装 Ollama 拉模型、用 Docker Compose 起 Dify、配置模型供应商、创建知识库并验证问答。

3.1 装 Ollama 并拉取 DeepSeek：模型名里的 7b 是什么意思

Ollama 的安装脚本会顺便把 systemd 服务配好，装完就能通过11434端口提供 API。先别急着拉模型，确认 GPU 驱动和 CUDA 是否被识别：

# 检查 Ollama 是否识别 GPU ollama ps # 如果上面命令没有输出模型，先运行一次模型再查 ollama run deepseek-r1:7b "显存测试"

ollama ps会列出当前加载的模型和显存占用。如果显示GPU列是空白的，说明 Ollama 在用 CPU 跑，回答会慢到让人怀疑人生。常见原因是 Nvidia 容器工具没装好，或者驱动版本太老。确认无误后，进入下一步。

3.2 用 Docker Compose 拉起 Dify：8 个容器一次起

Dify 社区版通过 Docker Compose 分发，拉下来的镜像会自动编排 API 服务、Worker、Web 前端、Sandbox、向量库等 8 个以上容器。

# 拉取 Dify 源码 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 启动全部容器 docker compose up -d # 查看容器状态 docker compose ps

git clone拉下来的源码里，真正起作用的只有docker目录里的编排文件和.env配置。.env是全局配置入口，里面有几个参数要提前改：VECTOR_STORE=weaviate指定向量库类型；UPLOAD_FILE_SIZE_LIMIT控制知识库单文件上限，内网部署常要调大到50以上。首次启动会拉取多个镜像，耗时取决于网络，耐心等。容器全部变为running后，浏览器访问http://服务器IP/install创建管理员账号。

3.3 在 Dify 里接入 DeepSeek：host.docker.internal 这一层必须打通

这时候最容易翻车的地方来了：Dify 跑在容器里，Ollama 装在宿主机上，两边要打通必须用对地址。Dify 容器里访问宿主机，要写host.docker.internal而不是localhost。在 Dify 后台操作路径：设置 → 模型供应商 → Ollama，填写 Base URL 为http://host.docker.internal:11434，Model Type 选 LLM，Model Name 填deepseek-r1:7b。

在 Linux 上光这样填还不够，Docker 默认不会把宿主机映射进容器，要手动加一行配置：

# 在 dify/docker/docker-compose.yaml 的 api 服务下加这段 extra_hosts: - "host.docker.internal:host-gateway"

加完执行docker compose up -d重建容器。这步做完后，再去模型供应商页面点“测试”，能看到模型返回成功才说明链路通了。同时把 embedding 模型也配上，类型选 Text Embedding，Model Name 填bge-m3。

3.4 建知识库、挂应用，用 curl 验证整条链路

模型接好后，创建知识库：知识库 → 创建知识库 → 上传文档 → 分段设置选“自动” → 索引方式选“高质量” → 确认保存。此时 Dify 会调用 embedding 模型把文档向量化并写入 Weaviate。接着创建应用：应用 → 创建应用 → 空白应用，在对话型应用里关联刚才的知识库。

验证整条链路最直接的方式是用 API：

curl --location --request POST 'http://localhost/v1/chat-messages' \ --header 'Authorization: Bearer app-xxxxx' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "报销流程是什么", "response_mode": "blocking", "user": "test-user" }'

app-xxxxx是应用访问凭证，在应用页面左侧的“API 访问”里能看到。执行后如果返回一段合理的答案，说明从文档解析、向量化到检索生成的整个流水线已经打通。如果返回报错，按返回错误信息去对应排查，后面避坑章节会详细列。

4. 知识库参数调优：分段、TopK、上下文窗口配合着调

系统跑通只是开始，知识库回答质量高低，全靠参数微调。RAG 的黄金法则是“检索决定上限，生成决定下限”——检索出来的是垃圾，DeepSeek 再强也编不出花。这一章的三个参数组，是我每次调知识库必动的：分段规则、召回设置、上下文长度控制。

4.1 分段策略：先把“切错”这个源头问题解决

Dify 分段设置里有两套方案：自动分段和自定义分段。自动分段适合快速验证；要追求质量，必须用自定义。自定义分段的核心参数有三个：分隔符、最大分段长度、重叠长度。分隔符告诉系统在哪里下刀，最大分段长度限制每一块的字数，重叠长度让相邻两块保留公共区域，避免语义被切断。

{ "mode": "custom", "rules": [ { "delimiter": "\\n\\n", "max_tokens": 800, "overlap_tokens": 100 } ] }

这段配置的意思是：按双换行符把文档切成段落，每段不超过 800 token，切完后下一段带上上一段末尾的 100 token 作为重叠。800 这个值对技术文档很合适，长段落会被拦腰截断，短段落则保持完整；重叠 100 是经验值，太少会丢上下文，太多会浪费向量库容量。

不同文档类型要用不同分段策略。技术方案、产品说明书用“分隔符 + 800/100”；法律合同这种长条款文本，把最大长度降到 500、重叠降到 50，防止一个完整条款被切散；FAQ 问答集则用固定长度 500，因为每个问答本身就是一个独立语义单元。如果你要存的文档里有图片，注意 RAG 文本链路默认不保留图片，图片要单独做多模态索引，别指望全文检索能搜到截图里的内容。

4.2 召回设置：TopK、Score 阈值与混合检索的搭配

Dify 的应用编排里，知识检索节点有三个关键参数：召回模式、TopK、Score 阈值。召回模式决定用哪种方式找文档片段，TopK 决定召回多少个候选片段，Score 阈值决定低于多少分的片段直接丢弃。三者必须联动调，只动一个会顾此失彼。

我见过太多人把 Score 阈值调到 0.8，结果知识库几乎回答不了任何问题。阈值设太高，会把大量语义相近但表达不同的合法片段拦在门外；设太低，又会把八竿子打不着的文档塞给大模型。正确做法是先调低阈值保证“查得到”，再靠 TopK 和 Rerank 保证“查得准”。混合检索模式是默认推荐，纯向量召回对专有名词、型号、编号这类精确信息非常不友好。

4.3 上下文超长怎么办：把窗口让给真正有用的片段

本地部署 DeepSeek 后，最常碰到的报错是“上下文超长”或“token 耗尽”。原因很直接：Ollama 默认给模型开的上下文窗口只有 4096 token，而知识库检索出来的多个片段加起来动辄两三千 token，再加上 System Prompt 和用户问题，很容易把窗口塞满。

解决思路不是盲目调大上下文窗口，而是先做减法。把 TopK 从 8 降到 3，让 LLM 只看最相关的三段；开启 Rerank，让重排模型把最可能包含答案的片段排到最前面；同时把知识检索节点的“引用”Mode 设为只返回引用文本而不附加大段原文档。做完这些还不够，再考虑把 Ollama 的上下文窗口调大：

# 设置 Ollama 服务允许的最大上下文长度 # 在 /etc/systemd/system/ollama.service 或用户环境变量中加入 OLLAMA_CONTEXT_LENGTH=8192 # 重启 Ollama 生效 systemctl daemon-reload && systemctl restart ollama

这里有个取舍要讲清楚：OLLAMA_CONTEXT_LENGTH调大到 8192 后，显存占用会跟着涨。7B 量化模型原本只要 6GB 显存，上下文翻倍后可能要多吃 2GB。小显存机器宁可减小 TopK 也不硬扛长上下文。如果你的业务场景确实需要读很长的合同条款，换 14B 模型配 16GB 显存是更稳的路。

5. Dify + DeepSeek 本地知识库避坑：5 个高频翻车现象与解法

这套方案我前后搭过不下十次，每次翻车点基本都集中在同一批问题上。下面按现象、原因、解决的格式写，能帮你少走大量弯路。

5.1 凭据校验失败：Dify 里的容器找不到宿主机上的 Ollama

现象：在 Dify 模型供应商页面配置 Ollama 后点击测试，提示An error occurred during credentials validation。

原因：Dify 跑在 Docker 容器里，localhost指向的是容器自己，不是宿主机。Linux 系统下 Docker 默认不启用host.docker.internal这个域名，导致请求根本发不到 Ollama。

解决：在docker-compose.yaml的 api 和 worker 服务下都加上extra_hosts: ["host.docker.internal:host-gateway"]，然后重新创建容器。不想动 compose 的话，直接填宿主机内网 IP，比如http://192.168.1.100:11434，也能通。

5.2 知识库一直“排队中”：embedding 进程卡住或向量库没就绪

现象：上传文档到知识库后，文档状态一直显示“排队中”，进度条不动。

原因：三个常见原因。一是 Weaviate 容器没正常运行，向量库写不进去；二是 embedding 模型名称没配对，Dify 在 Ollama 里找不到bge-m3；三是 embedding 模型首次拉取时网络中断，模型文件不完整。

解决：先跑docker compose ps确认 weaviate 是 running；再查 worker 容器日志docker compose logs worker，里面会有具体报错。如果日志提示拉取模型超时，大概率是网络问题，内网环境请提前在有网机器上ollama pull bge-m3，把镜像导出后带到内网加载。

5.3 SSL 错误：自签 HTTPS 服务被 Dify 拒之门外

现象：配置模型供应商或调用知识库时频繁报 SSL 错误。

原因：如果你把 Ollama 或别的模型服务套了一层自签 HTTPS 证书（比如用 Nginx 反代），Dify 服务端默认会校验 SSL 证书链，自签证书当然过不了。

解决：内网环境直接用 HTTP 内部地址，不要为省事加自签 HTTPS；如果安全策略强制要求加密传输，就把自签证书导入 Dify 容器所在系统的信任库，而不是在 URL 后面加verify=False这类参数硬跳过校验，后患无穷。

5.4 离线插件装不上：内网部署 Dify 的插件依赖要提前备好

现象：内网环境打开 Dify 插件市场，列表加载失败，工作流插件无法安装。

原因：Dify 插件中心默认从远程仓库拉取插件信息和安装包，离线环境没有外网，自然装不上。

解决：在有网的机器上进入 Dify 插件市场，搜到需要的插件后下载.difypkg文件，拷贝到内网，在插件管理页选择本地导入，上传安装。这个功能对离线部署非常友好，缺点是插件事后升级还得冲一次外在操作，建议把下载的插件包统一归档到内部制品库。

5.5 大模型自说自话：回答看着流畅，但内容不是文档里的

现象：知识库应用回答得很流畅，但仔细核对发现内容来自模型幻觉，不是文档原文。

原因：检索的空转——用户问题传入后，知识检索节点没有召回任何片段，或召回的片段与问题完全不相关，大模型只能临场发挥编答案。

解决：打开应用调试面板，查看知识检索节点的召回结果，确认是否有片段返回。然后看两件事：知识库是否真的关联到了应用上，以及 Score 阈值是否设高导致全部片段被过滤。最后在 System Prompt 里写死约束：“只基于提供的文档内容回答，如果文档中没有相关信息，直接说没有。”这一句提示词，能把幻觉率压下去一大半。

6. 进阶：混合检索、Rerank 与十问评测法，把知识库从“能用”推到“好用”

基础版跑通后，想再提升一个档次，我建议做三件事：打开混合检索、接入重排模型、建立一套自己的评测问答集。

混合检索的价值在于让两种互补信号同时生效：关键词检索擅长精确匹配型号、编号这类硬信息，向量检索擅长理解语义相近的说法。在 Dify 知识检索节点把召回模式切到“混合检索”，权重按 4:6 分配，关键词占四成、语义占六成，遇到“我要报销 2024 年的差旅费”这类含精确年份和专有名词的问题，混合模式明显更稳。

重排模型则是给“先粗后精”的流程兜底。把 TopK 调大到 20，让召回阶段放宽口径多捞一些候选片段，再用bge-reranker-v2-m3做精排，从 20 个候选中选出最相关的 3 个送入大模型。这是因为向量召回的排序质量并不可靠，重排模型会逐条计算 query 与片段的语义相关性，排序更准。

参数怎么调都不能靠玄学。我自己习惯每次调整后跑一遍十问评测集：准备 10 个典型业务问题，其中一半来自文档原文，一半是换了说法的同义问法，还有一两个故意问文档里不存在的内容。逐条记录系统是否回答正确、引用的片段是否来自正确文档、回答是否超过了上下文限制。跑完后对比数据，再决定下一步调 segmentation 还是 TopK。我现在每改一次知识库配置，就在本地脚本里把这十个问题全部跑一遍，输出现场打分表，练出来的评测集就是团队最有价值的数字资产。

这套组合拳打下来，本地知识库才算真正脱离了“demo 能吃能跑”的阶段。希望帮到你。

本文还有配套的精品资源，点击获取