為什麼我們沒有微調模型
我們每筆匯入的職缺，都會通過一個 LLM 來填入結構化欄位——資歷層級、工作模式、薪資、公司類型。這個 LLM 是計價的：我們按 token 付費。所以這個問題自然浮現——能不能用我們自己在 CPU 上跑的小模型，取代那些便宜又無聊的分類工作，幾乎免費地完成？
這個構想很合理。我們已經有完美的訓練資料：LLM 歷來填過的每個欄位，都是一個標註好的範例。把大模型蒸餾成小模型，在本地跑，不用再付錢。我們挑了最難、最有價值的欄位來測試這個構想——公司類型（product、startup、outsource、agency、in-house、government）——因為這是字典推導不出來的欄位，所以也是真正值得用模型來處理的欄位。
這個實驗
我們取出了約 38,000 家公司及其 LLM 標籤，在筆電上微調了一個小型多語言編碼器。然後我們測量它在沒見過的職缺上，與「老師」模型一致的頻率。
它的宏觀 F1 分數停在 0.42——低於你直接忽略輸入、每次都猜「product」能拿到的分數。各類別的細節說明了原因：模型在特徵明顯的類別上表現優異（政府機構、代理商），但在模糊地帶徹底崩潰——product vs in-house vs outsource vs startup。
而真正的關鍵在這裡：模型在 CPU 上每家公司跑 26 毫秒。速度從來不是問題。品質才是。更快的模型無濟於事。更大的模型也幫助不大。
問題不在模型——在問題本身
我們停下來檢查了一件本該先檢查的事：老師 模型本身是對的嗎？
在明確的案例上，絕對正確。美國聯邦職缺系統的每一筆職缺，都被標記為「government」——100% 正確，因為訊號毫無歧義。但接著我們看 YC 公司，它們本質上就是 startup。LLM 卻把 77% 標成「product」、22% 標成「startup」。
這不是 LLM 錯了。這是問題本身錯了。一家 YC 公司既是 product 公司也是 startup——這兩者並不對立。「公司類型」這個欄位，悄悄地把兩個不相關的概念塞進同一個欄位：公司做什麼（打造產品、銷售服務）與公司處於什麼階段（startup、scaleup、enterprise）。強迫用單一標籤涵蓋這兩者，意味著根本不存在正確答案——對 LLM 來說沒有，對蒸餾模型來說沒有，對人來說也沒有。
我們的模型失敗，不是因為它小。是因為我們叫它重現一場丟銅板的遊戲。
解法就在我們既有的資料裡
一旦把兩個軸分開來看，其中一個其實很簡單——而且完全不需要模型。
一家公司的階段，可以從我們已經儲存的事實推導出來：是否通過了 Y Combinator、員工人數、成立時間、是否透過政府職缺系統招募。所以我們直接用一組規則來計算，每家公司算一次：
- 透過聯邦職缺系統招募，或被標記為政府機構 → government
- 1,000 人以上 → enterprise（達到此規模的 YC 校友公司是企業，不是 startup——過去的標籤無法凌駕員工人數）
- 仍是活躍的 YC 公司，或規模小且剛成立不久 → startup
- 介於中間 → scaleup
- 訊號不足 → 不填，老實留白
不需要 LLM。不需要每筆職缺的成本。不需要訓練、部署、重新訓練的模型。它跑在我們每幾小時就會做一次的資料庫更新作業裡。當我們無法判斷時，我們就坦白說——沒有足夠訊號的公司，就不給階段，而不是硬塞進錯誤的分類來顯得我們很有把握。
你現在可以依階段篩選公司。
另一個軸——product vs services——我們暫時不動。我們的資料裡沒有乾淨的訊號可以判斷（公司列出的產業別太雜亂，無法信賴），所以假裝我們能分類只是換了件衣服重蹈覆轍。它在等待一個更好的訊號。
結論
對模型伸手的本能很強，經濟效益看起來也對。但這次衝刺的價值，在於用很低的成本就打消了這個計畫：一天的實驗，省下的是一條我們得永遠維護的管線。
在訓練任何東西之前，有兩個問題值得先問：
- 這件事其實是確定性的嗎？ 如果可靠的答案來自你既有的事實，那麼規則比任何模型都更便宜、更快、更值得信賴。
- 這個問題本身有答案嗎？ 如果標籤對人來說都是模糊的，那沒有任何模型能解決。先把問題修好。
最便宜的模型，就是你從未訓練的那個。