Maya Bennett
Az IBM Research bemutatta a ScarfBench-et, egy nyílt benchmarkot, amely azt méri, hogy az AI-ügynökök mennyire jól kezelik a vállalati Java keretrendszerek migrációját. A benchmark rávilágít, hogy a konfiguráció és a futásidejű függőségek jelentik a legnagyobb akadályt, nem pedig a kód fordítását.
A kódoló ügynökök legújabb fejlesztései izgalmat keltettek az AI-asszisztált modernizáció körül. De egy fontos kérdés továbbra is fennáll: Vajon az AI-ügynökök megbízhatóan modernizálják a valós vállalati alkalmazásokat?
A meglévő szoftvermérnöki benchmarkok lenyűgöző előrelépést mutattak a hibajavításban és a kódgenerálásban, de a keretrendszermigráció alapvetően más kihívást jelent. A sikerhez nemcsak a kód fordítása szükséges, hanem a viselkedés megőrzése, a buildrendszerek adaptálása és a futásidejű függőségek kezelése is.
Ennek a hiányosságnak a pótlására az IBM Research létrehozta a ScarfBench (Self-Contained Application Refactoring Benchmark) nevű nyílt benchmarkot, amely az AI-ügynökök értékelésére szolgál a keretrendszerek közötti migrációs feladatokban Enterprise Java környezetben. A ScarfBench három nagy Java ökoszisztéma – Spring, Jakarta EE és Quarkus – közötti migrációkra összpontosít.
Ellentétben a hagyományos benchmarkokkal, amelyek a generált kódot referenciaimplementációkhoz hasonlítják, a ScarfBench azt értékeli, hogy a migrált alkalmazások valóban buildelődnek, telepíthetők és megőrzik a viselkedést.
Miért nehéz a migráció
A keretrendszermigráció sokkal több, mint annotációk cseréje. Egy egyszerű repository migráció változtatásokat igényelhet a függőséginjektálásban, a perzisztenciakonfigurációban, a lekérdezésekben és a keretrendszerleírókban. Bármelyik apró hiba megakadályozhatja a sikeres telepítést.
Ábra: Spring → Jakarta migrációs példa
A keretrendszermigráció megköveteli a keretrendszer szemantikájának fordítását, nem csak a forráskódét.
A ScarfBench bemutatása
A ScarfBench szisztematikus módot biztosít az AI-ügynökök értékelésére vállalati Java keretrendszermigrációs feladatokban. Az alkalmazásoknak sikeresen buildelődniük, helyesen települniük és át kell menniük a viselkedési validáción. Ez sokkal reálisabb mérőszámot ad a modernizáció minőségére.
A benchmark tartalmaz fókuszált migrációs feladatokat és teljes alkalmazás migrációkat is.
Ábra: ScarfBench felépítési folyamat
Egy JSR-alapú vállalati Java taxonómiából kiindulva szakértői migrációk hoznak létre ellenőrzött implementációkat Spring, Jakarta EE és Quarkus környezetben.
Hogyan teljesítenek a határvonali ügynökök?
Az IBM Research több állapotfrissített kódoló ügynököt is kiértékelt a ScarfBench-en. A hagyományos szoftvermérnöki benchmarkokon nyújtott erős teljesítmény ellenére a keretrendszermigráció továbbra is nehéz. A sikerességi arányok jelentősen eltérnek a keretrendszerpárok között, és a teljes alkalmazás migrációk különösen nagy kihívást jelentenek.
Ábra: Jelenlegi ranglista
Ábra: Fordítás → Telepítés → Tesztelés előrehaladása
A fordítási sikeresség következetesen meghaladja a telepítési sikerességet, ami viszont meghaladja a viselkedési sikerességet. A build sikeressége önmagában jelentősen túlbecsüli a migráció minőségét.
Ábra: Migrációs eredmények célkeretrendszer szerint
A migráció nehézsége erősen függ a célkeretrendszertől, a Jakarta EE különösen nagy kihívást jelent.
Mit tanultunk az AI-ügynökökről a Java modernizációban
A sikerességi arányok mérésén túl a ScarfBench segít megérteni, hogyan viselkednek az ügynökök a modernizáció során.
Megbízhatóan meg tudják-e mondani az ügynökök, hogy mikor kész a migráció?
Egy migrált alkalmazás csak akkor hasznos, ha ténylegesen buildelődik és fut. Az IBM Research összehasonlította az ügynökök által jelentett eredményeket a független build ellenőrzéssel.
„A Claude Code 30 teljes alkalmazásból 29 esetben sikeres buildet jelentett. Valójában csak 22 alkalmazás buildelődött sikeresen. Eközben az egyetlen alkalmazás, amelyet az ügynök sikertelennek minősített, végül helyesen buildelődött.”
— IBM Research
Ez arra utal, hogy az ügynökök önértékelése nem tekinthető megbízható jelzésnek a migráció befejezésére. A független build- és tesztvalidáció továbbra is elengedhetetlen.
Hogyan navigálnak az ügynökök az alkalmazásfüggőségek között?
A keretrendszermigrációk ritkán érintenek egyetlen fájlt vagy réteget. A konfiguráció, szolgáltatások, adatbázisok és webes komponensek változásai gyakran áthatják az alkalmazást.
A leggyakrabban érintett rétegek a konfiguráció, a web, az adatbázis és a szolgáltatás voltak. Gyakori átmenetek voltak a konfiguráció ↔ web és a szolgáltatás ↔ adatbázis. Ez arra utal, hogy a migráció egy iteratív függőségfeloldási folyamat, nem pedig egyszerű forrásból forrásba történő átalakítás.
Hol töltik az ügynökök a legtöbb erőfeszítést?
A rétegek újralátogatásának gyakoriságát a migrációs erőfeszítés proxyjaként használva a kutatók azt találták, hogy a konfiguráció dominálja a migrációs erőfeszítést. A lineáris haladás helyett az ügynökök ismételten visszatértek a konfigurációval kapcsolatos artefaktumokhoz, miközben a keretrendszerbeli különbségeket és függőségi problémákat oldották meg.
Milyen kihívások nem a kódátalakításból származnak?
Nem minden migrációs probléma ered a forráskódból. Az ügynökök gyakran küzdöttek környezeti problémákkal, beleértve a Docker gyorsítótár inkonzisztenciákat, portkapcsolati problémákat, valamint Maven wrapper és build eszközökkel kapcsolatos problémákat. Ezek az operatív problémák gyakran késleltették a validációt, még akkor is, ha a forráskód migrációja nagyrészt kész volt.
Ábra: Hibamódok eloszlása
A modernizációs hibák kiterjednek a build rendszerekre, telepítési környezetekre, függőséginjektálásra, adatbázisokra, végpontokra, állításokra és infrastruktúrára.
Fő tanulság
A keretrendszer modernizáció legnagyobb kihívása nem a Java kód fordítása. Hanem a konfiguráció, infrastruktúra és futásidejű környezetek közötti függőségi háló kezelése. Bár a határvonali ügynökök képesek automatizálni a migrációs folyamat jelentős részét, a megbízható validáció és az architekturális gondolkodás továbbra is kritikus a sikeres eredmények eléréséhez.
A ScarfBench segít feltárni ezeket a kihívásokat, és szabványosított módot biztosít a valóban autonóm alkalmazásmodernizáció felé tett előrelépés mérésére.
Fedezze fel a ScarfBench-et
A ScarfBench nyílt forrásként áll a kutatók és gyakorlati szakemberek rendelkezésére. Az erőforrások közé tartozik egy benchmark adatkészlet, kiértékelési infrastruktúra, nyilvános ranglista, dokumentáció és nyílt forráskódú kód. A kutatók összehasonlíthatják az ügynök architektúrákat és technikákat. A gyakorlati szakemberek használhatják a ScarfBench-et a modernizációs megoldások értékelésére, mielőtt azokat éles környezetben telepítenék.
- Weboldal: https://scarfbench.info
- Adatkészlet: https://huggingface.co/datasets/ibm-research/ScarfBench
- Space: https://huggingface.co/spaces/ibm-research/ScarfBench
- GitHub Repository: https://github.com/scarfbench/scarfbench
- Ranglista: https://scarfbench.info/leaderboard
- Tanulmány: https://arxiv.org/abs/2605.06754
A keretrendszermigráció továbbra is az egyik legnagyobb megoldatlan probléma az AI-asszisztált szoftvermérnökségben. Az IBM Research reméli, hogy a ScarfBench segít a közösségnek mérni a fejlődést és felgyorsítani az AI-asszisztált alkalmazásmodernizáció következő generációját. A csapat meghívja a kutatókat, gyakorlati szakembereket és keretrendszer szerzőket, hogy járuljanak hozzá és segítsenek kitolni a határokat, amit az AI-ügynökök elérhetnek a vállalati szoftvermodernizációban.
