概述

伴随着大模型的性能提升、成本下降，在Web在线对话场景以外，大模型也越来多的被集成到传统业务场景。

在大模型API交互模式、业务集成模式经百家争鸣后已趋于稳定的背景下，Spring作为Java生态里的OSS巨头也下场为LLM提供生态支持，于近期释出 spring-ai 正式版。

需要说明的是，Spring-AI 所提供的能力并不神秘，业务上也不是必须用Spring-AI不可。但是，就像过去Spring对新的数据库、新的中间件提供生态支持一样，Spring-AI提供了一套和Spring全家桶兼容的、语义一致的、良好设计的、易于拓展的大模型交互的Java API，可以极大的降低LLM集成和开发的成本。

从大模型的工程化、实用化角度来说，当你厘清Spring-AI这一套API设施的逻辑后，事情最后还是会回归到我们业务开发仔最熟悉的CRUD领域。就像使用Mybatis操作mysql一样，我们用spring-ai来操作大模型。

那我们开始吧！

什么是大模型

大模型的舞台上，从来不缺新面孔。自ChatGPT开启AI新纪元后，各类大模型层出不穷。

但是我们不去考虑大模型的训练原理、推理/运算架构、参数调优等那些我们看不懂的数学上的东西，就像我们不会去关心mysql是怎么用代码实现的一样。

我们就类比我们熟悉的知识，对大模型有个盲人摸象式的、自洽的、基础的认识就好了。

从某种意义上来说，模型训练就是通过分析海量文本(如维基百科、图书、网页)寻找到人类语言的规律，再将这个规律固化成一个包含数十亿【参数】的超级【数学公式】。就像简单公式 y = 5x + 8 中的 5 和 8，这两个【参数】决定了输入X如何转化为输出Y。
训练好的【数学公式】就像代码，需要部署在算力平台上，借助【显卡】的并行运算能力来实现高效运算。
用户的输入作为这个【数学公式】的入参，经公式运算后，得到相关的【输出】。

假设大模型是一个上述数学公式，不同的大模型(ChatGPT/DeepSeek)是不同的架构、不同的公式。

那么模型训练就是通过对海量文本的分析、学习，找到合适的参数值。

大模型的特点

接下来我们看下，在工程应用场景下，需要我们开发仔关注的大模型的特点。

就像mysql，我们集成时也需要关注下不同的存储引擎(InnoDB/MyISAM)的特点。

无状态

大模型是没有记忆、没有状态的，它就是一个纯函数。

它不知道它之前跟你说过什么。所以每次给大模型输入的时候，我们需要根据业务场景把之前的【输入】，【反馈】一并给它，避免大模型失忆导致对话不流畅。

结构化输出

大模型是具备结构化输出能力的，当然了有些模型支持的不够好。但是不重要，只是支持的程度不同，但是它们都支持！

所谓的结构化输出是指，大模型除了可以返回口语化、没有模式的的自然语言文本外，它还可以按你需求给你返回其他的文本格式比如：JSON。

你看，这像不像在调一个REST接口？甚至是一个万能接口！毕竟大模型啥都会，不会它也可以给你现编！

函数调用

其实看到这里我们就可以实现一个大模型驱动的RPC调用引擎了！

大模型帮你推理、规划得到了需要执行的函数和对应的函数参数，至于这个【函数名】对应的到底是一个进程内方法、HTTP接口、Dubbo接口还是MCP接口都不重要，只是智能体实现的一个技术细节而已。

我们可以用自然语言表述需求，同时告诉大模型有哪些辅助【工具/函数】可以供他备用。它会推理、编排这些工具来达成需求！

把用户输入和可用函数输入给大模型，大模型推理发现需要调用外部函数，于是返回函数名+函数调用参数。
智能体捕获输出，对指定函数发起调用，再将用户输入和函数结果一起输入到大模型，大模型基于这些上下文推理输出结果。

考虑到大模型发起函数调用的普遍需求，大模型供应商一般都在API层面提供了【function call】能力，用于将文本输出和函数调用输出区分开。

但是原理就是这么个原理，只是API抽象层次的问题！

大模型接口

考虑到大模型对硬件资源的特别需求(如显卡)，所以大模型一般是独立部署，以SaaS模式提供能力。就像mysql对资源有特别的需求(如大内存)，所以一般也是独立部署一样！

训练好的大模型就是一套二进制数据集，SaaS化需要做外围的服务化、产品化封装，同一套模型可以在不同的算力平台部署，提供截然不同的服务化API。

我们可以简单看下当下比较热门的几大供应商提供的API文档：

硅基流动和Ollama都属于大模型算力/治理平台。他们不研发大模型，他们只是大模型的搬运工。

你把大模型理解成微服务集群，把硅基流动和Ollama理解成微服务发布平台就欧了。

大概扫一眼，你会发现核心API都差不多，毕竟有OpenAI珠玉在前，好多系统都已经对接了OpenAI的API了。后发的大模型为了兼容，降低接入难度，基本上都和OpenAI的API大差不差。

就像是mysql，尽管数据库产品类型枝繁叶茂，但是大家都兼容SQL语法。

我们这里只讨论【会话补全】这一个点，我们发现会话补全接口的输入/输出大概都是酱紫：

输入

{
  "stream": false, // 是否是流式输出(要不要SSE)
  "model": "deepseek-chat", //选用的哪个模型
  "messages": [ // 历史对话消息，因为大模型无状态，所以按场景提供一定数量的历史消息
    {
      "content": "You are a helpful assistant",
      "role": "system"
    },
    {
      "content": "Hi", //消息内容
      "role": "user" //消息类型
    }
  ],
  "tools": null, //外部函数列表，【函数调用】能力在 API 层面的支持
  "frequency_penalty": 0,  //无关紧要的模型行为控制参数
  "presence_penalty": 0, //无关紧要的模型行为控制参数
  "temperature": 1, //无关紧要的模型行为控制参数
  "top_p": 1, //无关紧要的模型行为控制参数
  "logprobs": false, //无关紧要的模型行为控制参数
  "top_logprobs": null //无关紧要的模型行为控制参数
}

所有我们不理解的参数都无关紧要！

输出

{
  "id": "<string>", //无关紧要
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "<string>", // 大模型生成的内容
        "reasoning_content": "<string>",
        "tool_calls": [  //需要发起的【函数调用】
          {
            "id": "<string>",
            "type": "function",
            "function": {
              "name": "<string>",
              "arguments": "<string>"
            }
          }
        ]
      },
      "finish_reason": "stop" //有点重要，但是我们先不管
    }
  ],
  "usage": {  //token使用量 计数、计费
    "prompt_tokens": 123,
    "completion_tokens": 123,
    "total_tokens": 123
  },
  "created": 123,  //无关紧要
  "model": "<string>",  //无关紧要
  "object": "chat.completion"  //无关紧要
}

看到这里是不是已经开始跃跃欲试了？是不是感觉搞个垂直领域的智能体有手就行了？