Asana свива разходите 76 пъти с GPT‑6.1 Sol в браузърни тестове
С GPT‑6 Astra в Codex Asana направи браузърния си агент 76 пъти по-евтин и 5 пъти по-бърз в тестове, за да предложи на клиентите модели с повече възможности.
76 пъти
По-ниски прогнозни разходи за модела с оптимизирания работен процес с GPT-6.1 Sol
5 пъти
По-бързо изпълнение в браузъра с оптимизирания работен процес с GPT-6.1 Sol
0,47 щ.д.
Среден прогнозен разход за модела при оптимизирания работен процес с GPT-6.1 Sol
Чрез експерименти с GPT‑6 Astra в Codex Asana оптимизира работния процес на своя браузърен агент с GPT‑6.1 Sol, така че да работи 76 пъти по-евтино и 5 пъти по-бързо.
Asana помага на клиентите си да автоматизират работата в различни бизнес приложения чрез StackAI(отваря се в нов прозорец) — платформа, която компанията придоби(отваря се в нов прозорец). Със StackAI клиентите могат да създават работни процеси, които навигират в уебсайтове, попълват формуляри и събират информация, без да пишат код. При мащаба на Asana дори малките загуби на ефективност в тези процеси се натрупват.
Д-р Франк Идалго, технически директор на StackAI в Asana, си постави за цел да направи браузърния агент по-бърз и по-евтин за използване. Той възложи на GPT‑6 Astra в Codex да проучи агента, да тества подобрения и да сравни резултатите. Работата, която според него би отнела един-два месеца на ръка, приключи за около седмица.
В проучването на Asana със 144 изпълнения(отваря се в нов прозорец) бяха тествани GPT‑6.1 Sol и три други авангардни модела, наречени тук модели A, B и C. Полученият оптимизиран работен процес с GPT‑6.1 Sol постигна среден прогнозен разход за модела от 0,47 щ.д. и време от около четири минути на изпълнение — 76 пъти по-евтино и 5 пъти по-бързо от първоначалната конфигурация с модел B в работната среда.
„Ето как изглеждат на практика екипите от хора и агенти. Инженер зададе посоката, GPT-6 Astra проведе експериментите, а резултатите преминаха през Command и бяха внедрени в работната среда. Това показва как Asana превръща екипите от хора и агенти в реалност.“
За да напредне бързо, Идалго първо използва GPT‑6 Astra в Codex, за да проучи структурата на кодовата база и да обясни как агентът изгражда всяка заявка към модела. GPT‑6 Astra откри, че агентът кешира постоянните си инструкции и дефинициите на инструментите, но не и нарастващата история от събран текст и екранни снимки на страниците. Така всяка заявка изпращаше отново тази история на пълната цена.
Агентът също така премахваше по-старите екранни снимки и съкращаваше текста на почти всяка стъпка. Всяка редакция променяше историята, затова само кеширането ѝ нямаше да помогне. А загубата на тези факти можеше да наложи агентът да се върне към вече прочетени страници.
Идалго прегледа предложените от GPT‑6 Astra решения и избра три за тестване:
Разширяване на кеширането, така че да обхваща историята на сърфиране на агента
Увеличаване на количеството текст, което агентът може да запазва
Премахване на екранните снимки на групи, вместо на всяка стъпка
GPT‑6 Astra започна с бързи тестове, за да установи кои променливи имат значение. Тъй като кодът не беше проектиран за контролирани експерименти, моделът го преструктурира, така че един фронтенд и един бекенд да поддържат паралелно множество работни процеси, всеки със собствени настройки.
Astra проведе цялото проучване: лимити за историята от 120 000 и 480 000 знака и шест стратегии за кеширане и екранни снимки, всяка тествана по три пъти с всеки от четирите модела (вижте таблицата по-долу). Най-успешната стратегия позволяваше да се натрупат 20 екранни снимки, след което оставяше само най-новата. Така по-ранната история оставаше непроменена за по-дълги периоди между премахванията. В съчетание с по-големия лимит за историята тази стратегия оформи оптимизирания работен процес. Всяка конфигурация изпълняваше една и съща задача: събиране на шест полета за всяка от 32 книги от публичен демонстрационен каталог — типична задача за някои клиенти на Asana, използващи StackAI.
Модел | Описание | Цена |
|---|---|---|
Модел A | По-малък и по-евтин модел от друга лаборатория за авангарден ИИ, пуснат през есента на 2025 г. | Наполовина по-евтин от GPT‑6.1 Sol |
Модел B | Моделът, използван първоначално в работната среда, от същата лаборатория като модел A, пуснат през лятото на 2026 г. | На същата цена като GPT‑6.1 Sol |
Модел C | Обновена версия на модел B, пусната през есента на 2026 г. | На същата цена като GPT‑6.1 Sol |
GPT‑6.1 Sol | Моделът на OpenAI |
GPT‑6 Astra изпълни работните процеси и анализира заявките, отчетите за потреблението и резултатите, а отделни сесии на модела провериха работата. Заявките, записите на данни и резултатите от всяка сесия бяха съхранени в Command(отваря се в нов прозорец), платформата на Asana за доставка на софтуер, за да може екипът да прегледа цялото проучване след това. В Command констатациите бяха превърнати в задачи, после в заявки за сливане на код, а промените бяха внедрени в работната среда.
„Това щеше да ми отнеме един-два месеца на ръка. С GPT-6 Astra в Codex отне около седмица: задавах /goal, преди да си легна, и преглеждах резултатите на сутринта.“
При модел B оптимизацията намали прогнозния разход за модела от поне 36,21 щ.д. (някои първоначални изпълнения достигнаха лимита на стъпките, преди да завършат) до 1,24 щ.д. на изпълнение — спад от 29 пъти. Оптимизираният работен процес с GPT‑6.1 Sol беше още 2,6 пъти по-евтин — 0,47 щ.д. Всяко изпълнение на оптимизирания работен процес завърши задачата и върна правилния отговор.
Средни стойности от 3 изпълнения. ≥: базовата конфигурация включва изпълнения, спрени поради лимит, затова средната ѝ стойност е долна граница.
Двата коефициента вдясно показват сравнение с оптимизирания модел B. Модел B беше тестван във фаза 1, а модел C и Sol 6.1 — във фаза 2 на същото проучване (пунктирана линия).
Само при GPT‑6.1 Sol, с по-големия лимит за историята, новата стратегия за кеширане и екранни снимки намали разхода 4 пъти — от 1,97 до 0,47 щ.д. на изпълнение. Всяко извикване беше около 3 пъти по-евтино, тъй като 89% от входните данни идваха от кеша на 5% от цената за некеширани данни. Изпълненията станаха и по-бързи: от поне 22,5 минути при първоначалната конфигурация с модел B до около четири минути с оптимизирания работен процес с GPT‑6.1 Sol.
Средна стойност от 3 изпълнения; отсечките показват стандартното отклонение. ≥: средната стойност включва изпълнение, спряно поради лимит или незавършено, затова действителната стойност е поне толкова голяма.
Стълбовете са в синя цветова гама. Сравнявайте ефектите от кеширането спрямо стълба за по-големия лимит от 480 хил.
Маркерите за изпълненията и отсечките за стандартното отклонение са възстановени приблизително от изходното изображение; оригиналните стойности за изпълненията и стандартните отклонения не бяха налични.
Средна стойност от 3 изпълнения; отсечките показват стандартното отклонение. ≥: средната стойност включва изпълнение, спряно поради лимит или незавършено, затова действителната стойност е поне толкова голяма.
Стълбовете са в синя цветова гама. Сравнявайте ефектите от кеширането спрямо стълба за по-големия лимит от 480 хил.
Маркерите за изпълненията и отсечките за стандартното отклонение са възстановени приблизително от изходното изображение; оригиналните стойности за изпълненията и стандартните отклонения не бяха налични.
Проучването показа също как управлението на историята влияе върху това дали агентът изобщо дава отговор. Когато GPT‑6.1 Sol получи повече място за историята си на сърфиране, броят изпълнения, завършили с отговор, нарасна от три от 18 при по-малкия лимит до всичките 18 при по-големия — всяко с правилния отговор. За Идалго бизнес ползата е в това клиентите да получат достъп до по-бързи модели с повече възможности, а оперативните разходи да останат устойчиви.
„Преди разходите ограничаваха избора на модели, които можехме да предложим на клиентите за тези задачи. Като повишаваме ефективността на агента, можем да дадем на клиентите по-добър и по-бърз модел, като същевременно намалим оперативните си разходи.“
Asana вече внедри промените в браузърната навигация в StackAI и разработва инструменти, с които подобни експерименти да се повтарят по-лесно. С времето екипът планира да включи тези тестове в оценяването на платформата, за да могат клиентите и вътрешните екипи да сравняват разходите, времето за изпълнение и качеството на отговорите, когато конфигурират своите агенти.
„Вече не скоростта на внедряване ни ограничава, а човешкото внимание. Близо сме до свят, в който всеки инженер е продуктов мениджър, ръководещ цял екип от агенти.“
Asana вече използва GPT‑6 Astra в Codex за тестване на продуктови функции преди пускането им: Astra навигира в платформата, изпробва различни входни данни и докладва грешки на специалистите по осигуряване на качеството. Идалго вижда в това основата за нов жизнен цикъл на разработка на софтуер, при който множество сесии на облачни агенти тестват функции паралелно.
Пълното проучване е достъпно в блоговете на Asana(отваря се в нов прозорец) и StackAI(отваря се в нов прозорец).
