每天收到的客服訊息如果只需要分成配送、帳務、商品問題和人工處理，值得測試的可能是一個專門做選擇的小模型。Together AI 9 月 23 日發布 Tev1-4B-experimental，並公開以 Qwen3.5 4B 微調分類模型的做法，案例訓練費約 17 美元、耗時約 25 分鐘。
對想降低大量分流成本的開發者，這提供了可參考的起點。先拿自己的繁中訊息比較分類結果與覆核時間，再決定是否微調；17 美元涵蓋的是這次訓練案例，完整服務仍有其他成本。下面先把輸出方式和證據限制說清楚，再用一組假設的客服資料安排試用。
Tev1 怎麼用？價格與成績各自涵蓋什麼
依官方模型卡，輸入由背景資料、問題和 2 到 24 個標示選項構成，模型應回傳一個選項字母，再由應用程式對應到分類代碼。它保留 Qwen 的逐 token 生成架構；一般聊天並非預期介面，也不宜把它當成另一套 Jev 執行架構的完整重製。
程式庫提供資料處理、LoRA 微調及推論範例。目前保存的訓練集有 37,840 筆、驗證集 4,568 筆；README 同時提醒，實際上傳檔案身分和該次工作的精確設定仍待驗證。因此，這是可研究與改作的範例，還不足以保證照做就重現同一成本與成績。
費用要分開算。Together 的教學在微調後另外建立專用端點，並提醒試驗結束後停止端點；讀者也可以依帳號可用性評估官方託管模型。訓練完成、模型可被呼叫，以及每天處理多少資料，是三筆不同的預算問題。 比較方案時，把準備資料、反覆訓練、端點運行和人員抽查一起算進去，才知道省下的是哪一部分。
成績也有範圍：模型卡列出主要決策集答對 880／1,000，政策轉移集為 300／300；這些資料參與過開發評估，後者含合成政策，尚無未微調 Qwen 的對照。繁中等多語行為、提示注入與廣泛分布外情境仍未完整評估，不能把百分比直接套到你的客服流程。
授權需要另外確認。截至 9 月 28 日，程式碼與原創文件標示 MIT，但模型卡寫明微調權重的發布授權仍在確認，第三方資料也各有條件。基底 Qwen 的 Apache-2.0 標示，不足以替這份微調權重與所有資料一併作結論；若要納入正式產品，先核對當下發布頁的完整條件。
用客服分流試一次，先算錯分與人工處理量
我會先做一個只有四種結果的測試：配送進度、付款問題、商品資訊，以及需要人工判斷。這是建議的試用設計，並非本站已跑過的成績。先由熟悉業務的人替一小批去識別化訊息標答案，再保留另一批完全不參與調整的資料，最後才用來驗收。
例如「款項已付，但一直沒看到出貨通知」同時出現付款和配送詞彙。你要先定義分類依據：以客戶目前需要解決的問題為準，還是以需要接手的團隊為準？若這條規則沒有講清楚，模型和人工標註者可能各自有合理答案，換更大的模型也未必解決問題。
接著放入缺資料與多重需求：「上次那筆又出問題了」應能進人工處理；「想改地址，也想確認發票」則要先決定單一分類是否符合工作需求。若一封信經常需要兩個團隊同時接手，就應重新設計分流流程，避免為配合單選輸出而遺漏需求。
驗收時，我會分開看三件事：答案是否符合格式、分類是否正確，以及錯分後要花多久才能修復。只回傳合法字母不代表判斷正確；少量高成本誤派，也可能吃掉大量便宜分類省下的費用。保留原文與人工更正結果，才能知道常錯在哪一類，而不是只留一個平均準確率。
程式庫還提醒，回傳的 token logprobs 不能直接當成校準過的正確機率。不要因為某個數值看起來很高，就自動略過覆核。可以先讓模型只提出分流建議，由人工照常處理；確認常見類別穩定後，再逐步擴大自動化範圍。
最後，把現有規則、未微調模型和新模型放到相同資料上比較。若改好分類定義就已足夠，微調可以暫緩；若某些穩定、重複的錯誤確實需要訓練，再回到 Fine-tuning 微調選擇指南。要把錯分、格式與維護成本整理成同一份驗收，可接著看 LLM 評估方法。