วิธีตรวจงาน AI Agent ก่อนใช้งานจริง คือเปิดชิ้นงานฉบับที่ส่ง เทียบกับเกณฑ์ที่ตกลงไว้ ตรวจหลักฐานของขั้นตอนสำคัญ แล้วแยกว่าข้อใดผ่าน ไม่ผ่าน หรือยังไม่ได้ตรวจ ก่อนตัดสินใจรับงาน คำว่า “เสร็จแล้ว” คะแนนสูง หรือผล build ผ่านอย่างเดียว ยังไม่ครอบคลุมทุกเงื่อนไขของงาน
ใช้คู่มือนี้เมื่อ Agent ส่งไฟล์ รายงาน หรือผลของงานหลายขั้นกลับมาแล้ว และคุณต้องตัดสินใจว่าจะรับ ส่งแก้ หรือขอหลักฐานเพิ่ม เนื้อหาเน้นการตรวจรับทั้งงาน ส่วนการตรวจโค้ดที่ AI เขียนและการตรวจสอบคำตอบ AI ต้องใช้เกณฑ์เฉพาะประเภทเพิ่มเติม หากยังไม่ได้มอบหมายงาน เริ่มจาก Prompt 7 ชั้นสำหรับตั้งโจทย์ ขอบเขต และหลักฐานที่ต้องส่ง
ขอบเขตและข้อจำกัด: ขั้นตอนนี้เป็นแนวทางที่ Hybrid Mind เสนอโดยสังเคราะห์จากแหล่งอ้างอิงท้ายบท ยังไม่ได้ผ่านการทดลองยืนยันว่าเป็นกรอบที่ใช้ได้ครบกับงานทุกประเภท ให้ปรับเกณฑ์ตามงานและความเสี่ยง “ตรวจงาน AI Agent” ในหน้านี้หมายถึงตรวจความถูกต้องและความครบของผลงาน ไม่ได้ใช้ตัดสินว่าใครหรือเครื่องมือใดเป็นผู้เขียนข้อความ ตัวอย่างและแบบฝึกเป็นสถานการณ์สมมติ ไม่มีการเรียกโมเดลหรือวัดประสิทธิภาพผลิตภัณฑ์จากหน้านี้
เลือกอ่านตามจุดที่กำลังตรวจ
- ตรวจรับงาน AI Agent หมายถึงอะไร
- 6 ขั้นตอนตรวจสอบงาน AI
- หลักฐานแบบไหนตอบคำถามอะไร
- เช็กลิสต์ก่อนรับงาน
- ตัวอย่างตรวจรับและแบบฟอร์มคัดลอก
- คำถามที่พบบ่อยและข้อจำกัด
ตรวจรับงาน AI Agent หมายถึงอะไร?
การตรวจรับ คือการตัดสินว่าสิ่งส่งมอบตรงเงื่อนไขที่ผู้ว่าจ้างยอมรับหรือยัง โดยระบุฉบับ ขอบเขต และหลักฐานประกอบ ส่วน AI Agent ในคู่มือนี้หมายถึงระบบที่ใช้ AI ร่วมกับเครื่องมือทำงานหลายขั้น เช่น อ่านข้อมูล ร่าง แก้ไฟล์ และรายงานผล จึงต้องตรวจทั้งเนื้อหาปลายทางและผลของขั้นตอนที่จำเป็น
“ถูกต้อง” ต้องผูกกับงาน เช่น ตัวเลขตรงต้นทาง สรุปไม่เกินหลักฐาน ไฟล์เปิดได้ ฟังก์ชันให้ผลตามข้อกำหนด หรือส่งถึงปลายทางที่ได้รับอนุญาต การรับร่างเพื่ออ่านต่อ การรับไฟล์พร้อมใช้ และการอนุมัติให้เผยแพร่เป็นคนละขอบเขต ควรบันทึกให้ชัดว่ากำลังตัดสินข้อใด
6 ขั้นตอนตรวจสอบงาน AI ก่อนนำไปใช้
1. ระบุชิ้นงานฉบับที่ตรวจและเกณฑ์บังคับ
เก็บคำสั่งล่าสุด รายการสิ่งส่งมอบ และเงื่อนไขที่จำเป็นไว้ข้างชิ้นงาน ระบุชื่อไฟล์ ฉบับ วันที่ หรือ commit ตามที่มีจริง แล้วแยก “ต้องผ่านก่อนรับ” ออกจาก “ข้อเสนอปรับปรุง” หากไม่มีเกณฑ์เดิม ให้ตกลงกับเจ้าของงานก่อนตัดสิน
- งานสรุป: ข้อความสำคัญตรงต้นทางและแยกสิ่งที่ยังไม่ยืนยัน
- งานแก้โค้ด: พฤติกรรมที่ต้องเปลี่ยนทำงานได้ และส่วนที่ตกลงให้คงไว้ไม่เสีย
- งานส่งไฟล์: เปิดไฟล์ได้ ชนิดและเนื้อหาตรงที่ขอ ผู้รับมีสิทธิ์เข้าถึงตามที่อนุมัติ
อย่าเปลี่ยนเกณฑ์ย้อนหลังเพื่อให้รายงานเป็นสีเขียว เมื่อเจ้าของเปลี่ยนโจทย์ให้บันทึกฉบับใหม่ และระบุว่าผลตรวจเดิมข้อใดใช้ต่อได้ แนวทาง Evaluation best practices ของ OpenAI เน้นกำหนดความสำเร็จและข้อมูลประเมินให้สัมพันธ์กับงานจริง
2. เปิดชิ้นงานและจับคู่หลักฐานกับรอบงานเดียวกัน
เปิดข้อความหรือไฟล์ฉบับที่ส่งจริง แยกคำกล่าวของ Agent ออกจากผลเครื่องมือและสิ่งที่คุณตรวจได้ หากมีหลายรอบ ให้จับคู่ด้วยตัวระบุที่ระบบให้ เช่น run, call หรือ revision พร้อมรักษาประวัติความผิดพลาดที่เกี่ยวข้องไว้ ไม่จับคู่เพียงเพราะชื่อเครื่องมือเหมือนกัน
ใบตรวจรับควรชี้ได้ว่า “ข้อกำหนดนี้ตรวจจากอะไร” เช่น ย่อหน้าที่แก้ ช่วงข้อมูลในตาราง ผลทดสอบของ commit เดียวกัน หรือบันทึกการอ่านไฟล์กลับ ฝึกอ่านหลักฐานแบบนี้ได้ใน gh-aw: แยกคำรายงาน ผลเครื่องมือ และชิ้นงานก่อนตรวจรับ
3. ตรวจเนื้อหาและที่มาของข้ออ้างสำคัญ
ย้อนเปิดต้นทางของชื่อ ตัวเลข วันที่ และข้อสรุปที่มีผลต่อการตัดสินใจ ดูว่าข้อความอ้างรองรับประโยคนั้นจริงหรือไม่ และยังใช้กับช่วงเวลาหรือเวอร์ชันนี้ได้หรือไม่ คำนวณซ้ำเมื่อผลรวมมีความสำคัญ หากแหล่งขัดกันให้คงความขัดแย้งไว้จนได้คำยืนยัน
แยกข้อมูลหลัก คอมเมนต์เสนอแก้ และคำบรรยายภาพให้ชัด ไม่รวมข้อเสนอที่ยังไม่อนุมัติเข้าเป็นข้อเท็จจริงโดยเงียบ บท OmniBox: ติดประเภทและตำแหน่งที่มาให้ข้อความ มีตัวอย่างฝึกย้อนจากร่างกลับไปยังข้อมูลแต่ละส่วน
4. ทดสอบพฤติกรรมและผลข้างเคียงตามความเสี่ยง
เลือกวิธีตรวจให้ตรงเกณฑ์ เริ่มจากเส้นทางใช้งานสำคัญ แล้วเพิ่มกรณีขอบเขตและกรณีผิดพลาดที่เกี่ยวข้อง เช่น ข้อมูลว่าง อินพุตไม่ถูกต้อง สิทธิ์ไม่พอ หรือความพยายามส่งงานซ้ำ เก็บผลที่สังเกตได้ พร้อมเงื่อนไขและข้อจำกัดของการทดสอบ
สำหรับโค้ด ให้ตรวจ diff และผลรันที่อนุญาต รวมถึงสิ่งที่อาจเปลี่ยนโดยไม่ตั้งใจ ใช้ผู้ตรวจหรือชุดทดสอบที่ไม่ได้ยึดคำตอบของผู้สร้างงานเพียงอย่างเดียวเมื่อทำได้ GitHub แนะนำให้ ตรวจและทดสอบงานจาก coding agent ก่อนนำไปรวมใช้งาน เพราะคำแนะนำและโค้ดที่ได้อาจมีข้อผิดพลาด
อ่าน กรณี build ผ่านแต่ยังต้องตรวจพฤติกรรม เพื่อเลือกหลักฐานให้ตรงเป้าหมาย และ Reward Hacking: เมื่อตัวชี้วัดเปิดช่องให้ได้คะแนนโดยไม่สำเร็จตามงาน เพื่อทบทวนว่าตัวตรวจของคุณวัดสิ่งที่ต้องการจริงหรือไม่
การทดสอบต้องอยู่ในสิทธิ์ที่ได้รับ การตรวจพบช่องว่างไม่ใช่เหตุให้ส่งข้อมูลส่วนตัว ใช้เงิน เปลี่ยนระบบจริง หรือเผยแพร่งานเพิ่มเอง ขออนุญาตก่อนขยายขอบเขต และปิดข้อมูลลับในหลักฐานที่จะส่งต่อ
5. แยกสถานะรายเกณฑ์ พร้อมเหตุผล
- PASS · ผ่าน: ตรวจเกณฑ์นี้กับฉบับที่ส่งแล้ว และมีหลักฐานรองรับผลตามเงื่อนไขที่ระบุ
- FAIL · ไม่ผ่าน: ตรวจแล้วพบสิ่งที่ขัดกับเกณฑ์ ระบุความต่างและตำแหน่งให้แก้ได้
- NOT_CHECKED · ยังไม่ได้ตรวจ: ยังไม่ได้ทำขั้นตรวจที่จำเป็น ห้ามนับรวมเป็นผ่าน
- INCONCLUSIVE · หลักฐานยังไม่พอสรุป: ตรวจหรือพยายามตรวจแล้ว แต่ผลกำกวม ข้อมูลขาด หรือหลักฐานขัดกัน ให้ระบุสิ่งที่ต้องเพิ่ม
ชื่อสถานะข้างต้นเป็นภาษาตรวจรับที่คู่มือนี้เสนอ เครื่องมือจริงอาจใช้ UNKNOWN, BLOCKED หรือคำอื่น จึงต้องอ่านความหมายและสาเหตุของแต่ละระบบ ไม่แปลง “ยังไม่รู้” เป็น “ผิด” และไม่ใช้จำนวนข้อผ่านกลบเกณฑ์บังคับที่ยังค้าง
ตัวอย่างการแยกสถานะพร้อมขอบเขตอยู่ใน squirrelscan: ยังไม่ได้ตรวจควรปรากฏในรายงานอย่างไร หากข้อลิงก์อยู่นอกขอบเขตร่างข้อความ อาจรับเฉพาะร่างได้ แต่ยังต้องคงสถานะข้อลิงก์ไว้ตามจริง
6. ตัดสินใจเฉพาะขอบเขตที่หลักฐานรองรับ แล้วส่งต่อ
รับงานเมื่อเกณฑ์บังคับของขอบเขตนั้นผ่านและมีหลักฐานครบ ส่งกลับจุดที่ไม่ผ่านพร้อมผลที่ต้องการ หรือพักข้อที่ยังตรวจไม่ได้พร้อมคำขอหลักฐานเฉพาะจุด การรับบางส่วนต้องระบุให้ชัดว่ารับส่วนใด ใครรับความเสี่ยงที่เหลือ และงานหยุดอยู่ตรงไหน
เมื่อมีฉบับแก้ ให้เทียบกับคำขอเดิมและสิ่งที่ต้องคง ตรวจซ้ำส่วนที่เปลี่ยนและส่วนที่อาจได้รับผลกระทบโดยไม่รื้อทั้งงานโดยไม่จำเป็น ดู Pathmode: ตรวจคำขอแก้ก่อนปิดประเด็น แล้วแยกการปิดข้อแก้ไขออกจากการอนุมัติทั้งงาน
แนบสิ่งส่งมอบ ใบตรวจรับ ข้อจำกัด ผู้รับผิดชอบ และขั้นถัดไป หากเป็นการเปลี่ยนระบบควรมีวิธีย้อนกลับที่ตรวจได้ตามขอบเขตงาน แนวคิดเก็บสถานะและจุดหยุดอ่านต่อได้ใน Loop Engineering: ตรวจผล บันทึก และตัดสินใจก่อนรอบต่อไป
หลักฐานแบบไหนตอบคำถามอะไร?
- ต้นฉบับพร้อมตำแหน่งอ้างอิง: ใช้ตรวจว่าข้อความมีที่มาและถ่ายทอดตรงต้นทาง แต่ยังต้องประเมินคุณภาพและความเป็นปัจจุบันของแหล่งนั้น
- ไฟล์ที่เปิดอ่านกลับหรือ diff: ใช้ดูสิ่งที่ส่งและสิ่งที่เปลี่ยนจริง แต่ชื่อไฟล์อย่างเดียวไม่ยืนยันเนื้อหา
- log หรือผลเครื่องมือ: ใช้ตามรอยขั้นตอนในรอบที่ระบุ แต่ต้องตรวจว่าครบ ตรงฉบับ และแยกเริ่มงานออกจากเสร็จงาน
- ผลทดสอบ: รองรับเฉพาะกรณี สภาพแวดล้อม และเกณฑ์ที่รันจริง ระบุกรณีที่ข้ามหรือรันไม่ได้ด้วย
- ภาพหน้าจอ: ช่วยยืนยันสิ่งที่มองเห็น ณ เวลาหนึ่ง แต่ปุ่มที่ดูถูกต้องยังต้องตรวจพฤติกรรม และภาพไม่ยืนยันผลส่งปลายทางทุกกรณี
- การอ่านกลับจากปลายทาง: ใช้ยืนยันสถานะหลังบันทึกหรือส่งตามสิทธิ์ที่อนุญาต คำตอบรับคำสั่งหรือการเข้าคิวเพียงอย่างเดียวยังไม่ยืนยันทุกขั้นตอนภายหลัง
แนวทาง NIST AI RMF ในส่วน Measure สนับสนุนการบันทึกชุดทดสอบ วิธีวัด ผล และข้อจำกัด รวมถึงการประเมินในบริบทใกล้เคียงการใช้งานจริง การใช้เช็กลิสต์นี้ไม่ได้เป็นการรับรองตามมาตรฐานหรือรับประกันว่าปราศจากความเสี่ยง
เช็กลิสต์ตรวจงาน AI ก่อนรับสิ่งส่งมอบ
ใช้เป็นรายการอ่านตรวจ เลือกเฉพาะข้อที่ตรงงาน และกำหนดข้อบังคับก่อนเริ่ม อย่านับจำนวนเครื่องหมายถูกเป็นคะแนนคุณภาพรวม
- ระบุคำสั่งล่าสุด สิ่งส่งมอบ และฉบับที่กำลังตรวจได้
- เปิดชิ้นงานจริงได้ และหลักฐานเป็นของฉบับหรือรอบเดียวกัน
- ข้ออ้างสำคัญย้อนถึงแหล่งได้ พร้อมแยกข้อเท็จจริง ข้อเสนอ และสิ่งที่ยังไม่รู้
- ตัวเลข ชื่อ วันที่ และเงื่อนไขสำคัญตรงต้นทางหรือคำนวณซ้ำแล้วตามเกณฑ์
- พฤติกรรมหลักและกรณีผิดพลาดที่จำเป็นมีผลตรวจที่อ่านได้
- ส่วนที่ต้องคงและผลข้างเคียงที่สำคัญได้รับการตรวจตามขอบเขต
- แต่ละเกณฑ์มีสถานะ เหตุผล หลักฐาน และข้อจำกัด ไม่มีข้อที่ข้ามแล้วถูกนับว่าผ่าน
- สิทธิ์ ข้อมูลส่วนตัว และการอนุมัติที่จำเป็นถูกตรวจแยกจากคุณภาพของผลงาน
- คำตัดสินระบุว่ารับ ส่งแก้ หรือพักส่วนใด พร้อมผู้รับผิดชอบขั้นถัดไป
- การเผยแพร่ ส่ง หรือเปลี่ยนระบบจริงมีการอนุมัติตามที่ตกลงไว้
ตัวอย่าง: ตรวจร่างสรุปนัดหมายก่อนส่ง
สถานการณ์สมมติ: เจ้าของขอร่างข้อความเท่านั้น โดยยืนยันให้ใช้ข้อมูลฉบับ A ว่า “ประชุมวันพุธ เวลา 10:00 ห้อง A” มีคอมเมนต์ B เสนอเปลี่ยนเป็น 14:00 แต่ยังไม่อนุมัติ ร่าง V2 ที่ให้ตรวจมีข้อความว่า “ประชุมวันพุธ เวลา 10:00 ห้อง A” และมีบันทึกแยกว่า “คอมเมนต์ B เสนอ 14:00 ยังไม่อนุมัติ” ร่างแนบป้าย [ลิงก์แผนที่] ไว้ แต่ตัวอย่างไม่ได้ให้ URL หรือผลตรวจการเข้าถึง ตัวอย่างนี้ไม่มีการส่งข้อความหรือเปิดลิงก์จริง
- เกณฑ์ 1 ใช้เวลาที่อนุมัติ: PASS ในตัวอย่าง เพราะ V2 ระบุ 10:00 ตรง A
- เกณฑ์ 2 แยกข้อเสนอที่ค้าง: PASS ในตัวอย่าง เมื่อบันทึก B เป็นข้อเสนอ 14:00 ที่ยังไม่อนุมัติ
- เกณฑ์ 3 ลิงก์แผนที่เข้าถึงได้: NOT_CHECKED เพราะไม่ได้ตรวจ ยังสรุปว่าลิงก์ใช้ได้หรือเสียไม่ได้
- ขอบเขตที่รับ: ร่างข้อความให้เจ้าของอ่าน หากเกณฑ์บังคับมีเพียงข้อ 1–2
- จุดหยุด: ยังไม่ส่งถึงผู้ร่วมประชุม หากต้องการรับพร้อมลิงก์ใช้งานได้ ให้ขอสิทธิ์และตรวจลิงก์ก่อนตัดสินส่วนนั้น
บันทึกตรวจรับตัวอย่าง: “อ่านร่าง V2 เทียบ A แล้ว วัน เวลา และห้องตรงข้อมูลที่อนุมัติ คอมเมนต์ B ยังแยกเป็นข้อเสนอ รับเฉพาะร่างเพื่อทบทวน ลิงก์แผนที่ยังไม่ได้ตรวจ และยังไม่ได้ส่งข้อความ”
แบบฟอร์มใบตรวจรับที่คัดลอกไปใช้ได้
เติมเฉพาะข้อมูลที่มีจริง หากไม่มีหลักฐานให้เขียนว่าขาดอะไร ชื่อไฟล์ ตัวระบุ และผลตรวจต้องมาจากงานของคุณ
- งานและขอบเขตที่ขอรับ: …
- คำสั่ง/เกณฑ์ฉบับที่ใช้: …
- ชิ้นงานและฉบับที่ตรวจ: …
- เกณฑ์บังคับแต่ละข้อ: …
- สถานะของแต่ละข้อ: PASS / FAIL / NOT_CHECKED / INCONCLUSIVE
- หลักฐานและตำแหน่งที่ย้อนตรวจได้: …
- เงื่อนไขการตรวจ วันที่ และผู้ตรวจ: …
- สิ่งที่ยังไม่ครอบคลุมหรือข้อมูลที่ขาด: …
- คำตัดสิน: รับเฉพาะ … / ส่งแก้ … / พักรอ …
- ผู้รับผิดชอบและขั้นถัดไปที่ได้รับอนุญาต: …
เกมจำลอง: หยุด ตรวจหลักฐาน แล้วค่อยส่งต่อ
ลองใช้หลักคิดตรวจรับกับงานห้องข่าวจำลอง: เมื่อ Agent พบคำสั่งแทรก หลักฐานที่ยังเปิดไม่ได้ หรือคำขอเผยแพร่ที่ต้องรออนุมัติ ควรหยุดส่วนใดและขอหลักฐานอะไรเพิ่ม? เกมนี้เป็นแบบฝึกเสริมเรื่องการตอบสนองเหตุขัดข้อง โดยใช้กติกาสำเร็จรูปของ Hybrid Mind ผลในเกมไม่ใช่ใบรับรองว่าชิ้นงานจริงถูกต้องหรือปลอดภัย
HYBRID MIND · REUSABLE GAME SYSTEM
Agent Failure Challenge — Stop, Verify, Recover
เลือกแนวทางตอบสนองเหตุการณ์ Agent ผิดพลาดทีละด่าน พร้อมเรียนรู้ผลของสิทธิ์ การตรวจสอบ และการทำงานซ้ำ
แม่แบบ: Newsroom — ตรวจข่าวก่อนเผยแพร่
กำลังเตรียมเกม…
สิ่งที่เรียนรู้: แยก Prompt Injection, Duplicate Action, Verification Failure และ Human Override ออกจากกันด้วยตัวอย่างสมมติ
Educational simulation · กฎและภาพแสดงผลของ Hybrid Mind ไม่ใช่ผลทดลองต้นฉบับหรือการคำนวณจริงจากเกมเต็ม · ไม่เรียก LLM
HYBRID MIND ORIGINAL RULES · bundled local code assets/system-core.js · source SHA256 0a61dc0eb1cf · adapter v1 · ทดสอบด้วยข้อมูลสมมติ ไม่ใช้ LLM หรือข้อมูลผู้เล่น
เกมใช้กฎจำลองและข้อมูลสมมติ ไม่เรียกโมเดล AI จริง หลังเล่นให้จดว่าเลือกหยุด ตรวจซ้ำ หรือให้มนุษย์ตัดสินในจุดใด แล้วเทียบกับเกณฑ์ตรวจรับของงานคุณ
ลองตรวจรับ 3 สถานการณ์
อ่านหลักฐานแล้วตัดสินก่อนเปิดเฉลย: เกณฑ์ใดผ่าน ไม่ผ่าน หรือยังไม่ได้ตรวจ และรับงานในขอบเขตที่ขอได้หรือยัง? โจทย์และผลตรวจทั้งหมดเป็นเรื่องสมมติสำหรับฝึก ไม่มีการเรียกโมเดล รันโค้ด หรือส่งข้อความจริง
เลือก “เปิดเฉลย” เพื่อดูคำตอบ หากใช้แป้นพิมพ์ ให้กด Tab ไปยังหัวข้อเฉลย แล้วกด Enter หรือ Space เพื่อเปิดหรือปิด
1. Agent บอกว่าครบ แต่ชิ้นงานมีอะไร?
เกณฑ์บังคับ: ร่างต้องมีครบ 3 หัวข้อ คือ เป้าหมาย วิธีทำ และข้อจำกัด คำรายงานของ Agent: “เพิ่มครบ 3 หัวข้อแล้ว” ร่าง V1 ที่ส่งจริงทั้งหมด: “เป้าหมาย: ลดเวลาสรุปเอกสาร / วิธีทำ: อ่านต้นฉบับแล้วร่างสรุป” ควรให้สถานะเกณฑ์ความครบว่าอะไร?
เปิดเฉลยข้อ 1: คำรายงานกับชิ้นงาน
FAIL · ไม่ผ่าน เพราะร่าง V1 ขาดหัวข้อข้อจำกัด คำรายงานว่าเสร็จแล้วไม่เปลี่ยนสิ่งที่พบในชิ้นงาน ส่งกลับให้เติมหัวข้อที่ขาด แล้วอ่านฉบับแก้ก่อนรับร่างตามเกณฑ์นี้
2. ข้อบังคับหนึ่งข้อยังไม่ได้ตรวจ
ขอบเขตที่ขอรับ: ร่างพร้อมลิงก์ใช้งานได้ โดยต้องผ่านทั้งเวลาและลิงก์ เวลาอนุมัติ: 10:00 ร่าง V1: “ประชุมเวลา 10:00 [ลิงก์แผนที่]” บันทึกตรวจ: อ่านเวลาแล้วตรงต้นทาง แต่ยังไม่ได้เปิดลิงก์ ตัวอย่างไม่ให้ URL จริง สถานะลิงก์คืออะไร และรับงานทั้งขอบเขตนี้ได้หรือยัง?
เปิดเฉลยข้อ 2: การตรวจที่ยังค้าง
เวลา: PASS · ลิงก์: NOT_CHECKED ยังรับงานในขอบเขต “ร่างพร้อมลิงก์ใช้งานได้” ไม่ได้ เพราะขาดผลตรวจข้อบังคับ ลิงก์ยังไม่ถูกพิสูจน์ว่าใช้ได้หรือเสีย ให้พักการรับงานขอบเขตนี้จนตรวจตามสิทธิ์ที่ได้รับ หากเจ้าของตกลงรับเฉพาะข้อความ ต้องบันทึกขอบเขตใหม่และคงสถานะลิงก์ตามจริง
3. แก้จุดหนึ่งแล้วทำอีกจุดเปลี่ยน
ร่าง V1: “ประชุมเวลา 10:00 ห้อง A” คำขอแก้ล่าสุด: “เปลี่ยนเป็น 14:00 และคงห้อง A” ทั้งสองข้อเป็นเกณฑ์บังคับ ร่าง V2 ที่ส่งจริง: “ประชุมเวลา 14:00 ห้อง B” คำรายงานของ Agent: “แก้เวลาแล้ว” ควรปิดคำขอแก้และรับ V2 หรือไม่?
เปิดเฉลยข้อ 3: ตรวจส่วนที่ต้องคงไว้
เวลา: PASS · ห้อง: FAIL ยังปิดคำขอแก้ทั้งชุดไม่ได้ แม้เวลาเปลี่ยนถูกต้อง แต่ห้องเปลี่ยนจาก A เป็น B โดยขัดกับคำขอ ให้แก้ห้องกลับเป็น A แล้วตรวจทั้งเวลาและห้องในฉบับใหม่ การแก้สำเร็จหนึ่งจุดไม่ยืนยันว่าข้อบังคับอื่นยังผ่าน
คำถามที่พบบ่อยในการตรวจสอบงาน AI
ให้ AI ตัวเดิมตรวจงานตัวเองได้ไหม?
ใช้ช่วยหาข้อผิดพลาดเบื้องต้นได้ แต่ควรบอกว่าเป็นการตรวจตัวเอง สำหรับเกณฑ์สำคัญให้เทียบแหล่งจริง ใช้การคำนวณหรือทดสอบที่ตรวจซ้ำได้ และให้คนหรือผู้ตรวจแยกช่วยทบทวนตามความเสี่ยง การเปลี่ยนชื่อ Agent อย่างเดียวไม่พิสูจน์ความเป็นอิสระของวิธีตรวจ
Build ผ่านและ test ผ่านแล้ว รับงานได้เลยหรือไม่?
รับได้เฉพาะขอบเขตที่ผลเหล่านั้นครอบคลุม ต้องดูว่าเป็นฉบับที่ส่งจริง ชุดทดสอบวัดเกณฑ์สำคัญหรือไม่ และยังมีสิ่งที่ข้ามหรือไม่ ตัวอย่างหนึ่งค่าหรือภาพหน้าเว็บหนึ่งภาพไม่ครอบคลุมทุกอินพุต ทุกอุปกรณ์ และผลข้างเคียงทั้งหมด
ต้องตรวจทุกอย่างใหม่ทุกครั้งหรือไม่?
ไม่จำเป็นต้องเริ่มใหม่ทั้งหมด หากหลักฐานเดิมยังตรงฉบับและเงื่อนไข ให้ใช้ต่อโดยระบุที่มา ตรวจซ้ำส่วนที่เปลี่ยนและส่วนที่เสี่ยงได้รับผลกระทบ หากข้อมูล เครื่องมือ หรือสภาพแวดล้อมเปลี่ยน ต้องทบทวนว่าหลักฐานใดหมดความเกี่ยวข้องแล้ว
คะแนนความมั่นใจสูงหรือคำอ้างอิงจำนวนมากช่วยยืนยันได้แค่ไหน?
ใช้เป็นข้อมูลประกอบได้ แต่ต้องเปิดตรวจสิ่งที่คะแนนหรือคำอ้างนั้นหมายถึง แหล่งจำนวนมากอาจอ้างต้นทางเดียวกัน และแหล่งที่เกี่ยวข้องกับหัวข้ออาจไม่รองรับประโยคที่เขียน รับงานจากหลักฐานที่ตอบเกณฑ์ได้โดยตรง
เช็กลิสต์นี้รับประกันความถูกต้องหรือความปลอดภัยได้ไหม?
ไม่ได้ เช็กลิสต์ช่วยทำให้เหตุผลและช่องว่างเห็นชัด แต่ผู้ตรวจอาจพลาด และการทดสอบมีขอบเขต งานที่กระทบสุขภาพ กฎหมาย เงิน หรือความปลอดภัยควรให้ผู้เชี่ยวชาญที่เกี่ยวข้องทบทวนตามความเสี่ยงก่อนนำไปใช้ตัดสินใจ
เลือกบทเรียนต่อให้ตรงปัญหา
เลือกวิธีตรวจเพิ่มตามสิ่งส่งมอบ: ถ้าเป็นโปรแกรม ใช้คู่มือตรวจโค้ดที่ AI เขียนด้วย 8 Tests ถ้าเป็นข้อความหรือรายงาน ใช้วิธีตรวจสอบคำตอบ AI ทั้งข้อเท็จจริง ตัวเลข และอ้างอิง แล้วนำหลักฐานของแต่ละส่วนกลับมาประกอบใบตรวจรับงานทั้งชุด
- gh-aw: อ่านหลักฐานและรอบงาน เมื่อเห็นคำรายงานแต่ยังจับคู่กับชิ้นงานไม่ได้
- squirrelscan: แยกสิ่งที่ยังไม่ได้ตรวจ เมื่อรายงานเหมือนผ่านทั้งงาน
- OmniBox: ตรวจที่มาของเนื้อหา เมื่อข้อมูลหลัก คอมเมนต์ และภาพปะปนกัน
- Pathmode: ตรวจฉบับแก้กับคำขอ เมื่อ Agent บอกว่าแก้แล้วแต่บางส่วนยังผิด
- Build ผ่านแต่พฤติกรรมยังผิด เมื่อหลักฐานเชิงโค้ดยังไม่ตอบเป้าหมาย
- Reward Hacking และช่องโหว่ของตัวประเมิน เมื่อคะแนนดูดีแต่ผลจริงยังไม่ตรงงาน
- Loop Engineering และจุดหยุด เมื่อต้องจัดวงจรตรวจและบันทึกงานหลายรอบ
- 12 Agentic AI Projects และเกณฑ์ตรวจรับ เมื่อต้องการฝึกระบบหลักฐาน สิทธิ์ และการทดสอบให้เป็นงานวิศวกรรม
แหล่งอ้างอิงและขอบเขตของคู่มือ
- OpenAI: Evaluation best practices ใช้ประกอบหลักตั้งเกณฑ์ เลือกกรณีทดสอบ และทบทวนด้วยคน ไม่ได้แนะนำให้สมัครแพลตฟอร์มใด
- NIST AI RMF Core: Measure ใช้ประกอบเรื่องเอกสารผลตรวจ บริบทใช้งาน ข้อจำกัด และผู้ตรวจ
- GitHub: Application card for Copilot Agents ใช้ประกอบข้อจำกัดของ coding agent และการตรวจทดสอบก่อนใช้งาน
ตรวจแหล่งอ้างอิงวันที่ 13 ตุลาคม 2026 ตามเวลาไทย ขั้นตอน เช็กลิสต์ และตัวอย่างเป็นการสังเคราะห์เชิงบรรณาธิการของ Hybrid Mind ไม่ใช่ผลทดสอบโมเดลใหม่หรือใบรับรองความถูกต้อง บทเรียนที่ลิงก์บางหน้ามี Lab จำลองซึ่งใช้ฝึกอ่านหลักฐาน ไม่ใช้คะแนนจากแบบจำลองแทนผลทดสอบงานจริง
ใส่ความเห็น