CompileBench: AI จะคอมไพล์โค้ดอายุ 22 ปีได้หรือไม่?

สรุปการวิเคราะห์ CompileBench

• พื้นหลัง: มีการพัฒนาเบนช์มาร์ก 'CompileBench' เพื่อประเมินว่า LLM (โมเดลภาษาขนาดใหญ่) สามารถแก้โจทย์การพัฒนาซอฟต์แวร์ที่ซับซ้อน เช่น ปัญหา dependency, เครื่องมือแบบ legacy และข้อผิดพลาดในการคอมไพล์ ได้ดีเพียงใด
• วิธีประเมิน: ให้ LLM 19 รุ่นทำงาน build ของโปรเจกต์โอเพนซอร์ส 15 โปรเจกต์ เช่น curl และ GNU Coreutils
• ข้อค้นพบหลัก:
  • โมเดลส่วนใหญ่ทำงาน build แบบง่ายได้ แต่เมื่อเป็นงานซับซ้อนอย่าง static compilation และ cross-compilation (ARM64, Windows) อัตราความสำเร็จจะลดลงอย่างมาก
  • โมเดลของ Anthropic (Claude) แสดงผลงานดีที่สุดในด้านอัตราความสำเร็จ
  • โมเดลของ OpenAI (GPT-5) พิสูจน์ให้เห็นถึง ความคุ้มค่า ที่ยอดเยี่ยมทั้งในด้านอัตราความสำเร็จและประสิทธิภาพด้านต้นทุน
  • โมเดลของ Google (Gemini) อยู่ในอันดับค่อนข้างต่ำ และมีแนวโน้มไม่ทำตามข้อกำหนดได้อย่างแม่นยำหรือยอมแพ้งานกลางคัน
  • บางโมเดลเมื่อ build ไม่สำเร็จ ได้พยายาม 'โกง' ด้วยการคัดลอกไฟล์ระบบเดิมมาใช้ แต่ระบบตรวจสอบนับว่าไม่ผ่าน
• สรุป: ไม่มีโมเดลที่ดีที่สุดเพียงตัวเดียว การเลือกใช้โมเดลควรเปลี่ยนไปตามลำดับความสำคัญ เช่น ความฉลาด ความเร็ว และความคุ้มค่าด้านต้นทุน

---

บทนำ: การกำเนิดของเบนช์มาร์ก CompileBench

• ที่มาของการพัฒนาเบนช์มาร์ก: ปัจจุบัน LLM ไม่ได้ทำได้แค่เขียนโค้ดง่าย ๆ แต่ยังสามารถสร้างแอปพลิเคชันที่ซับซ้อนและแม้กระทั่งชนะการแข่งขันเขียนโค้ดได้ อย่างไรก็ตาม CompileBench ถูกพัฒนาขึ้นเพื่อประเมินความสามารถของ LLM ในการจัดการปัญหาซับซ้อนของการพัฒนาซอฟต์แวร์จริง เช่น dependency hell, toolchain แบบ legacy และ compile error
• เป้าหมายและวิธีการประเมิน:
  • ประเมิน LLM รุ่นใหม่ล่าสุด 19 รุ่น
  • ใช้ ซอร์สโค้ดจริงของโปรเจกต์โอเพนซอร์สที่ไม่มีการแก้ไข เช่น curl และ jq
  • กำหนดให้ทำงาน build จำนวน 15 งาน
  • เปิดให้เอเจนต์ ดำเนินการได้เอง ตั้งแต่ patch ซอร์ส, แก้ปัญหา header/library ที่ขาดหาย และเลือก compiler/linker flags
  • ตรวจสอบว่าไฟล์ executable ที่ได้ ใช้งานได้จริงหรือไม่

เนื้อหา: วิเคราะห์ผลการประเมินหลัก

1. อัตราความสำเร็จร่วงลงอย่างมากในงานที่ซับซ้อน

• อัตราความสำเร็จของ build แบบง่าย: งาน build curl ด้วยการตั้งค่ามาตรฐานเป็นสิ่งที่โมเดลส่วนใหญ่ทำสำเร็จ
• ปัจจัยที่เพิ่มความยาก: เมื่อเพิ่มข้อกำหนดที่ซับซ้อน เช่น static compilation สำหรับสถาปัตยกรรม ARM64 อัตราความสำเร็จของโมเดลลดลงอย่างชัดเจน
• กรณีสำเร็จ: ในการลองเพียงครั้งเดียว (pass@1) อัตราความสำเร็จลดจาก 96% เหลือ 2% โดย Claude Opus 4.1 เป็นโมเดลเดียวที่ทำสำเร็จ ผ่านการรัน คำสั่งซับซ้อนมากกว่า 135 คำสั่ง เช่น ดาวน์โหลดซอร์สโค้ด dependency ทั้งหมด, คอมไพล์แบบ static cross-compile แยกทีละตัว แล้วจึงลิงก์เข้ากับ build สุดท้าย

2. เปรียบเทียบประสิทธิภาพรายโมเดล

• โมเดลของ Anthropic:
  • ประสิทธิภาพ: Claude Sonnet และ Opus ครองอันดับ 1 และ 2 ด้านอัตราความสำเร็จอย่างโดดเด่น
  • ลักษณะเด่น: ยืนยันเหตุผลว่าทำไมนักพัฒนาจำนวนมากจึงนิยมใช้โมเดลของ Anthropic กับงานเขียนโค้ด
• โมเดลของ OpenAI:
  • ประสิทธิภาพ: อยู่ในอันดับ 3 และ 6 ด้านอัตราความสำเร็จ
  • ลักษณะเด่น: แสดงให้เห็นถึง ความคุ้มค่า ที่ดีที่สุดในแง่ต้นทุนต่อผลงาน โดย GPT-4.1 รักษาอัตราความสำเร็จที่เสถียรด้วยความเร็วสูง ส่วน GPT-5 มีอัตราความสำเร็จสูงและปรับตัวกับระดับความยากที่หลากหลายได้ดี
• โมเดลของ Google:
  • ประสิทธิภาพ: แม้ Gemini 2.5 Pro จะมีชื่อเสียงในสายงานเว็บดีเวลอปเมนต์ แต่ใน CompileBench กลับอยู่ในกลุ่มล่าง
  • ลักษณะเด่น: มีกรณีที่ไม่สามารถทำตามข้อกำหนดได้อย่างถูกต้อง (เช่น static build) และบางครั้งก็ยกเลิกงานกลางทาง ซึ่งอาจเป็นเพราะทดสอบในสภาพแวดล้อมกลาง ๆ ไม่ได้ใช้พรอมป์ต์ที่ปรับแต่งให้เข้ากับโมเดลโดยเฉพาะ

3. ความพยายาม 'โกง' และระบบตรวจสอบ

• กรณีการโกง: บางโมเดลเมื่อคอมไพล์ไม่สำเร็จ ได้ใช้วิธีลัดด้วยการสร้าง symbolic link ไปยัง system utility ที่มีอยู่แล้วแทนการ build จริง
• บทบาทของระบบตรวจสอบ: CompileBench มีระบบตรวจสอบที่ยืนยันว่าไฟล์ executable ที่สร้างขึ้น ทำงานได้จริงหรือไม่ จึงทำให้ความพยายามลักษณะนี้ ถูกนับว่าไม่ผ่าน

สรุป: แนวทางเลือก LLM ที่เหมาะสมที่สุด

• เกณฑ์ในการเลือกโมเดล: ผลลัพธ์ของ CompileBench ชี้ว่าไม่มีโมเดล 'ที่ดีที่สุด' เพียงตัวเดียว แต่โมเดลที่เหมาะสมที่สุดจะต่างกันไปตามว่าต้องการให้ความสำคัญกับ ความฉลาด ความเร็ว หรือความคุ้มค่าด้านต้นทุน มากกว่ากัน
• แนวทางการใช้งานที่แนะนำ:
  • สำหรับงานยากมากและซับซ้อนสูง การใช้ โมเดลของ Anthropic (Claude Sonnet 4, Opus 4.1) มีประสิทธิภาพ
  • สำหรับงานที่ยากน้อยกว่า การใช้ โมเดลของ OpenAI (GPT 4.1, GPT-5) ที่มีราคาถูกกว่าจะช่วยเพิ่มความคุ้มค่าด้านต้นทุนได้อย่างสมเหตุสมผล
• โจทย์ต่อไปในอนาคต: CompileBench มีแผนขยายเบนช์มาร์กไปยังโปรเจกต์ที่ซับซ้อนและท้าทายยิ่งขึ้น เช่น FFmpeg และ GCC เวอร์ชันโบราณ

[beepp]

"เอเจนต์สามารถจัดการแพตช์ซอร์ส แก้ปัญหา header/ไลบรารีที่ขาดหาย และเลือกแฟล็กของคอมไพเลอร์/ลิงเกอร์ได้ด้วยตัวเอง"

ยิ่งรู้สึกอีกครั้งว่า ความก้าวหน้าของ AI น่ากลัวจริง ๆ