Asana-ն GPT‑6.1 Sol-ով ծախսերը կրճատում է 76 անգամ

Codex-ում GPT‑6 Astra-ի կատարած փորձերով Asana-ն օպտիմալացրեց GPT‑6.1 Sol-ով աշխատող իր բրաուզերային ագենտի աշխատանքային հոսքը՝ այն դարձնելով 76 անգամ էժան և 5 անգամ արագ։

Asana-ն օգնում է հաճախորդներին ավտոմատացնել աշխատանքը բիզնես հավելվածներում իր ձեռք բերած⁠(բացվում է նոր պատուհանում) StackAI⁠(բացվում է նոր պատուհանում) հարթակի միջոցով։ StackAI-ով հաճախորդները կարող են առանց կոդ գրելու ստեղծել աշխատանքային հոսքեր, որոնք շրջում են կայքերում, լրացնում ձևեր և տեղեկություններ հավաքում։ Asana-ի մասշտաբներում այս հոսքերի նույնիսկ փոքր անարդյունավետությունները կուտակվում են։

Asana-ի StackAI-ի տեխնոլոգիաների տնօրեն, գիտական աստիճան ունեցող Ֆրենկ Իդալգոն նպատակ դրեց արագացնել բրաուզերային ագենտը և նվազեցնել դրա գործարկման ծախսը։ Նա Codex-ում GPT‑6 Astra-ին հանձնարարեց ուսումնասիրել ագենտը, փորձարկել բարելավումներ և համեմատել արդյունքները։ Աշխատանքը տևեց մոտ մեկ շաբաթ, մինչդեռ, ըստ նրա գնահատման, ձեռքով անելու դեպքում կպահանջվեր մեկից երկու ամիս։

Asana-ի՝ 144 գործարկում ընդգրկող հետազոտությամբ⁠(բացվում է նոր պատուհանում) փորձարկվեցին GPT‑6.1 Sol-ը և երեք այլ առաջադեմ մոդելներ, որոնք այստեղ կոչվում են A, B և C։ GPT‑6.1 Sol-ով ստացված օպտիմալացված հոսքում մոդելի գնահատված ծախսը միջինում $0,47 էր, իսկ տևողությունը՝ մոտ չորս րոպե մեկ գործարկման համար. 76 անգամ էժան և 5 անգամ արագ՝ B մոդելի սկզբնական աշխատանքային կազմաձևի համեմատ։

Արագ առաջ գնալու համար Իդալգոն նախ Codex-ում GPT‑6 Astra-ին հանձնարարեց ուսումնասիրել կոդային բազայի կառուցվածքը և բացատրել, թե ագենտն ինչպես է կազմում մոդելին ուղղված յուրաքանչյուր հարցում։ GPT‑6 Astra-ն պարզեց, որ ագենտը քեշավորում էր իր անփոփոխ հրահանգներն ու գործիքների սահմանումները, բայց ոչ հավաքած էջերի տեքստի ու էկրանակադրերի աճող պատմությունը։ Ուստի ամեն հարցմամբ այդ պատմությունը կրկին ուղարկվում էր ամբողջ գնով։

Ագենտը նաև գրեթե ամեն քայլում հեռացնում էր հին էկրանակադրերը և կրճատում տեքստը։ Ամեն խմբագրում փոխում էր պատմությունը, ուստի միայն դրա քեշավորումը չէր օգնի։ Իսկ այդ տեղեկությունների կորուստը կարող էր ստիպել ագենտին կրկին այցելել արդեն կարդացած էջերը։

Իդալգոն վերանայեց GPT‑6 Astra-ի առաջարկած ուղղումները և ընտրեց երեքը՝ փորձարկելու համար․

• Քեշավորել նաև ագենտի զննարկման պատմությունը

• Մեծացնել պահպանվող տեքստի ծավալը

• Էկրանակադրերը հեռացնել խմբերով, ոչ թե ամեն քայլում

GPT‑6 Astra-ն սկսեց արագ փորձարկումներից՝ պարզելու, թե որ փոփոխականներն են կարևոր։ Քանի որ կոդը նախատեսված չէր վերահսկվող փորձերի համար, այն վերակառուցեց կոդը, որպեսզի մեկ հաճախորդային և սերվերային մասով հնարավոր լիներ զուգահեռ գործարկել բազմաթիվ հոսքեր՝ յուրաքանչյուրն իր կարգավորումներով։

Astra-ն կատարեց ամբողջ հետազոտությունը՝ պատմության 120 000 և 480 000 նիշ ծավալներով և քեշավորման ու էկրանակադրերի վեց կանոնակարգով։ Յուրաքանչյուր համադրություն փորձարկվեց երեք անգամ՝ չորս մոդելներից յուրաքանչյուրով (տե՛ս ստորև բերված աղյուսակը)։ Լավագույն արդյունք տված կանոնակարգը թույլ էր տալիս կուտակել մինչև 20 էկրանակադր, ապա թողնում էր միայն ամենավերջինը։ Այսպես հեռացումների միջև ավելի երկար ժամանակ պահպանվում էր պատմության նախորդ մասի անփոփոխությունը։ Պատմության ավելի մեծ ծավալի հետ համադրվելով՝ սա դարձավ օպտիմալացված աշխատանքային հոսքը։ Ամեն կազմաձև կատարում էր նույն առաջադրանքը՝ հանրային ցուցադրական կատալոգից հավաքում էր 32 գրքերից յուրաքանչյուրի վեց դաշտի տվյալները։ Սա բնորոշ է StackAI-ում Asana-ի որոշ հաճախորդների կատարած աշխատանքին։

GPT‑6 Astra-ն գործարկեց հոսքերը, ուսումնասիրեց հարցումները, օգտագործման գրանցումներն ու ելքային տվյալները, իսկ մոդելի առանձին նստաշրջաններում ստուգվեց կատարված աշխատանքը։ Ամեն նստաշրջանի հարցումները, տվյալների հետագծերն ու արդյունքները գրանցվեցին Asana-ի ծրագրային ապահովման թողարկման Command⁠(բացվում է նոր պատուհանում) հարթակում, որպեսզի թիմը հետո կարողանար վերանայել ամբողջ հետազոտությունը։ Command-ում բացահայտումները դարձան առաջադրանքներ, ապա՝ կոդի միավորման հարցումներ, իսկ փոփոխությունները ներդրվեցին աշխատանքային միջավայրում։

B մոդելի դեպքում օպտիմալացումը գնահատված ծախսը մեկ գործարկման համար առնվազն $36,21-ից իջեցրեց $1,24-ի՝ 29 անգամ։ Սկզբնական որոշ գործարկումներ մինչև ավարտը հասնում էին քայլերի սահմանաչափին։ GPT‑6.1 Sol-ով օպտիմալացված հոսքն էլ ավելի էժան էր՝ 2,6 անգամ, և արժեր $0,47։ Օպտիմալացված հոսքի բոլոր գործարկումներն ավարտեցին առաջադրանքը և տվեցին ճիշտ պատասխանը։

Միայն GPT‑6.1 Sol-ի դեպքում, պատմության ավելի մեծ ծավալով, քեշավորման ու էկրանակադրերի նոր կանոնակարգը ծախսը նվազեցրեց 4 անգամ՝ մեկ գործարկման համար $1,97-ից մինչև $0,47։ Յուրաքանչյուր կանչը մոտ 3 անգամ էժան էր, քանի որ մուտքային տվյալների 89%-ը գալիս էր քեշից՝ չքեշավորված տվյալների գնի 5%-ով։ Գործարկումները նաև արագացան․ B մոդելի սկզբնական կազմաձևով՝ առնվազն 22,5 րոպե, GPT‑6.1 Sol-ի օպտիմալացված հոսքով՝ մոտ չորս րոպե։

Հետազոտությունը նաև ցույց տվեց, թե պատմության կառավարումն ինչպես էր ազդում ընդհանրապես պատասխան ստանալու վրա։ GPT‑6.1 Sol-ին զննարկման պատմությունը պահելու ավելի մեծ ծավալ հատկացնելով՝ պատասխան տվող գործարկումների թիվը 18-ից երեքից հասավ բոլոր 18-ին, ընդ որում՝ բոլոր պատասխանները ճիշտ էին։ Իդալգոյի համար բիզնես արժեքը հաճախորդներին ավելի արագ ու կարող մոդելներ տրամադրելն է՝ միաժամանակ գործառնական ծախսերը պահելով ընդունելի մակարդակի վրա։

Asana-ն StackAI-ում արդեն ներդրել է բրաուզերով նավարկման փոփոխությունները և մշակում է գործիքներ՝ նման փորձերի կրկնությունը հեշտացնելու համար։ Թիմը նախատեսում է հետագայում այս փորձարկումները ներառել հարթակի գնահատումներում, որպեսզի հաճախորդներն ու ներքին թիմերը ագենտները կարգավորելիս կարողանան համեմատել ծախսը, գործարկման տևողությունն ու պատասխանի որակը։

Այժմ Asana-ն Codex-ում GPT‑6 Astra-ով փորձարկում է արտադրանքի գործառույթները նախքան թողարկումը․ Astra-ն շրջում է հարթակում, փորձում տարբեր մուտքային տվյալներ և սխալների մասին հաղորդում որակի ստուգման մասնագետներին։ Իդալգոն սա համարում է ծրագրային մշակման նոր կենսափուլի հիմք, որտեղ ագենտների բազմաթիվ ամպային նստաշրջաններ զուգահեռ փորձարկում են գործառույթները։

Հետազոտությունն ամբողջությամբ հասանելի է Asana⁠(բացվում է նոր պատուհանում) և StackAI⁠(բացվում է նոր պատուհանում) բլոգներում։