Human-in-the-Loop (ต่อไปนี้จะเรียกว่า HITL) คือแนวคิดการออกแบบที่ให้มนุษย์เข้ามามีส่วนร่วมและกำกับดูแลกระบวนการตัดสินใจของ AI ซึ่งเป็นกลไกสำคัญในการรับประกันคุณภาพและความน่าเชื่อถือของ AI BPO

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

เมื่ออ่านจบ คุณจะได้รับผลลัพธ์ดังนี้:

• การแบ่งขอบเขตที่ชัดเจนระหว่างงานที่ AI ควรประมวลผลอัตโนมัติและงานที่มนุษย์ควรเข้ามามีส่วนร่วม
• ขั้นตอนการออกแบบกฎการแยกสาขาโดยอิงจากคะแนนความเชื่อมั่น (Confidence Score) และการจำแนกความเสี่ยงของงาน
• วิธีการสร้างวงจรการปรับปรุง AI อย่างต่อเนื่องผ่าน Feedback Loop

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

เมื่อกลไกการประมวลผลงานโดยอัตโนมัติด้วย AI แพร่หลายมากขึ้น คำถามที่ว่า "ควรให้ AI รับผิดชอบถึงจุดไหน และมนุษย์ควรเข้ามาตัดสินใจตั้งแต่จุดใด" จึงกลายเป็นโจทย์สำคัญในการปฏิบัติงานจริงในหน้างาน BPO

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

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

เนื้อหาต่อจากนี้จะสรุปแนวคิดพื้นฐานของ HITL ในบริบทของงาน BPO พร้อมทั้งตรวจสอบวิธีการคัดกรองสถานการณ์ที่จำเป็นต้องมีการแทรกแซง และภาพรวมของความเสี่ยงที่จะเกิดขึ้นหากไม่มีการนำระบบนี้มาใช้ตามลำดับ

ระบบอัตโนมัติเต็มรูปแบบ (Full Automation) คือแนวคิดการออกแบบที่มุ่งเน้น "การเพิ่มประสิทธิภาพสูงสุดโดยการตัดมนุษย์ออกจากกระบวนการ" ในขณะที่ Human-in-the-Loop (ต่อไปนี้จะเรียกว่า HITL) คือการออกแบบเชิงร่วมมือที่ "มอบหมายงานที่ AI ถนัดให้ AI ทำ และให้มนุษย์เข้ามาแทรกแซงในสถานการณ์ที่การตัดสินใจทำได้ยาก" ความแตกต่างนี้ไม่ใช่แค่เรื่องของอัตราการทำงานอัตโนมัติที่ต่างกัน แต่หมายถึงความแตกต่างในแนวคิดการออกแบบพื้นฐานที่ว่า จะวางความรับผิดชอบในการจัดการความเสี่ยงไว้ที่ใด

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

เหตุผลที่ระบบอัตโนมัติเต็มรูปแบบทำได้ยาก มี 3 ประการหลัก ดังนี้:

• ขีดจำกัดของคะแนนความน่าเชื่อถือ (Confidence Score): การตัดสินใจของ AI มาพร้อมกับความผิดพลาดเชิงความน่าจะเป็น ดังนั้นในกรณีที่มีความน่าเชื่อถือต่ำ การตรวจสอบโดยมนุษย์จึงเป็นสิ่งที่ขาดไม่ได้
• การตัดสินใจที่ขึ้นอยู่กับบริบท: งานที่ต้องใช้ความรู้พื้นฐาน เช่น การตีความสัญญา หรือการตัดสินลำดับความสำคัญของข้อร้องเรียนจากลูกค้า เป็นงานที่ AI เพียงลำพังจะทำความแม่นยำได้ยาก
• ข้อกำหนดทางกฎหมาย: กฎหมาย EU GDPR มาตรา 22 ระบุไว้อย่างชัดเจนถึง "สิทธิในการให้มนุษย์เข้ามาแทรกแซง" สำหรับกระบวนการอัตโนมัติที่ส่งผลกระทบอย่างมีนัยสำคัญต่อบุคคล ทำให้มีสถานการณ์ที่กฎหมายบังคับให้มนุษย์ต้องเข้ามามีส่วนร่วม

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

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

สถานการณ์สำคัญ 3 ประการที่จำเป็นต้องมี HITL (Human-in-the-Loop) ได้แก่:

① การประมวลผลกรณีที่มีความเชื่อมั่นต่ำหรือมีความคลุมเครือ ในกรณีที่คะแนนความเชื่อมั่น (Confidence Score) ที่ AI โมเดลประมวลผลออกมาต่ำกว่าเกณฑ์ที่กำหนด จำเป็นต้องหยุดการประมวลผลอัตโนมัติและส่งต่อให้มนุษย์ตรวจสอบ ตัวอย่างเช่น งานอ่านค่าตัวเลขในใบแจ้งหนี้หรือการดึงเงื่อนไขจากสัญญา หากคุณภาพของข้อความต่ำหรือมีรูปแบบที่เป็นข้อยกเว้นมาก จะมีความเสี่ยงสูงที่การประมวลผลที่ผิดพลาดจะหลุดไปสู่กระบวนการถัดไป

② การประมวลผลที่ต้องอาศัยการตัดสินใจทางกฎหมายหรือการปฏิบัติตามกฎระเบียบ (Compliance) มาตรา 22 ของ EU GDPR ระบุชัดเจนถึง "สิทธิในการได้รับการแทรกแซงโดยมนุษย์" สำหรับการประมวลผลอัตโนมัติที่มีผลกระทบทางกฎหมายต่อบุคคล ในกรณีงานตรวจสอบเครดิต การอนุมัติสัญญา หรือการตัดสินใจที่เกี่ยวข้องกับข้อมูลส่วนบุคคล การตรวจสอบขั้นสุดท้ายโดยมนุษย์ถือเป็นเรื่องจำเป็น แต่หากเป็นงานที่มีความเสี่ยงต่ำซึ่งจัดการเฉพาะข้อมูลภายในองค์กร ก็สามารถขยายขอบเขตการทำอัตโนมัติให้กว้างขึ้นได้ ดังนั้น การออกแบบเงื่อนไขโดยใช้ข้อกำหนดทางกฎหมายเป็นเกณฑ์ในการตัดสินใจจึงมีความสำคัญ

③ ช่วงการตรวจสอบคุณภาพหลังการนำระบบมาใช้ครั้งแรกหรือหลังการอัปเดตโมเดล ทันทีที่นำ AI โมเดลใหม่หรือขั้นตอนการทำงานใหม่เข้าสู่สภาพแวดล้อมการใช้งานจริง ความแม่นยำของข้อมูลจริงอาจยังไม่เสถียร ในช่วงนี้การที่มนุษย์ทำการตรวจสอบแบบสุ่ม (Sampling Review) เพื่อตรวจจับรูปแบบการตัดสินใจที่ผิดพลาดตั้งแต่เนิ่นๆ จะเป็นกุญแจสำคัญในการรักษาคุณภาพ โดยทั่วไปแล้วเมื่อโมเดลมีความแม่นยำถึงระดับที่กำหนด จะมีการออกแบบให้ค่อยๆ ลดสัดส่วนการแทรกแซงของมนุษย์ลง

การระบุสถานการณ์ทั้ง 3 ประการนี้ไว้ล่วงหน้าในกระบวนการทำงาน คือจุดเริ่มต้นของการออกแบบ HITL

การคิดว่า "ยิ่งมีอัตราการทำงานอัตโนมัติสูงเท่าไรยิ่งดี" แล้วละเลย HITL (Human-in-the-Loop) จะนำไปสู่สถานการณ์แบบใด—ในหน้างานจริง มีหลายกรณีที่การออกแบบเริ่มดำเนินการไปก่อนที่จะได้คำตอบสำหรับคำถามนี้

หากไม่นำ HITL มาใช้ จะมีความเสี่ยงหลัก 3 ประการที่อาจเกิดขึ้น:

• การขยายตัวของข้อผิดพลาดแบบลูกโซ่ (Error Cascading): หากไม่มีกลไกตรวจจับเมื่อ AI ตัดสินใจผิดพลาด ข้อผิดพลาดนั้นจะถูกส่งต่อไปยังกระบวนการถัดไปเรื่อยๆ ในงานด้านการป้อนข้อมูล มีรายงานว่าการจำแนกประเภทผิดพลาดเพียง 1 รายการ อาจส่งผลกระทบต่อบันทึกข้อมูลหลายร้อยรายการ
• การขาดความรับผิดชอบ (Lack of Accountability): มาตรา 22 ของ EU GDPR ระบุไว้อย่างชัดเจนถึง "สิทธิในการได้รับการแทรกแซงจากมนุษย์" สำหรับการตัดสินใจโดยอัตโนมัติที่มีผลกระทบทางกฎหมาย หากในการออกแบบไม่มีจุดที่มนุษย์คอยกำกับดูแล จะนำไปสู่ปัญหาด้านการปฏิบัติตามกฎระเบียบ (Compliance) โดยตรง
• การปล่อยปละละเลยเมื่อโมเดลเสื่อมประสิทธิภาพ (Model Degradation): ในสภาวะที่ไม่มีวงจรป้อนกลับ (Feedback Loop) AI จะไม่สามารถปรับตัวตามการเปลี่ยนแปลงของสภาพแวดล้อมการทำงานได้ แม้จะเกิด Data Drift (ข้อมูลเปลี่ยนรูปแบบไปจากเดิม) แต่หากไม่มีตัวกระตุ้นให้แก้ไข ก็มักจะทำให้ความแม่นยำที่ลดลงถูกมองข้ามไปเป็นเวลานาน

รูปแบบความล้มเหลวที่พบบ่อยคือการตัดสินใจว่า "เนื่องจากความแม่นยำในขั้นตอน PoC สูง จึงใช้ระบบอัตโนมัติเต็มรูปแบบในการใช้งานจริง" เนื่องจากสภาพแวดล้อมของ PoC ทำงานด้วยข้อมูลที่เตรียมไว้เป็นอย่างดี การออกแบบจึงอาจไม่ได้รวมวิธีการรับมือกับข้อยกเว้นหรือกรณีที่กำกวมซึ่งเกิดขึ้นในงานจริง มีรายงานกรณีที่หลังจากเริ่มใช้งานจริง จำนวนการจัดการข้อยกเว้นมีมากกว่าที่คาดการณ์ไว้ ส่งผลให้ต้นทุนการจัดการด้วยตนเองสูงกว่าก่อนที่จะทำระบบอัตโนมัติเสียอีก

การไม่มี HITL ไม่ใช่ "การเพิ่มประสิทธิภาพ" แต่เป็น "การผลักภาระความเสี่ยงออกไปในอนาคต"

ก่อนเริ่มลงมือออกแบบ จำเป็นต้องมีขั้นตอนการคัดกรองว่า "สิ่งใดยังไม่ทราบแน่ชัด" เสียก่อน หากพยายามกำหนดจุดตัดสินใจโดยที่โครงสร้างของงานเป้าหมาย, ดัชนีความน่าเชื่อถือของ AI model และโครงสร้างของทีมงานที่เข้ามาแทรกแซง (intervention) ยังคงมีความคลุมเครือ จะทำให้ต้องย้อนกลับมาตั้งคำถามพื้นฐานระหว่างการออกแบบ เช่น "ใครจะเป็นผู้ตรวจสอบ" หรือ "จะกำหนดเกณฑ์ Threshold ของคะแนนความน่าเชื่อถืออย่างไร"

สิ่งที่ควรตรวจสอบในขั้นตอนเตรียมการมี 3 ประเด็นหลัก ได้แก่ จุดตัดสินใจในกระบวนการทำงานอยู่ตรงไหน, AI model ปัจจุบันใช้ดัชนีใดและมีความแม่นยำระดับใด, และมีการจัดเตรียมเจ้าหน้าที่ที่สามารถปฏิบัติงานจริงรวมถึงเวลาทำงานที่เพียงพอสำหรับช่วงที่มนุษย์ต้องเข้าไปแทรกแซงหรือไม่ หากดำเนินการออกแบบโดยที่สิ่งเหล่านี้ยังไม่พร้อม จะส่งผลให้เกิดการแก้ไขงาน (rework) จำนวนมากในขั้นตอนถัดไป

เมื่อเริ่มออกแบบ HITL มักมีหลายกรณีที่ตัดสินใจเลือก "จุดที่จะให้คนเข้ามาแทรกแซง (Intervention point)" โดยใช้เพียงสัญชาตญาณ แต่ในความเป็นจริง หากไม่ทำความเข้าใจกระบวนการทำงานและกระแสข้อมูล (Data flow) ให้ชัดเจนก่อน ความแม่นยำของกฎการแยกเงื่อนไข (Branching rules) จะลดลงอย่างมาก

ในการจัดทำแผนผังกระบวนการ (Process map) ให้ระบุองค์ประกอบต่อไปนี้ควบคู่ไปกับการสัมภาษณ์ผู้ปฏิบัติงานจริง:

• ประเภทและแหล่งที่มาของข้อมูลนำเข้า (เช่น เอกสาร, อีเมล, API, การกรอกข้อมูลด้วยตนเอง)
• ผู้รับผิดชอบและระยะเวลาที่ใช้ในแต่ละขั้นตอนการประมวลผล
• ความถี่และรูปแบบสาเหตุที่ทำให้เกิดการจัดการข้อยกเว้น (Exception handling)
• ผู้ตัดสินใจ/ผู้อนุมัติขั้นสุดท้าย และระบบปลายทางที่รับข้อมูล

สำหรับการทำให้กระแสข้อมูล (Data flow) เห็นภาพชัดเจน ต้องระบุให้ได้ว่าข้อมูลที่ AI ได้รับนั้น "ไหลเข้ามาในขั้นตอนใด, รูปแบบใด และมีคุณภาพอย่างไร" ตัวอย่างเช่น ในงาน BPO ประมวลผลใบแจ้งหนี้ จุดที่คุณภาพข้อมูลลดลงจะแตกต่างกันไปในแต่ละขั้นตอน ได้แก่ ภาพสแกน → OCR → การดึงข้อมูลจำนวนเงิน → การจับคู่บัญชี หากไม่ระบุจุดเหล่านี้ก่อนตั้งค่าเกณฑ์ (Threshold) จะทำให้เกิดการแทรกแซงกระจุกตัวอยู่ในขั้นตอนท้ายๆ จนลดทอนประโยชน์ของระบบอัตโนมัติลง

การใช้มาตรฐานอย่าง BPMN (Business Process Model and Notation) ในการเขียนแผนผังกระบวนการ จะช่วยให้วิศวกรและผู้ปฏิบัติงานอ้างอิงจากแผนภาพเดียวกันได้ ซึ่งช่วยป้องกันความเข้าใจที่คลาดเคลื่อน ส่วนแผนภาพกระแสข้อมูล (DFD) นั้น หากจัดระเบียบด้วยองค์ประกอบ 3 ส่วน ได้แก่ เอนทิตีภายนอก (External entity), กระบวนการ (Process) และแหล่งเก็บข้อมูล (Data store) จะช่วยให้ขอบเขตข้อมูลนำเข้าสำหรับโมเดล AI มีความชัดเจนยิ่งขึ้น

ความแม่นยำของการออกแบบ HITL ขึ้นอยู่กับว่าเราสามารถอ่านค่าความเชื่อมั่น (Confidence Score) ที่ AI โมเดลส่งออกมาได้แม่นยำเพียงใด

ค่าความเชื่อมั่นคือตัวเลขระดับความมั่นใจที่โมเดลกำหนดให้กับผลลัพธ์แต่ละรายการ ซึ่งจะเป็นเกณฑ์ตัดสินในการแบ่งแยกระหว่างการประมวลผลอัตโนมัติและการส่งต่อให้มนุษย์ตรวจสอบ (Escalation) อย่างไรก็ตาม เนื่องจากความหมายของคะแนนจะแตกต่างกันไปตามประเภทของโมเดลและข้อมูลที่ใช้ฝึกสอน จึงไม่สามารถสรุปได้ง่ายๆ ว่า "ถ้ามากกว่า 0.9 คือปลอดภัย" ดังนั้น ก่อนการออกแบบจึงจำเป็นต้องตรวจสอบตัวชี้วัดต่อไปนี้ในแต่ละงาน:

• ความแม่นยำ (Precision): สัดส่วนของรายการที่อนุมัติอัตโนมัติแล้วถูกต้องจริง
• ความสามารถในการเรียกคืน (Recall): สัดส่วนของรายการที่ควรจะถูกต้อง ซึ่งโมเดลสามารถตรวจพบได้อย่างถูกต้อง
• F1 Score: ค่าเฉลี่ยฮาร์มอนิกของ Precision และ Recall ใช้สำหรับตรวจสอบความสมดุล
• การกระจายตัวของค่าความเชื่อมั่น (Confidence Score Distribution): ตรวจสอบด้วยฮิสโตแกรมว่าคะแนนกระจุกตัวอยู่ในช่วงใดช่วงหนึ่งหรือไม่

ในแง่ของการกำหนดเงื่อนไข (Conditional Branching) การใช้เกณฑ์ตัดสินที่ว่า หากเป็นงานที่เน้นความแม่นยำ (เช่น การดึงข้อมูลจำนวนเงินจากสัญญา) ให้เน้นค่า Precision และตั้งเกณฑ์ (Threshold) ไว้สูง ส่วนงานที่เน้นการป้องกันการตกหล่น (เช่น การตรวจจับการละเมิดกฎระเบียบ) ให้เน้นค่า Recall และตั้งเกณฑ์ไว้ต่ำ จะเป็นแนวทางที่มีประสิทธิภาพ

นอกจากนี้ การตรวจสอบอย่างสม่ำเสมอว่าการกระจายตัวของคะแนนในสภาพแวดล้อมการใช้งานจริง (Production) แตกต่างจากช่วงการพัฒนาหรือไม่นั้นเป็นสิ่งที่ขาดไม่ได้ หากเกิด Data Drift อัตราการเข้าแทรกแซง (Intervention Rate) อาจเปลี่ยนแปลงอย่างกะทันหันแม้จะใช้เกณฑ์เดิมก็ตาม

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

"ต้องการนำ HITL มาใช้ แต่ไม่รู้ว่าใครควรรับหน้าที่เป็นผู้ดูแลการแทรกแซง" นี่เป็นปัญหาที่นักออกแบบระบบจำนวนมากต้องเผชิญ หากเริ่มใช้งานโดยที่โครงสร้างองค์กรยังไม่ชัดเจน จะเกิดเหตุการณ์ที่ AI ส่งเรื่องขึ้นมา (Escalation) แต่ไม่มีผู้รับผิดชอบอยู่บ่อยครั้ง

ผู้ดูแลการแทรกแซงจำเป็นต้องมีทักษะหลัก 2 ด้าน ดังนี้:

ความรู้เฉพาะทางในงาน (Domain Knowledge)

• มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับเกณฑ์การตัดสินใจและกฎข้อยกเว้นของงานนั้นๆ
• มีอำนาจในการตัดสินใจขั้นสุดท้ายโดยอ้างอิงตามกฎหมายและระเบียบข้อบังคับของบริษัท
• มีทักษะในการอ่านและวิเคราะห์ผลลัพธ์จาก AI อย่างมีวิจารณญาณ

ความสามารถในการปฏิบัติงาน (Operational Capability)

• สามารถใช้งานเครื่องมือแทรกแซง (หน้าจอตรวจสอบ/การจัดการสถานะ) ได้อย่างคล่องแคล่ว
• เข้าใจระยะเวลาดำเนินการที่กำหนด (SLA) และสามารถจัดลำดับความสำคัญของงานได้
• สามารถบันทึกเหตุผลประกอบการตัดสินใจลงในแบบฟอร์มตอบกลับได้อย่างกระชับ

ในการออกแบบโครงสร้างองค์กร สิ่งสำคัญคือต้องกำหนด 3 ระดับให้ชัดเจน ได้แก่ ผู้แทรกแซงระดับแรก (Primary Intervener), ผู้รับเรื่องต่อระดับสอง (Secondary Escalation Point) และผู้อนุมัติขั้นสุดท้าย (Final Approver) หากไม่มีการจัดทำเอกสารกฎเกณฑ์สำหรับกรณีที่ผู้แทรกแซงระดับแรกไม่สามารถตัดสินใจได้ จะทำให้เกิดการตัดสินใจตามความเห็นส่วนบุคคลในหน้างาน ซึ่งจะส่งผลให้คุณภาพของข้อมูลป้อนกลับ (Feedback Data) ลดลง

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

เมื่อจัดเตรียมโครงสร้างเรียบร้อยแล้ว ขอแนะนำให้จัดการฝึกอบรมในรูปแบบบทบาทสมมติ (Role-play) เพื่อค้นหาช่องว่างทางทักษะ การฝึกตัดสินใจในสถานการณ์การทำงานจริงจะช่วยให้คุณภาพการตอบสนองหลังเริ่มใช้งานจริงมีความเสถียรมากขึ้น

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

หัวใจสำคัญในการออกแบบกฎการแบ่งแยกหน้าที่ (Branching rules) ประกอบด้วย 3 ส่วน ได้แก่ คะแนนความเชื่อมั่น (Confidence score), การจำแนกความเสี่ยง (Risk classification) และรูปแบบข้อยกเว้น (Exception patterns) การพิจารณาว่าเรามั่นใจในผลลัพธ์ของ AI มากน้อยเพียงใด, ผลกระทบต่อธุรกิจหากเกิดการตัดสินใจที่ผิดพลาดมีระดับเท่าใด และจะจัดการกับกรณีที่ไม่ปกติซึ่งตรรกะทั่วไปไม่สามารถรองรับได้อย่างไร — การนำปัจจัยทั้ง 3 นี้มาผสมผสานกันจะทำให้เงื่อนไขที่ว่า "ควรดึงมนุษย์เข้ามามีส่วนร่วมตรงจุดไหน" มีความชัดเจนเป็นรูปธรรม ในขั้นตอนถัดไป เราจะเจาะลึกวิธีการออกแบบในแต่ละส่วนตามลำดับ

เรามักออกแบบโดยใช้การตัดสินแบบสองทาง (Binary) ว่า "ถ้าคะแนนความน่าเชื่อถือสูงให้ประมวลผลอัตโนมัติ ถ้าต่ำให้ส่งต่อให้มนุษย์" แต่ในความเป็นจริงแล้ว การจัดการกับช่วงกึ่งกลางคือสิ่งที่กำหนดคุณภาพของการดำเนินงาน การกำหนดเกณฑ์ตัดสิน (Threshold) เพียงเส้นเดียวจะทำให้ต้องยอมเสียสละระหว่างอัตราการทำงานอัตโนมัติ (Automation Rate) หรือความแม่นยำอย่างใดอย่างหนึ่ง

โครงสร้างเกณฑ์ตัดสินสามระดับที่แนะนำ มีดังนี้:

• โซนความน่าเชื่อถือสูง (ช่วงบนสำหรับการประมวลผลอัตโนมัติ): ดำเนินการประมวลผลอัตโนมัติและบันทึกเฉพาะ Log เท่านั้น
• โซนสีเทา (ช่วงกึ่งกลาง): ดำเนินการประมวลผลแบบชั่วคราวไปพร้อมกับแจ้งเตือนให้ผู้รับผิดชอบตรวจสอบ
• โซนความน่าเชื่อถือต่ำ (ช่วงล่างสำหรับการประมวลผลอัตโนมัติ): หยุดการประมวลผลอัตโนมัติและส่งเรื่องต่อ (Escalation) ทันที

ด้วยการออกแบบสามระดับนี้ จะทำให้สามารถจัดการกับเคสในโซนสีเทาด้วยกระบวนการแบบไฮบริดที่ "มนุษย์ตรวจสอบขั้นสุดท้ายในขณะที่ยังได้รับประโยชน์จากการทำงานอัตโนมัติ"

จุดสำคัญในการปฏิบัติสำหรับการตั้งค่าเกณฑ์ตัดสิน มี 3 ประการดังนี้:

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

ทั้งนี้ ระดับที่เหมาะสมของเกณฑ์ตัดสินจะขึ้นอยู่กับการรวมกันระหว่างดัชนีความแม่นยำของโมเดล (ความสมดุลระหว่าง Precision และ Recall) และความเสี่ยงของงาน การนำไปใช้ร่วมกับการจำแนกความเสี่ยงของงานที่จะกล่าวถึงในส่วนถัดไป จะช่วยให้การตั้งค่าเกณฑ์ตัดสินเป็นระบบมากขึ้น

หลักการพื้นฐานของการออกแบบคือการปรับเปลี่ยน "ความลึก" และ "จังหวะเวลา" ของการแทรกแซงโดยมนุษย์ตามระดับความเสี่ยงของงาน แทนที่จะส่งงานทุกรายการให้เจ้าหน้าที่รับผิดชอบเหมือนกันหมด การทำ Mapping ระดับการแทรกแซงตามการจำแนกความเสี่ยงไว้ล่วงหน้าจะช่วยรักษาคุณภาพงานโดยไม่สูญเสียประโยชน์จากระบบอัตโนมัติ

จุดเริ่มต้นของการจำแนกประเภทคือแกน "ขอบเขตผลกระทบ" (Impact Scope) และ "ความสามารถในการย้อนกลับ" (Reversibility) งานที่มีขอบเขตผลกระทบกว้างจะถูกจัดเป็นความเสี่ยงสูง ส่วนงานที่แก้ไขได้ง่ายหลังจากประมวลผลแล้วจะถูกจัดเป็นความเสี่ยงต่ำ การกำหนดแกนเหล่านี้ให้ชัดเจนเป็นลายลักษณ์อักษรจะช่วยลดความสับสนของเจ้าหน้าที่หน้างานได้อย่างมาก

สำหรับงานที่มีความเสี่ยงสูง ซึ่งรวมถึงผลกระทบทางกฎหมาย การชำระเงิน และการประมวลผลข้อมูลส่วนบุคคล จำเป็นต้องมีการอนุมัติล่วงหน้าโดยเจ้าหน้าที่ และให้ผลลัพธ์จาก AI เป็นเพียงข้อมูลสนับสนุนการตัดสินใจเท่านั้น โดยมีหลักการว่าห้ามละเว้นขั้นตอนนี้แม้จะมีจำนวนรายการน้อยก็ตาม สำหรับงานที่มีความเสี่ยงปานกลาง เช่น การบริการลูกค้า การร่างสัญญา หรือการเสนออนุมัติภายใน รูปแบบที่เป็นจริงคือให้ AI ประมวลผลในขั้นแรก และส่งต่อให้เจ้าหน้าที่เฉพาะรายการที่คะแนนความเชื่อมั่น (Confidence Score) ต่ำกว่าเกณฑ์ที่กำหนดเท่านั้น ซึ่งวิธีนี้จะช่วยให้งานส่วนใหญ่เป็นแบบอัตโนมัติ แต่ความแม่นยำในการตรวจจับข้อยกเว้นจะเป็นตัวกำหนดคุณภาพของการดำเนินงาน ส่วนงานที่มีความเสี่ยงต่ำ เช่น การป้อนข้อมูลตามรูปแบบ การติดแท็กจำแนกประเภท หรือการตอบคำถาม FAQ ให้ AI ดำเนินการจนเสร็จสิ้นโดยอัตโนมัติ และเจ้าหน้าที่เพียงแค่ตรวจสอบย้อนหลังด้วยการสุ่มตัวอย่างเท่านั้น

สิ่งที่ควรระวังคือ แม้จะเป็นหมวดหมู่งานเดียวกัน แต่การจำแนกประเภทอาจเปลี่ยนไปตามมูลค่าการทำธุรกรรมหรือคุณลักษณะของลูกค้า ตัวอย่างเช่น ในงานประมวลผลใบแจ้งหนี้ หากกำหนดกฎเกณฑ์แบบมีเงื่อนไขไว้ว่า รายการที่มีมูลค่าเกินระดับที่กำหนดให้ถือเป็นความเสี่ยงสูง และรายการที่ต่ำกว่านั้นให้ถือเป็นความเสี่ยงต่ำและปล่อยให้เป็นหน้าที่ของระบบอัตโนมัติ จะช่วยป้องกันความคลาดเคลื่อนในการตัดสินใจในทางปฏิบัติได้ง่ายขึ้น

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

การคัดแยกรูปแบบข้อยกเว้นโดยเริ่มจากบันทึกการทำงานในอดีตและประวัติการสอบถามถือเป็นวิธีที่มีประสิทธิภาพ รูปแบบข้อยกเว้นทั่วไปมีดังนี้:

• ข้อมูลไม่ครบถ้วน・รูปแบบไม่สอดคล้องกัน: ช่องข้อมูลที่จำเป็นว่างเปล่า, รูปแบบวันที่ปะปนกันหลายรูปแบบ
• คะแนนความเชื่อมั่น (Confidence Score) กระจุกตัวอยู่ใกล้เกณฑ์มาตรฐาน: เกิดการจำแนกผิดพลาดบ่อยครั้งบริเวณรอยต่อระหว่างการประมวลผลอัตโนมัติกับการแทรกแซงโดยมนุษย์
• กฎทางธุรกิจขัดแย้งกัน: มีเกณฑ์การตัดสินหลายอย่างถูกนำมาใช้พร้อมกันโดยไม่มีการกำหนดลำดับความสำคัญ
• รูปแบบที่ไม่เคยพบมาก่อน: กรณีใหม่ที่ไม่มีอยู่ในข้อมูลที่ใช้สอน (เช่น หมวดหมู่สินค้าใหม่, คู่ค้าใหม่)
• ข้อยกเว้นชั่วคราวจากการเปลี่ยนแปลงกฎหมายและข้อบังคับ: กรณีในช่วงเปลี่ยนผ่านที่เกิดขึ้นทันทีหลังมีการแก้ไขกฎระเบียบ

เมื่อรวบรวมรายการเหล่านี้แล้ว ให้จัดทำเป็นเอกสารในรูปแบบกฎการแยกสาขา (Branching Rules) ในการจัดทำเอกสาร แนะนำให้เขียนในโครงสร้างสามส่วนคือ 「เงื่อนไข → การตัดสิน → การดำเนินการ」 ตัวอย่างเช่น 「หากคะแนนความเชื่อมั่นต่ำกว่า 0.7 และยอดธุรกรรมเกินระดับที่กำหนด → ส่งต่อไปยังคิวการแทรกแซงที่มีความเสี่ยงสูง → ผู้ตรวจสอบอาวุโสตัดสินภายใน 4 ชั่วโมง」 โดยเขียนให้เป็นรูปแบบที่สามารถอ่านเงื่อนไข ผู้รับผิดชอบ และกำหนดเวลาได้ในบรรทัดเดียว

บทสรุป: หลังจากกำหนดจุดตัดสินใจแยกสาขาแล้ว จำเป็นอย่างยิ่งที่จะต้องออกแบบขั้นตอนการทำงานที่มนุษย์เข้ามามีส่วนร่วมจริงให้เป็นขั้นตอนที่ชัดเจน

HITL จะทำงานได้อย่างมีประสิทธิภาพก็ต่อเมื่อมีการจัดเตรียมกระบวนการทั้งหมดไว้อย่างครบถ้วน ตั้งแต่ประเภทของตัวกระตุ้นการแทรกแซง (Intervention trigger) วิธีการส่งต่องานไปยังผู้รับผิดชอบ ไปจนถึงการส่งข้อมูลย้อนกลับ (Feedback loop)

มักจะมีความคิดที่ว่าทริกเกอร์สำหรับการเข้าแทรกแซง (Intervention Trigger) นั้น "ค่อยจัดการเมื่อเกิดความผิดปกติก็พอ" แต่ในความเป็นจริงแล้ว การออกแบบโดยผสมผสานทริกเกอร์ทั้ง 3 ประเภทจะช่วยป้องกันทั้งการมองข้ามปัญหาและการเข้าแทรกแซงที่มากเกินความจำเป็นได้ดีกว่า

ประเภทของทริกเกอร์ 3 รูปแบบ

• การตรวจจับอัตโนมัติ (Automatic Detection): เมื่อคะแนนความเชื่อมั่น (Confidence Score) ของโมเดล AI ลดลงต่ำกว่าเกณฑ์ที่กำหนด ระบบจะส่งงานเข้าคิวโดยอัตโนมัติ ช่วยให้ตัดสินใจได้อย่างสม่ำเสมอตามกฎที่วางไว้โดยไม่กระทบต่อความเร็วในการประมวลผล
• การติดธงด้วยตนเอง (Manual Flag): เจ้าหน้าที่ผู้รับผิดชอบหรือพนักงาน BPO สามารถเลือกยกระดับ (Escalate) เคสที่ตนเอง "รู้สึกไม่แน่ใจในการตัดสินใจ" ได้ตามความสมัครใจ ซึ่งช่วยเสริมในส่วนของความรู้สึกผิดปกติเชิงบริบทที่การตรวจจับอัตโนมัติอาจมองข้ามไป
• การตรวจสอบตามระยะเวลา (Periodic Review): แม้จะเป็นเคสที่ผ่านเกณฑ์คะแนนความเชื่อมั่นแล้ว แต่จะมีการสุ่มตัวอย่างตามอัตราที่กำหนดเพื่อให้มนุษย์ตรวจสอบย้อนหลัง ซึ่งมีบทบาทในการค้นหาการเบี่ยงเบนเชิงระบบ (Systematic Drift) ของโมเดลได้ตั้งแต่เนิ่นๆ

ข้อควรระวังในการออกแบบ

หากพึ่งพาเพียงการตรวจจับอัตโนมัติเพียงอย่างเดียว อาจมีความเสี่ยงที่จะมองข้ามรูปแบบความผิดพลาดที่เล็ดลอดเกณฑ์ที่ตั้งไว้ไปได้อย่างแนบเนียน การตรวจสอบตามระยะเวลาจึงมีบทบาทในการเป็น "ตาข่าย" เสริม ซึ่งสอดคล้องกับแนวคิดการตรวจสอบอย่างต่อเนื่อง (Continuous Monitoring) ที่ระบุไว้ใน NIST AI RMF 1.0 (NIST AI 100-1)

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

หากกลไกการส่งต่องานแทรกแซง (Intervention Task) ไปยังผู้รับผิดชอบไม่มีประสิทธิภาพ จะทำให้เกิดสถานการณ์ที่การยกระดับปัญหา (Escalation) เกิดขึ้นแล้วแต่ไม่มีใครทราบ จนส่งผลให้การประมวลผลล่าช้า การออกแบบ UI และการแจ้งเตือนจึงถือเป็น "ไมล์สุดท้าย" (Last Mile) ของกระบวนการ HITL ที่ต้องให้ความสำคัญเป็นพิเศษ

หลักการพื้นฐานของการออกแบบ UI

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

• ผลการตัดสินของ AI และคะแนนความเชื่อมั่น (Confidence Score)
• ข้อมูลอินพุตที่ตัดตอนมาซึ่งใช้เป็นเหตุผลในการตัดสิน
• ลิงก์อ้างอิงถึงกรณีที่คล้ายคลึงกันในอดีตและการตัดสินใจครั้งสุดท้าย
• ปุ่มเลือกสำหรับการอนุมัติ (Approve), ส่งกลับ (Reject/Return) หรือยกระดับปัญหา (Escalation)

หากข้อมูลที่จำเป็นต่อการตัดสินใจกระจัดกระจาย จะทำให้ภาระทางปัญญา (Cognitive Load) ของผู้รับผิดชอบเพิ่มขึ้น ซึ่งเป็นสาเหตุของการตัดสินใจผิดพลาดและความล่าช้าในการประมวลผล

การแบ่งเงื่อนไขในการออกแบบการแจ้งเตือน

สำหรับงานที่มีความเร่งด่วนสูง (การจัดประเภทความเสี่ยงสูง หรือกรณีที่เวลา SLA เหลืออยู่น้อย) ให้ใช้ทั้งการแจ้งเตือนแบบ Push Notification และอีเมลควบคู่กัน ส่วนงานที่มีความสำคัญปกติให้แสดงเพียงสัญลักษณ์แจ้งเตือน (Badge) บนแดชบอร์ดเท่านั้น หากใช้การแจ้งเตือนแบบ Push Notification กับทุกกรณี จะทำให้เกิดภาวะล้าจากการแจ้งเตือน (Notification Fatigue) และเสี่ยงต่อการที่การแจ้งเตือนที่สำคัญถูกกลบไป

รูปแบบการออกแบบที่ควรหลีกเลี่ยง

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

UI สำหรับการส่งต่องานและการแจ้งเตือนยังถือเป็นจุดเริ่มต้นของวงจรป้อนกลับ (Feedback Loop) ซึ่งจะกล่าวถึงในหัวข้อถัดไป

"ผลการตัดสินที่เจ้าหน้าที่แก้ไขไปนั้น ถูกปล่อยทิ้งไว้โดยเปล่าประโยชน์หรือไม่" นี่คือจุดเริ่มต้นของการออกแบบวงจรป้อนกลับ (Feedback Loop)

การตัดสินใจที่มนุษย์เข้าไปแทรกแซงจะทำหน้าที่เป็น "ฉลากคำตอบที่ถูกต้อง" (Correct Label) สำหรับโมเดล AI หากไม่นำข้อมูลนี้ไปใช้ในการเรียนรู้ใหม่ ต้นทุนในการแทรกแซงก็จะเพิ่มขึ้นเรื่อยๆ โดยที่ความแม่นยำของ AI ไม่ได้พัฒนาขึ้นเลย

ขั้นตอนพื้นฐานในการนำข้อมูลป้อนกลับมาใช้ในการเรียนรู้มีดังนี้:

• การสร้างมาตรฐานการติดฉลาก (Labeling Standardization): ออกแบบ UI ที่บังคับให้เจ้าหน้าที่ต้องระบุรหัสเหตุผลทุกครั้งเมื่อเลือก "แก้ไข" "อนุมัติ" หรือ "ส่งกลับ"
• การจัดเก็บข้อมูลในบัฟเฟอร์ (Data Buffering): สะสมข้อมูลที่แก้ไขแล้วในปริมาณที่กำหนด (เช่น รายสัปดาห์) ก่อนนำเข้าสู่ไปป์ไลน์การเรียนรู้ เพื่อลดสัญญาณรบกวน (Noise)
• การประยุกต์ใช้การเรียนรู้แบบส่วนต่าง (Differential Learning): ลดต้นทุนโดยการทำ Fine-tuning เฉพาะหมวดหมู่ที่มีการตัดสินผิดพลาดบ่อย แทนการฝึกฝนโมเดลใหม่ทั้งหมด
• การจัดการเวอร์ชันอย่างเคร่งครัด (Version Control): จัดการเวอร์ชันของโมเดลทั้งก่อนและหลังการเรียนรู้ เพื่อให้สามารถย้อนกลับ (Rollback) ได้ในกรณีที่ความแม่นยำลดลง

สิ่งที่ควรระวังคือ การตัดสินใจของเจ้าหน้าที่อาจไม่สอดคล้องกันเสมอไป มีรายงานว่าเจ้าหน้าที่หลายคนอาจแก้ไขกรณีเดียวกันด้วยรหัสเหตุผลที่แตกต่างกัน หากละเลยการควบคุมคุณภาพของฉลาก โมเดลจะเรียนรู้สัญญาณที่ขัดแย้งกัน ดังนั้น การจัดเซสชันปรับเทียบ (Calibration Session) เพื่อให้เกณฑ์การตัดสินตรงกันเป็นเงื่อนไขสำคัญในการรักษาคุณภาพของข้อมูลที่ใช้เรียนรู้

ความสามารถในการทำงานของวงจรป้อนกลับสามารถตรวจสอบได้อย่างต่อเนื่องผ่าน KPI (แนวโน้มอัตราการแทรกแซงและอัตราการแก้ไข) ซึ่งจะอธิบายในส่วนถัดไป

เมื่อออกแบบเสร็จแล้ว หากคุณคิดว่า "ที่เหลือก็แค่รันระบบ" มักจะพบกับตัวเลขที่ไม่คาดคิดในอีกไม่กี่สัปดาห์ต่อมา ไม่ว่าจะเป็นอัตราการแทรกแซง (Intervention Rate) ที่สูงกว่าที่คาดไว้ การแก้ไขงานที่กระจุกตัวอยู่กับโอเปอเรเตอร์บางคน หรือเวลาในการประมวลผลที่นานขึ้นโดยไม่ทราบสาเหตุ สถานการณ์เหล่านี้มักเกิดขึ้นเมื่อเราละเลยการวางระบบวัดผลไว้ในภายหลัง

การออกแบบ HITL ไม่ใช่แค่การกำหนดกฎแล้วจบไป แต่เป็นกระบวนการที่ต้องปรับปรุงซ้ำๆ โดยดูจากตัวเลขหลังการใช้งานจริง ดังนั้น ตัวชี้วัดหลักที่คุณควรยึดเป็นแกนกลางมี 3 อย่าง ได้แก่ อัตราการแทรกแซง (Intervention Rate), อัตราการแก้ไข (Correction Rate) และเวลาในการประมวลผล (Processing Time) หากอัตราการแทรกแซงสูง ประโยชน์ของระบบอัตโนมัติก็จะลดลง หากอัตราการแก้ไขสูง จำเป็นต้องทบทวนความแม่นยำในการตัดสินใจของโมเดลหรือการตั้งค่า Threshold ใหม่ ส่วนความผันผวนของเวลาในการประมวลผลจะสะท้อนถึงภาระงานและคอขวดที่เกิดขึ้นจริง การทำให้ตัวชี้วัดเหล่านี้แสดงผลบนแดชบอร์ดอยู่ตลอดเวลา จะช่วยให้คุณตรวจพบความผิดเพี้ยนของการออกแบบได้ก่อนที่ปัญหาจะสะสมจนเกินแก้ไข ต่อจากนี้เราจะมาดูคำจำกัดความของแต่ละตัวชี้วัดและวิธีการนำไปใช้ในการปฏิบัติงานจริงกันครับ

ในการวัดผลประสิทธิภาพของ HITL มักมีความเข้าใจผิดว่า "ยิ่งอัตราการทำงานอัตโนมัติสูงขึ้น ยิ่งถือว่าประสบความสำเร็จ" แต่ในความเป็นจริง การติดตามตัวชี้วัดเชิงประกอบที่แสดงถึงคุณภาพของการแทรกแซงจะนำไปสู่การปรับปรุงคุณภาพงานได้ดีกว่า เราขอแนะนำให้คุณออกแบบโดยยึดตาม KPI 3 ประการ ดังนี้:

① อัตราการแทรกแซงของมนุษย์ (Human Intervention Rate)

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

• หากอัตราการแทรกแซงสูงเกินไป → อาจเกิดจากความแม่นยำของโมเดล AI ไม่เพียงพอ หรือการตั้งค่าเกณฑ์ (Threshold) ที่อนุรักษ์นิยมเกินไป
• หากอัตราการแทรกแซงต่ำเกินไป → อาจเกิดจากเกณฑ์ที่หลวมเกินไป ทำให้มีความเสี่ยงที่จะมองข้ามเคสที่ควรได้รับการยกระดับ (Escalation)
• ในช่วงที่การดำเนินงานมีความเสถียร แนะนำให้ติดตามการเปลี่ยนแปลงของอัตราการแทรกแซงเป็นรายสัปดาห์ เพื่อเตรียมระบบที่สามารถระบุสาเหตุได้ทันทีเมื่อเกิดการเปลี่ยนแปลงกะทันหัน

② อัตราการแก้ไข (Override / Correction Rate)

คือสัดส่วนที่มนุษย์เข้าไปแก้ไขการตัดสินใจของ AI จริงๆ จากจำนวนเคสทั้งหมดที่มนุษย์เข้าไปแทรกแซง หากอัตราการแก้ไขสูงอย่างต่อเนื่อง แสดงว่ามีความท้าทายในด้านความแม่นยำของการตัดสินใจของ AI ในหมวดหมู่งานเฉพาะเจาะจง การติดแท็ก (Tagging) และจัดเก็บเนื้อหาที่แก้ไขจะช่วยให้สามารถนำไปใช้เป็นข้อมูลนำเข้า (Input) สำหรับวงจรการปรับปรุงโมเดลในรอบถัดไปได้

③ เวลาในการประมวลผล (End-to-End Processing Time)

ให้แยกวัดเวลาในการประมวลผลระหว่างเคสที่เสร็จสิ้นด้วยระบบอัตโนมัติเพียงอย่างเดียว กับเคสที่มีการแทรกแซงโดยมนุษย์

แดชบอร์ดไม่ใช่แค่เครื่องมือสำหรับ "การทำให้เห็นภาพ" (Visualization) เท่านั้น แต่สิ่งสำคัญคือการออกแบบเพื่อกระตุ้นให้เกิดการตัดสินใจ

สำหรับแดชบอร์ดในการดำเนินงานแบบ HITL (Human-in-the-Loop) ขอแนะนำให้บรรจุองค์ประกอบขั้นต่ำดังต่อไปนี้:

• อัตราการแทรกแซงแบบเรียลไทม์ (Real-time Intervention Rate): แนวโน้มตามช่วงเวลาในรอบ 1 ชั่วโมง 1 วัน และ 1 สัปดาห์ที่ผ่านมา
• อัตราการแก้ไขและประเภทของการแก้ไข: ทำให้เห็นภาพหมวดหมู่ที่ AI ตัดสินใจผิดพลาด เพื่อนำไปใช้จัดลำดับความสำคัญในการปรับปรุงโมเดล
• ระยะเวลาการประมวลผลแยกตามรายบุคคลและรายทีม: ใช้เพื่อระบุปัญหาคอขวด (Bottleneck)
• จำนวนเคสที่รอการยกระดับ (Escalation): เพื่อติดตามความเสี่ยงในการละเมิด SLA แบบเรียลไทม์

ในการออกแบบการแจ้งเตือนเมื่อตรวจพบความผิดปกติ (Anomaly Detection Alert) การกำหนดเกณฑ์การตัดสินใจตามเงื่อนไขให้ชัดเจนจะช่วยลดภาระในการดำเนินงานได้ หากอัตราการแทรกแซงเกินเกณฑ์ที่ตั้งไว้ในระยะเวลาอันสั้น ควรส่งการแจ้งเตือนทันทีไปยังผู้จัดการที่รับผิดชอบ ในขณะที่หากอัตราการแทรกแซงสูงค้างอยู่อย่างต่อเนื่อง การจัดประเภทเป็นการ "แจ้งเตือนสรุปรายสัปดาห์" เพื่อเสนอให้ทบทวนการตั้งค่าเกณฑ์ใหม่ จะเป็นวิธีที่มีประสิทธิภาพมากกว่า โดยการแบ่งประเภทการแจ้งเตือนตามระดับความเร่งด่วน

เพื่อป้องกันอาการ Alert Fatigue (สภาวะที่การแจ้งเตือนมีมากเกินไปจนถูกละเลย) มาตรการทั่วไปคือการจำกัดช่องทางการแจ้งเตือนและระดับความสำคัญไว้ประมาณ 3 ระดับ:

• P1 (ตอบสนองทันที): แจ้งเตือนผ่าน Slack และอีเมลพร้อมกัน กรณีที่คาดว่าจะเกิดการละเมิด SLA ภายใน 30 นาที
• P2 (ตอบสนองภายในวัน): แจ้งเตือนผ่านอีเมล กรณีที่อัตราการแทรกแซงเกินค่ามาตรฐาน 1.5 เท่า
• P3 (ทบทวนตามรอบ): รวบรวมไว้ในรายงานรายสัปดาห์

นอกจากนี้ ควรพิจารณาแบ่งระดับการเข้าถึงแดชบอร์ดตามความละเอียดของข้อมูลสำหรับผู้ปฏิบัติงาน ผู้ควบคุมคุณภาพ และฝ่ายบริหารด้วย

บทสรุป: ในการออกแบบ HITL มักเกิดข้อผิดพลาด 2 ประการที่พบบ่อย ได้แก่ การแทรกแซงที่มากเกินไป (Over-intervention) และการไม่ใช้ประโยชน์จากผลตอบรับ (Underutilization of feedback) การทำความเข้าใจสาเหตุและวิธีหลีกเลี่ยงข้อผิดพลาดเหล่านี้ จะช่วยให้สามารถสร้างสมดุลระหว่างประสิทธิภาพของระบบอัตโนมัติและการปรับปรุงคุณภาพได้

แม้จะมีการวางระบบการออกแบบ HITL ไว้เป็นอย่างดีแล้ว แต่ในขั้นตอนการดำเนินงานจริงก็ยังมักจะประสบกับรูปแบบความล้มเหลวที่พบได้บ่อย ในหัวข้อถัดไป (H3) เราจะอธิบายถึงข้อผิดพลาดที่เกิดขึ้นซ้ำๆ ในหน้างานจริงและวิธีรับมืออย่างเป็นรูปธรรม

มีหลายกรณีที่แม้จะนำ HITL มาใช้แล้ว แต่สุดท้ายกลับกลายเป็นสถานการณ์ที่ "มนุษย์ต้องตรวจสอบเกือบทุกรายการ" โดยไม่รู้ตัว

หากตั้งค่าเกณฑ์ (Threshold) สำหรับการทำงานอัตโนมัติไว้เข้มงวดเกินไป งานที่ AI ควรจะจัดการได้ก็จะถูกส่งต่อ (Escalate) ให้มนุษย์ทำแทน ส่งผลให้เกิดภาระงานที่ไม่ต่างจากการทำงานด้วยมือแบบเดิม ซึ่งเปรียบเสมือนการติดตั้งประตูตรวจตั๋วอัตโนมัติแล้ว แต่ยังบังคับให้ทุกคนต้องผ่านการตรวจสอบจากเจ้าหน้าที่ "เพื่อความปลอดภัยไว้ก่อน" ผลที่ได้คือมีเพียงต้นทุนอุปกรณ์ที่เพิ่มขึ้น แต่ประสิทธิภาพการทำงาน (Throughput) กลับไม่ดีขึ้น

สาเหตุหลักที่ทำให้ความถี่ในการแทรกแซงสูงขึ้น

• การตั้งค่าเกณฑ์ที่อนุรักษ์นิยมเกินไป: ตั้งค่าคะแนนความเชื่อมั่น (Confidence Score) ขั้นต่ำไว้สูงเกินไป ทำให้เกิดกฎที่ต้องส่งต่อให้มนุษย์แม้จะมีความไม่แน่นอนเพียงเล็กน้อยก็ตาม
• การครอบคลุมรูปแบบข้อยกเว้นไม่เพียงพอ: กฎการแยกแยะ (Branching rules) มีความคลุมเครือ ทำให้ทุกกรณีที่ตัดสินไม่ได้ถูกส่งมาที่มนุษย์ทั้งหมด
• ผู้รับผิดชอบมีนิสัย "ตรวจสอบเพื่อความมั่นใจ": การออกแบบ UI หรือระบบแจ้งเตือนกระตุ้นให้เกิดการตรวจสอบ ทำให้ยากที่จะข้ามขั้นตอนไปได้

จะเกิดอะไรขึ้นหากปัญหายืดเยื้อ

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

หากปล่อยให้ผลลัพธ์การตัดสินใจที่มนุษย์แก้ไขแล้วจบลงที่สถานะ "ประมวลผลแล้ว" (Processed) AI ก็จะทำผิดพลาดซ้ำเดิมต่อไป สิ่งที่พบเห็นได้บ่อยในหน้างาน HITL (Human-in-the-Loop) คือกรณีที่ผู้รับผิดชอบจัดการเนื้อหาการแก้ไขผ่านสเปรดชีต แม้ว่าจะแก้ไขอย่างละเอียดถี่ถ้วน แต่ข้อมูลเหล่านั้นกลับไม่ได้ถูกนำไปใช้ในการเรียนรู้ของ AI เลย การคิดเพียงว่า "ให้มนุษย์แก้ก็พอ" เป็นการรักษาโครงสร้างที่ทำให้ต้นทุนการแทรกแซงเพิ่มขึ้นอย่างถาวร

รูปแบบของความล้มเหลวมีอยู่หลายประการ หากการออกแบบบันทึกเพียงแค่ตัวเลือก "อนุมัติ/ปฏิเสธ" (Approve/Reject) ก็จะไม่เกิดการสะสมเหตุผลว่าทำไมถึงผิดพลาด ทำให้โมเดลไม่มีเบาะแสในการปรับปรุง ข้อผิดพลาดที่เกิดขึ้นน้อยมักไม่ได้รับฟีดแบ็กและถูกปล่อยทิ้งไว้เป็นเวลานาน ยิ่งไปกว่านั้น หากกฎการแก้ไขขึ้นอยู่กับตัวบุคคล เมื่อมีการเปลี่ยนตัวผู้รับผิดชอบ ความรู้และเกณฑ์การตัดสินใจก็จะสูญหายไปพร้อมกับบุคคลนั้น

เพื่อตัดวงจรโครงสร้างเหล่านี้ การกำหนดให้ "การป้อนข้อมูลเหตุผลการแก้ไขแบบมีโครงสร้าง" (Structured input of correction reasons) เป็นฟิลด์บังคับตั้งแต่ขั้นตอนการออกแบบ UI สำหรับการแทรกแซง (Intervention UI) ถือเป็นวิธีที่มีประสิทธิภาพ แทนที่จะเป็นการเขียนอิสระ การออกแบบให้บันทึกด้วยการเลือกประเภทความผิดพลาด (เช่น ข้อมูลไม่เพียงพอ, ข้อยกเว้นของกฎ, โมเดลจำแนกผิดพลาด เป็นต้น) จะช่วยให้สามารถนำกลับมาใช้เป็นข้อมูลสำหรับการเรียนรู้ได้ง่ายขึ้น

นอกจากนี้ การจัดตั้งบทบาท "Data Curator" เพื่อตรวจสอบข้อมูลฟีดแบ็กที่สะสมไว้เป็นประจำถือเป็นเรื่องสำคัญ สิ่งที่สำคัญไม่ใช่ "ปริมาณ" ของการสะสม แต่เป็น "โครงสร้าง" ของข้อมูล การกำหนดบทบาทหน้าที่ในการรักษาคุณภาพข้อมูลให้ชัดเจนจะทำให้การปรับปรุง AI อย่างต่อเนื่องกลายเป็นจริงได้

รูปแบบความล้มเหลวที่พบเห็นได้บ่อยในการออกแบบ HITL คือการดำเนินงานแบบ "ให้มนุษย์ตรวจสอบไว้ก่อน" หากกฎการแทรกแซงไม่ได้รับการระบุไว้อย่างชัดเจน การตัดสินใจของเจ้าหน้าที่แต่ละคนจะมีความแตกต่างกัน และไม่สามารถสะสมข้อมูลป้อนกลับ (feedback) ได้ ความแม่นยำของการออกแบบจะแปรผันตามระดับของการจัดทำเอกสารกฎการแยกสาขา (branching rules) แทบจะโดยตรง

เนื้อหาที่กล่าวถึงในคู่มือฉบับนี้สามารถสรุปได้เป็น 3 คำถามหลัก ได้แก่ "จะหยุดการตัดสินใจของ AI ภายใต้เงื่อนไขใด" "หลังจากหยุดแล้ว จะส่งต่อให้ใครและอย่างไร" และ "จะนำผลลัพธ์นั้นกลับเข้าสู่ AI อย่างไร" การออกแบบทั้งสามส่วนนี้ให้เป็นลูปเดียวกันคือเงื่อนไขของระบบ HITL ที่ยั่งยืน การจัดทำเอกสารเกณฑ์มาตรฐาน (threshold) ที่ผสมผสานระหว่างคะแนนความเชื่อมั่น (confidence score) และการจำแนกความเสี่ยงทางธุรกิจ, การออกแบบเงื่อนไขการทริกเกอร์ (trigger), UI สำหรับการส่งต่อ และลูปป้อนกลับให้เป็นหนึ่งเดียวกัน, รวมถึงการวัดอัตราการแทรกแซง อัตราการแก้ไข และเวลาในการประมวลผลอย่างต่อเนื่องพร้อมวงจรการทบทวนเกณฑ์มาตรฐาน สิ่งเหล่านี้จะไม่สามารถทำงานได้หากจัดเตรียมแยกส่วนกัน

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

ทั้งนี้ EU AI Act (คาดว่าจะเริ่มบังคับใช้ในปี 2026), "สิทธิในการแทรกแซงโดยมนุษย์" ตามมาตรา 22 ของ GDPR และ "แนวทางปฏิบัติสำหรับผู้ประกอบการ AI (ฉบับที่ 1.0)" ของกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรมญี่ปุ่น (เผยแพร่เมื่อเดือนเมษายน 2024) จะเป็นแกนอ้างอิงที่ช่วยเสริมความแข็งแกร่งให้กับการออกแบบ HITL ในมุมมองของการปฏิบัติตามกฎระเบียบ (compliance) ขอแนะนำให้คุณบูรณาการสิ่งเหล่านี้เข้าตั้งแต่ขั้นตอนการออกแบบ เพื่อให้สามารถตอบโจทย์ทั้งด้านประสิทธิภาพการดำเนินงานและการปฏิบัติตามกฎระเบียบได้พร้อมกันผ่านงานเดียว คือการจัดทำเอกสารกฎการแยกสาขา แทนที่จะแยกปฏิบัติเป็นงานคนละส่วนกัน