Metaview 如何為履歷審查打造自我改進的提示（self-improving prompts） ☕ Buy me a coffee

🧑‍🏫 這支影片的講者來自招募軟體公司 MetaView。他說明怎麼讓 AI 篩履歷的標準，跟著招募者一次次的決定自動調整，而不是寫好就一直用同一套。只要你用 AI 幫忙做「由人判斷好壞」的工作，就會遇到同樣的問題：標準會變。所以這支很值得看。

• 00:13 講者是 MetaView 的 Product Engineer Nick Mayhew，主題是 MetaView 如何在 application review 中使用 self-improving prompts
  ↳ 講者 Nick Mayhew 是 MetaView 的 Product Engineer（寫程式也參與產品設計的工程師）。主題是 self-improving prompt：給 AI 的指令會跟著使用者的決定自己更新。
• 00:13 MetaView 做的是 AI-native 招募軟體；application review 是指瀏覽候選人的 CV 與求職信，決定要面試誰
  ↳ MetaView 做招募軟體，自稱 AI-native（這是他們的說法，影片沒多解釋）。application review 就是招募方看履歷和求職信，決定要約誰面試的那一步。
• 00:44 從 2023 年大型語言模型普及到一般消費者之後，求職申請數量暴增，主因是 AI 降低了應徵門檻
  ↳ 2023 年起，一般人都能用 ChatGPT 這類 LLM（大型語言模型，會讀寫文字的 AI）。寫履歷、求職信變得很快，投遞成本大降，大家就大量投。
• 00:44 有一位客戶上週光是一個職缺，24 小時內就收到 2,740 份申請
  ↳ 有個客戶光一個職缺，一天就收到 2,740 份申請。靠人一份一份看，根本看不完。
• 01:17 這種量大多出現在遠端、junior 的職缺，但整體申請量都非常高
  ↳ 遠端、junior（初階）職缺最誇張，因為門檻低、誰都能投。不過就算是其他職缺，申請量也很大。
• 01:17 像「為什麼想來 Anthropic／MetaView 工作」這類申請問題，平均回答長度兩年內大約增加了 50%，原因是有 LLM 幫忙寫
  ↳ 「為什麼想來我們公司」這類題目，回答兩年內平均變長約五成，因為有 AI 代寫。招募方要讀的字變多，內容卻不一定更真。
• 01:50 訪談 hiring manager 或創辦人時，他們會列出經典條件，例如五年後端經驗，於是你就依這些條件打造評估系統
  ↳ 一開始去問 hiring manager（職缺的用人主管），對方會給很標準的條件，像是「五年後端（伺服器端程式）經驗」。你就照這些條件寫好評分規則。
• 02:20 問題馬上出現：看完第一批 CV 後，對方改口要新創經驗；到了第一場面試又說沒做過 zero to one 不行，你只好一直重寫評估系統
  ↳ 但主管看到真人後想法會變：看完履歷說要新創經驗，面試完又說要做過 zero to one（一般指從無到有做出產品）。規則只好一改再改。
• 02:20 核心觀點：只要是以使用者判斷為主的決策，偏好一定會改變，所以提示也必須跟著演進
  ↳ 核心觀點：只要是「由人判斷好壞」的事，標準一定會變。所以給 AI 的指令不能寫死，要能跟著人的想法一起調整。
• 02:53 要把「偏好會演進」當成整個系統的核心與基礎，不要等到最後才外加
  ↳ 不要先做一套固定系統，之後才補「可以改」的功能。一開始就要把「標準會變」當成設計的地基。
• 03:26 流程第一步：候選人進來後先 redact 姓名、email、電話等個人可識別資訊，只依經驗、技能、資格來評估
  ↳ 第一步先 redact（遮掉）姓名、email、電話這些認得出是誰的資料，讓 AI 只看經驗、技能和資格來評估。
• 03:26 將去識別化的候選人資料與 ideal candidate profile（ICP）比對，產出評估；ICP 就是會自我學習、自我改進的那段提示
  ↳ 遮好的資料拿去跟 ICP（理想候選人描述）比對，產出評估。ICP 就是那段會自己學習、修正的指令，也就是片名說的 self-improving prompt。
• 03:26 ICP 有點像 ideal customer profile，描述這個職缺在找什麼樣的人、要補什麼缺
  ↳ ICP 借用行銷的 ideal customer profile（理想客戶樣貌）概念，寫清楚這個職缺要找什麼樣的人、要補團隊哪個缺。
• 04:01 這是高風險領域，人的判斷不只是 human in the loop，而是 human in the center；系統的角色是學徒（apprentice），不負責做決定
  ↳ 招募會影響別人的工作，風險高。人不只是 human in the loop（流程中有人參與），而是 human in the center（人是決策核心）。AI 是學徒（apprentice），不拍板。
• 04:31 LLM 系統負責做粗活，找出例如：待過目標公司嗎、相關領域經驗夠嗎、用過對的技術嗎；錄取或淘汰則由使用者決定
  ↳ AI 負責粗活：查這人待過目標公司沒、相關經驗夠不夠、用過對的技術沒。要推進還是淘汰，永遠由使用者決定。
• 04:31 因為決策都由使用者做，可以放一個 agent 在上層觀察他們 progress／reject 的模式，再據此改進 ICP
  ↳ 既然決定都是人做的，就能在上層放一個 agent（會自己規劃步驟、使用工具的 AI 程式），觀察人推進（progress）誰、淘汰（reject）誰，再據此修改 ICP。
• 05:04 ICP agent 有三個主要部分，第一是 user messages：每次推進、淘汰候選人、給回饋、手動修改 ICP，都會當作 user message 餵進去
  ↳ ICP agent 的第一個部分是 user messages（使用者訊息）：推進、淘汰、寫回饋、手動改 ICP，這些動作都會當成使用者對 AI 說的話輸入進去。
• 05:37 早期學到的教訓：使用者的回饋都是相對於他們剛看過的東西，所以 agent 需要候選人（去識別化）資料當 context
  ↳ 早期學到的教訓：使用者說「這人太資淺」，是拿剛看過的人比出來的。agent 看不到那份履歷就聽不懂，所以要附上去識別化的候選人資料。
• 05:37 因此做了專用工具 Query Files；他們試過 Bash、grep 等標準做法，但非結構化資料很難直接在檔案系統裡 grep
  ↳ 所以他們做了專用工具 Query Files。Bash、grep 是工程師搜尋檔案內容的標準指令，但履歷格式五花八門，用關鍵字硬搜效果很差。
• 06:07 例：招募者說「這人 Python 經驗不夠」，工具會回頭查那份去識別化履歷，理解什麼叫 Python 太少、什麼叫太 junior
  ↳ 例如招募者說「Python（一種程式語言）經驗不夠」，工具就回去翻那份履歷，看實際寫了多少，agent 才抓得到「不夠」的標準在哪。
• 06:38 建好的 context 會送進 ICP Manager agent，它只有一個功能：讓 ICP 這段提示保持最新
  ↳ 整理好的資料交給 ICP Manager agent。它只做一件事：讓 ICP 這段指令保持最新，符合使用者現在的想法。
• 06:38 為什麼不整個做成單一 agent：他們一天要處理數千份申請，量大時沒辦法什麼都丟給 agent
  ↳ 為什麼不讓一個 agent 全包？因為每天有幾千份申請，agent 每次思考都花錢又花時間，量一大就負擔不起。
• 07:10 一個職缺 3,000 份申請不能花到幾十美元；大公司一年收到數十萬甚至數百萬份申請，所以系統必須省 token，底層用 workflow、上層才放 agent
  ↳ 一個職缺三千份申請，不能花到幾十美元；大公司一年可能上百萬份。所以大量評估交給照固定步驟跑的 workflow，比較省 token（AI 的計費單位），上層才放 agent。
• 07:42 ICP 就是 markdown 文件，不用權重、if 判斷或流程圖；履歷關鍵字比對一直被批評，他們也認為那不是評估人的好方法
  ↳ ICP 就是一份 markdown（用簡單符號標標題、條列的純文字）文件，沒有加權分數、if 判斷或流程圖。他們認為用關鍵字比對履歷，本來就評估不好一個人。
• 08:12 要善用 LLM 擅長的自然語言，讓它用文字推理，不要用流程圖；使用者也習慣用一般語言描述需求，這樣系統更能反映他們的優先順序
  ↳ LLM 最擅長自然語言，就讓它用文字推理，不要硬塞流程圖。使用者本來也是用一般的話描述需求，直接用文字最能保留他們在意的輕重。
• 08:42 選用 Claude 的原因：履歷評估的關鍵是分辨真假，很多 CV 灌水誇大
  ↳ 選 Claude 的原因：看履歷最難的是分辨真假，很多人會把經歷寫得比實際厲害。
• 09:13 會照單全收的模型會相信候選人說的話、直接說他很棒，所以需要能批判性推理的模型，因此他們用 Haiku 和 Sonnet
  ↳ 容易照單全收的模型，候選人說自己很強它就信，直接說他很棒。他們需要會質疑、會批判推理的模型，所以用 Claude 的 Haiku 和 Sonnet。
• 09:13 Haiku 用來做評估，因為每天要跑數千次；Anthropic 有給他們特殊的 input token 額度，才能一天處理這麼多申請
  ↳ Haiku 負責每份履歷的評估，因為一天要跑幾千次。Anthropic 另外給了他們特別的 input token（送進模型的文字量）額度，才撐得住這個量。
• 09:44 Sonnet 用在找模式這種比較不受限、延遲沒那麼重要的任務，多用一點智能；評估則是「ICP＋履歷→評估」這種較受限的任務
  ↳ Sonnet 用在「從一堆決定裡找模式」這種開放、不急的工作，多用點智能。評估則是「ICP＋履歷→結果」，範圍固定，交給 Haiku。
• 10:14 Demo（皆為假資料）：「product engineer back-end bias」職缺，每位候選人都有 ICP fit 標示，例如 good fit、OK fit
  ↳ Demo（示範，全是假資料）：一個偏後端的 product engineer 職缺。每位候選人旁邊都標出和 ICP 的契合度，像 good fit（很合）、OK fit（還可以）。
• 10:44 ICP 的結構是：role summary、must haves、nice to haves、red flags；這樣寫是因為很多招募者就是這樣思考，沒有什麼獨門秘方
  ↳ ICP 分四段：role summary（職缺概述）、must haves（必備）、nice to haves（加分）、red flags（警訊）。沒有秘訣，招募者平常就是這樣想的。
• 11:14 Demo：Nina 看起來很強卻只是 OK fit，講者把她推進下一關，並回饋「Airbnb 這類工程文化強的公司出身的人，應該是很好的 fit」
  ↳ 候選人 Nina 看起來很強，系統卻只給 OK fit。講者直接推進她，並留言「出身 Airbnb 這種工程文化強的公司，應該很合」。這就是在教系統。
• 11:44 在 Langchain 中可看到呼叫了 Sonnet 4.6，input 裡有 user messages，最下方是 Nina Park 已被推進以及整體回饋
  ↳ 在 Langchain（常用來開發 AI 應用的工具）裡看得到這次呼叫：用的是 Sonnet 4.6，輸入裡有使用者訊息，最下面是「Nina Park 已推進」和那段回饋。
• 12:47 agent 會輸出它想做的任務以及要呼叫哪些工具
  ↳ agent 會先列出它打算做哪些事、要用哪些工具，過程看得到，不是黑箱。
• 12:47 另一個例子（sales associate 職缺）：依使用者回饋更新後的 ICP 會用綠／紅 diff 顯示，使用者可以確認或自己修改，再重新評估候選人
  ↳ 另一個例子是業務助理職缺：ICP 依回饋更新後，用 diff（新增標綠、刪除標紅的對照）顯示改了哪裡。使用者可以確認或自己改，再重新評估候選人。
• 13:47 回到剛才的例子：Claude 給出推理後呼叫更新 ICP 的工具，其中一個重大修改是要求「強的 product engineering 背景」
  ↳ 回到 Nina 的例子：Claude 先說明理由，再呼叫工具更新 ICP。其中一個重大修改，是把「強的 product engineering 背景」列為要求。
• 13:47 這是刻意簡化的例子；實際大規模運作時不會每則回饋就更新 ICP，通常每 100、200 則左右會開始看出模式，藉此持續精修 ICP
  ↳ 這是為了示範刻意簡化。實際上不會每則回饋都改 ICP，通常累積一兩百則，才看得出穩定的模式，再慢慢修。
• 14:17 更新 ICP 後，會由 Haiku 重新評估候選人
  ↳ ICP 更新後，由 Haiku 用新版 ICP 把候選人重新評一遍。
• 14:47 重點一：以使用者判斷為中心的評估系統，要理解偏好一定會演進；事後才臨時補上不會成功，要做進基礎架構
  ↳ 重點一：靠人判斷的評估系統，標準一定會變。這件事要從地基就設計進去，事後臨時補救不會成功。
• 15:18 重點二：用文字（prose），不要用規則；善用 markdown，順著使用者和 LLM 的寫法，不要退回流程圖和 if 判斷
  ↳ 重點二：用文字（prose）描述標準，不要寫成規則。用 markdown，貼近人和 LLM 的表達習慣，不要退回流程圖和 if 條件。
• 15:18 重點三：把 guardrails 做進架構；評估系統已被用在 code review、金融犯罪、KYC 等場景，最後才外加 guardrails 行不通
  ↳ 重點三：guardrails（防止 AI 出錯、越界的保護機制）要一開始就做進架構。這類系統也用在程式碼審查、金融犯罪、KYC（講者舉的例子，影片沒解釋）等場景。
• 16:20 從一開始就把系統設計成學徒：向使用者學習，但絕不推翻使用者的決定；使用者是師傅，系統是學徒
  ↳ 系統從頭就定位成學徒：向使用者學，但絕不推翻使用者的決定。使用者是師傅，最後拍板的永遠是人。

MetaView 每天要處理數千份申請，他們用哪個模型做候選人評估（evaluations）？