ผมพบว่าเมทริกซ์ (metric) ของ safety-gate เพียงตัวเดียวได้บดบังเหตุการณ์ระบบขัดข้อง (outage) ที่กินเวลาทั้งวันในฟีเจอร์การอธิบายด้วย AI การที่เมทริกซ์นี้ปฏิบัติกับ “gate rejection” (การปฏิเสธโดย gate) และ “model load failure” (ความล้มเหลวในการโหลดโมเดล) ว่าเป็นสิ่งเดียวกัน ทำให้เกิดความรู้สึกที่ผิดพลาดว่าระบบยังทำงานปกติ โดยมันบันทึกว่ามีการปฏิเสธ 4 ครั้งและไม่มีความสำเร็จเลย แต่ในความเป็นจริง โมเดลไม่ได้ทำงานเลยในช่วงเวลานั้น ซึ่งเป็นความผิดพลาดที่อาจทำให้ผู้ควบคุมระบบมองไม่เห็นว่าระบบกำลังพังอยู่

ความสับสนนี้เกิดขึ้นได้อย่างไร

ฟีเจอร์นี้ใช้โมเดลภาษาในเครื่อง (local language model) เพื่อเปลี่ยนตรรกะดิบของเครื่องจักรให้เป็นประโยคที่มนุษย์อ่านเข้าใจได้ โดยมี safety gate อยู่ในขั้นตอนถัดมาเพื่อบล็อกเอาต์พุตใดๆ ที่ละเมิดกฎที่กำหนดไว้ ในระบบโปรดักชัน ผมได้แสดงตัวนับ (counter) เพียงตัวเดียวที่จะเพิ่มค่าขึ้นทุกครั้งที่ gate ปฏิเสธประโยค เมื่อโดรนบันทึกการอธิบายด้วย AI ไป 4 ครั้ง ตัวนับก็รายงานว่ามีการปฏิเสธ 4 ครั้งและไม่มีเอาต์พุตที่สำเร็จเลย ผมจึงเข้าใจว่านั่นคือการที่ gate ทำหน้าที่ของมัน ไม่ใช่การที่ฟีเจอร์กำลังใช้งานไม่ได้

สิ่งที่ตัวนับนี้บดบังไว้คือความล้มเหลวแบบสองขั้นตอน:

  1. โมเดลไม่ได้ทำงาน (Model not running) – โมเดลใช้เครื่องร่วมกับส่วนอื่นๆ ของระบบ เพื่อประหยัดหน่วยความจำ host จึงทำการ unload โมเดลออกหลังจากไม่มีการใช้งาน
  2. การหมดเวลาขณะโหลดใหม่ (Timeout on reload) – เมื่อมีภัยคุกคามใหม่ปรากฏขึ้น ระบบพยายามโหลดข้อมูลโมเดลขนาดประมาณ 2 กิกะไบต์ขึ้นมาใหม่ การโหลดนี้ใช้เวลานานเกินกว่ากำหนดการตอบสนองที่ 30 วินาที ทำให้คำขอหมดเวลา (timeout) และส่งคำตอบที่ว่างเปล่ากลับมา

เนื่องจากตัวนับปฏิบัติกับการปฏิเสธโดย gate และการตอบกลับที่ว่างเปล่าจากการหมดเวลาว่าเป็นเหตุการณ์เดียวกัน แดชบอร์ดจึงแสดงผลว่า “safety gate กำลังทำงาน” ในขณะที่ฟีเจอร์ AI นั้นใช้งานไม่ได้โดยสิ้นเชิง

ทำไมเรื่องนี้ถึงสำคัญ

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

การแก้ไขที่ช่วยให้กลับมามองเห็นปัญหาได้อีกครั้ง

ผมได้ทำการเปลี่ยนแปลงในทางปฏิบัติ 3 อย่าง:

  • ให้โมเดลคงอยู่ในหน่วยความจำ (Keep the model resident) – ปรับปรุง host ให้เก็บโมเดลไว้ในหน่วยความจำ เพื่อกำจัดความล่าช้าในการโหลดใหม่
  • ขยายเวลา timeout – เพิ่มช่วงเวลาการตอบสนองเพื่อรองรับการโหลดที่อาจช้าในบางครั้ง
  • แยกตัวนับ (Split the counter) – เปลี่ยนจากเมทริกซ์ “rejected by gate” เพียงตัวเดียว เป็นตัวนับ 4 แบบที่แยกจากกัน ได้แก่: accepted (ยอมรับ), rejected (ปฏิเสธ), empty response (การตอบกลับว่างเปล่า), และ no answer (ไม่มีการตอบกลับ)

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

ข้อแลกเปลี่ยนและข้อโต้แย้ง

สิ่งที่ควรเฝ้าระวังต่อไป

นักพัฒนาที่กำลังนำส่วนประกอบ AI ออกใช้งาน ควรตรวจสอบตัวนับแบบรวม (aggregated counters) ใดๆ ที่นำการตรวจสอบความปลอดภัยไปปนกับความล้มเหลวในระดับระบบ การสร้างประวัติการทำงาน (history log) ที่ละเอียดซึ่งบันทึกเส้นทางของแต่ละคำขอ เช่น การเริ่มโหลดโมเดล, การประเมินโดย gate, และผลลัพธ์สุดท้าย จะช่วยให้มีข้อมูลเชิงนิติวิทยาศาสตร์ (forensic data) ที่จำเป็นในการตรวจพบปัญหาที่ซ่อนอยู่

บทเรียนสำคัญ: เมทริกซ์ “gate-rejection” เพียงตัวเดียวสามารถบดบังบริการ AI ที่หยุดทำงานได้ การแยกเมทริกซ์นั้นออกเป็นเหตุการณ์ย่อยๆ จะช่วยเผยความจริงและป้องกันความมั่นใจที่ผิดพลาดในระบบที่ไม่ได้ทำงานจริง