แยกสัญญาณออกจากสัญญาณรบกวนในการประเมินการเขียนโค้ด
(openai.com)- การประเมินความสามารถด้านการเขียนโค้ดของโมเดล AI เชื่อมโยงโดยตรงกับการตัดสินใจด้านการนำไปใช้งานและความปลอดภัย แต่การตรวจสอบของ OpenAI ประเมินว่างานใน SWE-Bench Pro ราว 30% อยู่ในสภาพที่เสียหาย
- SWE-Bench Pro ตั้งเป้าไปที่ขอบเขตงานที่ยาวขึ้นและโจทย์ที่สมจริงกว่าเดิม แต่ทำให้ยากที่จะเชื่อผลผ่านด่านของ 731 งานสาธารณะ ที่เพิ่มจาก 23.3% เป็น 80.3% ภายใน 8 เดือนตามตัวเลขเดิม
- ข้อบกพร่องแบ่งได้เป็นการทดสอบที่เข้มงวดเกินไป พรอมป์ต์ที่ระบุไม่ครบ การทดสอบที่ครอบคลุมน้อย และพรอมป์ต์ที่ชวนให้เข้าใจผิด ซึ่งอาจทำให้คำตอบที่ถูกต้องสอบตก หรือการแก้ไขที่ยังไม่สมบูรณ์กลับผ่านได้
- การตรวจสอบได้ทำเครื่องหมาย 286 งานที่อาจมีปัญหา โดยอาศัยความพยายามของโมเดล เมทาดาทาของงาน และการติดตามความล้มเหลว ก่อนส่งต่อให้เอเจนต์สืบสวนและวิศวกรผู้ชำนาญ 5 คนตรวจทานอย่างอิสระ
- OpenAI ถอนคำแนะนำเดิมในการยอมรับ SWE-Bench Pro แล้ว และชี้ว่าเกณฑ์ประเมินควรให้ สัญญาณที่มีความหมาย ซึ่งไม่บิดเบือนการตัดสินความสามารถและความปลอดภัยของโมเดล
ปัญหาที่พบจากการตรวจสอบ SWE-Bench Pro
- OpenAI ตรวจสอบ SWE-Bench Pro และประเมินว่าประมาณ 30% ของงานทั้งหมดอยู่ในสภาพที่เสียหาย
- การวัดความสามารถของโมเดลให้แม่นยำยังส่งผลต่อการตัดสินใจด้านการนำไปใช้งานและความปลอดภัยภายใต้ Preparedness Framework
- การประเมินที่มีข้อบกพร่องอาจทำให้เข้าใจความสามารถของโมเดลคลาดเคลื่อนจากความจริง และสั่นคลอนทั้ง การตัดสินด้านความปลอดภัย และลำดับความสำคัญของงานวิจัย
เป้าหมายของ SWE-Bench Pro และการเปลี่ยนแปลงของอัตราการผ่าน
- ก่อนหน้านี้ OpenAI พบทั้งปัญหาด้านการออกแบบและการปนเปื้อนใน SWE-bench Verified ที่ใช้อย่างแพร่หลาย และเห็นว่าการประเมินนี้ไม่สามารถให้สัญญาณที่มีความหมายเกี่ยวกับความสามารถด้านการพัฒนาซอฟต์แวร์ได้อีกต่อไป
- ในเวลานั้น OpenAI จึงแนะนำให้ชุมชนเปลี่ยนมาใช้ SWE-Bench Pro
- SWE-Bench Pro ถูกออกแบบมาเพื่อปรับปรุงจาก SWE-bench Verified โดยติดตามความสามารถการเขียนโค้ดแบบเอเจนต์ผ่านขอบเขตงานที่ยาวขึ้นและโจทย์ที่สมจริงกว่าเดิม
- งานถูกดึงออกมาแบบเป็นโปรแกรมจากประวัติการเปลี่ยนแปลงฟังก์ชันของทั้งรีโพสาธารณะและไม่สาธารณะ
- โมเดลต้องสร้างโซลูชันที่ผ่านการทดสอบฟีเจอร์ใหม่โดยไม่ทำให้ฟีเจอร์เดิมพัง
- ในชุดงานสาธารณะ 731 งาน อัตราการผ่านของ frontier model เพิ่มจาก 23.3% เป็น 80.3% ภายใน 8 เดือน
ไปป์ไลน์ประกันคุณภาพ
- OpenAI สร้าง ไปป์ไลน์ประกันคุณภาพ เพื่อตรวจสอบว่าแต่ละ data point สะท้อนความสามารถจริงของโมเดลหรือไม่
- ตัวกรองอัตโนมัติในขั้นต้นจะตรวจดูคำสั่งที่ให้กับโมเดล ความพยายามแก้โจทย์ของโมเดล และชุดทดสอบสำหรับให้คะแนน เพื่อทำเครื่องหมายตัวอย่างที่เสียหายหรืออาจมีปัญหา
- กระบวนการนี้ทำให้พบ 286 งานที่อาจมีปัญหา
- ชุดย่อยที่ถูกทำเครื่องหมายถูกตรวจทานเชิงลึกต่อผ่านสองเส้นทาง
- การตรวจทานโดยเอเจนต์ภายใต้การกำกับของมนุษย์: เอเจนต์สืบสวนทำการตรวจสอบรายละเอียด แล้วผ่านการตัดสินขั้นสุดท้ายโดยมนุษย์
- แคมเปญการใส่คำอธิบายประกอบโดยมนุษย์: นักพัฒนาซอฟต์แวร์ผู้ชำนาญตรวจทานงานโดยตรง
วิธีการตรวจทานของเอเจนต์และมนุษย์
- ปัญหาที่ถูกทำเครื่องหมายถูกตรวจสอบโดย เอเจนต์สืบสวนที่อิง Codex
- เอเจนต์เข้าถึงรีโพซิทอรีของงานและสภาพแวดล้อมการรันได้
- สามารถรันทดสอบ ตรวจไฟล์ในรีโพ และสืบสวนความพยายามของโมเดลรวมถึงรูปแบบความล้มเหลวที่พบบ่อยได้
- ใช้เพื่อแยกแยะความกำกวมที่สมเหตุสมผลซึ่งแก้ได้จากโค้ดรอบข้างและธรรมเนียมของรีโพ ออกจากการระบุข้อกำหนดไม่ครบจริง
- หลังการตรวจสอบเชิงลึกแบบอิสระหลายรอบ นักวิจัยจะทบทวนสรุปแล้วกำหนดคำตัดสินสุดท้ายและป้ายกำกับปัญหา
- ในแคมเปญการใส่คำอธิบายประกอบโดยมนุษย์ที่ดำเนินไปคู่ขนาน วิศวกรซอฟต์แวร์ผู้ชำนาญได้รับการฝึกเกี่ยวกับเป้าหมายของเบนช์มาร์ก การจัดหมวดปัญหา และกรณีขอบเขต ก่อนตรวจทานงาน
- แต่ละงานถูกตรวจโดย วิศวกร 5 คน
- ผู้ตรวจจะตัดสินอย่างอิสระก่อน โดยอิงจากคำอธิบายปัญหาที่มองเห็นได้ ชุดทดสอบ และ gold patch ซึ่งเป็นโซลูชันอ้างอิงที่ถูกต้อง
- จากนั้นจึงใช้การวิเคราะห์ของไปป์ไลน์หรือบันทึกต่าง ๆ เป็นบริบทเสริม
- มีการกำหนดป้ายกำกับและระดับความรุนแรงตามหลักฐานที่เป็นรูปธรรม และกรณีที่เห็นไม่ตรงกันหรือมีความมั่นใจต่ำจะถูกยกระดับไปตรวจทานเพิ่มเติม
ความล้มเหลว 4 ประเภท
- ปัญหาที่พบจากการตรวจสอบหลัก ๆ แบ่งได้เป็น 4 หมวด
- การทดสอบที่เข้มงวดเกินไป: บังคับรายละเอียดการติดตั้งใช้งานเฉพาะที่ไม่ได้อยู่ในพรอมป์ต์ ทำให้คำตอบที่ถูกต้องในเชิงฟังก์ชันถูกตัดตก
- พรอมป์ต์ที่ระบุไม่ครบ: ละทิ้งข้อกำหนดที่ hidden tests ต้องการ แต่ยากจะอนุมานได้อย่างสมเหตุสมผล
- การทดสอบที่ครอบคลุมน้อย: ตรวจสอบฟังก์ชันที่ร้องขอได้ไม่เพียงพอ ทำให้การแก้ไขที่ยังไม่สมบูรณ์ก็อาจผ่านได้
- พรอมป์ต์ที่ชวนให้เข้าใจผิด: ชี้นำโมเดลไปสู่พฤติกรรมที่ไม่ถูกต้อง หรือขัดแย้งกับข้อกำหนดของการทดสอบ
- ในบางงาน พรอมป์ต์กำหนดให้ใช้การติดตั้งใช้งานแบบหนึ่ง แต่ hidden test cases กลับคาดหวังพฤติกรรมอีกแบบหนึ่ง
ความต่างระหว่างการตรวจทานโดยมนุษย์กับเอเจนต์
- ผู้ตรวจทานที่เป็นมนุษย์มีแนวโน้มทำเครื่องหมายงานว่าเสียหายมากกว่าเอเจนต์สืบสวน
- แม้จะมีความต่างในการตัดสินหมวดหมู่ระหว่างสองเส้นทางการตรวจ แต่ในบรรดางานที่ถูกทำเครื่องหมาย ไม่มีกรณีใดที่ป้ายกำกับจากมนุษย์ระบุว่า “ไม่เสียหาย” เป็นป้ายที่มากที่สุด
- หมวดหมู่ที่ไปป์ไลน์เอเจนต์ทำเครื่องหมายไว้กับคำตัดสินของผู้ตรวจมนุษย์ ทับซ้อนกันใน 74% ของกรณี
- ผู้ตรวจมนุษย์ยังเลือกหลายป้ายกำกับให้กับงานเดียวบ่อยกว่า
- นี่เป็นสัญญาณว่างานหนึ่งอาจเสียหายได้หลายแบบ หรือไม่อาจจัดเข้าเพียงหมวดเดียวได้อย่างเรียบร้อย
- ไปป์ไลน์ที่ใช้ทั้งเอเจนต์และผู้ตรวจสามารถจับรูปแบบความล้มเหลวที่หลากหลายซึ่งมนุษย์พบได้ แต่ยังนับปัญหาเพิ่มเติมหรือปัญหาซ้ำอย่างระมัดระวังและมีจำนวนน้อยกว่า
- ความต่างที่ใหญ่ที่สุดปรากฏในกรณี การทดสอบที่ครอบคลุมน้อย
- มนุษย์เลือกหมวดนี้เป็นปัญหาที่พบบ่อยที่สุดใน 9.4% ของเบนช์มาร์ก
- ส่วนไปป์ไลน์เอเจนต์ทำเครื่องหมายไว้ที่ 4.1%
ทำไมการสร้างเบนช์มาร์กจึงยาก
- กรณีของ SWE-Bench Pro และ SWE-bench Verified แสดงให้เห็นว่าเบนช์มาร์กต้องได้รับการตรวจสอบอย่างเข้มงวด
- issue และ pull request ในรีโพโอเพนซอร์สเดิมทีถูกสร้างขึ้นเพื่อ ความร่วมมือของมนุษย์ ไม่ใช่เพื่อการประเมินโมเดล
- ในสภาพแวดล้อมที่มีการพูดคุยโต้ตอบกันยาวนานระหว่างผู้ดูแลและผู้มีส่วนร่วม คำอธิบายปัญหา โค้ดที่ถูก merge และ unit tests ไม่ได้ประกอบกันเป็นงานที่สะอาดและเป็นอิสระสำหรับการประเมินโมเดลเสมอไป
- ชุดทดสอบที่รวมอยู่ใน pull request อาจถูกเขียนขึ้นเพื่อยืนยันการเปลี่ยนแปลงเฉพาะอย่าง จึงอาจบังคับ การติดตั้งใช้งานแบบเฉพาะ แทนที่จะเป็นเกณฑ์ตัดสินที่เป็นอิสระจากวิธีแก้
ทิศทางการประเมินในอนาคต
- เมื่อความสามารถของโมเดลดีขึ้น ข้อบกพร่องของการประเมินก็ตรวจพบได้ง่ายขึ้นกว่าสมัยก่อน
- โมเดลที่พัฒนาขึ้นสามารถตรวจสอบพรอมป์ต์ ชุดทดสอบ patch ร่องรอยการรัน และกรณีขอบเขตได้ลึกและสม่ำเสมอยิ่งขึ้น จึงเปิดเผยปัญหาในเบนช์มาร์กที่ก่อนหน้านี้ค้นหาในวงกว้างได้ยากหรือมีต้นทุนสูง
- OpenAI คาดหวังให้ชุมชนการประเมินในวงกว้างพัฒนาเบนช์มาร์กชุดใหม่ที่สร้างขึ้นโดยนักพัฒนาซอฟต์แวร์ผู้ชำนาญโดยมีเป้าหมายเพื่อทดสอบความสามารถของโมเดลโดยตรง
- วิธีนี้จะช่วยคงทั้งระดับความยากสูงและความสมจริงที่ต้องการวัดไว้ พร้อมเปิดทางให้มี การกำกับดูแลโดยมนุษย์ ที่ดีขึ้นตลอดทั้งกระบวนการ
- OpenAI ถอนคำแนะนำก่อนหน้านี้เกี่ยวกับการยอมรับ SWE-Bench Pro เนื่องจากปัญหาที่เปิดเผยจากการวิเคราะห์ครั้งนี้
- การประเมินควรบิดเบือนได้ยาก เชื่อถือได้ง่าย และให้ สัญญาณที่มีความหมาย ซึ่งสะท้อนความสามารถหรือสถานะการจัดแนวของโมเดลได้จริง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ควรวัดทั้งประสิทธิภาพและความฉลาดไปพร้อมกัน โมเดลขนาดเล็กอาจใช้กลยุทธ์อย่างทดสอบผลลัพธ์ด้วยการใช้คอมพิวเตอร์ หรือใช้เวลากับปัญหานานขึ้นและตรวจสอบเอาต์พุต ส่วนโมเดลขนาดใหญ่อาจมีงบสำหรับการทดสอบตัวเองไม่พอ จึงน่าจะเกิดความแตกต่างด้านยุทธวิธีที่น่าสนใจ
https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
Toby Ord ลองทำเท่าที่ทำได้ด้วยข้อมูลสาธารณะแล้ว แต่ผลลัพธ์ดูไม่ค่อยดีนัก
https://www.tobyord.com/writing/hourly-costs-for-ai-agents
นอกจากนี้ยังมีการโกงในระดับ execution harness, การทำ reward hacking ของโมเดล ฯลฯ สิ่งที่ยังคาใจแม้ผ่านไปหลายเดือนคือ submission อย่างเป็นทางการของ gpt-5.5 โดยเฉพาะงานนี้: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
ข้อจำกัดเวลาของงานตาม https://github.com/harbor-framework/terminal-bench-2/blob/ma... คือ verifier 1200 วินาที, agent 1200 วินาที, environment build 600 วินาที ดังนั้นไม่มี agent ใดควรเกิน 3000 วินาที แต่จาก 5 ครั้งในลิงก์ด้านบน มี 2 ครั้งที่เกิน 3000 วินาทีไปมาก ใช้เวลา 75 นาทีและ 80 นาทีตามลำดับ แม้จะล้มเหลว แต่การรันนานขนาดนั้นก็น่าสงสัย เป็นกรณีที่ กฎของ Goodhart ทำงาน
การทำเบนช์มาร์กกับคนก็ไม่ได้ผลดีนัก ความสามารถในการเขียนโค้ดวัดได้ค่อนข้างถูกต้องก็ต่อเมื่อได้โต้ตอบกันโดยตรง หากโมเดลโดยพื้นฐานเป็นเครื่องจำลองมนุษย์ ยิ่งการจำลองแม่นยำขึ้น ก็ยิ่งแปลกที่จะคาดหวังว่าเบนช์มาร์กจะยังมีประโยชน์ต่อไป สุดท้ายก็เป็นแค่การขยายความ “กฎของ Goodhart” ที่กล่าวไว้ข้างต้น และมันทำงานเหมือนเป็นกฎจริง ๆ
ถ้าอย่างนั้นตรรกะคือโมเดลระดับแนวหน้าไม่ใช่แม้แต่วิศวกรจูเนียร์ แต่เป็นอินเทิร์นเดือนแรกที่ไม่มีความสามารถจะไปไกลกว่าระดับนั้นหรือ?
สิ่งที่น่าสนใจคือ LLM ทำคะแนนเกิน 70% ในเบนช์มาร์กแบบนี้ได้อย่างไร หรือทำคำถามบางส่วนที่จัดทำได้แย่มากให้ถูกได้อย่างไร มันเรียนรู้สไตล์ของผู้เขียนเทสต์โดยปริยายหรือเปล่า? คำตอบรั่วเข้าไปในข้อมูลฝึกหรือเปล่า?
ถึงอย่างนั้น แม้แต่ Fable ก็ยังหยุดอยู่ราว 72% บนชุดซ่อนที่ OpenAI ไม่ได้รันการวิเคราะห์นี้ ถือว่าน่าโล่งใจ ดูเหมือนไม่ได้ฝึกจากตัวเบนช์มาร์กโดยตรง ยกเว้นในทางอ้อมมาก ๆ
โมเดลเปิดขนาดเล็กไม่มีทางเรียนรู้นิสัยประหลาดแบบนี้ได้เลย ดังนั้นวิธีตัดสินโมเดลอย่างเป็นธรรมจึงสำคัญมาก เพิ่มเติมคือ OpenAI กำลังทำให้น้ำขุ่นเล็กน้อย เพราะปัญหาที่พังในลักษณะไม่เป็นธรรมต่อ agent มีเพียงประมาณ 20% และอีก 4~10% พังไปในทางที่เป็นประโยชน์ ดังนั้นเพดานของเบนช์มาร์กน่าจะใกล้ 80~85%
ดังนั้นพรอมป์งานที่แคบมากจะตรวจสอบได้ง่าย แต่ก็อาจง่ายเกินไปในฐานะโจทย์ท้าทาย ในทางกลับกัน พรอมป์งานที่สมจริงกว่าจะตรวจสอบได้ยากกว่ามาก และการสร้าง verifier ที่ทนทานพร้อมรันได้อย่างประหยัดก็ยากขึ้นด้วย
แน่นอนว่านั่นเท่ากับทดสอบสิ่งที่ต่างจากสิ่งที่เบนช์มาร์กอ้าง แต่บางครั้งมันก็บังเอิญทดสอบสิ่งที่ใกล้เคียงความจริงมากกว่าเบนช์มาร์กที่สะอาดเรียบร้อย จึงมีความหมายในแบบของมัน
แต่เป็นเรื่องนี้เฉพาะเมื่อ agent เห็นเทสต์ที่ล้มเหลวแล้วทำซ้ำได้เท่านั้น ถ้าไม่ใช่ก็เป็นปัญหาเฉย ๆ และกรณีที่ฝังรายละเอียดการใช้งานของวิธีแก้เฉพาะลงในเทสต์ แล้วเรียกร้องโครงสร้างภายในตามอำเภอใจนั้นยิ่งแย่กว่า ในโลกจริงเราไม่เจอสถานการณ์แบบนั้น
ในแง่หนึ่ง การที่ลงมือทำงานนั้นจริง ๆ ก็น่าชื่นชม แต่อีกแง่หนึ่ง มันก็ตรงตามคำว่า garbage in, garbage out ผู้เขียนต้นฉบับไม่ได้ตรวจสอบจริง ๆ ก็น่าอายอยู่บ้าง และทุกคนที่อยู่ downstream ก็ไม่ได้ตรวจสอบด้วยก็น่าอายเช่นกัน อีกอย่าง จากบทความจะเห็นว่า LLM ก็หาเจอว่ามีปัญหา แต่มีแนวโน้มจะประเมินปัญหาที่วิศวกรซอฟต์แวร์มืออาชีพพบต่ำเกินไป
Benchmark ทั้งหลายพอเปิดดูข้างในแล้ว โดยมากค่อนข้างแย่ทีเดียว
ขอเล่าพื้นหลังก่อน ผมกำลังปรับปรุง supervisor agent แบบวนซ้ำ เพื่อแทนที่ขั้นตอนจุกจิกหลายอย่างที่ต้องทำเวลาใช้ Codex/Claude Code และเมื่อไม่นานนี้ได้นำ agent ตัวนี้ไปรันกับ Terminal Bench 2.1
ตอนแรกก็ดีใจ เพราะ supervisor แบบอิงสเปกทำได้ดีกว่า Codex พื้นฐานในหลายงาน แต่พอดูลงลึกขึ้น งานเองกลับมีปัญหาเยอะมาก
ประเด็นหลักคือคำสั่งมักคลุมเครือ แต่ test case กลับเฉพาะเจาะจงเกินไป ตัวอย่างเช่น
configure-git-webserverมีถ้อยคำอย่าง “so that I can run” ทำให้ขอบเขตไม่ชัดว่า agent ควรจัดเตรียมอะไรและควรลบอะไรออก agent ที่คิดมากเกินไปจะตั้งค่าเซิร์ฟเวอร์แล้วมองว่า หากผู้ใช้รันคำสั่งเดียวกันจะเกิด conflict จึงลบไฟล์ตรง ๆ ที่ตัว verifier ตรวจสอบทิ้งไปmake-mips-interpreterมีวลี “I will check that you booted doom correctly” ทำให้ supervisor ตีความว่า ผู้ใช้ไม่ได้จะตรวจว่า Doom บูตได้เองอย่างอิสระ แต่จะตรวจผลลัพธ์จากการบูตที่ agent ทำไว้ จึงเหลือไฟล์/tmp/frame.bmpที่สร้างขึ้นไว้ verifier จะจบการทำงานหากมี/tmp/frame.bmpเดิมอยู่แล้ว จึงเริ่ม Doom ไม่ได้ และไม่ได้ตรวจด้วยว่ามีการสร้างไฟล์ใหม่ระหว่างกระบวนการบูตหรือไม่[0]ใน
mcmc-sampling-stansupervisor agent มักไปถึงค่าที่ถูกต้อง แต่แทนที่จะพิมพ์เลขฐานสิบธรรมดา กลับพิมพ์ผลลัพธ์ตัวเลขเฉพาะโดเมนเป็น scientific notation verifier parse ผลลัพธ์ผิดจนล้มเหลว[1]ความไม่ตรงกันแบบนี้เป็นเพียงบางส่วนเท่านั้น ดังนั้นผมจึงมองว่า Terminal Bench 2.1 อิ่มตัวแล้ว และผลของ GPT-5.6 กับ Mythos ที่ 88.8% และ 88% ตามลำดับ แทบแตะเพดานสูงสุดที่คาดหวังได้แล้ว ปัญหาใหญ่ที่สุดคือ benchmark ส่วนใหญ่เป็น การรันครั้งเดียว และแทบไม่ได้ทดสอบ model+ฮาร์เนสในงานแบบวนซ้ำนาน ๆ ซึ่งเป็นวิธีหลักที่ผู้ใช้จริงใช้เครื่องมือ
[0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
[1] https://github.com/harbor-framework/terminal-bench-2-1/issue...
ทุกคนก็รู้อยู่แล้วไม่ใช่หรือว่า SWE-Bench ทั้งชุดมีข้อบกพร่องตั้งแต่แรก? แม้แต่ผู้เขียนเองก็ยอมรับข้อจำกัด และขยับไปขั้นถัดไปตั้งนานแล้ว
ผมเข้าใจว่าทำไมมันอาจเป็น benchmark ที่แย่ได้ แต่ถ้าปัญหาคือ test ที่เข้มงวดเกินไปบังคับรายละเอียด implementation เฉพาะที่ไม่ได้ระบุใน prompt จนทำให้ submission ที่ถูกต้องเชิงฟังก์ชันใช้ไม่ได้, prompt ที่ไม่เพียงพอพลาด requirement ที่ hidden test บังคับแต่อนุมานอย่างสมเหตุสมผลไม่ได้, test coverage ต่ำตรวจฟีเจอร์ที่ขอน้อยเกินไปจนการแก้ที่ไม่สมบูรณ์ผ่านได้, และ prompt ที่ทำให้เข้าใจผิดชี้นำโมเดลไปสู่พฤติกรรมที่ผิดหรือขัดกับ requirement ของ test — ถ้าเป้าหมายคือ เปรียบเทียบวิศวกรซอฟต์แวร์จริงกับโมเดล สถานการณ์พวกนี้ก็ดูสมจริงทีเดียว
คล้ายกับการออกข้อสอบพยาบาล แล้วมาร์กบางข้อเพราะควรถามแพทย์เจ้าของไข้เพื่อขอข้อมูลเพิ่มเติมที่ไม่มีใน chart หรือเพราะครอบครัวผู้ป่วยไม่ได้อธิบายประวัติทางการแพทย์ของคุณยายสูงวัยให้เพียงพอ คุณอาจต้องการ benchmark ที่รัดกุมกว่าได้ แต่ถ้า OpenAI สัญญาว่าโมเดลจะเป็นสิ่งทดแทนแรงงานจริง นี่ไม่ใช่ภาพที่ดีนัก ตรงกันข้าม เราน่าจะอยากทดสอบเรื่องแบบนี้ด้วยซ้ำ
อ่านแล้วเหมือน “ทำงานทุกอย่างที่จำเป็นต่อการแก้ benchmark ไปแล้ว แต่สุดท้ายตัดสินใจทิ้ง benchmark” มีเหตุผลอะไรที่ข้อมูลฐานมันมีค่ามากจน patch ไม่ได้หรือเปล่า? ตอนท้ายเสนอให้ใช้แนวทางที่คัดกรองมากขึ้นอีกหน่อยในการสร้าง benchmark แต่ผมรู้สึกว่าวิธี patch อย่างเป็นธรรม กับ test ที่สกปรกและไม่สมบูรณ์ซึ่งดึงมาจากข้อมูลจริง ก็เป็นเส้นทางที่ค่อนข้างแข็งแรงเหมือนกัน
ถ้าบอกด้วยว่า “รายการ instance ที่พังอยู่ตรงนี้” หรือ “subset ของ SWE Bench Pro ที่จะใช้ต่อไปคือชุดนี้” ก็คงดี กำลังปล่อยให้ความสมบูรณ์แบบมาขวางสิ่งที่ดีอยู่
แต่ตอน OpenAI ออก SWE-Bench Verified เขาก็ทำเรื่องแบบนั้นอยู่แล้ว ดังนั้นผมอาจกำลังพูดเหลวไหลก็ได้
ตอนนี้ควรมองว่า state of the art ของ SWE benchmark คืออะไร?
ตามความคิดและการประเมินส่วนตัวของผม ตั้งนานมาแล้ว ผมมองว่าต่อให้เพดานศักยภาพของโมเดลหนึ่งสูงกว่า แต่ถ้าผมไม่มั่นใจจริง ๆ ว่าจะกด approve โค้ดนั้นได้ คุณค่าก็มีจำกัด
[0] https://deepswe.datacurve.ai/
[1] https://cognition.com/blog/frontier-code-1.1
[0]: https://deepswe.datacurve.ai/
มี https://cognition.ai/blog/frontier-code อยู่ ขอแจ้งไว้ก่อนว่าผมเคยอยู่ในทีมนั้น แต่ที่นั่นก็จัดการกับปัญหา swebench pro/deepswe ด้วย
การบรรลุ AGI ควรเป็นอะไรที่มากกว่าการผ่าน benchmark ทั้งหมด และต้องคำนึงถึงปัญหาที่ยังไม่เป็นที่รู้จักด้วย
ทางแก้มีเพียง a) ทำให้ LLM เล็กลงโดยยังมีประสิทธิภาพใกล้เคียงเดิม เพื่อไม่ให้มันจดจำหรือเจาะ benchmark ได้ หรือ b) สร้าง benchmark ที่ครอบคลุมข้อมูลโลกจริงทั้งหมด ซึ่งอย่างหลังเป็นไปไม่ได้ในทางปฏิบัติ