你已經挑出二十個真實案例，用完全相同的資料與 Prompt 比較兩個模型。

測試結果顯示：

  • 便宜模型答對十八題。
  • 平均處理速度更快。
  • 模型費用只有原本的十分之一。
  • 人工修改時間也沒有明顯增加。

這是不是代表可以立刻關掉原本的模型，把所有正式工作全部換過去？

答案是還不可以。

二十題測試很有價值，但它只能證明新模型值得進入下一階段。

它還不能證明新模型已經能在每天變化的真實環境中，長期、穩定而安全地取代原本系統。

為什麼通過二十題還不夠？

測試案例通常是你事先挑選並整理過的資料。

真實工作卻可能突然出現：

  • 以前沒有看過的資料格式。
  • 欄位名稱被供應商修改。
  • 客戶同時提出多項互相衝突的要求。
  • 文件裡缺少日期、價格或附件。
  • 外部工具暫時無法使用。
  • 大量請求同時進入系統。
  • 模型更新後輸出方式改變。

二十題可能涵蓋一般案例、缺漏案例、容易混淆案例與高風險案例。

但真實世界的例外狀況，通常比測試集更多。

通過測試代表模型在已知道路上開得不錯，不代表它第一次遇到暴雨、施工與道路中斷時，仍然知道該怎麼處理。

二十題測試真正證明了什麼？

它可以初步證明：

  • 新模型能理解你的基本指令。
  • 輸出格式大致符合要求。
  • 一般案例具有可接受的正確率。
  • 人工修改時間可能低於預期。
  • 模型費用值得進一步測試。

它也能幫你找出：

  • 最常出錯的資料類型。
  • 哪些欄位容易被省略。
  • 哪些工作不適合低成本模型。
  • Prompt 是否需要補充規則。

因此，二十題測試比較像是第一道篩選。

通過後可以進入少量真實工作，不代表立即全面替換。

第一個盲點：二十題可能沒有代表真正的工作比例

假設你的測試集包含：

  • 五題一般案例。
  • 五題缺少資料。
  • 五題容易混淆。
  • 五題高風險案例。

這種分配適合檢查模型能力。

但它不一定等於公司每天真正收到的工作比例。

真實工作可能是：

  • 百分之八十為一般案件。
  • 百分之十五需要補資料。
  • 百分之四涉及特殊判斷。
  • 百分之一為高風險例外。

如果模型在一般案件表現很好，卻在那百分之一的高風險案件中做錯決定，平均正確率仍可能看起來很漂亮。

因此，不能只看總分。

還要看：

  • 各類案件的個別正確率。
  • 錯誤發生在哪一類。
  • 錯誤是否容易被發現。
  • 錯誤發生後會造成多大影響。

第二個盲點：固定測試不能完全模擬新資料

模型可能在熟悉的二十題中表現穩定。

但新案件可能出現：

  • 新的商品名稱。
  • 新的產業用語。
  • 不同國家的日期與貨幣格式。
  • 掃描品質很差的文件。
  • 表格欄位順序完全改變。
  • 客戶使用縮寫或錯字。

這類資料差異常被稱為分布變化。

簡單來說，就是正式環境裡出現的內容，和測試時不完全相同。

模型不一定會明確說自己不懂。

它可能仍然產生一個格式完整、語氣流暢，但內容錯誤的答案。

第三個盲點：單筆正確，不代表大量處理仍然穩定

手動測試二十題時，通常是一題一題執行。

正式使用後，可能變成：

  • 每小時處理五千筆商品。
  • 同時分類數百封客服訊息。
  • 多個 Agent 一起呼叫模型。
  • 每天持續執行數萬次 API 請求。

大量使用後，可能遇到：

  • 速度下降。
  • 請求超過限制。
  • 部分回應失敗。
  • 輸出被截斷。
  • 重試造成重複處理。
  • 尖峰價格增加。

DeepSeek V4 Flash 的定位確實偏向高效率與大量請求，但實際服務仍有並行、價格及可用性條件。

因此，正式使用前還要測試：

  • 正常工作量。
  • 尖峰工作量。
  • 失敗後的重試規則。
  • 重複請求如何避免重複寫入。

第四個盲點：模型更新後，原本通過的結果可能改變

雲端模型可能由供應商持續更新。

更新通常希望改善：

  • 能力。
  • 速度。
  • 安全性。
  • 工具使用。

但同一次更新也可能改變：

  • 輸出格式。
  • 對 Prompt 的理解。
  • 工具選擇方式。
  • 拒絕回答的範圍。
  • 答案長度與語氣。

原本能穩定輸出固定 JSON 欄位的流程，更新後可能多出說明文字。

原本會標示「待確認」的模型，也可能開始嘗試補出答案。

所以測試不能只做一次。

模型版本、Prompt、資料規則或外部工具變更後，都應重新執行重要測試。

第五個盲點：測試時可能有人在旁邊即時修正

手動測試模型時，使用者通常會：

  • 看到錯誤立即重問。
  • 補充缺少的背景。
  • 重新貼上格式要求。
  • 跳過明顯不合理的答案。

這些人工介入會提高最後成果品質。

但正式自動化後，可能沒有人逐筆看見模型的中間過程。

因此要分清楚：

  • 有人陪同操作時的成功率。
  • 無人介入時的成功率。

如果測試成功依賴使用者不斷修正，模型就還不適合直接進入全自動流程。

那麼通過測試後，下一步該做什麼？

比較安全的下一步是進入小規模試行。

可以先挑選：

  • 低風險。
  • 數量足夠。
  • 結果容易檢查。
  • 錯誤可以復原。

的一類工作。

例如：

  • 商品資料初步分類。
  • 客服訊息分流。
  • 文件格式整理。
  • 內部摘要草稿。
  • 程式測試案例初稿。

不要第一天就處理付款、正式合約、網站部署或對外承諾。

什麼是平行運作？

平行運作是指新舊模型在一段時間內，同時處理相同或相近工作。

例如：

  • 原模型仍產生正式結果。
  • 新模型在旁邊產生比較結果。
  • 兩邊都不直接對外執行。
  • 由人比較差異與錯誤。

這種方式可以回答：

  • 新模型在真實資料中是否仍然省錢。
  • 兩個模型最常在哪些地方不同。
  • 新模型是否產生測試集沒出現過的錯誤。
  • 人工修改時間是否隨工作量增加。

平行運作的缺點是短期內需要同時支付兩套模型費用。

但相較於直接替換後發生大量錯誤，這通常是較低的驗證成本。

平行運作不是浪費兩倍費用，而是用一段有限成本，確認新模型不會把省下的帳單變成更大的返工。

如果成本有限，不能兩個模型全部平行跑怎麼辦？

可以只抽取一部分案件。

例如：

  • 每天隨機抽取百分之十。
  • 所有高風險案件都同時比較。
  • 新資料格式第一次出現時雙重處理。
  • 模型更新後抽樣重新驗證。

抽樣時不要只選最簡單的案件。

應涵蓋：

  • 一般案件。
  • 資料不完整案件。
  • 特殊格式。
  • 高風險例外。

什麼是小流量試行？

小流量試行是讓新模型真正處理少部分正式工作，但保留人工審核與回復能力。

例如第一週：

  • 只讓新模型處理百分之五的低風險案件。
  • 所有成果都要人工確認。
  • 原模型保留作為備援。

如果結果穩定，第二階段可以提高到百分之二十。

接著再逐步增加。

每一次提高比例前，都要確認：

  • 錯誤率沒有上升。
  • 人工修改時間仍然合理。
  • 服務速度與失敗率可接受。
  • 沒有出現新的高風險錯誤。

應該觀察哪些正式環境指標？

至少可以追蹤：

  • 第一次成功率：不需重試即可使用的比例。
  • 人工修改時間：每件成果平均需要修改多久。
  • 不可用率：必須完全重做的比例。
  • 高風險錯誤：金額、個資、權限與正式承諾出錯的次數。
  • 延遲：從送出資料到取得結果需要多久。
  • 失敗與重試：API 錯誤及重複執行的次數。
  • 每份成果總成本：模型費用加人工與返工成本。

不要只追蹤模型費用。

也不要只看整體平均正確率。

什麼錯誤應該設定為立即停止？

可以為試行設定紅線。

例如新模型出現以下情況時，立即停止提高流量：

  • 虛構價格、數量或日期。
  • 把個人資料放進錯誤欄位。
  • 沒有依規則轉交高風險案件。
  • 執行未經批准的外部動作。
  • 重複處理同一筆付款或訂單。
  • 輸出格式錯誤導致正式系統寫入失敗。

紅線不能只寫：

錯誤太多就停止。

應該明確定義：

  • 哪一種錯誤。
  • 多少次。
  • 由誰決定停止。
  • 停止後如何回到原模型。

可以直接使用這段試行規則

新模型目前只處理指定的低風險案件，初始比例不得超過百分之十。所有輸出在進入正式系統前都必須通過人工確認。遇到金額、日期、個資、正式承諾、資料缺漏、工具失敗或無法依規則分類時，立即轉回原模型或人工處理。每週比較第一次成功率、人工修改時間、不可用率、重試次數與每份可用成果總成本。任何高風險錯誤出現時，停止提高使用比例並重新檢查測試集與 Prompt。

新模型表現穩定多久，才可以增加比例？

沒有適用所有公司的固定天數。

應依照：

  • 每天案件數量。
  • 工作風險。
  • 資料變化速度。
  • 錯誤是否容易發現。

決定。

如果每天有一萬筆低風險分類，一週可能已累積大量觀察資料。

如果每月只有十件高價合約，即使運作一個月，樣本也可能仍不足。

比「跑了幾天」更重要的是：

  • 是否涵蓋足夠多種案件。
  • 是否經過尖峰流量。
  • 是否遇過資料缺漏與工具失敗。
  • 是否觀察到高風險例外。

新模型什麼時候可以成為主要模型？

可以設定幾項條件：

  • 正式環境的正確率達到要求。
  • 高風險錯誤維持在允許範圍內。
  • 人工修改時間沒有明顯增加。
  • 大量請求下仍能穩定回應。
  • 每份可用成果總成本確實下降。
  • 發生故障時能切回原模型。

即使達到這些條件，也不一定要所有工作都使用同一模型。

一定要完全取代原模型嗎？

不一定。

更實際的做法可能是模型分流。

例如：

  • 低成本模型：處理大量分類、格式整理及初稿。
  • 較強模型：處理複雜推理、特殊案例及失敗重試。
  • 人工處理：負責付款、合約、醫療、法律及正式承諾。

這樣可以同時取得：

  • 低成本模型的價格優勢。
  • 較強模型的複雜問題處理能力。
  • 人類對高風險決定的控制。
最省錢的架構不一定是只留一個模型，而是讓每一類工作使用足夠好、但不過度昂貴的處理方式。

什麼情況應該自動升級到較強模型？

可以設定以下條件：

  • 資料缺少必要欄位。
  • 低成本模型信心不足。
  • 輸出沒有通過格式檢查。
  • 同一案件重試仍失敗。
  • 內容涉及多份互相衝突的文件。
  • 案件包含較高金額或重要客戶。

較強模型也不是最後保證。

如果涉及正式決策，仍要轉交真人。

價格變動也要重新評估嗎？

需要。

模型供應商可能調整：

  • 輸入價格。
  • 輸出價格。
  • 快取價格。
  • 尖峰與離峰價格。
  • 並行使用限制。

原本最便宜的模型，幾個月後不一定仍然最便宜。

同時，原模型也可能降價或提高效率。

因此，正式導入後仍應定期重新計算：

每份可用成果總成本＝模型費用＋人工修改＋重試＋錯誤返工。

什麼情況代表應該暫時切回原模型？

  • 不可用率突然增加。
  • 輸出格式頻繁改變。
  • 高風險分類開始漏判。
  • API 失敗或延遲明顯增加。
  • 供應商更新模型後成果改變。
  • 實際總成本已經高於原模型。

切回原模型不是導入失敗。

它是備援流程正常發揮作用。

哪些工作可以較快提高新模型比例？

  • 不含敏感資料的固定格式分類。
  • 能用程式自動檢查的欄位整理。
  • 內部使用、不直接發布的初稿。
  • 錯誤可以重新產生的摘要。
  • 有原始資料可供人工核對的工作。

哪些工作即使通過二十題，也不能立刻自動取代？

  • 付款與退款。
  • 正式合約。
  • 醫療與法律判斷。
  • 員工錄取與解雇。
  • 客戶價格、庫存及交期承諾。
  • 正式網站部署與資料庫修改。
  • 包含大量敏感個資的流程。

這些工作可以使用模型協助整理、比較與準備草稿。

最終行動仍需要人類批准。

今天最重要的答案

二十題測試是更換模型前很好的第一步。

它能幫你比較：

  • 模型費用。
  • 基本正確率。
  • 重試次數。
  • 人工修改時間。
  • 常見錯誤類型。

但它無法完全模擬：

  • 未見過的新資料。
  • 大量並行請求。
  • 外部工具故障。
  • 模型版本更新。
  • 真實環境中的罕見例外。

便宜模型通過二十題後，正確的下一步不是全面取代，而是小流量試行、平行比較、保留人工審核與回復機制；只有它在真實工作中持續證明總成本更低、錯誤可控，才逐步提高使用比例。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀