简介DeepSeekDify本地部署知识库是一份面向大模型爱好者、开发者和企业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我一般按这张表拍板维度OllamavLLM部署难度低一条命令高要配 Python 环境和启动参数并发能力低适合个人和小组高适合团队或生产显存控制自动按需分配手动设置gpu-memory-utilization知识库场景数据量小、验证为主文档量大、检索频繁推荐度先跑通再换确认长期使用后再迁移别一上来就上 vLLM我见过太多人在环境依赖里耗掉一晚上。先用 Ollama 把业务跑通再评估是否要换推理引擎。2.2 Dify 知识库流水线从 PDF 到可检索片段要过六道闸Dify 的知识库模块把 RAG 流程做成了可视化流水线你要理解的不是界面按钮而是背后六个环节文件解析、内容清洗、分段切分、向量化、写入向量库、检索召回。文件解析把 PDF、DOCX、Markdown 转成纯文本内容清洗去掉页眉页脚和多余空行分段切分按固定长度或分隔符把长文切成块向量化用 embedding 模型把每个块变成一维数组写入向量库后每次问答先做相似度检索再交给 DeepSeek 组织答案。流水线环节Dify 里的对应位置常见参数文件解析创建知识库 → 上传文件单文件大小限制分段切分分段设置最大分段长度、重叠长度向量化索引方式 → 高质量embedding 模型写入向量库存储位置Weaviate / Qdrant检索召回应用 → 知识检索节点TopK、Score 阈值生成LLM 节点DeepSeek 模型、System Prompt格式复杂的 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 拉起 Dify8 个容器一次起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 psgit clone拉下来的源码里真正起作用的只有docker目录里的编排文件和.env配置。.env是全局配置入口里面有几个参数要提前改VECTOR_STOREweaviate指定向量库类型UPLOAD_FILE_SIZE_LIMIT控制知识库单文件上限内网部署常要调大到50以上。首次启动会拉取多个镜像耗时取决于网络耐心等。容器全部变为running后浏览器访问http://服务器IP/install创建管理员账号。3.3 在 Dify 里接入 DeepSeekhost.docker.internal 这一层必须打通这时候最容易翻车的地方来了Dify 跑在容器里Ollama 装在宿主机上两边要打通必须用对地址。Dify 容器里访问宿主机要写host.docker.internal而不是localhost。在 Dify 后台操作路径设置 → 模型供应商 → Ollama填写 Base URL 为http://host.docker.internal:11434Model Type 选 LLMModel 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 EmbeddingModel Name 填bge-m3。3.4 建知识库、挂应用用 curl 验证整条链路模型接好后创建知识库知识库 → 创建知识库 → 上传文档 → 分段设置选“自动” → 索引方式选“高质量” → 确认保存。此时 Dify 会调用 embedding 模型把文档向量化并写入 Weaviate。接着创建应用应用 → 创建应用 → 空白应用在对话型应用里关联刚才的知识库。验证整条链路最直接的方式是用 APIcurl --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 阈值决定低于多少分的片段直接丢弃。三者必须联动调只动一个会顾此失彼。参数推荐值调整方向召回模式混合检索关键词精确匹配 语义相似度互补TopK5 ~ 8答案不完整就调大噪声多就调小Score 阈值0.3 ~ 0.5查不到就调低混入不相关内容就调高Rerank开启用重排模型给候选片段二次打分我见过太多人把 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_LENGTH8192 # 重启 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 后面加verifyFalse这类参数硬跳过校验后患无穷。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 能吃能跑”的阶段。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek本地部署+Dify知识库搭建全指南：从选型到避坑
简介DeepSeekDify本地部署知识库是一份面向大模型爱好者、开发者和企业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我一般按这张表拍板维度OllamavLLM部署难度低一条命令高要配 Python 环境和启动参数并发能力低适合个人和小组高适合团队或生产显存控制自动按需分配手动设置gpu-memory-utilization知识库场景数据量小、验证为主文档量大、检索频繁推荐度先跑通再换确认长期使用后再迁移别一上来就上 vLLM我见过太多人在环境依赖里耗掉一晚上。先用 Ollama 把业务跑通再评估是否要换推理引擎。2.2 Dify 知识库流水线从 PDF 到可检索片段要过六道闸Dify 的知识库模块把 RAG 流程做成了可视化流水线你要理解的不是界面按钮而是背后六个环节文件解析、内容清洗、分段切分、向量化、写入向量库、检索召回。文件解析把 PDF、DOCX、Markdown 转成纯文本内容清洗去掉页眉页脚和多余空行分段切分按固定长度或分隔符把长文切成块向量化用 embedding 模型把每个块变成一维数组写入向量库后每次问答先做相似度检索再交给 DeepSeek 组织答案。流水线环节Dify 里的对应位置常见参数文件解析创建知识库 → 上传文件单文件大小限制分段切分分段设置最大分段长度、重叠长度向量化索引方式 → 高质量embedding 模型写入向量库存储位置Weaviate / Qdrant检索召回应用 → 知识检索节点TopK、Score 阈值生成LLM 节点DeepSeek 模型、System Prompt格式复杂的 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 拉起 Dify8 个容器一次起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 psgit clone拉下来的源码里真正起作用的只有docker目录里的编排文件和.env配置。.env是全局配置入口里面有几个参数要提前改VECTOR_STOREweaviate指定向量库类型UPLOAD_FILE_SIZE_LIMIT控制知识库单文件上限内网部署常要调大到50以上。首次启动会拉取多个镜像耗时取决于网络耐心等。容器全部变为running后浏览器访问http://服务器IP/install创建管理员账号。3.3 在 Dify 里接入 DeepSeekhost.docker.internal 这一层必须打通这时候最容易翻车的地方来了Dify 跑在容器里Ollama 装在宿主机上两边要打通必须用对地址。Dify 容器里访问宿主机要写host.docker.internal而不是localhost。在 Dify 后台操作路径设置 → 模型供应商 → Ollama填写 Base URL 为http://host.docker.internal:11434Model Type 选 LLMModel 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 EmbeddingModel Name 填bge-m3。3.4 建知识库、挂应用用 curl 验证整条链路模型接好后创建知识库知识库 → 创建知识库 → 上传文档 → 分段设置选“自动” → 索引方式选“高质量” → 确认保存。此时 Dify 会调用 embedding 模型把文档向量化并写入 Weaviate。接着创建应用应用 → 创建应用 → 空白应用在对话型应用里关联刚才的知识库。验证整条链路最直接的方式是用 APIcurl --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 阈值决定低于多少分的片段直接丢弃。三者必须联动调只动一个会顾此失彼。参数推荐值调整方向召回模式混合检索关键词精确匹配 语义相似度互补TopK5 ~ 8答案不完整就调大噪声多就调小Score 阈值0.3 ~ 0.5查不到就调低混入不相关内容就调高Rerank开启用重排模型给候选片段二次打分我见过太多人把 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_LENGTH8192 # 重启 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 后面加verifyFalse这类参数硬跳过校验后患无穷。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 能吃能跑”的阶段。希望帮到你。本文还有配套的精品资源点击获取