ATS โอเพนซอร์สของ HackerRank ให้คะแนนเรซูเม่เดียวกันสวิงเป็น 90, 74 และ 88 คะแนน

 (danunparsed.com)
2 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อนำเรซูเม่เดียวกันและคำสั่งเดียวกันไปรันซ้ำกับ เอเจนต์จ้างงาน ATS แบบโอเพนซอร์ส ของ HackerRank คะแนนกลับแกว่งตั้งแต่ 66~99 คะแนน และหากใช้เกณฑ์ตัดที่ 85 คะแนน จะมีผลให้ 65% ไม่ผ่าน
  • เครื่องมือนี้จะแปลงเรซูเม่ PDF แล้วเรียก LLM 6 ครั้งเพื่อจัดโครงสร้างข้อมูลพื้นฐาน ประสบการณ์ การศึกษา ทักษะ โปรเจกต์ และรางวัล ก่อนนำข้อมูล GitHub มารวมเพื่อประเมินแบบ 100 คะแนน + โบนัส 20 คะแนน
  • คะแนนด้านทักษะทางเทคนิคค่อนข้างคงที่ โดย 98 จาก 100 ครั้งได้ 8/10 คะแนน แต่การประเมินโปรเจกต์มี ความผันผวนสูง สลับไประหว่าง “ความซับซ้อนด้านสถาปัตยกรรมไม่เพียงพอ” กับ “แสดงให้เห็นการ deploy ใช้งานจริง”
  • ไม่ใช่แค่ temperature 0.1 ของโมเดลเริ่มต้น gemma3:4b เท่านั้นที่มีปัญหา แม้ลดเป็น temperature 0 ก็ยังมีความไม่เป็น deterministic อยู่ และแม้เปลี่ยนเป็น Gemini ก็ยังมี อัตราตก 28% ที่เกณฑ์ตัด 60 คะแนน
  • หมวดประสบการณ์การทำงานกลับได้ 25/25 คะแนนแม้ในเรซูเม่เก่าที่มีแค่อินเทิร์นชิปเดียว ทำให้การให้คะแนนด้วย LLM อาจกลายเป็น การคัดกรองตามดวง มากกว่าการแยกคุณภาพผู้สมัคร

เรซูเม่เดียวกันได้คะแนนไม่เหมือนกันทุกครั้ง

  • hiring-agent ซึ่งเป็น ATS แบบโอเพนซอร์สของ HackerRank กลายเป็นเป้าทดสอบหลังได้รับความสนใจบน LinkedIn และ Reddit
  • การรันครั้งแรกได้ 90/100 คะแนน แต่หลังลบบรรทัด output สำหรับดีบัก แล้วรันใหม่ด้วยเรซูเม่เดิมและคำสั่งเดิม กลับได้ 74/100 คะแนน
  • เมื่อปิด DEVELOPMENT_MODE และรันซ้ำ 100 ครั้ง ช่วงคะแนนยิ่งกว้างเป็น 66~99 คะแนน
  • หากบริษัทใช้เกณฑ์ผ่านที่ 85 คะแนน เรซูเม่เดียวกันก็มีโอกาส ไม่ผ่าน 65%

โครงสร้าง pipeline การประเมินและสัดส่วนคะแนน

  • เครื่องมือจะ parse เรซูเม่ PDF เป็นข้อความก่อน แล้วเรียก LLM หลายครั้งเพื่อจัดโครงสร้างข้อมูลผู้สมัคร
    • ข้อมูลพื้นฐาน
    • ประสบการณ์การทำงาน
    • การศึกษา
    • ทักษะ
    • โปรเจกต์
    • รางวัล
  • จากนั้นจะสแกนโปรไฟล์ GitHub และ repository อันดับต้น ๆ แล้วแนบข้อมูลนี้เป็นบริบทเพิ่มเติม ก่อนส่งข้อมูลทั้งหมดให้ LLM ประเมินในครั้งเดียว
  • โมเดลเริ่มต้นคือ gemma3:4b ที่รันบนเครื่องโลคัล โดยตั้งค่า temperature ไว้ที่ 0.1
  • คะแนนเต็มอยู่ที่ 100 คะแนน และมีโบนัสเพิ่มได้สูงสุด 20 คะแนน
    • การมีส่วนร่วมกับโอเพนซอร์ส: 35 คะแนน
    • โปรเจกต์ส่วนตัว: 30 คะแนน
    • ประสบการณ์ทำงาน: 25 คะแนน
    • ทักษะทางเทคนิค: 10 คะแนน
    • ประสบการณ์สตาร์ตอัป เว็บไซต์พอร์ตโฟลิโอ บล็อกเทคนิค ฯลฯ: โบนัสสูงสุด 20 คะแนน

หมวดที่คงที่กับหมวดที่แกว่งแรง

  • ทักษะทางเทคนิค เกือบคงที่ โดย 98 จาก 100 ครั้งได้ 8/10 คะแนน
    • การมีเทคโนโลยีอย่าง React หรือไม่นั้นใกล้เคียง checklist มาก ทำให้มีพื้นที่สำหรับการตัดสินแบบอัตวิสัยของ LLM น้อย
  • ในทางกลับกัน หมวด โปรเจกต์ มีการตัดสินที่แกว่งมากในแต่ละรอบ
    • บางรอบประเมินว่าโปรเจกต์ “ความซับซ้อนด้านสถาปัตยกรรมไม่เพียงพอ”
    • อีกรอบกลับประเมินว่า “แสดงให้เห็นการ deploy ใช้งานจริง”
  • แม้ temperature 0.1 จะถือว่าต่ำ แต่ปัญหาก็ไม่หายไปแม้ลดลงเป็น temperature 0
  • ใน GitHub issue ที่เปิดเมื่อเดือนตุลาคม 2025 ก็พบว่าแม้ใช้ temperature 0 คะแนน 6 ครั้งติดก็ยังต่างกันเป็น 27, 34, 32, 34, 34, 30

เปลี่ยนโมเดลแล้วก็ยังไม่เสถียร

  • เนื่องจาก gemma3:4b เป็นโมเดลที่รันแบบโลคัล จึงมีการตรวจสอบผลของตัวโมเดลด้วย
  • เมื่อใช้ Gemini การกระจายของคะแนนแคบลงเป็น 48~64 คะแนน
  • แต่ถ้าใช้เกณฑ์ผ่านที่ 60 คะแนน ผู้สมัครก็ยังมีโอกาส ไม่ผ่าน 28% โดยไม่เกี่ยวกับเนื้อหาในเรซูเม่ของตนเอง
  • คะแนนโอเพนซอร์สดูคงที่ขึ้น แต่คะแนนโปรเจกต์ยังแกว่งมากเหมือนเดิม

ปัญหาตรงข้ามของคะแนนประสบการณ์: คงที่แต่ไร้ประโยชน์

  • หมวดประสบการณ์การทำงานได้ 25/25 คะแนน ในทุกรอบ
  • แม้กรณีมีเพียงอินเทิร์นชิปเดียวเหมือนเรซูเม่เก่าก็ยังได้ 25/25 คะแนน
  • ในพรอมป์ประเมิน ส่วน Production มีเพียงสองบรรทัด
    • วิเคราะห์ประสบการณ์ทำงานจริง อินเทิร์นชิป และประสบการณ์ production จากส่วน work และ volunteer
    • ให้พิจารณาเพิ่มสำหรับบทบาทผู้ก่อตั้ง ผู้ร่วมก่อตั้ง และวิศวกรยุคแรกของสตาร์ตอัป
  • ไม่มีเกณฑ์ ตัวอย่าง หรือ baseline ว่าอะไรทำให้ได้ 15 คะแนนหรือ 25 คะแนน
  • ผลคือทั้งอินเทิร์นชิปของวิศวกรระดับจูเนียร์ principal engineer ที่มีประสบการณ์ระบบกระจายศูนย์ 10 ปี และเรซูเม่ที่ใช้ในการทดสอบ ต่างก็อาจได้ 25/25 คะแนนเหมือนกัน

ความเสี่ยงเชิงปฏิบัติในการคัดกรองเรซูเม่

  • การใช้ LLM เพื่อ parse เรซูเม่เป็นข้อมูลแบบมีโครงสร้าง หรือเช็กว่ามีทักษะ Python หรือไม่ ถือว่าใกล้เคียงกับงานที่เหมาะสมกว่า
  • แต่การตัดสินว่าประสบการณ์ของผู้สมัครควรได้ 18 คะแนนหรือ 24 คะแนน กลับให้ผลลัพธ์ที่ใกล้เคียง vibe-check มากกว่า
  • โครงสร้างที่ให้น้ำหนักรวม 65% กับโอเพนซอร์สและโปรเจกต์ ก็อาจบิดเบือนการตัดสินใจจ้างงานได้
    • ผู้สมัครที่มีอินเทิร์นชิป 2 แห่งและมีโปรเจกต์โอเพนซอร์ส อาจถูกมองว่าสูงกว่าวิศวกรที่สร้าง S3 และมีประสบการณ์ 30 ปี
    • วิศวกรที่ทำงานสำคัญแต่ไม่ได้ทิ้งร่องรอยไว้บน GitHub อาจเสียคะแนนไปมากกว่าครึ่ง
  • วิศวกรที่มีอำนาจตัดสินใจนำเครื่องมือ AI มาใช้คัดกรองเรซูเม่ ควรระวังว่าเครื่องมือที่แยกคุณภาพไม่ได้ อาจกลายเป็นเพียงอุปกรณ์สำหรับคัดคนออกเท่านั้น

ข้อแก้ไข

  • บรรทัดแรกของเทมเพลต resume_evaluation_criteria.jinja มีคำว่า “Software Intern” อยู่
  • ข้อความนี้ไม่มีการอธิบายไว้ในเอกสาร และไม่ได้ถูกอ้างอิงจากส่วนอื่นของ repository
  • เทมเพลตเดียวกันนี้ยังให้โบนัสกับบทบาทผู้ก่อตั้ง ผู้ร่วมก่อตั้ง และวิศวกรสตาร์ตอัประยะแรกในส่วนถัดไป
  • แม้ใส่พรอมป์ Senior SWE อย่างชัดเจนแล้วรันใหม่ ผลลัพธ์ก็ยังเหมือนเดิม และมิติการให้คะแนนนี้ทำงานโดยไม่เกี่ยวกับระดับตำแหน่งงาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • มีคนจำนวนมากจนน่าตกใจที่ไม่รู้ว่า LLM ทำงานเป็นกระบวนการเชิงความน่าจะเป็นล้วน ๆ เลยดีใจที่ได้เห็นบทความเจาะลึกแบบนี้
    กำลังหางานอยู่ และไม่แน่ว่านี่อาจเป็นเหตุผลว่าทำไมช่วงนี้ถึงยากเหลือเกินที่จะได้ callback เรซูเม่อาจถูกโยนเข้าไปในหลุมดำ LLM สักแห่ง และดูเหมือนไม่มีใครรู้จริง ๆ ว่ามันทำงานอย่างไร
    คำอธิบายในบทความที่ว่า “temperature 0.1 — เป็นค่าต่ำ จึงถือกันว่าช่วยชี้นำโมเดลไปสู่เอาต์พุตแบบกำหนดแน่นอน” นั้นไม่ถูกต้อง temperature ไม่ใช่สวิตช์ความเป็น deterministic แต่เป็นค่าที่มีผลต่อ การกระจายของการสุ่มตัวอย่าง และแม้การกระจายจะคมขึ้น แต่ก็ยังเป็นการกระจายอยู่ดี

    • ในทางทฤษฎี temperature 0 สามารถทำให้ LLM เป็น deterministic ได้
      พูดให้เคร่งครัดกว่านั้น temperature 0 เองไม่มีอยู่จริง ในเชิงคณิตศาสตร์ เมื่อ temperature เข้าใกล้ 0 การกระจายจะยิ่งคมขึ้นเรื่อย ๆ ตัวอย่างที่มีความเป็นไปได้สูงสุดจะเข้าใกล้อนันต์ และตัวอื่น ๆ จะเข้าใกล้ 0
      ในการใช้งานจริง temperature=0 ไม่ได้ใช้สูตรเดียวกับค่าที่ไม่ใช่ 0 แต่จะเป็นกิ่งแยกในคำสั่ง if เพื่อหลีกเลี่ยงการหารด้วยศูนย์ โดยเลือกตัวอย่างที่พบบ่อยที่สุดแทน
      อย่างไรก็ตาม บ่อยครั้งที่ตัวการกระจายความน่าจะเป็นเองเปลี่ยนไปในแต่ละรอบการรัน เนื่องจาก การประมวลผลแบบ batch หรือข้อผิดพลาดเลขทศนิยมของแต่ละ implementation และผลก็คือตัวอย่างที่ได้ต่างกันไปด้วย
    • การทำความเข้าใจข้อความทั้งหมดเป็นปัญหาเรื่อง การอนุมานภายใต้ความไม่แน่นอน เราไม่อาจมั่นใจได้เสมอว่าคนกำลังพูดถึง “witch” แบบไหน และไม่ว่าจะใช้กระบวนการจ้างงานแบบใด คนที่จ้างเข้ามาก็อาจประสบความสำเร็จหรือไม่ก็ได้
      คนสองคนอาจดูเรซูเม่เดียวกันแล้วได้ข้อสรุปเดียวกันก็ได้ และผู้ป่วยสองคนที่มีอาการกับภาพทางคลินิกเหมือนกันก็อาจป่วยคนละโรคกันได้
      คำอธิบายที่ว่า AI ยุคเก่าตายไปส่วนใหญ่เพราะต้นทุนการดูแล knowledge base นั้นผมไม่ค่อยคล้อยตามนัก และมองว่าประเด็นหลักน่าจะเป็นการขาดกรอบการอนุมานสากลที่จัดการความไม่แน่นอนได้มากกว่า
      ส่วนตัวแล้วผมรู้สึกว่า Spock ที่ชอบพูดว่า “กัปตันครับ โอกาสรอดชีวิตในภารกิจนี้คือ 21%” อะไรทำนองนั้น เป็นเหมือนมุกซ้ำ ๆ ในมุมมองแบบเบย์เซียน แม้แต่การกระจายความน่าจะเป็นก็ยังมีการกระจายความน่าจะเป็นอีกที ดังนั้น “โอกาสรอดชีวิตในภารกิจนี้คือ β(5,1)” น่าจะใกล้เคียงกว่าด้วยซ้ำ
      ในแง่นั้น การเอาเรซูเม่ใส่เครื่องนั้น 100 ครั้งแล้วดู การกระจายความน่าจะเป็นของคะแนน ก็ไม่ได้แปลกขนาดนั้น
      [1] ถึงอย่างนั้น ผมก็เป็นคนบ้าประเภทที่นอนอยู่บนเตียงจัดระเบียบรูปภาพบนแท็บเล็ตไปเรื่อย ๆ จนระบบการมองเห็นรวน
    • ขอพูดให้ชัดเจนว่า temperature 0 เป็น deterministic และสำหรับอินพุตที่เหมือนกันทุกประการ ไม่ว่าจะเลือก seed ใดก็จะให้เอาต์พุตเดียวกัน
      แต่ถ้าเป็น MoE อินพุตที่ซ้ำกันต้องเหมือนกันทั้ง batch ด้วย เพื่อนบ้านใน batch อาจส่งผลต่อการเลือก expert ได้
      kernel ต้องเป็น deterministic และในโมเดลแบบ reasoning ต้องไม่มีสวิตช์ระดับ effort ของระบบที่ตอบสนองต่อสิ่งอย่างโหลดรวมของคลัสเตอร์
      สรุปคือ บนโครงสร้างพื้นฐานคลาวด์แบบเดิม temperature 0 ก็คงไม่ deterministic จริง ๆ แต่ในการ inferencing บน edge น่าจะ deterministic ได้ค่อนข้างเสถียร
      สำหรับคำพูดที่ว่า 0.1 deterministic กว่านั้น ผมมองว่าเป็นสรุปที่สมเหตุสมผลอยู่มาก ที่ temperature 0.1 เราน่าจะสุ่มได้ “คำตอบของ temperature 0” บ่อยกว่า temperature 0.9 มากไม่ใช่หรือ?
    • ผมมีเพื่อนร่วมงานที่เรียกตัวเองว่าผู้เชี่ยวชาญ AI หลายคนที่พูดเรื่องนี้ซ้ำเหมือนเป็นคัมภีร์
      ได้ยินคำว่า “ถ้าอยากได้ผลลัพธ์ที่สม่ำเสมอ ให้ตั้ง temperature เป็น 0” มานับครั้งไม่ถ้วน
    • การกระจายที่มวลความน่าจะเป็นทั้งหมดไปรวมอยู่ที่ผลลัพธ์เดียวถือเป็น deterministic ดังนั้นโดยหลักการแล้ว หากตั้ง temperature เป็น 0 ก็ควรได้เอาต์พุตแบบ deterministic
      มีเหตุผลอยู่สองสามข้อที่อาจทำให้ไม่เป็นเช่นนั้น แต่ในกรณีที่รัน โมเดล local แบบที่ผู้เขียนทำ ผมคิดว่าเหตุผลเหล่านั้นใช้ไม่ได้

  • เมื่อรวมแนวโน้มที่ AI มักจะ “ชอบ” โค้ดที่ AI สร้างขึ้นเองเข้ากับอคติอื่น ๆ วิธีแบบนี้จึงมีความเป็นไปได้สูงว่าจะผิดกฎหมายอย่างมากใน EU เพราะละเมิด กฎหมายห้ามการเลือกปฏิบัติ ได้หลายทาง
    การคัดทิ้งแบบสุ่มเพราะมีเรซูเม่มากเกินไป โดยทั่วไปน่าจะถือว่ายอมรับได้ แต่ต้องเป็นการสุ่มจริง ๆ และต้องเป็นอิสระจากเนื้อหาในเรซูเม่
    ในกรณี AI ความสุ่มไม่ได้เป็นอิสระจากการประเมินเรซูเม่จริง ๆ จึงเข้าข่ายนั้นไม่ได้
    โดยทั่วไปเราไม่สามารถรับประกันได้ว่า AI จะไม่ใช้อคติเชิงระบบ และยังมีสัญญาณชัดเจนว่ามีโอกาสสูงที่จะเป็นเช่นนั้นจริง
    สำหรับมนุษย์ เราสามารถฝึกและสั่งให้ละเลยอคติได้ แน่นอนว่าสิ่งนั้นก็ไม่ได้ทำงานได้อย่างเสถียรนัก แต่อย่างน้อยก็กลายเป็นโครงสร้างที่ผลักความรับผิดชอบของอคติที่ผิดกฎหมายไปยังผู้สรรหาที่ฝ่าฝืนคำสั่ง
    ในทางกลับกัน เมื่อใช้ AI ผู้ใช้ต้องรับผิดชอบไม่ว่าจะสั่งอะไรไปก็ตาม ในบริบทเฉพาะ ยังสามารถ “แสดงให้เห็นหรือพิสูจน์” ทางเทคนิคได้ว่า AI ตัวหนึ่งมีอคติรุนแรง สำหรับพนักงานมนุษย์ก็เป็นไปได้ในเชิงเทคนิคเช่นกัน แต่ในทางปฏิบัติแทบไม่ง่ายเลย
    สุดท้าย ความเสี่ยงทางกฎหมายจึงย้ายจากระดับ “เป็นรายบุคคลและโดยมากปฏิเสธได้” ไปสู่พื้นที่ของ อคติที่พิสูจน์ได้อย่างเป็นระบบ กล่าวอีกอย่างคือ ถ้ารู้ว่ามีการใช้ AI ในการจ้างงาน ผู้คนก็จะสามารถโจมตีทางกฎหมายได้อย่างเป็นระบบ

    • ทุกสิ่งมีสหสัมพันธ์กับทุกสิ่ง [1]
      กล่าวคือ มองในเชิงคณิตศาสตร์ล้วน ๆ ก็มีโอกาสสูงที่สิ่งนี้จะสัมพันธ์กับเชื้อชาติ เพศ และกลุ่มที่ได้รับความคุ้มครองอื่น ๆ ในสหรัฐฯ ไม่ทางใดก็ทางหนึ่ง
      ดังนั้นแม้ในสหรัฐฯ แค่คดีความดี ๆ สักคดีก็อาจทำให้มันผิดกฎหมายได้ ไม่จำเป็นต้องชนะคดีเสมอไป แค่ยืนหยัดในศาลได้นานพอ ก็ทำให้บริษัทอื่น ๆ กลัวที่จะใช้สิ่งนี้ได้แล้ว
      ผมไม่อยากอยู่ในฐานะจำเลยที่ต้องพิสูจน์ว่าเครื่องคัดกรอง AI ของผมปฏิบัติตามกฎหมายการจ้างงานทั้งหมดอย่างครบถ้วน มันคงเหมือนฝันร้าย
      [1]: https://gwern.net/everything
    • การคัดเรซูเม่ทิ้งด้วยวิธีที่สุ่มอย่างสมบูรณ์และเป็นอิสระจากเนื้อหานั้นไม่เป็นปัญหาเลย
      การหยิบเรซูเม่ใบที่สี่จากกองแล้วเสนองานให้คนนั้น เป็นวิธีตัดสินใจจ้างงานที่โง่ แต่ยุติธรรมโดยสมบูรณ์
      แต่ AI เก่งมากในการ จับอคติ ดังนั้นถ้าสั่งให้คัดเรซูเม่ ก็ไม่น่าแปลกใจแม้มันจะใช้ปัจจัยที่ไม่ควรถูกใช้เป็นเกณฑ์เด็ดขาด เช่น ชื่อผู้สมัคร มาเป็นเกณฑ์
      อาจเป็นกรณีที่เรซูเม่ซึ่งเขียนว่าเคยแก้คำผิดในโปรเจกต์โอเพนซอร์สขนาดใหญ่ผ่านทั้งหมด แต่เรซูเม่ที่ระบุแค่โปรเจกต์ของตัวเองมีโอกาสถูกตัดทิ้ง 60% แบบนี้ก็เป็นได้ ถ้าเป็นอย่างนั้น คุณจะเสียผู้สมัครที่ดีมากกว่าผู้สมัครที่แย่
    • ผมไม่แน่ใจว่าการพิสูจน์ว่าสิ่งนี้ละเมิด ข้อกำหนดการไม่เลือกปฏิบัติ ด้านการจ้างงานอย่าง Council Directive 2000/78/EC จะง่ายขนาดนั้นหรือไม่
      ผมเห็นด้วยว่ามันอาจมีผลเป็นการเลือกปฏิบัติทางอ้อมที่ไม่ต้องการ เพราะทำงานเหมือนเครื่องพนันที่ไร้เหตุผล แต่คงไม่ง่ายนักที่จะทำให้เห็นว่ามันเลือกปฏิบัติโดยอาศัย “ศาสนาหรือความเชื่อ ความพิการ อายุ หรือรสนิยมทางเพศ” เป็นเหตุ อาจเป็นไปได้ แต่ทนายต้องทำงานหนักมากเพื่อพิสูจน์ในศาล
      ส่วนที่น่าสนใจกว่าคือ EU AI Act แม้ส่วนนี้ยังไม่เริ่มบังคับใช้จนถึงวันที่ 2 ธันวาคม 2027 แต่ระบบ AI ที่ใช้ในการจ้างงานหรือการคัดเลือกบุคคลธรรมดา โดยเฉพาะระบบที่ใช้วางโฆษณารับสมัครงานแบบเจาะกลุ่ม วิเคราะห์และกรองใบสมัคร หรือประเมินผู้สมัครนั้น เป็น ระบบ AI ความเสี่ยงสูง อย่างชัดเจน
      ไม่ได้หมายความว่าถูกห้ามใช้ แต่ในภายหลัง LLM อาจถูกยกเว้นจากกรณีใช้งาน AI ความเสี่ยงสูงก็ได้ เพราะอาจเข้าข่าย Article 6 โดยไม่มีข้อยกเว้น
      ในสถานการณ์ที่มาตรฐานยังไม่เผยแพร่ ผมนึกไม่ออกเลยว่าจะทำให้การใช้ LLM กับงานแบบนี้เป็นไปตามส่วนต่อไปนี้ของ Article 10 ได้อย่างไร
      “(f) ตรวจสอบอคติที่อาจส่งผลต่อสุขภาพและความปลอดภัยของบุคคล ส่งผลเสียต่อสิทธิขั้นพื้นฐาน หรืออาจนำไปสู่การเลือกปฏิบัติที่กฎหมาย EU ห้ามไว้ โดยเฉพาะเมื่อผลลัพธ์ข้อมูลมีผลต่ออินพุตของงานในอนาคต
      (g) มาตรการที่เหมาะสมในการตรวจจับ ป้องกัน และบรรเทาอคติที่อาจเกิดขึ้นซึ่งระบุได้ตาม (f)”
      ณ ตอนนี้ ผมมองว่าในทางเทคนิคเป็นไปไม่ได้สำหรับ LLM ทั่วไป แม้ผู้ให้บริการโมเดลจะให้ความร่วมมือเต็มที่ก็ตาม โมเดลขนาดเล็กอาจตรวจสอบอย่างมีความหมายได้บ้าง
      ท้ายที่สุด EU AI Act อาจตัดแนวทางแบบ vibe coding ที่ “ก็ใช้ LLM อยู่ แต่ไม่ค่อยรู้ว่าทำไมถึงใช้” ออกไปทั้งหมดจากกรณีใช้งานความเสี่ยงสูงใน Annex III และนั่นก็ดูสมเหตุสมผล
      https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    • โดยทั่วไปผิดกฎหมายตาม GDPR Article 22
      “เจ้าของข้อมูลมีสิทธิที่จะไม่ตกอยู่ภายใต้การตัดสินใจที่อาศัยการประมวลผลอัตโนมัติเพียงอย่างเดียว รวมถึงการทำโปรไฟล์ ซึ่งก่อให้เกิดผลทางกฎหมายต่อบุคคลนั้น หรือส่งผลกระทบอย่างมีนัยสำคัญในลักษณะใกล้เคียงกัน”
      ข้อยกเว้นใน 22(2) นำมาใช้ได้ยาก ยากที่จะอ้างว่าจำเป็นจริง ๆ และในบริบทการจ้างงาน ความยินยอมก็แทบจะเกิดขึ้นไม่ได้ อาจเป็นไปได้หากมีกฎหมายเฉพาะของ EU หรือของรัฐสมาชิกอนุญาตไว้ แต่ก็ต้องมีฐานทางกฎหมายแยกต่างหาก

  • ถึงจุดนี้ คงเอามุกที่ว่า “ไม่อยากจ้างคนดวงไม่ดี ก็เลยหลับตาทิ้งเรซูเม่ไปครึ่งหนึ่ง” มาใช้จริงได้เลย

    • ในอดีต Barts and The London School of Medicine and Dentistry ซึ่งเป็นคณะแพทย์สำคัญแห่งหนึ่งของอังกฤษ และเป็นส่วนหนึ่งของ Queen Mary University of London เคยนำ การคัดเลือกแบบสุ่ม มาใช้กับผู้สมัครที่มีคุณสมบัติครบถ้วน
      วิธีนี้เป็นประโยชน์ต่อผู้สมัครที่มีคุณสมบัติครบแต่มีพื้นฐานไม่ร่ำรวย มากกว่านักเรียนที่มีทรัพยากรพอจะวางกลยุทธ์เจาะเกณฑ์การประเมินเรซูเม่แบบใช้แรงคนซึ่งซับซ้อนขึ้นเรื่อย ๆ ในตอนนั้น
      มีการรณรงค์อย่างเป็นระบบในทำนองว่า “จะเลือกหมอในอนาคตด้วยการพนันหรือ?” และท้ายที่สุดระบบจับสลากก็ถูกยกเลิกไปอย่างเงียบ ๆ
    • ปริมาณโชคตลอดชีวิตของคนหนึ่งคนมีค่าคงที่
      ผู้สมัครอีกครึ่งที่เหลือได้ใช้โชคบางส่วนไปแล้วในการคัดเลือกรอบนี้ ดังนั้นโดยเฉลี่ยแล้วพวกเขาจะโชคดีน้อยกว่าครึ่งที่ถูกทิ้งไป
    • ประเด็นสำคัญกว่านั้นคือ ปกติแล้วมีผู้สมัครที่มีคุณสมบัติเหมาะสมมากกว่าตำแหน่งงานอยู่มาก
      ตลอดหลายสิบปีที่ผ่านมา การฝึกอบรมและการศึกษาได้ขยายตัวอย่างมาก ทำให้จำนวนผู้หางานเพิ่มขึ้นต่อเนื่อง แต่การสร้างงานตามไม่ทันความเร็วเดียวกัน
    • การคัดกรองเรซูเม่ด้วย LLM อาจเป็นอาการของปัญหาที่ใหญ่กว่า
      เมื่อมีผู้สมัครหลายสิบคนต่อหนึ่งตำแหน่งงาน นายจ้างจะคัดเรซูเม่แบบเละเทะหรือทิ้งไปครึ่งหนึ่ง ก็ยังสามารถจ้างคนที่มีคุณสมบัติเหมาะสมได้

  • “ฉันมีโอกาสถูกคัดออก 65% ด้วยเรซูเม่ฉบับเดียวกันเป๊ะ แต่ดวงคนละแบบ” ผลลัพธ์แบบนี้ ถ้ามองจากมุมของคนที่เคยดูแล pipeline การจ้างงานสายเทคนิคในช่วงไม่กี่ปีที่ผ่านมา จริง ๆ แล้วถือว่าเป็นตัวเลขที่ยอดเยี่ยม
    พูดแบบนี้แล้วไม่ชอบเลยในเชิงวัตถุวิสัย แต่มันคือเรื่องจริง
    โอกาส 35% ที่จะดันคนสายเทคนิคไปขั้นถัดไปได้โดยไม่ต้องลงแรงเนี่ยนะ? ต่อให้ใส่คำถามคัดกรองเฉพาะโดเมนเข้าไป ผมก็เคยเห็นผู้สมัครมากกว่า 100 คนต่อชั่วโมง แบบนั้นก็เท่ากับได้ผู้สมัครที่ “คัดกรองแล้ว” 35 คนต่อชั่วโมง
    มีผู้สมัครที่ใช้ได้ถูกกรองออกไปไหม? ใช่ แต่คุณยังจะได้ pool ผู้สมัครที่ใหญ่กว่าที่ต้องการ 35 เท่าไหม? น่าเสียดาย แต่ก็ใช่อีกเหมือนกัน
    จำนวนผู้สมัครเยอะเกินไป จนถ้าไม่มี AI เข้ามาเกี่ยวข้อง โอกาสที่จะผ่านไปขั้นถัดไปกลับยิ่งต่ำกว่านี้มาก ถ้าคุณไม่ได้สมัครทันที แถมไม่ได้ใช้บอต AI สมัครด้วย ก็จะมีคนมากกว่า 50 คนอยู่ข้างหน้าคุณ และ tech lead ที่เหนื่อยล้าต้องไปถึงเรซูเม่ของคุณให้ได้สักวันหนึ่ง
    โบนัสจากการแนะนำคน มีอยู่ด้วยเหตุผลของมัน

    • ถ้าอย่างนั้น ผมมีระบบคัดกรองล่วงหน้าที่จะขายให้
      ด้วยเทคโนโลยีล่าสุด เราจะปล่อยให้เฉพาะ 1% ของใบสมัครที่ดีที่สุด* ผ่านเท่านั้น
      *ตามตัวชี้วัดเฉพาะกรรมสิทธิ์ ไม่เปิดเผย และไม่เป็นแบบกำหนดแน่นอนของเรา ซึ่งอาจจะเป็น Math.random หรือไม่ก็ได้
    • จริงหรือ? หรือเป็นเพราะเรซูเม่มีโอกาส 65% ที่จะถูกมองข้ามก่อนที่มนุษย์คนใดจะได้เห็น ทำให้ pipeline การจ้างงานมี โอกาสจับผู้สมัครที่มีคุณสมบัติเหมาะสม ลดลงในอัตราเดียวกัน?
      ด่านที่ลดปริมาณเรซูเม่ที่ไหลเข้าจะมีประโยชน์ก็ต่อเมื่อการลดลงนั้นสัมพันธ์กับคุณภาพ ไม่อย่างนั้นก็แค่ทำให้กระบวนการจ้างงานยืดเยื้อ หรือสุดท้ายทำให้ต้องลดมาตรฐานการจ้างงานลงโดยไม่จำเป็น
    • วิธีแก้เชิงตรรกะคือให้ผู้สมัครเปลี่ยนข้อมูลติดต่อเล็กน้อยแล้วสมัครหลายครั้ง
      เช่น “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt” อะไรทำนองนั้น
    • ถ้าไม่มีข้อกำหนดเรื่องความแม่นยำ ก็แค่สุ่มเอาผู้สมัคร 35% ผ่านไปขั้นถัดไปก็พอ
      ถ้าผู้สมัคร 50 คนแรกเป็นบอตทั้งหมด แล้วทำไมถึงยังอ่านเรซูเม่ตาม ลำดับการสมัคร อยู่ล่ะ?

  • สิ่งที่น่ากังวลกว่าคือ ถ้าระบบอื่น ๆ ทำงานเหมือน ATS ตัวนี้ มันดูเหมือนจะตัดสินจากปัจจัยที่ทำให้ผู้สมัครที่ค่อนข้างดีหรือดีจำนวนมากถูกคัดออก
    ตัวอย่างเช่น การมีทั้งโปรเจกต์ส่วนตัวและการมีส่วนร่วมในโอเพนซอร์สถูกให้ 65 คะแนน ถ้าเทคโนโลยีเป็นสิ่งเดียวที่คุณสนใจ และไม่มีครอบครัว ผู้ที่ต้องดูแล หรืองานที่สองหรืองานที่สาม นั่นก็อาจจะดี
    แต่ถ้ามีสักอย่างในนั้น โอกาสก็ดูเสียเปรียบอย่างมหาศาล
    เลยสงสัยว่าระบบพวกนี้ถูกออกแบบมาให้เอื้อกับ คนร่ำรวย มากแค่ไหน—คนที่ไม่มีเรื่องต้องกังวลนอกจากเรียนมหาวิทยาลัยหรือทำงานเดียวในอุตสาหกรรมที่ต้องการ และสามารถหมกมุ่นกับเทคโนโลยีได้แทบจะถึงระดับความสนใจเฉพาะทาง

    • การให้ค่าน้ำหนักกับโปรเจกต์ส่วนตัวและโปรเจกต์โอเพนซอร์สมากเกินไปเป็นเรื่องน่ากังวลและไม่ค่อยดี
      เอาตัวผมเองเป็นตัวอย่าง นอกเวลางานผมแทบไม่ทำโปรเจกต์ส่วนตัวเลย ประสบการณ์การเขียนโปรแกรมจริงทั้งหมดคือสิ่งที่ทำให้กับนายจ้างในเวลางาน
      งานอดิเรกของผมเป็นเรื่องใกล้เทคโนโลยี เช่น 3D printing, ฮาร์ดแวร์/Arduino, การถ่ายภาพ แต่ไม่ใช่สายที่สร้างโปรเจกต์ลง GitHub เต็มไปหมด
      และผมจะไม่มีวันสร้างแอป CRUD หรือ SaaS ปลอม ๆ เพื่อเอาไปโชว์นายจ้างที่อาจจะจ้างผมด้วย นั่นเสียเวลา
      ผมตั้งใจไม่สร้างตัวตนออนไลน์แบบนั้นเลย GitHub ของผมไม่มี repository สาธารณะ และผมก็ไม่เขียนบล็อก
      แนวโน้มนี้ลามไปถึงสายงาน operations/การดูแลระบบที่ผมทำอยู่ด้วย และในฝั่งนั้นยิ่งหนักกว่าเดิมอีก แน่นอนว่าผมไม่ได้เอาสคริปต์เฉพาะสภาพแวดล้อมมากมายไปลง GitHub แล้วทำไมต้องทำด้วย? มันไม่มีความหมายอะไรสำหรับคนที่ไม่ได้ทำงานในแผนกของผมที่บริษัทปัจจุบัน

  • คำว่า determinism มีพลังวิเศษในการบิดเบือนบทความออนไลน์ทุกชิ้นที่มันไปแตะ
    พอได้ยินคำนั้น แทบจะรับประกันได้เลยว่าจะพาไปผิดทาง แต่ครั้งนี้อย่างน้อยก็พูดถึง determinism จริง ๆ ในความหมายว่า input เดียวกันให้ output เดียวกัน ไม่ใช่เรื่องอื่นที่ไม่เกี่ยวข้อง
    determinism สำคัญต่อการทำซ้ำผลได้ แต่ในกรณีนี้ คุณอยากให้ output ทำซ้ำได้จริงหรือ? การทำให้ output ของ LLM เป็น deterministic นั้นค่อนข้างจิ๊บจ๊อย ถ้าใช้ batching ก็ใช้ kernel ที่ไม่เปลี่ยนตาม batch และตั้ง temperature เป็น 0—หรืออย่าทำแบบนั้น เพราะ random sampling มีเหตุผลของมัน—ทางที่ดีกว่าคือ fix seed ซึ่งในบางระบบก็ทำได้อยู่แล้ว
    แต่นั่นไม่ได้ทำให้ผลลัพธ์มีประโยชน์มากขึ้น มันแค่ปิดบังข้อเท็จจริงว่า agent ไม่ได้มั่นใจจริง ๆ ดูช่วงคะแนนสิ มันยังทำนายอะไรไม่ได้อยู่ดี เพียงแต่คะแนนจะเหมือนเดิมทุกครั้ง คุณต้องการแบบนั้นจริงหรือ?
    สิ่งที่เกิดขึ้นตรงนี้คือให้ข้อมูลน้อยเกินไป ให้แค่เรซูเม่หนึ่งฉบับที่แทบจะเป็น noise แล้วคาดหวังคำตอบที่มีนัยกว้างเกินไป
    นี่เป็นความผิดพลาดด้านการออกแบบพื้นฐาน ไม่ว่าจะใช้ LLM หรือไม่ก็ตาม แบบสำรวจ การสอบ กฎหมาย ระบบลงคะแนนเสียงทั้งหมดล้วนไวต่อ framing อย่างยิ่ง เพราะทำงานด้วยข้อมูลที่น้อยเกินไป เพียงแต่ว่าสิ่งเหล่านั้นไม่ได้อยู่ในสุญญากาศเหมือนของชิ้นนี้

    • ความไม่เป็น deterministic ไม่ได้แปลว่าไม่สามารถไปถึง output ที่ถูกต้องได้อย่างเสถียร แน่นอนว่าบางครั้งมันอาจแปลแบบนั้นได้
      Las Vegas algorithm เป็นแบบไม่ deterministic แต่ถูกต้อง 100% เพียงแต่แลกกับเวลาที่ใช้ไปถึงคำตอบซึ่งแตกต่างกันได้มาก
      ความผิดพลาดตรงนี้ไม่ใช่การใช้ระบบที่ไม่ deterministic ในบางแง่ ความผิดอาจเป็นการใช้มันน้อยเกินไปด้วยซ้ำ การให้ประเมินเรซูเม่ฉบับเดิมซ้ำ 5 ครั้งแล้วดูว่าคะแนนกระจายมาก เป็นสัญญาณที่มีประโยชน์กว่าการประเมินเพียงครั้งเดียว
    • เป็นที่รู้กันดีว่าผู้พิพากษาและผู้คุมสอบที่เป็นมนุษย์ก็ไม่ได้ deterministic อย่างที่เราหวัง
      ทุกคนคงเคยได้ยินเรื่องที่ว่าชั่วโมงก่อนมื้อเที่ยงมักมีการตัดสินโทษหนักกว่า
    • ความไม่เป็น deterministic ไม่ได้เป็นบั๊กเท่านั้น แต่ยังเป็นฟีเจอร์ได้ด้วย
      ถ้าต้องการไม่ให้ผู้คน optimize ตัวเองให้เข้ากับกระบวนการคัดกรอง ก็ต้องทำให้มันไม่ deterministic ในระดับหนึ่ง
      เช่น แทนที่จะตัดเส้นเป๊ะ ๆ ที่ 100 อันดับแรก ก็ทำให้ผู้สมัครที่ดีกว่ามีโอกาสผ่านตัวกรองเพิ่มขึ้นแบบ exponential
      แบบนั้นจะลดความคุ้มค่าของการเล่นงานกระบวนการคัดกรองแบบ Goodhart เพราะโอกาสเพิ่มขึ้นแทบไม่มาก และยังมีที่อื่นอีกมากที่ใช้เวลาได้คุ้มกว่ามาก

  • ถ้าโมเดลพื้นฐานคือ gemma3:4b ก็ถือว่าเป็นโมเดลที่เล็กมาก
    LLM ใด ๆ ก็คงไม่ใช่กรรมการที่สมบูรณ์แบบและให้ผลซ้ำได้ทุกครั้งอยู่แล้ว แต่การเอา โมเดล 4B มาเสียบกับระบบแบบนี้ก็คล้ายกับต่อเครื่องสุ่มตัวเลขเข้าไป
    การทดลองทั้งหมดให้ความรู้สึกเหมือนมีใครบางคนอยากทำโปรเจกต์ ATS แบบโอเพนซอร์ส เลยใช้ vibe coding ทำ ATS ขึ้นมา แล้วปรับแค่ให้เทสต์ผ่านเท่านั้น

    • โมเดลแบบนี้ถ้าใช้อย่างถูกวิธีก็โอเคกับปัญหาเล็ก ๆ ได้
      น่าจะมีวิธีวิเคราะห์เรซูเม่ที่ใช้โมเดลนี้แล้วทำงานได้ดีอยู่ แต่ไม่ใช่วิธีประมาณว่า “เฮ้ เจ้าเศษเหล็ก คนนี้เคยทำโปรเจกต์อะไรบ้าง?”
      ต้องมีการดึงข้อมูล การจัดระเบียบ อาจต้องเปรียบเทียบผ่าน OCR และจัดระเบียบเพิ่มเติม วิเคราะห์ด้วย LLM หลายรอบแยกตามสัญญาณ และมีตัวตัดสิน
      ไม่มีส่วนไหนจำเป็นต้องเป็นโมเดลใหญ่เลย ใช้โมเดลใหญ่ก็อาจดีขึ้นเล็กน้อย แต่เพราะบริบทมีน้อยมาก หากใช้อย่างถูกต้อง โมเดลแบบนี้ก็อาจทำงานได้ดี

  • ได้ลองรัน ATS เองแล้วเจอประสบการณ์ประหลาดคล้ายกัน
    มันหาโปรไฟล์ GitHub ของผมไม่เจอ เลยได้คะแนนช่วง 70 กว่า ๆ จากนั้นก็ไม่ค่อยชอบ ไลบรารี Ruby ที่ค่อนข้างเป็นที่รู้จักหลายตัวที่ผมสร้าง
    หลังรันไปสองสามครั้งมันถึงเริ่มรู้จักได้เหมาะสมขึ้น แต่ส่วนวุฒิการศึกษาอย่างเป็นทางการโดนหักคะแนนตลอด
    แบบนี้น่าขยะแขยง

    • เจอประสบการณ์คล้ายกันเลย บางรอบได้ประมาณ 65 คะแนน เพราะมันไม่ชอบที่ไม่มี contribution โอเพนซอร์ส
      มันตรวจไม่เจอใบรับรองหรือรางวัลด้วย ผมลองนำ PR บางอันที่คนเสนอการปรับปรุงมาใช้แล้ว (https://github.com/Zem-0/hiring-agent) ก็ช่วยได้บ้าง แต่โดยรวมแล้ว ATS ตัวนี้ลำเอียงอย่างมากไปทางคนที่มี contribution โอเพนซอร์สบน GitHub ขนาดใหญ่

  • ผมแปลกใจเสมอที่บริษัทเทคโนโลยียอมจ่ายมากกว่า 300,000 ดอลลาร์เพราะบอกว่าวิศวกรเก่ง ๆ หายาก แต่เอาเข้าจริงรีครูตเตอร์กลับต้องทำงานโดยไม่มีการสนับสนุน และแต่ละคนก็มีเกณฑ์เรื่อง “ผู้สมัครที่ดี” ต่างกันโดยสิ้นเชิง
    ATS ส่งเรซูเม่มากกว่า 50% ลงหลุมดำด้วย heuristic การกรองห่วย ๆ ทีมจ้างงานเลือก ATS เพราะเหตุผลอย่างการเชื่อมต่อกับ Google Gmail และเทคโนโลยีการกรองของ ATS นั้นก็ไม่ได้ผ่านการตรวจสอบจากใครในทีมวิศวกรรมหรือทีมข้อมูลเลย

  • ลองกับเรซูเม่ของผมแล้ว somehow ได้ คะแนนโบนัส GSoC
    BONUS POINTS: 5.0
    ------------------------------
    Google Summer of Code (GSoC) participation: +5
    แต่ผมไม่เคยทำ GSoC และไม่ได้เขียนไว้ในเรซูเม่ว่าเคยทำ