Asana تخفض كلفة النماذج إلى 1/76 في تجارب المتصفح مع GPT‑6.1 Sol
باستخدام GPT‑6 Astra في Codex، خفّضت Asana تكلفة وكيل المتصفح إلى 1/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، فانخفضت تكلفة تشغيله إلى 1/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 دولار، واستغرق التشغيل الواحد نحو أربع دقائق؛ أي بتكلفة تعادل 1/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 دولار لكل تشغيل، أي إلى نحو 1/29 من التكلفة. ومع سير العمل المحسّن على GPT‑6.1 Sol، انخفضت التكلفة أكثر لتبلغ 0.47 دولار، أي ما يعادل نحو 1/2.6 من المبلغ السابق. أكملت كل عملية تشغيل ضمن سير العمل المحسّن المهمة وأعادت الإجابة الصحيحة.
متوسطات 3 عمليات تشغيل. ≥: يشمل خط الأساس عمليات تشغيل بلغت الحد الأقصى، لذا يمثّل متوسطه حدًا أدنى.
يمثّل معاملا التحسّن على اليمين مقارنةً بالنموذج B بعد التحسين. شُغّل النموذج B في المرحلة 1، والنموذجان C وSol 6.1 في المرحلة 2 من الدراسة نفسها (الخط المنقّط).
وعلى GPT‑6.1 Sol وحده، مع السعة الأكبر للسجل، خفّضت السياسة الجديدة للتخزين المؤقت ولقطات الشاشة التكلفة إلى الربع، من 1.97 دولار إلى 0.47 دولار لكل تشغيل. انخفضت تكلفة كل استدعاء إلى نحو الثلث، لأن 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(يفتح في نافذة جديدة).
