Agent ยิงคำสั่งสำคัญไปเองก่อนทีมจะทันเห็น ต้องออกแบบจุดอนุมัติตรงไหนบ้าง

ทีมที่เริ่มปล่อยให้ AI Agent เรียก Tool ทำ Action จริงในระบบ มักเจอเหตุการณ์ทำนองเดียวกัน คือ Agent ตัดสินใจถูกต้องในเกือบทุกเคส แต่พอเจอเคสที่คลุมเครือหรือข้อมูลไม่ครบ Agent กลับเลือก Action ที่ผิดพลาดไปเลยโดยไม่มีใครทันเห็นก่อน จนกว่าผลกระทบจะเกิดขึ้นจริงกับลูกค้าหรือระบบข้อมูล

ปัญหานี้ไม่ได้แปลว่าต้องเลิกให้ Agent ทำงานอัตโนมัติ แต่สะท้อนว่าระบบยังขาดจุดที่ให้คนเข้ามาตรวจสอบก่อนความเสียหายเกิดขึ้นจริง คำถามที่ทีมพัฒนาต้องตอบให้ได้ไม่ใช่ 'ควรมี Human in the Loop ไหม' แต่เป็น 'ควรวางจุดอนุมัติตรงไหนบ้าง' เพราะใส่มากเกินไประบบจะช้าจนไม่มีใครอยากใช้ ใส่น้อยเกินไปความเสี่ยงก็ยังสูงเหมือนเดิม

บทความนี้จะพาดูหลักการออกแบบ Human in the Loop ตั้งแต่จุดที่ควรมีคนอนุมัติ วิธีกำหนด Confidence Threshold ไปจนถึงต้นทุน Friction ที่ต้องยอมแลกเมื่อเพิ่มคนเข้ามาในกระบวนการ

Human in the Loop คืออะไร ต่างจากการมีคนตรวจทุกอย่างอย่างไร

Human in the Loop หมายถึงการออกแบบระบบให้มีจุดที่คนเข้ามาตรวจสอบหรืออนุมัติก่อน AI Agent ลงมือทำ Action ที่ส่งผลจริง ไม่ใช่การให้คนนั่งอ่านทุกคำตอบของ Agent ตลอดเวลาเหมือนงาน Manual แบบเดิม เพราะถ้าต้องตรวจทุกอย่าง ก็ไม่ต่างจากไม่ได้ใช้ AI ช่วยงานเลย

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

Human in the Loop จึงไม่ใช่สวิตช์เปิดปิดแบบมีหรือไม่มี แต่เป็นสเปกตรัมที่ทีมต้องออกแบบตามระดับความเสี่ยงของแต่ละ Action ในระบบ ตั้งแต่ปล่อยให้ Agent ทำเองทั้งหมด ไปจนถึงต้องรอคนอนุมัติทุกครั้งก่อนดำเนินการ

ทำไม Agent ที่ทำงานอัตโนมัติเต็มรูปแบบยังไม่ปลอดภัยพอในตอนนี้

โมเดลภาษาในปัจจุบันยังมีอัตราความผิดพลาดที่ไม่เท่ากับศูนย์ โดยเฉพาะเมื่อเจอสถานการณ์ที่ไม่เคยเจอในข้อมูลฝึก หรือข้อมูล Context ที่ป้อนให้ไม่ครบถ้วนพอจะตัดสินใจถูกต้อง ความผิดพลาดแบบนี้ต่างจากบั๊กซอฟต์แวร์ทั่วไปตรงที่ไม่สามารถคาดเดาล่วงหน้าได้ชัดเจนว่าจะเกิดกับ Input แบบไหน

เมื่อ Agent มีสิทธิ์เรียก Tool ทำ Action จริง เช่น ยกเลิกออเดอร์ ส่งอีเมล หรือแก้ไขข้อมูลในฐานข้อมูล ความผิดพลาดที่เคยเป็นแค่ 'คำตอบผิด' จะกลายเป็น 'ความเสียหายจริง' ทันที และบางความเสียหายก็ย้อนกลับไม่ได้ เช่น อีเมลที่ส่งออกไปแล้วหรือข้อมูลที่ถูกลบไปแล้ว

อีกประเด็นที่มักถูกมองข้ามคือ Agent ไม่รู้ตัวว่าตัวเองกำลังตัดสินใจผิด โมเดลภาษาส่วนใหญ่ยังไม่มีกลไกประเมินความมั่นใจของตัวเองได้แม่นยำนัก ทำให้ Agent อาจตอบด้วยน้ำเสียงมั่นใจเต็มที่ทั้งที่กำลังเดาอยู่ ซึ่งเป็นเหตุผลสำคัญที่ต้องมีคนเข้ามาเป็นด่านตรวจสำหรับ Action ที่มีความเสี่ยงสูง

จุดไหนใน Workflow ที่ควรมีคนอนุมัติก่อน Agent ลงมือทำ

การเลือกจุดอนุมัติที่ดีเริ่มจากการมองว่า Action นั้นย้อนกลับได้หรือไม่ ถ้า Action ย้อนกลับได้ง่าย เช่น การสร้างร่างเอกสารที่ยังไม่ถูกส่งออกไปไหน ความเสี่ยงต่ำกว่า Action ที่ย้อนกลับไม่ได้ เช่น การโอนเงินหรือการลบข้อมูลถาวร

มิติที่สองที่ต้องพิจารณาคือขอบเขตของผลกระทบ Action ที่กระทบแค่ผู้ใช้คนเดียวความเสี่ยงต่ำกว่า Action ที่กระทบผู้ใช้จำนวนมากพร้อมกัน เช่น การเปลี่ยนค่า Config ที่ใช้ร่วมกันทั้งระบบ หรือการส่งข้อความแบบ Broadcast

มิติที่สามคือมูลค่าทางการเงินหรือความสำคัญทางธุรกิจของ Action นั้น Action ที่เกี่ยวกับเงินจำนวนมาก สัญญา หรือข้อมูลที่มีความอ่อนไหว ควรมีคนอนุมัติเสมอไม่ว่า Agent จะมั่นใจแค่ไหนก็ตาม เพราะความเสียหายเมื่อผิดพลาดสูงเกินกว่าจะยอมรับความเสี่ยงได้

• Action ที่ย้อนกลับไม่ได้ เช่น ลบข้อมูล ยกเลิกออเดอร์ถาวร หรือส่งอีเมลออกไปแล้ว
• Action ที่กระทบเงินหรือมูลค่าสูง เช่น คืนเงิน ปรับราคา หรืออนุมัติวงเงิน
• Action ที่กระทบผู้ใช้จำนวนมากพร้อมกัน เช่น Broadcast หรือแก้ Config ร่วม
• Action ที่ Agent ต้องตีความข้อมูลกำกวมหรือไม่ครบก่อนตัดสินใจ
• Action ที่เกี่ยวกับข้อมูลอ่อนไหวทางกฎหมายหรือความเป็นส่วนตัว

ออกแบบ Confidence Threshold อย่างไรให้ Agent รู้ว่าเมื่อไหร่ต้องถามคน

1. กำหนดสัญญาณที่ใช้วัดความมั่นใจของ Agent ก่อน เช่น ค่าความน่าจะเป็นจากโมเดล ความสอดคล้องของคำตอบเมื่อถามซ้ำหลายครั้ง หรือความครบถ้วนของข้อมูลที่ Agent มีอยู่ในมือ
2. แบ่งระดับความเสี่ยงของ Action ออกเป็นกลุ่มตามที่วิเคราะห์ไว้ในหัวข้อก่อนหน้า แล้วกำหนด Threshold ที่ต่างกันสำหรับแต่ละกลุ่ม Action ความเสี่ยงต่ำอาจตั้ง Threshold หลวมกว่า Action ความเสี่ยงสูง
3. ทดสอบ Threshold ที่ตั้งไว้กับชุดเคสจริงหรือเคสจำลองจำนวนมาก เพื่อดูว่า Agent ถามคนบ่อยเกินไปจนน่ารำคาญ หรือปล่อยผ่านเคสที่ควรถามไปเยอะเกินไป
4. ปรับ Threshold เป็นรอบตามข้อมูลจริงที่เก็บได้ ไม่ใช่ตั้งครั้งเดียวแล้วใช้ตลอดไป เพราะพฤติกรรมผู้ใช้และรูปแบบ Input ที่ Agent เจอมักเปลี่ยนไปตามเวลา
5. เมื่อ Agent ไม่มั่นใจและต้องส่งให้คนตัดสินใจ ต้องแนบเหตุผลและข้อมูลที่ Agent ใช้ประกอบการตัดสินใจไปด้วยเสมอ ไม่ใช่แค่ส่งคำถามเปล่า ๆ ให้คนตอบโดยไม่มีบริบท

เปรียบเทียบรูปแบบ Human in the Loop สามแบบที่ใช้จริง

รูปแบบ Human in the Loop ที่ใช้ในระบบจริงมีหลายแบบ แต่ละแบบเหมาะกับสถานการณ์ต่างกัน การเลือกใช้ผิดรูปแบบมักทำให้ทีมรู้สึกว่า Human in the Loop ทำให้งานช้าลงโดยไม่จำเป็น ทั้งที่ปัญหาจริงคือเลือกรูปแบบไม่เหมาะกับความเสี่ยงของ Action นั้น

หน้าจออนุมัติที่ดีควรมีอะไรบ้างให้คนตัดสินใจเร็วและแม่น

คนที่ต้องอนุมัติ Action ของ Agent มักมีเวลาจำกัดและต้องตัดสินใจหลายเคสต่อวัน ถ้าหน้าจออนุมัติออกแบบไม่ดี คนอนุมัติจะเริ่มกดผ่านโดยไม่อ่านรายละเอียดจริง ซึ่งทำให้ทั้งกระบวนการ Human in the Loop สูญเสียประโยชน์ไปเลย

หน้าจอที่ใช้งานได้จริงควรแสดงบริบทที่จำเป็นครบในหน้าเดียว ไม่ต้องให้คนคลิกไปหาข้อมูลเพิ่มหลายที่ ควรมีทั้งข้อมูลที่ Agent ใช้ตัดสินใจ เหตุผลที่ Agent เลือก Action นี้ และผลกระทบที่จะเกิดขึ้นถ้าอนุมัติ

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

Audit Trail และการนำผลการตัดสินใจของคนกลับไปพัฒนา Agent

ทุกครั้งที่คนอนุมัติ ปฏิเสธ หรือแก้ไข Action ของ Agent ควรถูกบันทึกไว้เป็น Audit Trail ที่ครบถ้วน ทั้งข้อมูลที่ Agent ใช้ตัดสินใจ ผลการตัดสินใจของคน และเหตุผลถ้ามีการปฏิเสธ ข้อมูลชุดนี้มีประโยชน์ทั้งด้านความรับผิดชอบเมื่อเกิดปัญหา และด้านการพัฒนาระบบต่อ

ทีมที่ทำได้ดีมักนำเคสที่ถูกปฏิเสธหรือแก้ไขบ่อยมาวิเคราะห์เป็นรอบ เพื่อดูว่า Agent มักตัดสินใจผิดในรูปแบบใดซ้ำ ๆ แล้วปรับ Prompt, Threshold หรือ Tool ที่ Agent ใช้ให้ตรงจุดมากขึ้น แทนที่จะปล่อยให้คนต้องคอยแก้เคสเดิมซ้ำไปเรื่อย ๆ โดยไม่มีอะไรเปลี่ยนแปลง

Audit Trail ยังเชื่อมโยงกับเรื่อง Guardrails โดยตรง เพราะเป็นแหล่งข้อมูลสำคัญที่ใช้ตรวจสอบว่า Guardrails ที่ตั้งไว้ยังครอบคลุมความเสี่ยงจริงอยู่หรือไม่ หากสนใจเรื่องการออกแบบ Guardrails หลายชั้น ลองอ่านเพิ่มเติมที่ แนวทางออกแบบ AI Guardrails ซึ่งอธิบายกลไกป้องกันในมุมที่ต่างจาก Human in the Loop แต่ทำงานเสริมกัน

ต้นทุนและ Friction ที่ต้องแลกเมื่อเพิ่มคนเข้ามาในระบบ

Human in the Loop ไม่ได้มาฟรี ทุกจุดที่ต้องรอคนอนุมัติหมายถึง Latency ที่เพิ่มขึ้น และหมายถึงต้องมีคนพร้อมตอบสนองในเวลาที่ระบบต้องการ ถ้าไม่มีคนว่างพอดี Action นั้นจะค้างอยู่ในคิวรออนุมัติ ซึ่งอาจกลายเป็นคอขวดใหม่ของระบบแทนที่จะเป็นตัวช่วย

ทีมที่วางแผน Human in the Loop โดยไม่คิดเรื่องกำลังคนล่วงหน้า มักเจอปัญหาว่าระบบ AI ที่ตั้งใจให้ทำงานเร็วขึ้น กลับช้าลงกว่าเดิมเพราะ Action สำคัญติดอยู่ที่คิวรอคนอนุมัติเป็นชั่วโมง ซึ่งขัดกับเป้าหมายเดิมของการเอา AI มาช่วยงานตั้งแต่แรก

ทางแก้ที่ทีมส่วนใหญ่ใช้คือการจำกัดจำนวนจุดอนุมัติให้เหลือเฉพาะที่จำเป็นจริง ตามที่วิเคราะห์ไว้ในหัวข้อการเลือกจุดอนุมัติ และหมุนเวียนคนที่รับผิดชอบตรวจสอบให้มีคนว่างตลอดช่วงเวลาที่ระบบทำงาน แทนที่จะฝากไว้กับคนคนเดียวที่อาจไม่ว่างในบางช่วง เมื่อระบบต้องรองรับงานต่อเนื่องยาวนานโดยไม่สะดุด การออกแบบให้ Agent ทนต่อความล้มเหลวและ Resume งานต่อได้ก็สำคัญไม่แพ้กัน ดูรายละเอียดเพิ่มเติมได้ที่ แนวทางออกแบบ Durable AI Agents

ข้อผิดพลาดที่ทีมมักทำเมื่อเริ่มออกแบบ Human in the Loop

ข้อผิดพลาดที่พบบ่อยที่สุดคือใส่จุดอนุมัติมากเกินไปตั้งแต่แรก เพราะกลัวความผิดพลาดของ Agent จนทุก Action ต้องรอคนอนุมัติหมด ผลคือระบบช้าจนทีมเลิกใช้ AI Agent ไปเลยทั้งที่ปัญหาจริงอยู่ที่การออกแบบจุดอนุมัติ ไม่ใช่ตัว Agent เอง

อีกข้อผิดพลาดที่พบบ่อยคือไม่มีแผนสำรองเมื่อไม่มีคนว่างมาอนุมัติ Action ที่ค้างอยู่ในคิวนานเกินไปควรมี Escalation Path ที่ชัดเจน เช่น ส่งต่อให้คนอื่น หรือมีกฎว่า Action ความเสี่ยงต่ำที่ค้างนานเกินเวลาที่กำหนดสามารถดำเนินการต่อได้เองโดยมีการแจ้งเตือนย้อนหลัง แทนที่จะปล่อยให้ค้างไม่มีกำหนด

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

ทำแบบนี้แล้วพัง เพราะไม่เคยนำผลการอนุมัติหรือปฏิเสธย้อนหลังมาปรับปรุง Agent เลย ทำให้ Agent ทำผิดรูปแบบเดิมซ้ำไปเรื่อย ๆ และคนต้องคอยแก้ไขเคสเดิมทุกครั้งโดยไม่มีอะไรดีขึ้น

สรุป

Human in the Loop คือการออกแบบให้คนเข้ามาตรวจสอบหรืออนุมัติ Action ของ AI Agent เฉพาะจุดที่ความเสี่ยงสูงหรือ Agent ไม่มั่นใจ ไม่ใช่การตรวจทุก Action ทั้งหมด การเลือกจุดอนุมัติที่เหมาะสมต้องพิจารณาว่า Action นั้นย้อนกลับได้ไหม กระทบกว้างแค่ไหน และมีมูลค่าทางธุรกิจเท่าไร

ทีมที่ทำได้ดีจะออกแบบ Confidence Threshold ที่ปรับได้ตามข้อมูลจริง มีหน้าจออนุมัติที่ให้บริบทครบ และนำผลการตัดสินใจของคนย้อนกลับไปพัฒนา Agent อย่างต่อเนื่อง แทนที่จะปล่อยให้คนแก้ไขปัญหาเดิมซ้ำไปเรื่อย ๆ โดยไม่มีอะไรดีขึ้น

• Human in the Loop เป็นสเปกตรัม ไม่ใช่สวิตช์เปิดปิด ต้องเลือกจุดอนุมัติตามความเสี่ยงของแต่ละ Action
• รูปแบบ Pre-approval, Post-review และ Escalation-only เหมาะกับสถานการณ์ต่างกัน เลือกผิดรูปแบบทำให้รู้สึกว่า Human in the Loop ทำให้งานช้าเกินจำเป็น
• Audit Trail และการนำผลอนุมัติย้อนกลับไปปรับ Agent คือกลไกที่ทำให้ระบบพัฒนาต่อเนื่อง ไม่ใช่แค่ด่านตรวจแบบตายตัว

คำถามที่พบบ่อย