1. 为什么我最终选了RAG而不是微调来做知识库问答毕业设计选题那会儿我在微调一个大模型和用RAG搭一套知识库问答之间纠结了差不多一周。导师一句话点醒我你手头有多少标注数据我算了算零。实验室积累的文档倒是一大堆PDF、Word、Markdown混在一起但没人有精力去清洗成指令微调数据集。这就是我转向RAG的直接原因。RAG全称Retrieval-Augmented Generation检索增强生成。说人话就是模型本身不记住你的私有知识而是每次回答前先去你的知识库里翻书把翻到的相关段落塞进提示词再让大模型基于这些段落组织答案。这个思路对毕业设计特别友好——你不需要训练不需要GPU集群一台普通笔记本就能跑起来而且知识更新只需要往库里加文档不用重新训练。我这套系统的定位很明确面向中小团队或个人的私有文档问答。典型场景是你有一堆产品手册、内部规范、课程讲义想让人用自然语言提问就能拿到答案而不是靠CtrlF一个个翻。技术栈上我选了SpringBoot做后端、Vue.js做前端、MySQL存业务数据向量检索这块用LangChain4j串起来。选SpringBoot是因为生态成熟、资料多出问题好查选Vue.js是因为Element UI那套组件拿来就能用前端不用从零造轮子。这篇文章我会把整个系统的设计思路、关键代码、踩过的坑全部摊开讲。不管你是正在做类似毕设还是想给团队搭一个内部知识助手都能直接抄作业。我会重点讲清楚三件事文档怎么切、向量怎么存和检索、检索结果怎么喂给大模型才能答得准。这三件事决定了RAG系统到底是能用还是智障。2. 整体架构一条从文档到答案的完整链路2.1 系统分层与模块划分我把整个系统拆成了四层这样职责清晰调试的时候也容易定位问题出在哪一层。第一层是文档接入层负责把各种格式的原始文档读进来。支持PDF、Word、Markdown、纯文本这几种最常见格式。这一层的核心任务不是读而是清洗——把页眉页脚、乱码、多余空行去掉因为脏数据会直接污染后面的检索质量。第二层是向量化与存储层。文档清洗完要切成小块chunk每块通过Embedding模型转成一个高维向量存进向量库。这里我用的是LangChain4j的Embedding接口底层可以接不同的模型实现。向量库我选了内存版的EmbeddingStore做开发调试生产环境可以换成Milvus或PgVector接口基本不用改。第三层是检索与生成层也是RAG的核心。用户提问后问题先被向量化然后去向量库做相似度检索召回Top-K个最相关的文档块拼成上下文连同问题一起发给大模型拿到最终答案。第四层是业务与展示层SpringBoot提供REST接口Vue.js负责聊天界面、知识库管理、文档上传这些交互。MySQL存的是用户、会话、文档元数据这些结构化信息向量本身不进MySQL。2.2 技术选型背后的取舍很多人做毕设喜欢堆技术什么新用什么结果自己都调不通。我的原则是每个组件都要能说清楚为什么是它。组件选型理由备选方案后端框架SpringBoot 3.x生态成熟自动配置省事社区问题好搜早期版本Gradle构建的项目配置更繁琐前端Vue.js Element UI组件丰富表格/上传/对话框开箱即用React Ant Design关系库MySQL 8毕设标配安装配置资料多PostgreSQL向量检索LangChain4j 内存Store纯Java和SpringBoot无缝集成Python的LangChain需跨语言调用大模型本地Ollama或云端API本地零成本云端效果好二选一按需切换对象存储MinIO文档原文件存储S3兼容直接存本地磁盘这里重点说下为什么用LangChain4j而不是Python的LangChain。我的后端是Java如果检索逻辑用Python写就得再起一个服务跨语言调用增加复杂度和故障点。LangChain4j是Java原生的Embedding、向量存储、对话链这些抽象都有直接注入Spring容器就能用调试也方便。代价是它的生态没有Python版丰富但对毕设这种规模完全够用。2.3 数据流转的完整过程把链路串起来看是这样的用户上传一份PDF后端用解析库把文字抽出来清洗后按规则切成若干chunk每个chunk调Embedding模型拿到向量向量连同chunk原文和元数据来源文件、页码一起存进向量库原文件丢进MinIO元数据写进MySQL。用户提问时问题向量化去向量库检索Top-K拿到chunk列表按相似度分数排序拼成上下文提示词发给大模型流式返回答案同时把命中的来源标注出来。整个过程中MySQL只参与会话和文档管理不参与向量计算这样职责分离性能也好控制。3. 文档切分RAG效果好坏的第一道分水岭3.1 为什么切分策略比模型选择更关键我一开始天真地以为只要模型够强检索差点也能答对。实测下来完全不是这么回事。有一次我拿一份技术规范提问模型答得驴唇不对马嘴我以为是模型不行换了个更大的模型还是错。最后发现问题出在切分上——我把整份文档按固定500字硬切结果一个完整的操作步骤被从中间截断前半段在chunk 3后半段在chunk 4检索只召回了chunk 3模型看到的是残缺信息自然答不对。这件事让我明白切分决定了检索的上限。切得不好再强的模型也救不回来。切分的核心目标是让每个chunk语义完整、自包含同时大小适中。太小则信息碎片化太大则噪声多、检索精度下降。3.2 我实际采用的递归切分方案我最终用的是递归字符切分配合中文标点做分隔符。逻辑是优先按段落切段落太长再按句子切句子还长再按逗号切层层降级尽量保证语义边界。// 递归切分核心配置 DocumentSplitter splitter DocumentSplitters.recursive( 500, // 每个chunk最大字符数 50, // chunk之间的重叠字符数 new ChineseParagraphSplitter() // 自定义中文分隔逻辑 );这里有两个参数要重点解释。chunk大小500不是拍脑袋定的。中文一个汉字大约对应1到2个token500字大概700到1000 token这个量级既能容纳一个完整知识点又不会让上下文过长导致模型注意力分散。重叠50字是为了防止边界信息丢失——如果一句话正好被切在边界上重叠部分能让相邻两个chunk都包含它检索时至少有一个能命中。分隔符的优先级我设成段落换行 句号/问号/感叹号 分号 逗号 空格。中文标点和英文不一样句号是。不是.这个细节不注意切分效果会差很多。3.3 针对不同文档类型的差异化处理一刀切的切分策略对付不了所有文档。我根据文档类型做了差异化处理。对于结构化的技术手册我优先按标题层级切。Markdown的##、###就是天然的语义边界按标题切出来的chunk自带层级信息检索时还能把父标题拼进去增强语义。对于问答对形式的FAQ文档我直接按问-答配对切一个问答就是一个chunk这样检索命中的就是完整的一问一答效果特别好。对于连续叙述的长文才用上面说的递归切分。还有一个容易被忽略的点给每个chunk加上下文头。我在每个chunk前面拼上它所属的文档标题和章节路径比如《XX系统操作手册》第三章 数据备份 3.2 增量备份。这样即使chunk本身没提到备份这个词检索时也能靠上下文头匹配上。实测这一招对提升召回率帮助很大。提示切分参数没有万能值。500字是我在技术文档上试出来的经验值你做法律文书或小说可能得调。建议准备20到30个测试问题用不同参数跑一遍看召回率再定。4. 向量检索从能搜到到搜得准的调优过程4.1 Embedding模型的选择与本地化部署Embedding模型负责把文本转成向量它的质量直接决定检索准不准。我试过三种方案调用云端Embedding API、用Ollama跑本地模型、用LangChain4j内置的轻量模型。云端API效果最好但有两个问题一是要联网二是按量计费毕设演示时网络一抖就尴尬。所以我最终选了本地部署用Ollama拉了一个中文效果不错的小模型。本地部署的好处是零成本、离线可用、数据不出本地缺点是首次加载慢且对机器内存有要求。# 拉取并运行本地embedding模型 ollama pull nomic-embed-text ollama serve然后在SpringBoot里配置LangChain4j的Embedding模型指向本地服务Bean public EmbeddingModel embeddingModel() { return OllamaEmbeddingModel.builder() .baseUrl(http://localhost:11434) .modelName(nomic-embed-text) .build(); }这里有个坑要提醒Embedding模型和生成模型是两回事。Embedding模型只负责把文本转向量不做问答生成模型才负责组织答案。两者可以来自不同厂商别搞混了。我一开始想用一个模型全包结果发现Embedding和生成对模型能力的要求完全不同分开选反而效果更好。4.2 相似度计算与Top-K召回策略向量存进去之后检索就是算相似度。常用的是余弦相似度值越接近1越相关。LangChain4j的EmbeddingStore封装了这套逻辑调search方法传问题和K值就行。Embedding queryEmbedding embeddingModel.embed(question).content(); ListEmbeddingMatchTextSegment matches embeddingStore.search( EmbeddingSearchRequest.builder() .queryEmbedding(queryEmbedding) .maxResults(5) // Top-K .minScore(0.6) // 相似度阈值 .build() ).matches();Top-K取多少是个需要权衡的参数。K太小可能漏掉关键信息K太大噪声多还会撑爆上下文窗口。我实测下来K5是个不错的起点。minScore阈值更重要它是一道过滤网低于阈值的直接扔掉。我设0.6低于这个分数的基本是无关内容硬塞给模型反而干扰判断。但纯向量检索有个天然缺陷它擅长语义匹配不擅长精确匹配。比如你问错误码E0434352是什么意思向量检索可能召回一堆讲错误处理的段落却没召回那个精确提到E0434352的段落。这时候就需要混合检索来补。4.3 混合检索向量加关键词的双保险我的做法是向量检索和关键词检索并行跑然后合并结果。关键词检索用MySQL的全文索引或者简单的LIKE匹配都行重点是把精确命中的结果加权提上来。具体策略是向量检索召回Top-5关键词检索召回Top-5两边的结果按文档块ID去重合并向量命中的给基础分关键词命中的额外加分最后统一排序取Top-5喂给模型。这样既保留了语义理解能力又补上了精确匹配的短板。实测这个改动让查具体错误码、查具体函数名、查具体配置项这类问题的准确率提升非常明显。纯向量检索时这类问题经常答非所问混合之后基本能精准命中。4.4 检索质量的量化评估光靠感觉说效果变好了不严谨毕设答辩时老师也会问你怎么证明。我建了一个小测试集30个问题每个问题人工标注了应该命中的文档块。然后算两个指标——召回率该命中的有没有被召回和命中率召回的里面有多少是相关的。检索方案召回率命中率纯向量 Top-573%68%纯关键词60%82%混合检索90%79%数据说明混合检索在召回率上优势明显命中率略低于纯关键词但差距不大综合来看是最优解。这套评估方法也成了我论文里实验与分析章节的核心内容比空谈效果良好有说服力得多。5. 提示词工程让大模型基于检索结果老实回答5.1 上下文拼接的格式设计检索回来的chunk怎么拼进提示词直接影响模型的表现。我试过几种格式最后固定成带编号和来源的结构你是一个严谨的知识库助手请仅根据下面提供的资料回答问题。 如果资料中没有相关信息请直接说根据现有资料无法回答不要编造。 【资料1】来源操作手册.pdf 第3章 chunk内容 【资料2】来源FAQ.md chunk内容 用户问题xxx这个格式有几个讲究。编号让模型能引用来源回答时可以标注根据资料1。来源信息方便用户溯源也方便我调试时看命中了哪些文档。**仅根据资料回答**这句约束是防幻觉的关键不加这句模型很容易自由发挥把训练时的知识混进来。5.2 防幻觉与不知道的处理RAG最大的价值之一是能说我不知道。纯大模型问它没见过的知识它会一本正经地编RAG因为检索不到就会明确告诉你查不到。但前提是提示词里要明确授权它说不知道。我踩过一个坑早期提示词写的是请回答用户问题结果模型检索不到相关内容时硬是拿检索到的无关片段拼凑了一个看似合理的答案。后来改成如果资料中没有相关信息请直接说无法回答幻觉率大幅下降。还有一个技巧是要求模型标注引用。让它回答时带上[资料2]这样的标记一方面方便用户核实另一方面也逼着模型真的去看资料而不是凭记忆瞎答。5.3 多轮对话中的上下文管理知识库问答经常是多轮的用户会追问。如果每轮都重新检索可能丢失上一轮的语境。我的处理是把最近几轮对话历史也拼进提示词同时对当前问题做查询改写——结合历史把它呢那这个怎么配这种指代消解成完整问题再去检索。// 查询改写示例结合历史把省略问题补全 String rewritten queryRewriter.rewrite(currentQuestion, chatHistory); // 那这个怎么配 - MySQL连接池怎么配置这一步对多轮体验提升很大。不做改写的话用户追问那它呢检索系统根本不知道它指什么召回的全是无关内容。6. 工程落地SpringBoot与Vue.js的集成细节6.1 后端接口设计与流式返回后端我按RESTful风格设计了几个核心接口文档上传、知识库列表、问答对话、会话历史。问答接口用SSE做流式返回让答案像打字一样逐字出现体验比等半天一次性返回好得多。GetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter chatStream(RequestParam String question, RequestParam String sessionId) { SseEmitter emitter new SseEmitter(0L); // 异步执行检索生成逐token推送 chatService.streamAnswer(question, sessionId, emitter); return emitter; }SSE的好处是单向推送、实现简单、浏览器原生支持。相比WebSocket问答场景不需要双向通信SSE足够了。6.2 前端聊天界面与文档管理前端用Vue.js加Element UI主要两个页面聊天页和知识库管理页。聊天页就是个消息列表加输入框消息气泡区分用户和助手助手消息支持Markdown渲染和来源标注。管理页用el-upload做文档上传el-table展示已入库文档支持删除和重新索引。有个细节值得说上传大文件时要显示解析进度。一份几百页的PDF解析加向量化可能要几十秒如果界面一直转圈没反馈用户会以为卡死了。我用WebSocket把解析进度推给前端体验好很多。6.3 文档原文件存储与MinIO集成原文件我存MinIO而不是直接扔数据库或本地磁盘。原因是MinIO是S3兼容的对象存储部署简单扩容方便而且和业务数据分离备份迁移都清晰。SpringBoot集成MinIO就是加个依赖、配个客户端Bean的事。Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(http://localhost:9000) .credentials(minioadmin, minioadmin) .build(); }上传时把文件流写进MinIO返回一个对象key存进MySQL的文档表。下载和预览时用key去MinIO取。这样MySQL里只有轻量的元数据不会因为存大文件而膨胀。7. 那些让我熬夜的坑与排查过程7.1 MySQL连接池耗尽导致问答卡死系统上线演示前一天我压测时发现连续问十几个问题后接口就不响应了。日志里全是Could not get JDBC connection。排查下来是连接池配置太小默认HikariCP最大连接10个而我的问答流程里一个请求要多次查库并发一上来就耗尽了。解决是把最大连接数调到20同时检查代码里有没有忘记关闭的连接。这里有个经验流式接口里千万别长时间持有数据库连接。我一开始在SSE的整个生命周期里都开着事务导致连接被占住不放。改成先查完数据、关掉连接再慢慢推送流问题就没了。7.2 向量维度不匹配的隐蔽报错换Embedding模型时踩了个坑新模型输出768维向量但向量库是按之前384维建的存进去直接报维度不匹配。这个错还算明显更坑的是有些向量库不报错而是静默截断或补零导致检索结果莫名其妙地差。教训是换Embedding模型必须重建整个向量库。不同模型的向量空间完全不兼容混用等于灾难。我在代码里加了个校验存向量前检查维度不一致直接抛异常避免静默出错。7.3 中文分词的边界问题用HanLP做关键词检索时发现数据备份被切成了数据和备份两个词检索数据备份反而匹配不到完整短语。这是分词粒度的问题。解决办法是关键词检索时同时用分词结果和原始短语做匹配短语精确匹配的给更高权重。7.4 大模型返回格式不稳定的处理让模型标注来源时它有时候返回[资料1]有时候返回资料1有时候干脆不标。格式不稳定导致前端解析来源时经常失败。我的处理是用正则宽松匹配把各种括号形式都兼容进来匹配不到就降级为不显示来源不让格式问题影响主流程。8. 系统还能怎么往下做这套系统跑通之后我陆续想了一些扩展方向也分享给正在做类似项目的你。GraphRAG是最近很火的方向。普通RAG是按块检索块与块之间的关系是断的。GraphRAG把知识抽成实体和关系图谱检索时能沿着关系链找到关联信息对某某和某某是什么关系这类问题效果更好。实现上可以引入图数据库把文档里的实体关系抽出来建图。Agentic RAG是另一个思路让模型自己决定要不要检索、检索几次、用什么查询。比如第一次检索结果不理想模型可以自动改写查询再检一次。这比固定的一次检索灵活但工程复杂度也高适合作为进阶方向。多模态检索也值得做。现在只能检索文本如果能把图片、表格也向量化那技术文档里的架构图、数据表就能被检索到覆盖面会广很多。检索结果重排序是个性价比很高的优化。初次召回用向量快速筛然后用一个更精细的rerank模型对Top结果重新排序把最相关的顶上来。这一步通常能再提升几个点的准确率代价是增加一点延迟。最后说句实在的RAG系统的效果是调出来的不是搭出来的。框架搭起来可能就几天但切分参数、检索策略、提示词这些细节的打磨才是真正拉开差距的地方。我前后调了差不多两周才从能答变成答得准。你做的时候也别指望一次到位准备好测试集边测边调数据会告诉你哪里该改。