第1章 大模型、企业知识库与 RAG 平台概述

小罗水2026-07-27 11:16

本章目标

从这一章开始，我们正式进入《基于 Spring Cloud 的企业级 AI 知识库 / RAG 平台实战》这本书的主线。

很多初学者第一次接触大模型应用时，会把它理解成"调用一个聊天接口"。这当然是最容易入门的方式，但如果我们要做的是企业知识库、内部制度问答、客服知识库、研发文档助手，就不能只停留在"把问题发给大模型，再把回答返回给用户"这一层。

企业真正需要的不是一个会聊天的页面，而是一个能管理文档、能校验用户权限、能异步处理索引任务、能检索私有知识、能返回引用来源、能在模型失败时降级、能让管理员排查问题的完整系统。

本书要带你完成的项目，教学化名称叫 KnowHub 。它基于我们已有的 rag-platform 项目整理而来，后续会围绕 Spring Cloud、Spring AI、pgvector、RabbitMQ、MinIO、Redis、Sentinel 和 Vue 前端，一步一步把一个 AI 知识库/RAG 平台讲清楚。

学完本章，你应该能回答下面几个问题：

  1. 大模型为什么不能直接替代企业知识库。
  2. RAG 到底解决了什么问题。
  3. 一个企业级 RAG 平台需要哪些核心模块。
  4. KnowHub 为什么要使用 Spring Cloud 微服务架构。
  5. RabbitMQ、MinIO、pgvector、Redis、Sentinel 在系统里分别承担什么职责。

这一章不急着写代码。我们先把全局架构和业务问题讲明白。方向对了，后面的代码才不会变成零散技术堆砌。

1.1 从"会聊天的大模型"到"可落地的企业系统"

大模型很强，这是事实。

它可以写文章、总结文档、生成代码、解释概念，也可以根据一段上下文回答问题。很多人第一次体验大模型时，会觉得它几乎什么都知道。于是一个很自然的想法出现了：既然大模型这么强，企业知识库是不是只需要接一个模型接口就行？

答案是否定的。

原因很简单：大模型擅长语言生成，但企业系统需要的是可信、可控、可追溯的业务答案。

比如，一个员工问：

复制代码 
我入职半年了，今年可以休几天年假？

通用大模型可能会根据公开劳动法规给出一段看起来很合理的回答。但是一家公司的真实年假规则，可能写在内部制度文档里：

  • 试用期是否计算年假。
  • 年假按自然年还是入职周期折算。
  • 不同岗位是否有额外福利假。
  • 离职、调岗、请病假后是否影响年假。

这些规则并不一定存在于公开互联网中，也不一定出现在大模型训练数据里。模型如果没读过这家公司自己的制度文档，就只能根据通用知识猜测。

在聊天场景里，猜错也许只是体验不好；但在企业场景里，猜错可能意味着制度误导、客服误答、合规风险，甚至带来真实业务损失。

所以，企业知识库系统的目标不是让模型"自由发挥"，而是让模型先查企业资料，再基于资料回答。

这就是 RAG 的价值。

1.2 RAG 是什么

RAG 是 Retrieval-Augmented Generation 的缩写，中文通常叫"检索增强生成"。

这几个词听起来有点抽象，但它的核心思想非常简单：

先检索资料，再生成答案。

如果把普通大模型问答比作闭卷考试，那么 RAG 就像开卷考试。学生本身会组织语言，但在回答之前，允许先翻参考书。参考书越相关，答案越可靠。

一个标准 RAG 流程通常包括下面几步：

放到 KnowHub 项目里，这条链路会更加工程化：

可以看到，RAG 不是一个单点功能，而是一条完整链路。它至少涉及：

  • 用户认证。
  • 权限隔离。
  • 文档管理。
  • 文档解析。
  • 文本切片。
  • Embedding 向量化。
  • 向量检索。
  • Prompt 构建。
  • 大模型调用。
  • 日志记录。
  • 异常降级。

如果只调用 Chat 接口，那只是聊天机器人；如果能把私有知识接入、检索、引用、追踪和管理起来，才是企业知识库/RAG 平台。

1.3 企业知识库为什么需要平台化

一个简单 Demo 可以只有一个 Controller：：用户传问题，后端调用模型，返回回答。

但企业知识库不能这么做。

原因主要有五个。

1.3.1 文档需要管理

企业资料不是一段固定文本，而是不断变化的文档集合。

可能包括：

  • PDF 制度文件。
  • Markdown 技术文档。
  • TXT 培训材料。
  • 接口说明。
  • 操作手册。
  • 常见问题。

这些文档需要上传、存储、解析、切片、索引、重建索引，还要记录状态。如果上传失败、解析失败、向量化失败，系统必须能告诉用户失败原因，而不是只返回一个 500。

KnowHub 中的 document_info、document_chunk、index_task 就是为了解决这些问题。

1.3.2 用户需要隔离

企业知识库通常不是所有人都能看所有资料。

A 用户创建的知识库，B 用户不能访问。普通用户不能进入管理端。管理员可以查看全局数据，但也必须通过明确的角色校验。

所以 KnowHub 使用 Gateway 统一校验 JWT，并向下游服务透传：

复制代码 
X-User-Id
X-Username
X-User-Role

业务服务拿到用户身份后，还要继续校验知识库归属。也就是说，前端隐藏菜单不算安全边界，后端资源校验才算。

1.3.3 文档索引需要异步化

文档上传之后，系统不能在上传接口里同步做完所有事情。

因为一次完整索引可能包括：

如果文档稍大，或者模型接口较慢，同步处理会让上传接口长时间阻塞，用户体验很差，也容易触发超时。

因此企业级实现通常会引入任务表和消息队列。

KnowHub 的完整链路中，文档上传后会创建索引任务，并通过 RabbitMQ 投递索引消息，由 rag-task-service 消费后执行真正的索引流程。这样上传接口只负责接收文件和创建任务，耗时处理交给后台任务完成。

1.3.4 文件存储需要从本地目录升级为对象存储

学习阶段可以把文件保存到本地目录，比如：

复制代码 
uploads/kb/{kbId}/{yyyyMMdd}/{uuid}.txt

但一旦拆成多个服务，特别是当 knowledge-service 和 task-service 部署在不同机器上时，本地目录会出现问题：上传文件的服务能看到文件，执行索引的服务可能看不到。

因此 KnowHub 的完整版本使用 MinIO 作为对象存储。上传服务把文件写入 MinIO，任务服务根据对象路径下载文件并解析。这样不管服务部署在哪台机器，只要能访问 MinIO，就能处理同一份文件。

MinIO 在本书中的定位不是"炫技"，而是为了解决多服务环境下文件共享和部署一致性问题。

1.3.5 AI 调用需要限流和降级

大模型接口不是普通本地方法调用。它可能超时、限流、失败，也可能因为 API Key、网络、模型服务异常导致不可用。

如果没有保护措施，一个问答接口可能因为模型服务异常直接拖垮用户请求。

KnowHub 使用 Sentinel 对问答接口做限流，并在 AI 调用失败时返回降级回答，同时把失败原因写入 qa_log。这样用户能收到可理解的提示，开发者也能根据日志排查问题。

1.4 KnowHub 的整体架构

KnowHub 采用前后端分离和 Spring Cloud 微服务架构。

整体可以分成七层：

从用户视角看，它是一套知识库问答系统；从开发者视角看，它是一套完整的后端工程训练项目。

1.4.1 前端展示层

KnowHub 包含两个前端入口。

用户端：rag-user-web

主要面向普通用户，功能包括：

  • 登录和注册。
  • 创建知识库。
  • 查看知识库列表。
  • 上传文档。
  • 查看文档索引状态。
  • 发起知识库问答。
  • 查看答案引用来源。

管理端：rag-admin-web

主要面向管理员，功能包括：

  • 管理员登录。
  • 用户管理。
  • 知识库查看。
  • 文档查看。
  • 索引任务查看。
  • 失败任务重试。
  • 问答日志查看。

这两个前端的价值，不是页面多，而是让用户侧和管理侧职责分开。普通用户只能看自己的资源，管理员才能看全局数据。

1.4.2 Gateway 网关层

rag-gateway-service 是系统统一入口。

它主要负责：

  • 路由转发。
  • CORS 处理。
  • JWT 校验。
  • 白名单放行。
  • 用户信息解析。
  • 向下游服务透传用户身份。
  • /admin/** 管理员角色校验。

用户请求不会直接打到 knowledge-service 或 task-service，而是先经过 Gateway。这样认证逻辑不用在每个服务里重复写。

1.4.3 Auth 认证服务

rag-auth-service 负责用户身份相关能力。

核心职责包括：

  • 用户注册。
  • 用户登录。
  • BCrypt 密码加密。
  • JWT 签发。
  • 当前用户信息查询。
  • 用户状态校验。
  • USER / ADMIN 基础角色管理。

登录成功后，前端保存 Token，后续请求统一携带：

复制代码 
Authorization: Bearer xxx

Gateway 校验 Token 后，把用户身份写入请求头，下游服务再基于这些信息完成业务校验。

1.4.4 Knowledge 知识库服务

rag-knowledge-service 是 RAG 主业务服务。

它负责：

  • 知识库创建、查询、删除。
  • 文档元数据管理。
  • 文档上传入口。
  • 文档解析和切片规则。
  • 向量检索。
  • RAG 问答。
  • qa_log 和 qa_reference 记录。
  • Redis owner 缓存。
  • Sentinel 问答限流。
  • AI 调用降级。

在完整链路中，knowledge-service 不直接长时间阻塞处理索引，而是创建任务并投递 RabbitMQ 消息，把耗时索引交给 task-service。

1.4.5 Task 异步任务服务

rag-task-service 负责索引任务生命周期。

一个文档索引任务通常会经历这些状态：

复制代码 
WAITING
RUNNING
SUCCESS
FAILED
RETRYING
TIMEOUT

状态流转大致如下：

复制代码 
WAITING -> RUNNING -> SUCCESS
WAITING -> RUNNING -> FAILED
FAILED -> RETRYING -> RUNNING -> SUCCESS
RUNNING -> TIMEOUT
TIMEOUT -> RETRYING -> RUNNING

引入 RabbitMQ 后，task-service 会消费索引消息，并执行：

这样可以避免重复消费导致重复入库，也方便管理员查看任务状态和失败原因。

1.4.6 AI 与向量检索层

KnowHub 使用 Spring AI 接入大模型能力。

主要有两类模型：

  • Embedding 模型：把问题和文档片段转成向量。
  • Chat 模型：基于检索到的上下文生成答案。

向量存储使用 PostgreSQL + pgvector。

选择 pgvector 的原因是：

  • 部署简单。
  • SQL 可调试。
  • 适合学习和简历项目。
  • 可以清楚展示 MySQL 与向量库的分工。

MySQL 存业务数据，比如用户、知识库、文档、任务、日志。pgvector 存向量数据，用于相似度检索。

1.4.7 基础设施层

KnowHub 的基础设施包括：

  • MySQL：业务数据。
  • PostgreSQL + pgvector：向量数据。
  • Redis：缓存、状态、幂等锁。
  • RabbitMQ：异步索引消息。
  • MinIO：原始文档对象存储。
  • Nacos：服务注册。
  • Docker Compose：本地和虚拟机依赖编排。

这些组件不是为了堆技术栈，而是分别解决不同问题：

复制代码 
MySQL 解决业务数据持久化
pgvector 解决向量检索
Redis 解决缓存和幂等
RabbitMQ 解决异步解耦
MinIO 解决多服务文件共享
Nacos 解决服务发现
Docker Compose 解决环境复现

1.5 一条完整业务链路

为了让读者建立整体印象，我们先看一个用户从上传文档到完成问答的完整流程。

1.5.1 文档上传和索引链路

这条链路解决的是：文档如何从一个上传文件变成可检索知识。

1.5.2 知识库问答链路

这条链路解决的是：模型如何基于企业私有文档回答问题。

1.6 本书会怎么讲

本书不是一上来就堆 RabbitMQ、MinIO、K8s、Milvus 这些名词，而是按照项目成长路径展开。

整体顺序大致是：

复制代码 
先理解 RAG
-> 搭建 Spring Cloud 项目结构
-> 做 JWT 和用户隔离
-> 做知识库和文档上传
-> 做解析、切片和索引任务
-> 接入 MinIO 和 RabbitMQ
-> 做 Embedding 和 pgvector 检索
-> 完成 RAG 问答闭环
-> 加 Redis、Sentinel 和日志
-> 完成 Vue 用户端和管理端
-> 做部署、测试、异常演练

每一章都会尽量回答三个问题：

  1. 为什么需要这个模块。
  2. 当前项目怎么设计。
  3. 代码里应该怎么落地。

对于刚入门的读者，本书会尽量少用空泛术语，多用具体业务问题解释。比如讲 RabbitMQ，不会只讲 exchange、queue、routing key，而是先讲为什么上传接口不能同步等文档索引完成。讲 MinIO，也不会只讲对象存储，而是先讲为什么多服务部署时本地文件路径会失效。

1.7 常见误区

误区一：RAG 等于调用大模型

RAG 的核心不是"问模型"，而是"先检索，再基于资料回答"。没有文档处理、向量检索、Prompt 约束和引用来源，就只是普通聊天接口。

误区二：有了向量库就一定能答好

向量库只负责找相似内容。切片质量、Embedding 模型、相似度阈值、TopK、Prompt 模板都会影响最终效果。检索不准，回答再流畅也可能是错的。

误区三：企业级项目就是堆技术

MySQL、Redis、RabbitMQ、MinIO、pgvector、Sentinel 都不是为了让简历好看，而是分别解决业务中的真实问题。技术选型必须能讲清楚"为什么需要它"。

误区四：前端只是附属品

如果没有用户端和管理端，后端接口只是能被调用。前端把登录、知识库、上传、任务状态、问答和管理流程串起来，系统才真正可演示、可使用。

误区五：只写成功链路

真实项目不只要考虑成功，还要考虑失败。文档解析失败怎么办？Embedding 超时怎么办？RabbitMQ 重复消费怎么办？MinIO 文件不存在怎么办？用户越权访问怎么办？这些问题才是项目质量的关键。

本章小结

这一章没有急着写代码，而是先把 KnowHub 的业务背景和整体架构讲清楚。

我们先说明了大模型的能力边界：它擅长语言生成，但不能天然知道企业私有知识。然后引出 RAG 的核心思想：先检索资料，再生成答案。

接着，我们把 KnowHub 拆成前端展示层、Gateway 网关层、认证服务、知识库服务、异步任务服务、AI 检索层和基础设施层，说明了 Spring Cloud、JWT、RabbitMQ、MinIO、pgvector、Redis、Sentinel 在系统里的位置。

从下一章开始，我们会进入项目准备和技术选型，看看一个企业级 AI 知识库/RAG 平台应该如何搭建开发环境、组织工程目录，并为后续代码实战打基础。

思考题

  1. 为什么企业知识库不能只依赖大模型直接回答？
  2. RAG 中 "检索" 和 "生成" 分别解决什么问题？
  3. 为什么文档上传后不适合在接口中同步完成解析、切片和向量化？
  4. MinIO 相比本地文件存储，解决了多服务部署中的什么问题？
  5. RabbitMQ 在文档索引链路中承担什么职责？
  6. Gateway 层统一鉴权相比每个服务重复鉴权有什么好处？
  7. pgvector 和 MySQL 在 KnowHub 中分别存储什么数据？
相关推荐
不知疲倦的仄仄1 小时前
MySQL/Read View快照/MVCC/串行化
java·数据库·mysql
奶糖 肥晨1 小时前
mac系统中Java项目环境配置与问题解决全记录｜环境准备篇：JDK与Maven安装配置
java·macos·maven
qq_185198692 小时前
骆驼任务Flowable + Apache Camel 集成
spring·apache·flowable
SimonKing2 小时前
OpenCode 桌面版这 10 天偷偷迭代了 5 个版本，你还在用旧版吗？
java·后端·程序员
lichuangcsdn2 小时前
【Spring AI 学习（一）】spring ai是什么
人工智能·学习·spring·spring ai
Dontla2 小时前
冒烟测试介绍（Smoke Test、BVT构建验证测试、构建验收测试）与回归测试对比、与单元测试对比、与集成测试对比、Cypress
java·单元测试·集成测试
暖和_白开水2 小时前
数据分析agent(十)：loguru日志输出优化 和es 启动流程
java·elasticsearch·数据分析
减瓦2 小时前
Gradle 版本演进全景：构建工具的进化密码
java·gradle
玛丽莲茼蒿2 小时前
很难出错的Spring5（十）—— IOC进阶
java·开发语言·jvm
热门推荐
01GitHub 镜像站点02如何新建文件夹？ 电脑新建文件夹的4种方法032026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片04AI科技热点日报 | 2026年07月01日05国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南092026 年 AI 大模型 & AI 编程工具实战全总结10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新