不佔住連線，也能扛住 AI 助手的流量

背景

一個線上電商平台，除了既有的業務流程之外，還有一個服務客戶的 AI 客服助手。

問題與模糊之處

每一個 LLM 產品的中心都有一個結構性的錯配：一次模型回合動輒數十秒，而一個網頁請求在抵達模型的路上會經過的所有東西 —— 閘道、防火牆、代理 —— 它們的逾時預算都是為毫秒級請求設計的。所以同步設計會同時有兩種失效模式。明顯的那一種是：一個慢回答可能超過路徑上某一處的上限。被忽略的那一種是：它跑的時候佔住了那條路徑，於是下一位客戶排在後面等。從外面看，這兩種一模一樣：AI 很慢。而兩者都不是模型的問題。

我的角色

我參與公司的 AI 客服系統 —— 知識結構、回應路由、工具呼叫、對話管理、評測、安全控制與轉真人 —— 並且設計並交付了這裡描述的請求路徑變更。平台本身的正式環境電商系統也由我維護。

這是在職期間刻意採取的公開層級用詞。內部紀錄支持更強的動詞，但公開頁面用的是這一版。

需求探索

有用的問題不是「怎麼讓模型更快」，而是「這條路徑上有什麼東西預期請求會很快結束？而當它沒有結束的時候，其他人會怎麼樣？」回答這個問題，就把題目從模型調校換成了連線架構。

架構與取捨

不再同步處理。請求進佇列；瀏覽器每隔幾秒輪詢一次，準備好就算繪出來。沒有任何東西佔住連線，所以路徑上的逾時上限不再支配一次對話，客戶是被並行服務的，而不是彼此排隊。代價是客戶端稍微複雜一點、以及一個看得見的等待狀態 —— 這個交換我會再做一次，因為另一個選擇是讓它安靜地、而且不公平地失敗。

實作與整合

在平台既有框架上的 queue workers，搭配前端輪詢，以及模型呼叫外圍的重試與錯誤處理。另外帶進兩項控制：閒置對話會到期 —— 安靜下來的對話會被提示一次，沒有回應就關閉並釋放它佔住的資源；以及較輕的請求路由到較小的模型層級，而不是每一次呼叫都打最大的模型 —— 這是不犧牲重要回答品質的前提下，最簡單的推論成本控制。

正式環境控制

模型呼叫外圍的重試與錯誤處理；對話生命週期管理；以及一套「設計進去而不是事後補上」的評測思路 —— 包含一次回答需要檢索並合併多項資訊時的正確性，以及在對抗性與社交工程探測下的行為。那套評測是正在建立中，不是已經上線的強化 —— 我描述的是一個設計，不是一個結果。

成果

這次重構已完成並合併進平台。這項工作不公布任何效能數字，未來也不會 —— 我沒有一個能誠實宣稱的正式環境結果。

可複用的經驗

當一個 AI 功能被說成「慢」，先量路徑，再去動模型。以我的經驗，模型做的還是它一直在做的事，是它周圍的架構改變了使用者的體驗 —— 而修法幾乎永遠是：不要再佔住連線。