ทำ AI evaluation ให้ทำซ้ำได้ด้วย Docker Sandboxes: บันทึกว่าอะไรรันจริง ไม่ใช่แค่ตั้งใจจะรันอะไร

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

ปัญหาไม่ได้อยู่ที่เกณฑ์วัด แต่อยู่ที่การรัน

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

Docker Sandboxes ให้อะไร

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

ขั้นตอนทำงาน: นิยาม ชุดคิต และการรัน

นิยามการประเมินเขียนเป็น YAML ระบุ executor และคำสั่ง เช่น executor: sbx กับคำสั่ง python3 -c print("hello from sbx") จากนั้นใช้คำสั่ง sbx run claude --kit . เพื่อใช้ชุดคิตกับแซนด์บ็อกซ์ และรัน python run_evaluation.py ตัวรันจะอ่าน executor ที่ตั้งไว้ ส่งคำสั่งให้ Docker Sandboxes ทำงาน แล้วบันทึกหลักฐานการรัน

หลักฐานที่ได้เป็น JSON ระบุ executor ที่ใช้ คำสั่งที่รันจริง ผลลัพธ์ทางมาตรฐาน ข้อความผิดพลาด รหัสจบการทำงาน เวลาที่ใช้ เช่น 120 มิลลิวินาทีในตัวอย่าง และค่าแฮชของการตั้งค่าที่ผูกนิยามเข้ากับผลลัพธ์แบบกำหนดได้ ทำให้ตอบได้เสมอว่าผลชิ้นนี้มาจากนิยามเวอร์ชันไหน

ชั้นตัวรันที่สลับได้ และการขยายเป็นชุดประเมิน

จุดออกแบบสำคัญคือนิยามการประเมินไม่ผูกกับสภาพแวดล้อม ตั้ง executor: local จะรันบนเครื่องโฮสต์ ตั้ง executor: sbx จะส่งไป Docker Sandboxes โดยไม่ต้องแก้โค้ด หลายการประเมินรวมเป็นชุดที่รันซ้ำได้ ใช้เปรียบเทียบ prompt หลายแบบ ทดสอบถดถอยระหว่างรุ่น หรือตรวจหลายสถานการณ์ แต่ละรายการให้ผลลัพธ์แยกและชุดให้สรุปรวม รูปแบบเดียวกันนี้ใช้ต่อกับงานทดสอบถดถอย การตรวจนโยบาย การวิเคราะห์ความปลอดภัย และการทดลองสร้างโค้ดได้

สิ่งที่ตัวอย่างนี้ไม่ได้ทำ

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

นำไปใช้กับทีม DevOps ในไทย

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

ทีมงาน Smart Cyber Tech วางระบบ DevOps และไปป์ไลน์ CI/CD ที่รวมการทดสอบและประเมินผลระบบ AI เข้าเป็นขั้นตอนอัตโนมัติ พร้อมเก็บหลักฐานการรันเพื่อการตรวจสอบย้อนหลัง หากทีมของคุณต้องการทำให้การประเมิน AI ทำซ้ำได้และเชื่อถือได้ก่อนขึ้นระบบจริง ปรึกษาได้ที่ แบบฟอร์มติดต่อ