从零搭建 LLM + 知识库：RAG 完全入门指南

前言：你为什么要读这篇文章？

假设你有几百份 PDF 合同、几十篇技术文档、一堆内部 Wiki 页面。每次想查个信息，要么翻半天文件夹，要么在几个系统之间来回切换。

大语言模型（LLM）很强，但它有个致命缺陷：不知道自己不知道什么。你问 ChatGPT “我们公司上季度的销售政策是什么”，它要么编一个答案，要么说”我没有这方面的信息”。

RAG（Retrieval-Augmented Generation，检索增强生成） 就是解决这个问题的。简单说：

先把你的文档”喂”给系统 → 系统理解并存储 → 你提问时，系统先检索相关文档片段 → 再让 LLM 基于这些片段生成答案。

就像一个随身带着你全部文档的新员工——记性好、不编造、有问必答。

本文从零开始，带你用最主流的方式搭建一个属于自己的 LLM 知识库。

---

第一章：理解 RAG 的基本原理

1.1 不用 RAG 的 LLM 有什么问题？

问题	说明
❌ 知识截止	训练数据有时间限制，不知道之后的事
❌ 幻觉	不知道的问题会编造答案，还编得一本正经
❌ 领域盲区	不懂你公司内部的术语、流程、文档
❌ 上下文窗口	一次能塞进去的文档量有限

1.2 RAG 是怎么工作的？

整个流程分两步：

离线阶段（准备知识）——只做一次：

你的文档（PDF/Word/Markdown/网页）
        │
        ▼
┌──────────────────┐
│  文档解析 & 切分   │  把长文档切成合适大小的小块（chunk）
└──────────────────┘
        │
        ▼
┌──────────────────┐
│  向量化（Embedding）│  用 Embedding 模型把文字变成数学向量
└──────────────────┘
        │
        ▼
┌──────────────────┐
│  存入向量数据库     │  向量 + 原文一起存
└──────────────────┘

在线阶段（回答问题）——每次提问都执行：

用户提问："合同里违约金怎么算？"
        │
        ▼
┌──────────────────┐
│  问题向量化        │  把问题也变成向量
└──────────────────┘
        │
        ▼
┌──────────────────┐
│  语义检索          │  在向量数据库中找最相关的文档片段
└──────────────────┘
        │
        ▼
┌──────────────────┐
│  组装 Prompt       │  把检索到的片段 + 问题拼成完整提示词
└──────────────────┘
        │
        ▼
┌──────────────────┐
│  LLM 生成答案      │  基于提供的文档内容回答问题
└──────────────────┘

1.3 关键概念解释

Embedding（向量化）

把一段文字转换成一串数字（向量）。语义相近的文字，向量也相近。比如”苹果很好吃”和”这个水果真甜”在向量空间中距离很近，”苹果发布了新手机”则离得很远。

Chunk（文档分块）

LLM 一次能处理的文字有限（上下文窗口），而且检索粒度太粗也没用。所以把长文档切成小块，每块通常 300-1000 个字符，块与块之间可以有重叠（防止一句话被拦腰截断）。

向量数据库

专门存储和检索向量的数据库。流行的有：

数据库	特点	适用场景
Chroma	轻量、Python 原生、零配置	本地开发 / 小项目
Milvus	高性能、分布式	企业级 / 百万级文档
Qdrant	Rust 编写、性能好	中大型项目
Weaviate	GraphQL 接口、功能全	有复杂查询需求
FAISS	Meta 开源、纯向量搜索	嵌入式 / 高性能场景
pgvector	PostgreSQL 插件	已有 PG 技术栈的团队

重排序（Rerank）

第一次检索返回的文档片段不一定是最相关的（粗排），可以用 Rerank 模型做二次精排，提高准确率。

---

第二章：选型对比

市面上的 LLM 知识库方案很多，先做一个快速对比帮你选型。

2.1 主流方案一览

方案	定位	上手难度	适合谁
Dify	全能 LLM 应用平台	⭐ 简单	所有人，首选
FastGPT	专注知识库问答	⭐ 简单	只想做知识库
AnythingLLM	桌面端一键部署	⭐ 最简单	个人用户、不想折腾
MaxKB	国产知识库问答	⭐ 简单	中文场景、企业用
LangChain	开发框架	⭐⭐⭐ 中等	开发者、需要定制
LlamaIndex	数据索引框架	⭐⭐⭐ 中等	复杂数据管道

2.2 新手推荐：Dify

推荐理由：

• 开箱即用：Docker 一条命令启动，有 Web 管理界面
• 功能完整：不只是知识库，还包括工作流编排、Agent、对话日志
• 社区活跃：GitHub 6 万+ Star，中文文档完善
• 模型灵活：支持 OpenAI / Claude / 本地模型 / 各种国产模型
• 有云版本：不想自己部署可以用 Dify Cloud 直接开始

本文以 Dify 自部署版为主进行实操讲解。其他方案思路类似，一通百通。

---

第三章：环境准备

3.1 硬件要求

配置	最低要求	推荐配置
CPU	2 核	4 核+
内存	4 GB	8 GB+
磁盘	20 GB	50 GB+ (看文档量)
GPU	不需要	本地跑模型时建议

如果你只是用云端 API（OpenAI / Claude / 国产模型），不需要 GPU。只有当你打算本地部署开源模型时才需要。

3.2 安装 Docker

Dify 通过 Docker 部署，先安装 Docker：

Windows：

# 方式一：直接下载 Docker Desktop
# https://www.docker.com/products/docker-desktop/

# 方式二：WinGet
winget install Docker.DockerDesktop

macOS：

brew install --cask docker

Linux（Ubuntu/Debian）：

curl -fsSL https://get.docker.com | bash
sudo usermod -aG docker $USER  # 免 sudo

验证安装：

docker --version
docker compose version

3.3 获取 API Key

你需要至少一个 LLM 的 API Key。可选方案：

提供商	获取方式	费用
OpenAI	platform.openai.com → API Keys	按量付费
Anthropic	console.anthropic.com → API Keys	按量付费
智谱 (GLM)	open.bigmodel.cn → API Keys	有免费额度
DeepSeek	platform.deepseek.com → API Keys	极便宜
阿里通义	dashscope.aliyun.com → API Keys	有免费额度
SiliconFlow	siliconflow.cn → API Keys	聚合多模型

新手建议：先用 DeepSeek 或智谱，有免费额度，够你学完整套流程。

---

第四章：部署 Dify

4.1 一条命令启动

# 克隆项目
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境变量配置
cp .env.example .env

# 启动所有服务
docker compose up -d

Docker 会自动拉取并启动以下服务：

• api — Dify 后端 API
• web — Dify 前端界面
• db — PostgreSQL 数据库
• redis — 缓存
• weaviate — 向量数据库
• nginx — 反向代理
• sandbox — 代码执行沙箱

等几分钟后，浏览器打开 http://localhost，你会看到初始化页面。

4.2 初始化设置

1. 设置管理员邮箱和密码
2. 点击「初始化」
3. 登录后进入 Dify 主界面

4.3 配置模型

登录后第一步：设置 → 模型供应商，添加你的 LLM。

以 DeepSeek 为例：

1. 点击「DeepSeek」→「设置」
2. 填入 API Key
3. 点击「保存」

以 OpenAI 为例：

1. 点击「OpenAI」→「设置」
2. 填入 API Key
3. 可选：填入自定义 API 地址（如果你用中转服务）
4. 保存

同样方式添加 Embedding 模型。Dify 会自动使用与 LLM 同提供商的 Embedding 模型，也可以单独配置。

省钱技巧：LLM 用 DeepSeek（便宜），Embedding 用智谱或 SiliconFlow 的免费额度。一个大模型回答 + 一个向量化模型，分开配置，成本极低。

---

第五章：创建你的第一个知识库

5.1 上传文档

1. 顶部导航 → 「知识库」 → 「创建知识库」
2. 填写名称（如”公司制度知识库”）
3. 点击创建

进入知识库后，你可以上传文档：

• 支持格式：PDF、TXT、Markdown、Word (.docx)、Excel (.xlsx)、HTML、CSV
• 上传方式：拖拽文件 / 从 URL 导入 / 粘贴文本 / 对接 Notion
• 批量上传：支持一次性上传多个文件

5.2 文档处理设置

上传前可以调整关键参数：

参数	说明	建议值
分段最大长度	每个 chunk 的字符数上限	500-800
分段重叠长度	相邻 chunk 的重叠字符数	50-100
索引方式	高质量（推荐） / 经济 / 自定义	高质量
检索方式	向量检索 / 全文检索 / 混合检索	混合检索

分段长度怎么选？

• 合同、法律文档：偏长（800-1000），一个条款不能断
• FAQ、问答对：偏短（300-500），问题答案各自独立
• 技术文档：中等（500-800），一个知识点一块

5.3 等待处理

上传后 Dify 自动执行：

1. 文档解析（提取文字）
2. 文本分块（按设置切分）
3. 向量化（调用 Embedding 模型）
4. 存入向量数据库

处理速度取决于文档大小和 API 响应速度，一般几兆 PDF 几十秒就完成。

处理完后你可以：

• 查看分段结果（每个 chunk 的内容）
• 手动编辑或删除某些分段
• 在检索测试中直接搜索，看返回结果质量

---

第六章：创建知识库问答应用

知识库准备好后，把它变成一个可交互的聊天应用。

6.1 创建应用

1. 顶部导航 → 「工作室」 → 「创建空白应用」
2. 选择 「聊天助手」 类型
3. 命名（如”合同助手”）
4. 点击创建

6.2 关联知识库

在应用编辑界面：

1. 左侧 「上下文」 → 点击 「添加」
2. 选择你刚创建的知识库
3. 设置参数：

参数	说明	建议
Top K	每次检索返回多少个 chunk	3-5
相似度阈值	低于此分值的 chunk 不采用	0.5-0.7

6.3 编写系统提示词（Prompt）

在 「提示词」 编辑框中，这是最关键的一步。一个模板：

你是一个专业的知识库助手，专门回答关于[你的领域]的问题。

## 规则
1. 只根据「参考文档」中的内容回答问题
2. 如果文档中没有相关信息，直接说"文档中未找到相关内容"，不要编造
3. 回答时尽量引用文档原文，并注明来源
4. 保持回答简洁专业，用中文回复

## 参考文档
{{context}}

其中 {{context}} 是变量占位符，RAG 检索到的文档片段会自动填入。

6.4 调试测试

右侧有一个 「调试与预览」 面板，可以直接测试。

先确认右上角选择了正确的模型（比如 DeepSeek V3 或 GPT-4o），然后输入问题：

“合同中提前解约需要提前多少天通知？”

你会看到 Dify 先展示了检索到的文档片段（可以展开查看哪些 chunk 被命中），然后基于这些片段生成回答。

如果回答质量不好？

症状	可能原因	调整方向
答非所问	检索不准	调高 Top K、换混合检索
信息不全	分段太碎	增大 chunk 长度
答了无关内容	阈值太低	提高相似度阈值
回答太啰嗦	Prompt 太弱	优化系统提示词
幻觉严重	文档覆盖不足	补充文档、优化提示词

---

第七章：发布与使用

7.1 发布应用

调试满意后，点击右上角 「发布」。

Dify 提供多种使用方式：

方式	说明
网页链接	生成一个公开 URL，直接分享
嵌入网页	提供 iframe / script 代码，嵌入到你的网站
API 调用	提供 REST API，集成到自己的系统
企业微信/飞书/钉钉	对接办公 IM

7.2 API 集成示例

import requests

url = "http://localhost/v1/chat-messages"
headers = {
    "Authorization": "Bearer app-YOUR_APP_API_KEY",
    "Content-Type": "application/json"
}

data = {
    "inputs": {},
    "query": "员工年假有多少天？",
    "response_mode": "blocking",
    "conversation_id": "",
    "user": "employee-001"
}

response = requests.post(url, json=data, headers=headers)
print(response.json()["answer"])

7.3 对话日志与分析

应用发布后，Dify 自动记录所有对话：

• 「日志与标注」：查看每条对话的问题、回答、检索到的文档
• 标注功能：标记好的回答，用于后续优化
• 用量统计：查看 API 调用次数、Token 消耗

---

第八章：进阶技巧

8.1 多知识库联合检索

一个应用可以关联多个知识库。比如：

• 知识库 A：产品手册
• 知识库 B：客服 FAQ
• 知识库 C：内部流程文档

用户问一个问题，Dify 同时检索三个知识库，取最相关的 Top K 条。

8.2 元数据过滤

上传文档时可以加元数据标签（如 category:财务、year:2025），检索时按标签过滤：

只检索「2025年」的「财务类」文档 → 精确度和速度大幅提升

8.3 工作流编排（Workflow）

Dify 不只是问答。你可以用可视化的拖拽方式创建处理流程：

用户输入 → 意图识别 → 
  ├─ 查资料 → 检索知识库 → LLM 回答
  ├─ 查数据 → 调用 API → 格式化返回
  └─ 闲聊 → 直接 LLM 回复

8.4 本地模型部署（省钱 + 隐私）

如果你有一定量的文档，不想每次调用都花 API 费用，或者文档涉密不能上云，可以本地部署开源模型。

Embedding 模型（向量化）：

# 用 Ollama 部署
ollama pull nomic-embed-text
ollama pull bge-m3

LLM 模型（生成回答）：

# Qwen2.5 系列（中文友好）
ollama pull qwen2.5:7b
ollama pull qwen2.5:14b

# 或 DeepSeek
ollama pull deepseek-r1:8b

然后在 Dify 中配置模型供应商为「Ollama」，地址填 http://localhost:11434。

7B 模型最低要求：16GB 内存，无 GPU 也能跑（慢但能用）
14B 模型：建议 32GB+ 内存或有 8GB+ 显存的 GPU

8.5 持续优化知识库

知识库不是建完就完事了：

• 定期更新：文档变了要重新上传新版本
• 分析失败案例：看日志里哪些问题没回答好，补文档或调参数
• 用户反馈：用标注功能收集好评/差评，针对性改进
• A/B 测试：同一问题用不同 chunk 大小或检索策略，对比效果

---

第九章：常见问题与排错

Q1：检索结果不准确怎么办？

1. 先检查检索到的 chunk 是否包含答案（可能是 chunk 里有但没有被 LLM 用上 → 优化 Prompt）
2. 如果 chunk 里就没有答案 → 你的文档覆盖不足，或 chunk 切分有问题
3. 尝试切换检索方式：向量检索 → 混合检索 → 全文检索轮着试
4. 启用 Rerank 模型做二次精排

Q2：Docker 启动失败？

# 查看日志
docker compose logs -f

# 常见问题：端口冲突
# 修改 .env 中的端口配置

# 重启
docker compose down
docker compose up -d

Q3：Embedding 处理很慢？

• 检查 API 是否限速（免费额度通常有 RPM 限制）
• 大批量文档分批上传
• 换成更快的 Embedding 模型（如 text-embedding-3-small）

Q4：中文效果不好？

• Embedding 模型选中文优化的（bge-large-zh、text-embedding-3、智谱 Embedding）
• LLM 选中文能力强的（DeepSeek、Qwen、GLM）
• 分段时不要切断中文字符（Dify 默认会处理）

---

总结

阶段	你需要做什么
准备	装 Docker、搞一个 LLM API Key
部署	docker compose up -d 一条命令
建知识库	上传文档，调整分段参数
建应用	关联知识库 + 写系统提示词
上线	发布 → 生成链接/嵌入网页/API 调用

整个流程从零到能用，新手一般 一个下午 可以搞定。

最后提醒一句：知识库的核心不是技术，是你的文档质量。垃圾文档进 → 垃圾答案出。花时间整理好你的文档，比调任何参数都管用。

• Dify 官方文档：https://docs.dify.ai
• Dify GitHub：https://github.com/langgenius/dify
• Ollama（本地模型）：https://ollama.com