黑马Java跟学.SpringAI+DeepSeek大模型应用开发实战.大模型应用开发篇
黑马SpringAI跟学
黑马Java跟学.SpringAI+DeepSeek大模型应用开发实战.大模型应用开发篇
一、介绍
1.AI时代Java程序员的出路在哪里?
2022年11月30日,OpenAI公司发布了GPT3.5模型,同时对外开放了ChatGPT产品。人工智能突然进入了普通人的生活中,各种AI应用如雨后春笋般出现。
2025年1月20日,位于杭州的DeepSeek公司正式发布了具有划时代意义的DeepSeek-R1模型,该模型在数学、代码、自然语言推理等任务上,性能比肩 OpenAI o1 正式版,且训练成本仅为 560 万美元,远低于美国科技巨头的数亿美元乃至数十亿美元投入,这一突破彻底震惊了全球科技界。
要知道,全球有25亿+的Java应用正在运行,超过90的服务端应用都是采用Java语言!传统应用要向AI领域进军,最好的办法一定是使用Java语言。
然而,一直以来,AI开发似乎都是Python的强项,传统Java应用想要AI化,缺少完善的解决方案和即懂Java、又懂AI的人才,而这就是最大的机会!
2.为什么是SpringAI
目前大模型应用开发最常见的框架就是LangChain,然而LangChain是基于Python语言,虽然有LangChain4j,但是对于大量使用Spring生态的应用来说,适配性就稍微差了些。
而Spring公司推出的SpringAI框架,充分利用了Spring框架中AOP、IOC的能力,可以与现有的Java项目无缝融合,非常方便。
当然,SpringAI要求的JDK版本至少是JDK17,SpringBoot也必须是3.x的版本才可以,所以如果想要使用SpringAI,必须先升级JDK和SpringBoot版本才行。
如果是比较老的项目,也可以考虑采用LangChain4j,它要求的最低JDK版本为JDK8.
3.课程目录
课程介绍
课程收获
二、认识AI和大模型
1.人工智能的发展
AI,人工智能(Artificial Intelligence),使机器能够像人类一样思考、学习和解决问题的技术。
AI发展至今大概可以分为三个阶段:
其中,深度学习领域的自然语言处理(Natural Language Processing, NLP)有一个关键技术叫做Transformer,这是一种由多层感知机组成的神经网络模型,是现如今AI高速发展的最主要原因。
我们所熟知的大模型(Large Language Models, LLM),例如GPT、DeepSeek底层都是采用Transformer神经网络模型。
以GPT模型为例,其三个字母的缩写分别是Generative、Pre-trained、Transformer:
2.大模型原理
其实,最早Transformer是由Google在2017年提出的一种神经网络模型,一开始的作用是把它作为机器翻译的核心:
Transformer中提出的注意力机制使得神经网络在处理信息时可以根据上下内容调整对数据的理解,变得更加智能化。这不仅仅是说人类的文字,包括图片、音频数据都可以交给Transformer来处理。于是,越来越多的模型开始基于Transformer实现了各种神奇的功能。
例如,有的模型可以根据音频生成文本,或者根据文本生成音频:
还有的模型则可以根据文字生成图片,比如Dall-E、MidJourney:
不过,我们今天要聊的大语言模型(Large Language Models, 以下简称LLM)是对Transformer的另一种用法:推理预测。
LLM在训练Transformer时会尝试输入一些文本、音频、图片等信息,然后让Transformer推理接下来跟着的应该是什么内容。推理的结果会以概率分布的形式出现:
可能大家会有疑问:
仅仅是推测接下来的内容,怎么能让ChatGPT在对话中生成大段的有关联的文字内容呢?
其实LLM采用的就是笨办法,答案就是:持续生成
根据前文推测出接下来的一个词语后,把这个词语加入前文,再次交给大模型处理,推测下一个字,然后不断重复前面的过程,就可以生成大段的内容了:
这就是为什么我们跟AI聊天的时候,它生成的内容总是一个字一个字的输出的原因了。
以上就是LLM的核心技术,Transformer的原理了~
如果大家想要进一步搞清楚Transformer机制,可以参考以下视频:
90分钟!清华博士带你一口气搞懂人工智能和神经网络

三、大模型应用开发
1. 模型部署
云部署模型:
- 优点:
- 前期投入成本低
- 部署和维护方便
- 网络延迟较低
- 缺点:
- 数据存储在第三方,有隐私和安全问题
- 长期使用成本高
本地部署模型:
- 优点:
- 数据完全自主掌控,安全性高
- 不依赖外部环境
- 虽然短期投入大,但长期来看成本会更低
- 缺点:
- 初期部署成本高
- 维护困难
使用开放大模型API的优缺点如下:
- 优点:
- 没有部署和维护成本,按调用收费
- 缺点:
- 依赖平台方,稳定性差
- 长期使用成本较高
- 数据存储在第三方,有隐私和安全问题

注意:
这里说的本地部署并不是说在你自己电脑上部署,而是公司自己的服务器部署。由于大模型所需要的算力非常多,自己电脑部署的模型往往都是阉割蒸馏版本,性能和推理能力都比较差。
再加上现在各种模型都有很多免费的服务可以访问,性能还是满血版本,推理能力拉满。所以完全不建议大家在自己电脑上部署,除非你想自己做模型微调或测试。
1.1 模型部署-云服务
通常发布大模型的官方、大多数的云平台都会提供开放的、公共的大模型服务。大模型官方前面讲过,我们不再赘述,这里我们看一些国内提供大模型服务的云平台:
| 云平台 | 公司 | 地址 |
|---|---|---|
| 阿里百炼 | 阿里巴巴 | https://bailian.console.aliyun.com |
| 腾讯TI平台 | 腾讯 | https://cloud.tencent.com/product/ti |
| 千帆平台 | 百度 | https://console.bce.baidu.com/qianfan/overview |
| SiliconCloud | 硅基流动 | https://siliconflow.cn/zh-cn/siliconcloud |
| 火山方舟-火山引擎 | 字节跳动 | https://www.volcengine.com/product/ark |
以阿里百炼为例,可以打开模型广场查看
点击密钥管理-创建API Key进行API-KEY的创建
1.2 本地部署
很多云平台都提供了一键部署大模型的功能,这里不再赘述。我们重点讲讲如何手动部署大模型。
手动部署最简单的方式就是使用Ollama,这是一个帮助你部署和运行大模型的工具。官网如下:
Ollama默认安装目录是C盘的用户目录,如果不希望安装在C盘的话(其实C盘如果足够大放C盘也没事),就不能直接双击安装了。需要通过命令行安装。
命令行安装方式如下:
在OllamaSetup.exe所在目录打开cmd命令行,然后命令如下:
OllamaSetup.exe /DIR=你要安装的目录位置

OK,安装完成后,还需要配置一个环境变量,更改Ollama下载和部署模型的位置。环境变量如下:
OLLAMA_MODELS=你想要保存模型的目录
环境变量配置方式相信学过Java的都知道,这里不再赘述,配置完成如图:
配置完第一次使用可以输入以下命令
ollama --help

拉取镜像,可以访问ollama-models
以deepseek为例,7b指令如下
ollama run deepseek-r1:7b

但是这样直接拉取的话速度很慢,最好添加一下系统变量
切换到「高级」→ 点击「环境变量」
在「用户变量」或「系统变量」中,新建: 变量名:OLLAMA_MODEL_SERVER
变量值:https://mirrors.aliyun.com/ollama 确定保存
重启 PowerShell 后再执行 ollama pull deepseek-r1:7b
ollama因为是中断下载,速度比较慢
保存以下脚本为.ps1文件并运行(需替换模型名如deepseek-r1 :7b),这个脚本会打开ollama界面看到进度,是很不错的脚本。
while ($true) {
$modelExists = ollama list 2>&1 | Select-String "deepseek-r1:7b"
if ($modelExists) {
Write-Host "deepseek-r1:7b 下载完成!" -ForegroundColor Green
break
}
try {
# 关键修改:去掉 -NoNewWindow,让Ollama单独开窗口显示进度
$process = Start-Process -FilePath "ollama" -ArgumentList "run", "deepseek-r1:7b" -PassThru -ErrorAction Stop
Start-Sleep -Seconds 60
if (-not $process.HasExited) {
Stop-Process -Id $process.Id -Force -ErrorAction SilentlyContinue
Write-Host "下载进程已中断,准备重启..." -ForegroundColor Yellow
}
}
catch {
Write-Host "启动进程出错:$($_.Exception.Message)" -ForegroundColor Red
Start-Sleep -Seconds 10
}
}
Read-Host "按回车退出"
下载完成后使用指令,就可以开始对话了
ollama run deepseek-r1:7b

使用指令,可以查看模型内存使用情况
ollama ps

停止模型
ollama stop
查看模型列表
ollama list
总结指令如下:
启动模型 ollama run deepseek-r1:7b
查看模型内存使用情况 ollama ps
停止模型: ollama stop
查看模型列表 ollama list
2. 调用大模型
目前大多数大模型都遵循OpenAI的接口规范,是基于Http协议的接口。因此请求路径、参数、返回值信息都是类似的,可能会有一些小的差别。具体需要查看大模型的官方API文档。
2.1 大模型接口规范
我们以DeepSeek官方给出的文档为例:
2.1.1 接口说明
- 请求方式:通常是POST,因为要传递JSON风格的参数
- 请求路径:与平台有关
- DeepSeek官方平台:https://api.deepseek.com
- 阿里云百炼平台:https://dashscope.aliyuncs.com/compatible-mode/v1
- 本地ollama部署的模型:http://localhost:11434
- 安全校验:开放平台都需要提供API_KEY来校验权限,本地ollama则不需要
- 请求参数:参数很多,比较常见的有:
- model:要访问的模型名称
- messages:发送给大模型的消息,是一个数组
- stream:true,代表响应结果流式返回;false,代表响应结果一次性返回,但需要等待
- temperature:取值范围[0:2),代表大模型生成结果的随机性,越小随机性越低。DeepSeek-R1不支持
注意,这里请求参数中的messages是一个消息数组,而且其中的消息要包含两个属性:
- role:消息对应的角色
- content:消息内容
2.1.2 提示词角色
通常消息的角色有三种:
| 角色 | 描述 | 示例 |
|---|---|---|
| system | 优先于user指令之前的指令,也就是给大模型设定角色和任务背景的系统指令 | 你是一个乐于助人的编程助手,你以小团团的风格来回答用户的问题。 |
| user | 终端用户输入的指令(类似于你在ChatGPT聊天框输入的内容) | 写一首关于Java编程的诗 |
| assistant | 由大模型生成的消息,可能是上一轮对话生成的结果 | 注意,用户可能与模型产生多轮对话,每轮对话模型都会生成不同结果。 |
其中System类型的消息非常重要!影响了后续AI会话的行为模式。
比如,我们会发现,当我们询问这些AI对话产品“你是谁”这个问题的时候,每一个AI的回答都不一样,这是怎么回事呢?
这其实是因为AI对话产品并不是直接把用户的提问发送给LLM,通常都会在user提问的前面通过System消息给模型设定好背景:
2.1.3 会话记忆问题
这里还有一个问题:
我们为什么要把历史消息都放入Messages中,形成一个数组呢?
这是因为大模型是没有记忆的,因此我们调用API接口与大模型对话时,每一次对话信息都不会保留,多次对话之间都是独立的,没有关联的。
但是大家可能发现了,我们使用的AI对话产品却能够记住每一轮对话信息,根据这些信息进一步回答,这是怎么回事呢?
答案就是Messages数组。
我们只需要每一次发送请求时,都把历史对话中每一轮的User消息、Assistant消息都封装到Messages数组中,一起发送给大模型,这样大模型就会根据这些历史对话信息进一步回答,就像是拥有了记忆一样。
2.2 调用大模型
部分平台提供了图形化的试验台,可以方便测试模型接口。比如阿里云百炼平台:
当然,我们也可以用普通的http客户端来发起请求大模型,我们以Ollama为例:
Ollama在本地部署时,会自动提供模型对应的Http接口,访问地址是:http://localhost:11434/api/chat
使用如下body来调用http://localhost:11434/api/chat
{
"model": "deepseek-r1:7b",
"messages": [
{
"role": "user",
"content": "你是谁?"
}
],
"stream": false
}
响应结果
那如果我们指定大模型一个身份呢
代码如下:
{
"model": "deepseek-r1:7b",
"messages": [
{
"role": "system",
"content": "你是一个热心的语音助手,你的名字叫小王,请以小王的身份回答用户的问题"
},
{
"role": "user",
"content": "你是谁?"
}
],
"stream": false
}
响应结果如下
3. 大模型应用
大模型应用是基于大模型的推理、分析、生成能力,结合传统编程能力,开发出的各种应用。
为什么要把传统应用与大模型结合呢?
别着急,我们先来看看传统应用、大模型各自擅长什么,不擅长什么
3.1 传统应用与AI大模型

3.2.强强联合
传统应用开发和大模型有着各自擅长的领域:
- 传统编程:确定性、规则化、高性能,适合数学计算、流程控制等场景。
- AI大模型:概率性、非结构化、泛化性,适合语言、图像、创造性任务。
两者之间恰好是互补的关系,两者结合则能解决以前难以实现的一些问题:
3.3.大模型与大模型应用
下面我把常见的一些大模型对话产品及其模型的关系给大家罗列一下:
| 大模型 | 对话产品 | 公司 | 地址 |
|---|---|---|---|
| GPT-3.5、GPT-4o | ChatGPT | OpenAI | https://chatgpt.com/ |
| Claude 3.5 | Claude AI | Anthropic | https://claude.ai/chats |
| DeepSeek-R1 | DeepSeek | 深度求索 | https://www.deepseek.com/ |
| 文心大模型 3.5 | 文心一言 | 百度 | https://yiyan.baidu.com/ |
| 星火 3.5 | 讯飞星火 | 科大讯飞 | https://xinghuo.xfyun.cn/desk |
| Qwen-Max | 通义千问 | 阿里巴巴 | https://tongyi.aliyun.com/qianwen/ |
| Moonshoot | Kimi | 月之暗面 | https://kimi.moonshot.cn/ |
| Yi-Large | 零一万物 | 零一万物 | https://platform.lingyiwanwu.com/ |
当然,除了AI对话应用之外,大模型还可以开发很多其它的AI应用,常见的领域包括:
4. 大模型应用开发技术架构
基于大模型开发应用有多种方式,接下来我们就来了解下常见的大模型开发技术架构。
4.1 技术架构
目前,大模型应用开发的技术架构主要有四种:
4.1.1 纯Prompt模式
不同的提示词能够让大模型给出差异巨大的答案。
不断雕琢提示词,使大模型能给出最理想的答案,这个过程就叫做提示词工程(Prompt Engineering)。
很多简单的AI应用,仅仅靠一段足够好的提示词就能实现了,这就是纯Prompt模式。
4.1.2 FunctionCalling
大模型虽然可以理解自然语言,更清晰弄懂用户意图,但是却无法直接操作数据库、执行严格的业务规则。这个时候我们就可以整合传统应用于大模型的能力了。
简单来说,可以分为以下步骤:
- 我们可以把传统应用中的部分功能封装成一个个函数(Function)。
- 然后在提示词中描述用户的需求,并且描述清楚每个函数的作用,要求AI理解用户意图,判断什么时候需要调用哪个函数,并且将任务拆解为多个步骤(Agent)。
- 当AI执行到某一步,需要调用某个函数时,会返回要调用的函数名称、函数需要的参数信息。
- 传统应用接收到这些数据以后,就可以调用本地函数。再把函数执行结果封装为提示词,再次发送给AI。
- 以此类推,逐步执行,直到达成最终结果。

注意: 并不是所有大模型都支持Function Calling,比如DeepSeek-R1模型就不支持。
4.1.3 RAG
RAG(Retrieval-Augmented Generation)叫做检索增强生成。简单来说就是把信息检索技术和大模型结合的方案。
大模型从知识角度存在很多限制:
- 时效性差:大模型训练比较耗时,其训练数据都是旧数据,无法实时更新
- 缺少专业领域知识:大模型训练数据都是采集的通用数据,缺少专业数据
可能有同学会说, 简单啊,我把最新的数据或者专业文档都拼接到提示词,一起发给大模型,不就可以了。
同学,你想的太简单了,现在的大模型都是基于Transformer神经网络,Transformer的强项就是所谓的注意力机制。它可以根据上下文来分析文本含义,所以理解人类意图更加准确。
但是,这里上下文的大小是有限制的,GPT3刚刚出来的时候,仅支持2000个token的上下文。现在领先一点的模型支持的上下文数量也不超过 200K token,所以海量知识库数据是无法直接写入提示词的。
怎么办呢?
RAG技术正是来解决这一问题的。
RAG就是利用信息检索技术来拓展大模型的知识库,解决大模型的知识限制。整体来说RAG分为两个模块:
- 检索模块(Retrieval):负责存储和检索拓展的知识库
- 文本拆分:将文本按照某种规则拆分为很多片段
- 文本嵌入(Embedding):根据文本片段内容,将文本片段归类存储
- 文本检索:根据用户提问的问题,找出最相关的文本片段
- 生成模块(Generation):
- 组合提示词:将检索到的片段与用户提问组织成提示词,形成更丰富的上下文信息
- 生成结果:调用生成式模型(例如DeepSeek)根据提示词,生成更准确的回答
由于每次都是从向量库中找出与用户问题相关的数据,而不是整个知识库,所以上下文就不会超过大模型的限制,同时又保证了大模型回答问题是基于知识库中的内容,完美!

4.1.4 Fine-tuning
Fine-tuning就是模型微调,就是在预训练大模型(比如DeepSeek、Qwen)的基础上,通过企业自己的数据做进一步的训练,使大模型的回答更符合自己企业的业务需求。这个过程通常需要在模型的参数上进行细微的修改,以达到最佳的性能表现。
在进行微调时,通常会保留模型的大部分结构和参数,只对其中的一小部分进行调整。这样做的好处是可以利用预训练模型已经学习到的知识,同时减少了训练时间和计算资源的消耗。微调的过程包括以下几个关键步骤:
- 选择合适的预训练模型:根据任务的需求,选择一个已经在大量数据上进行过预训练的模型,如Qwen-2.5。
- 准备特定领域的数据集:收集和准备与任务相关的数据集,这些数据将用于微调模型。
- 设置超参数:调整学习率、批次大小、训练轮次等超参数,以确保模型能够有效学习新任务的特征。
- 训练和优化:使用特定任务的数据对模型进行训练,通过前向传播、损失计算、反向传播和权重更新等步骤,不断优化模型的性能。
模型微调虽然更加灵活、强大,但是也存在一些问题:
- 需要大量的计算资源
- 调参复杂性高
- 过拟合风险
总之,Fine-tuning成本较高,难度较大,并不适合大多数企业。而且前面三种技术方案已经能够解决常见问题了。
那么,问题来了,我们该如何选择技术架构呢?
4.2 技术选型
从开发成本由低到高来看,四种方案排序如下:
Prompt < Function Calling < RAG < Fine-tuning
所以我们在选择技术时通常也应该遵循"在达成目标效果的前提下,尽量降低开发成本"这一首要原则。然后可以参考以下流程来思考:
更多推荐


所有评论(0)