北京時間 2025 年 5 月 20 日，Spring AI 官方團隊宣布 1.0 GA 版本正式發(fā)布，并采用了全新的 Logo。

Spring AI 1.0 GA 功能集剖析

第一、Prompt 提示詞

創(chuàng)建正確的 Prompt（即傳遞給大模型的內(nèi)容）是一項重要技能。掌握幾種模式可以充分利用 AI 大模型的推理能力，從而獲得最佳結果。

第二、模型增強（The Augmented LLM）

不過，在現(xiàn)實世界的 AI 應用中，對于大模型的需求已經(jīng)不僅限于與無狀態(tài)的 AI 大模型 API 進行簡單的請求和響應交互。

為了開發(fā)出高效的 AI 應用程序，一系列輔助功能是必不可少的。模型增強的概念（如下圖所示）正是為了滿足這一需求，它為基本大模型增加了數(shù)據(jù)檢索（Retrieval Augmented Generation，簡稱 RAG）、對話記憶（Memory）和工具調(diào)用（Tool）等功能。這些功能使得用戶能夠?qū)⒆陨淼臄?shù)據(jù)和外部 API 直接集成到大模型的推理過程中。

第三、顧問（Advisors）

Spring AI ChatClient 的核心功能之一是 Advisor API。該 API 采用了攔截器鏈的設計模式，這使得用戶能夠通過添加檢索上下文（Retrieval Context）和對話記憶（Chat Memory）來調(diào)整輸入的提示（Prompt）。

第四、檢索（Retrieval）

在 AI 應用中，檢索數(shù)據(jù)的基礎通常是一個數(shù)據(jù)庫，而向量數(shù)據(jù)庫因其特性而成為首選。Spring AI 提供了一個通用的向量存儲接口，能夠兼容包括 Azure Cosmos DB 和 Weaviate 在內(nèi)的多達20種不同類型的向量數(shù)據(jù)庫。

使用這些數(shù)據(jù)庫時常見的一個問題是，每種數(shù)據(jù)庫都有其獨特的元數(shù)據(jù)過濾查詢語言。為了解決這個問題，Spring AI 引入了一種通用的過濾器表達式語言，該語言采用了類似 SQL 的語法，使得用戶能夠更加方便地進行查詢。如果用戶需要更復雜的查詢，也可以選擇使用數(shù)據(jù)庫的原生查詢語言。

Spring AI 還包含了一個輕量級且可配置的 ETL（提取、轉換、加載）框架，它簡化了將數(shù)據(jù)導入向量存儲的過程。這個框架通過支持多種輸入源的 DocumentReader 插件，包括本地文件系統(tǒng)、網(wǎng)頁、GitHub 倉庫、AWS S3、Azure Blob 存儲、Google Cloud Storage、Kafka、MongoDB 以及兼容 JDBC 的數(shù)據(jù)庫，使得用戶能夠輕松地將內(nèi)容從幾乎任何地方導入到 RAG （檢索增強生成）流程中。此外，它還內(nèi)置了對數(shù)據(jù)分塊、元數(shù)據(jù)豐富化和嵌入生成的支持。

Spring AI 支持 RAG 模式，這使得 AI 大模型能夠基于傳入的數(shù)據(jù)生成響應。用戶可以通過簡單的 QuestionAnswerAdvisor 方法將相關上下文注入到提示詞中，或者使用更復雜、更模塊化的 RetrievalAugmentationAdvisor 來擴展 RAG 管道，以滿足 AI 應用的具體需求。

第五、記憶（ChatMemory）

對話歷史是構建 AI 聊天應用的一個關鍵要素。Spring AI 利用 ChatMemory 接口來實現(xiàn)這一點，該接口負責管理消息的保存和提取。MessageWindowChatMemory 的實現(xiàn)方式是在滑動窗口中保存最近 N 條消息，并能夠隨著對話的進行自動更新。它依賴于一個 ChatMemoryRepository，目前我們提供了針對 JDBC、Cassandra 和 Neo4j 的存儲庫實現(xiàn)，并且還在開發(fā)更多的版本。

另一種方案是采用 

VectorStoreChatMemoryAdvisor

這種方法不僅記住了最新的對話內(nèi)容，還能通過向量搜索技術從歷史對話中找出語義上最接近的消息。

第六、工具（Tool）

Spring AI 可以輕松通過工具擴展模型的功能--自定義函數(shù)，讓 AI 檢索外部信息或執(zhí)行實際操作。工具調(diào)用（也稱為函數(shù)調(diào)用）由 OpenAI 于 2023 年 6 月首次廣泛引入，并在和模型中發(fā)布了函數(shù)調(diào)用功能??。??

?

??

工具可以獲取當前天氣、查詢數(shù)據(jù)庫或返回最新新聞，幫助大模型解答訓練數(shù)據(jù)以外的問題。它們還可以觸發(fā)工作流、發(fā)送電子郵件或更新系統(tǒng)，從而將模型轉變?yōu)閼贸绦蛑械幕钴S參與者。定義工具很簡單：使用 ??@Tool???注解來聲明方法，使用動態(tài)注冊 Bean ??@Bean??，或以編程方式創(chuàng)建它們以實現(xiàn)完全控制。

第七、評估（Evaluation）

開發(fā) AI 應用是一件令人興奮的事情，但是如何評估其效能呢？不幸的是，這并不像編寫常規(guī)的單元測試或集成測試然后查看測試結果那樣直接。我們需要依據(jù)一系列準則來評價 AI 模型的輸出。比如：答案是否與問題相關？它是否產(chǎn)生了不真實的信息？回答是否基于提供的事實？

為了應對這一挑戰(zhàn)，我們應該首先進行所謂的“直覺檢查”。顧名思義，這涉及到手動檢查答案，并運用個人的判斷力來確定答案的正確性。當然，這個過程相當耗時，因此有一系列不斷發(fā)展的技術來幫助自動化這一過程。

Spring AI 能夠輕松地檢驗 AI 生成內(nèi)容的準確性和相關性。它提供了一個靈活的評估器（Evaluator）接口和兩個實用的內(nèi)置評估器：

• 相關性評估器（RelevancyEvaluator）- 幫助您判斷 AI 的響應是否真正與用戶的問題和檢索到的上下文相匹配。它非常適合測試 RAG 流程，并使用可定制的提示詞來詢問另一個模型：“根據(jù)檢索到的內(nèi)容，這個響應是否合理？”
• 事實核查評估器（FactCheckingEvaluator）- 根據(jù)提供的上下文驗證 AI 的響應是否符合事實。它的工作方式是要求模型判斷某個陳述是否在邏輯上得到了文檔的支持。您可以使用如 Bespoke 的 Minicheck（通過 Ollama）等小型模型來運行此評估器，這比每次都使用 GPT-4 這樣的工具成本要低得多。

然而，這并不是萬能的解決方案。Hugging Face “LLM as judges”排行榜的主要維護者 Clémentine Fourrier 警告說，“LLM 作為評委”并非萬能藥。在 Latent Space Podcast 的采訪中，她概述了幾個關鍵問題：

• 模式崩潰和位置偏差：法學碩士評委通常更傾向于來自同一系列模型的答案或顯示的第一個答案。
• 冗長偏見：無論準確性如何，模型對較長的答案評價更高。
• 評分不穩(wěn)定：排名比評分更可靠；即便如此，可重復性也很弱。
• 過度自信偏見：人們和模型通常更喜歡自信的答案，即使這些答案可能是錯誤的。

第八、可觀測性（Observability）

在 AI 應用系統(tǒng)的生產(chǎn)環(huán)境中，為了確保其性能和效果，可觀測性是必不可少的。Spring AI 提供了一種簡便的方式來監(jiān)控模型的運行狀況、性能指標以及成本消耗。

Spring AI 通過與 Micrometer 的集成，能夠提供關鍵性能指標的詳盡遙測數(shù)據(jù)，包括：

• 模型響應時間：即模型處理請求并給出響應所需的時間。
• Token 消耗：每個請求的輸入和輸出 Token 數(shù)量，這有助于您追蹤并優(yōu)化成本支出。
• 工具調(diào)用和數(shù)據(jù)檢索：這可以幫助您了解模型在何時發(fā)揮了實際作用，而不是僅僅在向量數(shù)據(jù)庫中進行無效查詢。

此外，您還可以利用 Micrometer Tracing 獲得全面的追蹤支持，它包含了模型交互過程中每個關鍵步驟的詳細信息。您還可以獲取有助于診斷問題的日志信息，這些日志可以展示用戶輸入的提示或向量數(shù)據(jù)庫的響應內(nèi)容。

第九、模型上下文協(xié)議 MCP

模型上下文協(xié)議(MCP) 于 2024 年 11 月問世。它迅速走紅，因為它為 AI 模型與外部工具、提示詞和資源交互提供了一種標準化的方式。MCP 是一種面向客戶端-服務器的協(xié)議，一旦構建了 MCP 服務器，就可以輕松地將其應用于您的應用程序，無論 MCP 服務器是用什么編程語言編寫的，MCP 客戶端是用什么編程語言編寫的。

這在工具領域確實取得了長足的進步，盡管 MCP 并不局限于工具?，F(xiàn)在，您可以使用“開箱即用”的 MCP 服務器來實現(xiàn)特定功能，比如：與 GitHub 交互，而無需自己編寫代碼。從 AI 工具的角度來看，它就像一個工具類庫，您可以輕松將其添加到您的應用程序中。

Spring AI 團隊在 MCP 規(guī)范發(fā)布后不久就開始支持該規(guī)范，并將這些代碼捐贈給 Anthropic作為 MCP Java SDK的基礎。Spring AI 圍繞此基礎提供了豐富的功能。

第十、智能體（Agent）

2025年被譽為智能體的元年，而一個價值連城的問題是“智能體究竟是什么”。讓我來解答這個問題：智能體的本質(zhì)在于“利用 AI 模型與外界環(huán)境互動，以完成用戶指定的任務”。高效的智能體結合了規(guī)劃、記憶和執(zhí)行能力來達成用戶設定的目標。

智能體主要分為兩大類型：

1. 工作流型智能體：這種方法更加有序，其中大型語言模型（LLM）和工具按照預設的流程進行組合。這些工作流是規(guī)范性的，引導AI按照既定的步驟操作，以實現(xiàn)可預測的結果。
2. 自主決策型智能體：這類智能體允許 LLM 自主規(guī)劃和執(zhí)行任務，無需明確的指令即可自行確定執(zhí)行路徑，選擇使用哪些工具以及它們的使用順序。

盡管完全自主的智能體因其靈活性而極具吸引力，但對于有明確定義的任務，工作流提供了更好的可預測性和一致性。選擇哪種方法取決于您的具體需求和風險偏好。

工作流（Workflow）Spring AI 支持多種構建代理行為的工作流模式，如下所示：

• 評估器-優(yōu)化器：該模型分析自身的反應，并通過結構化的自我評估過程進行改進。
• 路由：此模式能夠根據(jù)用戶請求和上下文的分類將輸入智能地路由到專門的處理器。
• 協(xié)調(diào)者-執(zhí)行者：這種模式是一種靈活的方法，用于處理需要動態(tài)任務分解和專門處理的復雜任務。
• 鏈式：該模式將復雜任務分解為一系列步驟，每個 LLM 調(diào)用都會處理前一個調(diào)用的輸出。
• 并行化：該模式對于需要并行執(zhí)行LLM調(diào)用并自動進行輸出聚合的情況非常有用。

這些模式可以通過 Spring AI 的聊天模型和工具執(zhí)行功能來實現(xiàn)，框架可以處理大部分底層復雜性。

自主決策型智能體（Autonomous Agent）Spring AI 還支持通過模型上下文協(xié)議（MCP）開發(fā)自主代理。正在孵化的 Spring MCP Agent 項目展示了如何創(chuàng)建以下智能體：

• 接受用戶指令并自主確定最佳執(zhí)行方法。
• 通過 MCP 動態(tài)發(fā)現(xiàn)并利用可用工具。
• 維護執(zhí)行記憶以跟蹤進度和決策。
• 根據(jù)結果遞歸地完善策略。

Spring AI 是一款非常優(yōu)秀的 AI 應用開發(fā)框架，它專為 Java 開發(fā)者而設計，幫助 Java 開發(fā)者快速構建具備智能化的應用，很高興看到 Spring AI 在今天達成正式 GA 版本！！

本文轉載自??玄姐聊AGI??  作者：玄姐