کاهش ۷۶ برابری هزینه مدل در Asana با GPT‑6.1 Sol

Asana با سپردن آزمایش‌ها به GPT‑6 Astra در Codex، گردش کار عامل مرورگر خود را روی GPT‑6.1 Sol بهینه کرد تا با یک‌هفتادوششم هزینه و ۵ برابر سریع‌تر اجرا شود.

Asana از طریق StackAI⁠(در یک پنجره جدید باز می‌شود)، پلتفرمی که آن را خریداری کرده است⁠(در یک پنجره جدید باز می‌شود)، به مشتریان کمک می‌کند کارها را در برنامه‌های کسب‌وکار خودکار کنند. مشتریان با StackAI می‌توانند بدون کدنویسی، گردش کارهایی بسازند که وب‌سایت‌ها را مرور می‌کنند، فرم‌ها را پر می‌کنند و اطلاعات گرد می‌آورند. در مقیاس فعالیت Asana، ناکارآمدی‌های کوچک این گردش کارها روی هم جمع می‌شوند.

دکتر فرانک هیدالگو، مدیر ارشد فناوری StackAI در Asana، تصمیم گرفت سرعت اجرای عامل مرورگر را افزایش و هزینه آن را کاهش دهد. او از GPT‑6 Astra در Codex خواست عامل را بررسی کند، بهبودها را بیازماید و نتایج را مقایسه کند. کاری که به برآورد او انجام دستی‌اش یک تا دو ماه زمان می‌برد، حدود یک هفته طول کشید.

مطالعه Asana با ۱۴۴ اجرا⁠(در یک پنجره جدید باز می‌شود)، GPT‑6.1 Sol و سه مدل پیشرو دیگر را آزمود که در اینجا مدل‌های A، B و C نامیده می‌شوند. گردش کار بهینه‌شده روی GPT‑6.1 Sol به‌طور میانگین در هر اجرا حدود چهار دقیقه زمان و ۰٫۴۷ دلار هزینه برآوردی مدل داشت؛ یعنی یک‌هفتادوششم هزینه و ۵ برابر سریع‌تر از پیکربندی اولیه محیط عملیاتی با مدل B.

هیدالگو برای پیشبرد سریع کار، ابتدا از GPT‑6 Astra در Codex استفاده کرد تا ساختار پایگاه کد را مشخص کند و توضیح دهد عامل چگونه هر درخواست ارسالی به مدل را می‌سازد. GPT‑6 Astra دریافت که عامل، دستورالعمل‌های ثابت و تعریف ابزارها را کش می‌کند، اما سابقه رو‌به‌رشد متن صفحات و تصاویر صفحه را نه؛ در نتیجه، این سابقه در هر درخواست دوباره با هزینه کامل ارسال می‌شد.

عامل همچنین تقریباً در هر گام، تصاویر قدیمی‌تر صفحه را حذف و متن را کوتاه می‌کرد. هر ویرایش، سابقه را تغییر می‌داد؛ پس کش کردن سابقه به‌تنهایی کمکی نمی‌کرد. از دست رفتن این اطلاعات نیز ممکن بود عامل را وادار کند به صفحاتی که قبلاً خوانده بود بازگردد.

هیدالگو اصلاحات پیشنهادی GPT‑6 Astra را بررسی کرد و سه مورد را برای آزمایش برگزید:

• گسترش کش به سابقه مرور عامل

• افزایش حجم متنی که عامل می‌توانست نگه دارد

• حذف دسته‌ای تصاویر صفحه به‌جای حذف در هر گام

GPT‑6 Astra با آزمایش‌های سریع شروع کرد تا متغیرهای مؤثر را شناسایی کند. ازآنجاکه کد برای آزمایش‌های کنترل‌شده طراحی نشده بود، سپس آن را بازآرایی کرد تا یک فرانت‌اند و بک‌اند بتواند از گردش کارهای متعدد، هرکدام با تنظیمات مستقل، به‌صورت موازی پشتیبانی کند.

Astra مطالعه کامل را انجام داد: ظرفیت‌های سابقه ۱۲۰٬۰۰۰ و ۴۸۰٬۰۰۰ نویسه‌ای و شش سیاست کش و تصاویر صفحه، که هرکدام سه بار روی هر یک از چهار مدل آزموده شدند (جدول زیر را ببینید). در سیاستی که بهترین عملکرد را داشت، تعداد تصاویر صفحه به ۲۰ می‌رسید و سپس فقط آخرین تصویر حفظ می‌شد. به این ترتیب، سابقه قبلی در فاصله بین حذف‌ها مدت بیشتری بدون تغییر می‌ماند. ترکیب این سیاست با ظرفیت بیشتر سابقه، گردش کار بهینه‌شده را شکل داد. همه پیکربندی‌ها یک کار یکسان انجام دادند: گردآوری شش فیلد اطلاعاتی برای هر یک از ۳۲ کتاب از یک فهرست آزمایشی عمومی؛ کاری مشابه آنچه برخی مشتریان Asana در StackAI اجرا می‌کنند.

GPT‑6 Astra گردش کارها را اجرا و درخواست‌ها، سوابق مصرف و خروجی‌ها را بررسی کرد؛ نشست‌های جداگانه مدل نیز کار را بازبینی کردند. درخواست‌ها، ردگیری داده‌ها و نتایج هر نشست در Command⁠(در یک پنجره جدید باز می‌شود)، پلتفرم تحویل نرم‌افزار Asana، ثبت شد تا تیم بتواند بعداً کل مطالعه را بازبینی کند. یافته‌ها در Command ابتدا به تیکت و سپس به درخواست ادغام کد تبدیل شدند و تغییرات به محیط عملیاتی راه یافتند.

برای مدل B، بهینه‌سازی هزینه برآوردی مدل را از حداقل ۳۶٫۲۱ دلار به ۱٫۲۴ دلار در هر اجرا رساند؛ یعنی یک‌بیست‌ونهم هزینه قبلی. برخی اجراهای اولیه پیش از اتمام به سقف تعداد گام‌ها رسیده بودند. گردش کار بهینه‌شده روی GPT‑6.1 Sol با هزینه ۰٫۴۷ دلار، باز هم ۲٫۶ برابر ارزان‌تر بود. در گردش کار بهینه‌شده، همه اجراها کار را تکمیل کردند و پاسخ درست دادند.

تنها روی GPT‑6.1 Sol، با ظرفیت بیشتر سابقه، سیاست جدید کش و تصاویر صفحه هزینه هر اجرا را به یک‌چهارم رساند: از ۱٫۹۷ دلار به ۰٫۴۷ دلار. هزینه هر فراخوانی حدود یک‌سوم شد، چون ۸۹٪ ورودی از کش تأمین می‌شد و هزینه‌اش ۵٪ قیمت ورودی کش‌نشده بود. اجراها سریع‌تر هم شدند: از حداقل ۲۲٫۵ دقیقه با پیکربندی اولیه مدل B به حدود چهار دقیقه با گردش کار بهینه‌شده روی GPT‑6.1 Sol.

این بررسی همچنین نشان داد مدیریت سابقه چگونه بر اینکه عامل اصلاً پاسخی تولید کند یا نه اثر می‌گذارد. با فراهم کردن فضای بیشتر برای حفظ سابقه مرور در GPT‑6.1 Sol، تعداد اجراهایی که پاسخ تولید کردند از ۳ مورد در ۱۸ اجرا با ظرفیت کمتر، به هر ۱۸ اجرا با ظرفیت بیشتر رسید؛ همه پاسخ‌ها نیز درست بودند. از نظر هیدالگو، ارزش تجاری این کار در آن است که مشتریان به مدل‌های سریع‌تر و توانمندتر دسترسی پیدا کنند و در عین حال هزینه‌های عملیاتی در سطحی قابل‌تداوم بماند.

Asana تغییرات مربوط به پیمایش با مرورگر را در StackAI منتشر کرده و در حال توسعه ابزارهایی است تا تکرار آزمایش‌های مشابه آسان‌تر شود. تیم قصد دارد به‌مرور این آزمون‌ها را در ارزیابی‌های پلتفرم بگنجاند تا مشتریان و تیم‌های داخلی هنگام پیکربندی عامل‌های خود، هزینه، زمان اجرا و کیفیت پاسخ را مقایسه کنند.

Asana اکنون از GPT‑6 Astra در Codex برای آزمودن قابلیت‌های محصول پیش از انتشار استفاده می‌کند: Astra در پلتفرم پیمایش می‌کند، ورودی‌های مختلف را می‌آزماید و اشکالات را به بازبینان انسانی تضمین کیفیت گزارش می‌دهد. هیدالگو این را پایه چرخه‌ای تازه برای توسعه نرم‌افزار می‌داند که در آن، نشست‌های متعدد عامل‌های ابری قابلیت‌ها را به‌صورت موازی می‌آزمایند.

مطالعه کامل در وبلاگ‌های Asana⁠(در یک پنجره جدید باز می‌شود) و StackAI⁠(در یک پنجره جدید باز می‌شود) در دسترس است.