近幾年做自然語言處理系統(tǒng)越來越多的團(tuán)隊(duì)開始重新審視Pipeline這個(gè)詞。以前提起NLP工程化大家的第一反應(yīng)是一條寫死的處理鏈分詞、詞性標(biāo)注、依存句法、命名實(shí)體識別、關(guān)系抽取每一環(huán)的輸入輸出像齒輪一樣咬合任何一環(huán)出錯(cuò)后面整條鏈基本報(bào)廢。現(xiàn)在不一樣了?，F(xiàn)代NLP組件強(qiáng)調(diào)的是組件化設(shè)計(jì)、按場景選型、深度集成不是把流程做成鐵板一塊而是把語義理解能力拆成可組合、可替換、可獨(dú)立擴(kuò)展的服務(wù)單元。這篇文章我想從設(shè)計(jì)思路、選型標(biāo)準(zhǔn)、集成實(shí)操和踩坑經(jīng)驗(yàn)四個(gè)維度聊聊我在這塊積累的一些實(shí)實(shí)在在的經(jīng)驗(yàn)希望能給正在搭NLP系統(tǒng)或者準(zhǔn)備重構(gòu)文本處理鏈路的同學(xué)一些參考。我接觸過的團(tuán)隊(duì)包括我自己手頭維護(hù)的幾個(gè)文本處理系統(tǒng)最終都走過傳統(tǒng)Pipeline規(guī)規(guī)矩矩搭起來線上效果一言難盡被迫推倒重來這條路。原因其實(shí)很簡單業(yè)務(wù)需求是動(dòng)態(tài)的而傳統(tǒng)Pipeline是靜態(tài)的。當(dāng)你要在同一個(gè)系統(tǒng)里同時(shí)處理電商評論的情感分析、法律文書的條款抽取、技術(shù)文檔的術(shù)語識別一條流水線根本撐不住。所以今天聊的內(nèi)容不是要徹底否定Pipeline的價(jià)值而是探討在什么場景下應(yīng)該保留Pipeline的骨架在什么場景下必須拆成組件以及拆完之后怎么把這些組件塞進(jìn)你的業(yè)務(wù)架構(gòu)里讓它們真正跑起來、跑得穩(wěn)。1. 傳統(tǒng)Pipeline模式的天花板在哪里1.1 錯(cuò)誤傳播鏈條上一處崩全線跟著崩傳統(tǒng)NLP Pipeline最核心的結(jié)構(gòu)問題是強(qiáng)順序依賴帶來的錯(cuò)誤傳播。拿中文處理舉例一個(gè)標(biāo)準(zhǔn)Pipeline長這樣先分詞再詞性標(biāo)注再做依存句法分析最后做語義角色標(biāo)注。聽起來邏輯清晰每層都建立在前一層的結(jié)果之上但實(shí)際上每層都會(huì)引入噪聲。分詞階段的一個(gè)微小切分歧義比如研究生命科學(xué)被切成研究生/命科學(xué)詞性標(biāo)注階段就可能會(huì)把研究生標(biāo)成名詞、命標(biāo)成名詞后面的依存句法分析直接開始胡說八道。這個(gè)誤差沿著鏈路越傳越大到最后的語義理解環(huán)節(jié)準(zhǔn)確率已經(jīng)不是逐層相乘而是逐層指數(shù)級衰減。我當(dāng)時(shí)在做一個(gè)面向金融領(lǐng)域公告的事件抽取系統(tǒng)時(shí)體會(huì)尤其深。公告文本里充斥著非常長的機(jī)構(gòu)名、產(chǎn)品名、縮略語傳統(tǒng)Pipeline里第一層分詞詞典維護(hù)就占了團(tuán)隊(duì)三分之一的人力。每次新公告出現(xiàn)一個(gè)沒見過的產(chǎn)品簡稱分詞就要錯(cuò)一次后面所有環(huán)節(jié)全部重來。你沒法只修后面那一環(huán)因?yàn)闆]有中間表示可以繞過。這就是Pipeline最根本的局限中間結(jié)果不可驗(yàn)證、不可替換、耦合太深。1.2 特征工程的隱性成本與泛化困境傳統(tǒng)Pipeline的另一個(gè)隱形殺手是特征工程。詞性標(biāo)注要定義特征模板NER要設(shè)計(jì)詞邊界特征、上下文特征、詞典特征每個(gè)環(huán)節(jié)特征工程都是獨(dú)立的項(xiàng)目。換一個(gè)領(lǐng)域特征基本作廢。我見過有個(gè)團(tuán)隊(duì)做了一個(gè)面向醫(yī)療文本的實(shí)體識別組件特征模板里塞了幾十條基于詞形和位置的特征規(guī)則在病歷數(shù)據(jù)上F1能到88%換到影像報(bào)告文本F1直接崩到67%。原因很簡單特征模板是手工設(shè)計(jì)的它捕捉的是設(shè)計(jì)者對某一類文本的先驗(yàn)假設(shè)換文本分布等于推翻假設(shè)。這種問題的根源在于傳統(tǒng)Pipeline把知識表達(dá)優(yōu)雅地分散到了每個(gè)環(huán)節(jié)的特征工程里導(dǎo)致整個(gè)系統(tǒng)極度依賴人工先驗(yàn)。業(yè)務(wù)方不會(huì)因?yàn)槟愕姆衷~器換了一個(gè)領(lǐng)域就允許你重構(gòu)整個(gè)Pipeline但線上的badcase又實(shí)實(shí)在在催著你改。最后團(tuán)隊(duì)陷入一個(gè)死循環(huán)改特征、調(diào)參數(shù)、等效果、發(fā)現(xiàn)別的環(huán)節(jié)又崩了、再改回去。1.3 傳統(tǒng)Pipeline適合什么場景說了這么多問題也不是要全盤否定。傳統(tǒng)Pipeline在三種場景下依然有其合理性一是計(jì)算資源極度受限的嵌入式環(huán)境二是要求每個(gè)環(huán)節(jié)可解釋、每個(gè)輸出可審計(jì)的合規(guī)場景三是業(yè)務(wù)輸入高度標(biāo)準(zhǔn)化、領(lǐng)域邊界極其清晰的情況。比如銀行客服工單的自動(dòng)分類字段基本固定文本長度和格式高度規(guī)整詞法分析和規(guī)則匹配組成的Pipeline完全夠用而且出問題好查。但如果你的業(yè)務(wù)文本是互聯(lián)網(wǎng)級別的多樣性那傳統(tǒng)Pipeline會(huì)拖垮整個(gè)迭代速度。2. 現(xiàn)代NLP組件的核心設(shè)計(jì)思路2.1 從流程鏈到能力原子組件化的本質(zhì)轉(zhuǎn)變現(xiàn)代NLP組件化設(shè)計(jì)的核心轉(zhuǎn)變是把流程降格為能力。傳統(tǒng)Pipeline強(qiáng)調(diào)的是順序現(xiàn)代組件強(qiáng)調(diào)的則是接口契約。一個(gè)NLP組件本質(zhì)是一個(gè)能接收文本輸入、產(chǎn)出特定語義產(chǎn)物的能力原子。比如情感分析組件輸入是一段評論輸出是情感極性、情感強(qiáng)度、情感對象三元組文本分類組件輸入是一段文本輸出是類別標(biāo)簽和置信度。組件之間不存在必須誰先誰后的關(guān)系只存在業(yè)務(wù)方需要什么能力的對應(yīng)關(guān)系。我在設(shè)計(jì)組件接口時(shí)習(xí)慣把輸入輸出統(tǒng)一成一種自描述的語義結(jié)構(gòu)類似這樣{ text: 原始文本內(nèi)容, lang: zh, metadata: { domain: ecommerce, scene: review, request_id: uuid } }輸出統(tǒng)一成{ results: [ { type: sentiment, value: negative, confidence: 0.93, start: 12, end: 28 } ], latency_ms: 128, model_version: roberta-base-sentiment-2024.03 }這種統(tǒng)一契約最直觀的好處是業(yè)務(wù)方不需要關(guān)心這個(gè)組件內(nèi)部是傳統(tǒng)規(guī)則、傳統(tǒng)模型還是大模型它暴露出來的能力簽名是穩(wěn)定的。你換內(nèi)部實(shí)現(xiàn)只要輸出契約不變對上游就是透明替換。我后來所有NLP組件的設(shè)計(jì)都循著這個(gè)思路換模型、換算法上游業(yè)務(wù)系統(tǒng)幾乎不用改代碼。2.2 無狀態(tài)設(shè)計(jì)與語義版本管理組件化的地基組件化的第二個(gè)關(guān)鍵設(shè)計(jì)原則是服務(wù)無狀態(tài)。NLP組件應(yīng)該像函數(shù)一樣給定輸入返回輸出不保存任何與調(diào)用方相關(guān)的狀態(tài)。我自己在早期踩過坑做一個(gè)文本分類組件時(shí)為了效率把部分中間結(jié)果緩存在組件內(nèi)部Map里結(jié)果多線程環(huán)境下頻繁出現(xiàn)臟數(shù)據(jù)。后來徹底重構(gòu)為無狀態(tài)服務(wù)所有上下文都由調(diào)用方在metadata里傳遞。無狀態(tài)不僅解決了并發(fā)一致性問題更讓組件的水平擴(kuò)展變得極其簡單這也是后續(xù)服務(wù)編排的基礎(chǔ)。版本管理是另一個(gè)值得認(rèn)真對待的問題。NLP模型不像普通軟件語義效果沒有絕對的對錯(cuò)只有好壞。你優(yōu)化了某個(gè)領(lǐng)域的準(zhǔn)確率可能另一個(gè)領(lǐng)域的泛化能力就下降了。所以我給每個(gè)組件設(shè)計(jì)了一套獨(dú)立的版本管理機(jī)制包括四層版本算法版本、模型版本、切詞表版本、規(guī)則庫版本。線上調(diào)用統(tǒng)一攜帶組件版本簽名出了問題可以一鍵回滾到某個(gè)組合。2.3 組件內(nèi)部結(jié)構(gòu)意圖層、算法層與適配層現(xiàn)代NLP組件內(nèi)部我習(xí)慣劃分為三層結(jié)構(gòu)。最上層是意圖層負(fù)責(zé)理解調(diào)用方傳進(jìn)來的場景信息決定當(dāng)前應(yīng)該走哪條處理路徑。中間是算法層承載真正干活的模型或規(guī)則集合。最底層是適配層負(fù)責(zé)把算法層的輸出標(biāo)準(zhǔn)化成統(tǒng)一的語義結(jié)構(gòu)。以我的一個(gè)中文文本分類組件為例它的請求里metadata攜帶domain: ecommerce, scene: comment意圖層直接選定電商評論分類模型不帶這個(gè)字段時(shí)意圖層走一個(gè)泛化分類模型。同一個(gè)組件對外能力不變對內(nèi)能根據(jù)場景靈活切換算法路徑。這種內(nèi)部三層結(jié)構(gòu)讓組件既能標(biāo)準(zhǔn)化對外又保留了對復(fù)雜場景的適配彈性。業(yè)務(wù)方不需要理解你內(nèi)部怎么切模型只需要知道這個(gè)組件能處理它的問題。3. 組件選型不同場景下的取舍方法論3.1 選型核心維度精度、延遲、成本、可維護(hù)性NLP組件選型市面上開源和商業(yè)方案五花八門看花眼很正常。我的經(jīng)驗(yàn)是抓住四個(gè)核心維度去對比不要被花哨的技術(shù)名詞帶偏。第一個(gè)維度是精度與效果。這是最容易量化的部分用標(biāo)桿數(shù)據(jù)集跑測試、算F1、算召回率就行。但要注意一個(gè)坑公開數(shù)據(jù)集的分?jǐn)?shù)和你線上真實(shí)場景的分?jǐn)?shù)可能差距巨大。我習(xí)慣在調(diào)研團(tuán)隊(duì)自己積累的1000條真實(shí)業(yè)務(wù)樣本上做盲測讓標(biāo)注人員不看模型歸屬只打分。第二個(gè)維度是延遲與吞吐。尤其對在線NLP組件p99延遲比平均延遲更重要。模塊加載時(shí)間、GPU推理耗時(shí)、批處理策略都會(huì)影響真實(shí)體驗(yàn)。第三個(gè)維度是成本與資源。不單是GPU卡的成本還有運(yùn)維成本、人力成本。有些模型精度高一個(gè)點(diǎn)但要專卡服務(wù)運(yùn)維復(fù)雜度翻倍我通常會(huì)建議將這個(gè)一個(gè)點(diǎn)放到業(yè)務(wù)綜合收益里去評估。第四個(gè)維度是可維護(hù)性。模型能不支持二次增量訓(xùn)練、有沒有實(shí)用的評估工具、社區(qū)的穩(wěn)定性如何直接決定以后迭代時(shí)你們團(tuán)隊(duì)是輕松還是痛苦。3.2 場景化選型策略不同任務(wù)不同打法按任務(wù)場景來拆選型策略會(huì)更清楚。文本分類任務(wù)如果你的類別體系明確、數(shù)據(jù)量幾萬條級別一個(gè)輕量級預(yù)訓(xùn)練語言模型加微調(diào)是性價(jià)比之王不需要上超大模型。但如果分類任務(wù)涉及大量語義重疊、情感傾向微妙則需要更大規(guī)模的模型來兜底。命名實(shí)體識別任務(wù)我的建議是優(yōu)先考慮序列標(biāo)注框架并與領(lǐng)域詞典做兩層融合。純模型抽取在規(guī)范文本上效果尚可在口語化、非正式文本上置信度非常不穩(wěn)定。我做的某個(gè)知識庫實(shí)體抽取組件最終線上方案是模型粗抽加詞典精篩加規(guī)則糾偏的組合把實(shí)體邊界的F1從原來單純模型的79%提升到了92%。這個(gè)提升完全來自組件內(nèi)部結(jié)構(gòu)設(shè)計(jì)而不是單純換模型。語義相似度或檢索場景選型思路會(huì)更不一樣。關(guān)鍵在于Embedding模型的選擇與向量檢索的配合。這個(gè)場景下不太看F1更看重檢索相關(guān)性和召回分布的合理性。我做的企業(yè)知識庫問答系統(tǒng)先走向量召回粗排再做重排粗排用通用Embedding模型重排用一個(gè)針對性訓(xùn)練的交互式模型線上效果比只用單一模型好很多。粗排保證查詢和相似度基本方向不偏重排把信息量相近的候選內(nèi)容精排到頭部。3.3 開源、商業(yè)與自研的三方權(quán)衡到底用開源、買商業(yè)API還是自研這個(gè)決策不能一概而論要看你們團(tuán)隊(duì)的核心競爭力在哪里。如果NLP不是公司的核心壁壘那直接買成熟的商業(yè)API往往更劃算省掉從數(shù)據(jù)標(biāo)注到模型迭代一整套成本。如果NLP能力本身就是產(chǎn)品的核心賣點(diǎn)數(shù)據(jù)是你的資產(chǎn)那必須有自研能力至少在關(guān)鍵組件上要能自己訓(xùn)練、自己調(diào)優(yōu)。開源方案則通常是一個(gè)折中適合起步階段驗(yàn)證想法也要對后續(xù)運(yùn)維成本有預(yù)期。我的判斷標(biāo)準(zhǔn)就一條你能不能承受這個(gè)組件黑盒化帶來的業(yè)務(wù)風(fēng)險(xiǎn)。能承受就買現(xiàn)成不能承受就自己掌握核心組件。這句話說起來簡單但真正執(zhí)行時(shí)很多團(tuán)隊(duì)容易搖擺最后搞出既有商業(yè)API又自研的混亂架構(gòu)。4. 深度集成把組件真正塞進(jìn)業(yè)務(wù)系統(tǒng)4.1 組件編排的三種主流模式選型完了就是集成這是最折騰人的階段。組件和服務(wù)完全不是一回事組件是能力單元服務(wù)是部署形態(tài)。集成方案本質(zhì)上是回答一個(gè)問題多個(gè)組件之間如何協(xié)同如何對外提供穩(wěn)定高效的語義服務(wù)。目前我實(shí)踐下來比較成熟的編排模式有三種。第一種是同步調(diào)用鏈編排適用于組件之間強(qiáng)依賴、需要實(shí)時(shí)返回最終結(jié)果的場景。比如搜索引擎里的相關(guān)性計(jì)算需要實(shí)體識別結(jié)果做特征輸入隨即就走重排模型一條同步鏈路串下來。這種模式簡單直接但鏈路任一環(huán)節(jié)出問題會(huì)導(dǎo)致整個(gè)請求失敗所以每個(gè)環(huán)節(jié)必須有超時(shí)控制和降級預(yù)案。第二種是異步消息流編排適用于組件之間低耦合、允許一定延遲的場景。比如一個(gè)工單系統(tǒng)新工單進(jìn)來生產(chǎn)一條語義理解任務(wù)推到消息隊(duì)列下游多個(gè)組件并發(fā)處理各自把語義標(biāo)注結(jié)果寫回?cái)?shù)據(jù)存儲。這種模式削峰填谷效果好系統(tǒng)穩(wěn)定性高但要注意最終一致性問題。第三種是混合編排同步與異步混用。我在一個(gè)電商內(nèi)容審核系統(tǒng)里就是混合編排先同步調(diào)用一個(gè)粗分類組件判斷是否需要深度審核需要的話再丟進(jìn)異步隊(duì)列做細(xì)粒度情感和風(fēng)險(xiǎn)檢測。這個(gè)設(shè)計(jì)省了約40%的計(jì)算成本因?yàn)榇罅空?nèi)容根本不會(huì)觸發(fā)深度分析。4.2 讓組件跑得穩(wěn)的工程化要點(diǎn)集成過程中有幾個(gè)工程細(xì)節(jié)值得多說兩句。一個(gè)是模型加載與預(yù)熱。我見過太多系統(tǒng)的冷啟動(dòng)失敗模型服務(wù)沒預(yù)熱就接流量第一波請求全部超時(shí)。所以我在模型服務(wù)啟動(dòng)腳本里強(qiáng)制加了一個(gè)預(yù)熱階段啟動(dòng)后用一批真實(shí)業(yè)務(wù)請求先跑一遍確認(rèn)狀態(tài)碼和延遲指標(biāo)正常后才注冊到服務(wù)發(fā)現(xiàn)中心。另一個(gè)是批處理與延遲的博弈?，F(xiàn)代NLP模型很多都支持動(dòng)態(tài)批處理吞吐能提好幾倍但也會(huì)引入額外的等待時(shí)間。我的經(jīng)驗(yàn)是要給批處理設(shè)置一個(gè)嚴(yán)格的窗口邊界比如最多等50毫秒或積滿32個(gè)請求就立即執(zhí)行兩方面保證延遲峰值可預(yù)期吞吐又不至于太拉胯。緩存策略也是集成時(shí)的重頭戲。文本語義結(jié)果在不少業(yè)務(wù)里是高度可復(fù)用的同一個(gè)用戶反復(fù)查詢同一個(gè)知識點(diǎn)相似評論反復(fù)出現(xiàn)。我用一個(gè)語義緩存層以文本內(nèi)容的歸一化哈希為鍵緩存分析結(jié)果配合合理的過期時(shí)間。實(shí)測在高頻問答場景下緩存命中率能到35%左右有效削掉了底層模型服務(wù)三成以上的壓力。4.3 模型服務(wù)與業(yè)務(wù)系統(tǒng)之間的接口形態(tài)設(shè)計(jì)模型服務(wù)對外提供的接口形態(tài)直接決定集成難度。我的建議是業(yè)務(wù)系統(tǒng)側(cè)使用統(tǒng)一的RESTful接口通過gRPC做內(nèi)部服務(wù)間通信這個(gè)組合成熟也能打。高并發(fā)或?qū)π阅軜O致敏感的場景再考慮全鏈路gRPC。接口設(shè)計(jì)上每個(gè)接口都要能傳遞trace_id方便全鏈路追蹤。響應(yīng)體里必須攜帶model_version和latency_ms這兩項(xiàng)對問題歸因和灰度比對太重要了。還有一個(gè)容易忽略的地方錯(cuò)誤碼設(shè)計(jì)。模型服務(wù)返回的錯(cuò)誤碼不能只給500一個(gè)粗糙的返回要細(xì)分是輸入格式錯(cuò)誤、是模型推理超時(shí)、是依賴的后置規(guī)則庫不可用。錯(cuò)誤信息要足夠具體方便下游系統(tǒng)做不同的容錯(cuò)策略。我在一個(gè)多語言文本分析系統(tǒng)里就是因?yàn)殄e(cuò)誤碼設(shè)計(jì)清晰排查線上問題的時(shí)間從小時(shí)級直接降到了分鐘級。4.4 灰度發(fā)布與效果回歸集成后的持續(xù)守衛(wèi)模型組件集成上線后灰度發(fā)布機(jī)制直接決定你們迭代模型的膽子能有多大。我給組件灰度發(fā)布設(shè)定了一套固定流程先在離線評測集上跑差異對比用與線上相同路徑的離線版評測確認(rèn)候選模型沒有明顯回退然后小流量灰度一般控制在5%請求量持續(xù)觀察核心指標(biāo)再逐步放量到30%、80%、全量。全量后依然保留一段觀察期確保p99延遲、錯(cuò)誤率、badcase比例都在預(yù)期內(nèi)。效果回歸方面我會(huì)在組件上線時(shí)自動(dòng)搭建一個(gè)回歸任務(wù)每天固定拉取線上歷史的1000條樣本重新跑一遍組件將當(dāng)天的效果指標(biāo)與基線版本對比任何一項(xiàng)指標(biāo)下降超過閾值自動(dòng)觸發(fā)告警。這套機(jī)制幫我攔截過好幾次因?yàn)橛?xùn)練數(shù)據(jù)偏差導(dǎo)致的隱性回退沒有它問題很可能在線上跑一兩周才被用戶發(fā)現(xiàn)。5. 常見問題與排查技巧實(shí)錄5.1 多語言與混合文本的血淚教訓(xùn)NLP組件落地時(shí)文本編碼和語言處理是最容易翻車的隱形問題。我做過一個(gè)面向跨境電商評論分析的引擎上線后經(jīng)常出現(xiàn)英文夾雜中文的評論情感判斷全偏。查了半天發(fā)現(xiàn)組件內(nèi)部的切詞器對中英混合文本的分詞處理存在嚴(yán)重的上下文丟失問題英文上下文和中文上下文切完以后各歸各語義信息完全沒有融合。這個(gè)問題如果只是看單一語言測試集根本不會(huì)暴露。我的解決思路是加一道語言歸并預(yù)處理層。在組件入口對文本做一個(gè)語言片段識別判斷每一個(gè)子區(qū)間的語言類型中文部分和英文部分分別做對應(yīng)的標(biāo)準(zhǔn)化處理后再送入語義模型。這聽起來簡單但對整體準(zhǔn)確率的提升非常大。踩過這類坑之后我所有的文本組件都會(huì)默認(rèn)加入一個(gè)文本清洗與語言識別前置檢查寧可稍微增加一點(diǎn)延遲也不讓臟文本污染后面的語義模型。5.2 長文本截?cái)嗯c信息丟失矛盾預(yù)訓(xùn)練語言模型通常有輸入長度限制這個(gè)限制和業(yè)務(wù)長文檔之間的沖突幾乎每個(gè)做NLP組件的團(tuán)隊(duì)都遇到過。單純把超長文本從頭到512字截?cái)喾浅：唵未直┑殃P(guān)鍵信息直接切掉。尤其是法律合同類文檔條款編號經(jīng)常出現(xiàn)在中后段截?cái)嘀蟪槿∧Ｐ洼敵龅慕Y(jié)果往往是殘缺的。我實(shí)踐出的有效方案是語義分塊分塊加權(quán)。把長文檔按句段邊界切成若干個(gè)語義完整的塊每個(gè)塊獨(dú)立過模型得到結(jié)果然后再根據(jù)塊的位置權(quán)重和塊內(nèi)的置信度做一個(gè)加權(quán)融合。比如一個(gè)文檔里同一個(gè)實(shí)體出現(xiàn)在三個(gè)塊置信度分別是0.6、0.9、0.7最終輸出取0.9并附帶位置信息。這個(gè)方法比頭部截?cái)嘈Ч€(wěn)定得多代價(jià)是要多做幾次模型調(diào)用但換取的信息完整性價(jià)值非常高。5.3 組件并發(fā)導(dǎo)致的隱性GD歸零或內(nèi)存泄漏模型服務(wù)跑久了內(nèi)存漸漸漲高是NLP組件運(yùn)維里的一個(gè)老大難問題。我排查過一個(gè)線上不斷重啟的文本分類服務(wù)表面現(xiàn)象是用量一來就內(nèi)存告警重啟完又好轉(zhuǎn)。一開始以為是并發(fā)太高打滿資源后來深挖發(fā)現(xiàn)是某一段代碼在循環(huán)里不斷創(chuàng)建張量計(jì)算圖但又沒有徹底釋放引用導(dǎo)致內(nèi)存以肉眼可見的速度爬坡。排查這類問題最有效的辦法是把日志里內(nèi)存趨勢和推理請求量畫成曲線對照分析問題定位就快很多。這類問題也提醒我模型服務(wù)側(cè)必須有一套自監(jiān)控進(jìn)程內(nèi)存、GPU顯存使用率、單次推理耗時(shí)、批處理隊(duì)列長度。任何一個(gè)指標(biāo)異常趨勢持續(xù)超過閾值服務(wù)就應(yīng)該有自動(dòng)摘除與重啟的能力而不是等到整個(gè)節(jié)點(diǎn)完全OOM掛掉。組件的能力再強(qiáng)跑不穩(wěn)就等于沒有能力。5.4 組件版本混亂與結(jié)果不可復(fù)現(xiàn)另一個(gè)高頻問題是組件迭代一段時(shí)間后線上結(jié)果開始不可復(fù)現(xiàn)。同一條文本今天調(diào)用和上周調(diào)用返回的結(jié)果完全不一樣但代碼沒改。查到最后八成是模型版本被悄悄更新過或者是組件依賴的規(guī)則庫臨時(shí)表、外部詞典被動(dòng)過。以我的經(jīng)驗(yàn)組件生產(chǎn)環(huán)境必須鎖定版本任何組件升級必須走灰度流程不能有人在服務(wù)器上直接更新內(nèi)容。每個(gè)組件的接口都要返回完整版本簽名每次線上結(jié)果異常排查首先核對版本簽名再談別的。這習(xí)慣養(yǎng)成了能讓團(tuán)隊(duì)少走特別多彎路。6. 實(shí)操心得與后續(xù)擴(kuò)展踩著這些坑一路走過來我最大的體會(huì)是NLP組件化不是把模型打成服務(wù)就完事。真正決定一個(gè)NLP系統(tǒng)能否長期轉(zhuǎn)起來的關(guān)鍵是組件設(shè)計(jì)時(shí)有沒有考慮接口契約、版本管理、可觀測性、故障隔離這些工程要素。很多團(tuán)隊(duì)技術(shù)上選的模型都是一流的但敗在工程化不夠細(xì)一個(gè)小小的問題就要花一個(gè)通宵去查。最后再分享一個(gè)我現(xiàn)在一定會(huì)做的事為每個(gè)NLP組件維護(hù)一份能力說明書。它會(huì)持續(xù)記錄這個(gè)組件到底服務(wù)哪些業(yè)務(wù)場景、效果指標(biāo)是多少、換過哪幾次版本、每一版的區(qū)別是什么、線上有多少調(diào)用方在依賴它。這份說明書不僅是給新同事的交接文檔更是你迭代模型時(shí)評估影響范圍的最可靠依據(jù)。做組件選型和深度集成之前先花時(shí)間把這份說明書做扎實(shí)后面所有的判斷都不會(huì)跑偏。