A Gemini 4 Argon 11 óra alatt gyorsította fel a Google ADK-ját

A Gemini 4 Argon egy közel 205 ezer soros Python-kódbázisban talált teljesítményproblémákat, majd a Google fejlesztői által végzett ellenőrzés után két javítás került a projekt fő ágába. A Google ADK hosszú munkameneteinek memóriabeli előkészítési ideje körülbelül 40 százalékkal, a hideg csomagbetöltés ideje pedig 21 százalékkal csökkent.
- A Gemini 4 Argon 11 órán át dolgozott a Google ADK Python-kódbázisán.
- A közel 205 ezer soros projektben hat optimalizálást javasolt.
- A fejlesztői ellenőrzés után két módosítás került a fő ágba.
- A hosszú munkamenetek előkészítési ideje körülbelül 40 százalékkal csökkent.
- A hideg csomagimportok 21 százalékkal gyorsultak.
Nagy és összetett kódbázison tesztelték
A Google Developers Blog október 13-i beszámolója szerint a Gemini 4 Argon teljesítményét nem üres mappából létrehozott mintaprojekten vizsgálták. A cél az volt, hogy a modell egy már működő, több fájlból álló rendszerben keressen és javítson teljesítményszűk keresztmetszeteket.
A tesztalany a google/adk-python repository volt. Az Agent Development Kit, röviden ADK, a Google nyílt forráskódú keretrendszere vállalati ügynökök létrehozására és telepítésére. A Python-kód nagyjából 205 ezer sorból áll közel 800 forrásfájlban, a projektet pedig csaknem 17 ezer egységteszt támogatja.
A Google szerint a teljesítmény javítása azért jelentett nehéz feladatot, mert a lassulás oka gyakran nem ott található, ahol a tünet megjelenik. A modellnek hosszabb futás közben kellett feltérképeznie a kódbázis kapcsolatait, a hívókat, a tesztelési helyeket és a megosztott állapotokat.
Kétféle beállítással futott a kísérlet
Az első körben a Gemini 4 Argon semmilyen egyedi repository-utasítást nem kapott. Egyetlen célmeghatározás alapján dolgozott, amely szerint az ADK nem okozhatott észrevehető többletterhelést induláskor, hosszú munkamenetekben, többügynökös és munkafolyamat-alapú használatkor. A Google elvárta azt is, hogy a modell ne változtassa meg a nyilvános programozási felületet, és minden módosítást regressziót kiszűrő teszttel támasszon alá.
Ez a kör körülbelül két órán át tartott. Argon hét perc után benchmarkot írt, majd 70 percig méréseket végzett és kódot olvasott, mielőtt módosított volna egyetlen ADK-forrásfájlt. Valós szűk keresztmetszeteket talált a munkamenetek másolásában és a csomagok importálásában.
A Google azonban több problémát is azonosított. A modell nem ismerte a karbantartói elvárásokat, egy egyedi hitelesítési megoldás finoman módosította a nyilvános JSON-sémát, a másolója nem kezelt minden ál-eseményhez kapcsolódó esetet, és csak 216 közeli egységtesztet futtatott.
A második körben a csapat a karbantartói irányelveket az .agents/skills könyvtárban helyezte el. Az irányelvek rövid SKILL.md indexekből és szükség esetén betöltött referenciafájlokból álltak. Emellett bekapcsolták a Google Antigravity /goal módját, amely a cél megtartásával segítette a hosszabb, kontextus-összevonásokon átívelő futást. Argon 11 órán keresztül dolgozott felügyelet nélkül, majd ellenőrzésre kész, a fő ágba nem beolvasztott pull requestet nyitott.
Hat javaslatból kettő került be a projektbe
A második futás elején Argon 12 irányelvfájlt olvasott el, majd négy munkaterhelésen végzett alapmérést. Ezek között szerepelt a csomag indulása, egy 200 lépéses beszélgetés, egy 20 alügynököt használó tesztalkalmazás és egy 12 csomópontos munkafolyamat. A méréseket 30 alkalommal futtatta le.
A modell összesen hat optimalizálást javasolt 32 fájlban. Az első elfogadott módosítás a memóriában tárolt munkamenetek előzményeit érintette. Korábban az ADK minden olvasáskor a teljes beszélgetést mélyen lemásolta, majd csak ezután szűrte ki a kért eseményeket. Argon a szűrést a másolás elé helyezte, és a Pydantic általános mélymásolási útvonala helyett gyors, ciklusbiztos másolót alkalmazott.
A második változtatás a nehéz csomagok késleltetett betöltését vezette be. A google.adk importálása korábban az élő hang- és videostreameléshez, az OpenTelemetry nyomkövetéshez, valamint a FastAPI és Starlette webszerverekhez kapcsolódó modulokat is betöltötte. Az új megoldás csak használatkor tölti be ezeket, miközben a nyilvános attribútumok továbbra is tesztelhetők maradnak. A javítások után mind a 16 892 nyílt forráskódú teszt sikeresen lefutott.
A másik négy javaslatot a Google fejlesztői elutasították. Ezek között volt olyan gyorsítótár, amely szintetikus benchmarkban 17 százalékos javulást mutatott, de elavult adatot adhatott volna vissza. Egy telemetriai módosítás privát OpenTelemetry-attribútumra támaszkodott, két további ötlet pedig összetettebb állapotkövetést vagy nehezebben olvasható kódot eredményezett, miközben a hétköznapi használatban nem hozott megfelelő nyereséget.
A fejlesztők ellenőrzése maradt a folyamat része
A Google beszámolója szerint a modell önálló munkája és a karbantartói kódreview együtt vezetett a végső változtatásokhoz. A csapat a két elfogadott optimalizálást egy 22 fájlt érintő módosításban egyesítette, amelyet 17 új tesztfüggvény támogatott. A változtatás végül bekerült az ADK fő ágába.
Az eredmény az ADK hosszú munkameneteiben körülbelül 40 százalékkal kisebb memóriabeli előkészítési idő, a hideg csomagimportoknál pedig 21 százalékkal rövidebb idő lett. A példa a Google szerint azt mutatja, hogy egy kódolóügynök hosszabb, felügyelet nélküli futásban is képes több modulon átívelő teljesítményproblémák feltárására, de a végső döntésekhez továbbra is szükség volt a projekt karbantartóinak ellenőrzésére.
Google for Developers: Optimizing a 200,000-line Python codebase overnight with Gemini 4 Argon- Google Developers Blog


