*本文作者系阿里云云原生微服務技術負責人，Spring AI Alibaba 發起人彥林，望陶和隆基對可觀測和 RocketMQ 部分內容亦有貢獻。
*

摘要

隨著生成式 AI 的快速發展，基于 AI 開發框架構建 AI 應用的訴求迅速增長，涌現出了包括 LangChain、LlamaIndex 等開發框架，但大部分框架只提供了 Python 語言的實現。但這些開發框架對于國內習慣了 Spring 開發范式的 Java 開發者而言，并非十分友好和絲滑。

因此，我們基于 Spring AI 發布并快速演進 Spring AI Alibaba，通過提供一種方便的 API 抽象，幫助 Java 開發者簡化 AI 應用的開發。同時，提供了完整的開源配套，包括可觀測、網關、消息隊列、配置中心等。

應用框架發展趨勢

應用架構歷經了單體架構、LAMP 架構、SOA 架構、微服務架構、云原生架構。

下圖左邊是典型的云原生應用架構，采用了容器 、微服務和聲明式 API 技術。其中，微服務按照業務模塊進行拆分，架構做無狀態改造，將存儲下沉到數據庫；微服務跑在容器上進行按量伸縮，從而把研發效率和運維發揮到極致。

右圖的 AI 原生應用架構，則是基于大模型（大腦），Agent 驅動（手腳）進行構建。其中，Agent 有三個架構原則：

• API First，開放協同： OpenAI 作為全球最大售賣 API 公司，通過 API 快速構建了生態和營收，加速創新，大模型企業無不例外通過 API 來向外提供服務。
• 事件驅動，提升吞吐： 不同于經典應用，大模型處理速度慢，長鏈接流式推送消耗大，因此需要消息解耦，提升吞吐。
• AIOps，一鍵診斷： 相比經典應用，大模型失敗率更高，定位難度更大，因此需要更智能的診斷工具。

AI Agent 框架發展趨勢

AI Agent 的發展大致可以分為以下 3 個階段：

• 第一階段：2022 年 ，ChatGPT 3.0 發布，震驚世界，但是當時數據幻覺，數據質量，數據格式問題非常多，很快行業推出了 LangChain 試圖來解決這些問題；但是隨著模型能力的增強，原有的問題逐步得到解決，但是由于大模型迭代迅速，Langchain 的過度封裝，反而沒有減少工程師們的代碼量，額外帶來了復雜度。
• 第二階段：2023 年，隨著 ChatGPT 4.0 / LIama 3.0 / Qwen 2.5 的推出，模型能力進一步提升，早期提示詞的價值逐步弱化，LlamaIndex 因其更簡單的體系抽象，更加符合當前的需求。
• 第三階段：2024 年，隨著多模態發展，模型能力持續突破，在過去的兩年框架以 Python 為主，但是對于中國 42.9% 的 Java 開發者會選擇是什么來構建 AI 應用呢？寫 Python？寫 Java 版 Langchain / LlamaIndex ？還是基于 Spring 體系進行構建？

Spring AI Alibaba?重磅發布

隨著生成式 AI 的快速發展，基于 AI 開發框架構建 AI 應用的訴求迅速增長，涌現出了包括 LangChain、LlamaIndex 等開發框架，它們為 Python 開發者提供了方便的 API 抽象。但這些開發框架對于國內習慣了 Spring 開發范式的 Java 開發者而言，并非十分友好和絲滑。因此，我們基于 Spring AI 發布并快速演進 Spring AI Alibaba，通過提供一種方便的 API 抽象，幫助 Java 開發者簡化 AI 應用的開發，一步邁入 AI 原生時代。

同時，我們發布了配套組件，更完整的幫助 Java 開發者簡化 AI 應用的開發。

• Higress：作為 AI 網關，支持多模型適配、流式輸出、請求/Tokens 限流防護、長連接無損熱更新，支持最小請求數負載均衡，并借助豐富的 AI 插件，幫助開發者零代碼構建 AI 應用，守住安全合規底線。
• OTel：基于開源 Open Telemetry Python SDK 進行了擴展，發布可觀測探針，為 GenAI 應用可觀測而生，能自動獲取大模型調用各個階段的數據，全面提升 LLM 應用的可觀測性。
• Apache RocketMQ：支持主動 POP 消費模式，自適應負載均衡，動態消費超時時長，適應不同算力消耗的請求，實時數據驅動 RAG 架構，提升吞吐量和實時性。
• Nacos Python SDK：提升靈活性，動態調整提示詞模版、算法、相關度等參數。

這一套開源矩陣具備“自用、開源、商業”三位一體的優勢，包括：

• 阿里內部大規模驗證，通義 / PAI / 百煉長期打磨。
• 具備完整的生態和組件，覆蓋應用開發的主鏈路。
• 支持主流大模型，低代碼、甚至無代碼構建企業級 AI 應用。
• 深度集成阿里云百煉、云原生應用開發平臺 CAP，開箱即用。

Spring AI Alibaba 已完整提供 Model、Prompt、RAG、Tools 等 AI 應用開發所需的必備能力，將兼具提示詞模板、函數調用、格式化輸出等低層次抽象，以及 RAG、智能體、對話記憶等高層次抽象。

項目地址：https://github.com/alibaba/spring-ai-alibaba

Higress：零代碼構建 AI 應用

我們可以很快構建 AI 應用，但是如何確保上線后不出問題呢？

• 相比 Web 應用，LLM 應用的內容生成時間更長，對話連續性對用戶體驗至關重要，如何避免后端插件更新導致的服務中斷？Higress 使用 Envoy 作為數據面，對網關配置、和連接無關的配置做了合理抽象，并通過 WASM 插件形式實現了熱更新，避免后端插件更新導致的服務中斷。
• 相比傳統 Web 應用，LLM 應用在服務端處理單個請求的資源消耗會大幅超過客戶端，來自客戶端的攻擊成本更低，后端的資源開銷更大，如何加固后端架構穩定性？Higress 提供了 Token 流控能力，并且集成 WAF 插件，在入口建立安全防線。
• 不同于傳統 Web 應用基于信息的匹配關系，LLM 應用生成的內容則是基于人工智能推理，如果保障生產內容的合規和安全？例如近期有兩家公司因為內容合規問題導致股市大跌，Higress 通過濾網插件，幫助用戶在流量入口處守住了合規底線。
• 當接入多個大模型 API 時，如何屏蔽不同模型廠商 API 的調用差異，來提升單一大模型的調用失敗率？Higress 提供了 AI Proxy 插件，構建高可用 AI 服務，如通義 2.5 失敗，Failover 到通義 2.0；或者自建大模型失敗，Failover 到通義模型等。

此外，為了解決 RT 問題，Higress 在入口構建緩存（對接 Redis），RAG 能力（對接向量數據庫），降低 RT，降低了大模型的調用成本。

OTel：提升大模型應用可觀測性

大模型失敗率較高，數據幻覺需要檢測，對輸出進行評估等。為了解決這個挑戰，我們基于 OTel Python 探針構建了阿里云 OTel python 發行版，增加了常見的大模型的埋點，以更好的觀測和大模型的交互過程，預計在 9 月正式上線。

在構建的過程中我們也看到 OTel 社區正在討論中的 GenAI 語義約定，因此我們的發行版也嚴格的遵循了最新 GenAI 語義約定，同時支持了常見的大模型框架例如 LlamaIndex，Langchain，PromtFlow 以及通義千問 2，OpenAI 等大模型。

在社區 GenAI 規范的基礎上，我們還增加了額外的精細化的埋點和 Attribute，能夠觀測到更加細節的交互過程，包括支持 session_id 在多個 traceId 之前進行傳播，以方便在一個會話中關聯多個調用鏈。有了這些埋點之后，客戶可以方便的在專屬大模型視圖中查看與大模型交互的信息，包括各種 RAG 的過程，調用大模型的入參出參，消耗的 token 等等，這些增強我們也計劃貢獻給社區。

Nacos：提升 Agent 靈活性

模型上線后，我們為了不斷提升效果，需要不斷優化各種參數和配置。傳統做法是改一個參數就重啟發布一次；這樣效率低下，且發布對業務業務流量有損。

因此，我們把提示詞模版/相關的參數存儲在在 Nacos 配置中心，通過動態配置可以實時修改，無需重啟就能發布應用；為了滿足安全合規要求，把對大模型調用過程中定義的脫敏規則、密鑰，以及數據源外置到 Nacos 配置中心；最后，為了提升模型的穩定性，需要做好 A/B 測試，可以把模型版本、參數、流控規則，也存儲在 Nacos 配置中心。可見，通過 Nacos 可以大幅提升 Agent 的靈活性。

Apache RocketMQ：提升 AI 應用吞吐量和實時性

在推理場景，私域數據向量化后，提供給 AI 應用搜索增強，但是這個模式私域數據不能及時更新，為了提升整體鏈路實時性，可以通過事件流集成關鍵事件，實時 Embedding 向量數據庫、更新私有數據存儲，全面提升 AI 應用實時性、個性化和準確度。

AI 原生應用請求往往耗時過久，全面采用同步調用會使得系統性能急劇惡化，響應慢，影響客戶體驗。通過引入RocketMQ 事件驅動架構、解耦快慢服務，能顯著提升性能和體驗。面臨 AI 應用請求耗時方差大，資源消耗不均勻的特點，RocketMQ 支持主動 Pop 消費模式，動態消費超時時長，能夠實時結合模型實例負載和推理請求特點，自適應負載均衡。

Java AI 開發框架的落地&實踐

相信通過上面的介紹，大家對于構建生成式 AI 應用已經躍躍欲試了，但是選擇哪些場景投入產出比較高呢？下面簡單分享一下我們的思路。

AI 落地場景

是不是所有的業務都能用 AI 解決呢？目前看不是的。那 AI 適合做什么場景呢？目前看，適合容錯性高、結構化強的場景。

我們在做開源社區的時候發現社區的 Issue 非常多，但是無法響應開發者需求，因此我們想如果構建一個 AI 答疑專家，幫助開發者解決場景問題，構建新型開源社區協作模式，這個就非常有價值。

因此我們落地第一個場景是 AI 答疑專家，解決開源社區答疑問題，提升開源社區活躍度。

AI 技術選型

我們在技術上有三個技術選型 ：Prompt / RAG / 微調。

• Prompt：效果略有提升，但是不能帶來本質改變；
• 微調：成本比較高，我們的數據還不斷迭代過程中無法承受；
• RAG：無論是成本、效果，還是可持續迭代性，都是目前最高投入產出比模式，因此我們采用了 RAG 為主的技術方案。

AI 應用實踐

AI 答疑專家-實踐

AI 答疑專家基于百煉的通義 2.5 模型，將開源文檔、電子書、常見問題灌入百煉數據中心，進行了向量化；通過 Spring AI Alibaba 對接通義模型和 RAG 能力，搜索到了 TOP3 的相關度信息，進行壓縮提煉。并通過 Higress 將服務發布到開源官網和釘釘機器人，在入口構建安全合規防線。最后通過 AI 答疑專家不斷與開發者溝通，收集反饋。通過 Chat-Admin 處理反饋差的信息，補充文檔，優化數據。

AI 答疑專家-落地效果

落地效果非常顯著，開源官網的流量提升了 20%，人工答疑成本降低 20%，準確率可達 90%+，并且完成了私域數據、AI 專家反饋機制、人工訂正的正循環。

AI 答疑專家-AIPaaS 雛形

最后我們構建了 AI 行業專家解決方案，沉淀了 AIPaaS 的雛形，以模型未核心，Agent 驅動，充分挖掘私域數據，打造行業 AI 專家！

未來，我們將提供 Spring AI Alibaba 和阿里巴巴整體開源生態的深度適配，包括 Prompt Template 管理、事件驅動的 AI 應用程序、更多 Vector Database 支持、函數計算等部署模式、可觀測性建設、AI 代理節點開發能力，如綠網、限流、多模型切換和開發者工具集，旨在構建業內最完整的 AI 驅動的 Java 開發框架生態。