為何選擇 Spring AI：Spring 開發者通往生成式 AI 世界的無縫之路

引言

作為一名探索生成式 AI 世界的 Java 開發者，您可能已經瞭解了一些承諾使 AI 整合變得容易的框架。我相信 Spring AI 是一個自然的絕佳選擇，特別是對於已經在 Spring 生態系統內工作的開發者。Spring AI 基於與 Spring Boot 和 Spring Data 相同的構建基礎，使得為您的應用新增 AI 能力變得無縫且直觀，而無需您學習一套全新的範例。

與 Spring 生態系統的無縫整合

Spring AI 最顯著的優勢之一是它與 Spring 生態系統的深度整合。如果您已經熟悉開發 Spring Boot 應用，那麼 Spring AI 會讓您感覺它只是現有知識的延伸。驅動 Spring Data 的相同概念——例如依賴注入、註解和清晰的抽象——同樣適用於 Spring AI。這種一致性意味著您可以輕鬆進入 AI 領域，而無需重新思考如何開發應用。

與某些工具不同，Spring AI 入門無需複雜的配置或工作流設定。它能與您現有的程式碼庫完美契合，允許您重用現有的 bean、服務和倉庫。Spring AI 不是將外部 AI 平臺附加進來，而是直接與您已構建的業務邏輯和企業服務整合，充分利用您在 Spring 生態系統中的投資。

簡化企業應用的 AI

Spring AI 專注於簡化企業級應用的 AI 操作。它非常適合需要向業務應用中新增簡單 AI 功能（如文字生成、嵌入和函式呼叫）的開發者。Spring AI 的魅力在於其簡潔性：您可以在不增加管理複雜工作流或編排多步驟流程開銷的情況下獲得生成式 AI 的強大能力。對於大多數企業用例而言，AI 的作用是增強現有功能而非驅動整個工作流，Spring AI 正好提供了所需的一切。

向量儲存整合：擴充套件 Spring 的資料處理能力

Spring AI 的另一個關鍵優勢是其與向量儲存的整合。無論您是使用帶 pgVector 的 Postgres、Redis，還是任何其他受支援的支援向量的資料庫，Spring AI 都擴充套件了 Spring 眾所周知的能力，以處理向量嵌入和其他 AI 驅動的資料儲存需求。

Spring AI 使得在不同向量儲存實現之間切換變得異常容易。使用 Spring 開發者熟悉的相同依賴注入模式，您只需更改 Spring Boot Starter 依賴項，而無需觸動核心應用邏輯，即可替換一個向量儲存。對於構建需要可擴充套件、高效儲存和檢索嵌入或其他 AI 生成資料的 AI 增強應用，這種靈活性是一個顯著的優勢。

將源資料嵌入向量儲存是一個強大的功能，但在嵌入之前如何處理不同的資料結構呢？藉助 Spring AI，您可以使用現成的文件讀取器來處理各種格式，包括 PDF、Markdown、Microsoft Word 和 PowerPoint 文件、HTML 等等。文件讀取器功能確保您可以處理各種源格式。如果某個特定格式不受支援，建立您自己的實現也非常簡單。

供應商無關的元資料過濾器

Spring AI 的一個突出特點是支援對嵌入進行元資料過濾，這與底層向量儲存實現無關。在典型的 RAG（檢索增強生成）應用中，會在向量儲存上執行相似度搜索，計算查詢與資料集中每個資料點之間的距離度量（例如，餘弦相似度）。雖然這種方法對於較小的資料集來說尚可管理，但隨著資料量的增長，其挑戰也越來越大。為了解決這個問題，向量儲存實現了各種效能增強演算法，例如近似最近鄰（ANN）、區域性敏感雜湊（LSH）或分層可導航小世界（HNSW）。

為了進一步應對這一挑戰，另一種有效的策略是首先在執行相似度搜索之前減少要查詢的資料量。例如，如果您只對位於波士頓的客戶感興趣，則可以將資料集過濾到僅包含居住在此地的客戶。這種縮減過程稱為元資料過濾。

許多向量儲存都提供了自己的元資料過濾實現，各有優缺點。然而，Spring AI 提供了一個供應商中立的解決方案，彌合了各種向量儲存之間的差距。這種能力在企業應用中尤為寶貴，在這些應用中，僅靠語義可能不足夠，並且必須從相似度搜索中排除某些個人身份資訊（PII）資料。透過利用元資料過濾，可以在相關的文件子集上執行相似度搜索，而不是掃描整個資料集。

以下是一個簡單的示例，更詳細的資訊可在Spring AI 參考文件中找到

public void example() {
    // Assume we have a large dataset of customers.
    // Embedding the data is computationally expensive 
    // but it is typically a one-time / ETL process
    List<Document> allMyCustomers = new ArrayList<>();
    allMyCustomers.add(new Document("""
            {
              "customerId": 12345,
              "name": "John Doe",
              "email": "[email protected]",
              "phone": "+1234567890",
              "address": "123 Main St, Boston, MA"
            }
            """, Map.of("city", "Boston"))); // Metadata filter!
    // Add more customers...
    allMyCustomers.add(...);
    
    // Add all embedded documents and their 
    // associated metadata to the vector store
    vectorStore.add(allMyCustomers);

    // Prepare a search query, for example: 
    // "Which customers are named John?"
    SearchRequest searchRequest = 
       SearchRequest.query("Which customers are named John?");

    // This similarity search is computationally intensive 
    List<Document> results = vectorStore.similaritySearch(
            searchRequest.withTopK(5)
                         .withSimilarityThresholdAll());

    // Instead, we'll first filter by city to reduce the dataset size,
    // then perform the similarity search on the filtered results
    results = vectorStore.similaritySearch(
            searchRequest.withTopK(5)
                         .withSimilarityThresholdAll()
                         .withFilterExpression("city == 'Boston'"));
}

函式呼叫的魔力：一種新範例

Spring AI 的一個突出功能是其函式呼叫能力，透過解決其最大的挑戰：與您自己的 API 整合！，這簡化了企業應用中的 AI 互動。

我最近讀到 Jonathan Schneider 在 LinkedIn 上的一篇文章，它引起了我的注意。他寫道，函式呼叫之於檢索增強生成 (RAG)，就像 IoC 之於 Java 開發一樣。IoC 使開發者能夠專注於業務邏輯，而 Spring 則負責物件建立和依賴注入。類似地，Spring AI 中的函式呼叫使開發者能夠專注於他們的函式做什麼，而大型語言模型 (LLM) 則負責處理幕後的複雜互動。

您用自然語言描述您的函式做什麼，Spring AI 會確保 LLM 在需要時理解並執行它。這極大地減少了與 AI 模型互動通常所需的樣板程式碼量，讓您可以專注於構建功能，而不是管理複雜的 AI 流程。

以下是來自Spring AI 參考文件的一個簡單示例

@Configuration
static class Config {
	@Bean
	@Description("Get the current weather in location")
	public Function<WeatherService.Request, WeatherService.Response> currentWeather() {
		return new MockWeatherService();
	}

}
public class WeatherService implements Function<Request, Response> {

	public enum Unit { C, F }
	public record Request(String location, Unit unit) {}
	public record Response(double temp, Unit unit) {}

	public Response apply(Request request) {
		// Logic goes here!
	}
}

目前沒有 AI 模型能夠提供特定地點的即時天氣資料。因此，LLM 可能會回覆說它不知道答案——或者更糟，它可能會返回一個幻覺響應。

然而，透過註冊如上所示的函式，Spring AI 允許 LLM 從 @Description 註解中推斷出此函式可以提供即時天氣資料。然後，LLM 可以根據使用者輸入，以正確的格式為 WeatherService.Request 構建請求。例如，如果使用者詢問“波士頓的天氣怎麼樣？”，LLM 將自動用位置和單位填充 Request 物件，請求 Spring AI 呼叫該函式，從 WeatherService 中檢索實際的天氣資料，然後根據該資料為使用者格式化一個人類可讀的響應。

以下是呼叫流程的分步分解

雖然向量儲存透過將您的資料嵌入 LLM 可以理解的格式來預處理資料，但函式呼叫使 LLM 能夠與您現有的事務性 API 進行即時互動，從而使其能夠在需要時生成有意義的響應。

使用 Spring AI Advisors 處理橫切關注點

Spring AI 引入了 Advisors，這是一種強大的機制，用於處理 AI 應用中的橫切關注點。如果您熟悉 面向切面程式設計 (AOP) 攔截器或 Spring MVC 攔截器，其概念是相似的。然而，考慮到並非所有開發者都熟悉這些術語，Spring AI 團隊選擇了使用“Advisor”一詞來強調其目的——增強請求/響應提示流——而不是其操作的技術細節，後者涉及攔截請求/響應並應用過濾器。Advisors 簡化了對諸如日誌記錄、訊息轉換和聊天記憶管理等任務的管理，同時保持您的應用程式碼乾淨整潔。

透過將這些例行任務分流，Advisors 確保您的應用專注於業務邏輯，而必要的 AI 相關操作則在後臺無縫執行。這種方法在有效解決必要的運營問題的同時，保持了程式碼庫的清晰度。

以下是一個簡單示例

this.chatClient = builder
    .defaultAdvisors(
            new MessageChatMemoryAdvisor(chatMemory), 
            new SimpleLoggerAdvisor())
    .build();

這個聊天客戶端集成了兩個 Advisor：一個記憶 Advisor，它將先前的使用者提示附加到當前訊息中以提供上下文和連貫性；以及一個日誌記錄 Advisor，它捕獲與 LLM 的請求和響應，並將其輸出到應用日誌中，以便有效進行故障排除。

無縫處理模型怪癖

使用生成式 AI 模型時經常出現的一個挑戰是每個模型都有自己的一套怪癖。例如，要求大型語言模型提供結構化響應（例如 JSON）並非看起來那麼簡單。LLM 經過訓練生成對話文字，它們通常喜歡以更像人類的方式“聊天”。這可能導致不可預測或過於冗長的輸出，這在您期望機器可讀格式時並不理想。

Spring AI 為您抽象了這些細微之處。它透過根據所使用的特定 LLM 新增適當的使用者提示或指令來自動處理這些差異。因此，無論您使用的是 OpenAI 的 GPT4-o、Anthropic 的 Claude，還是不同的 LLM，Spring AI 都確保您收到的響應是所需結構。這種能力消除了開發者進行反覆試驗的提示工程的需要，讓您可以專注於利用 AI，而不是費力應對其怪癖。

以下是 Spring AI 的 BeanOutputConverter 實現的一個示例，旨在從 LLM 以 JSON 格式檢索響應，並遵循給定資料類的模式。請注意，要達到期望的結果，需要向 LLM 提供多麼詳細和具體的提示

	@Override
	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);
	}

Spring AI 替您完成了繁重的工作。

AI 應用的內建可觀測性

可觀測性在任何企業應用中都至關重要，而增強了生成式 AI 的應用也不例外。Spring AI 提供了內建的可觀測性功能，使得無縫監控 AI 服務的健康狀況和效能成為可能。這包括全面的指標、跟蹤和日誌記錄，以便對您的生成式 AI 應用實現端到端的可見性。這不僅僅是針對聊天模型，而是針對整個堆疊，包括嵌入模型和向量資料庫。這項能力再次凸顯了 Spring 這種整合解決方案的強大之處，因為可觀測性功能由 micrometer 提供支援，就像其他 Spring 專案一樣

藉助 Spring AI，您可以深入瞭解關鍵指標，例如令牌使用率，這對於在使用根據處理的令牌數量收費的模型時管理成本至關重要。此外，您還可以監控向量儲存的延遲、錯誤率，甚至可以跟蹤請求如何在您的 AI 增強服務中流動。這種級別的可觀測性確保您可以在效能瓶頸或潛在問題影響您的應用之前快速識別它們，就像您習慣於處理其他基於 Spring 的服務一樣。

簡化的 A/B 測試以最佳化模型選擇

使用 Spring AI 的另一個顯著優勢是可以在不同的 LLM 提供商之間輕鬆進行 A/B 測試。為了在成本和響應質量之間取得最佳平衡，能夠比較多個模型是無價的。

藉助 Spring AI，您只需替換 Spring Boot Starter 依賴項並更改屬性檔案中的幾行程式碼，即可輕鬆在各種 LLM 之間切換。這種簡單直接的方法讓您無需進行大量重新配置或編碼開銷即可評估不同模型的效能。無論您是在評估準確性、響應時間還是成本效益，Spring AI 都提供了工具來促進這些無縫比較。

透過將 A/B 測試直接整合到您的工作流程中，您可以根據資料驅動的決策來確定哪家 LLM 提供商最適合您的應用需求。這項能力不僅增強了您 AI 實現的整體有效性，而且隨著生成式 AI 領域新模型和功能的出現，還允許進行持續最佳化。

為何選擇 Spring AI？

Spring AI 專為 Java 開發者設計，提供一種無縫且高效的方式將 AI 整合到其應用中。它不僅僅是新增 AI 能力，更重要的是以一種自然融入現有系統的方式來實現。將生成式 AI 應用於應用主要是一個整合挑戰，而這正是 Spring 框架的優勢所在。Spring AI 是 Spring 生態系統的自然延伸，旨在輕鬆處理企業應用整合的複雜性。

如果您的目標是使用生成模型、函式呼叫和向量嵌入來增強企業應用，那麼 Spring AI 是理想的選擇。它與 Spring 生態系統的深度整合，以及廣泛的大型語言模型和向量儲存選擇，使其在 AI 開發中既強大又直接。它非常適合將 AI 整合到現有業務邏輯中，消除了管理多步工作流或鏈式模型的複雜性。

總而言之，Spring AI 的一些突出優勢包括

• 無縫整合：毫不費力地將 AI 能力嵌入到現有 Spring 應用中。

• 專為 RAG 構建：簡化資料嵌入和執行相似度搜索的過程，同時支援強大的元資料過濾器。

• 函式呼叫：實現與事務性 API 的即時互動。

• Advisors： 使用內建的 Advisor 處理橫切關注點，或在需要時編寫您自己的 Advisor。

• 供應商無關：使用各種向量儲存和 LLM 提供商，而無需鎖定特定解決方案，從而在資料和模型管理方面提供靈活性。

• A/B 測試：輕鬆進行 A/B 測試以最佳化 AI 效能。

• 內建可觀測性：訪問監控、日誌記錄和跟蹤功能以提高透明度。

選擇 Spring AI，您將為您的企業應用注入先進的 AI 能力，推動創新並提升使用者體驗。