基于RAG的智能知识库问答系统：SpringBoot+Vue.js毕业设计实战指南

1. 项目缘起与整体设计思路

1.1 这个系统到底解决什么问题

先说说我为什么盯上这个题目。过去一年，我帮不下五个学弟学妹看过毕业设计，其中三个都选了“智能知识库问答”这个方向。原因很简单：大模型火了，但企业里真正落地的痛点不是“模型不够聪明”，而是“模型不知道我们公司内部那点事”。你问ChatGPT“我们公司报销流程是什么”，它只能瞎编；你问“这份设备维修手册里第三章讲了什么”，它也没法直接给你翻出来。这就是RAG（Retrieval-Augmented Generation，检索增强生成）要解决的核心问题——让大模型在回答之前，先去指定的知识库里“查资料”，然后基于查到的内容组织答案。

这个毕业设计题目“基于RAG的智能知识库问答系统的设计与实现”，本质上就是做一个私有化的、能上传文档、能问答、能溯源的知识管理工具。技术栈选的是SpringBoot + Vue.js + MySQL，这是国内高校毕设最稳妥的组合，没有之一。前端用Vue.js配ElementUI，后端SpringBoot扛住接口，MySQL存用户、知识库元数据和问答记录，向量检索部分可以接本地模型或者调用API。整套东西做下来，工作量饱满，技术点覆盖全面，答辩的时候也好讲——既有传统CRUD，又有RAG这种前沿概念，老师想挑刺都得先掂量掂量自己懂不懂向量检索。

适合谁来参考这篇内容？如果你是计算机相关专业的应届生，正在找毕设题目，或者已经选了RAG方向但不知道从哪下手，那这篇东西就是给你写的。我会把架构怎么定、数据库怎么设计、RAG链路怎么串、前后端怎么对接、文档怎么处理这些事全部分享出来。哪怕你之前没接触过向量数据库，跟着思路走也能把系统跑起来。

1.2 为什么选SpringBoot + Vue.js + MySQL这套组合

先解释一下技术选型的逻辑，因为答辩的时候老师必问“你为什么用这个不用那个”。

SpringBoot的优势在于生态成熟、资料多、上手快。你遇到任何问题，搜索引擎里一搜，八成已经有现成答案。而且SpringBoot的自动配置机制让整合MyBatis、Redis、MinIO这些组件变得非常轻松，几个注解加配置文件就能跑起来。对于毕设这种周期短、要求功能全的项目来说，SpringBoot是最不容易翻车的选择。我试过用Quarkus或者Micronaut，性能确实好，但资料少，踩坑成本太高，不值得。

Vue.js配合ElementUI，前端开发效率极高。ElementUI的组件库覆盖了表格、表单、弹窗、上传、分页这些毕设常用元素，你不需要自己写CSS就能搭出一个看起来挺专业的后台界面。而且Vue的响应式数据绑定让前后端联调变得很舒服，后端改个接口字段，前端改个绑定就行，不用手动操作DOM。

MySQL作为关系型数据库，存用户信息、知识库列表、文档元数据、问答历史这些结构化数据绰绰有余。向量数据虽然MySQL 8.0也支持向量类型，但实际做RAG的时候，我建议还是用专门的向量库或者内存索引，MySQL只负责存业务数据。这样分工明确，也方便答辩时解释“为什么不用MySQL存向量”——因为向量检索需要近似最近邻算法，关系型数据库在这方面性能不行。

注意：如果你的学校要求必须用MySQL存所有东西，那也可以把向量序列化成BLOB存进去，检索的时候全量加载到内存算余弦相似度。但知识库文档一多，这种方案就会卡得没法用。所以最好还是把向量检索单独拆出来。

1.3 系统整体架构长什么样

整个系统我把它拆成四层：前端展示层、后端服务层、数据存储层、RAG引擎层。

前端展示层就是Vue.js那套东西，负责登录注册、知识库管理、文档上传、问答对话、历史记录查看这些页面。用户的所有操作都通过HTTP请求打到后端。

后端服务层用SpringBoot，对外提供RESTful接口。核心模块包括：用户认证模块（JWT）、知识库管理模块、文档处理模块、问答服务模块、系统管理模块。每个模块对应一个Controller，业务逻辑放在Service层，数据访问用MyBatis-Plus。

数据存储层分三块：MySQL存业务数据，MinIO或者本地文件系统存原始文档，向量索引存文档切片的向量表示。如果图省事，向量索引可以直接用内存里的一个List，启动时从MySQL加载；如果想做得像样一点，可以接Chroma或者Milvus的轻量版。

RAG引擎层是整个系统的灵魂。它负责把用户的问题转成向量，去向量索引里找最相似的文档片段，然后把问题和检索到的上下文拼成一个Prompt，发给大模型生成答案。这一层可以完全本地化（用Ollama跑一个小模型），也可以调云端API。毕设答辩的时候，本地化方案更稳妥，因为不依赖网络，演示不会翻车。

2. 核心细节解析与实操要点

2.1 数据库表设计：别等到写代码才想这件事

很多同学做毕设的通病是：先写代码，数据库表边写边改，最后发现字段不够用或者关联关系乱了。我建议你先花半天时间把ER图想清楚，后面能省至少三天的返工时间。

这个系统最少需要这几张表：

document表的status字段很关键，用来标记文档的处理状态：0-待处理，1-处理中，2-已完成，3-处理失败。因为文档上传后需要解析、切片、向量化，这个过程可能耗时几秒到几十秒，不能让前端一直等着，所以用异步处理加状态轮询的方式。

document_chunk表的vector_id字段存的是向量在向量库里的唯一标识。如果你用内存索引，这个字段可以存数组下标；如果用Chroma，就存Chroma返回的ID。

qa_record表的sources字段存的是本次回答引用了哪些文档片段，用JSON格式存一个数组，包含文档名和片段内容摘要。前端展示的时候可以做成“引用来源”的折叠面板，答辩的时候这个功能很加分。

实操心得：MySQL建表的时候，字符集统一用utf8mb4，排序规则用utf8mb4_general_ci。别用utf8，那个是假的utf8，存emoji会报错。虽然毕设不一定用到emoji，但养成好习惯没坏处。

2.2 文档处理流水线：从上传到可检索

文档处理是RAG系统里最容易被低估的环节。很多同学以为上传完就完事了，结果问答的时候发现检索出来的内容驴唇不对马嘴。问题就出在文档处理上。

完整的文档处理流程是这样的：

1. 文件上传：前端用ElementUI的Upload组件，后端用MultipartFile接收。文件存到MinIO或者本地磁盘，数据库里只存路径。
2. 格式解析：根据文件扩展名选择解析器。PDF用PDFBox或者Apache Tika，Word用POI，TXT直接读，Markdown按行读。解析出来的是一整段纯文本。
3. 文本清洗：去掉多余的空格、换行、页眉页脚、特殊字符。这一步不做的话，切片里会混入大量噪声，影响检索质量。
4. 文本切片：这是核心步骤。切片太短，语义不完整；切片太长，检索精度下降。我一般用固定长度+重叠的策略：每片500个字符，相邻片之间重叠50个字符。重叠是为了防止关键信息刚好被切在边界上。
5. 向量化：把每个切片送进Embedding模型，得到向量。可以用OpenAI的text-embedding-ada-002，也可以用本地的BGE-small-zh。毕设推荐用本地模型，免费且不依赖网络。
6. 存入向量索引：把向量和对应的切片ID存进向量库。同时把切片内容存进MySQL的document_chunk表。

// 切片核心逻辑示例 public List<String> splitText(String text, int chunkSize, int overlap) { List<String> chunks = new ArrayList<>(); int start = 0; while (start < text.length()) { int end = Math.min(start + chunkSize, text.length()); chunks.add(text.substring(start, end)); start = end - overlap; if (start >= text.length() - overlap) break; } return chunks; }

注意：切片大小不是固定的，要根据文档类型调整。技术文档可以小一点（300-500字），因为概念密集；叙述性文档可以大一点（800-1000字），因为需要上下文。毕设为了简单，统一用500字加50字重叠就行。

2.3 向量检索：RAG的“查资料”环节

向量检索的原理说起来不复杂：把用户的问题也转成向量，然后计算它和知识库里所有切片向量的相似度，取最相似的Top-K个。

相似度计算用余弦相似度，公式是：

similarity = (A · B) / (||A|| * ||B||)

其中A是问题向量，B是切片向量。余弦相似度的值在-1到1之间，越接近1越相似。实际用的时候，因为向量都已经归一化了，所以直接算点积就行。

Top-K的K值怎么定？我试过K=3、K=5、K=10。K太小，可能漏掉关键信息；K太大，会引入无关内容干扰大模型。K=5是个比较稳妥的默认值。如果知识库文档很多，可以先用K=20粗筛，再用重排序模型精排取前5。

// 余弦相似度计算（向量已归一化） public double cosineSimilarity(float[] a, float[] b) { double dot = 0.0; for (int i = 0; i < a.length; i++) { dot += a[i] * b[i]; } return dot; }

检索的时候还有一个关键参数：相似度阈值。低于这个阈值的切片直接丢弃，不送给大模型。阈值设0.7比较合适，太低会引入噪声，太高可能什么都检索不到。这个值需要根据你的Embedding模型和文档特点微调。

实操心得：如果检索效果不好，先别急着换模型。检查一下切片质量，看看检索出来的片段是不是本身就答非所问。很多时候问题出在切片上，不是模型上。

3. 实操过程与核心环节实现

3.1 后端项目搭建与依赖配置

先创建一个SpringBoot项目，用Spring Initializr生成骨架。注意SpringBoot版本别选太新的，3.0以上对JDK版本要求高，而且有些依赖还没适配。推荐用2.7.x版本，稳定且资料多。

pom.xml里需要加这些核心依赖：

<!-- Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <!-- JWT --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- 文档解析 --> <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>2.0.29</version> </dependency> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.3</version> </dependency> <!-- MinIO --> <dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.2</version> </dependency>

application.yml的配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/rag_kb?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true minio: endpoint: http://localhost:9000 access-key: minioadmin secret-key: minioadmin bucket-name: rag-docs

注意：MySQL 8.0的连接URL必须加serverTimezone参数，否则会报时区错误。这个坑我踩过，折腾了半小时才发现。

3.2 文档上传与异步处理实现

文档上传接口不能同步处理，因为解析和向量化可能很慢。我的做法是：上传接口只负责存文件、写数据库记录，然后发一个异步任务去处理。

@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file, @RequestParam("kbId") Long kbId) { // 1. 存文件到MinIO String filePath = minioService.upload(file); // 2. 写数据库记录 Document doc = new Document(); doc.setKbId(kbId); doc.setFileName(file.getOriginalFilename()); doc.setFilePath(filePath); doc.setStatus(0); // 待处理 documentMapper.insert(doc); // 3. 发异步任务 documentProcessService.processAsync(doc.getId()); return Result.success(doc); }

异步处理用@Async注解，记得在启动类上加@EnableAsync。

@Async public void processAsync(Long docId) { Document doc = documentMapper.selectById(docId); doc.setStatus(1); // 处理中 documentMapper.updateById(doc); try { // 解析文本 String text = parseFile(doc.getFilePath()); // 清洗 text = cleanText(text); // 切片 List<String> chunks = splitText(text, 500, 50); // 向量化并存储 for (int i = 0; i < chunks.size(); i++) { float[] vector = embeddingService.embed(chunks.get(i)); String vectorId = vectorStore.add(vector, docId, i); DocumentChunk chunk = new DocumentChunk(); chunk.setDocId(docId); chunk.setContent(chunks.get(i)); chunk.setVectorId(vectorId); chunk.setChunkIndex(i); chunkMapper.insert(chunk); } doc.setStatus(2); // 已完成 doc.setChunkCount(chunks.size()); } catch (Exception e) { doc.setStatus(3); // 失败 log.error("文档处理失败", e); } documentMapper.updateById(doc); }

前端上传后，轮询文档状态接口，直到status变成2或3。

3.3 问答接口的完整链路

问答接口是整个系统最核心的部分。用户在前端输入问题，后端要完成：问题向量化 → 检索 → 拼Prompt → 调大模型 → 返回答案和来源。

@PostMapping("/ask") public Result ask(@RequestBody AskRequest request) { // 1. 问题向量化 float[] queryVector = embeddingService.embed(request.getQuestion()); // 2. 检索Top-K List<SearchResult> results = vectorStore.search(queryVector, request.getKbId(), 5); // 3. 过滤低相似度结果 results = results.stream() .filter(r -> r.getScore() > 0.7) .collect(Collectors.toList()); // 4. 拼Prompt StringBuilder context = new StringBuilder(); for (SearchResult r : results) { context.append(r.getContent()).append("\n\n"); } String prompt = "基于以下资料回答问题。如果资料中没有相关信息，请说不知道。\n\n" + "资料：\n" + context + "\n" + "问题：" + request.getQuestion() + "\n" + "回答："; // 5. 调大模型 String answer = llmService.chat(prompt); // 6. 存记录 QaRecord record = new QaRecord(); record.setUserId(request.getUserId()); record.setKbId(request.getKbId()); record.setQuestion(request.getQuestion()); record.setAnswer(answer); record.setSources(JSON.toJSONString(results)); qaRecordMapper.insert(record); return Result.success(new AskResponse(answer, results)); }

Prompt的写法很关键。我试过几种模板，最后发现**明确告诉模型“资料里没有就说不知道”**能有效减少幻觉。另外，把资料放在问题前面，模型更容易找到依据。

实操心得：如果大模型返回的答案里出现了“根据资料”这种话，可以在Prompt里加一句“回答时不要提及资料二字，直接给出答案”。这样用户体验更好。

3.4 前端关键页面实现

前端用Vue CLI创建项目，装ElementUI和axios。

vue create rag-frontend cd rag-frontend npm install element-ui axios

在main.js里引入ElementUI：

import Vue from 'vue' import ElementUI from 'element-ui' import 'element-ui/lib/theme-chalk/index.css' import App from './App.vue' import router from './router' import axios from 'axios' Vue.use(ElementUI) Vue.prototype.$axios = axios axios.defaults.baseURL = 'http://localhost:8080' new Vue({ router, render: h => h(App) }).$mount('#app')

问答页面是核心，用ElementUI的卡片和输入框搭：

<template> <div class="qa-container"> <el-card> <div slot="header">智能问答</div> <el-select v-model="kbId" placeholder="选择知识库"> <el-option v-for="kb in kbList" :key="kb.id" :label="kb.name" :value="kb.id" /> </el-select> <el-input v-model="question" type="textarea" :rows="3" placeholder="输入你的问题" /> <el-button type="primary" @click="ask" :loading="loading">提问</el-button> </el-card> <el-card v-if="answer"> <div slot="header">回答</div> <p>{{ answer }}</p> <el-collapse> <el-collapse-item title="引用来源"> <div v-for="(src, idx) in sources" :key="idx"> <p>{{ src.fileName }} - 片段{{ src.chunkIndex }}</p> <p>{{ src.content }}</p> </div> </el-collapse-item> </el-collapse> </el-card> </div> </template>

文档上传页面用el-upload组件，设置:http-request自定义上传逻辑，上传成功后轮询状态。

4. 常见问题与排查技巧实录

4.1 检索效果差怎么办

这是RAG系统最常见的问题。用户问“报销流程”，检索出来的却是“考勤制度”。排查思路按这个顺序来：

我遇到过一个典型案例：用户问“设备故障怎么报修”，检索出来的全是“设备采购流程”。后来发现是切片的时候把“报修”和“采购”切到了同一个片里，导致向量语义混杂。把切片大小从1000降到500后问题解决。

4.2 大模型回答不准确或胡编

RAG系统最怕的就是模型“一本正经地胡说八道”。明明检索到了正确资料，模型却给出了错误答案。原因通常是Prompt没写好。

我的经验是Prompt里必须包含这三句话：

1. “仅基于以下资料回答问题”
2. “如果资料中没有相关信息，请直接说‘根据现有资料无法回答’”
3. “不要编造资料中不存在的信息”

另外，把temperature参数调低，0.1到0.3之间比较合适。temperature越高，模型越有创造力，但也越容易胡编。毕设演示的时候，稳定比创意重要。

注意：如果用的是本地小模型（比如Qwen2-1.5B），它的指令遵循能力有限，Prompt要写得更简单直接。别用太复杂的格式要求，它理解不了。

4.3 文档处理速度慢

一个10页的PDF，切片后可能有50-100个片段，每个片段都要调Embedding模型。如果用云端API，受网络影响可能要好几分钟。优化方案：

• 批量向量化：把多个切片拼成一个batch，一次请求返回多个向量。大多数Embedding API都支持batch输入。
• 本地模型：用ONNX Runtime跑BGE-small，CPU上单条推理只要几十毫秒，比调API快得多。
• 异步+进度反馈：前端显示处理进度，用户知道系统在工作，不会以为卡死了。

// 批量向量化示例 public List<float[]> embedBatch(List<String> texts) { // 每批最多16条 List<float[]> vectors = new ArrayList<>(); for (int i = 0; i < texts.size(); i += 16) { int end = Math.min(i + 16, texts.size()); List<String> batch = texts.subList(i, end); vectors.addAll(embeddingClient.embed(batch)); } return vectors; }

4.4 前端跨域和文件上传大小限制

前后端分离开发时，跨域是必踩的坑。后端加一个配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowCredentials(true) .maxAge(3600); } }

文件上传大小限制在application.yml里改：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 50MB

实操心得：MinIO的bucket权限要设成public read，否则前端拿到的文件URL访问不了。但生产环境别这么干，毕设演示无所谓。

4.5 数据库连接池配置

MySQL默认的连接数很少，并发一高就报“Too many connections”。在application.yml里配一下HikariCP：

spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000

这个配置对毕设来说绰绰有余。如果答辩演示时有多人同时访问，也不会崩。

5. 论文写作与答辩准备建议

5.1 论文结构怎么安排

毕设论文一般要求1.5万到2万字，章节安排我建议这样：

第一章绪论，讲研究背景和意义，重点说清楚“为什么需要RAG”和“现有知识库系统有什么不足”。第二章相关技术介绍，把SpringBoot、Vue.js、RAG、向量检索这些概念解释清楚，别抄百度百科，用自己的话讲。第三章需求分析，画用例图、功能模块图。第四章系统设计，画架构图、ER图、流程图。第五章系统实现，贴核心代码和界面截图。第六章测试，写功能测试和性能测试。第七章总结与展望。

注意：论文里的图别用Mermaid画，用Visio或者Draw.io画好导出PNG。Mermaid渲染出来的图在Word里容易乱码。

5.2 答辩时老师可能问的问题

根据我帮人模拟答辩的经验，这几个问题出现频率最高：

• “你的RAG和直接问ChatGPT有什么区别？”——答：RAG能基于私有知识库回答，且能溯源，ChatGPT不知道你的私有数据。
• “向量检索的相似度怎么算的？”——答：余弦相似度，公式是……
• “如果知识库很大，检索会不会很慢？”——答：可以用近似最近邻算法（如HNSW）建索引，把复杂度从O(n)降到O(log n)。
• “你的系统有什么创新点？”——答：把RAG落地到毕设场景，实现了文档自动处理和引用溯源，工程完整度高。
• “为什么不用LangChain？”——答：LangChain封装太厚，出问题不好排查。自己实现链路更可控，也更能体现工作量。

5.3 源码和文档整理

毕设提交一般要求源码+论文+答辩PPT。源码目录结构要清晰：

rag-kb-system/ ├── backend/ # SpringBoot后端 │ ├── src/main/java/ │ │ ├── controller/ │ │ ├── service/ │ │ ├── mapper/ │ │ ├── entity/ │ │ └── config/ │ └── pom.xml ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── views/ │ │ ├── components/ │ │ └── router/ │ └── package.json ├── sql/ # 建表语句 │ └── init.sql └── README.md # 部署说明

README里写清楚环境要求、启动步骤、默认账号密码。答辩老师如果让你现场演示，你直接按README操作就行，不会手忙脚乱。

实操心得：提前把演示数据准备好，上传几份文档，问几个典型问题，把问答记录也预置几条。答辩现场网络可能不稳定，如果调云端API卡住了，就切到本地模型。我建议至少准备一套完全离线的方案作为保底。

5.4 后续扩展方向

这个系统做完之后，如果想继续深挖，有几个方向可以扩展：一是加入多轮对话能力，让用户能追问；二是加入权限管理，不同用户看到不同知识库；三是加入知识图谱，把实体关系也纳入检索范围；四是加入反馈机制，用户可以对回答点赞点踩，用来优化检索排序。这些扩展点写在论文的“展望”章节里，能体现你对领域的理解深度。

最后再分享一个小技巧：答辩PPT别放太多字，每页一个核心点，配一张图。老师看的是你的思路和演示效果，不是你的PPT排版。把系统跑通、把问题答上来，比什么都强。