ทดสอบเรซูเม่ Google Docs กับระบบ Open-source Parser
เจาะลึกการทดสอบเรซูเม่จาก Google Docs บน Open-source Parser เผยปัญหาฟอนต์ ลิกาเจอร์ และการแบ่งหน้าPDF ที่แคนดิเดตต้องรู้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- นักพัฒนาทดสอบเรซูเม่จาก Google Docs ผ่านโปรแกรม Open-source Parser
- พบปัญหาการแปลงฟอนต์ ลิกาเจอร์ (fi, fl) และช่องว่างที่หายไปในหลายฟอนต์
- มีเพียง 9 จาก 32 ฟอนต์ที่ผ่านการทดสอบความถูกต้องครบถ้วนทุก 46 ฟิลด์
คำแนะนำเรื่องเรซูเม่มักจะพูดถึงคำว่า ATS-friendly อยู่บ่อยครั้ง แต่แทบไม่เคยมีใครแสดงให้เห็นเลยว่าระบบตัวแยกแยะข้อมูลหรือ Parser ดึงข้อมูลอะไรออกมาจากไฟล์จริงบ้าง เจ้าของแม่แบบเรซูเม่บน ReadableResume จึงต้องการหาคำตอบในประเด็นแคบๆ ว่า หากมีคนกรอกข้อมูลลงในแม่แบบแล้วคลิกดาวน์โหลดเป็น PDF ผ่านเมนู File > Download ฟิลด์ไหนที่ Parser อ่านถูกต้อง และฟิลด์ไหนที่อ่านผิดพลาด
เนื่องจากไม่สามารถทดสอบเรซูเม่กับระบบจริงอย่าง Workday หรือ Greenhouse ได้โดยตรง จึงต้องสร้างเครื่องมือทดสอบที่สามารถควบคุมและรันซ้ำได้เอง โดยสคริปต์จะทำการดาวน์โหลดไฟล์ PDF และ .docx ผ่าน URL ส่งออกสาธารณะของ Google Docs โดยไม่ต้องเข้าสู่ระบบ ซึ่งไฟล์ผลลัพธ์ทั้งหมดถูกจัดเก็บไว้ในที่เก็บโค้ด (repository)
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในส่วนของการตรวจสอบข้อความ เครื่องมือจะทำการเช็กทั้งตัวอักษรลิกาเจอร์ (Ligature) เช่น ตัวอักษร fi หรือ fl ที่ถูกรวมเป็นตัวอักษรเดียว รวมถึงตรวจสอบว่ามีคำใดถูกตัดแบ่งเป็นสองส่วน ลำดับข้อความสลับกัน หรือมีข้อความตกค้างหลังจากดึงข้อมูลที่คาด Wหวังออกหมดแล้ว นอกจากนี้ยังมีการตรวจสอบไฟล์ .docx ผ่านห้องชุดคำสั่ง python-docx เพื่อให้มั่นใจว่ารายการแบบจุด (bullet) ยังคงเป็นรายการจริง ไม่ถูกเปลี่ยนไปใช้ฟอนต์ Symbol หรือ Wingdings และไม่มีตารางหรือกล่องข้อความหลุดรอดไป
จากการทดสอบฟอนต์ทั้งหมด 32 แบบ บนเรซูเม่หน้าเดียวของแม่แบบ Jake's Resume โดยใช้กระดาษขนาด US Letter พบว่ามีเพียง 9 ฟอนต์เท่านั้นที่อ่านค่าความถูกต้องครบถ้วนทั้ง 46 ฟิลด์ ได้แก่ Arial, Book Antiqua, Calibri, Cambria, EB Garamond, Garamond, Georgia, Times New Roman และ Trebuchet MS โดยฟอนต์เหล่านี้สามารถแสดงผลตัวอักษรที่มองเห็นได้ครบถ้วน และหน้าเอกสารไม่ล้นเกินหนึ่งหน้า
การทดสอบนี้สะท้อนให้เห็นข้อจำกัดทางเทคนิคที่คนทำเรซูเม่มักมองข้าม แม้หน้าตาเอกสารใน Google Docs จะสวยงามและจัดหน้ามาอย่างดี แต่กลไกการแปลงไฟล์ PDF ของระบบคลาวด์มักแอบซ่อนความผิดพลาดระดับอักขระ เช่น การยุบรวมตัวอักษรหรือปัญหาช่องว่าง ซึ่งส่งผลโดยตรงต่อระบบ ATS (Applicant Tracking System) ขององค์กรใหญ่ๆ ที่ใช้ซอฟต์แวร์สกัดข้อความอัตโนมัติ การเลือกใช้ฟอนต์มาตรฐานจึงเป็นด่านแรกที่ช่วยลดความเสี่ยงในการถูกปัดตกโดยไม่รู้ตัว
ปัญหาสำคัญประการหนึ่งที่พบคือ ฟอนต์ถึง 16 แบบทำการจัดเก็บคู่ตัวอักษร (Letter pairs) เป็นตัวอักษรลิกาเจอร์ตัวเดียว เช่น fi และ fl ซึ่งทำให้ Parser มองไม่เห็นคำเต็มหากใช้การจับคู่คำแบบตรงตัว นอกจากนี้ยังมีปัญหาเรื่องช่องว่างที่หายไปในบางฟอนต์ เช่น Lato, Lora, Raleway และ Roboto ทำให้ข้อมูลบางส่วนติดกันและไม่ผ่านเกณฑ์การตรวจสอบ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น