零樣本分類的意思
傳統的監督式文字分類需要為每個類別蒐集數百到數千筆標註資料、訓練模型，類別一改就得重新訓練。零樣本分類省去這個針對任務的訓練步驟：一個已經理解語言的模型在請求當下拿到候選標籤，選出最符合輸入的那一個。「零」指的是模型看過你這項任務的標註範例數量，而不是你不必做任何準備。
這個概念比大型語言模型更早出現。零樣本學習的研究探討如何透過與已知概念的關聯，辨識訓練資料中沒有出現過的類別。在文字領域，常見做法是把分類改寫成自然語言推論：每個標籤變成一個假設，例如「這段文字與帳務有關」，再由訓練過蘊含判斷的模型評估文字支持這個假設的程度。Hugging Face 的 zero-shot-classification 管線以 BART-MNLI 等 NLI 模型讓這種做法普及；指令微調過的語言模型則讓流程更簡單：把標籤與一段簡短規則放進請求，模型直接回傳選擇。
零樣本、少樣本與微調模型的差別
零樣本只用標籤與指示。它是最快的起點，不必蒐集資料，每次請求都可以換一組類別；弱點是當標籤取決於公司內部用語或細微的政策界線時，模型很難只從字面推斷。
少樣本（few-shot）在請求中加入幾個示範範例，常能修正兩個標籤之間的模糊地帶，代價是請求變長，而且模型可能模仿範例的長度或語氣等表面特徵，而不是規則本身。
微調模型用你自己的標註資料訓練。在標籤穩定、量大的情況下通常最一致，但需要標註資料集、訓練流程，以及類別變動時的重新訓練計畫。務實的做法是先用零樣本上手、找出失誤的位置、針對那些界線補幾個範例，等到量與分類體系都穩定時再評估是否值得微調。
零樣本請求怎麼組成
每個零樣本請求都有三個部分：要分類的文字、允許的標籤清單，以及說明如何在標籤之間做選擇的指示。標籤就是契約：模型只能回答清單中的一個，程式就不必解析自由文字，清單外的答案也能直接拒絕，而不是用猜的。
Jev API Pro 就是圍繞這份契約設計的。你送出文字、指示與標籤，並可設定信心門檻；回應是你的其中一個標籤，模型有提供時會附上信心值。低於門檻的結果會標記為需要覆核，而不是直接當成定案。下面的請求可以直接貼進 Playground 試用。
{
"text": "三月的帳單被重複扣款兩次，請退還其中一筆。",
"instructions": "選擇能處理這項請求的團隊；都不適用時選「其他」。",
"labels": ["帳務", "技術支援", "帳號登入", "其他"],
"threshold": 0.8
}寫出模型分得開的標籤
零樣本的失誤多半來自標籤設計，而不是模型本身。互相重疊的標籤，例如「客訴」與「帳務問題」，會逼模型自己挑一個你沒指定的維度。每個標籤只對應一個軸：誰負責處理、要求的是什麼動作，或適用哪條政策。需要兩個軸（例如主題與情感）時，就做兩次獨立的判定。
用模型本來就懂的一般詞彙，而不是內部代碼：「退款申請」比「FIN-2」容易判斷。內部名稱無法避免時，在指示中解釋一次。一定要保留「其他」或「需要釐清」這類出口標籤，讓什麼都不符合的訊息有誠實的去處。
清單要短。五到十個界線清楚的標籤，比四十個更容易評估。分類體系很大時，先分到大類，再用第二次判定在大類內細分。
零樣本分類容易失誤的地方
否定與引述是典型陷阱：「不要取消我的帳號」裡就有「取消」兩個字。混合請求是另一種：同時要求退款與重設密碼的訊息，除非規則指定以哪個為主，否則有兩個正確答案。領域用語也會影響結果，產品名稱、縮寫與地區說法可能從未出現在模型學習過的語境中。
藏在文字裡的指令是另一種風險。客戶訊息可能含有看起來像在命令模型的句子。請把輸入當成要分類的證據，並在指示中寫明；也絕不要只憑一次分類就觸發退款或刪除帳號這類不可逆的動作。
信心值有幫助，但不是保證，模型也可能很有把握地答錯。用門檻決定哪些結果交給人看，並用自己的標註範例校準，而不是直接沿用預設值。
自動化之前先測試
蒐集 100 到 300 則真實訊息、移除個人資料，請實際負責這些工作的同事標註。再用你的零樣本規則跑同一批資料並比對答案。特別注意會導致不同動作的標籤之間的混淆；單一的整體準確率可能掩蓋昂貴的錯誤，例如取消申請被送到錯誤的佇列。
先用建議模式上線：把預測標籤寫進欄位，讓團隊接受或修正，並依標籤記錄修正次數。某條可回復的路徑錯誤率可以接受後再自動化，低信心結果仍交給人處理；每次調整標籤或指示後，都重新跑一次評估資料。