用 Dify 搭建本地知识库，让 AI 读懂你写的博客

1 序言

博客写到几十篇之后，会出现一个尴尬的情况：自己都记不清哪篇写过什么。

「我是不是写过 DD 脚本的注意事项？」「那个 AdGuard 的部署端口是几来着？」——去搜索框翻关键词，效率其实不高，因为 Markdown 搜索只认字面匹配，你换个说法它就找不到了。

大模型恰好擅长处理这个问题，前提是它能读到你的文章。 把文章交给通用在线模型有隐私顾虑，而且它根本不知道你写过什么。答案就是 RAG：用本地模型 + 自己的文章，搭一个只回答你博客内容的知识库。

本文用 Dify 完成这套链路，语言模型和向量模型全部走本地 Ollama，数据不出内网。

2 什么是 RAG（核心概念）

2.1 基础定义

RAG（检索增强生成） 是先检索、再生成的问答方式：

text

你的问题 → 向量化 → 在知识库里找最相关的几段 → 连同问题一起交给大模型 → 生成回答

关键在于中间那一步：模型不是凭记忆回答，而是拿着你提供的原文片段来回答。

2.2 RAG 与微调的区别

很多人一上来就问「要不要微调」，其实大部分「让 AI 懂我的资料」的需求都不需要：

对比维度	RAG（检索增强）	微调（Fine-tuning）
解决什么	让模型知道事实	让模型改变风格或技能
数据更新	加一篇文档即可生效	要重新训练
硬件要求	一台能跑推理的机器	需要训练显存，门槛高得多
可溯源	能指出答案出自哪一篇	不能
适合场景	文档问答、知识库	固定格式输出、专业领域语气

结论很直接：「让我写的文章能被问答」是 RAG 的典型场景，做微调是拿高射炮打蚊子，而且效果更差（幻觉更严重、无法溯源）。

3 部署 Dify

Dify 是一套完整的 RAG 应用平台，自带知识库管理、检索调参和对话界面，省去自己写前后端。

3.1 前置要求

资源：至少 2 核 4 GB 内存，知识库文章多时建议 4 核 8 GB。
磁盘：Dify 本体加向量库约 5–10 GB，另需为模型留空间。
Docker 与 Compose：已安装。

3.2 拉取并启动

bash

# 克隆官方仓库
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 生成配置文件
cp .env.example .env

启动前先改端口。 Dify 默认用 nginx 监听 80，大概率会和系统里已有服务冲突。编辑 .env：

bash

# 修改 nginx 对外端口，避开 80
EXPOSE_NGINX_PORT=8088

启动：

bash

# 首次启动会拉取多个镜像，耐心等待
docker compose up -d

# 确认所有容器都是 Up 状态
docker compose ps

应该能看到 api、worker、web、db、redis、weaviate、sandbox、plugin_daemon 等容器。任何一个反复重启都要先解决，否则后面用不了。

3.3 初始化

浏览器打开 http://你的内网IP:8088，第一次访问会要求设置管理员邮箱和密码，设置完登录即可。

4 接入本地 Ollama

Dify 需要两类模型：推理模型（生成回答）和向量模型（把文字变成向量）。两者都在「设置 → 模型供应商」里配置。

4.1 Base URL 怎么填

这是最容易踩的坑：Dify 跑在容器里，容器里的 localhost 是它自己，不是你的宿主机。

情况	Base URL 填什么
Linux 宿主机	`http://192.168.x.x:11434`（宿主内网 IP，最稳）
已配 host-gateway	`http://host.docker.internal:11434`
Ollama 在另一台机器	那台机器的内网 IP

4.2 配置步骤

「设置 → 模型供应商 → Ollama」：

模型类型：选 LLM，添加你已拉取的对话模型，如 qwen2.5:7b。
再添加一个 Embedding 类型，填向量模型，如 bge-m3。
保存后点「测试」，出现绿色对勾即成功。

⚠️ 向量模型必须单独配。只配了对话模型的话，创建知识库时会提示找不到 embedding 模型——这是新手最常见的卡点。

5 准备知识库数据

5.1 从博客导出文章

知识库的原料就是 content/blog/ 下的 Markdown 文件。Dify 支持批量上传，但一篇一文件更好用，因为检索结果能直接告诉你出自哪篇。

bash

# 把散落在各级目录的文章复制到一个临时目录，便于批量上传
cd 你的博客仓库根目录
mkdir -p /tmp/blog-kb

find content/blog -name "*.md" -not -path "*/.obsidian/*" -exec cp {} /tmp/blog-kb/ \;

# 确认数量对得上
ls /tmp/blog-kb | wc -l

建议保留 frontmatter。里面的 title、date、tags 是有价值的信息，检索时能帮模型判断文章主题。如果担心干扰，可以在上传后再用处理规则过滤。

5.2 分块策略

新建知识库时，「分段设置」决定文章怎么切。这是影响效果最大的一个参数：

参数	建议值	理由
分段标识符	`\n\n`（按段落）	技术文章天然按段落组织
最大分段长度	500 tokens	太小会丢上下文，太大会稀释相关性
分段重叠长度	50 tokens	避免正好切在关键句中间

技术教程类文章不要用固定长度硬切，因为一个命令块被切成两半，检索出来的片段就没法用了。按段落切、给足重叠，效果明显更好。

6 创建知识库与检索测试

「知识库 → 创建知识库」：

选择刚配好的 Ollama embedding 模型（如 bge-m3）；
上传 /tmp/blog-kb 下的 Markdown 文件；
分段设置按 5.2 填；
等待索引完成（bge-m3 速度中等，56 篇文章大约几分钟）。

完成后在知识库的「召回测试」标签页里试几个问题：

「AdGuard 部署在哪个端口？」
「DD 脚本重装后默认密码是什么？」
「飞牛 OS 外网访问是怎么做安全加固的？」

看召回的是什么片段，而不是看回答。 检索对了，回答自然对；检索错了，再换模型也没用。

6.1 检索模式怎么选

模式	特点	适合
向量检索	语义匹配，换个说法也能找到	中文提问（推荐）
全文检索	精确关键词匹配	查具体的命令、报错信息
混合检索	两者加权，通常效果最好	不确定时的默认选择

我的建议：中文技术博客用「混合检索」。纯向量检索对专有名词（如 strm、LXC）反而容易跑偏，全文检索能兜住。

7 组装成对话应用

知识库建好后，「工作室 → 创建应用 → 聊天助手」，在编排页里：

添加上下文：选中刚建的知识库；
推理模型：选 Ollama 里的 qwen2.5:7b；
提示词：明确告诉它基于资料回答。例如：

text

你是一个博客知识库助手。请严格根据提供的上下文回答用户问题。

规则：
1. 如果上下文里没有相关内容，直接回答「我的博客里没有写过这个」，不要编造。
2. 回答时引用出处文章的标题。
3. 涉及命令、端口、路径时，原样保留，不要改写。

第 1 条规则很重要——它把「不知道」变成了一种合法回答，能挡掉大部分幻觉。

8 实测与调优

在我的环境（RTX 3060 12G + qwen2.5:7b + bge-m3）实测：

项目	表现
索引速度	56 篇约 3–5 分钟
单次问答耗时	首字 2–4 秒，完整回答 8–15 秒
检索命中率	明确的「端口/命令/步骤」类问题基本都能召回正确文章
概念类提问	表述差异大时偶尔召回不准，需补充领域词或把文章标题写进提问

一个实用技巧：提问时带上领域词效果明显更好。问「飞牛反代雷池怎么配」比问「怎么让 NAS 安全外网访问」召回率高得多。

9 常见问题

9.1 提示找不到 embedding 模型

模型供应商里只配了 LLM，没配 Embedding。回到 4.2 补配。

9.2 上传文件后一直卡在索引中

先看 bge-m3 是否真的在跑：

bash

# 在 Ollama 宿主机上查看模型占用
docker exec -it ollama ollama ps

如果不是 100% GPU，说明显存不足降级到了 CPU，向量化会慢很多。可以换成更小的 embedding 模型，或改用 CPU 专用的 nomic-embed-text。

9.3 回答答非所问 / 一直说「没有写过」

分块太大：500 tokens 以上会让检索相关性被稀释，调小试试；
检索模式不对：换成混合检索；
文章本身没写：确认那篇内容真的在知识库里（用召回测试直接查关键词）。

9.4 内存被吃满

Dify 全家桶本身占 2–3 GB，加上模型推理，4 GB 内存机器会很紧张。可以停掉用不到的服务（如 sandbox）精简，或者把向量库换成更轻的选项。

10 总结

RAG 解决的是「事实」，微调解决的是「风格」，让 AI 读懂自己的文章用 RAG 就够了。
影响效果最大的不是模型大小，而是分块策略和检索模式，这两个值得反复调。
提示词里一定要写「查不到就说没有」，否则本地模型会一本正经地编造。
这套方案的数据全程在内网，写过的文章不必交给任何第三方。

阅读本文前建议先完成《用 Docker 部署 Ollama 与 Open WebUI 搭建本地大模型》，因为本文的推理与向量模型都依赖它。

Created with ❤️ by 张萌萌

分享文章