第 2 篇：用 Dify 搭建第一个 RAG 知识库应用

项目地址

• 在线预览：frontend-ai-assistant-two.vercel.app/
• GitHub 源码：github.com/hewq/dify-c…

说明：当前在线版本部署在 Vercel，国内网络访问可能不稳定。如果打不开，可以直接查看 GitHub 源码并在本地启动。

---

前言

上一篇我们确定了这个系列的学习目标：

从 0 到 1 做一个 AI 知识库问答系统，把 AI 应用开发、前端工程化、Node BFF、流式输出、多会话管理等能力串起来。

这一篇正式开始动手。

不过第一步我们先不写代码，而是用 Dify 搭一个最小可用的 RAG 知识库应用。

为什么先用 Dify？

因为一开始就自己写 Embedding、文本切片、向量数据库、检索召回、Prompt 组装，很容易把学习重心带偏。

对前端工程师来说，第一阶段最重要的是先理解 AI 知识库应用的完整链路：

上传文档
  ↓
文档切片
  ↓
知识库索引
  ↓
用户提问
  ↓
知识检索
  ↓
LLM 基于检索结果回答

Dify 正好可以帮我们快速跑通这条链路。

这一篇的目标很明确：

用 Dify 创建一个知识库，上传一份前端学习文档，搭建一个 Chatflow，让它能基于知识库回答问题。

---

什么是 RAG？

在正式操作之前，先简单解释一下 RAG。

RAG 全称是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。

普通大模型回答问题时，主要依赖模型自己训练时学到的知识。

但知识库问答不一样。它的流程通常是：

用户问题
  ↓
从知识库中检索相关内容
  ↓
把检索到的内容和用户问题一起交给大模型
  ↓
大模型基于这些上下文生成回答

这样做的好处是：

• 可以回答企业内部文档里的内容
• 可以减少模型胡编乱造
• 可以展示引用来源
• 可以让知识更新不依赖重新训练模型

所以，一个最小 RAG 应用至少要包含三个东西：

知识库
检索节点
LLM 回答节点

这也是我们接下来要在 Dify 里搭建的内容。

---

第一步：创建 Dify 应用

进入 Dify 控制台后，先创建一个应用。

我这里创建的是：

frontend-ai-assistant

应用类型选择 Chatflow。

为什么选 Chatflow？

因为 Chatflow 可以让我们通过节点编排来控制流程，比如：

用户输入 → 知识检索 → LLM → 直接回复

这个流程比普通 Chatbot 更清晰，也更适合后面学习 RAG 的数据流。

---

第二步：创建知识库

接下来创建一个知识库。

我创建的知识库叫：

frontend-learning-kb

这个知识库后面会存放前端学习相关文档。

第一版不用上传复杂 PDF，也不用上传公司真实文档。我们先创建一份非常简单的 Markdown 测试文档。

文件名：

frontend-notes.md

内容如下：

# 前端架构学习笔记

前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。

大型前端项目可以分为 UI 层、业务逻辑层、数据请求层、基础设施层。

性能优化重点关注 LCP、INP、CLS 三个指标。

AI 知识库系统通常包括文档上传、文本切片、向量化、检索、Prompt 组装和大模型回答。

RAG 的意思是检索增强生成，它会先从知识库中检索相关内容，再把内容交给大模型生成答案。

这份文档很简单，但它有一个好处：我们可以很容易判断知识库有没有命中。

比如我们问：

前端架构主要包括哪些内容？

如果系统回答的是：

前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。

那就说明知识库确实生效了。

---

第三步：上传文档到知识库

进入刚才创建的知识库：

frontend-learning-kb

上传 frontend-notes.md。

上传时，Dify 会让你选择分段和索引方式。

第一版建议先使用默认配置，不要一开始就调复杂参数。

原因是：

第一阶段目标是跑通主流程，不是优化召回效果。

等后面项目稳定了，再研究这些参数：

• 分段长度
• 分段重叠
• 检索模式
• Top K
• Score 阈值
• Rerank

上传完成后，确认文档状态是可用的，而不是处理中或失败。

---

第四步：配置模型供应商

Dify 要回答问题，需要配置模型。

刚开始我使用的是 Dify 自带的免费额度，但免费额度很快用完了。

后面我选择了 DeepSeek，因为学习项目成本比较低，够做 RAG Demo。

这里要注意两个 Key 的区别：

Dify 应用 API Key：给我们自己的前端/后端调用 Dify 用
DeepSeek API Key：配置在 Dify 后台，给 Dify 调用模型用

也就是说：

前端项目 → 调用 Dify 应用 API Key
Dify 应用 → 调用 DeepSeek API Key

这两个不是同一个东西。

在 Dify 后台进入：

设置 → 模型供应商 → DeepSeek / 深度求索

添加 DeepSeek API Key。

然后回到 Chatflow 的 LLM 节点，选择 DeepSeek 对应模型。

学习阶段建议先用非推理模型，比如：

deepseek-chat

不要一上来就用 reasoner / reasoning 类模型，成本更高，而且这个项目暂时不需要复杂推理。

---

第五步：搭建 Chatflow 流程

现在开始搭建 Chatflow。

最小流程应该是：

用户输入 → 知识检索 → LLM → 直接回复

1. 用户输入节点

用户输入节点默认就有，不需要特别配置。

它提供用户问题，后续节点会使用这个问题去检索知识库。

2. 知识检索节点

添加一个知识检索节点。

在节点里选择刚才创建的知识库：

frontend-learning-kb

这个节点负责根据用户问题，从知识库中召回相关片段。

3. LLM 节点

添加 LLM 节点。

这个节点负责根据用户问题和知识检索结果生成最终回答。

4. 直接回复节点

最后连接到直接回复节点，把 LLM 的输出返回给用户。

最终流程是：

用户输入
  ↓
知识检索
  ↓
LLM
  ↓
直接回复

---

第六步：第一次测试

流程搭好后，可以先在 Dify 预览里测试。

先问：

前端架构主要包括哪些内容？

如果知识库检索成功，知识检索节点里应该能看到类似内容：

{
  "title": "frontend-notes.md",
  "content": "前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。"
}

这说明知识库已经命中了。

然后理想回答应该接近：

前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。

---

一个很容易踩的坑：知识库命中了，但 LLM 还是说没找到

我在这一步遇到了一个问题：

知识检索节点明明已经返回了 frontend-notes.md 的内容，但 LLM 却回答：

知识库中没有找到相关信息。

一开始很容易误以为是知识库没建好，或者检索失败。

但其实不是。

真正原因是：

知识检索结果没有正确传给 LLM 节点，或者 LLM 的 Prompt 里没有引用上下文变量。

也就是说，流程图连上了，不代表 LLM 一定读到了知识检索内容。

需要在 LLM 节点里配置上下文。

Dify 里会有类似：

上下文 → 设置变量值

选择：

知识检索 / result

然后在 SYSTEM 提示词里显式引用上下文变量。

例如：

你是一个前端学习助手。请严格根据上下文回答用户问题。

上下文内容：
{{#context#}}

规则：
1. 只能使用上下文中的内容回答。
2. 不要补充上下文中没有出现的信息。
3. 如果上下文中没有相关内容，请回答：知识库中没有找到相关信息。
4. 回答要简洁，不要扩展发挥。

这里最关键的是：

{{#context#}}

如果只设置了上下文变量，但 Prompt 里没有引用，Dify 会提示：

要启用上下文功能，请在提示中填写上下文变量。

这一步非常关键。

---

如何判断 RAG 真的生效？

不要问那些大模型本身就知道的问题。

比如：

什么是 RAG？

这个问题即使不接知识库，大模型也能回答。

更好的测试方式是问文档里的原文内容，比如：

大型前端项目可以分为哪几层？

如果回答是：

大型前端项目可以分为 UI 层、业务逻辑层、数据请求层、基础设施层。

那基本可以确认知识库生效。

再进一步，可以问一个知识库没有的内容，比如：

Webpack 的 loader 原理是什么？

如果 Prompt 约束足够严格，它应该回答：

知识库中没有找到相关信息。

这说明模型没有乱扩展。

---

Prompt 该宽松还是严格？

调试阶段，我建议先严格。

例如：

你是一个前端学习助手。请严格根据上下文回答用户问题。

规则：
1. 只能使用上下文中的内容回答。
2. 不要补充上下文中没有出现的信息。
3. 如果上下文中没有相关内容，请回答：知识库中没有找到相关信息。
4. 回答要简洁，不要扩展发挥。

为什么要严格？

因为我们第一阶段要验证的是：

知识检索 → 上下文传递 → LLM 回答

这条链路是否真实生效。

如果 Prompt 太宽松，模型可能会用自己的通用知识回答，让你误以为 RAG 成功了。

等链路稳定后，再逐步让回答更自然一些。

---

当前阶段的完成标准

做到下面几项，就说明 Dify RAG 最小 Demo 跑通了：

1. 创建了 Dify Chatflow 应用
2. 创建了 frontend-learning-kb 知识库
3. 上传了 frontend-notes.md
4. Chatflow 中包含：用户输入 → 知识检索 → LLM → 直接回复
5. 知识检索节点能命中文档内容
6. LLM 能基于上下文回答问题
7. 知识库没有的内容不会乱编

这一阶段不需要追求 UI，也不需要写前端代码。

先把 RAG 主链路跑通就够了。

---

这一篇我们完成了什么？

这一篇我们完成了 AI 知识库项目的第一块拼图：

Dify RAG 知识库应用

具体做了：

• 创建 Dify Chatflow 应用
• 创建知识库
• 上传测试文档
• 配置 DeepSeek 模型
• 添加知识检索节点
• 添加 LLM 节点
• 配置上下文变量
• 用 Prompt 约束模型基于知识库回答

这一步看起来不复杂，但非常重要。

因为后面所有前端功能，都是围绕这个 Dify 应用展开的。

后面的调用链路会变成：

React 前端
  ↓
Express BFF
  ↓
Dify Chat API
  ↓
知识检索 + LLM

---

下一篇预告

下一篇开始写前端代码。

我们会用 Vite + React 做一个最小聊天页面，实现：

输入问题
点击发送
调用 Dify API
展示回答

不过在前端直接调用 Dify API 之前，我们也会先讨论一个非常重要的问题：

Dify API Key 能不能直接写在前端？

答案当然是不能。

所以接下来会从最小前端页面开始，再逐步引出 Express BFF 代理层。