給Javaer看的大模型開發指南
一、概述
二、什么是大模型
三、大模型的特點
1. 無狀態
2. 結構化輸出
3. 函數調用
四、大模型接口
1. 模型封裝
2. 接口輸入
3. 接口輸出
五、RAG架構
六、MCP協議
七、Spring-AI
1. 模型抽象
2. 聊天會話
3. RAG拓展
4. 代碼示例
八、智能體示例
1. 接口骨架
2. 構造外部函數定義
3. 系統提示詞
4. 發起調用
九、總結
一、概述
伴隨著大模型的性能提升、成本下降，在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文檔：
- OpenAI-會話補全https://openai.apifox.cn/api-67883981
- DeepSeek-會話補全https://api-docs.deepseek.com/zh-cn/api/create-chat-completion
- 硅基流動-會話補全https://docs.siliconflow.cn/cn/api-reference/chat-completions/chat-completions
- Ollama-會話補全https://www.runoob.com/ollama/ollama-api.html
硅基流動和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" //無關緊要
}看到這里時，你是不是已經開始躍躍欲試了？是不是感覺打造一個垂直領域的智能體沒有想象中那么困難了~
五、RAG架構
除非是圍繞特定業務場景結合私域數據訓練的專用大模型，否則涉及到一些企業內部的私域信息時，通用大模型也只能不懂裝懂的現編。
例如：當你詢問大模型【DJob如何接入與使用】，除非訓練大模型時輸入了相關資料，不然大模型只能現編了。
考慮到專用大模型的成本，工程上解決這個問題的方法一般是通過外掛知識庫來實現：
- 結合具體業務場景，將相關的文檔與資料提前錄入到【知識庫】中。
- 用戶提交一個【輸入】后，先使用 用戶【輸入】作為搜索條件，去【知識庫】中搜索得到相關的【資料】。
- 將用戶【輸入】和【資料】一起提供給大模型。
此【知識庫】組件的具體選型屬于實現細節，簡單的可以用MySQL、Elasticsearch，如果想提升【知識庫搜索結果】的匹配度，也可以使用近期討論度很高的【向量數據庫】。
添加了RAG后，流程如下：
圖片
詳情可參考下文：https://www.zhihu.com/tardis/zm/art/675509396?source_id=1003
六、MCP協議
可以看到，將大模型作為一個【函數調用】的規劃引擎，借助它的推理與生成能力，可以實現復雜的業務流程。如果說大模型是【腦】，那提供給大模型規劃、使用的【函數】就是它的【手】和【腳】。有腦有手的大模型，可以迸發出巨大的業務潛力。
那如何打通大模型和傳統軟件系統（如存量微服務）呢？
我們關注的問題，開源社區也在積極的關注，這就是MCP協議誕生的背景和目的。
圖片
MCP協議介紹
https://mcp-docs.cn/introduction
在這里我們不展開MCP協議的細節，僅作個人對MCP協議的思考，重點在于打破MCP協議的神秘感、破除MCP迷信。
- MCP協議本身并非高精尖的內容，簡單來說，就是常用人群約定系統間調用的流程、格式。若不考慮通用，誰都可以設計符合自己需求的、領域特定的交互協議。
- MCP協議的優勢在于，它出現的非常及時，且基本滿足了常規交互需求，因此快速在社區達成了共識。
- 不管是MAP、MBP還是MCP，都沒有那么重要，但是形成共識非常重要。協議達成了共識，開源社區才可以合力圍繞協議進行生態建設。
七、 Spring-AI
到了這一步，我們開始探討Java代碼，首先我們需要熟悉下 spring-ai 的整套代碼架構，一步一步來，以整體到到細節的節奏進行討論。
模型抽象
核心的API實體是 Model ，是一個帶泛型的純函數，提供了對大模型能力的頂層抽象：
圖片
org.springframework.ai.model.Model
大模型的能力本質就是：輸入一個( request )，返回一個輸出。
至于輸入/輸出的具體類型，由細分的子類限定：
不同模態的大模型支持不同類型的輸入/輸出，在此我們只討論 ChatModel 。
org.springframework.ai.chat.model.ChatModel
spring-ai 提供了不同平臺、不同模型的API集成，開發者只需要提供接口地址、調用憑證即可開箱使用~
聊天會話
考慮到大模型對話是熱點場景， spring-ai 針對性的提供了會話接口抽象。
org.springframework.ai.chat.client.ChatClient
RAG拓展
類似Spring-AOP， spring-ai 基于請求橫切提供了開箱即用的RAG能力抽象。
圖片
圖片
org.springframework.ai.rag.advisor.RetrievalAugmentationAdvisor
代碼示例
基于供應商構建ChatModel
圖片
構建ChatClient發起會話
八、智能體示例
到這里，我們已經自上而下的理解了大模型的工程化，現在我們來開發一個【DJob智能助手】吧！
接口骨架
圖片
通過 POST 接口，響應 Content-Type 為 text/event-stream 。
構造外部函數定義
假設有以下幾個函數可以給大模型提供能力：
圖片
將上述3個本地方法封裝成 ChatClient API 認識的【ToolCallback】：
圖片
構建可用的 函數/工具 信息，這里用本地方法來mock。實際使用時可以利用MCP/HTTP/gRPC/Dubbod等實現跨系統調用。
系統提示詞
由于不能讓大模型自由發揮，因此需要在用戶輸入的內容外，給大模型一些定向信息補充或場景限定，幫助大模型更好地解決問題！
圖片
發起調用
圖片
- 考慮到大模型無狀態，所以每次會話時歷史消息也需要一并輸入。
- 歷史消息可以由前端收集、提交，也可以由后端每次會話存儲、收集。
九、總結
綜上所述，太陽底下沒有新鮮事，工程領域所有的新生事物都可以暫時把它當做MySQL，沒有人比Java工程師更懂MySQL了（開玩笑）。
