我們如何合併重複的職缺

在 freehire 上搜尋的使用者，希望每個職缺只出現一次。但同一個職位經常會張貼在多個地方：公司自家的徵才頁面，以及一個或多個會轉貼的職缺彙整網站。我們兩邊都會抓取，所以若不特別處理，同一份工作就會出現兩、三次。

合併這些複本聽起來簡單，其實不然。以下是我們最終採行的做法。

簡單的情況：完全相同的身分

當彙整網站直接連結到公司的招募系統（例如 Greenhouse 或 Lever 的網址）時，我們會以該系統本身的身分來儲存這筆刊登。只要帶有真實連結的複本就會與我們直接從該平台抓取的資料落到同一個鍵，兩者便自動合併，無需猜測。

這對願意揭露原始連結的彙整網站有效，但很多網站並不會。

大型的區域性與遠端職缺彙整網站會透過自家網站接受應徵，從不揭露來源網址。對這些網站而言，兩份複本之間唯一共通的只有職缺本身：同一家公司、同一個角色、相似的職稱。因此我們以職稱來比對。

在同一間公司內部，當彙整網站的刊登與第一方刊登的職稱對得起來時，前者會被視為後者的重複項。所謂「對得起來」最終需要三道比對程序：

完全相同：標準化後的職稱完全一致。
格式重排：彙整網站以可預期的方式改動了職稱。某飯店連鎖的系統列出 Assistant Director of Sales - Leisure，彙整網站卻刪掉尾端部分，只留下 Assistant Director of Sales。或是留下未解碼的 HTML 實體，使 F&B 無法與 F&B 對應。我們將兩者都標準化處理掉。
詞彙子集：彙整網站從職稱中間刪去了詞彙，而不僅僅是結尾。Guest Service Agent 與 Guest Service Agent Front Office 其實是同一份工作。當彙整網站職稱中的每個詞彙都出現在第一方職稱中時，就視為相符。

每道比對程序放寬的條件越多，就越容易把兩個實際上不同的職位合併在一起。為此我們設有兩道防護。

第一道是地理位置。美國公司的 Store Associate 與其新加坡分部的 Store Associate 是不同的工作，因此只有在國家相容時才會合併。這正是結果是否乾淨，以及是否會把新加坡的刊登誤併到毫不相關的美國刊登上的關鍵差異。

第二道是資深程度。Software Engineer 是 Senior Software Engineer 的子集，但兩者是不同職等，並非重複。因此，詞彙子集比對程序在多出的詞僅為資深程度標記時，會拒絕合併；只有當第一方職稱多出彙整網站省略的實質內容時，才會進行合併。

有兩個看似可行的做法，經過簡單實驗後都未獲採用。

模糊字串相似度可以找出子集比對漏掉的改寫職稱。但根據實際資料評估，單純的詞彙子集比對就已經能抓到同樣的重複項目，無需調整相似度門檻，也降低了合併錯誤職位的風險。較模糊的工具並未帶來額外效益。

從彙整網站的頁面中挖掘真正的招募系統連結，原本可以讓所有資料都走完全相同身分的路徑。我們實際查驗過：有的網站會透過自己接受應徵，有的則將頁面藏於機器人驗證之後，在我們取得的資料中根本沒有來源網址。這些網站根本無法取得精確的對應路徑。

首次執行時合併了大約 10,600 筆重複刊登：約 2,800 筆來自某系統轉發的飯店與餐旅業職缺、2,200 筆來自另一系統的遠端職務，以及散落在十餘個其他來源中的長尾。每筆現在只會顯示一次，且取自最接近公司本身的來源。

資料並沒有被刪除。被合併的複本仍保有自己的頁面與連結，僅會在搜尋結果中隱藏；若第一方刊登日後關閉，該複本就會自動重新出現。