2026 最热的课设方向：用 Spring AI + RAG 给课程资料做个智能问答助手

如果要问今年计算机专业课设里哪个方向最热答案几乎没有悬念接入大模型的智能问答。原因很现实老师在评审时对增删改查管理系统已经审美疲劳了而一个能基于课程资料准确回答问题的助手演示起来效果完全不同——你问它快速排序最坏情况为什么退化到 O(n²)它能引用你上传的课件第 42 页给出推导这个画面足够让老师记住你。但难点也很明显大部分人的实现只是调了个聊天接口没有知识库回答全靠模型瞎编一问具体知识点就露馅。真正的做法是 RAG检索增强生成。这篇把整条链路讲清楚文档解析 → 切片 → 向量化 → 检索 → 拼装上下文 → 流式输出 → 引用溯源。一、技术选型为什么用 pgvector 而不是 Milvus课设环境装 Milvus 是灾难Docker 拉镜像 2G内存吃满。pgvector 只需CREATE EXTENSION vector和你已有的 PostgreSQL 是同一个库部署成本为零。这个取舍写进文档是很好的工程权衡论据。二、整体链路上传课件 → Tika 解析纯文本 → 按语义切片(800字/重叠100) → 调嵌入模型 → 存 vector(1536) 到 pgvector ↓ 用户提问 → 向量化 → 相似度检索 Top-K → 重排 → 拼成 Prompt → 调大模型(SSE 流式) → 返回答案 引用来源这条链路每一步都有讲究下面挑最关键的三个讲。三、核心难点 1切片策略决定回答质量RAG 效果好不好70% 取决于切片而不是模型。三种切法对比public ListDocument split(MarkdownDocument doc) { TokenTextSplitter splitter new TokenTextSplitter( 800, // 单块目标长度token 100, // 块间重叠防止答案刚好跨在切口上 5, // 最小块长度太碎的直接丢弃 10000, true // 保留段落边界 ); ListDocument chunks splitter.apply(List.of(doc)); // 关键给每块补上元数据后面引用溯源全靠它 for (int i 0; i chunks.size(); i) { chunks.get(i).getMetadata().put(source, doc.getMetadata().get(filename)); chunks.get(i).getMetadata().put(page, doc.getMetadata().get(page)); chunks.get(i).getMetadata().put(chunkIndex, i); } return chunks; }元数据是引用溯源的基础。没有source和page模型就算答对了你也说不出这句话来自课件第 42 页而这个引用恰恰是演示时最有说服力的地方。四、核心难点 2检索质量Top-K 不够就加重排只做向量相似度检索有个通病召回的块看起来相关但对回答没用。解决办法是两步检索public String answer(String question, String kbId) { // 第一步向量检索多召回一些Top 20 SearchRequest req SearchRequest.query(question) .withTopK(20) .withSimilarityThreshold(0.5) .withFilterExpression(kbId kbId ); // 限定知识库避免串库 ListDocument candidates vectorStore.similaritySearch(req); // 第二步重排压缩到 Top 5 再喂给模型 ListDocument top rerank(question, candidates, 5); String context top.stream() .map(d - 【来源 d.getMetadata().get(source) 第 d.getMetadata().get(page) 页】\n d.getText()) .collect(Collectors.joining(\n\n---\n\n)); return chatClient.prompt() .system(SYSTEM_PROMPT) .user(u - u.text( 只根据下面的资料回答问题资料中没有的内容请直接说资料中未涉及不要编造。 回答末尾用 [1][2] 标注引用序号。 {context} 问题{question} ).param(context, context).param(question, question)) .call() .content(); }withFilterExpression这一步很多人会漏如果你的系统里同时有数据结构操作系统两个知识库不加过滤就会串库问数据结构却召回操作系统的内容。系统提示词里那句资料中没有就说未涉及是整个方案的灵魂——它把胡说八道变成了诚实拒答这是 RAG 相比纯聊天最本质的改进文档里一定要重点写。五、核心难点 3SSE 流式输出大模型生成一段 500 字的回答要 10 秒如果等全部生成完再返回用户会以为卡死了。必须用 SSE 边生成边推GetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxServerSentEventString stream(RequestParam String q, RequestParam String kbId) { return chatClient.prompt() .user(buildPrompt(q, kbId)) .stream() .content() .map(chunk - ServerSentEvent.builder(chunk).build()) .concatWith(Flux.just(ServerSentEvent.builder([DONE]).build())); }前端用fetchReadableStream逐块追加const res await fetch(/api/chat/stream?q${encodeURIComponent(q)}kbId${kbId}, { headers: { Authorization: Bearer ${token} } }) const reader res.body.getReader() const decoder new TextDecoder() let answer while (true) { const { done, value } await reader.read() if (done) break const chunk decoder.decode(value, { stream: true }) if (chunk.includes([DONE])) break answer chunk.replace(/^data:\s*/, ) messages[messages.length - 1].content answer // 响应式更新 }一个小细节SSE 的数据格式是data: xxx\n\n前端要剥掉前缀空行是消息分隔符别直接JSON.parse整块。六、页面效果对话页的核心是答案 引用左边是会话列表右边是消息流答案下方显示引用来源文档和页码引用条这一块我特意做了来源课件第 42 页的形式——它直接回答了老师最可能的质疑你怎么证明答案不是编的知识库管理页负责文档的上传、切片状态和检索命中率统计检索命中率这个指标值得做记录每次问答用户是否点了有用/没用命中率 有用次数 / 总次数。虽然简单但它让系统有了可度量的属性文档里的系统评估章节就有数据可写了——这一章绝大多数人都是空着的。七、四周排期这个题目比前几个多一周如果只有两周砍掉文档解析改成手动粘贴文本入库砍掉重排Top-K 直接取 5。核心链路仍然是完整的 RAG不影响答辩。八、三个容易翻车的点成本失控嵌入模型按量计费一个 200 页的课件全量向量化不便宜。开发阶段先把课件截取前 20 页测试跑通再全量。超时大模型接口默认超时可能只有 10 秒长回答直接断流。把RestClient的读超时调到 60 秒。敏感信息别把学校内部资料、学生信息传到第三方接口。这一点在文档的合规性说明里写一句是很成熟的考虑。九、这个题目为什么容易拿高分选题新大模型 RAG 是当下最热的工程方向老师也会好奇有真实效果演示时能答对具体知识点比我实现了增删改查强太多技术栈有层次文档解析、向量检索、流式通信、提示工程每一层都能写一节可讲清楚取舍为什么用 pgvector 不用 Milvus、为什么切片 800 字、为什么要重排——这些都是你思考过的证据最后这个题目代码量其实不大后端核心不到 15 个类但概念密度高文档写起来最费劲向量、嵌入、切片、召回、重排、提示词每个词都要解释清楚又不显得像抄的。如果时间紧张建议先把能跑通的最小链路搭出来上传一段文本 → 提问 → 得到带引用的回答再回头补功能和文档。跑通之后再写文档思路会顺很多——这一点对所有课设都适用。五篇选题到这里就写完了Java 后端、Python 后端、小程序、React 全栈、AI 应用覆盖了目前主流的五个方向。需要哪一篇的详细实现比如完整的库表脚本或接口清单可以留言告诉我。