IBM และ Kaggle จับมือกันจัดทำลีดเดอร์บอร์ดการย้ายระบบ ScarfBench ที่อัปเดตอย่างต่อเนื่อง

IBM และ Kaggle กำลังร่วมกันจัดทำลีดเดอร์บอร์ดสาธารณะที่อัปเดตอย่างต่อเนื่องสำหรับ ScarfBench ซึ่งเป็นเบนช์มาร์กแบบเปิดของ IBM ที่ใช้ประเมินเอเจนต์เขียนโค้ดในการย้ายระบบเฟรมเวิร์ก Java ระดับองค์กร ตามบันทึกทางเทคนิคของ IBM Research ที่เผยแพร่เมื่อวันที่ 27 ตุลาคม 2026

ScarfBench ย่อมาจาก Self-Contained Application Refactoring Benchmark ใช้ทดสอบว่าเอเจนต์สามารถนำแอปพลิเคชัน Java ระดับองค์กรที่ไม่คุ้นเคยไปย้ายข้ามเฟรมเวิร์ก Jakarta EE, Quarkus และ Spring พร้อมทำให้ซอฟต์แวร์ยังคงทำงานได้หรือไม่ เบนช์มาร์กนี้ตรวจสอบว่าแอปพลิเคชันที่สร้างขึ้นสามารถบิลด์ เริ่มทำงาน และทำงานได้ตามที่คาดหวังอย่างต่อเนื่อง โดยใช้ทั้งเวิร์กโหลดเฉพาะด้านและแอปพลิเคชันทั้งระบบ IBM เปิดตัว ScarfBench เมื่อต้นปี 2026 ในฐานะเบนช์มาร์กที่ทำซ้ำได้สำหรับการย้ายระบบด้วย AI โดย ประกาศต้นฉบับ ซึ่งลงวันที่ 11 มีนาคม 2026 อธิบายองค์ประกอบเจ็ดส่วนไว้ ได้แก่ แอปพลิเคชันระดับองค์กรบนเฟรมเวิร์กทั้งสามที่นักพัฒนายืนยันความถูกต้องแล้ว เวิร์กโหลดเฉพาะด้านที่แยกประเด็นต่าง ๆ เช่น พฤติกรรมการจัดเก็บข้อมูลและการฉีดการพึ่งพา แอปพลิเคชันทั้งระบบที่รวมสถาปัตยกรรมหลายชั้นเข้าด้วยกัน การตรวจสอบการบิลด์และการเริ่มทำงานโดยอัตโนมัติ ตลอดจนการทดสอบพฤติกรรมที่ตรวจสอบการทำงานขณะรันและความเท่าเทียมด้านฟังก์ชันการทำงาน ประกาศดังกล่าวระบุว่า นักพัฒนาผู้มีประสบการณ์เป็นผู้ลงมือพัฒนาและตรวจสอบความถูกต้องของแต่ละเวิร์กโหลดด้วยตนเอง เพื่อให้มั่นใจว่ามีฟังก์ชันการทำงานเทียบเท่ากันและใช้เฟรมเวิร์กได้อย่างเป็นธรรมชาติ

ความร่วมมือระหว่าง IBM กับ Kaggle

ภายใต้ความร่วมมือนี้ Kaggle ให้คำปรึกษาแก่ IBM ในการออกแบบเบนช์มาร์กและการประเมินผล ทำซ้ำและรัน ScarfBench บนแพลตฟอร์มของตนเองอย่างเป็นอิสระ พร้อมสนับสนุนค่าใช้จ่ายด้านการประมวลผล และจะดูแลเบนช์มาร์กนี้ในระยะยาว IBM ระบุว่าจุดแข็งของทั้งสองทีมส่งเสริมกัน โดย IBM พัฒนา ScarfBench โดยมุ่งเน้นการปรับปรุงระบบ Java ระดับองค์กรให้ทันสมัย ส่วน Kaggle นำโครงสร้างพื้นฐานสำหรับการประเมินผลอย่างเป็นอิสระและการดูแลลีดเดอร์บอร์ดอย่างต่อเนื่องมาเสริม

ผลการประเมินงานย้ายระบบ 204 รายการ

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

จากงานย้ายระบบ 204 รายการและการกำหนดค่าระหว่างโมเดลกับฮาร์เนสที่ประเมิน 10 แบบ IBM รายงานว่า Gemini 4 Argon เมื่อใช้กับฮาร์เนส Antigravity ได้อันดับหนึ่งในตัวชี้วัดหลักอย่างคะแนนทดสอบเบื้องต้นที่ 75.2% ตามด้วย Claude Opus 5.5 เมื่อใช้กับ Claude Code ที่ 70.5% และ Claude Opus 5 เมื่อใช้กับ Claude Code ที่ 69.8% คะแนนทดสอบเบื้องต้นซึ่งใช้เป็นตัวชี้วัดของลีดเดอร์บอร์ดให้คะแนนบางส่วนได้ และให้น้ำหนักชุดทดสอบขนาดใหญ่กว่าให้มากขึ้น ส่วนเกณฑ์ที่เข้มงวดกว่าอย่างการผ่านการทดสอบทั้งหมด Claude Opus 5.5 เมื่อใช้กับ Claude Code ทำอัตราสูงสุดได้ 72.1% เฉือนชนะ Gemini 4 Argon เมื่อใช้กับ Antigravity ซึ่งทำได้ 71.1%

ตามที่โพสต์ระบุ ลำดับของกลุ่มผู้นำยังคงเดิมเมื่อทดสอบความไวของผลลัพธ์ งาน 4 รายการจากทั้งหมด 204 รายการไม่ได้รับคะแนนจากการทดสอบพฤติกรรมเลยในการกำหนดค่าทุกแบบ เมื่อตัดงานเหล่านี้ออก คะแนนรวมสูงขึ้น แต่ไม่ทำให้ผู้นำเปลี่ยนไป: Gemini 4 Argon เมื่อใช้กับ Antigravity ทำคะแนนได้ 79.4% ตามด้วย Claude Opus 5.5 เมื่อใช้กับ Claude Code ที่ 74.5% และ Claude Opus 5 เมื่อใช้กับ Claude Code ที่ 73.7% IBM ระบุว่า แม้แต่การจับคู่ที่ทำผลงานได้ดีที่สุดก็ยังมีช่องว่างให้พัฒนาอีกมาก โดยไม่มีการกำหนดค่าใดผ่านงานย้ายระบบทั้งหมดได้เกินประมาณสามในสี่

จุดที่การกำหนดค่าทำได้ดีและยังติดขัด

IBM รายงานว่า ช่องว่างที่กว้างที่สุดในการประเมินอยู่ระหว่างโค้ดที่บิลด์ได้กับซอฟต์แวร์ที่ทำงานได้อย่างถูกต้อง หลังตัดงาน 4 รายการที่ทุกการกำหนดค่าได้คะแนนศูนย์ออก Claude Opus 5 เมื่อใช้กับ Claude Code, Gemini 4 Argon เมื่อใช้กับ Antigravity และ Gemini 3.8 Flash เมื่อใช้กับ mini-swe ต่างก็คอมไพล์งานได้ 100% และการกำหนดค่า 8 จาก 10 แบบคอมไพล์ได้อย่างน้อย 97% ในทางกลับกัน คะแนนทดสอบเบื้องต้นมีช่วงห่างกันมากกว่า 50 จุด ในบรรดาแอปพลิเคชันที่ติดตั้งใช้งานได้สำเร็จ การกำหนดค่าที่ทำผลงานนำหน้ามีอัตราผ่านการทดสอบทั้งหมดอยู่ที่ประมาณ 63% ถึง 76% ขณะที่ Kimi K3 เมื่อใช้กับ kimi-code ทำได้เพียง 53%, Gemini 3.1 Pro เมื่อใช้กับ OpenHands ทำได้ 42% และ Gemma 4 26B-A4B เมื่อใช้กับ mini-swe ทำได้ 26%

IBM จัดประเภทการรันที่ล้มเหลว 745 ครั้ง โดย 535 ครั้ง หรือประมาณ 72% เป็นความล้มเหลวด้านพฤติกรรมขณะรัน ซึ่งแอปพลิเคชันบิลด์ได้และมักเริ่มทำงานได้ แต่ไม่ผ่านการตรวจสอบพฤติกรรม กลุ่มนี้ประกอบด้วยกรณีเนื้อหาหรือผลการยืนยันไม่ตรงกัน 304 ครั้ง เส้นทางสูญหายหรือข้อผิดพลาด 404 จำนวน 210 ครั้ง และข้อผิดพลาด HTTP 500 หรือ 405 ที่ระบุชัดเจน 21 ครั้ง ความล้มเหลวในการคอมไพล์หรือจัดแพ็กเกจคิดเป็นประมาณ 20% ของการรันที่ล้มเหลว หรือ 152 ครั้ง ส่วนการหยุดทำงานขณะเริ่มระบบหรือจากการฉีดการพึ่งพาคิดเป็นประมาณ 8% หรือ 58 ครั้ง

โพสต์ยกตัวอย่างปัญหาในระดับงานไว้หลายกรณี ใน concurrency-taskcreator-quarkus-to-jakarta, Claude Opus 5 เมื่อใช้กับ Claude Code ได้ 0/6 หลังจากจุดเชื่อมต่อ /taskinfo ส่งกลับข้อความ “File not found” และการทดสอบที่คาดหวัง HTTP 405 ไม่ผ่าน ใน address-book-jakarta-to-quarkus, GPT-6 Astra เมื่อใช้กับ Codex ได้ 2/10 หลังจากหน้ารายการและหน้าสร้างข้อมูลส่งกลับ HTTP 404 ใน cargotracker-jakarta-to-spring, Gemini 3.8 Flash เมื่อใช้กับ mini-swe ยังคงใช้การเชื่อมต่อ JSF/JoinFaces ในเป้าหมาย Spring Boot และล้มเหลวระหว่างเริ่มทำงานขณะสร้างบีน facesContext ส่วนใน cart-spring-to-jakarta, GPT-6 Astra เมื่อใช้กับ Codex ติดปัญหาการติดตั้งใช้งาน เนื่องจากชนิดแพ็กเกจที่เหลือจากการย้ายระบบไม่ได้รับการรองรับจาก Liberty runtime เป้าหมาย

IBM รายงานด้วยว่าประสิทธิภาพแตกต่างกันไปตามการตั้งค่า ในงาน 200 รายการที่เหลือหลังตัดรายการออกตามการวิเคราะห์ความไว จำนวนรอบการทำงานมัธยฐานอยู่ระหว่าง 32 รอบสำหรับ Claude Opus 5 ร่วมกับ Claude Code ไปจนถึง 79 รอบสำหรับ Gemini 3.8 Flash ร่วมกับ mini-swe ส่วน Claude Opus 5.5 ร่วมกับ Claude Code อยู่ที่ 64 รอบ ในกรณีที่ชุดเครื่องมือรายงานค่าใช้จ่าย ซึ่งครอบคลุมการตั้งค่า Claude Code, Codex, mini-swe และ kimi-code ค่าใช้จ่ายต่อภารกิจที่ทำสำเร็จอยู่ระหว่าง $1.25 สำหรับ GPT-6.1 Sol ร่วมกับ Codex ไปจนถึง $10.10 สำหรับ Claude Opus 5.5 ร่วมกับ Claude Code ส่วนชุดเครื่องมือ Antigravity, qwen-code และ OpenHands ไม่ได้รายงานตัวเลขค่าใช้จ่ายต่อการทำงานแต่ละครั้ง

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