文档堆了三个硬盘，员工找资料还是靠问人；制度规范更新了十几次，有人永远拿着旧版当标准答案。这是我经手过的知识库项目里最典型的场景，问题从来不在“有没有文档”，而在“能不能在需要的时候精准找到、还能负责任的引用”。今年我自己搭过、也帮企业落地过几套本地私有化 AI 知识库方案，目前最顺手、技术上最不折腾、软件成本几乎为零的组合，就是标题这套：Dify 做应用编排和知识库底座，DeepSeek 管理解与生成。这篇不是产品介绍，是我从零开始完整走一遍的思路、步骤和踩坑记录，想给准备做企业内网 AI 知识库、又不想被商业软件按席位收费绑死的人一个真正能落地的参考。

1. 方案选型：为什么是 Dify + DeepSeek，而不是其他组合

1.1 企业知识管理到底难在哪

老式企业知识库通常是一个搜索框加一堆分类目录，背后是倒排索引和关键词匹配。员工想查“上季度客户投诉的处理时效标准”，搜索引擎只认“投诉”和“时效”这种字面同时出现的文档，一旦文档里写的是“客户反馈应在三个工作日内闭环”，这一条就找不出来。这不是搜索引擎的错，是关键词匹配天生理解不了语义。

传统知识库的第二个问题是“有结果无答案”。检索系统给了二十个文档标题，用户还得一个个打开自己判断哪个才是对的。对一线员工来说，他要的是一句准确的答复和出处，不是一个文件列表。第三个问题更麻烦：文档更新靠人工维护，旧版本没有强制下架机制，知识库里同一件事有三个互相矛盾的说法。这些问题叠加在一起，导致知识库建设投入越大、维护越累、员工越不爱用，最后沦为存档工具。

RAG（检索增强生成）思路恰好能同时解决这三件事：先用向量检索把语义相近的片段找出来，再让大模型基于这些片段组织回答，最后给出引用来源。用户问一句话，系统给出有依据的答案，而不是二十个标题。而本地私有化部署，是为了让这个过程发生企业内网里，文档不出门。

1.2 私有化知识库的核心诉求

企业在知识管理上真正在意的东西，我观察下来其实是四条：

一是数据安全。产品规格、客户信息、财务制度这些文档，几乎都不可能接受上传到公有云知识库。即便合同里写了数据隔离，法务和大客户那一关也过不去。数据必须留在自己的服务器上。二是权限管理。不同部门之间知识互相隔离，不能一个账号进去能看到全公司所有文档。三是访问可控。知识库不是一个“能用就行”的玩具，得有人管账号、看日志、控制谁能改文档谁能提问。四是长期成本。按用户数收年费的知识库产品，几百人规模的企业一年下来是一笔不小的开支，而且知识量越大、用量越高、账单越贵。

想清楚这四条，自建路线基本就是唯一选择了。剩下的问题是：用哪套东西搭。

1.3 Dify + DeepSeek 的组合优势

Dify 是一个开源的 LLM 应用开发平台，社区版可以完整私有化部署。它自带的不只是知识库管理，还有模型供应商接入、可视化工作流编排、Agent、API 发布和用户权限，等于把“做一个 AI 应用”所需的大部分配套都做好了。用 Docker Compose 起一套服务，后台界面上就能传文档、分段、建索引、编排问答流程，这对没有专门算法团队的绝大多数企业来说，是快速上线最现实的路径。

DeepSeek 的价值主要体现在中文理解能力和开源友好度上。中文场景下它对长文本、专业术语、口语化提问的把握，都不比同类模型差，而且模型权重开放。想要零软件成本，就意味着大模型这个最贵的环节不能用闭源收费 API 硬撑，DeepSeek 给了本地私有化一个现实选项。

我经常被问“为什么不用商业知识库 SaaS”。拿对比数据说话更直观：

1.4 “零成本”到底指哪些成本

我必须先说清楚，免得有人抱着错误预期开工。零成本，指的是软件授权和模型调用这两个最大头为零：Dify 社区版开源免费，DeepSeek 模型权重开放可下载且在本地推理不产生 token 费。但服务器硬件、运维人员的工时、文档整理的人工，这些投入不可能为零，也不应该省。如果你的服务器已经存在，只是新起几个容器，那这套方案的新增软件成本确实可以做到几乎为零。这也是“零成本”最严谨的理解。

2. 架构梳理与部署环境评估

2.1 一个知识库应用由哪几部分组成

别看概念多，一套 RAG 知识库拆开就五个角色：

用户提问后，先经过 Dify 编排的应用入口；入口把问题交给知识检索层，在这一层把问题转换成向量，去向量数据库里找语义相近的文档片段；找到的片段连同原始问题一起组装成提示词，发给大模型；大模型生成回答后再通过界面或 API 返回给用户。

一句话类比：知识库像档案室，文档都按语义分好了架位，检索员根据问题挑出几份最相关的档案，讲解员（大模型）只看这几份档案，用你自己的话整理出一份带出处的答复。

这套架构里有两个模型各管一段，很容易被人忽略：对话模型负责“理解和生成”，Embedding 模型负责“文本转向量”。很多人在 Dify 里只配了对话模型，建知识库索引时报错，就是因为少了 Embedding 这一环。后文我会在接入模型的部分专门讲。

2.2 硬件配置怎么定

先明确一个原则：你的硬件需求由“要不要把大模型跑在本地”决定。如果只通过 API 方式调用 DeepSeek，那么服务器只是跑 Dify 和向量库，压力很小。如果连模型都要本地化部署，那就要重点算显卡和内存。

我按项目经验整理了一张参考表，注意这是“能跑”的下限而非“跑得好”的推荐值：

纯 CPU 跑 7B 量化模型不是不行，但生成速度会让人着急，平均每秒几个 token，适合内部体验，不适合多人同时高频使用。GPU 能带来的提升是数量级的，有条件上 GPU 就直接上。

2.3 企业内网环境下的基础组件准备

部署 Dify 离不开 Docker 和 Docker Compose。在干净的 Linux 服务器上，先把这两样装好，然后确认服务器能访问需要用到的镜像仓库。完全隔离的内网环境也常见，那我就提前在能联网的机器上拉好镜像和模型权重文件，打包复制进内网，再离线导入 Docker。正规项目基本都用这套流程，不复杂，但要注意镜像平台架构别搞错，x86 和 ARM 的镜像不通用。

Dify 依赖的持久化组件包括 PostgreSQL、Redis 和向量数据库。Docker Compose 会一并拉起，这些都不需要单独安装，但提前规划数据盘位置很重要。我通常把数据目录单独挂在容量充足的数据盘上，而不是塞进系统盘，否则后续文档和向量数据膨胀，系统盘满了会很被动。

3. Dify 服务端部署实录

3.1 获取安装包与目录结构

Dify 的部署方式以 Docker Compose 为主。在服务器上找个合适目录，从 Dify 官方仓库克隆代码就行。命令很简单：

git clone <Dify 官方仓库地址> dify cd dify/docker ls -la

不用纠结克隆到哪个路径，但建议路径别带中文和空格。进入docker目录后你会看到docker-compose.yaml、.env.example，以及存放持久化数据的volumes目录。.env.example是环境变量模板，部署的第一步是把它复制成.env再修改。这里有个新手最容易犯的错：直接拿默认模板启动。Dify 有一些密钥和密码字段，是安全相关的配置，默认值在生产环境绝对不能直接用。

3.2 先改好 .env 再启动

.env里字段不少，但真正必须改的就几个。第一个是SECRET_KEY，它用于登录态加密和敏感数据签名，用 OpenSSL 生成一个随机值填进去：

openssl rand -base64 42

第二个是访问端口EXPOSE_NGINX_PORT，默认是 80。如果服务器上 80 被其他服务占了，改成 8080 之类的高位端口。这决定了用户以后访问知识库的地址，顺便把反代需要的域名也规划好，后面变动端口会牵扯到已发布的 API 地址。

第三个是默认数据库密码POSTGRES_PASSWORD，改成强密码。虽然数据库容器默认只在内网网段暴露，但企业环境里默认口令是安全事故高发点，不值得赌。

其余配置按需调整，例如向量库类型。Dify 默认用的是 Weaviate，足够大多数场景使用。如果企业里已有独立的向量数据库集群，可以在.env里切换VECTOR_STORE配置。首次部署不建议折腾这个，先把默认跑通。

# 复制模板 cp .env.example .env # 编辑 .env 中的 SECRET_KEY、EXPOSE_NGINX_PORT、POSTGRES_PASSWORD vim .env # 启动全部组件 docker compose up -d

3.3 一键启动与初始化验证

首次启动要拉取镜像和初始化数据库，耗时取决于带宽和机器性能，耐心等几分钟。启动完成后用docker compose ps看所有容器是否处于Up状态。Dify 整套服务里有几个关键容器，我列一下方便排障时对号入座：

• api：后端 API 服务，处理所有业务请求
• worker：异步任务队列，文档索引这类重活由它干
• web：前端页面
• db：PostgreSQL 业务数据库
• redis：缓存与消息队列
• weaviate：向量数据库，存文档向量
• nginx：统一对外入口

确认容器都起来了，浏览器访问http://服务器IP:端口/install，按提示设置第一个管理员账号。这一步完成后，系统会引导你登录后台。别急着传文档，先到“设置”里把模型接好，知识库的索引工作依赖模型，没有模型配好之前所有入库操作都会卡住。

3.4 首次登录后必须做的三件事

登录进后台，我的习惯是先做三件事再继续。第一，把管理员密码改成符合企业密码策略的强密码，Dify 安装向导生成的默认密码强度不够。第二，在“成员管理”里把后续要用的同事账号建好，按职责分配角色，避免大家共用管理员账号操作。第三，在“设置”里接好模型供应商，这部分是下一章重点。三件事做完，再谈创建知识库和应用。

4. 接入 DeepSeek 大模型：API 与本地化两条路线

4.1 路线一：通过 DeepSeek API 接入

接 DeepSeek API 是最快的方式。到 DeepSeek 开放平台申请 API Key，然后在 Dify 后台的“设置 > 模型供应商”里找到 DeepSeek，填入 Key 即可。Dify 原生支持 DeepSeek，不需要额外填接口地址。模型名按用途区分：对话模型常用deepseek-chat，需要模型展示推理过程的场景用deepseek-reasoner。参数上，知识库问答的 Temperature 我习惯调低到 0.2 以下，让输出更忠实于检索到的文档，减少自由发挥。

这条路线适合满足两个条件的企业：服务器能访问互联网、文档内容可以脱敏后出域调用模型。成本上，DeepSeek 的 API 按 token 计费，日常问答的体量开销很低。但要注意，API 方式本质上是把用户问题发到外部服务，数据不出域这个诉求就不成立了。很多企业采购流程走到安全评审这关，都会因为这个被否掉。所以 API 通常是我用来做功能验证和技术预演的首选，真正生产环境还是看本地化路线。

4.2 路线二：在本地服务器部署 DeepSeek 开源模型

本地部署大模型，我用的最多的工具是 Ollama。它把模型下载、量化、启动推理这些事情包装得很简单，适合没有专业推理优化经验的人上手。安装完成后的关键动作是让 Ollama 监听所有网卡，否则默认只允许本机访问，Dify 容器里是连不上的。Linux 下设置环境变量重启服务即可：

# 以环境变量方式启动 export OLLAMA_HOST=0.0.0.0:11434 ollama serve

接着拉取需要的 DeepSeek 模型。原版 DeepSeek-V3 这类超大模型权重有几百 GB，绝大多数企业本地硬件跑不动，现实选择是蒸馏版模型，既保留不错的推理能力，参数量又降到了可以部署的范围：

ollama pull deepseek-r1:7b # 需要更好效果可以上 14b 或 32b ollama pull deepseek-r1:14b

在 Dify 后台新增 Ollama 供应商，接口地址填http://宿主机IP:11434，模型名填deepseek-r1:7b，保存后测试连通。这里有一处高频踩坑点：Dify 容器与宿主机之间的网络模式。如果用 Docker 默认的 bridge 网络，容器访问宿主机不能写localhost，必须写宿主机的实际内网 IP；如果用 host 网络模式则可以直接写localhost。两种模式对应不同的 Base URL，写错就报连接失败。

我还得提醒一句，生产环境跑模型建议用 vLLM 这类推理引擎，吞吐和并发能力比 Ollama 好不少；但 Ollama 做内部知识库足够。

4.3 Embedding 模型怎么解决

接入 DeepSeek 解决了“生成回答”的问题，但建知识库索引还需要一个把文本变成向量的模型。有些读者会问“DeepSeek 不能做向量化吗”，目前它没有开放官方的 Embedding 接口。实战里我的一般做法是继续用 Ollama 拉一个开源 Embedding 模型：

ollama pull bge-m3

然后在 Dify 的 Ollama 供应商配置里，同样新增一条 Embedding 类型的模型配置。这样对话走 DeepSeek，向量化走 bge-m3，各司其职。Embedding 模型的选择直接影响检索召回质量，不能随便拿个玩具模型顶事。bge-m3 在中文场景表现不错，支持 8192 长度的输入，企业文档常用的段落规模它都接得住。实在不想在 Embedding 上占用本机资源，也可以选商用的 Embedding API，按量付费，但这就又牵涉到数据出域问题了。

4.4 两条路线的决策表

把两条路线放在一起对比，选择标准就很清晰：

我的建议很直白：先在能联网的机器上用 API 把整个 Dify 流程跑通，让业务团队确认效果；确认可行后，再根据数据合规要求决定要不要转本地模型。这样不会一上来就投入买显卡的钱，等到真的把需求验证清楚了，采购审批也好做。

5. 知识库建设：从原始文档到可检索的数据资产

5.1 知识库结构规划

模型接好后，开始处理文档。我见过不少团队拿到系统就疯狂上传文档，把所有 PDF 堆进一个库里，结果检索质量惨不忍睹。知识库的结构规划，应该先于文档上传。

按业务主题和部门边界分库，是最基础的做法。比如“人力资源制度库”“产品技术手册库”“客户服务话术库”。原因是不同主题的文档语义空间差异很大，混在一起会让向量检索的区分度下降。另一个维度是权限：不同团队的人应该只能看到自己的库。Dify 里每个知识库可以单独管理访问范围，分库之后再分配权限，比在单一库里做文档级控制容易得多。

命名规范也值得提前定。知识库名称、文档标题、文档内部标签统一格式，能让后续维护的人少费无数口舌。我一般建议在文档标题前加业务域前缀，比如“客服-退款流程-2025版”，这样不管在界面里还是在日志里，来源一目了然。

5.2 文档清洗与格式转换

上传文档之前，先做一次人工清洗。这一步的 ROI 是所有环节里最高的，比任何参数调优都管用。

优先统一格式。Dify 支持 PDF、Word、Markdown、TXT 等常见格式，但同样的内容用不同格式表示，解析结果差异很大。我的经验是内部制度类文档尽量转成 Markdown 或经过排版的 PDF 再入库，表格复杂的文档转 Word 或 HTML 保留结构。扫描版 PDF 必须先做 OCR，否则 Dify 抽出来的是白纸。手机拍照的图片、带着页眉页脚的扫描件、Excel 里混排的单元格，这些是文档解析乱码的重灾区，宁可花时间预处理，也不要指望后处理能救回来。

去敏感信息这一条要严格执行。知识库的权限隔离在 Dify 里是“库”级别的，如果一个库里混了不该让该库用户看到的内容，就出问题了。上传前人工删掉身份证号、银行账号这类字段，如果原文确实需要保留，至少单独放一个高权限库。

5.3 分段策略与参数

文档处理的关键参数是分段长度和重叠长度。Dify 默认分段长度约 500 token、重叠 50 token，但这个默认值只是通用模板，不同文档类型需要不同策略。

分段太长，一个片段里混入多个主题，检索时召回的内容会包含无关信息；分段太短，语义不完整，向量表达也会失真。我的经验是：FAQ 类文档每条问答作为一个独立分段，长度 100~200 token 就足够；流程制度类按章节分段，单段控制在 300~800 token；技术手册这类长文段落到 800 token 以内。

重叠的作用是防止两个分段边界把一句话拦腰截断，让语义断裂。每段与前一段保留 50~100 token 的重叠，成本很低但效果明显。Dify 的自定义分段支持按分隔符切分，常见做法是按\n\n或标题层级切。分段完成后，抽几条实际切片看边界是否合理，这一步不能省，我几乎每次都能发现一两处规则切出来的离谱片段。

5.4 索引与检索模式选择

Dify 建索引时提供几种模式。高质量模式会把文档交给 Embedding 模型生成向量，检索时按语义匹配，这是知识库问答的默认选择。经济模式只用关键词索引，适合对精度要求低、文档量巨大的场景，但它本质上还是老式搜索引擎，我不建议在正式问答里用。

适合企业生产环境的是混合检索：向量检索负责召回语义相近的内容，关键词检索负责锁定精确术语，两者结果合并后再做去重和重排。Dify 新版对混合检索和 Rerank 都有支持。Rerank 是重排环节，对召回的候选片段做二次精排，效果提升明显，前提是要配置重排模型。同样可以用 Ollama 拉一个 bge-reranker 系列模型，部署成本和 Embedding 类似。如果硬件还能接受，我强烈建议加上重排这一步，它解决的是“找回来的内容里哪个才是真正的答案”这个最后一百米问题。

5.5 知识库的生命周期维护

知识库不是静态仓库，文档过期是必然的。我在项目里会给维护团队定一个简单流程：文档更新时，先在原库中禁用旧版本，上传新版本，重新触发索引；下架文档不是删除记录，而是保留归档，便于审计追踪。Dify 的索引更新支持单篇文档重新索引，不用整库重建，日常更新很方便。

定期清理也很重要。一般业务制度文档三个月内就会有版本更替，半年以上的旧版本如果还留在默认检索范围里，就会和最新要求打架。我养成的习惯是每个季度翻一遍各知识库的“未命中”报告，把长期无人问津的文档检查一遍，该下架就下架。这比任何检索调参都更能维持知识库的长期可用性。

6. 应用编排：把知识库变成一个真正能问答的机器人

6.1 创建应用与基础 Prompt 设计

知识库建完，下一步是创建应用。在 Dify 前台选择“聊天助手”类型，这适合会话式问答。新建后第一件事是写好系统提示词。提示词决定了大模型的行为边界，对知识库问答来说，核心要求有三条：只依据提供的资料回答，不得自行脑补；如果资料无法回答问题，明确说不知道；回答末尾标注引用的来源编号。

一个基础模板长这样：

你是企业内部知识助手。请严格依据上下文中的资料回答用户问题。 如果资料不包含答案，请直接说明“资料中没有找到相关内容”，不要编造。 回答时标注引用来源编号，例如【来源3】。

模板里的“上下文”来自知识检索节点注入的字段，这个变量名要和后面搭建工作流时用的名字保持一致，否则内容传不到大模型那里。Dify 聊天助手自带“引用与归属”功能，打开后系统会把检索到的文档片段和回答一起返回给前端，界面可以展示来源链接，这对“负责任地回答”很关键。

6.2 编排 RAG 工作流

聊天助手可以在“编排”页拖拽出来一条完整链路。标准 RAG 流程是四个节点：开始、知识检索、大模型、结束。每个节点负责一段职责，我在项目里一直是这么搭的。

开始节点定义用户输入的变量，默认对话变量即可。知识检索节点选择目标知识库，把用户问题作为查询输入。这个节点是整套流程的引擎，检索质量在这里决定。大模型节点把知识检索返回的片段和用户问题拼进提示词，调用配置好的 DeepSeek 模型生成回答。结束节点把大模型输出返回给用户，如果需要附带引用来源，就把知识检索结果中的原文档信息一并输出。

如果遇到多知识库的复杂问答，可以在中间加条件分支或代码节点做逻辑处理，但第一个版本不要试图做得太复杂。简洁链路更容易排查问题，上线一段时间后再根据实际需求增加路由、改写等高级节点，是更稳妥的路径。

6.3 调优：回答质量的关键参数表

上线前必须做一轮参数调优。三个参数影响最大：召回数量、相似度阈值、生成温度。

召回数量我习惯从 8 开始，观察检索结果里相关片段是不是排在前列。如果 Top8 里只有一两条真正有用，就把 TopK 调小并降低阈值，确保有用的内容不被相似度过滤掉；如果 Top8 里混入大量不相关内容，说明分段或 Embedding 模型有问题，该去调知识库而不是继续提高数量。

6.4 对话调试与效果验证

Dify 编排页提供调试面板，可以在发布前反复提问。调试时我不会只问标准问题，会准备三组测试集：直接命中型问题、语义改写型问题、知识库外的问题。直接命中型测试检索是否正常；语义改写型测试向量检索的语义理解能力，比如把“退款几天到账”换成“钱什么时候退回”；知识库外的问题测试大模型会不会硬编，理想的回答应该是“资料中没有找到相关内容”。

调试面板里最值得看的是每次回答下方的“引用”数据，能直观看到大模型到底用了哪些文档片段。如果引用片段和答案对不上，问题出在检索环节；如果引用了正确片段但回答还是乱讲，问题出在提示词或模型参数。这个排查路径能省下大量瞎调的时间。

调试通过后，把应用发布为 Web App 或 API。Web App 适合直接给内部员工用，API 更适合嵌入现有 OA 或企微机器人。记得在应用设置里生成访问密钥，不要裸奔在公网上。

7. 企业级落地：权限、安全与运维治理

7.1 账号与权限模型

应用能跑通只是第一步，真正上线还要过安全和运维这道关。Dify 的角色体系分四个层级：所有者、管理员、编辑者、普通成员。所有权和管理员负责系统配置、模型供应商、全局的设置；编辑者可以创建和维护知识库与应用；普通成员只能使用被分配的应用。企业内部落地时，知识库管理员和应用使用者的角色必须分离，否则一个普通用户误操作改了知识库内容，影响的是所有人。

知识库级别也要做授权。Dify 支持单独设置知识库可被哪些应用或成员访问。按部门分库之后，每个部门的知识库只对本部门的团队成员开放，从数据访问层面做隔离。这个动作要作为上线 checklist 的一条，我见过因为漏配导致客服看到了产品研发内部资料的事故，影响很大。

7.2 数据安全与审计

私有化的核心价值是数据留在自己手里，但“留在自己手里”不等于天然安全。传输层要启用 HTTPS，应用对外只通过 Nginx 暴露必要端口，数据库、Redis、向量库这类后端服务不要对公网开放访问端口。Dify 的容器网络默认只在内部互通，不要在docker-compose.yaml里随意加端口映射到宿主机。

审计方面，Dify 自带对话日志和应用日志。每次问答、每次知识检索、每个模型调用都会产生记录，至少保留 180 天。涉及敏感业务时，我会额外让运维团队把日志接入企业已有的日志平台，做集中审计。人工删除知识库文档、修改权限配置这类操作，默认不留痕，企业要求严格的话要考虑二开或外部审计日志系统来补充。

数据和配置的备份，比日志更要紧。需要备份的包括：PostgreSQL 数据库里的全部业务数据、向量数据库的持久化目录、上传的源文件目录、以及.env配置文件。Dify 的 docker 卷默认都在volumes目录下，把整个目录定期备份即可。数据库层面执行pg_dump更稳妥，恢复路径更清晰。备份策略按数据重要程度定，一般内部知识库每日增量、每周全量就够。

7.3 运维观测

Dify 的服务由多个容器组成，线上出问题第一件事就是看日志：

# 查看 api 容器日志 docker compose logs -f api # 查看异步任务日志 docker compose logs -f worker # 查看全部容器资源占用 docker stats

日常运维我关注四个指标：API 响应耗时、问答接口错误率、向量库磁盘占用、模型推理节点负载。资源使用率持续升高时，优先考虑增加 worker 副本数来分担异步任务压力。Dify 支持docker compose scale调整副本数量，API 和 worker 都能扩。向量库磁盘空间要留足余量，索引文件占用的增长往往比预想快。

版本升级不要贪新。升级前先看官方发版说明，确认不存在破坏性变更，备份数据和配置后，再停服务、拉新镜像、启动。跨大版本升级尤其要谨慎，Dify 这类系统的大版本可能引入数据库结构变更，直接原地跳版本升级容易出现兼容问题。

8. 高频问题与避坑实录

8.1 容器起不来，怎么定位

最常见的启动失败原因是端口冲突。默认 80 端口被占用时，容器反复重启，页面打不开。改.env里的EXPOSE_NGINX_PORT，然后重启。其次常见的是 Docker 版本过旧，Compose 语法不兼容，报错会直接提示字段错误。升级 Docker 到新版本即可。如果修改过SECRET_KEY之后又回退配置，数据库里已有的会话会失效，登录会异常。生产环境改SECRET_KEY前先备份，改完后重新登录一次。

8.2 文档一直显示“处理中”或索引失败

文档上传后状态卡住，八成都和 worker 容器有关。先看 worker 日志有没有报错，再检查 Embedding 模型是否配置正确。一个很典型的错误是：只配置了对话模型 DeepSeek，没有配置 Embedding 模型，索引任务一直在队列里重试。另一个坑是文档本身是扫描版 PDF，文件能上传，但解析出的是空文本，索引自然失败。上传前先用 PDF 阅读器抽查两页，确保有文本层。

8.3 回答不引用知识库内容

模型回答得挺好，但完全不提来源，看起来像是自己在天马行空。这种情况优先检查提示词里有没有明确要求“标注来源”，没有的话模型默认不会主动给编号。另一个原因是知识检索节点返回了空结果，大模型拿不到任何上下文，就只能自己发挥了。用调试面板看知识检索节点的输出，如果是空的，回到第 8.2 节排查索引问题。

8.4 检索效果差

检索不精准的原因很多，按我的排查顺序来：先看文档分段是否合理，一段几百字里面杂糅了多个主题的话，召回结果一定乱。再看索引是否走的是高质量模式，经济模式关键词检索对语义问法基本无效。再看 Embedding 模型是不是太弱，中文场景换 bge-m3 这类专门优化的模型有质的提升。最后用混合检索加 Rerank，把候选片段精排一遍。这套组合拳打完，检索效果基本能到可交付水平。

8.5 硬件不够用怎么办

硬件紧张时有几条降级路线。第一，Embedding 模型换小一号的，比如 bge-small，牺牲少量精度换速度。第二，对话模型用更低量化级别，7B 量化到 Q4 后显存占用降低接近一半。第三，知识库索引切换经济模式，绕过向量化流程，仅做关键词检索，虽然语义能力下降，但 CPU 和内存压力大幅下降。第四，限制同时在线用户数，Dify 的 Web App 访问可以加访问密钥，限制到内部小组试用，避免全员同时拥入把服务打垮。

我个人在多个项目里最深的体会是：知识库问答的瓶颈从来不是大模型选的有多强，而是文档整理得够不够干净、分段够不够合理、检索链路有没有闭环。Dify + DeepSeek 这个组合最大的价值，是让团队能专注在这些真正影响效果的事情上，而不必从零造轮子。如果你准备动手，我的建议是先用一小批真实业务文档跑通全流程，再逐步扩展，第一批文档的质量决定了这套系统在业务眼里是“有用”还是“又一个系统”。