قصة GPT-6.1 Sol من DevRev هي في الحقيقة قصة عن المواضع التي لا يوجد فيها GPT-6 Astra.

نشرت OpenAI هذا الأسبوع قصة عميل بعنوان "DevRev تقدّم خدمة ذاتية مستقلة باستخدام GPT-6.1 Sol"، والجملة الأكثر إفادة فيها لا تتعلق بـ GPT-6.1 Sol إطلاقًا. إنها الجملة التي يُقال فيها إن مهندسي مبيعات DevRev يستخدمون GPT-6 Astra لبناء عروض توضيحية لأجنحة المؤتمرات. يصف أحمد بشير، المدير التنفيذي للتقنية في DevRev، شركةً قسّمت منظومة نماذجها إلى قسمين: النموذج المتوسط يضطلع بمسار دعم الإنتاج، والنموذج المتطور يضطلع بالشيء الذي ينظر إليه العميل المحتمل لمدة تسعين ثانية. وهذا دليل أنفع من أي معيار أداء في المنشور، لأنه قرار نشر اتخذه شخص عليه فاتورة يدفعها.

توقيت الأمر مهم. طُرحت GPT-6.1 Sol في 29 سبتمبر 2026 خلال DevDay، بعد أسبوع من GPT-6 Sol، بسعر 2.00 دولار لكل مليون رمز إدخال و10.00 دولارات لكل مليون رمز إخراج. ويحمل المقال الذي كتبته DevRev بنفسها عن شراكة OpenAI ختم تحديث بتاريخ 2 نوفمبر 2026، وقصة العميل هي المرة الأولى التي تضع فيها خدمة إنتاجية مسمّاة النموذج المتوسط، لا النموذج الرائد، على المسار المواجه للعملاء. إنه ليس إطلاقًا. إنه أول مرجع عمل.

ما الذي تشغّله DevRev فعليًا

تبني DevRev منتجين على الركيزة نفسها. Computer هو رفيق الذكاء الاصطناعي الذي يجيب ويتصرف عبر بيانات الأعمال؛ أما Operator فهو الوكيل الذي ينفّذ إجراءً معتمدًا أو يوجّه طلبًا إلى الشخص المناسب. ويحتاج كلاهما إلى الأشياء الثلاثة نفسها قبل السماح لأي نموذج بالاقتراب من العميل: سياق الشركة، وأذونات تطابق دور الشخص، وإجراءات قابلة للتراجع. يوفّر النموذج الاستدلال والتخطيط واختيار الأدوات. ويوفّر إطار تشغيل DevRev الباقي، وAgent Studio هو المكان الذي يصف فيه العميل، عبر المحادثة، كيف ينبغي أن تتصرف الأداة، ثم يثبّت الأجزاء التي يجب ألا تتغيّر بقواعد ثابتة.

ثمة خاصيتان في القصة تستحقان أكثر من الثناء: الإجراءات قابلة للتراجع، والإجابات تستشهد بمصادرها. وهذان هما نمطا الفشل اللذان يمنعان المؤسسات من السماح لوكيل بإغلاق تذكرة، وتزعم DevRev أن كليهما سلوك منتج لا سلوك نموذج. وإذا كنت تقيّم أي وكيل خدمة ذاتية، فهذه هي الأسئلة التي يجب طرحها، ولا توجد لوحة صدارة تجيب عنها.

الرقم الذي سيُرفق بهذه القصة يعود إلى يوليو، وهو لا يخص Sol

ابحث عن التغطية الإعلامية لـ DevRev وOpenAI وستجد زوجًا لافتًا من الأرقام: دقة أعلى بنسبة 48%، وعدد رموز أقل بمقدار 4.4 مرة لكل استجابة صحيحة. إنها أرقام حقيقية، وقد نُشرت، ولا علاقة لها بـ GPT-6.1 Sol.

تأتي تلك الأرقام من إصدار صادر في 9 يوليو 2026 يعلن عن Enterprise-Bench، وهو معيار مفتوح لوكلاء المؤسسات بناه DevRev بالتعاون مع Laude Institute ونُشر على Harbor harness. في تلك المقارنة، سجّل Computer من DevRev نسبة 94.3% مقابل 63.6% على مجموعة بيانات XL، واستخدم نحو 5,598 رمزًا لكل استجابة صحيحة مقابل 24,461. كانت المقارنة صراحةً بين أداة اختبار وأداة اختبار، مع تشغيل كلا النظامين للنموذج الأساسي نفسه. وأرجعت DevRev الفجوة إلى بنيتها للاسترجاع والذاكرة المشتركة، لا إلى النموذج الأساسي. كما جرى قياس أدائه مقابل Claude Code، وليس مقابل أي شيء أطلقته OpenAI في سبتمبر.

تذكر قصة عميل OpenAI معيار Enterprise-Bench، ويقول Bashir إن GPT-6.1 Sol يؤدي أداءً جيدًا عليه. هذا تصريح نوعي. لا تُقدَّم أي درجة، ولا شريحة من مجموعة البيانات، ولا مقارنة. أي شخص يلصق أرقام يوليو على قصة نوفمبر فهو يقيس شيئًا مختلفًا على نموذج مختلف في ربع مختلف. القراءة الصادقة أضيق نطاقًا لكنها لا تزال مثيرة للاهتمام: لدى DevRev معيار بنته لهذا القرار تحديدًا، وقد امتنعت عن نشر صف Sol عليه.

ما لا تقوله القصة

لا يوجد معدل حل، ولا حجم تذاكر، ولا نسبة مئوية لزمن الاستجابة، ولا عدد رموز، ولا سعر في منشور OpenAI. بالنسبة لقصة عميل عن الخدمة الذاتية المستقلة، هذا يعني غياب لوحة النتائج بأكملها.

أقرب رقم منشور هو إثبات المفهوم BILL من DevRev، حيث أفادت BILL بمعدل حل بالذكاء الاصطناعي بنسبة 70% على استفسارات عملاء حقيقية باستخدام تقييمها الخاص. تذكر مواد DevRev أيضًا انخفاضًا بنسبة 77% في الرموز (tokens)، وانخفاضًا من نحو تسع دقائق إلى نحو 1.5 دقيقة في الأسئلة متعددة الخطوات، قياسًا على نهجها السابق الخاص. هذه أرقام أفصح عنها المورّد ولم يُعَد إنتاجها، ولا يرتبط أي منها بجيل النموذج المستخدم الآن في الإنتاج. تعامل معها على أنها شكل الادعاء، لا حجمه.

قيد بشير نفسه هو ما ينبغي التمسك به: «هذه الأشياء يجب أن تكون قادرة على العمل وإكمال نفسها في ثوانٍ، لا دقائق». تفاعل دعم يستغرق عشرين دقيقة من الاستدلال ليس خدمة ذاتية، مهما كانت درجته. تلك الجملة تفسّر اختيار النموذج أفضل من أي جدول معايير.

الحساب الذي يستطيع مكتب الدعم التحقق منه

خذ تذكرة روتينية: 20,000 رمز إدخال من السياق المسترجَع، و2,000 رمز إخراج بما في ذلك الاستدلال. وفق سعر القائمة لدى GPT-6.1 Sol، يمثل ذلك 0.04 دولار من الإدخال و0.02 دولار من الإخراج، أي نحو ستة سنتات. والطلب نفسه على GPT-6 Astra، بسعر 10.00 دولارات للإدخال و50.00 دولاراً للإخراج، يكلف 0.20 دولار زائد 0.10 دولار، أي نحو ثلاثين سنتاً. المهمة نفسها، لكن الفاتورة خمسة أضعاف.

ستة سنتات حدّ أدنى لا توقع. تُحتسب رموز الاستدلال ضمن المخرجات، وتُحتسب إعادة المحاولات مرتين، وأي حلقة أدوات تضاعف الأمرين معًا. لكن النسبة هي المقصد، وهي تصمد أمام التحفظات الثلاثة جميعًا. أرقام التكلفة التي أبلغ عنها المورّد من OpenAI نفسها تشير في الاتجاه ذاته: في Terminal-Bench Science 0.1، قدّرت OpenAI تكلفة GPT-6.1 Sol عند 5.47 دولار لكل مهمة مقابل 23.80 دولارًا لـ GPT-6 Astra و23.21 دولارًا لـ Claude Opus 5.5، مع تسجيل Sol نسبة 57.02% بأقصى جهد مقابل 68.1% لـ Astra. أنت تشتري إحدى عشرة نقطة من القدرة مقابل أربعة أمثال المال، وفي طابور دعم تكون النقطة الحادية عشرة عادةً إعادة صياغة أفضل، لا تذكرة محلولة.

هذا هو الحساب الذي يقوم عليه نموذج تسعير OrcaRouter: سعر القائمة من المزوّد يُمرَّر دون أي هامش ربح، لذا فإن سعرًا مثل $2.00 و$10.00 هو الرقم الذي تدفعه، ويصل تغيّر سعر المورّد في اليوم نفسه بدلًا من تجديد العقد التالي. كلا النموذجين خلف مفتاح واحد، ما يعني أن التقسيم الذي أجرته DevRev في بنيتها — نموذج رخيص على مسار الحجم، ونموذج مكلف حيث تكون الإجابة هي المنتج — هو قرار توجيه لا عملية شراء ثانية. وفي الخطوات التي يكون فيها استدعاء أداة خاطئ مكلفًا، فإن التحويل الاحتياطي إلى نموذج أقوى على أساس كل طلب هو الفرق بين بعد ظهيرة سيئة وأسبوع سيئ.

لماذا يحصل النموذج المتوسط المستوى على مسار الإنتاج

الغريزة تقود إلى قراءة هذا كقصة تكلفة. وهو في جزء منه قصة زمن استجابة. يعمل GPT-6.1 Sol مع تشغيل الاستدلال دائمًا عبر خمسة مستويات جهد، من low إلى max، ويُضبط افتراضيًا على medium، ولا يقبل temperature أو top_p على الإطلاق. وهذا يزيل مقبض الضبط الذي تلجأ إليه معظم الفرق عندما يبدو الوكيل بطيئًا، ويترك مستوى الجهد بوصفه صمام التحكم. بين low وmax، يُقاس الفرق في زمن الوصول إلى أول توكن إجابة بالدقائق، لا بالمللي ثانية.

الأرقام المستقلة تأتي حيث تتوقعها لطراز في هذه الفئة. على مقياس Artificial Analysis Intelligence Index v5.0.1، يسجل GPT-6.1 Sol درجة 55 عند أقصى جهد، وبسرعة 56 رمزًا في الثانية، وبتكلفة 1.27 دولار لكل مهمة مؤشر مكتملة، و63.7 مليون رمز إخراج على مدار التشغيل. وفي بيانات القياس عن بُعد الخاصة بنا على مدى سبعة أيام، يُظهر زمنًا وسيطًا يبلغ 937 مللي ثانية للوصول إلى أول رمز، ومعدل خطأ 5.7%، وإخراجًا بسرعة 39.5 رمزًا في الثانية، وهو نوع الملف الذي يمكن بناء تدفق دعم عليه: ليس أسرع طراز متاح، لكنه متوقع بما يكفي بحيث يمكن تحجيم قائمة انتظار حوله.

نافذة السياق هي النصف الآخر من الخيار. فعند 1,050,000 رمز مع سقف إخراج يبلغ 128,000 رمز، يتسع طلب واحد لملف القضية وسجله والمعرفة المسترجعة كلها. وهذا ما يجعل وكيلًا يستدل «عبر بيانات حية» ممكنًا دون طبقة تقسيم معقدة — وهو الجزء من ورقة المواصفات الذي يعتمد عليه فعليًا معدل حل بنسبة 70%.

ما الذي سيحوّل هذا إلى دراسة حالة؟

ثلاثة أشياء ستنقل هذا من شعار على صفحة إلى دليل يمكن التخطيط بناءً عليه. معدل حل منشور لـ Operator، على مجموعة بيانات محددة بالاسم، مع معدل التصعيد البشري بجانبه. توزيع زمن الكمون بدلاً من متوسط، لأن p95 هو حيث تتعطل الخدمة الذاتية. واختبار استئصال Sol مقابل Astra على Enterprise-Bench، لأن DevRev تمتلك بالفعل أداة الاختبار وقد أظهرت بالفعل أنها ستنشر النتائج عندما تكون لصالح معماريتها.

يشير بشير إلى شيئين يريدهما تاليًا: Decisions API، من أجل الأحكام الصغيرة التي يصعب ترميزها كقواعد لكنها لا تحتاج إلى استدلال عميق، وUltrafast، طبقة السرعة 6× من OpenAI بسعر 12.00 دولارًا للإدخال و60.00 دولارًا للإخراج لكل مليون رمز، والمتاحة للشراء منذ 8 أكتوبر. كلاهما محاولتان لشراء زمن استجابة أقل دون شراء ذكاء، وهو الحدس الصحيح لقائمة انتظار الدعم وعكس ما تسعى إليه معظم خرائط طريق الوكلاء.

النمط الذي ينبغي مراقبته ليس DevRev تحديدًا، بل هو أن أول نشر إنتاجي مسمّى لـ GPT-6.1 Sol وضع النموذج الرخيص حيث يوجد العملاء والنموذج المكلف حيث يوجد العملاء المحتملون. وإذا أصبح ذلك هو الشكل المعتاد لمكدس وكلاء المؤسسات — نموذج عملي على المسار عالي الحجم، ونموذج رائد للعرض التجريبي — فإن السؤال المثير للاهتمام لكل مورّد يتوقف عن كونه أي نموذج هو الأذكى، ويبدأ في كونه مدى نظافة نقل الطلب بينهما.