HR Agent Reliability Test: จำอะไร ลืมอย่างไร และแยกงานให้หลาย Agent เมื่อไร

ทำไม Agent ที่ตอบถูกยังอาจไม่น่าเชื่อถือ?

HR agent อาจตอบคำถามสวัสดิการถูกวันนี้ แต่ยังเก็บสถานะครอบครัวที่หมดอายุไว้ อาจลบข้อความต้นฉบับแล้วเหลือใจความใน summary หรือให้เหตุผลคนละเรื่องเมื่อเพิ่ม click ที่ไม่เกี่ยวข้อง ปัญหาเหล่านี้ไม่ปรากฏใน accuracy ของคำตอบครั้งเดียว

ประกาศ Workday AI Research วันที่ 19 สิงหาคม 2026 รวบรวมงานเรื่อง persistent memory, explainability และ multi-agent orchestration ที่ทำให้เห็นว่า reliability มีหลายแกน ความจำมากไม่เท่ากับความจำดี การมี agent หลายตัวไม่เท่ากับ compliance และคำอธิบายที่ลื่นไหลไม่เท่ากับเหตุผลที่เสถียร

สำหรับ HR ความต่างเล็ก ๆ มีผลมาก เพราะ context อาจเป็นข้อมูลสุขภาพ สถานะครอบครัว ผลประเมิน หรือ career interest ถ้าระบบจำผิด ลืมไม่หมด หรืออธิบายเปลี่ยน ผู้รับผลกระทบต้องมีทางแก้และขอให้คนทบทวน

Reliability Test มีสี่ชั้นอะไรบ้าง?

ชั้นที่หนึ่ง Memory Quality ตรวจว่าระบบเก็บข้อมูลที่มีประโยชน์ น่าเชื่อถือ ใหม่ ไม่ซ้ำ และยังสด ชั้นที่สอง Residual Deletion ตรวจว่าคำสั่งลบตามไปถึง summary, cache, vector index, trace และสำเนาที่ agent อื่นได้รับ

ชั้นที่สาม Explanation Stability เปลี่ยน noise ที่ไม่เกี่ยวข้องแล้วเหตุผลหลักควรอยู่ เปลี่ยน evidence ที่สำคัญแล้วเหตุผลควรเปลี่ยน ชั้นที่สี่ Constraint Compliance ตรวจว่า workflow หลาย agent ยังรักษา eligibility, permission, policy และ approval gate ทุกเส้นทาง

สี่ชั้นนี้ต้องวัดแยกจาก task outcome ตัวอย่างเช่นคำแนะนำคอร์สเดิมอาจยังถูก แต่เหตุผลเปลี่ยนจาก skill gap เป็นประวัติ click ที่บังเอิญ หรือระบบอาจทำตามกฎครบแต่ช้าเกิน SLA จนใช้หน้างานไม่ได้

Memory Quality ควรทดสอบอย่างไร?

งาน A-MAC ที่ Workday สรุปใช้ candidate memories ราว 1,500 รายการจาก LoCoMo และถามห้ามิติ: useful, trustworthy, new, fresh และ information type วิธี hybrid ใช้โมเดลตัดสิน usefulness แล้วใช้กฎโปร่งใสตรวจส่วนอื่น รายงานว่า precision สูงขึ้น 12%, overall memory quality ดีขึ้นราว 8%, เก็บ memory สำคัญได้ 97% และเร็วขึ้น 31% เมื่อเทียบทางเลือกที่อ้างอิง

ตัวเลข quality เป็น balance score ไม่ใช่ accuracy percentage และ benchmark ไม่ใช่ข้อมูล HR เราจึงไม่ควรคัด threshold มาใช้ตรง ๆ สิ่งที่นำมาใช้ได้คือ test design: ใส่ข้อมูลซ้ำ ข่าวลือ ข้อมูลเก่า ความชอบชั่วคราว และข้อเท็จจริงที่ขัดกัน แล้วตรวจ keep/drop decision พร้อมเหตุผล

สร้าง gold set ร่วมกับ process owner และ privacy owner ระบุข้อมูลใดห้ามจำ ข้อมูลใดมีอายุ ข้อมูลใดต้องยืนยันจาก system of record และข้อมูลใดเก็บได้เฉพาะเมื่อพนักงานร้องขอ จากนั้นวัด precision, recall, stale-memory rate, unsupported-memory rate และ time/cost ต่อ decision

การลบข้อมูลต้องพิสูจน์ตรงไหน?

ประกาศ Workday ระบุว่างานทดลองพบข้อมูลที่สั่งให้ agent ลืมยังถูกกู้คืนจาก summary เก่าประมาณหนึ่งในห้าครั้ง และต้องลบทุก summary ที่กล่าวถึงข้อมูลนั้นจึงจะลบครบ ประเด็นนี้สำคัญกว่า UI ที่ขึ้นคำว่า deleted

ทำ deletion map ตั้งแต่ source record, prompt history, long-term memory, embedding/vector store, summary, tool log, cache, evaluation dataset และ downstream agent ระบุ retention, owner และวิธียืนยันของแต่ละสำเนา การพิสูจน์ควรใช้ canary fact ที่ไม่ใช่ข้อมูลคนจริงแล้วค้นทั้ง direct query และ indirect inference หลังลบ

อย่าสัญญา right to deletion เกินกว่าสถาปัตยกรรมทำได้ ถ้าบาง log ต้องเก็บเพื่อ security หรือกฎหมาย ให้แยก purpose, access และ retention อย่างโปร่งใส พร้อมทดสอบว่า agent ไม่เรียกกลับมาใช้ในคำตอบปกติ

หลาย Agent ดีกว่าตัวเดียวเมื่อไร?

DualAgent-Rec แบ่ง agent สำรวจทางเลือกกับ agent รักษากฎ และมี coordinator ปรับน้ำหนัก งานที่ Workday สรุปรายงาน accuracy ดีขึ้น 5.8%, final answer ผ่าน constraints ที่กำหนด 100% และคุณภาพดีขึ้นราว 4-6% แต่รุ่นที่มี coordinator ช้ากว่า single-agent ราว 94%

นี่ไม่ใช่หลักฐานว่าทุก HR workflow ควรมีสาม agent เหตุผลที่แยกเหมาะเมื่อ objective ขัดกันและ hard rules ชัด เช่นแนะนำ benefit ที่ต้องสมดุลความเหมาะสม ความหลากหลาย ค่าใช้จ่าย eligibility และข้อกำกับ หากงานเป็น lookup ง่าย การเพิ่ม orchestration อาจเพิ่ม latency, cost และจุดผิดพลาดโดยไม่เพิ่มคุณค่า

กำหนด rule owner ให้เป็นคน ไม่ปล่อย agent นิยามกฎเอง เก็บ trace ว่า agent ใดเสนออะไร coordinator เปลี่ยนทิศเพราะเหตุใด และ final approval อยู่ที่ใคร ถ้าระบบหาทางเลือกที่ผ่านกฎไม่ได้ ต้องหยุดหรือส่งต่อคน ไม่ผ่อนกฎเงียบ ๆ

Explanation Stability ทำไมต้องแยกวัด?

RobustExplain ทดสอบสี่โมเดลโดยเปลี่ยน activity data ห้าชนิด เช่น irrelevant activity, ลำดับเหตุการณ์, ข้อมูลที่อาจเป็นของอีกคน, preference ที่เปลี่ยน และข้อมูลหาย Workday สรุปว่า explanation consistency เฉลี่ย 0.51 จาก 1 และความรุนแรงของการเปลี่ยนมีผลต่อความไม่เสถียรต่างกันเพียงราว 1.7%

งานใช้ synthetic shopping data ไม่ใช่ HR แต่โจทย์แปลตรงกับ recommendation ที่อาศัยประวัติ: เพิ่ม noise ที่ไม่เกี่ยวข้องแล้วเหตุผลต้องไม่แกว่งมาก เพิ่มหลักฐานสำคัญแล้วเหตุผลต้องเปลี่ยนอย่างสมเหตุผล วัด semantic consistency, evidence citation, sensitivity by perturbation type และ unsupported rationale

อย่ารวมคะแนนคำแนะนำกับคะแนนคำอธิบาย คำแนะนำเดิมอาจบังเอิญเหมือนเดิมขณะที่ rationale เปลี่ยน และโมเดลใหญ่ไม่ได้แก้ปัญหาโดยอัตโนมัติ พนักงานต้องเห็นข้อมูลหลักที่ใช้และส่ง correction ได้

ข้อจำกัดของหลักฐานและการนำมาใช้กับ HR คืออะไร?

งานทั้งสามมาจาก Workday AI Research และถูกสรุปบนช่องทางของผู้ขาย แม้ระบุ conference และ methodology แต่ตัวเลขที่ใช้ในบทความยังควรตรวจ paper ต้นฉบับเมื่อทีมจะตั้ง threshold จริง ที่สำคัญ benchmark เป็น personal/technical conversations หรือ shopping recommendation ไม่ใช่ payroll, benefits, promotion หรือ employee relations

NIST AI RMF แนะนำให้ Map บริบทและผู้ได้รับผลกระทบ, Measure ด้วยวิธีที่เหมาะกับความเสี่ยง และ Manage ด้วยการจัดลำดับและติดตาม กรอบ Reliability Test จึงควรเป็น evidence package ประกอบ use-case risk assessment ไม่ใช่ตราประทับว่า agent ปลอดภัยตลอดไป

เริ่มใน sandbox ด้วยข้อมูลสังเคราะห์ ทำ red-team สำหรับ memory poisoning, cross-user leakage และ deletion failure กำหนด rollback กับ kill switch และทดสอบซ้ำเมื่อ model, prompt, tool, memory policy หรือ data connector เปลี่ยน

Admin ต้องตรวจอะไรบ้างก่อนอนุมัติ?

ตรวจว่าตัวเลข 12%, 8%, 97%, 31%, 5.8%, 100%, 94%, 0.51 และหนึ่งในห้าอ้างเป็นผลของงานทดลองที่ Workday สรุป ไม่เขียนว่าเป็น performance ของ Workday product หรือ HR agent production คงข้อจำกัด dataset ทุกจุด

ตรวจลิงก์ Workday และ NIST, ภาพ hero, direct answer และข้อความเรื่อง human approval ตรวจ meta title และ sourceHighlights ก่อนเปลี่ยนสถานะจาก draft