„Asana“ su „GPT‑6.1 Sol“ modelio sąnaudas sumažino 76 kartus
Pasitelkusi „GPT‑6 Astra“ „Codex“ aplinkoje, „Asana“ bandymuose padarė savo naršyklės agentą 76 kartus pigesnį ir 5 kartus greitesnį, kad galėtų siūlyti klientams pajėgesnius modelius.

76×
Mažesnės apskaičiuotosios modelio naudojimo sąnaudos taikant optimizuotą „GPT-6.1 Sol“ darbo eigą
5×
Greitesnis užduočių vykdymas naršyklėje taikant optimizuotą „GPT-6.1 Sol“ darbo eigą
0,47 USD
Vidutinės apskaičiuotosios modelio naudojimo sąnaudos taikant optimizuotą „GPT-6.1 Sol“ darbo eigą
Pasitelkusi „Codex“ aplinkoje veikiantį „GPT‑6 Astra“ eksperimentams atlikti, „Asana“ optimizavo savo naršyklės agento darbo eigą su „GPT‑6.1 Sol“: ji tapo 76 kartus pigesnė ir 5 kartus greitesnė.
„Asana“ padeda klientams automatizuoti darbą įvairiose verslo programose per įsigytą(atsidaro naujame lange) platformą „StackAI“(atsidaro naujame lange). Naudodamiesi „StackAI“, klientai gali nerašydami kodo kurti darbo eigas, kurios naršo svetaines, pildo formas ir renka informaciją. Dirbant „Asana“ mastu, net nedideli šių darbo eigų neefektyvumai sumuojasi.
„Asana“ platformos „StackAI“ technologijų vadovas dr. Frank Hidalgo užsibrėžė padaryti naršyklės agentą greitesnį ir pigesnį naudoti. Jis pavedė „Codex“ aplinkoje veikiančiam „GPT‑6 Astra“ išanalizuoti agentą, išbandyti patobulinimus ir palyginti rezultatus. Jo vertinimu, darbas, kurį atlikti rankiniu būdu būtų prireikę vieno ar dviejų mėnesių, užtruko apie savaitę.
Per „Asana“ tyrimą, apėmusį 144 vykdymus(atsidaro naujame lange), buvo išbandyti „GPT‑6.1 Sol“ ir trys kiti priešakiniai modeliai, čia vadinami modeliais A, B ir C. Gautos optimizuotos darbo eigos su „GPT‑6.1 Sol“ vieno vykdymo apskaičiuotosios modelio naudojimo sąnaudos vidutiniškai siekė 0,47 JAV dolerio, o trukmė – apie keturias minutes. Tai 76 kartus pigiau ir 5 kartus greičiau nei pradinė gamybinė konfigūracija su modeliu B.
„Taip žmonių ir agentų komandos atrodo praktiškai. Inžinierius nubrėžė kryptį, „GPT-6 Astra“ atliko eksperimentus, o jų rezultatai per „Command“ pasiekė gamybinę aplinką. Tai parodo, kaip „Asana“ įgyvendina žmonių ir agentų komandų idėją.“
Siekdamas greitai judėti į priekį, Hidalgo pirmiausia pasitelkė „GPT‑6 Astra“ „Codex“ aplinkoje, kad išnagrinėtų kodo bazę ir paaiškintų, kaip agentas sudaro kiekvieną užklausą modeliui. „GPT‑6 Astra“ nustatė, kad agentas talpykloje saugo pastovias instrukcijas ir įrankių aprašus, tačiau nesaugo vis augančios surinkto puslapių teksto ir ekrano nuotraukų istorijos. Todėl su kiekviena užklausa ši istorija buvo siunčiama iš naujo už visą kainą.
Be to, agentas beveik kiekviename žingsnyje šalino senesnes ekrano nuotraukas ir trumpino tekstą. Kiekvienas toks pakeitimas keitė istoriją, tad vien jos saugojimas talpykloje nebūtų padėjęs. Praradęs šiuos faktus, agentas galėjo būti priverstas grįžti į jau perskaitytus puslapius.
Hidalgo peržiūrėjo „GPT‑6 Astra“ pasiūlytus pataisymus ir pasirinko išbandyti tris:
Talpykloje saugoti ir agento naršymo istoriją
Padidinti išlaikomo teksto kiekį
Ekrano nuotraukas šalinti grupėmis, o ne kiekviename žingsnyje
„GPT‑6 Astra“ pradėjo nuo trumpų bandymų, kad nustatytų, kurie kintamieji turi reikšmės. Kadangi kodas nebuvo pritaikytas kontroliuojamiems eksperimentams, modelis pertvarkė jo struktūrą taip, kad viena naudotojo sąsaja ir serverio dalis galėtų lygiagrečiai vykdyti daug darbo eigų, kiekvieną su atskiromis nuostatomis.
„Astra“ atliko visą tyrimą: išbandė 120 000 ir 480 000 ženklų istorijos apimties ribas bei šešias talpyklos ir ekrano nuotraukų valdymo strategijas. Kiekvieną derinį išbandė po tris kartus su kiekvienu iš keturių modelių (žr. lentelę toliau). Geriausių rezultatų davusi strategija leido sukaupti 20 ekrano nuotraukų, o tada palikti tik naujausią. Taip ankstesnė istorija ilgiau išlikdavo nepakitusi tarp šalinimų. Ši strategija kartu su didesne istorijos apimties riba tapo optimizuota darbo eiga. Kiekviena konfigūracija atliko tą pačią užduotį: iš viešo demonstracinio katalogo surinko po šešis duomenų laukus apie kiekvieną iš 32 knygų. Tai atspindi užduotis, kurias kai kurie „Asana“ klientai vykdo „StackAI“ platformoje.
Modelis | Aprašas | Kaina |
|---|---|---|
Modelis A | Mažesnis, pigesnis kitos priešakinės laboratorijos modelis, išleistas 2025 m. rudenį | Pusė „GPT‑6.1 Sol“ kainos |
Modelis B | Iš pradžių gamybinėje aplinkoje naudotas modelis, sukurtas tos pačios laboratorijos kaip ir modelis A, išleistas 2026 m. vasarą | Tokia pati kaina kaip „GPT‑6.1 Sol“ |
Modelis C | Atnaujinta modelio B versija, išleista 2026 m. rudenį | Tokia pati kaina kaip „GPT‑6.1 Sol“ |
GPT‑6.1 Sol | „OpenAI“ modelis |
„GPT‑6 Astra“ vykdė darbo eigas ir nagrinėjo užklausas, naudojimo įrašus bei išvestis, o atskiruose modelio seansuose atliktas darbas buvo peržiūrėtas. Kiekvieno seanso užklausos, duomenų sekos ir rezultatai buvo užfiksuoti „Asana“ programinės įrangos pristatymo platformoje „Command“(atsidaro naujame lange), kad komanda vėliau galėtų peržiūrėti visą tyrimą. „Command“ platformoje tyrimo išvados buvo paverstos užduotimis, vėliau – kodo pakeitimų įtraukimo užklausomis, o pakeitimai įdiegti gamybinėje aplinkoje.
„Rankiniu būdu man tai būtų užtrukę vieną ar du mėnesius. Su „GPT-6 Astra“ „Codex“ aplinkoje tai užtruko apie savaitę: prieš eidamas miegoti nustatydavau tikslą komanda /goal, o ryte peržiūrėdavau rezultatus.“
Naudojant modelį B, optimizavimas sumažino apskaičiuotąsias modelio naudojimo sąnaudas nuo bent 36,21 JAV dolerio (kai kurie pradiniai vykdymai pasiekė žingsnių ribą dar nebaigę užduoties) iki 1,24 JAV dolerio už vykdymą – 29 kartus. Optimizuota darbo eiga su „GPT‑6.1 Sol“ buvo dar 2,6 karto pigesnė – kainavo 0,47 JAV dolerio. Per kiekvieną optimizuotos darbo eigos vykdymą užduotis buvo baigta ir pateiktas teisingas atsakymas.
3 vykdymų vidurkiai. ≥: į pradinės konfigūracijos rezultatus įtraukti ribą pasiekę vykdymai, todėl jos vidurkis yra apatinė riba.
Du dešinėje pateikti santykiai rodo palyginimą su optimizuota modelio B konfigūracija. Modelis B buvo testuotas 1 etape, o modelis C ir „Sol 6.1“ – to paties tyrimo 2 etape (punktūrinė linija).
Naudojant vien „GPT‑6.1 Sol“ su didesne istorijos apimties riba, naujoji talpyklos ir ekrano nuotraukų valdymo strategija sumažino vieno vykdymo sąnaudas 4 kartus – nuo 1,97 iki 0,47 JAV dolerio. Kiekvienas modelio iškvietimas buvo maždaug 3 kartus pigesnis, nes 89 % įvesties buvo gaunama iš talpyklos už 5 % talpykloje nesaugomos įvesties kainos. Sutrumpėjo ir vykdymo trukmė: pradinė konfigūracija su modeliu B užtrukdavo bent 22,5 minutės, o optimizuota darbo eiga su „GPT‑6.1 Sol“ – maždaug keturias minutes.
3 vykdymų vidurkis; paklaidos juostos rodo standartinį nuokrypį (SD). ≥: į vidurkį įtrauktas ribą pasiekęs arba nebaigtas vykdymas, todėl tikroji reikšmė yra bent tokio dydžio.
Stulpeliams naudojami mėlyni atspalviai. Talpyklos naudojimo poveikį vertinkite lygindami su didesnės, 480 tūkst. ženklų apimties ribos stulpeliu.
Vykdymų žymos ir standartinio nuokrypio paklaidos juostos apytiksliai atkurtos iš pradinio vaizdo; originalios vykdymų reikšmės ir standartiniai nuokrypiai nebuvo prieinami.
3 vykdymų vidurkis; paklaidos juostos rodo standartinį nuokrypį (SD). ≥: į vidurkį įtrauktas ribą pasiekęs arba nebaigtas vykdymas, todėl tikroji reikšmė yra bent tokio dydžio.
Stulpeliams naudojami mėlyni atspalviai. Talpyklos naudojimo poveikį vertinkite lygindami su didesnės, 480 tūkst. ženklų apimties ribos stulpeliu.
Vykdymų žymos ir standartinio nuokrypio paklaidos juostos apytiksliai atkurtos iš pradinio vaizdo; originalios vykdymų reikšmės ir standartiniai nuokrypiai nebuvo prieinami.
Tyrimas taip pat parodė, kaip istorijos valdymas lėmė, ar agentas apskritai pateikdavo atsakymą. Suteikus „GPT‑6.1 Sol“ daugiau vietos naršymo istorijai išlaikyti, vykdymų, per kuriuos pateiktas atsakymas, padaugėjo nuo trijų iš 18 taikant mažesnę istorijos apimties ribą iki visų 18 taikant didesnę ribą. Visi šie atsakymai buvo teisingi. Hidalgo požiūriu, vertė verslui – galimybė suteikti klientams prieigą prie greitesnių ir pajėgesnių modelių, išlaikant tvarias veiklos sąnaudas.
„Anksčiau sąnaudos ribojo tai, kuriuos modelius galėjome siūlyti klientams šioms užduotims atlikti. Padarę agentą efektyvesnį, galime suteikti klientams geresnį, greitesnį modelį ir kartu sumažinti savo veiklos sąnaudas.“
„Asana“ įdiegė naršymo pakeitimus „StackAI“ platformoje ir kuria įrankius, kurie leis lengviau kartoti panašius eksperimentus. Ilgainiui komanda planuoja įtraukti šiuos bandymus į platformos vertinimo procesus, kad klientai ir vidinės komandos, konfigūruodami savo agentus, galėtų palyginti sąnaudas, vykdymo trukmę ir atsakymų kokybę.
„Ribojantis veiksnys jau nebe išleidimo greitis, o žmonių dėmesys. Artėjame prie pasaulio, kuriame kiekvienas inžinierius yra produkto vadovas, vadovaujantis agentų būriui.“
Dabar „Asana“ naudoja „GPT‑6 Astra“ „Codex“ aplinkoje produkto funkcijoms testuoti prieš jas išleidžiant: „Astra“ naršo platformą, išbando skirtingas įvestis ir praneša apie klaidas kokybės užtikrinimo specialistams. Hidalgo tai laiko naujo programinės įrangos kūrimo gyvavimo ciklo pagrindu, kuriame daugybė debesijoje veikiančių agentų seansų lygiagrečiai testuoja funkcijas.
Visą tyrimą rasite „Asana“(atsidaro naujame lange) ir „StackAI“(atsidaro naujame lange) tinklaraščiuose.


