Az Asana a GPT‑6 Astra in Codex segítségével feltérképezte és átalakította StackAI platformja böngészőügynökének munkafolyamatát, aminek eredményeként a tesztekben a GPT‑6.1 Sol alapú, optimalizált folyamat 76× olcsóbbá és körülbelül 5× gyorsabbá vált az eredeti üzembe helyezett beállításhoz képest.
Mi volt a cél és miért számít
Asana StackAI rendszere kód nélküli munkafolyamatokat biztosít, amelyek weboldalakat járnak be, űrlapokat töltenek ki és információkat gyűjtenek. Mivel a platformot ügyfelek nagy mennyiségben használják, a kisebb hatékonysági hiányosságok is jelentős költségnövekedést és lassulást okoznak. Frank Hidalgo, PhD, a StackAI CTO‑ja azt a feladatot adta a GPT‑6 Astra in Codexnak, hogy vizsgálja át az ügynököt, javasoljon javításokat és mérje azok hatását — a manuális munkával egy-két hónapot igénylő folyamatot így körülbelül egy hét alatt elvégezték.
A vizsgálat felépítése
A csapat 144 futtatásból álló kísérletsorozatot hajtott végre, amelyben a GPT‑6.1 Sol mellett három másik, a cikkben Model A, B és C néven említett frontier modellt teszteltek. A vizsgálat több változót vizsgált: két történet‑(history) költségvetést (120 000 és 480 000 karakter), valamint hat különböző gyorsítótár‑ és képernyőkép‑kezelési házirendet. Minden konfigurációt háromszor futtattak mind a négy modellen. A tesztek célja az volt, hogy egy nyilvános demókatalógusból 32 könyv hat mezőjét gyűjtsék össze — ez reprezentálja az olyan StackAI‑feladatokat, amelyeket ügyfelek futtathatnak.
Mit találtak és milyen változtatásokat vezettek be
A GPT‑6 Astra feltérképezte a kódot és megállapította, hogy az ügynök ugyan gyorsítótárazta a rögzített utasításokat és eszközdefiníciókat, de nem cache‑elte a folyamatosan növekvő böngészési előzményeket (oldalszövegek, képernyőképek). Ennek következménye az volt, hogy minden kérés újraküldte a teljes előzményt, ami jelentős költséget okozott. Emellett az ügynök a folyamatok során gyakran eltávolította korábbi képernyőképeket és több lépésben vágta a szövegeket; ezek a szerkesztések megváltoztatták az előzményt, ezért az egyszerű cache‑bevezetés önmagában nem oldotta volna meg a problémát.
Hidalgo a GPT‑6 Astra javaslatai közül három változtatást választott kísérletre:
- a böngészési előzmények gyorsítótárazásának kiterjesztése,
- a megtartható szöveg mennyiségének növelése (nagyobb history budget),
- a képernyőképek eltávolításának ütemezése: lépésenkénti törlés helyett kötegelt eltávolítás.
A legjobb eredményt az adta, hogy engedték a képernyőképek felgyülemlését 20 darabig, majd csak ekkor csökkentették a készletet az utolsó darabra; ezzel az előzmény hosszabb ideig változatlan maradt a törlések között. Ezt kombinálták a nagyobb, 480 000 karakteres history budgettel, és ez képezte az optimalizált munkafolyamatot.
Eredmények: költség és idő
A vizsgálat szerint az optimalizált munkafolyamat átlagosan 0,47 USD becsült modellköltséget és körülbelül négy percet igényelt futásonként a GPT‑6.1 Sol esetén. Ez 76× költségcsökkentést és körülbelül 5× gyorsulást jelent az eredeti, Model B‑n futó gyártásba állított beállításokhoz képest.
Konkrét példák a mérésből:
- Model B eredeti verzióján a becsült modellköltség legalább 36,21 USD/futás volt (néhány korábbi futás a lépéshatárig lefutott, így a szám alsó becslés), az optimalizálás után ez 1,24 USD/futásra csökkent — ez 29× megtakarítás.
- A GPT‑6.1 Sol optimalizált beállításánál a költség tovább csökkent 0,47 USD/futásra; egyetlen futás költsége mintegy 3× lett olcsóbb, mert a bemenet 89%-a cache‑ből érkezett, amely az uncached ár 5%-ával terhelt.
- Futási idők: az eredeti Model B‑s beállításon a futások legalább 22,5 percet vettek igénybe, míg az optimalizált GPT‑6.1 Sol munkafolyamat nagyjából négy perces futásidőt ért el.
Minden optimalizált futás befejezte a feladatot és helyes választ adott; a nagyobb history budget növelte annak valószínűségét is, hogy az ügynök egyáltalán választ ad: GPT‑6.1 Sol esetén a kisebb költségvetéssel 18 futásból csak 3 adott választ, míg a nagyobb költségvetéssel mind a 18 futás helyes választ adott.
Hogyan vitték be a változtatásokat
A GPT‑6 Astra nemcsak javasolt, hanem gyors, kísérleti futtatásokat is végzett, majd a kódot refaktorálták, hogy egy frontend és backend több párhuzamos munkafolyamatot tudjon kezelni különböző beállításokkal. Az összes kísérleti kérés, használati nyom és eredmény rögzítve lett a Command, Asana szoftverszállítási platformján; ezekből jegyek (tickets) és pull requestek készültek, majd a módosítások bekerültek a produkciós környezetbe.
Asana kiadta a böngészőnavigációs változtatásokat a StackAI‑ban és eszközök fejlesztésén dolgozik, hogy az ilyen kísérletek megismétlése egyszerűbb legyen. Hosszabb távon a csapat azt tervezi, hogy a tesztelést integrálja a platform értékeléseibe, hogy ügyfelek és belső csapatok össze tudják hasonlítani a költségeket, futási időt és válaszminőséget az ügynökök konfigurálásakor.
GPT‑6 Astra szerepe a termékfejlesztésben
Jelenleg az Asana GPT‑6 Astra in Codexet használja arra is, hogy a kiadások előtt termékfunkciókat teszteljen: Astra navigál a platformon, kipróbál különböző bemeneteket és hibajelentéseket készít emberi QA felülvizsgálók számára. Hidalgo szerint ez egy új szoftverfejlesztési életciklus alapját képezheti, ahol sok felhőügynök‑session párhuzamosan tesztel funkciókat.
Elérhetőség
A teljes tanulmány és részletes beszámoló az Asana és a StackAI blogjain jelent meg.
