工作以后，對于做業務的同學，一個避免不了的話題就是“badcase”，在大模型時代，當然也是避免不了的問題。

對于很多沒接觸過實際業務的同學可能認為大模型足夠強，強到可以很好的 fit 用戶的所有需求，就算 fit 不了，也可以微調模型來解決。

但實際情況是怎樣呢？其實不管是大模型，還是專有領域小模型，一定存會各式各樣模型解決不了的 badcase。

具體原因很多，以智能客服系統為例，用戶的咨詢分布也符合二八原則，即用戶 80% 的咨詢問題主要是集中在 20% 的知識點中；

針對用戶 20% 長尾知識咨詢，一般采用 AI 模型手段解決，這個部分是比較好處理的。那剩下的 20% 的問題覆蓋了 80% 的知識點，就屬于長尾問題了。

這部分出現頻率低，數據量不足，模型也不易學習到。長尾不代表不重要，但是卻很難優化，線上出的 badcase 也經常屬于這部分。

那線上大模型服務報了 badcase，如何解決呢？

我結合自己的經驗，總結主要有以下 4 個思路：

• 加前置模塊
• 加后處理
• 調 prompt
• 模型微調優化

最直接方式就是加前處理。具體來說就是在進入大模型前，做一級或者多級前置模塊。

實際業務系統中，會呈現一個漏斗形，最前面是高頻話術緩存，用戶的問題會被逐級過濾和篩選。高頻簡單的問題會被優先處理掉，直接返回。

這部分的模塊具有幾個很明顯的特點：

• 精度高
• 速度快
• 模型/規則簡單

所以針對某些 badcase，可以直接在這一層做掉，如果命中，直接加 trigger 返回。

我給大家舉幾個例子：

（1）比如用戶的 query 可能會出現一些敏感話題或詞語，這種情況是不能進大模型。

如果敏感詞檢測模型也沒有攔住，往往會在前面加一個拒識模塊，問題可以及時 hotfix。

（2）有時候會出現地域性方言或者當地口語的話術，query 改寫沒兜住，意圖識別沒兜住，大模型也沒兜住，怎么辦？

第一類加前置處理。結合一些泛化手段，這個在平時工作中會總結出一套完整流程，從種子語料，query 泛化，到線上自動配置化，基本能做到只需要少量人工參與的快速 fix。

第二類方法是后處理。為了方便理解，我也給大家舉個例子。

比如大模型被人熟知的輸出會有“幻覺”，甚至出現一些不可控的話題。這種比較好的方案就是在后面加一個處理模塊來二次過濾。

根據不可控的內容來構建檢索規則，直接對這種話術過濾刪掉，快速修復，保證產品的安全性。

第三類方法是調 prompt。這種方案一般是在 bug 不太緊急的情況下使用，不要求立即 fix。

例如有些場景對輸出話術有要求，比如必須要回答上關鍵要點，比如機器人的人設不能偏離，保證一致性等。

在線下多次測試已經 OK 了，但推到線上發現了漏網之魚，這種就可以通過調 prompt 來解決，這個過程比較長，也需要經驗，所以一般不會很高效。

最后一類方案才是微調模型。是不是跟大家想象得不太一樣？

把這個方案放到最后，原因有兩點：

• 重新訓練模型，時間比較長，可能需要多次調優。
• 對原有結果有影響，線上系統一般比較復雜，比如修復了 A，影響了 B，出現蹺蹺板的情況

所以，一般是有大版本升級的情況，才會更新模型。工作中，1，2，3 類的 badcase 會累積整理，累計到一個周期以后，再微調優化模型，然后經過嚴格的冒煙測試，回歸測試和灰度測試以后，才發布到線上。

最后做一個總結吧，線上問題多種多樣，科技含量最高的方案不一定是最好的，實際處理時要考慮幾個方面，問題的緊急性，是否對現有模塊有影響，修復所費的成本，對系統的負擔等。

“奧卡姆剃刀”是合適的指導準則，復雜不一定是最好的，即思維經濟性原則，如無必要，勿增實體。

本文轉載自 ??丁師兄大模型??，作者： 丁師兄