วิธีอ่านเบนช์มาร์ก AI สำหรับเขียนโค้ด และหลีกเลี่ยงการเลือกผู้ชนะบนกระดาษ

สรุปสั้น ๆ: ตัวเลข “แก้โจทย์ได้ 76 เปอร์เซ็นต์” แทบไม่มีความหมายในตัวมันเอง สิ่งสำคัญคือชุดงานใดที่ทำให้ได้ตัวเลขนั้น นับโมเดลและ agent wrapper ใดรวมกัน งานนั้นใหม่หรือเก่า และมีค่าใช้จ่ายเท่าไร หากไม่มีเงื่อนไขเหล่านี้ เปอร์เซ็นต์ดังกล่าวก็เหมาะกับแบนเนอร์โฆษณา แต่ไม่เหมาะสำหรับเลือกเครื่องมือ

ต่อไป ฉันจะอธิบายอย่างเข้าใจง่ายว่าเบนช์มาร์กด้านการเขียนโค้ดหลักสองชุดวัดอะไร กับดักซ่อนอยู่ตรงไหนในตาราง และวิธีตรวจสอบการจัดอันดับใด ๆ ภายในหนึ่งนาทีก่อนจะเชื่อถือ ด้านล่างอธิบายนิยามเบนช์มาร์กในอดีต ไม่ได้แสดง snapshot ตารางอันดับสดที่จับคู่กัน การเทียบคะแนนหรือต้นทุนปัจจุบันต้องมีลิงก์ตาราง วันที่ และการตั้งค่าของตน

อ่านเพิ่มเติมเกี่ยวกับการทำงานกับโมเดลได้ในเอกสารประกอบของ Ailoot

เปอร์เซ็นต์ของเบนช์มาร์กแสดงอะไรจริง ๆ?#

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

ข้อดีคือการประเมินมีความเป็นกลาง การทดสอบเป็นสีเขียวหรือสีแดง ไม่มีใครให้คะแนนแบบ “กะเอาด้วยสายตา” ในแง่นี้ เบนช์มาร์กจึงตรงไปตรงมากว่าบทวิจารณ์หรือคำรับรองใด ๆ

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

HumanEval วัดอะไร และทำไมตอนนี้จึงใช้เลือกไม่ได้อีกต่อไป?#

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

ในเวลานั้น HumanEval ช่วยแยกความแตกต่างได้ดี ในบทความของผู้สร้างเอง มีตัวเลขนี้ระบุไว้: Codex รุ่นแรกแก้โจทย์ได้ 28.8 เปอร์เซ็นต์ในการลองครั้งเดียว ขณะที่ GPT-3 ทั่วไปแก้ไม่ได้เลย

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

ข้อบกพร่องประการที่สองร้ายแรงกว่า งานมีขนาดเล็กมาก: เขียนฟังก์ชันหนึ่งฟังก์ชันจากคำอธิบาย แต่งานจริงของคุณต่างออกไป—เป็นโปรเจกต์ขนาดใหญ่ที่มีประวัติ ซึ่งคุณต้องทำความเข้าใจโค้ดของคนอื่น หา defect และหลีกเลี่ยงการทำให้โค้ดส่วนข้างเคียงเสียหาย ระหว่าง “เขียนฟังก์ชันขึ้นมาใหม่” กับ “แก้บั๊กในโปรเจกต์ที่ใช้งานจริง” มีช่องว่างมหาศาล ดังนั้นคะแนน HumanEval สูงในวันนี้จึงไม่ใช่เหตุผลให้เลือกเครื่องมืออีกต่อไป แต่เป็นเหมือนเครื่องหมายว่า “พื้นฐานผ่านแล้ว”

SWE-bench วัดอะไร และใกล้เคียงงานจริงมากกว่าอย่างไร?#

SWE-bench แตกต่างโดยพื้นฐาน จึงน่าสนใจกว่า สร้างขึ้นจาก issue จริงและ pull request ในโปรเจกต์ GitHub ยอดนิยม ตามข้อมูลจากผู้สร้าง มีงาน 2,294 งานจาก repository Python ขนาดใหญ่ 12 แห่ง และเผยแพร่ในเดือนตุลาคม 2023

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

ตัวเลขเริ่มต้นแสดงให้เห็นว่างานนี้ยากกว่าโจทย์ตัวอย่างเล็ก ๆ มากเพียงใด แนวทางพื้นฐานรุ่นแรกได้คะแนนเพียง 1.96 เปอร์เซ็นต์บน SWE-bench และเอเจนต์รุ่นแรกได้ 12.47 เปอร์เซ็นต์ กล่าวคือ แม้แต่การเข้าใกล้งานเขียนโค้ดจริงก็ยังยาก และเปอร์เซ็นต์เพิ่มขึ้นในภายหลัง แต่จุดเริ่มต้นอยู่ใกล้ศูนย์

ดังนั้นเมื่อคุณเห็นตัวเลขสูง ๆ ในการจัดอันดับ agent สำหรับเขียนโค้ดด้วย AI ในปัจจุบัน ตัวเลขเหล่านั้นมักมาจาก SWE-bench หรือชุดย่อยที่มี 500 งานซึ่งผ่านการตรวจสอบโดยมนุษย์ เรียกว่า SWE-bench Verified นี่เป็นเบนช์มาร์กที่สมเหตุสมผล แต่ก็ยังมีเงื่อนไขที่หากไม่คำนึงถึง เปอร์เซ็นต์จะทำให้เข้าใจผิด และฉันจะพูดถึงเรื่องนี้ต่อไป

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

ทำไมโมเดลเดียวกันจึงแสดงเปอร์เซ็นต์ต่างกัน?#

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

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

การเทียบที่ทำซ้ำได้ควรเก็บการตั้งค่าครบ ใช้ตารางนี้เป็นเทมเพลตรายงาน ไม่ใช่ผลจัดอันดับที่วัดแล้ว:

จึงเห็นว่าอะไรเปลี่ยนและแยกผลของ reasoning จริงหรือไม่ ตัวอย่างตัวเลขเดิมที่ไม่มีลิงก์ไม่ถือเป็นผลวัด

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

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

ทำไมงานจึง “หมดอายุ” และ training data leakage คืออะไร?#

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

กลไกนั้นเรียบง่าย หากงานและเฉลยที่ถูกต้องเข้าไปอยู่ในข้อมูลฝึก โมเดลอาจจดจำมันไว้ได้ ระหว่างการประเมิน แทนที่จะกำลังแก้โจทย์ ก็อาจเป็นการดึงคำตอบที่คุ้นเคยจากความจำ ดูเหมือนเป็นการแก้โจทย์ แต่เป็นเพียงความจำ เรื่องนี้เรียกว่า training leakage หรือ data contamination

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

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

ทำไมความแตกต่างไม่กี่จุดเปอร์เซ็นต์จึงมักไม่มีความหมาย?#

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

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

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

อ่านตารางเบนช์มาร์กใด ๆ ภายในหนึ่งนาทีได้อย่างไร?#

ขอสรุปทั้งหมดเป็นรายการตรวจสอบสั้น ๆ เปิดตารางจัดอันดับใดก็ได้ แล้วตรวจสอบเจ็ดข้อนี้ตามลำดับ

1. ใช้ชุดงานใด? HumanEval อ่อนในปัจจุบัน ส่วน SWE-bench ใกล้เคียงงานจริงกว่า หากไม่มีการระบุชื่อชุดงาน ก็ไม่จำเป็นต้องอ่านต่อ
2. งานใหม่หรือเก่า? ชุดงานใหม่หรือปิดบางส่วนเชื่อถือได้มากกว่าชุดเก่าสาธารณะที่โมเดลอาจเรียนรู้มาแล้ว
3. วัดโมเดลใด? ชื่อและเวอร์ชันที่แน่นอน ไม่ใช่คำว่า “AI” ที่คลุมเครือหรือชื่อกลุ่มโมเดล
4. ใช้ agent wrapper ใด? เปอร์เซ็นต์เป็นของชุด “โมเดลบวก wrapper” หากไม่ระบุ wrapper คุณก็ไม่รู้ว่าวัดอะไร
5. ระดับการให้เหตุผลใด? โมเดลหนึ่งตัวที่ใช้ระดับต่างกันให้เปอร์เซ็นต์และค่าใช้จ่ายต่างกัน
6. งานหนึ่งชิ้นราคาเท่าไร? ผลลัพธ์ใกล้เคียงกันอาจมีราคาต่างกันหลายเท่า อ่านเปอร์เซ็นต์ควบคู่กับค่าใช้จ่าย
7. ความแปรปรวนเป็นอย่างไร? ความแตกต่างหนึ่งหรือสองจุดระหว่างแถวมักเป็นเพียงสัญญาณรบกวน

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

สุดท้ายแล้วควรดูอะไร?#

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

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

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

สำหรับการทำงานต่อไป—Ailoot.