上個月一號早上我習慣性打開控制臺看賬單好家伙客服機器人這個功能一個月燒掉的錢比它帶來的轉化還刺眼。我把調用日志抽樣拉出來看了一圈越看越不對勁——起碼七成的提問是你們幾點下班發(fā)票能開嗎幫我查下訂單到哪了這種一句話就能答完的事。而這些請求全被我送進了自家最貴的旗艦模型。相當于我請了一位博士后坐在前臺專門回答廁所在哪。于是我決定給項目加一層模型路由model routing模型路由就是在請求進門時先分類簡單問題分給便宜的小模型難的才請出大模型。狠一點的做法叫級聯調用cascading級聯調用先一律讓小模型上答不好再自動升級找大模型救場。聽著都很美對吧我第一次跑的時候還挺得意覺得自己用 AI 管 AI架構優(yōu)雅得很——我讓旗艦模型親自當路由器每個請求先問它一句這題簡單嗎再決定分給誰。結果跑了一周賬單比不加路由還高了 8%平均響應時間也翻了一倍。原因特別樸素路由這一步本身也是一次大模型調用錢一分沒少花延遲還多出一截。同事看完我的架構圖憋了半天來了句你這門衛(wèi)的工資比里面上班的還高。行這話說得難聽但在理。推翻重來第二版我把路由器從最貴的換成了最便宜的。規(guī)則先上高頻 FAQ 命中的直接走模板答案壓根不進模型剩下的請求用 embedding向量嵌入把文本變成一串數字方便機器算相似度加一個輕量邏輯回歸分類器判斷類型成本約等于零判斷不準的一律默認給小模型。旗艦模型從全員營業(yè)變成了只接疑難雜癥。這一版上線路由本身的開銷降到可以忽略不計。然后我就撞上了第二個坑也是這個方案里真正難的部分——難度這個信號遠沒有想象中好判斷。我一開始偷懶拿問題短簡單當規(guī)則用結果被現實教育了幫我寫周報四個字是生成類任務小模型寫出來就是一篇流水賬用戶直接投訴反過來一段三百字的技術報錯貼進來看著挺唬人其實是我們 FAQ 里躺了半年的已知問題。你看長度根本不能代表難度任務類型是問答、生成還是推理和領域熟悉度才是關鍵變量。我后來把分類器改成了按任務類型領域打標準確率才肉眼可見地爬上來。寫到這兒插一句產品同學聽說賬單砍了六成第二天就興沖沖跑來想把省下的預算拿去做兩個新功能。我趕緊把報表收起來——省下的錢是拿來填下次事故的真不是拿來花的。光省錢還不行路由錯了得有安全網兜底。我們現在的設計是小模型答完先過一道自查置信度confidence模型對自身答案的把握程度低就自動升級到大模型重答用戶點了不滿意的案例會自動回流進標注池每月喂回分類器重新訓練一次。上線時是灰度放的先切 10% 流量觀察了一周兩類錯誤率都穩(wěn)住了才全量?，F在的狀態(tài)是七成流量走小模型總成本降了六成多答對率只掉了不到兩個百分點而且大半還是被兜底撈回來的。說實話路由這事到現在也沒有標準答案。云廠商這兩年都推出了托管路由服務聽著省心實際是黑盒分流邏輯一變你連招呼都不會收到自己搭呢分類器要持續(xù)養(yǎng)數據業(yè)務一變方向整套策略就得重新校準。另外也別神化這套玩法——小模型的能力上限擺在那復雜推理、多輪長對話這類任務路由器再聰明也該直接放行給大模型硬省那點錢最后都是事故工單。如果你手上也有項目在拿同一個旗艦模型硬扛全部流量不妨先去抽一百條日志看看說不定你會跟我一樣發(fā)現博士后正坐在前臺。看完了記得回來聊聊你的場景里簡單請求和硬核請求的比例是多少你是愿意自己養(yǎng)一個分類器還是干脆信云廠商的黑盒路由評論區(qū)見我是真的想知道大家這筆賬都是怎么算的。