คำถามว่า “ยังต้องมีคนอยู่ไหม?” มักถูกถามเหมือนเราต้องเลือกอย่างใดอย่างหนึ่งระหว่าง automation กับ human review แต่ในระบบจริง คำถามที่ useful กว่าคือ ควรวางคนไว้ตรงไหน และให้คนตัดสินใจเรื่องอะไร

ถ้าคนต้องตรวจทุก token ระบบจะช้าและคนจะล้า แต่ถ้าปล่อยให้ agent ทำ action ที่ย้อนกลับไม่ได้โดยไม่มี approval ความเสี่ยงอาจสูงเกินไป การออกแบบ Human-in-the-Loop จึงเป็นเรื่องของการวาง control point ไม่ใช่การขอความช่วยเหลือแบบสุ่ม

Human-in-the-loop คือ control point ตามความเสี่ยง

ให้ระบบทำงาน low risk อัตโนมัติ และวางคนไว้ตรง action ที่กระทบสูง ย้อนกลับไม่ได้ หรือหลักฐานไม่พอ

จุดที่ควรเหลือพื้นที่ให้คน

เริ่มจากผลกระทบ ไม่ใช่จากความรู้สึกว่า model ฉลาดแค่ไหน จุดที่ควรพิจารณา human review ได้แก่:

  • irreversible operation เช่น ลบข้อมูล โอนเงิน หรือส่งข้อความออกไปในนามองค์กร
  • high-impact decision ที่กระทบสิทธิ์ รายได้ หรือโอกาสของคน
  • insufficient evidence เมื่อข้อมูลขัดแย้งหรือเก่าเกินไป
  • policy boundary ที่ระบบไม่ควรตีความเอง
  • exception ที่อยู่นอก distribution ของตัวอย่างที่เคยประเมิน

ในทางกลับกัน งานที่อ่านอย่างเดียว ผลกระทบต่ำ และตรวจย้อนหลังได้ อาจให้ระบบทำอัตโนมัติแล้วสุ่ม audit ภายหลังได้

Approval ไม่ใช่ปุ่ม Yes/No ที่ไม่มีบริบท

ถ้าหน้าจอแสดงเพียง “Approve?” คนจะกลายเป็น rubber stamp การขออนุมัติควรแสดงอย่างน้อย:

  1. ระบบกำลังจะทำอะไร
  2. ใช้ข้อมูลหรือ evidence ใด
  3. มี uncertainty หรือ policy conflict ตรงไหน
  4. ผลกระทบและวิธีย้อนกลับคืออะไร
  5. ถ้าไม่อนุมัติ workflow จะไปทางไหน
proposed_action: ส่งอีเมลแจ้งปฏิเสธคำขอ
evidence: policy-v4, case-182
uncertainty: ชื่อผู้รับซ้ำกับอีกหนึ่ง record
reversible: ไม่ได้ หลังส่งแล้ว
decision: ต้องให้เจ้าหน้าที่ตรวจชื่อผู้รับ

ข้อมูลแบบนี้ช่วยให้คนใช้ judgment จริง แทนการยืนยันคำตอบของ model โดยไม่รู้ว่ากำลังยืนยันอะไร

Risk tier ช่วยลดการขออนุมัติเกินจำเป็น

เราอาจแบ่งงานเป็นสามระดับแบบง่าย:

low risk       -> automate + audit
medium risk    -> automate preparation + human approval
high risk      -> human decision, AI assists with evidence

ระดับไม่ควรถูกกำหนดตายตัวจากชื่อ feature อย่างเดียว ต้องดูบริบท ผู้ได้รับผลกระทบ และความสามารถในการย้อนกลับ การสรุป draft อาจ low risk แต่การเผยแพร่ draft ออกสาธารณะอาจกลายเป็น medium หรือ high risk ทันที

Human fallback ต้องถูกออกแบบและวัดผล

การส่งต่อให้คนไม่ใช่การโยน error ไปที่ inbox แล้วจบ ควรมี queue ที่มีเหตุผลของการส่งต่อ ข้อมูลที่คนต้องใช้ และ SLA ที่เหมาะสม ถ้าระบบส่งต่อเกือบทุกครั้ง แปลว่า automation boundary อาจผิดหรือข้อมูลต้นทางไม่พร้อม

เราควรดู escalation rate, approval time, override rate และประเภทของ exception ร่วมกับคุณภาพของคำตอบ ไม่ใช่พยายามลด escalation ให้ต่ำที่สุด เพราะบางระบบ escalation ที่เพิ่มขึ้นในช่วงแรกอาจแปลว่าระบบเริ่มตรวจพบความเสี่ยงที่เคยมองไม่เห็น

สรุป

HITL ยังจำเป็นในจุดที่ความเสียหายสูง ความไม่แน่นอนมีผล และหลักฐานไม่พอ แต่ไม่จำเป็นต้องแทรกคนในทุกขั้นตอน

สิ่งที่ควรจำมีสามข้อ:

  1. วางคนตาม risk, reversibility และ evidence ไม่ใช่ตามความกลัวหรือความสะดวก
  2. approval ต้องแสดง action, หลักฐาน, uncertainty และผลกระทบ
  3. human fallback เป็นส่วนหนึ่งของระบบที่ต้องออกแบบและวัดผล ไม่ใช่ถังรับ error

References

  • NIST — Appendix C: AI Risk Management and Human-AI Interaction (2023): บทบาท ความรับผิดชอบ และเงื่อนไขของ human oversight
  • NIST — Generative AI Profile (2024): ระดับ oversight และ human-AI configuration ที่ควรสอดคล้องกับความเสี่ยง
  • Google PAIR — People + AI Guidebook (2021): แนวทางออกแบบ user control, feedback และการช่วยผู้ใช้เมื่อ automation ผิดพลาด
  • Amershi et al. — Guidelines for Human-AI Interaction (CHI 2019): งานวิจัยแนวทางออกแบบ interaction ระหว่างคนกับ AI