企业官网建设流程全解析

先回答一个很多人关心的问题：RAG 是不是已经被大模型长上下文淘汰了？答案是：没有。

2026 年再谈 RAG，重点已经不在“要不要用”，而是“怎么把检索质量做好、怎么把链路工程化”。长上下文解决了“能读多少”的问题，RAG 解决的是“该读什么、读出来的东西准不准”的问题。对于企业内部知识库、客服问答、文档问答、合规审查这些场景，RAG 依然是成本最低、可控性最强、落地最快的方案。

这篇文章不打算讲太多 PPT 层面的概念，直接进入实战。会用一整套完整流程，从技术选型、环境准备、组件部署，到知识库写入、检索验证、API 集成和批量任务，带你把一套企业级 RAG 知识库从零跑通。文章里会给出通用命令、配置示例和排查清单，你可以直接在自己的服务器或本机上跟着操作。

1. RAG 知识库核心能力速览

这套方案的核心思路是：所有组件尽量本地化部署，数据不出内网。如果你只是个人学习，一台 16G 内存的笔记本也能跑；如果是企业生产环境，建议 GPU 服务器加独立向量库。

2. RAG 技术原理与整体架构

2.1 为什么需要 RAG

大模型本身的知识截止到训练日期，企业内部私有文档、最新制度、项目经验这些内容模型并不知道。单纯靠微调去灌入知识，成本高、更新慢、还可能产生幻觉。RAG 的思路是：把知识先存到外部知识库，用户在提问时先检索相关内容，再把检索结果和原始问题一起交给大模型生成答案。

这样做的好处有三个：

• 知识可实时更新，新增文档直接入库，无需重新训练模型。
• 答案可溯源，能明确指出答依据来自哪篇文档。
• 数据可控性高，私有知识不需要进入公网模型。

2.2 RAG 系统需要哪几个组件

一套完整的企业级 RAG 知识库，至少包含以下五个部分：

大模型（LLM）：负责最终答案生成。可选择本地部署的开源模型，也可以接云端 API。生产环境建议本地部署，避免数据外泄。

Embedding 模型：把文本转换成向量。它的质量直接决定检索召回效果。常见的开源方案有 BGE、M3E、Text2Vec 等。

向量数据库：存储向量数据，提供相似度检索能力。常见开源方案有 Chroma、Milvus、Qdrant、Weaviate，轻量场景也可以用 FAISS。

RAG 编排框架：负责文档处理、分块、提示词组装、检索调度。常见方案有 Dify、AnythingLLM、LangChain、LlamaIndex。

Rerank 重排序模型：对召回的候选文本做二次排序，把最相关的内容排到最前面，提升问答准确率。

2.3 一条 Query 从提问到回答的完整流程

一次完整的 RAG 问答请求会经历以下步骤：

1. 用户输入问题。
2. 系统对问题进行 Embedding 向量化。
3. 向量数据库执行相似度检索，召回 Top-K 候选文档块。
4. Rerank 模型对候选块重新排序。
5. 系统把排序后的文本块、用户问题、系统提示词组装成 Prompt。
6. 大模型基于提供的上下文生成答案。
7. 返回答案和引用来源。

整个链路里，最容易出问题的环节不是大模型，而是分块策略和召回效果。很多人搭完知识库发现“答非所问”，90% 是分块大小不合理、Embedding 模型不匹配、或者缺少 Rerank 这一步。

3. 适用场景与使用边界

3.1 这套方案适合谁

企业内部知识管理：把制度文档、技术方案、项目总结、操作手册统一接入知识库，员工用自然语言提问即可获取答案，不用再去翻共享目录。

客服与售前场景：把产品说明、FAQ、售后规范录入知识库，辅助客服快速回答用户问题，也可以直接做成问答机器人。

研发团队内部工具：把 API 文档、开发规范、历史故障记录接进来，新同学上手和老同学查问题都会快很多。

个人知识管理：把本地笔记、技术收藏、PDF 文档统一管理，做一个能对话的个人知识库。

3.2 使用边界与合规提醒

RAG 知识库本身是一个通用技术方案，但落地过程中有几个边界必须注意：

• 录入知识库的文档必须拥有合法授权，不得把未授权的商业文档、个人隐私信息、敏感数据随意接入知识库。
• 如果知识库包含个人信息，需要遵守相关数据保护法规，做好权限隔离和访问审计。
• 企业环境建议全链路本地化部署，避免把内部文档发送到外部 API。
• 涉及人脸、声音、身份信息的场景，需要额外强化权限控制和合规审查。
• 大模型生成结果不能直接作为最终结论，重要决策场景必须人工复核。

3.3 不适合什么场景

• 需要毫秒级响应的超高并发场景，RAG 链路的检索和生成延迟会比普通接口高很多。
• 对答案精确度要求达到 100% 的业务，大模型天然存在幻觉概率，不能替代规则系统。
• 完全依赖云端 API 又不愿意做数据脱敏的场景，存在数据合规风险。

4. 环境准备与前置条件

开始部署前，先把环境检查一遍。按照下面的清单准备，能省很多后续排查时间。

4.1 硬件与操作系统

如果没有 GPU，CPU 也能跑完整流程，只是大模型生成速度会慢很多。7B 量级的量化模型在 CPU 上大约每秒能生成几个 token，适合开发测试，不适合生产环境。

4.2 软件环境检查清单

部署前需要安装以下基础软件：

# Ubuntu / Debian 系统示例 sudo apt update && sudo apt install -y curl git python3 python3-pip # 验证版本 python3 --version git --version curl --version

如果需要使用 Docker 部署框架和向量库，先安装 Docker 和 Docker Compose：

# 安装 Docker（官方脚本，按实际系统环境执行） curl -fsSL https://get.docker.com | bash # 验证安装 docker --version docker compose version

4.3 端口规划

RAG 系统涉及多个服务，建议提前规划端口，避免冲突：

如果端口冲突，可以在各自配置文件中修改。

5. 本地大模型与 Embedding 模型部署

RAG 链路里最核心的模型有两个：文本生成模型和Embedding 模型。

5.1 使用 Ollama 管理本地推理模型

Ollama 是目前本地运行大模型最省事的方式。它自带模型管理、API 服务和 GPU/CPU 自适应调度，特别适合 RAG 场景。

安装 Ollama：

# Linux 一键安装 curl -fsSL https://ollama.com/install.sh | sh # Windows 用户直接从官网下载安装包，macOS 同理

安装完成后，拉取文本生成模型。以 Qwen2.5 7B 为例：

# 拉取模型 ollama pull qwen2.5:7b # 启动服务（默认监听 11434 端口） ollama serve

验证模型是否正常：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是RAG", "stream": false }'

返回内容中包含响应文本，说明模型服务正常。

5.2 部署 Embedding 模型

Embedding 模型负责把文本转成向量。推荐使用 BGE 系列或 M3E 系列。同样可以用 Ollama 管理：

# 拉取 BGE-M3 embedding 模型 ollama pull bge-m3 # 验证 embedding 接口 curl http://localhost:11434/api/embed -d '{ "model": "bge-m3", "input": "知识库测试文本" }'

返回的 JSON 中会包含一个高维向量数组，说明 Embedding 服务正常。

这里特别提醒：Embedding 模型和文本生成模型必须保持同时在线，RAG 链路中查询向量化和文档向量化使用的是同一个 Embedding 模型，必须保持一致，否则检索匹配度会大幅下降。

5.3 显存与模型选择参考

模型选择需要根据硬件情况来决定，以下是大致参考（实际占用以本机测试为准）：

没有 GPU 的机器，Ollama 会自动退化为 CPU 推理，速度会明显变慢，但功能可用。

6. RAG 框架选型与部署

模型层准备好之后，需要选择一个 RAG 编排框架来管理知识库。这里重点介绍两套方案：Dify适合企业级完整流程，AnythingLLM适合轻量级快速验证。

6.1 方案一：Dify 企业级知识库

Dify 是目前开源社区里比较成熟的 LLM 应用开发平台，内置知识库管理、工作流编排、模型管理、API 发布等功能，非常适合搭建企业级 RAG 系统。

使用 Docker Compose 部署：

# 克隆官方仓库（按官方最新文档操作） git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量配置 cp .env.example .env # 启动服务 docker compose up -d

启动完成后，浏览器访问：

http://localhost:3000

首次访问需要设置管理员账号。然后在 Dify 管理后台完成以下配置：

1. 进入“设置 -> 模型供应商”，添加 Ollama 供应商。
2. 填写 Ollama API 地址：http://host.docker.internal:11434（容器内访问宿主机 Ollama 服务的地址，Linux 下可尝试http://172.17.0.1:11434）。
3. 配置文本生成模型为qwen2.5:7b。
4. 配置 Embedding 模型为bge-m3。

配置完成后，可以创建知识库，上传测试文档，Dify 会自动完成文本解析、分块、向量化和入库。

6.2 方案二：AnythingLLM 轻量级知识库

如果你只是个人使用，不想部署太重的基础设施，AnythingLLM 是更快的选择。它是一个开源的桌面端知识库应用，内置文档管理、向量存储和聊天界面。

安装方式：

# 从 GitHub Releases 下载桌面版安装包 # 或者使用 Docker 部署 docker pull mintplexlabs/anythingllm

启动后同样需要配置 Ollama 模型和 Embedding 模型，然后创建一个 Workspace，上传文档，即可开始问答。

AnythingLLM 的优势是开箱即用，界面简单，适合学习 RAG 流程和验证小规模知识库。缺点是在权限管理、工作流编排、多用户支持方面不如 Dify 完善。

6.3 方案三：LangChain + 自定义流程

Dify 和 AnythingLLM 已经封装了大部分流程，如果你想深入理解 RAG 的实现细节，或者需要完全定制化的处理逻辑，可以直接用 LangChain 或 LlamaIndex 写一套。这是学习 RAG 原理最推荐的方式。

一段最简的 LangChain RAG 流程示例如下（仅做结构参考，需要按实际项目调整）：

from langchain_community.llms import Ollama from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain.chains import RetrievalQA # 初始化模型 llm = Ollama(model="qwen2.5:7b", base_url="http://localhost:11434") embeddings = OllamaEmbeddings(model="bge-m3", base_url="http://localhost:11434") # 加载本地文档 with open("./docs/company_policy.md", encoding="utf-8") as f: raw_text = f.read() # 分块 text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=64 ) chunks = text_splitter.split_text(raw_text) # 写入向量库 vectorstore = Chroma.from_texts(chunks, embedding=embeddings) # 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 5}) ) # 提问 result = qa_chain.invoke("公司年假制度是怎么规定的？") print(result["result"])

这段代码虽然短，但包含了 RAG 的全部核心逻辑：文档加载、分块、向量化、检索、生成。建议在学习阶段把它跑通一遍，再回到 Dify 这类平台操作，理解会更深。

7. 功能测试与效果验证

部署完成后，不能只看“能回答”就认为系统没问题。RAG 知识库需要系统性测试，重点覆盖解析、召回、生成三个环节。

7.1 文档解析与入库测试

测试目的：确认框架能正确处理不同格式的文档。

测试步骤：

1. 准备一份包含标题、段落、表格的 PDF 文档。
2. 准备一份 Markdown 格式的技术文档。
3. 准备一份带页码的 Word 文档。
4. 依次上传到知识库，观察解析结果。

预期结果：

• 文档被成功切成多个文本块。
• 每个文本块有对应的来源文件名。
• 向量化任务全部完成，无失败项。

失败排查：

• PDF 扫描件需要 OCR 组件支持。
• 表格类文档需要确认是否开启表格解析选项。
• 图片型内容不会被默认解析。

7.2 检索召回测试

测试目的：确认用户提问能召回正确的文档片段。

测试步骤：

在知识库的“召回测试”或“调试预览”功能中，输入测试问题：

公司对远程办公的申请流程有什么要求？

预期结果：

• 返回的文本块与问题高度相关。
• 召回结果包含文档名称和片段内容。
• 排序靠前的内容是直接相关段落，而不是泛泛提及。

失败排查：

• 召回结果不相关，检查 Embedding 模型是否一致。
• 召回内容太少，降低 Top-K 值或减少分块长度。
• 召回内容太多且杂乱，增加相似度阈值或接入 Rerank 模型。

7.3 问答质量测试

测试目的：验证大模型能否基于检索内容生成正确答案。

测试步骤：

设计一组覆盖不同难度的问题：

1. 我们公司一共有多少条员工管理制度？ 2. 技术部的故障响应时间标准是多少？ 3. 今年新发布的远程办公政策相比去年有哪些变化？ 4. 报销流程中超过多少金额需要总监审批？

预期结果：

• 简单事实问题直接给出准确答案。
• 对比类问题能综合多个文档块给出分析。
• 答案末尾或系统路径中能查到引用来源。

失败排查：

• 答案错误但检索结果正确，说明 Prompt 组装或模型自身能力有瓶颈。
• 答案正确但引用来源不对，需要检查分块时是否保留来源元数据。
• 答案与检索内容无关，说明模型没遵循上下文约束，需要调整系统提示词。

7.4 分块参数调优测试

分块策略是 RAG 落地中最需要反复调的部分。推荐按以下顺序做实验：

1. 固定文档A，分别设置块大小 256、512、1024，对比同一问题的回答质量。
2. 固定块大小，分别设置重叠 0、64、128，观察上下文连贯性。
3. 记录每组参数下的召回命中位置，找到最佳组合。

从实际经验看，块大小 512、重叠 64是一个比较通用的起点。对于代码类、表格类文档，需要更小的块；对于长文叙述类文档，可以适当加大。

8. 接口 API 与批量任务

RAG 知识库最终要接入业务系统，接口能力和批量处理能力是生产环境必须验证的部分。

8.1 Dify 应用 API

Dify 创建的每个应用都会生成对应的 API 密钥和 API 端点。在应用的“API 访问”页面可以看到完整信息。

创建知识库问答应用后，可以通过 API 调用：

curl -X POST "http://localhost:5001/v1/chat-messages" \ -H "Authorization: Bearer app-你的API密钥" \ -H "Content-Type: application/json" \ -d '{ "query": "远程办公申请流程是什么？", "response_mode": "blocking", "user": "test-user" }'

返回结果包含答案文本、会话 ID、检索引用等字段。

8.2 批量文档导入

企业级知识库首次上线时，通常需要批量导入几千份历史文档。Dify 支持在页面上批量上传，也有批量导入的 API。

通用批量处理流程建议这样设计：

1. 把待导入文件统一放入./input_docs目录。
2. 按目录或文件名规则进行分类。
3. 通过 API 或脚本逐批提交。
4. 每批任务记录任务 ID。
5. 轮询任务状态，确认向量化完成。
6. 失败文件单独记录到日志，后续重试。

一个简单的批量导入脚本结构示例：

import os import time import requests API_URL = "http://localhost:5001/v1/datasets/{dataset_id}/document/create-by-file" TOKEN = "app-你的API密钥" INPUT_DIR = "./input_docs" headers = { "Authorization": f"Bearer {TOKEN}" } for file_name in os.listdir(INPUT_DIR): file_path = os.path.join(INPUT_DIR, file_name) if not os.path.isfile(file_path): continue with open(file_path, "rb") as f: files = {"file": (file_name, f)} data = {"data": '{"indexing_technique":"high_quality"}'} resp = requests.post(API_URL, headers=headers, files=files, data=data) if resp.status_code == 200: print(f"[OK] {file_name} 导入成功") else: print(f"[FAIL] {file_name} {resp.text}") time.sleep(1)

使用脚本前需要把代码中的 API 地址、密钥、数据集 ID 和文件路径替换成实际环境的值。

8.3 批量评估检索效果

检索质量评估是 RAG 上线前的必要环节。可以准备一组“问题 -> 期望来源文档”的测试集，批量跑检索，统计 Top-K 命中率：

如果命中率低于 70%，优先排查分块参数、Embedding 模型选择、Rerank 配置这三项。

9. 资源占用与性能观察

9.1 如何观察资源占用

RAG 系统部署后，需要掌握一套监控手段。

查看 GPU 显存占用：

nvidia-smi

查看 CPU 和内存占用：

top -o %MEM

查看 Docker 容器资源占用：

docker stats

9.2 性能瓶颈分析

RAG 链路中常见的性能瓶颈有四个：

Embedding 速度：大批量文档入库时，向量化速度可能很慢。用 GPU 加速后能明显提升。Embedding 任务本身是密集计算，CPU 和 GPU 差距很大。

向量检索速度：数据量在百万级以下时，单机向量库足够应对。超过百万级，建议使用分布式向量库并做分片。

大模型生成速度：生成阶段是延迟最高的环节，7B 模型在消费级显卡上大约每秒生成 20-40 个 token。如果并发高，需要多卡部署或多实例负载均衡。

分块质量：分块不足会导致跨段落的信息被切断，模型无法获得完整上下文。

9.3 降低资源的实用手段

• 文本生成模型使用 4-bit 量化版本，显存占用下降明显。
• 入库时设置合理的批量大小，避免一次性灌入过多文档导致内存暴涨。
• 向量库开启持久化，避免每次重启都要重新向量化。
• 配置缓存策略，高频问题直接命中缓存，跳过检索和生成流程。
• 限制单次问答的最大 Token 数，避免长输出占用资源。

10. 常见问题与排查方法

RAG 系统组件多、链路长，踩坑是很正常的。下面把高频问题整理成清单：

针对 Dify 升级后无法保存知识库或报internal server error的问题，优先做三件事：查看 Dify API 容器日志定位具体报错；确认 PostgreSQL 和 Redis 是否正常运行；确认是否已执行数据库迁移命令。多数情况下，这类问题来自数据库连接中断或迁移未执行。

11. 最佳实践与使用建议

11.1 上线前的最小验证清单

不要一上来就追求完整功能。第一次跑通，建议按以下顺序验证：

1. Ollama 里跑通一个文本生成模型的对话请求。
2. Ollama 里跑通一个 Embedding 模型的向量化请求。
3. 在 Dify 或 AnythingLLM 里配置好两个模型。
4. 上传一份文档到知识库，确认向量化成功。
5. 在调试界面检索一个预期能召回的问题。
6. 发起一次问答，确认答案中有引用来源。

这套流程全部走通后，再逐步扩展知识库规模和并发能力。

11.2 工程化管理建议

• 模型文件、输入文档、输出结果分目录管理，方便备份和复盘。
• 批量导入任务必须记录日志，包含成功数、失败数和失败原因。
• 接口服务如果暴露在局域网，需要设置访问密钥和调用频率限制。
• 定期备份向量数据库，知识库是核心资产。
• 文档有更新时，按增量策略重新向量化，而不是全量重灌。
• 大模型 Prompt 里的系统提示词要明确约束“只能基于给定内容回答”，降低幻觉概率。

11.3 从学习到生产

如果你刚接触 RAG，建议的学习路径是：

1. 先用 AnythingLLM 跑通一套最简知识库，感受 RAG 的完整效果。
2. 再用 LangChain 自己写一遍检索流程，理解分块、向量化、召回、生成的每个环节。
3. 切换到 Dify，用可视化工作流把流程产品化。
4. 最后引入 Rerank、查询改写、多路召回、Agent 化工具调用这些进阶能力。

12. 最容易踩的坑与扩展方向

12.1 最容易踩的坑

这里集中说四个入坑频率最高的点。

第一，Embedding 模型不一致。入库用 A 模型，检索时却换成 B 模型，向量空间完全不同，检索结果必然混乱。

第二，没有 Rerank。向量召回的前几名经常混着不相关内容，直接丢给大模型就会答非所问。加一层 Rerank 能显著提升答案质量。

第三，分块策略不调优。默认参数在通用文档上或许能跑，但技术文档、表格类、代码类文档需要单独调整分块大小和重叠值。

第四，忽略引用溯源。生产环境如果没有引用来源，出问题根本无法定位，上线前必须确保每个回答能追回到具体文档块。

12.2 后续扩展方向

RAG 知识库搭好之后，可扩展的方向不少：

• Agentic RAG：把检索过程交给 Agent 自主规划，先判断该查哪些知识源，再决定用什么方式检索，适合多知识库、多工具联动的场景。
• 图谱 RAG（GraphRAG）：把实体关系抽取出来构建知识图谱，回答“实体之间有什么关系”这类问题，比纯向量检索更准确。
• 多路召回融合：同时走向量检索、关键词检索、SQL 查询多路召回，再融合排序，覆盖更多查询类型。
• 多模态文档解析：引入 OCR、表格识别、版面分析，让知识库真正理解复杂 PDF。
• 在线学习与反馈闭环：记录用户的“回答有帮助/没帮助”反馈，定期用低质量问答对迭代检索策略。

本文从原理、架构到部署、测试、排错，把一套 RAG 知识库的搭建过程完整过了一遍。如果你正在考虑搭建企业级知识库，建议先按照第 11 节的最小验证清单跑通一条链路，再逐步扩展。整套方案的价值不在于某个组件多强，而在于把模型、向量库和流程编排组合好之后，能不能真正回答业务问题。现在推荐的起步动作是：一台机器、一个 Ollama、一个 Dify，先跑起来再优化。