ระบบทดสอบ AI ที่บอกว่าไม่รู้ ดีกว่าระบบที่บอกว่าผ่าน
เจาะลึกแนวคิดระบบทดสอบ AI จาก Derek Wang ใน Essay Eleven ที่ชี้ว่าการบันทึกข้อผิดพลาดและรู้จักยอมรับว่าไม่รู้ มีค่ามากกว่าแค่การบอกว่าผ่าน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Karl Popper ชี้ว่าวิทยาศาสตร์ก้าวหน้าด้วยการกำจัดความผิดพลาด ไม่ใช่การสะสมความถูกต้อง
- ระบบทดสอบ AI ที่ดีต้องบันทึกประวัติความล้มเหลว (Ledger) แทนที่จะเป็นแค่ประตูผ่าน/ตก
- การทดสอบแบบเต็มรูปแบบใช้เวลา 10 วินาที และเติบโตเป็น 50 สถานการณ์ใน 6 ชุดทดสอบ
- กรณีศึกษาจริงพิสูจน์ว่าระบบช่วยสกัดข้อผิดพลาด HTTP-500 ซ่อนเร้นได้ถึง 22 จุดก่อนส่งมอบ
Karl Popper นักปรัชญาชื่อดังในช่วงกลางศตวรรษที่ 20 ได้พลิกมุมมองเกี่ยวกับการสะสมความรู้ทางวิทยาศาสตร์ โดยระบุว่าวิทยาศาสตร์ไม่ได้ก้าวหน้าจากการพิสูจน์ว่าตนเองถูกต้องบ่อยขึ้น แต่ก้าวหน้าจากการที่คำตอบที่ผิดพลาดถูกกำจัดออกไปอย่างชัดเจน ทฤษฎีที่สวยงามจะมีค่าเท่ากับสิ่งที่มันสามารถเอาตัวรอดได้ ไม่ใช่สิ่งที่มันอธิบายได้ การคาดเดาและหักล้างจึงเป็นหัวใจสำคัญของการทดสอบ
เมื่อนำแนวคิดนี้มาประยุกต์ใช้กับการควบคุมระบบปัญญาประดิษฐ์ (AI Harness Engineering) เป้าหมายจึงไม่ใช่การสร้างเครื่องจักรที่พยายามพิสูจน์ว่าโค้ดนั้นถูกต้อง แต่เป็นเครื่องจักรที่พยายามพิสูจน์ว่าโค้ดนั้นผิดพลาด พร้อมทั้งเก็บบันทึกความล้มเหลวทุกครั้งที่เคยเกิดขึ้น ซึ่งบันทึกนี้เปรียบเสมือนหัวใจสำคัญที่ระบบ AI ส่วนใหญ่มักขาดหายไป
การเริ่มต้นทดสอบของหลายทีมมักมีจุดเริ่มต้นที่คล้ายคลึงกัน คือการที่เอเจนต์ตรวจสอบผลลัพธ์แล้วประกาศว่าใช้งานได้ โดยไม่มีการกำหนดบรรทัดฐานหรือความรับผิดชอบที่ชัดเจน หากไม่เคยนับจำนวนความล้มเหลวของตนเอง ก็เป็นไปไม่ได้เลยที่จะรู้ว่ามีหนี้สินทางเทคนิคสะสมอยู่มากน้อยเพียงใด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ระบบทดสอบเต็มรูปแบบในท้ายที่สุดใช้เวลาในการรันเพียง 10 วินาที ซึ่งความเร็วนี้นี่เองที่เป็นดาบสองคม ความเร็วที่มากเกินไปทำให้ง่ายต่อการละเลย และการข้ามขั้นตอนการตรวจสอบก็คือหนทางที่ทำให้ความมั่นใจกลายเป็นคำโกหก ความเร็วและความปลอดภัยจึงเป็นสิ่งต้องขับเคลื่อนไปพร้อมกัน การตอบสนองที่รวดเร็วยิ่งช่วยให้การเปลี่ยนแปลงที่ถูกต้องมีความกล้าหาญมากขึ้น
การที่ระบบทดสอบสามารถทำงานเสร็จสิ้นภายใน 10 วินาทีสะท้อนถึงหลักการ Fast Feedback Loop ในวิศวกรรมซอฟต์แวร์สมัยใหม่ เมื่อนักพัฒนาหรือ AI agent ได้รับฟีดแบ็กเร็วพอ พวกเขาจะกล้า refactor โค้ดส่วนที่ซับซ้อนขึ้น เพราะรู้ว่าหากเกิดข้อผิดพลาด ระบบจะตรวจจับได้ทันทีโดยไม่ต้องรอรอบการรันที่ยาวนานเป็นชั่วโมง ซึ่งช่วยลดความลังเลและเพิ่มความถี่ในการปรับปรุงโค้ดให้ดีขึ้นอย่างต่อเนื่อง
แนวคิดเรื่องบันทึกความล้มเหลว (Ledger) แตกต่างจากการใช้เกณฑ์ตัดสิน (Gate) ทั่วไปอย่างสิ้นเชิง เนื่องจากเกณฑ์ตัดสินทำหน้าที่แค่หยุดงานที่แย่ แต่สะพานที่ดีจะช่วยให้งานที่ดีเดินทางไปข้างหน้าได้ ฟีดแบ็กที่น่าเชื่อถือช่วยเปลี่ยนพฤติกรรมของเอเจนต์ ทำให้กล้าที่จะปรับเปลี่ยนสัญญาหรือรีแฟกทอรีโค้ดโดยรู้ทันทีว่ามันส่งผลกระทบต่อส่วนอื่นของระบบหรือไม่ แทนที่จะเป็นการยิงคำสั่งออกไปในความมืดแล้วภาวนาไม่ให้ระบบล่ม
"A test system that can say 'I don't know' is worth more than one that says 'passed'"
Derek Wang
ระบบทดสอบ fulltest ได้พัฒนาองค์ประกอบสำคัญ 3 ประการที่ตัวรันการทดสอบทั่วไปมักมองข้าม ประการแรกคือการจำแนกประเภทก่อนตัดสิน โดยเก็บบันทึกประวัติความล้มเหลวและสูตรการซ่อมแซม ประการที่สองคือการที่บันทึกนี้เติบโตขึ้นจากเหตุการณ์จริง ปัญหาที่ได้รับการวินิจฉัย และคอมมิตใน git และประการที่สามคือการยกระดับบรรทัดฐานด้วยตนเองอย่างต่อเนื่อง ซึ่งป้องกันไม่ให้ระบบถอยหลังกลับไปสู่จุดที่แย่กว่าเดิม
บทเรียนสำคัญคือปริมาณของชุดทดสอบไม่ได้เป็นตัวชี้วัดความปลอดภัยที่แท้จริง กำแพงที่มีทหารยามนับพันนายแต่ไม่เคยพบเห็นการต่อสู้ก็เป็นเพียงแค่รั้วสวนราคาแพง ตัวชี้วัดเดียวที่มีความหมายคือชุดทดสอบนั้นสามารถดักจับเหตุการณ์ผิดพลาดจริงในอดีตได้มากน้อยเพียงใด ซึ่งจากการนำไปปฏิบัติจริง ระบบได้ขยายตัวเป็น 50 สถานการณ์ใน 6 ชุดทดสอบ และสามารถดักจับข้อผิดพลาด HTTP-500 ที่ซ่อนอยู่ลึกถึง 22 จุดก่อนที่จะถูกส่งมอบสู่การใช้งานจริง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น