Amazon Mechanical Turk ปิดบริการแล้ว งานที่ค้างต้องย้ายระบบ

Amazon Mechanical Turk (MTurk) ปิดบริการถาวรเมื่อ 30 กันยายน 2026 และหยุดรับการส่งงาน HIT แล้ว ตามFAQ การปิดบริการของ MTurk ผู้ว่าจ้างยังอนุมัติหรือปฏิเสธงานที่ส่งแล้ว และจ่ายโบนัสได้ถึง 30 ตุลาคม 2026 ส่วนประวัติธุรกรรมเข้าถึงได้ถึง 28 มกราคม 2027 ทีมที่ใช้คนตรวจข้อมูลผ่านบริการนี้จึงต้องจัดการคำตอบเก่าตามกำหนด พร้อมเปลี่ยนเส้นทางงานใหม่ออกจาก MTurk

ประกาศสถานะบริการของ AWS ลงวันที่ 29 กันยายน 2026 จัด MTurk เป็นบริการที่สิ้นสุดการสนับสนุนและไม่พร้อมใช้งาน ณ วันที่ประกาศ ขณะที่ FAQ ของ MTurk ระบุวันปิดถาวรเป็น 30 กันยายน 2026 สำหรับผู้ว่าจ้าง ผลในขณะนี้เหมือนกันในส่วนงานใหม่: ส่ง HIT เข้าระบบเดิมต่อไม่ได้ แต่คำตอบที่ส่งไว้ก่อนปิดยังมีช่วงให้ตรวจรับและจัดการค่าตอบแทน

งานที่ส่งแล้วกับงานที่หมดอายุต้องอยู่คนละคิว

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

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

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

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

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

จุดเชื่อมต่อที่อาจหยุดเงียบหลัง MTurk ปิด

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

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

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

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

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

อีกจุดที่ควรค้นหาคืองานซึ่งไม่ได้เรียก MTurk โดยตรง แต่เลือก MTurk เป็นกลุ่มผู้ทำงานสำหรับการติดป้ายกำกับหรือการตรวจทานโดยมนุษย์ FAQ การปิดบริการระบุว่าตัวเลือกผู้ทำงาน MTurk ใช้สร้างงานใหม่ใน SageMaker Ground Truth และ Amazon Augmented AI ไม่ได้แล้ว ทีมที่ใช้บริการเหล่านี้จึงต้องดูการตั้งค่ากลุ่มผู้ทำงานของแต่ละงาน ไม่ใช่ค้นหาเฉพาะชื่อ MTurk ในโค้ดที่สร้าง HIT

เก็บผลลัพธ์พร้อมที่มา ก่อนเปลี่ยนทางเดินข้อมูล

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

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

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

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

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

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

โครงการวิจัยต้องจัดการผู้เข้าร่วมที่ยังอยู่กลางงาน

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

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

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

ลำดับย้ายงานควรอิงความเสี่ยงของผลที่ขาด

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

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

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

1. หยุดงานตามเวลาและคำสั่งสร้าง HIT ที่ยังทำงานอยู่ แล้วระบุระบบต้นทางของแต่ละคำสั่ง การหยุดเฉพาะปุ่มบนหน้าเว็บไม่ครอบคลุมงานอัตโนมัติที่อาจยังพยายามส่งโจทย์ ให้เปลี่ยนสัญญาณความล้มเหลวเป็นรายการที่มีเจ้าของรับผิดชอบ
2. ส่งออกคำตอบ สถานะการตรวจรับ และข้อมูลธุรกรรมที่จำเป็น จับคู่รหัสจาก MTurk กับรหัสภายใน แล้วตรวจจำนวนรายการที่เชื่อมได้กับรายการที่เชื่อมไม่ได้ อย่าเติมคำตอบให้ HIT ที่หมดอายุโดยอาศัยเพียงชื่อโจทย์คล้ายกัน
3. ปิดคิวคำตอบที่ส่งแล้วตามเกณฑ์เดิม แยกการตรวจคุณภาพออกจากการสร้างงานทดแทน และบันทึกผู้อนุมัติหรือเหตุผลปฏิเสธไว้กับรายการนั้น งานเก่ากับงานใหม่อาจอยู่คนละระบบ แต่ต้องมีเจ้าของการตัดสินทั้งคู่
4. ระบุจุดรับส่งข้อมูลทุกจุด ตั้งแต่ API งานตามเวลา คิวแจ้งเหตุการณ์ webhook ภายใน ไฟล์ส่งออก ไปจนถึงตารางปลายทาง จากนั้นกำหนดว่าจะปิด เปลี่ยน หรือคงแต่ละจุดไว้ชั่วคราวตามงานที่ยังค้าง
5. กำหนดรูปแบบโจทย์ทดแทนจากข้อมูลจริง รวมถึงวิธีสุ่มตัวอย่าง เกณฑ์คุณภาพ วิธีแก้คำตอบที่ขัดกัน และหลักฐานการยินยอมถ้ามีผู้เข้าร่วมวิจัย อย่าสมมติว่าคุณสมบัติของผู้ทำงานหรือสิทธิใช้ข้อมูลย้ายตามไปได้โดยอัตโนมัติ
6. ทดลองงานขนาดเล็กที่มีคำตอบอ้างอิงและผู้ตรวจรับก่อนเปลี่ยนคิวทั้งหมด ตรวจทั้งคำตอบที่ได้ เวลาที่ผลกลับถึงระบบปลายทาง และวิธีบันทึกการอนุมัติ หากผลไม่ผ่านเกณฑ์ ให้แก้โจทย์หรือทางเดินข้อมูลก่อนเพิ่มปริมาณงาน
7. เปิดทางเดินใหม่โดยติดป้ายที่มาของผลลัพธ์ทุกชุด เฝ้าดูรายการที่ไม่กลับมา รายการซ้ำ และคำตอบที่รอตรวจนานเกินกติกา พร้อมรักษาทางเข้าข้อมูลเก่าจนกระทบยอดงานค้างและค่าตอบแทนเสร็จ

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