如何防止候選人排序測試中的評估資料洩漏

只有在選定排序方法的過程中，測試案例一直沒被看過，評估才有意義。當評估集的資訊影響了前處理、特徵選擇、提示詞調整、評分標準修改或門檻選擇時，就發生了資料洩漏。它會讓估計值偏高，讓方法看起來比實際面對新的候選人資料時更強。

這份指南把 scikit-learn 常見陷阱指南中的訓練／測試紀律，套用到候選人排序測試上。這是一套搭配合成範例的教學方法，不是 Talent Summoner 實作或效能的報告。公開的候選人排序流程說明的是如何審閱你提供的履歷；它沒有公開任何私有評估集或基準測試。

先固定問題，再切分資料

在看結果之前，先寫下評估問題。寫清楚需求說明的版本、排序用的評分標準、被排序的單位、成功標籤，以及結果可能影響哪個決定。把開發資料和最終的保留測試集分開。依照可能重複出現的單位來切分：候選人、履歷、職缺，或近乎重複的文件。如果好幾筆紀錄描述的是同一個人或同一個職缺，隨機按列切分仍然可能洩漏。

在排序方法、前處理和決策門檻都固定之前，保留測試集要一直封存。一個被反覆拿來挑設定的測試集，會變成另一種訓練訊號。如果審閱者為了釐清一個模糊的標籤而打開保留測試集，就記錄這次變更，並把那個案例移回開發資料；不要悄悄把它留下來當作獨立證據。

只用開發資料擬合轉換

scikit-learn 的指引很直接：先切分再做前處理，只在訓練資料上呼叫 fit，再用 transform 把學到的轉換套用到測試資料。用 pipeline 可以讓這些步驟綁在一起。同樣的規則也適用於排序測試：

• 詞彙表、正規化器、特徵選擇器、門檻和評分標準的權重，都只用開發案例來建立。
• 把固定好的轉換套用到保留案例時，不要用這些案例重新計算統計值。
• 保留測試集的標籤、審閱者的裁定和保留測試集的錯誤類別，都不能進入任何特徵或提示詞的選擇步驟。開發資料的標籤如果本來就是被訓練方法的一部分，可以當作輸入。
• 不要根據保留測試集裡的候選人順序，去改寫需求說明，或決定什麼才算符合。

這樣可以同時防止明顯欄位造成的洩漏（例如審閱者的最終標籤），以及間接欄位造成的洩漏（例如用整個語料庫裡每份履歷算出來的詞頻）。

一個固定的合成範例

下面的範例刻意做得很小，內容也是虛構的。它示範固定的資料切分，以及只在開發資料列上擬合的轉換。它不會產生 Talent Summoner 的分數。

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.pipeline import make_pipeline

texts = [
    "owned a production data migration",       # 正例
    "supported a reporting dashboard",         # 反例
    "designed an event driven API",             # 正例
    "attended an API workshop",                # 反例
    "maintained an on call rotation",          # 正例
    "read about on call practice",             # 反例
]
labels = [1, 0, 1, 0, 1, 0]

dev_text, test_text, dev_y, test_y = train_test_split(
    texts, labels, test_size=0.33, random_state=7, stratify=labels
)
model = make_pipeline(TfidfVectorizer(), LogisticRegression(max_iter=1000))
model.fit(dev_text, dev_y)
print(model.score(test_text, test_y))

向量器在 pipeline 裡只從 dev_text 學習詞彙。保留測試集只有在固定好的模型替它評分時才會被轉換。如果是排序評估，就把分類器換成與工作相關的評分標準或排序做法，維持同樣的切分，並檢查引用的證據，而不是把數字分數當成招募品質。

檢查洩漏途徑

接受結果之前，先問每一項輸入從哪裡來、在什麼時間點才拿得到：

保留切分 ID、轉換的版本、評分標準或提示詞的版本、程式碼版本、隨機種子、符合條件的數量和排除原因。一次通過的執行，只是那個固定設計的證據；它不能證明公平性、準確度、工作表現，也不能證明可以推論到每一個職缺。

回報不確定性和人的決定

每個指標都要寫明分母：候選人層級的一致度、條件層級的證據、前 k 名的重疊率，或無效輸出的比例。開發資料和保留測試集的數量要分開列。說明缺少的標籤、同分、棄權，以及審閱者之間的意見分歧。當證據不明時，排在後面的個人檔案也可能是對的；看起來合理的第一名，也可能含有沒有根據的說法。

模糊的條件交給一位負責人判斷，並為以下情況設定停止規則：隱私外洩、與工作無關的替代指標、無法進行的無障礙審閱，或無法重現的切分。保留原始輸出、更正內容和重跑的結果。絕對不要把合成測試樣本的結果，說成客戶成果或正式環境的基準測試。

Talent Summoner 適合用在哪裡

如果想看看你自己的職缺排序起來是什麼樣子，候選人排序可以依你的職缺說明替最多 50 份履歷評分，並列出每個分數的理由。

下一步：寫好評估約定，封存一個合成的保留測試集，並且只在已記錄的審閱範圍內使用候選人排序流程。