1. 為什么大模型后端比傳統(tǒng)后端更“怕黑”先聊一個我在多個項目里反復遇到的場景線上的大模型服務突然響應變慢了從原來的1.2秒漲到4秒。傳統(tǒng)后端排查查接口日志、看數(shù)據(jù)庫慢查詢、盯CPU和內(nèi)存基本能定位。但到了大模型這條鏈路事情變得棘手——你打開日志看到的是一大段提示詞、一大段流式輸出token沒有SQL沒有Redis有的是一個HTTP調(diào)用外部推理服務的耗時記錄和一堆看似“正?！钡笜水惓５那€。你不知道是模型服務端出了問題、prompt被業(yè)務側(cè)改壞了、還是并發(fā)把某個中間環(huán)節(jié)壓垮了。這時候靠傳統(tǒng)的那套“日志里撈關鍵字”的玩法基本是寸步難行。這也是我在做大模型后端工程化時最強烈的體會大模型后端不是“多了一個外部API調(diào)用”那么簡單它更像是把一個高度不確定、高成本、高延遲的第三方組件硬塞進了你原本確定性的系統(tǒng)里。日志體系與可觀測性在這個背景下不再是一個運維輔助工具而是整個系統(tǒng)能不能穩(wěn)定迭代的基礎設施。這篇文章我想完整復盤一下我在大模型后端工程中落地日志體系與可觀測性的全過程——從架構(gòu)設計、埋點規(guī)范、全鏈路Trace到成本監(jiān)控、質(zhì)量畫像、告警規(guī)則再到踩過的坑和排查實錄。內(nèi)容偏向工程落地適合正在做大模型應用后端、或者想把現(xiàn)有服務可觀測性補齊的開發(fā)者參考。2. 可觀測性的整體設計與拆解思路2.1 大模型后端到底需要觀測什么傳統(tǒng)后端可觀測性講“三支柱”——日志、指標、鏈路追蹤。大模型后端不是推翻這套體系而是在此之上增加了四個大模型特有的觀測維度。第一個是成本維度。大模型按Token計費一次普通對話可能只有幾分錢但一個批量任務、一個Agent多輪調(diào)用鏈可能一次就消耗幾百萬Token。成本從“賬單上的一個數(shù)字”變成了“每一次請求都會產(chǎn)生的實時消耗”必須在單個請求粒度就能回答“這單花了多少錢”。第二個是質(zhì)量維度。傳統(tǒng)接口返回的是結(jié)構(gòu)化數(shù)據(jù)對錯明確。大模型返回的是文本沒有絕對的“對錯”。同一套prompt在不同模型版本、不同參數(shù)配置下輸出可能忽好忽壞。必須有一套針對生成內(nèi)容的觀測手段比如響應長度分布、拒絕回答比例、關鍵詞命中率、語義相似度漂移等。第三個是行為漂移維度。大模型服務的“系統(tǒng)狀態(tài)”不只有CPU、內(nèi)存這類硬件指標還包括“模型行為狀態(tài)”——同一段prompt這周和上周的輸出分布是否一致。模型版本升級、prompt模板調(diào)整、上下文策略改動都可能導致線上行為悄悄變化。這類變化不靠日志是發(fā)現(xiàn)不了的。第四個是鏈路串聯(lián)維度。一個典型的大模型后端請求往往要經(jīng)過網(wǎng)關鑒權(quán)、檢索增強、上下文組裝、模型調(diào)用、結(jié)果后處理、流式回推等多個階段。任何一個環(huán)節(jié)出問題都會表現(xiàn)為“用戶覺得變慢了”但具體是哪個環(huán)節(jié)必須靠全鏈路Trace才能回答。這四個維度決定了我們需要的不僅是“日志收集系統(tǒng)”而是一套以請求為圓心、把成本、質(zhì)量、時延、鏈路全部串起來的觀測體系。2.2 日志、指標、Trace在大模型場景的分工三支柱在大模型場景下各有側(cè)重我實際落地時是這樣劃分的日志負責“發(fā)生了什么”。每一筆請求的完整生命周期包括入?yún)⒄z索結(jié)果數(shù)量、組裝后的prompt長度、模型返回的token數(shù)、流式傳輸?shù)暮臅r、錯誤碼、重試次數(shù)。日志是事后回溯的基礎要求全量記錄、結(jié)構(gòu)化輸出、可檢索。指標負責“現(xiàn)在怎么樣”。以固定時間窗口聚合出來的數(shù)字包括QPS、平均首Token延遲、P95/P99整體延遲、Token吞吐量、成本消耗速率、緩存命中率、錯誤率。指標用于實時監(jiān)控和告警不需要全量但要實時、要穩(wěn)定。Trace負責“慢在哪里”。一次請求從進入到返回經(jīng)過的每個子階段耗時拆解。傳統(tǒng)Trace可以精確到毫秒級大模型場景還需要額外記錄ttft首Token生成時間、推理耗時、傳輸耗時這幾個關鍵階段因為它們對用戶體驗的影響完全不一樣。這里有一個容易犯的錯誤很多人上來就想上一套全量日志全量Trace結(jié)果就是存儲成本爆炸、查詢變慢、鏈路采樣率過低導致失去參考價值。我的建議是分層處理——日志全量但精簡字段Trace按請求采樣比如默認10%慢請求100%采樣指標全量實時聚合。三者的數(shù)據(jù)量級差別很大不要用一套方案硬套。2.3 技術選型背后的考量大模型后端可觀測性在選型上我見過不少團隊被“新概念”帶偏去自研一套大模型監(jiān)控平臺。其實大可不必。存量的開源生態(tài)完全夠用而且穩(wěn)定性有保障。日志存儲方面核心需求是全文檢索和快速過濾尤其是能對prompt內(nèi)容做關鍵詞查詢。我采用的是業(yè)界主流的“日志采集器分布式搜索引擎”組合業(yè)務側(cè)通過日志SDK異步上報結(jié)構(gòu)化JSON采集端做簡單的字段解析和清洗寫入分布式搜索引擎配合監(jiān)控可視化平臺做查詢分析。指標鏈路用的是主流的時序數(shù)據(jù)庫采集器組合重點放在自定義業(yè)務指標的埋點上也就是上一節(jié)說的成本、延遲、Token消耗這類指標。鏈路追蹤選型上我建議直接采用開源的標準鏈路協(xié)議配合兼容該協(xié)議的采集端和存儲端這樣未來無論是切換模型供應商、還是接入云廠商托管的可觀測服務遷移成本都可控。選型的一個核心原則是不要為了大模型單獨造輪子。大模型的可觀測性難點不在采集和存儲而在“埋什么點”和“怎么關聯(lián)”這些屬于業(yè)務層的設計工具解決不了。3. 核心細節(jié)解析與埋點規(guī)范3.1 統(tǒng)一TraceId與請求生命周期我踩過的第一個坑就是日志之間串不起來。大模型后端通常不是單服務而是API網(wǎng)關、業(yè)務服務、檢索服務、模型網(wǎng)關多層結(jié)構(gòu)甚至同一個請求會經(jīng)過多個微服務。如果沒有統(tǒng)一的請求ID排查問題基本靠猜。解決方案是在網(wǎng)關層生成統(tǒng)一TraceId通過HTTP頭向下游傳遞所有日志框架自動攜帶這個ID。大模型相關的日志事件統(tǒng)一繼承同一個TraceId確保從用戶請求進入到最終流式響應結(jié)束所有日志都能按一個ID拉出來。流式響應尤其需要注意——大模型是邊生成邊返回的一個請求會產(chǎn)生多次chunk寫操作每個chunk的日志都必須帶同一個TraceId否則排查“流到一半斷了”的問題時日志根本對不上。我的埋點規(guī)范里有幾條硬性要求所有外部調(diào)用必須記錄調(diào)用目標、請求大小、響應大小、耗時、重試次數(shù)、錯誤信息。所有日志必須是結(jié)構(gòu)化JSON禁止在業(yè)務代碼里拼字符串日志。關鍵路徑上的日志必須帶BatchId、UserId、TraceId三個關聯(lián)字段缺一不可。日志級別按場景嚴格區(qū)分DEBUG用于聯(lián)調(diào)INFO記錄請求摘要WARN記錄可降級場景ERROR記錄真正的異常。3.2 提示詞結(jié)構(gòu)與響應元數(shù)據(jù)的記錄規(guī)范大模型日志里最容易失控的就是內(nèi)容字段——如果你把完整prompt和完整響應都塞進日志存儲成本會迅速壓垮整個日志系統(tǒng)。但如果不記錄內(nèi)容出了問題又無從分析。這里需要有取舍地記錄。我的做法是把日志內(nèi)容拆成“元數(shù)據(jù)”和“內(nèi)容摘要”兩層。元數(shù)據(jù)全量記錄模型名稱、模型版本、temperature、max_tokens、top_p等參數(shù)以及Token輸入數(shù)、Token輸出數(shù)、耗時、緩存命中與否。內(nèi)容摘要層則分場景常規(guī)業(yè)務請求記錄prompt的模板ID、模板版本號以及渲染后的prompt截斷前500個字符。響應記錄截斷前300個字符。異常與失敗請求完整記錄prompt和響應。因為這是排查問題的核心證據(jù)不能省?；叶扰c實驗請求按實驗組ID全量記錄用于后續(xù)質(zhì)量分析。涉及隱私或敏感業(yè)務的請求內(nèi)容字段直接脫敏只記錄處理后的特征值。這套規(guī)范落地后日志量大約能壓掉70%同時保留了絕大多數(shù)排查場景需要的證據(jù)。另外要強推一個細節(jié)記錄prompt模板ID和版本號。大模型應用里prompt是會頻繁迭代的同一份prompt今天改了個詞明天可能就多了一批重新生成的需求。如果日志里只有prompt內(nèi)容沒有版本號線上出問題想回滾對比會非常痛苦。我們后來把prompt管理做成了獨立的配置中心每次變更自動生成版本號日志埋點里帶上這個版本號這波操作在后面排查質(zhì)量問題時幫了大忙。3.3 Token計算的三種口徑Token是成本和質(zhì)量觀測的核心單位但它的統(tǒng)計口徑很容易出問題。我遇到過不止一次日志里記錄的Token消耗總和和模型服務商賬單上的數(shù)字對不上差了20%以上。這不是模型服務商亂扣費而是我們統(tǒng)計口徑有問題。實際落地中Token統(tǒng)計至少有三種口徑第一種是計費口徑。模型服務商賬單上的Token數(shù)包含輸入Token、輸出Token、緩存Token、特殊字符拆分規(guī)則等這是你實際要付的錢。這個口徑必須從模型服務商的響應報文里拿不能自己數(shù)。第二種是應用口徑。業(yè)務代碼里通過官方SDK拿到的usage信息用于實時成本展示和配額控制。這個口徑同樣來自模型響應但要注意不同SDK對usage的解析方式不同有些SDK默認不返回usage需要顯式開啟參數(shù)。第三種是自算口徑。本地用分詞器對輸入的prompt和輸出的文本重新計算Token數(shù)。用于在沒有模型服務商響應的情況下做估算比如日志采樣數(shù)據(jù)的成本推算、prompt超長預判。三種口徑的使用場景一定要分清楚。我在日志埋點里分別用三個字段記錄并在面板上明確標注口徑來源。如果混用輕則成本預估失真重則觸發(fā)錯誤的告警規(guī)則——比如我們曾經(jīng)因為用自算口徑去核對模型賬單導致誤以為模型服務商扣費異常白白折騰了一個星期。3.4 上下文與檢索環(huán)節(jié)的觀測細節(jié)大模型后端很少是“裸模型”直接對外基本都會接知識庫檢索、歷史會話摘要、上下文管理等模塊。這些模塊看似是傳統(tǒng)后端組件但它們直接影響大模型的效果和成本必須納入觀測范圍。檢索環(huán)節(jié)的觀測重點是召回文檔數(shù)、每篇文檔的相關性得分、最終拼接進上下文的文檔數(shù)與Token數(shù)。一個非常典型的線上問題是“prompt被上下文撐爆”——知識庫召回20篇文檔每篇幾千字加上歷史記錄prompt總長超過模型上下文窗口請求直接報錯。如果檢索日志里記錄了拼接后的總Token數(shù)、各部分Token占比這類問題一眼就能看穿。上下文管理模塊的觀測重點是會話歷史的截斷策略實際觸發(fā)了多少次、每次截斷了多少條、截斷后丟失了哪部分信息。大模型應用最隱蔽的質(zhì)量殺手之一就是“歷史太長被悄悄截斷前面的信息丟了用戶還在繼續(xù)追問”。這類問題不會報錯只會表現(xiàn)為回答越來越偏沒有日志記錄截斷行為的話基本無解。4. 實操工程化從埋點到告警的完整鏈路4.1 業(yè)務側(cè)埋點的具體實現(xiàn)埋點這塊我推薦“SDK封裝注解/中間件自動化”的方式盡量避免在每個業(yè)務方法里手寫日志代碼。手寫的壞處不是“累”而是容易漏——大模型后端的日志字段非常多手寫很容易在不同方法里字段命名不一致后面做聚合查詢會非常痛苦。我們最終沉淀的埋點封裝包含這幾個核心組件請求上下文組件負責從HTTP頭或消息隊列消息體里提取TraceId、UserId、業(yè)務場景名并寫入線程上下文。異步線程池場景下必須做上下文透傳否則日志會失去關聯(lián)。模型調(diào)用攔截器統(tǒng)一攔截所有進出模型網(wǎng)關的調(diào)用自動記錄模型名、參數(shù)、輸入Token、輸出Token、耗時、錯誤信息。業(yè)務代碼里只需要寫一次調(diào)用日志自動補齊。流式響應增強組件大模型流式返回比較特殊傳統(tǒng)的“method入口出口記錄耗時”方式統(tǒng)計不準因為首Token可能很快但整體流完可能很久。增強組件會分別記錄連接建立時間、首Token到達時間、流結(jié)束時間三段分別埋點。業(yè)務事件日志API給業(yè)務代碼輸出自定義事件用比如“檢索完成”“上下文截斷”“內(nèi)容安全判定命中”統(tǒng)一JSON格式自動附帶TraceId。這套封裝落地后業(yè)務開發(fā)新增一個模型調(diào)用場景基本不需要額外關注日志代碼觀測能力自動補齊。還有一個細節(jié)日志輸出必須走異步通道。大模型響應動輒幾千Token日志內(nèi)容本來就大如果再同步寫磁盤會對接口時延產(chǎn)生影響。我們統(tǒng)一采用高性能異步日志框架并且配置了獨立的日志隊列和刷盤策略確保日志寫入在高并發(fā)下不會阻塞業(yè)務線程。4.2 全鏈路Trace的采樣與串聯(lián)策略鏈路追蹤的采樣策略我強烈建議針對大模型場景做專門設計不要直接用默認的全量或固定比例采樣。原因是大模型的調(diào)用鏈路有幾個特點一是單次調(diào)用體量大二是外部推理耗時占比高三是并發(fā)模型調(diào)用比如并行跑多個子任務會產(chǎn)生大量同層級Span。如果按默認的“全鏈路10%采樣”等于是隨機丟棄請求——可能剛好把最貴的、最慢的那筆請求丟掉了。我的采樣策略是三層組合默認按請求路徑采樣10%保證常規(guī)流量有數(shù)據(jù)參考。所有慢請求總耗時超過P90閾值的強制100%采樣通過攔截器判斷耗時后主動標記。所有錯誤請求、重試請求、降級請求100%采樣。所有成本超過設定閾值的“大單請求”比如單次消耗超過設定金額100%采樣。這套策略的實質(zhì)是“把采樣資源留給異常和關鍵請求”。效果也是立竿見影——之前排查慢請求經(jīng)常找不到Trace改完之后只要告警通知你“有慢請求”點進去必定有完整鏈路。4.3 指標設計從業(yè)務視角定義監(jiān)控項大模型監(jiān)控面板不能只堆QPS和CPU必須圍繞“業(yè)務可用性”來設計。我實際使用的核心指標分為五組第一組時延指標整體響應時延、首Token時延、推理完成時延、流式傳輸時延。這四者必須分開看。用戶體感主要受首Token時延影響而后端資源消耗主要受推理完成時延影響。我們有一次線上排查發(fā)現(xiàn)整體響應時延P95漲了50%但首Token時延平穩(wěn)最終定位出來是流式傳輸環(huán)節(jié)的網(wǎng)絡問題如果只盯著總時延方向就偏了。第二組成本指標每小時Token消耗總量、輸入/輸出Token比例、單請求平均成本、按業(yè)務場景聚合的成本分布。成本指標的意義不只是算錢更是發(fā)現(xiàn)異常行為——如果某個場景的輸入Token突然暴漲大概率是上下文管理邏輯出了bug比如歷史消息重復拼接。第三組錯誤指標模型調(diào)用錯誤率、超時率、重試率、內(nèi)容安全攔截率。這里要特別注意大模型請求的超時重試和普通接口不一樣重試可能帶來重復扣費所以重試率必須單獨監(jiān)控。第四組緩存指標緩存命中率、緩存節(jié)省成本、緩存回源率。大模型的語義緩存和結(jié)果緩存能大幅降本但這個收益是動態(tài)的需要持續(xù)監(jiān)控命中率來判斷緩存策略是否仍然有效。第五組上下文指標請求平均上下文Token數(shù)、最大上下文Token數(shù)、上下文截斷觸發(fā)率。這組指標直接反映prompt工程側(cè)的穩(wěn)定性上下文Token暴漲通常意味著檢索或歷史管理出了問題。4.4 告警規(guī)則的幾個實戰(zhàn)設計告警規(guī)則是“寧可少而準不可多而廢”。我見過太多團隊第一天上線就配了二十條告警結(jié)果全是噪音最后告警被靜默等于沒配。大模型后端的告警我沉淀了幾個實戰(zhàn)經(jīng)驗。首Token時延必須單獨設置告警閾值?？倳r延波動很常見但首Token時延如果連續(xù)多個周期超過模型供應商的SLO說明模型服務端可能出問題這類告警要直接拉高優(yōu)先級。我們的經(jīng)驗閾值是P95首Token時延超過模型供應商公布值的1.5倍并持續(xù)5分鐘觸發(fā)告警。成本異常要配環(huán)比告警。絕對值告警沒意義不同業(yè)務規(guī)模成本差異太大。我們做的是“每小時成本同比上一小時同場景成本增長超過50%且絕對增量超過設定金額”觸發(fā)告警。這個規(guī)則成功抓到過一次線上事故某個定時任務的循環(huán)條件寫錯模型調(diào)用變成死循環(huán)成本在一個小時內(nèi)翻了四倍。模型錯誤率告警必須分級。5xx類錯誤率超過1%觸發(fā)警告超過5%觸發(fā)緊急但4xx類錯誤要單獨看錯誤碼——上下文超限、內(nèi)容安全攔截這類“業(yè)務錯誤”不是故障卻往往比故障更值得關注。上下文截斷率告警很多人忽略。我建議把它當成一等告警來配。上下文截斷率突然上升往往意味著知識庫召回策略出問題或者用戶行為發(fā)生變化這種問題不告警的話表面看起來一切正常實際用戶體驗已經(jīng)在悄悄下滑了。5. 常見問題與排查思路實錄5.1 一次典型的“響應變慢”排查過程拿一個真實案例來串一下排查思路。某天線上反饋對話響應變慢用戶體感明顯但錯誤率沒有變化。我按這個順序排查第一步看指標面板?？倳r延P95從2秒漲到3.5秒首Token時延P95也從800毫秒漲到2秒說明問題出在“模型首Token返回前”的階段而不是流式傳輸階段。第二步拉全鏈路Trace。篩選慢請求的Trace發(fā)現(xiàn)耗時主要集中在“檢索增強”環(huán)節(jié)該環(huán)節(jié)的Span耗時從平均300毫秒漲到1.5秒。第三步看檢索環(huán)節(jié)日志。發(fā)現(xiàn)召回文檔數(shù)沒有變化但“向量檢索”的耗時異常高。繼續(xù)下鉆看到向量索引服務的CPU已經(jīng)打滿慢查詢語句集中在某個特定知識庫集合上。第四步看該知識庫集合的日志發(fā)現(xiàn)當天有人批量導入了大量新文檔觸發(fā)了向量索引的增量重建任務這個任務和線上檢索搶資源。整個排查過程耗時約40分鐘比傳統(tǒng)后端排障要快得多。關鍵在于指標快速收斂范圍、Trace精確定位環(huán)節(jié)、日志給出根因證據(jù)。三者缺一都得靠猜。5.2 Token統(tǒng)計口徑不一致的排查記錄另一個高頻坑是統(tǒng)計口徑。我們曾遇到某業(yè)務場景報告“今日成本比模型服務商賬單多了30%”差點就要找服務商理論。排查后發(fā)現(xiàn)業(yè)務側(cè)日志統(tǒng)計用的是SDK返回的usage字段但該SDK版本默認不統(tǒng)計緩存命中的Token消耗而模型服務商賬單里緩存命中的Token也是按折扣價計費的兩邊基礎數(shù)據(jù)就差了。加上我們?nèi)罩纠镉袀€字段把“預估Token”和“計費Token”混在一起算乘上單價后誤差被放大。最后統(tǒng)一了統(tǒng)計鏈路所有成本計算必須從模型服務商官方賬單接口拉每日明細日志側(cè)只做實時展示不用于對賬。同時把SDK升級到支持完整usage返回的版本在埋點里區(qū)分prompt_tokens、completion_tokens、cached_tokens三個字段。現(xiàn)在兩邊誤差控制在1%以內(nèi)對賬基本無感。5.3 日志體量失控與采樣策略調(diào)整全量日志上線不到兩周搜索引擎存儲集群的磁盤消耗就比預估快了一倍。定位后發(fā)現(xiàn)大模型流式輸出的每個chunk都被打了一條日志一個千Token響應產(chǎn)生了上百條日志記錄單請求日志量膨脹到幾十KB。這是大模型日志最常見的失控場景。后來的整改方案是流式傳輸過程只記錄聚合摘要不再逐chunk輸出日志。具體做法是在流結(jié)束或異常中斷時一次性輸出該請求的總傳輸Token數(shù)、傳輸耗時、中斷位置。如果確實需要逐chunk調(diào)試單獨開DEBUG級別按TraceId過濾生產(chǎn)環(huán)境默認關閉。另外做了分級存儲策略最近7天的全量日志保留在熱存儲支持秒級查詢7天到30天的轉(zhuǎn)冷存儲30天以上的自動清理只保留聚合指標。成本直接降了一個量級查詢速度反而更快了。5.4 超時重試導致重復扣費的隱藏事故還有一次事故讓我印象深刻。業(yè)務方反饋某個批處理任務成本異常高查日志發(fā)現(xiàn)大量請求都走了“超時-重試”路徑。進一步分析模型網(wǎng)關配置的超時時間是30秒但那個批處理任務使用的模型推理本身就比較慢P95耗時已經(jīng)達到35秒。結(jié)果就是大量請求第一次調(diào)用30秒超時重試又花了35秒成功單次邏輯操作產(chǎn)生了兩次模型調(diào)用、雙倍成本。這個問題的根本原因是超時配置和模型能力不匹配但可觀測性在這里的價值是它讓“重試率”這個指標浮出水面。如果沒有重試率監(jiān)控這筆成本會成為一筆糊涂賬。我們隨后為不同模型型號配置了差異化的超時時間并給重試行為增加了告警——單場景重試率超過5%直接通知。6. 在日志體系落地過程中的幾點經(jīng)驗心得做完整套體系后我最大的體會是大模型后端可觀測性70%是設計問題20%是埋點問題只有10%是工具問題。很多團隊一上來就搭監(jiān)控平臺、接告警通道結(jié)果因為埋點字段不規(guī)范、Trace鏈路不完整、指標口徑不統(tǒng)一平臺搭得再漂亮也是花架子。幾個值得反復強調(diào)的經(jīng)驗第一指標和日志必須建立“可下鉆”關系。面板上看到一個異常指標能一鍵跳到對應的Trace列表再從Trace跳到完整日志。如果三級跳轉(zhuǎn)做不到可觀測性就是半成品。我們?yōu)榇藢ｉT做了一次數(shù)據(jù)模型對齊確保三套系統(tǒng)里請求ID的格式、字段名完全一致。第二可觀測性要覆蓋模型的“非功能屬性”。Token成本、上下文截斷、提示詞版本、重試率、緩存命中率這些在大模型場景比CPU和內(nèi)存更關鍵。傳統(tǒng)運維指標只是底線大模型特有的業(yè)務指標才是核心競爭力。第三從第一天就把內(nèi)容脫敏規(guī)則設計好。大模型應用會記錄大量用戶輸入而這些輸入可能包含敏感信息。我們很早就定了規(guī)則日志中默認不記錄原始對話內(nèi)容只記錄長度、關鍵詞、分類標簽只有顯式標記為“可審計”的請求才保留全文。這個決策幫我們避免了很多后續(xù)的合規(guī)麻煩。第四定期做日志數(shù)據(jù)的“減脂”。大模型日志天然膨脹每個月我都會檢查一次哪些字段實際查詢率不到5%哪些日志事件重復度最高有沒有新的截斷規(guī)則可以加這是一種持續(xù)治理不是一次性工程。做可觀測性這件事短期看是增加了一堆埋點代碼和配置文件好像拖慢了業(yè)務節(jié)奏。但等到模型上線、流量起來、用戶開始反饋“有時候回答很慢”“有些回答明顯變差了”的時候你就知道這套看不見的體系才是讓你能睡個安穩(wěn)覺的東西。大模型后端還在快速演進今天記錄的每一個Token、每一條Trace都是未來優(yōu)化模型、迭代prompt、控制成本最重要的原始依據(jù)。