1. 一個(gè)框架停更引發(fā)的技術(shù)選型焦慮前幾天在技術(shù)群里看到有人轉(zhuǎn)了一篇文章標(biāo)題大意是某個(gè)Java生態(tài)的AI框架停更了底下評(píng)論區(qū)立刻炸了鍋。有人說(shuō)Java做AI本來(lái)就沒(méi)戲有人說(shuō)趕緊轉(zhuǎn)Python吧還有人翻出幾年前Java已死的老梗重新炒了一遍。我當(dāng)時(shí)正在用Java寫(xiě)一個(gè)RAG檢索增強(qiáng)生成的服務(wù)端模塊看到這些討論說(shuō)實(shí)話心里也咯噔了一下——畢竟誰(shuí)都不想把生產(chǎn)系統(tǒng)建在一個(gè)沒(méi)人維護(hù)的地基上。但冷靜下來(lái)之后我把這件事從頭到尾捋了一遍發(fā)現(xiàn)事情遠(yuǎn)沒(méi)有標(biāo)題黨說(shuō)的那么悲觀。一個(gè)框架停更和Java能不能做AI完全是兩個(gè)層面的問(wèn)題。前者是某個(gè)具體開(kāi)源項(xiàng)目的生命周期問(wèn)題后者是一個(gè)語(yǔ)言生態(tài)在AI工程化領(lǐng)域的定位問(wèn)題。把這兩件事混為一談就像因?yàn)槟臣也蛷d關(guān)門了就說(shuō)中餐沒(méi)希望了一樣荒謬。這篇文章我想聊清楚三件事第一一個(gè)AI框架停更到底意味著什么它影響的是哪一層第二Java在AI應(yīng)用開(kāi)發(fā)中真正的位置在哪里哪些場(chǎng)景它天然有優(yōu)勢(shì)哪些場(chǎng)景確實(shí)不該硬上第三如果你正在用Java做AI相關(guān)的服務(wù)端開(kāi)發(fā)接下來(lái)該怎么調(diào)整技術(shù)棧和架構(gòu)思路。不管你是剛接觸AI應(yīng)用開(kāi)發(fā)的Java后端還是正在做技術(shù)選型的技術(shù)負(fù)責(zé)人希望這篇內(nèi)容能幫你把焦慮轉(zhuǎn)化成清晰的判斷。2. 框架停更這件事到底動(dòng)了誰(shuí)的奶酪2.1 先搞清楚停更的是什么層面的東西很多人一聽(tīng)到AI框架停更就慌了但其實(shí)得先看清楚這個(gè)框架在技術(shù)棧里處于什么位置。AI應(yīng)用開(kāi)發(fā)大致可以分成這么幾層最底層是模型訓(xùn)練和推理引擎中間層是模型服務(wù)化和編排框架最上層是應(yīng)用層的業(yè)務(wù)邏輯集成。不同層的東西停更影響完全不一樣。如果停更的是底層推理引擎那確實(shí)比較麻煩因?yàn)檫@意味著你可能要自己維護(hù)算子優(yōu)化、硬件適配這些極其復(fù)雜的東西。但如果停更的是應(yīng)用層的集成框架——比如某個(gè)幫你把大模型API封裝成Spring Bean的庫(kù)——那影響就小得多。這類框架本質(zhì)上做的是膠水工作把HTTP調(diào)用封裝一下把返回結(jié)果解析一下提供幾個(gè)注解讓你少寫(xiě)點(diǎn)樣板代碼。它的核心邏輯并不復(fù)雜你甚至可以在幾天內(nèi)自己實(shí)現(xiàn)一個(gè)簡(jiǎn)化版本。我仔細(xì)看了一下那個(gè)停更項(xiàng)目的定位它主要做的是應(yīng)用層的集成和編排包括對(duì)話管理、提示詞模板、向量庫(kù)對(duì)接這些。這些東西的技術(shù)含量不在于代碼有多難寫(xiě)而在于生態(tài)整合和持續(xù)維護(hù)。停更意味著不再有新功能、不再適配新版本的依賴、不再修復(fù)bug但它已經(jīng)實(shí)現(xiàn)的功能不會(huì)突然消失你已有的系統(tǒng)也不會(huì)明天就崩掉。2.2 停更的真正風(fēng)險(xiǎn)在哪里雖然已有的功能不會(huì)消失但停更確實(shí)帶來(lái)幾個(gè)實(shí)實(shí)在在的風(fēng)險(xiǎn)這些才是你需要認(rèn)真評(píng)估的。依賴版本鎖死是最直接的問(wèn)題。你用的Spring Boot版本在升級(jí)JDK版本在升級(jí)但那個(gè)停更的框架可能只兼容到某個(gè)舊版本。時(shí)間一長(zhǎng)你的整個(gè)依賴樹(shù)就被它拖住了想升級(jí)其他組件就得先解決兼容性問(wèn)題。我遇到過(guò)類似的情況一個(gè)停更的SDK鎖死了某個(gè)HTTP客戶端的版本導(dǎo)致我們沒(méi)法升級(jí)到支持HTTP/2的新版本最后只能把那個(gè)SDK的源碼扒出來(lái)自己改。安全漏洞無(wú)人修復(fù)是更隱蔽的風(fēng)險(xiǎn)。AI應(yīng)用框架通常會(huì)處理外部輸入——用戶的消息、上傳的文檔、調(diào)用的外部API返回——這些都是潛在的攻擊面。如果框架里存在注入漏洞或者反序列化問(wèn)題停更就意味著不會(huì)有官方補(bǔ)丁。你得自己盯著CVE公告自己評(píng)估影響自己打補(bǔ)丁。社區(qū)知識(shí)斷層也很要命。一個(gè)活躍的項(xiàng)目你遇到問(wèn)題去搜能找到大量討論、issue和解決方案。停更的項(xiàng)目你遇到新問(wèn)題可能全網(wǎng)都搜不到答案只能自己啃源碼。而且隨著時(shí)間推移記得這個(gè)框架的人越來(lái)越少你能獲得的幫助也越來(lái)越少。但話說(shuō)回來(lái)這些風(fēng)險(xiǎn)都是可以管理的。依賴鎖死可以通過(guò)隔離層來(lái)緩解安全漏洞可以通過(guò)代碼審計(jì)來(lái)發(fā)現(xiàn)社區(qū)斷層可以通過(guò)提前儲(chǔ)備知識(shí)來(lái)應(yīng)對(duì)。關(guān)鍵是你得知道自己面對(duì)的是什么而不是被停更兩個(gè)字嚇到。2.3 為什么Java做不了AI是個(gè)偽命題每次有Java AI相關(guān)的項(xiàng)目出問(wèn)題就會(huì)有人跳出來(lái)說(shuō)Java不適合做AI。這個(gè)說(shuō)法混淆了兩個(gè)完全不同的概念A(yù)I模型研發(fā)和AI應(yīng)用開(kāi)發(fā)。模型研發(fā)確實(shí)主要是Python的天下因?yàn)镻yTorch、TensorFlow這些訓(xùn)練框架的生態(tài)在Python里最成熟學(xué)術(shù)界和工業(yè)界的研究人員也都在用Python。但AI應(yīng)用開(kāi)發(fā)是另一回事。當(dāng)你把訓(xùn)練好的模型部署到生產(chǎn)環(huán)境要處理高并發(fā)請(qǐng)求、要保證服務(wù)可用性、要做事務(wù)管理、要集成到現(xiàn)有的業(yè)務(wù)系統(tǒng)里——這些恰恰是Java最擅長(zhǎng)的領(lǐng)域。你想想一個(gè)電商平臺(tái)要加一個(gè)智能客服功能它需要的是什么需要的是能扛住雙十一級(jí)別的并發(fā)量需要的是和現(xiàn)有的訂單系統(tǒng)、用戶系統(tǒng)無(wú)縫集成需要的是完善的監(jiān)控、日志、熔斷、降級(jí)機(jī)制。這些能力Java生態(tài)積累了二十年P(guān)ython在這方面差得遠(yuǎn)。模型推理可以單獨(dú)部署成服務(wù)用任何語(yǔ)言調(diào)用都行但業(yè)務(wù)邏輯的編排和集成Java仍然是首選。所以真正的問(wèn)題不是Java能不能做AI而是Java在AI技術(shù)棧里應(yīng)該承擔(dān)什么角色。想清楚這個(gè)問(wèn)題框架停更這種事就不會(huì)讓你慌了。3. Java在AI應(yīng)用棧里的真實(shí)位置3.1 模型推理層Java不是主角但也不必缺席在模型推理這一層Java確實(shí)不是主流選擇。大多數(shù)團(tuán)隊(duì)會(huì)把模型部署成獨(dú)立的推理服務(wù)用Python或者C寫(xiě)然后通過(guò)HTTP或gRPC對(duì)外提供服務(wù)。這種架構(gòu)下Java作為調(diào)用方完全不需要關(guān)心模型是怎么加載的、推理是怎么加速的。但有些場(chǎng)景下你確實(shí)可能需要在Java進(jìn)程內(nèi)做推理。比如邊緣計(jì)算場(chǎng)景設(shè)備上只有一個(gè)JVM你不可能再塞一個(gè)Python運(yùn)行時(shí)進(jìn)去。或者對(duì)延遲極其敏感的場(chǎng)景少一次網(wǎng)絡(luò)調(diào)用就能省幾毫秒。這時(shí)候可以考慮ONNX Runtime的Java綁定或者一些專門為JVM優(yōu)化的推理引擎。不過(guò)我得說(shuō)這條路走起來(lái)比較辛苦工具鏈不如Python成熟遇到問(wèn)題參考資料也少。除非有明確的必要否則我還是建議把推理獨(dú)立出去。3.2 應(yīng)用編排層Java的主場(chǎng)這一層才是Java真正該發(fā)力地方。所謂應(yīng)用編排就是把模型能力、業(yè)務(wù)邏輯、外部工具、數(shù)據(jù)存儲(chǔ)這些東西串起來(lái)形成一個(gè)完整的AI應(yīng)用。比如一個(gè)智能文檔處理系統(tǒng)它需要接收用戶上傳的文檔、調(diào)用OCR提取文字、調(diào)用大模型做摘要和分類、把結(jié)果存入數(shù)據(jù)庫(kù)、通知用戶處理完成。這一整套流程的編排Java做起來(lái)得心應(yīng)手。Spring生態(tài)在這方面的優(yōu)勢(shì)太明顯了。依賴注入讓你可以輕松替換不同的模型提供商AOP可以統(tǒng)一處理日志和監(jiān)控事務(wù)管理保證數(shù)據(jù)一致性Spring Batch適合處理大批量任務(wù)。這些能力不是專門為AI設(shè)計(jì)的但AI應(yīng)用同樣需要。你不需要一個(gè)AI框架來(lái)告訴你怎么做這些事Spring本身就能做好。我現(xiàn)在的做法是把模型調(diào)用封裝成一個(gè)普通的Service用接口隔離具體實(shí)現(xiàn)。這樣今天用這家模型明天換那家只需要換一個(gè)實(shí)現(xiàn)類。提示詞模板用配置文件管理方便調(diào)整。向量檢索封裝成Repository和數(shù)據(jù)庫(kù)訪問(wèn)一樣的模式。整個(gè)架構(gòu)里沒(méi)有什么AI特有的東西都是標(biāo)準(zhǔn)的Java企業(yè)級(jí)開(kāi)發(fā)模式。3.3 數(shù)據(jù)處理層被低估的Java強(qiáng)項(xiàng)AI應(yīng)用離不開(kāi)數(shù)據(jù)處理——清洗、轉(zhuǎn)換、分塊、嵌入、索引。這些工作Java其實(shí)很擅長(zhǎng)。Apache Tika可以解析幾乎所有格式的文檔Lucene/Elasticsearch是成熟的全文檢索方案各種ETL工具和批處理框架也很完善。特別是當(dāng)你的數(shù)據(jù)量上來(lái)之后Java的批處理能力和內(nèi)存管理優(yōu)勢(shì)就體現(xiàn)出來(lái)了。Python處理幾百萬(wàn)條數(shù)據(jù)可能會(huì)遇到內(nèi)存和性能瓶頸Java在這方面有更多的調(diào)優(yōu)空間。而且Java的并發(fā)工具包非常成熟做并行數(shù)據(jù)處理比Python的multiprocessing要順手得多。3.4 什么時(shí)候該用Python什么時(shí)候該用Java說(shuō)了這么多Java的好話我也得客觀一點(diǎn)。有些場(chǎng)景確實(shí)用Python更合適。場(chǎng)景推薦語(yǔ)言理由模型訓(xùn)練與微調(diào)Python生態(tài)成熟工具鏈完善快速原型驗(yàn)證Python開(kāi)發(fā)效率高試錯(cuò)成本低數(shù)據(jù)探索與分析PythonNotebook交互式體驗(yàn)好高并發(fā)API服務(wù)Java并發(fā)處理能力強(qiáng)性能穩(wěn)定企業(yè)級(jí)系統(tǒng)集成Java生態(tài)完善與現(xiàn)有系統(tǒng)對(duì)接方便大規(guī)模批處理Java內(nèi)存管理和并發(fā)控制更精細(xì)邊緣設(shè)備推理C/Rust資源占用低無(wú)運(yùn)行時(shí)依賴這張表不是絕對(duì)的只是一個(gè)參考。實(shí)際選型還要考慮團(tuán)隊(duì)的技術(shù)棧、運(yùn)維能力、招聘難度等因素。但核心思路是讓每種語(yǔ)言做它最擅長(zhǎng)的事而不是強(qiáng)行用一種語(yǔ)言解決所有問(wèn)題。4. 框架停更后的技術(shù)棧調(diào)整方案4.1 先做影響評(píng)估別急著換聽(tīng)到框架停更的消息第一反應(yīng)不應(yīng)該是趕緊換而是先看看影響有多大。我一般會(huì)從這幾個(gè)維度做評(píng)估使用深度你是只用了最基礎(chǔ)的幾個(gè)功能還是深度依賴了它的各種高級(jí)特性如果只是用它的HTTP客戶端封裝那替換成本很低。如果用了它的工作流編排、狀態(tài)管理、自定義擴(kuò)展點(diǎn)那替換起來(lái)就麻煩了。替代方案成熟度市面上有沒(méi)有功能對(duì)等的替代品替代品的社區(qū)活躍度如何遷移成本有多大如果替代品還不如自己維護(hù)那不如不換。業(yè)務(wù)關(guān)鍵程度這個(gè)框架支撐的是核心業(yè)務(wù)還是邊緣功能核心業(yè)務(wù)求穩(wěn)邊緣功能可以激進(jìn)一點(diǎn)。團(tuán)隊(duì)技術(shù)儲(chǔ)備團(tuán)隊(duì)有沒(méi)有能力自己維護(hù)一個(gè)fork有沒(méi)有精力跟進(jìn)上游的安全補(bǔ)丁做完這個(gè)評(píng)估你可能會(huì)發(fā)現(xiàn)有些項(xiàng)目其實(shí)可以繼續(xù)用只是需要做好隔離和監(jiān)控有些項(xiàng)目確實(shí)該換但可以慢慢來(lái)不用一刀切。4.2 隔離層設(shè)計(jì)讓框架可替換不管最終換不換有一個(gè)架構(gòu)原則是通用的不要讓業(yè)務(wù)代碼直接依賴具體的AI框架。這一層隔離做好了換框架就是換一個(gè)實(shí)現(xiàn)類的事。具體怎么做定義一組接口把AI能力的調(diào)用抽象出來(lái)。比如public interface ChatService { ChatResponse chat(ChatRequest request); FluxChatResponse stream(ChatRequest request); } public interface EmbeddingService { Listfloat[] embed(ListString texts); } public interface VectorStore { void add(ListDocument documents); ListDocument search(String query, int topK); }然后針對(duì)每個(gè)框架寫(xiě)一個(gè)實(shí)現(xiàn)類。業(yè)務(wù)代碼只依賴接口不依賴具體實(shí)現(xiàn)。這樣今天用A框架明天換B框架業(yè)務(wù)代碼一行不用改。這個(gè)模式的好處不僅僅是方便換框架。它還讓你可以在測(cè)試環(huán)境用Mock實(shí)現(xiàn)在生產(chǎn)環(huán)境用真實(shí)實(shí)現(xiàn)讓你可以同時(shí)接入多個(gè)模型提供商根據(jù)成本或效果動(dòng)態(tài)切換讓你可以在框架出問(wèn)題時(shí)快速降級(jí)到備用方案。4.3 自研輕量級(jí)替代方案如果找不到合適的替代框架或者替代框架太重自己寫(xiě)一個(gè)輕量級(jí)的封裝其實(shí)不難。我前段時(shí)間就自己寫(xiě)了一個(gè)核心代碼不到五百行覆蓋了對(duì)話、嵌入、向量檢索三個(gè)最常用的功能。關(guān)鍵是要想清楚你需要什么。不要試圖復(fù)刻一個(gè)完整的框架只實(shí)現(xiàn)你真正用到的功能。比如對(duì)話功能核心就是構(gòu)造請(qǐng)求、發(fā)送HTTP、解析響應(yīng)、處理錯(cuò)誤這幾步。用Java的HttpClient或者OkHttp加上Jackson做JSON處理半天就能寫(xiě)出一個(gè)可用的版本。自己維護(hù)的好處是完全可控。你不需要等社區(qū)更新不需要遷就框架的設(shè)計(jì)決策遇到問(wèn)題直接改代碼。壞處是安全補(bǔ)丁和bug修復(fù)都得自己來(lái)所以要做好代碼審查和測(cè)試覆蓋。4.4 多框架并存的策略有時(shí)候你不需要二選一可以多個(gè)方案并存。比如核心業(yè)務(wù)用一個(gè)穩(wěn)定的、自己維護(hù)的封裝新功能嘗試用新的框架?；蛘卟煌臉I(yè)務(wù)線用不同的方案互不影響。這種策略的關(guān)鍵是做好抽象和隔離。只要接口定義清晰底層用幾個(gè)框架都無(wú)所謂。而且多方案并存還有一個(gè)好處可以對(duì)比不同框架的表現(xiàn)為未來(lái)的技術(shù)選型積累數(shù)據(jù)。5. 從零搭建一個(gè)不依賴特定框架的AI服務(wù)5.1 項(xiàng)目結(jié)構(gòu)設(shè)計(jì)說(shuō)了這么多理論不如直接動(dòng)手搭一個(gè)。我以一個(gè)文檔問(wèn)答服務(wù)為例展示一下怎么用純Spring Boot加少量自研代碼實(shí)現(xiàn)一個(gè)AI應(yīng)用不依賴任何特定的AI框架。項(xiàng)目結(jié)構(gòu)大概是這樣src/main/java/com/example/ai/ ├── config/ │ ├── HttpClientConfig.java │ └── ModelProperties.java ├── controller/ │ └── QaController.java ├── service/ │ ├── ChatService.java │ ├── EmbeddingService.java │ └── DocumentService.java ├── store/ │ └── InMemoryVectorStore.java └── model/ ├── ChatRequest.java ├── ChatResponse.java └── Document.java核心思路是用配置類管理模型參數(shù)用Service封裝模型調(diào)用用Store管理向量數(shù)據(jù)用Controller暴露API。每一層職責(zé)清晰替換任何一層都不影響其他層。5.2 模型調(diào)用的最小實(shí)現(xiàn)先看模型調(diào)用這部分。我用Java 11的HttpClient來(lái)發(fā)請(qǐng)求不引入額外的HTTP庫(kù)。Service public class OpenAiChatService implements ChatService { private final HttpClient httpClient; private final ModelProperties properties; private final ObjectMapper objectMapper; public OpenAiChatService(ModelProperties properties, ObjectMapper objectMapper) { this.properties properties; this.objectMapper objectMapper; this.httpClient HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); } Override public ChatResponse chat(ChatRequest request) { var body Map.of( model, properties.getModel(), messages, request.getMessages(), temperature, request.getTemperature() ); var httpRequest HttpRequest.newBuilder() .uri(URI.create(properties.getBaseUrl() /chat/completions)) .header(Content-Type, application/json) .header(Authorization, Bearer properties.getApiKey()) .POST(HttpRequest.BodyPublishers.ofString( objectMapper.writeValueAsString(body))) .build(); var response httpClient.send(httpRequest, HttpResponse.BodyHandlers.ofString()); return objectMapper.readValue(response.body(), ChatResponse.class); } }這段代碼沒(méi)什么魔法就是構(gòu)造JSON、發(fā)HTTP請(qǐng)求、解析響應(yīng)。你可以很容易地加上重試、超時(shí)、熔斷這些邏輯。而且因?yàn)椴灰蕾嚾魏慰蚣苌?jí)JDK或者Spring Boot都不會(huì)有兼容性問(wèn)題。5.3 向量存儲(chǔ)與檢索的簡(jiǎn)化方案向量存儲(chǔ)這塊如果數(shù)據(jù)量不大比如幾萬(wàn)條以內(nèi)完全可以用內(nèi)存加簡(jiǎn)單的余弦相似度計(jì)算來(lái)實(shí)現(xiàn)。不需要上專業(yè)的向量數(shù)據(jù)庫(kù)。Component public class InMemoryVectorStore implements VectorStore { private final ListDocument documents new CopyOnWriteArrayList(); Override public void add(ListDocument docs) { documents.addAll(docs); } Override public ListDocument search(float[] queryVector, int topK) { return documents.stream() .map(doc - Map.entry(doc, cosineSimilarity(queryVector, doc.getVector()))) .sorted(Map.Entry.Document, DoublecomparingByValue().reversed()) .limit(topK) .map(Map.Entry::getKey) .collect(Collectors.toList()); } private double cosineSimilarity(float[] a, float[] b) { double dot 0, normA 0, normB 0; for (int i 0; i a.length; i) { dot a[i] * b[i]; normA a[i] * a[i]; normB b[i] * b[i]; } return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } }這個(gè)實(shí)現(xiàn)很粗糙但對(duì)于原型驗(yàn)證和小規(guī)模應(yīng)用足夠了。等數(shù)據(jù)量上來(lái)了再換成Elasticsearch的向量檢索或者專業(yè)的向量數(shù)據(jù)庫(kù)接口不用變。5.4 提示詞模板的管理提示詞模板我建議放在配置文件里而不是硬編碼在Java代碼里。這樣調(diào)整提示詞不需要重新編譯也方便做A/B測(cè)試。prompts: qa: system: | 你是一個(gè)知識(shí)助手根據(jù)提供的上下文回答問(wèn)題。 如果上下文中沒(méi)有相關(guān)信息請(qǐng)如實(shí)告知。 user: | 上下文 {context} 問(wèn)題{question}然后用Spring的ConfigurationProperties注入用簡(jiǎn)單的字符串替換填充變量。不需要引入模板引擎Java自帶的String.format或者M(jìn)essageFormat就夠了。6. 實(shí)操中踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)6.1 流式響應(yīng)的處理比想象中麻煩如果你要做打字機(jī)效果的流式輸出會(huì)發(fā)現(xiàn)事情沒(méi)那么簡(jiǎn)單。SSEServer-Sent Events的解析需要處理分塊傳輸、不完整的JSON、連接中斷重連等各種情況。我一開(kāi)始自己寫(xiě)解析邏輯踩了不少坑有時(shí)候一個(gè)JSON對(duì)象被拆成兩個(gè)TCP包有時(shí)候服務(wù)端會(huì)發(fā)送空行作為心跳有時(shí)候網(wǎng)絡(luò)抖動(dòng)導(dǎo)致連接斷開(kāi)但客戶端不知道。后來(lái)我的做法是用成熟的HTTP客戶端庫(kù)比如OkHttp的SSE支持或者Spring WebFlux的WebClient它們已經(jīng)處理好了這些邊界情況。如果非要自己實(shí)現(xiàn)一定要做好緩沖和狀態(tài)管理不要假設(shè)每次讀取都能拿到完整的消息。6.2 超時(shí)和重試策略需要仔細(xì)設(shè)計(jì)模型調(diào)用通常比較慢幾秒到幾十秒都正常。超時(shí)設(shè)太短會(huì)導(dǎo)致大量請(qǐng)求失敗設(shè)太長(zhǎng)會(huì)拖垮線程池。我的經(jīng)驗(yàn)是連接超時(shí)設(shè)5秒讀取超時(shí)設(shè)60秒根據(jù)實(shí)際模型響應(yīng)時(shí)間調(diào)整。重試要特別小心。模型調(diào)用不是冪等的——同樣的請(qǐng)求可能返回不同的結(jié)果而且重試會(huì)消耗額外的token。我的策略是只對(duì)網(wǎng)絡(luò)錯(cuò)誤和5xx錯(cuò)誤重試4xx錯(cuò)誤直接返回重試次數(shù)不超過(guò)2次重試之間加指數(shù)退避。還有一個(gè)容易被忽略的點(diǎn)流式請(qǐng)求的重試很麻煩因?yàn)椴糠猪憫?yīng)可能已經(jīng)發(fā)送給客戶端了。這種情況我一般不做自動(dòng)重試而是讓客戶端決定是否重新發(fā)起請(qǐng)求。6.3 成本控制要從架構(gòu)層面考慮用大模型API是要花錢的而且很容易超支。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)因?yàn)闆](méi)做限制一個(gè)月燒掉了幾萬(wàn)塊?？刂瞥杀疽獜膸讉€(gè)層面入手緩存是最有效的手段。相同的請(qǐng)求直接返回緩存結(jié)果能省下大量重復(fù)調(diào)用。對(duì)于問(wèn)答場(chǎng)景可以對(duì)問(wèn)題進(jìn)行歸一化處理后做緩存。限流是必須的。按用戶、按接口、按時(shí)間段設(shè)置調(diào)用上限防止異常流量導(dǎo)致費(fèi)用失控。降級(jí)策略也很重要。當(dāng)預(yù)算快用完時(shí)自動(dòng)切換到更便宜的模型或者限制單次請(qǐng)求的token數(shù)量。監(jiān)控不能少。實(shí)時(shí)跟蹤token消耗和費(fèi)用設(shè)置告警閾值發(fā)現(xiàn)異常及時(shí)處理。6.4 測(cè)試策略要覆蓋模型的不確定性AI應(yīng)用的測(cè)試和傳統(tǒng)應(yīng)用很不一樣因?yàn)槟Ｐ偷妮敵鍪遣淮_定的。同樣的輸入兩次調(diào)用可能得到不同的結(jié)果。這給自動(dòng)化測(cè)試帶來(lái)了挑戰(zhàn)。我的做法是分兩層測(cè)試。第一層是單元測(cè)試用Mock的模型響應(yīng)驗(yàn)證業(yè)務(wù)邏輯的正確性。第二層是集成測(cè)試調(diào)用真實(shí)的模型但只驗(yàn)證輸出的格式和關(guān)鍵特征不驗(yàn)證具體內(nèi)容。比如驗(yàn)證返回的JSON結(jié)構(gòu)正確、包含必要的字段、長(zhǎng)度在合理范圍內(nèi)但不檢查具體說(shuō)了什么。另外維護(hù)一組黃金測(cè)試用例很有必要。這些用例覆蓋了常見(jiàn)的場(chǎng)景和邊界情況每次修改提示詞或者換模型后都跑一遍人工評(píng)估輸出質(zhì)量。雖然不能完全自動(dòng)化但能及時(shí)發(fā)現(xiàn)明顯的退化。6.5 日志和可觀測(cè)性要提前規(guī)劃AI應(yīng)用的調(diào)試比傳統(tǒng)應(yīng)用困難得多。用戶說(shuō)回答不對(duì)你需要知道當(dāng)時(shí)用的什么提示詞檢索到了哪些文檔模型的原始返回是什么這些信息如果沒(méi)提前記錄事后根本查不到。我的做法是在關(guān)鍵節(jié)點(diǎn)打結(jié)構(gòu)化日志請(qǐng)求進(jìn)入時(shí)記錄用戶輸入和參數(shù)檢索完成后記錄命中的文檔ID和相似度分?jǐn)?shù)模型返回后記錄原始響應(yīng)和token消耗最終響應(yīng)前記錄處理耗時(shí)。這些日志用JSON格式輸出方便后續(xù)分析和檢索。敏感信息要脫敏。用戶的原始輸入可能包含個(gè)人信息日志里要做好掩碼處理。API密鑰絕對(duì)不能打進(jìn)日志。6.6 關(guān)于框架選型的個(gè)人體會(huì)折騰了這么多我對(duì)框架選型的態(tài)度是用框架但要保持可替換性能自己寫(xiě)的就別引入重依賴?？蚣艿膬r(jià)值在于幫你快速起步但代價(jià)是增加了抽象層和依賴。如果一個(gè)框架只是幫你省了幾十行樣板代碼那引入它的收益可能抵不過(guò)維護(hù)成本。反過(guò)來(lái)如果一個(gè)框架提供了你很難自己實(shí)現(xiàn)的能力比如復(fù)雜的編排引擎、完善的監(jiān)控體系那引入它是值得的。但不管用什么框架隔離層一定要做。這不僅僅是為了應(yīng)對(duì)框架停更更是為了保持架構(gòu)的靈活性。技術(shù)變化太快今天流行的框架明天可能就過(guò)時(shí)了唯一不變的是你的業(yè)務(wù)邏輯和接口定義?；氐阶畛醯膯?wèn)題某個(gè)框架停更了Java還有希望嗎我的答案是Java在AI應(yīng)用開(kāi)發(fā)領(lǐng)域的地位不會(huì)因?yàn)槟硞€(gè)框架的停更而動(dòng)搖。真正重要的是你對(duì)業(yè)務(wù)的理解、對(duì)架構(gòu)的把控、對(duì)技術(shù)本質(zhì)的洞察?？蚣苤皇枪ぞ吖ぞ邥?huì)換但能力不會(huì)。把隔離層做好把核心邏輯掌握在自己手里任何框架的變動(dòng)都不會(huì)讓你措手不及。