ScarfBench: เกณฑ์มาตรฐาน AI Agent สำหรับการย้าย Framework Java ในระดับองค์กร

ScarfBench: เกณฑ์มาตรฐาน AI Agent สำหรับการย้าย Framework Java ในระดับองค์กรความก้าวหน้าล่าสุดของ AI ด้านการเขียนโค้ดได้จุดประกายความตื่นเต้นเกี่ยวกับการปรับปรุงระบบด้วย AI แต่คำถามสำคัญที่ยังคงอยู่คือ: AI Agent สามารถปรับปรุงแอปพลิเคชันระดับองค์กรในโลกแห่งความเป็นจริงได้อย่างน่าเชื่อถือหรือไม่?แม้ว่าเกณฑ์มาตรฐานทางวิศวกรรมซอฟต์แวร์ที่มีอยู่จะแสดงให้เห็นถึงความคืบหน้าที่น่าประทับใจในการแก้ไขข้อบกพร่องและการสร้างโค้ด แต่การย้าย Framework นั้นเป็นความท้าทายที่แตกต่างออกไปโดยสิ้นเชิง ความสำเร็จไม่เพียงแต่ต้องอาศัยการแปลโค้ดเท่านั้น แต่ยังรวมถึงการรักษาพฤติกรรม, การปรับระบบ Build, และการจัดการ Dependencies ขณะทำงานด้วยเพื่อแก้ไขช่องว่างนี้ เราขอแนะนำ ScarfBench (Self-Contained Application Refactoring Benchmark) ซึ่งเป็นเกณฑ์มาตรฐานแบบเปิดสำหรับการประเมิน AI Agent ในงานย้าย Framework ข้ามระบบใน Enterprise JavaScarfBench มุ่งเน้นไปที่การย้ายระหว่างระบบ Java หลักสามระบบ:SpringJakarta EEQuarkusซึ่งแตกต่างจากเกณฑ์มาตรฐานแบบดั้งเดิมที่เปรียบเทียบโค้ดที่สร้างขึ้นกับ Implementation อ้างอิง ScarfBench จะประเมินว่าแอปพลิเคชันที่ถูกย้ายนั้นสามารถ Build, Deploy, และรักษาพฤติกรรมเดิมได้หรือไม่ทำไมการย้าย Framework ถึงเป็นเรื่องยาก? 🤔การย้าย Framework นั้นเป็นมากกว่าการแทนที่ Annotation เพียงอย่างเดียว การย้าย Repository แบบง่ายๆ อาจต้องมีการเปลี่ยนแปลงในส่วนต่างๆ เช่น Dependency Injection, การตั้งค่า Persistence, Query, และ Framework Descriptors ความผิดพลาดเล็กน้อยในส่วนเหล่านี้สามารถป้องกันไม่ให้ระบบทำงานได้สำเร็จรูปภาพ: ตัวอย่างการย้ายจาก Spring ไปยัง Jakartaการย้าย Framework ต้องการการแปลความหมายของ Framework ไม่ใช่แค่ Source Code เท่านั้นการเปิดตัว ScarfBench 🚀ScarfBench นำเสนอวิธีการที่เป็นระบบในการประเมิน AI Agent สำหรับงานย้าย Framework ใน Enterprise Javaแอปพลิเคชันจะต้อง:Build สำเร็จDeploy สำเร็จผ่านการตรวจสอบพฤติกรรม (Behavioral Validation)สิ่งนี้เป็นการวัดคุณภาพของการปรับปรุงระบบที่สมจริงมากขึ้นภาพรวมของเกณฑ์มาตรฐาน 📊ScarfBench ประกอบด้วยทั้งงานย้ายแบบเฉพาะเจาะจงและงานย้ายแอปพลิเคชันทั้งระบบรูปภาพ: ScarfBench Construction Pipelineเริ่มต้นจาก Taxonomy ของ Enterprise Java ที่อิงตาม JSR, ผู้เชี่ยวชาญได้สร้าง Implementation ที่ได้รับการยืนยันสำหรับ Spring, Jakarta EE, และ QuarkusAI Agent ในปัจจุบันทำได้ดีแค่ไหน? 🤖เราได้ประเมิน AI Agent ที่ทันสมัยหลายตัวบน ScarfBench แม้จะมีประสิทธิภาพที่แข็งแกร่งในเกณฑ์มาตรฐานแบบดั้งเดิม แต่การย้าย Framework ยังคงเป็นเรื่องยาก อัตราความสำเร็จแตกต่างกันไปอย่างมากในแต่ละคู่ Framework และการย้ายแอปพลิเคชันทั้งระบบยังคงเป็นสิ่งที่ท้าทายอย่างยิ่งรูปภาพ: Current Leaderboardรูปภาพ: Compile → Deploy → Test Progressionความสำเร็จในการ Build มักจะสูงกว่าความสำเร็จในการ Deploy ซึ่งสูงกว่าความสำเร็จในการตรวจสอบพฤติกรรม การพึ่งพาแค่ความสำเร็จในการ Build เพียงอย่างเดียวอาจทำให้ประเมินคุณภาพการย้ายสูงเกินจริงรูปภาพ: Migration Outcomes by Target Frameworkความยากในการย้ายขึ้นอยู่กับ Framework ปลายทางอย่างมาก โดย Jakarta EE พิสูจน์แล้วว่ามีความท้าทายเป็นพิเศษสิ่งที่เราได้เรียนรู้เกี่ยวกับ AI Agent สำหรับการปรับปรุง Java 💡นอกเหนือจากการวัดอัตราความสำเร็จแล้ว ScarfBench ยังช่วยให้เราเข้าใจพฤติกรรมของ Agent ในระหว่างการปรับปรุงระบบAgent สามารถบอกได้อย่างน่าเชื่อถือหรือไม่ว่าการย้ายเสร็จสมบูรณ์? 🧐แอปพลิเคชันที่ถูกย้ายจะมีประโยชน์ก็ต่อเมื่อสามารถ Build และ Run ได้จริงเท่านั้น เราจึงเปรียบเทียบผลลัพธ์ที่ Agent รายงานกับผลการตรวจสอบ Build ที่เป็นอิสระClaude Code รายงานว่า Build สำเร็จสำหรับ 29 จาก 30 แอปพลิเคชันทั้งระบบแต่มีเพียง 22 แอปพลิเคชันเท่านั้นที่ Build สำเร็จจริงในขณะเดียวกัน แอปพลิเคชันเดียวที่ Agent จัดว่าเป็นความล้มเหลว กลับ Build ได้อย่างถูกต้องสิ่งนี้ชี้ให้เห็นว่าการประเมินตนเองของ Agent ไม่ควรถูกมองว่าเป็นสัญญาณที่น่าเชื่อถือของการย้ายที่เสร็จสมบูรณ์ การตรวจสอบ Build และ Test ที่เป็นอิสระยังคงมีความสำคัญAgent นำทางการพึ่งพาของแอปพลิเคชันได้อย่างไร? 🔗การย้าย Framework มักจะส่งผลกระทบต่อหลายส่วนของแอปพลิเคชัน การเปลี่ยนแปลงในการตั้งค่า, บริการ, ฐานข้อมูล, และส่วนประกอบเว็บ มักจะส่งผลกระทบต่อเนื่องไปทั่วทั้งแอปพลิเคชันLayer ที่ถูกเยี่ยมชมบ่อยที่สุด:ConfigurationServicesPersistenceWeb Componentsการเปลี่ยนผ่านทั่วไป:Spring Boot → Jakarta EESpring MVC → Jakarta MVCSpring Data JPA → Jakarta Persistenceสิ่งนี้บ่งชี้ว่าการย้ายเป็นการดำเนินการแก้ไข Dependency แบบวนซ้ำ มากกว่าจะเป็นการแปลง Source-to-Source แบบง่ายๆAgent ใช้เวลาส่วนใหญ่ไปกับอะไร? ⏳เราใช้ความถี่ในการเยี่ยมชม Layer ซ้ำเป็นตัวแทนของความพยายามในการย้าย Layer ที่ต้องกลับมาเยี่ยมชมซ้ำๆ มักเกี่ยวข้องกับการ Debug, การแก้ไข Dependency, หรือการปรับ FrameworkAgent กลับไปที่ Artifact ที่เกี่ยวข้องกับการตั้งค่าซ้ำๆ ในขณะที่แก้ไขความแตกต่างของ Framework และปัญหา Dependency แทนที่จะดำเนินการตามลำดับความท้าทายใดที่ไม่ใช่การแปลง Source Code? ⚠️ไม่ใช่ทุกปัญหาการย้ายที่เกิดจาก Source Code Agent มักประสบปัญหาเกี่ยวกับสภาพแวดล้อม รวมถึง:ความไม่สอดคล้องกันของ Docker cacheปัญหาการเชื่อมต่อ Portปัญหาเกี่ยวกับ Maven wrapper และเครื่องมือ Buildข้อกังวลในการดำเนินงานเหล่านี้มักทำให้การตรวจสอบล่าช้า แม้ว่าการย้าย Source Code จะเสร็จสมบูรณ์แล้วก็ตามรูปภาพ: Failure Mode Distributionความล้มเหลวในการปรับปรุงระบบครอบคลุมถึงระบบ Build, สภาพแวดล้อมการ Deploy, Dependency Injection, ฐานข้อมูล, Endpoint, Assertion, และโครงสร้างพื้นฐานความท้าทายที่ใหญ่ที่สุดในการปรับปรุง Framework ไม่ใช่การแปล Java Code แต่คือการจัดการเครือข่ายของ Dependencies ที่ครอบคลุมการตั้งค่า, โครงสร้างพื้นฐาน, และสภาพแวดล้อมขณะทำงานแม้ว่า Agent ที่ทันสมัยจะสามารถทำงานส่วนใหญ่ของกระบวนการย้ายโดยอัตโนมัติได้ แต่การตรวจสอบที่น่าเชื่อถือและการให้เหตุผลเชิงสถาปัตยกรรมยังคงมีความสำคัญอย่างยิ่งต่อการบรรลุผลลัพธ์ที่สำเร็จScarfBench: ทรัพยากรสำหรับทุกคน 🤝ScarfBench ถูกออกแบบมาให้เป็นทรัพยากรแบบเปิดสำหรับนักวิจัยและผู้ปฏิบัติงานโครงสร้างพื้นฐานสำหรับการประเมิน: นักวิจัยสามารถเปรียบเทียบสถาปัตยกรรมและเทคนิคของ Agentสำหรับผู้ปฏิบัติงาน: สามารถใช้ ScarfBench เพื่อประเมินโซลูชันการปรับปรุงระบบก่อนนำไปใช้ในสภาพแวดล้อมการผลิตแหล่งข้อมูลเพิ่มเติม:[scarfbench.info](https://scarfbench.info)[huggingface.co/datasets/ibm-research/ScarfBench](https://huggingface.co/datasets/ibm-research/ScarfBench)[huggingface.co/spaces/ibm-research/ScarfBench](https://huggingface.co/spaces/ibm-research/ScarfBench)[github.com/scarfbench/scarfbench](https://github.com/scarfbench/scarfbench)[scarfbench.info/leaderboard](https://scarfbench.info/leaderboard)[arxiv.org/abs/2605.06754](https://arxiv.org/abs/2605.06754)การย้าย Framework ยังคงเป็นหนึ่งในปัญหาที่ใหญ่ที่สุดที่ยังไม่ได้รับการแก้ไขในด้านวิศวกรรมซอฟต์แวร์ที่ช่วยเหลือด้วย AI เราหวังว่า ScarfBench จะช่วยให้ชุมชนสามารถวัดความคืบหน้าและเร่งการพัฒนา AI-assisted application modernization รุ่นต่อไปเราขอเชิญนักวิจัย, ผู้ปฏิบัติงาน, และชุมชน Framework ต่างๆ มาประเมิน Agent ของตนเอง, มีส่วนร่วมกับสถานการณ์การย้ายใหม่ๆ และช่วยขับเคลื่อนความก้าวหน้าของเทคโนโลยี#ScarfBench #AI #Java #FrameworkMigration #EnterpriseJavahttps://huggingface.co/blog/ibm-research/scarfbench