深入解析Spring AI框架:在Java應用中實現智能化交互的關鍵
今天我們的Spring AI源碼分析主題即將結束。我已經對自己感興趣的基本內容進行了全面的審視,并將這些分析分享給大家。如果你對這個主題感興趣,可以閱讀以下幾篇文章。每篇文章都層層遞進,深入探討相關內容。考慮到長文可能讓大家感到疲憊,我采用了逐步推進的方式,確保每一篇都簡明易懂,便于理解。希望能為你們提供有價值的參考!
Spring AI的基本用法:https://www.cnblogs.com/guoxiaoyu/p/18284842
Spring.3版本自動裝配機制的演變與實踐:https://www.cnblogs.com/guoxiaoyu/p/18384642
SpringBoot.3中的aot.factories到底有什么用:https://www.cnblogs.com/guoxiaoyu/p/18434660
Spring AI的阻塞式請求與響應機制的核心邏輯:https://www.cnblogs.com/guoxiaoyu/p/18440488
Spring AI的流式回答源碼分析:https://www.cnblogs.com/guoxiaoyu/p/18440684
今天我們的主題將聚焦于最后一步:如何將AI技術有效應用于Java程序中。眾所周知,Java是一種面向對象的編程語言,因此不論我們調用什么AI接口,從業務的角度來看,它本質上只是一個接口,而AI則充當了一個第三方對接平臺。然而,值得注意的是,AI的聊天回復往往不適用于對象,因為這些回復無法直接返回格式化的JSON數據。這一問題導致Spring無法將其轉化為實體類,從而無法真正融入業務流程。
今天,我們將探討Spring AI框架是如何有效解決這一挑戰的。通過深入分析框架的設計和實現,我們希望為大家展示如何將AI能力順利整合到Java應用中,推動業務的進一步發展。
除此之外,function call 函數回調也是AI技術的一個重要特性。那么,Spring AI是如何應對這一挑戰的呢?今天,我們將深入探討這個問題,解析Spring AI框架如何有效處理函數回調,從而增強AI與Java程序之間的交互能力。
實體化類
實體類在Java程序中扮演著不可或缺的角色,無論是進行內部操作,還是將數據返回給前端的RESTful接口,實體類都是業務中信息傳遞的核心。在Spring AI框架中,我們可以有效地控制AI的回答,以確保其能夠正確映射到實體類。接下來,我們將探討Spring AI是如何實現這一功能的,基本用法如下:
@GetMapping("/ai-Entity")
ActorFilms generationByEntity() {
ActorFilms actorFilms = chatClient.prompt()
.user("Generate the filmography for a random actor.")
.call()
.entity(ActorFilms.class);
return actorFilms;
}
源碼分析
在這里,我們不再直接調用 content 方法,而是選擇使用 entity 方法作為返回類型。這一變化意味著我們需要重點關注 entity 的實現及其在整個流程中的作用。接下來,讓我們通過代碼示例來深入分析這一關鍵部分:
public <T> T entity(Class<T> type) {
Assert.notNull(type, "the class must be non-null");
var boc = new BeanOutputConverter<T>(type);
return doSingleWithBeanOutputConverter(boc);
}
這里使用了一個名為 BeanOutputConverter 的轉換器。接下來,我們來詳細查看一下 doSingleWithBeanOutputConverter 方法的具體實現。
private <T> T doSingleWithBeanOutputConverter(StructuredOutputConverter<T> boc) {
var chatResponse = doGetObservableChatResponse(this.request, boc.getFormat());
var stringResponse = chatResponse.getResult().getOutput().getContent();
return boc.convert(stringResponse);
}
在這里,我們要討論的 doGetObservableChatResponse 方法主要負責與第三方 API 的交互過程。由于我們在之前的講解中已經對聊天調用API方法的實現進行了詳細分析,因此這次我們就不再深入探討其具體內容,而是集中于方法的核心功能和應用場景。
實體類提示詞限制
在這里,我們來查看一下 boc.getFormat() 方法。這個方法返回一段提示詞,而這些提示詞會根據不同的類型而有所區別。為了更好地理解,我們可以具體分析一下單個 Bean 實體類所對應的提示詞格式。
image
具體如下:
public String getFormat() {
String template = """
Your response should be in JSON format.
Do not include any explanations, only provide a RFC8259 compliant JSON response following this format without deviation.
Do not include markdown code blocks in your response.
Remove the ```json markdown from the output.
Here is the JSON Schema instance your output must adhere to:
```%s```
""";
return String.format(template, this.jsonSchema);
}
這其實非常簡單。通過使用提示詞來明確限制 AI 返回的格式,可以最大程度地確保其輸出符合我們的要求。這種方式使得 Spring 能夠有效地進行解析,而 jsonSchema 則僅僅是我們傳遞的實體類的各種信息。
封裝實體類
boc.convert 方法負責將數據封裝成實體類的過程。具體來說,它會接收原始數據,并通過內部邏輯進行轉換,以生成符合我們定義的實體類結構。
image
從表面上看,我們可以清晰地看出該過程涉及到 JSON 序列化,它將數據封裝成我們所期望的對象格式。然而,需要注意的是,雖然 AI 的提示詞旨在盡量限制其回復內容,以使其盡可能符合我們的要求,但由于各種因素的影響,我們無法保證其返回的格式會完全按照預設進行。
因此,為了確保程序的穩健性和可靠性,在此過程中引入了異常捕獲機制。這一機制能夠有效地處理潛在的格式不一致或錯誤,從而確保應用在面對不符合預期的數據時,能夠平穩運行而不至于崩潰。
函數回調
AI目前能夠發揮一定作用,主要得益于模型的函數調用功能。如果僅僅依靠訓練模型進行聊天回答,其實際價值是相對有限的,因為這種方式的成本非常高,很多企業難以承受。然而,隨著函數回調功能的引入,AI可以實時訪問和利用各種數據,包括實時數據和業務數據,使其能夠根據提供的信息進行更為精準和有效的回答,從而具備了實質性的業務能力。
接下來,我們來看看Spring AI是如何實現這一點的。
基本用法
了解了之前的 Spring AI 用法文章后,你大概已經掌握了如何創建一個 Function 函數。接下來,我們將直接深入探討如何將這個函數添加到我們的項目中。
@PostMapping("/ai-function")
ChatDataPO functionGenerationByText(@RequestParam("userInput") String userInput) {
String content = this.myChatClientWithSystem.prompt()
.user(userInput)
.functions("CurrentWeather")
.call()
.content();
log.info("content: {}", content);
ChatDataPO chatDataPO = ChatDataPO.builder().code("text").data(ChildData.builder().text(content).build()).build();;
return chatDataPO;
}
在我們的項目中,functions 函數允許添加多種功能,不僅僅局限于單一工具的調用。例如,在可視化智能體的應用中,如千帆 AppBuilder,我們可以觀察到思考輪數的運用,這其中涉及了多個工具的調用。這種方式為我們的智能體提供了更豐富的功能和靈活性。
接下來,我們將進行一次函數的調用,以實際展示其效果。
image
在這里,我們使用了一個固定的 30 度作為示例值,但你可以在函數方法內部通過接口調用其他第三方服務來獲取實時數據。因此,通過集成外部數據源,你可以實現更為智能和適應性強的功能。
源碼分析
還記得我們之前討論過的內容嗎?在回答的最后,我們會進行一次判斷,以確定當前的輸出是否為函數調用。這一過程是確保系統能夠準確識別和執行函數的重要環節。接下來,我們將展示相關的源碼,以便更深入地理解這一機制的具體實現:
if (isToolCall(chatResponse,
Set.of(ChatCompletionFinishReason.TOOL_CALLS.name(), ChatCompletionFinishReason.STOP.name()))) {
var toolCallConversation = handleToolCalls(prompt, chatResponse);
// Recursively call the call method with the tool call message
// conversation that contains the call responses.
return this.call(new Prompt(toolCallConversation, prompt.getOptions()));
}
我也在這里設置了一個斷點,以便大家可以清楚地看到這一過程。這一斷點幫助我們確認,返回的結果完全是由 AI 生成的。在這個基礎上,我們會進行進一步的判斷,以決定是否需要調用函數工具。
圖片
接下來,我們將進入函數調用的過程。這一步驟至關重要,因為函數的返回值將被再次提供給 AI,作為后續回答的參考。我們來看看具體是如何進行函數調用的。雖然我已經找到了相關的源碼,但為了讓大家更容易理解這個過程,我將提供一張可視化的圖片。這張圖片將清晰地展示函數調用的流程,以及返回值是如何被整合進 AI 的回答中的。
圖片
發送這些參數的原因在于,在發起請求時已經設置了相關限制。以下是我截取下來的請求參數:
tools=[FunctionTool[type=FUNCTION, functinotallow=Function[descriptinotallow=獲取指定地點的天氣情況, name=CurrentWeather, parameters={$schema=https://json-schema.org/draft/2020-12/schema, type=object, properties={locatinotallow={type=string}, unit={type=string, enum=[C, F]}}}]]]
目前幾乎所有第三方AI接口都提供了一個名為 tools 的參數,用于傳遞我們需要的參數。以OpenAI為例:
圖片
調用函數接口
由于我們的函數實現了 @FunctionalInterface 接口,因此 call 這一行實際上會調用我們定義的 apply 接口。鑒于我們的參數是一個實體記錄,系統會對其進行 JSON 轉化和封裝,隨后再進行調用。具體過程如下所示:
public String call(String functionArguments) {
// Convert the tool calls JSON arguments into a Java function request object.
I request = fromJson(functionArguments, inputType);
// extend conversation with function response.
return this.andThen(this.responseConverter).apply(request);
}
因此,即使所有操作都已結束,如果在下次 AI 判斷中仍然需要調用工具,系統將繼續進行循環,直到所有問題都得到完整的回答為止。這種設計確保了整個過程的連貫性和完整性。
總結
在這次探討中,我們深入挖掘了Spring AI框架如何與Java程序完美結合,提升業務能力。隨著AI技術的不斷發展,其在Java應用中的整合成為了提升開發效率和用戶體驗的關鍵。我們不僅分析了實體類的映射與控制,還探討了函數回調的強大功能,展示了如何通過Spring AI有效處理這些復雜交互。
希望這些分析能夠激發你對AI應用的靈感,并促使你在自己的項目中大膽嘗試,將AI技術融入到業務流程中。期待未來能看到大家的創意實現和應用!