小滴课堂SpringAI Alibaba+RAG+Milvus 传统应用升级项目实战

这门课的主题很明确：把一个大模型能力接进已有的 Spring 后端应用，而不是从零写一个 demo。它选的技术路线是 SpringAI Alibaba + RAG + Milvus，模型侧用 Ollama 在本地跑 Qwen3。对已经写过 Spring Boot、手里有存量业务系统的开发者来说，这个组合的可对照价值比较高，因为每一层都能落到具体的 jar 依赖、配置项和数据流上。

技术栈的取舍：为什么是 SpringAI Alibaba 而不是裸调 HTTP

很多团队接入大模型的第一版代码，是在 Service 里拼一个 RestTemplate 或 WebClient，手写 JSON 请求体，再把返回的 choices 字段解析出来。这种写法能跑，但提示词模板、对话历史、流式输出、函数调用、向量库检索这些能力都得自己攒。SpringAI 的价值在于把这些抽象成可注入的 Bean：ChatClient 管调用，PromptTemplate 管模板，Advisor 管拦截增强，VectorStore 管检索。SpringAI Alibaba 在此之上补了对国内模型与阿里系组件的适配。

对应到工程里，最值得关注的是依赖坐标和自动配置类。看源码时先确认 starter 引入了哪些 AutoConfiguration，再顺着 Condition 注解找默认实现，就能判断哪些 Bean 需要自己覆盖。这个思路比死记 API 更有用，因为版本迭代时 API 会变，配置装配的套路基本稳定。

项目结构可以拆成哪几块复用的部分

这类升级型项目通常不是单体平铺，而是按职责分层。可以重点看四块：

• 模型接入层：Ollama 的本地服务地址、模型名、超时与重试参数如何配置化，便于在本地 Qwen3 和线上模型之间切换。
• 检索层：文档切分策略、Embedding 模型选择、Milvus 的 collection 结构与索引类型、相似度阈值与 topK 的取值。
• 编排层：把检索结果拼进提示词的模板设计，以及多轮对话中历史消息的截断策略。
• 业务接口层：原有 Controller 如何在不破坏既有契约的前提下新增 AI 能力，比如新增一个端点而不是改动老接口的返回结构。

这四块里，检索层最容易出问题。切分粒度太粗，召回内容噪声大；太细，上下文被割裂。Milvus 那边还要注意维度必须和 Embedding 模型输出一致，索引选 IVF 还是 HNSW 取决于数据量和召回要求。这些细节在视频里往往一带而过，但恰恰是照着敲代码时最容易卡住的地方。

RAG 的落地难点不在框架，在数据

RAG 的链路本身并不复杂：文档入库、向量化、检索、拼接、生成。真正决定效果的是数据准备。文档格式是否统一、是否需要清洗页眉页脚、表格和代码块如何处理、增量更新时如何避免重复写入，这些问题框架不会替你解决。看这门课时，建议把注意力放在文档加载器和切分器的实现上，理解它用了哪种 Reader、按什么规则切、元数据存了哪些字段。元数据很关键，因为它决定了后续能不能按业务维度过滤检索范围。

另外要留意检索结果注入提示词的方式。是把原文直接塞进去，还是带上来源标识和序号。后者在需要引用溯源的场景里更好扩展，也方便后续做答案评估。

本地部署这条线的实际意义

用 Ollama 跑 Qwen3，最大的好处是省掉 API 成本和网络依赖，调试时可以反复试提示词而不用担心计费。代价是显存和推理速度。课程从 Ollama 的模型管理讲起，这部分对没接触过本地推理的后端来说是必要铺垫：模型拉取、量化版本选择、上下文长度设置、并发请求下的表现，都会直接影响你本地跑通后的体感。如果你打算把同样的代码搬到线上，需要提前想清楚模型侧的替换方案，接口层要保持可配置。

怎么用这份资料

建议的路径是先跑通最小链路：本地起 Ollama，写一个只调模型不带检索的接口，确认依赖和配置没问题。然后再加上 Milvus，灌一批自己的文档，观察召回质量。最后才去做提示词调优和多轮对话。

学习过程中以代码为主线，视频当讲解补充。遇到版本相关的报错，优先查 starter 的自动配置类和官方示例，而不是照着视频里的行号硬对。这门课适合拿来对照实践，边改边验证，比连着看完再动手有效得多。