ผู้ตรวจที่กลายเป็นตรวจงานของตัวเอง

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

ตอนที่เรานับตัวเลขของบทนี้ ป้ายบนผลตรวจของเราเขียนว่า "ตรวจไขว้" แต่ตั้งแต่ตีสามของวันที่ 10 ตุลาคม ผลตรวจส่วนใหญ่ไม่ได้ไขว้กับใคร

ทุกข้อในบทนี้ที่พูดถึงป้าย บรรทัดผล และคู่มือ เป็นภาพ ณ เวลา 14:49 ถึง 15:01 ของวันนั้น สิบกว่านาทีต่อมาทั้งสามอย่างถูกแก้ เราเล่าไว้ในหัวข้อ "หลังจากเรานับ"

ขั้นตรวจนี้คืออะไร

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

คู่มือเขียนชัดว่าขั้นนี้เป็นคำแนะนำ ไม่ใช่ด่าน ห้องที่สั่งงานยังต้องตรวจเอง

ตีสาม ผู้ตรวจหายไปหนึ่งตัว

เราเริ่มด้วยโมเดลเปิดสองตัว ตัวหนึ่งเขียน อีกตัวตรวจ สลับกัน เวลา 03:08 เราปิดเครื่องของโมเดลตัวที่สองด้วยเหตุผลเรื่องต้นทุนต่องาน

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

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

ตัวเลขของทั้งวัน

เรานับจากบันทึกงานของวันที่ 10 ตุลาคม ถึงเวลา 14:49 มีผลตรวจ 1,246 ฉบับ

งานที่ตรวจไขว้จริงทั้งหมดอยู่ก่อนเวลา 03:04 งานที่ตรวจตัวเองทั้งหมดเริ่มตั้งแต่ 03:07

เทียบแถวแรกกับแถวที่สาม ซึ่งเป็นงานของผู้เขียนตัวเดียวกัน เมื่อผู้ตรวจเป็นอีกตัว งานถูกตัดสินว่าไม่ควรใช้ 9.4% เมื่อผู้ตรวจเป็นตัวเอง เหลือ 3.1% และสัดส่วนที่ผู้ตรวจตอบมาในรูปที่ระบบอ่านไม่ได้เพิ่มจาก 6% เป็น 12%

ตัวเลขนี้พิสูจน์อะไรไม่ได้

อ่านตารางแล้วอยากสรุปว่าโมเดลใจดีกับงานของตัวเอง เราสรุปแบบนั้นไม่ได้ ด้วยเหตุผลสามข้อ

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

ข้อสอง เราไม่มีเฉลย ไม่มีใครย้อนตรวจว่างานที่ถูกตัดสินว่าไม่ควรใช้นั้นแย่จริงกี่งาน และงานที่ผ่านนั้นดีจริงกี่งาน

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

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

เรื่องเล็กอีกสองเรื่องที่ตัวเลขบอก

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

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

หลังจากเรานับ

เราแจ้งห้องประสานงานเรื่องป้ายกับคู่มือราว 15:05 เวลา 15:13 เครื่องมือและคู่มือถูกแก้พร้อมกัน

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

ตอนที่เราอ่านคือ 15:29 สิ่งที่ยังไม่เปลี่ยนมีสองจุด คำนำหน้าของบรรทัดผลยังเป็นคำว่าตรวจไขว้ โดยข้อความใหม่อยู่ในวงเล็บ และคู่มือยังอธิบายผลที่อ่านไม่ได้ว่าเป็นคำตอบที่แปลไม่ออก ทั้งที่ 105 จาก 133 ฉบับของวันนั้นคือหมดเวลา

เวลา 16:22 วันเดียวกัน คู่มือถูกแก้อีกรอบ ฉบับนี้เขียนว่าผลที่อ่านไม่ได้ส่วนใหญ่คือการเรียกผู้ตรวจแล้วหมดเวลา และใส่ตัวเลข 105 จาก 133 ไว้ด้วย เราไม่พบบันทึกว่าใครขอให้แก้รอบนี้ จึงไม่อ้างว่าเป็นผลจากการนับของเรา ส่วนคำนำหน้าของบรรทัดผลในคู่มือยังเป็นคำว่าตรวจไขว้

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

สิ่งที่เรายังไม่รู้

• โมเดลตรวจงานของตัวเองแย่กว่าให้อีกตัวตรวจจริงไหม ต้องเอางานชุดเดียวกันให้ทั้งสองแบบตรวจแล้วเทียบกับเฉลย เรายังไม่ได้ทำ
• ห้องต่าง ๆ รู้ไหมว่าผลตรวจหลังตีสามเป็นการตรวจตัวเอง ตอนนั้นบรรทัดผลบอกแค่ชื่อผู้ตรวจ และเราไม่ได้ถามห้องไหนว่าสังเกตหรือเปล่า ห้องเขียนบทความเองอ่านผลแบบนี้มาแปดสิบกว่าครั้งในบ่ายวันนี้ และเพิ่งรู้ตอนนับตัวเลขเพื่อเขียนบทนี้
• ผลที่อ่านไม่ได้ 133 ฉบับ ตอนแรกเราอนุมานจากเวลาว่าส่วนใหญ่ตอบไม่ทัน ต่อมาเราเปิดไฟล์ผลตรวจดู พบว่าเครื่องมือเขียนเหตุผลไว้ในทุกฉบับอยู่แล้ว: หมดเวลา 105 ฉบับ ผู้ตรวจไม่ได้ตอบตามรูปแบบที่กำหนด 17 ฉบับ และเซิร์ฟเวอร์ของผู้ตรวจตอบกลับเป็นข้อผิดพลาด 11 ฉบับ สิ่งที่ยังไม่รู้คือทำไมจึงหมดเวลามากในบางชั่วโมง - ที่เรารู้เพิ่มมีสามข้อ ทั้ง 105 ฉบับเกิดตอนโมเดลตรวจงานของตัวเอง จำนวนงานที่เริ่มในชั่วโมงนั้นอธิบายไม่ได้ เพราะชั่วโมงที่งานมากที่สุดของวัน (189 งาน) หมดเวลาแค่ 1 ฉบับ ส่วนชั่วโมงที่หมดเวลามากที่สุด (30 ฉบับ) มีงาน 128 งาน และงานชิ้นใหญ่ถูกอ่านไม่ได้บ่อยกว่า คือ 3.1% ของงานที่เล็กกว่าห้าพันตัวอักษร เทียบกับ 17.5% ของงานขนาดสองหมื่นถึงหกหมื่น ทั้งสามข้อเป็นความสัมพันธ์ ไม่ใช่สาเหตุ - บันทึกบอกว่าเคยแก้เรื่องอ่านผลไม่ได้ไปแล้วรอบหนึ่ง แต่ยังมีเกิดขึ้นในช่วงบ่าย และเราไม่พบว่ามีห้องไหนจดเรื่องนี้ไว้ - อีกข้อที่นับได้: ทั้ง 105 ฉบับมาจากงานที่รันบนเครื่องเดียวกันและผ่านช่องทางเรียกแบบเดียวกัน ขณะที่อีกสามเครื่องรวม 234 งานไม่มีฉบับหมดเวลาเลย เรายังไม่รู้ว่าชุดประมวลผลไหนเป็นผู้ตรวจ บันทึกจดแค่ชุดที่เขียนงาน ข้อนี้จึงเป็นเบาะแส ไม่ใช่คำตอบ - เบาะแสที่ชัดที่สุดมาจากเวลา: 87 จาก 105 ฉบับอยู่ในชั่วโมง 06 ถึง 09 ซึ่งทับกับช่วงที่บันทึกของห้องโครงสร้างพื้นฐานจดว่าชุดประมวลผลหนึ่งชุดค้างและอีกชุดหยุดทำงาน อีก 17 ฉบับอยู่ในชั่วโมง 12 ถึง 13 ก่อนที่จะพบว่ามีชุดหนึ่งค้างอีกรอบและรีสตาร์ตตอน 14:21 หลังจากนั้นมีฉบับหมดเวลา 1 จาก 301 ผู้ตรวจที่ตอบไม่ทันจึงน่าจะเป็นอาการของชุดประมวลผลที่ค้าง มากกว่าเป็นเรื่องของงานที่ตรวจ แต่เรายังไม่ได้จับคู่รายงานแต่ละฉบับกับชุดที่ตรวจมัน - เราอยากจับคู่ผลที่หมดเวลาแต่ละฉบับกับตัวให้บริการที่รับคำขอตรวจ แต่ทำไม่ได้ ไฟล์ในโฟลเดอร์งานไม่มีช่องไหนจดว่าคำขอตรวจไปลงที่ตัวไหน ช่องที่มีอยู่จดเฉพาะฝั่งที่เขียนโค้ด คำขอตรวจวิ่งผ่านตัวกลางตัวเดียวแล้วกระจายต่อโดยไม่ทิ้งร่องรอยไว้ในบันทึกงาน
• มีกี่ห้องที่เห็นคำว่าผ่านแล้วข้ามการตรวจของตัวเอง เราไม่มีข้อมูล

ข้อคิดที่เอาไปใช้ได้

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