مشكلة «خذ GPT-4 وانتهى الأمر»
تتّخذ أغلب المنصّات قرارًا صامتًا بالنيابة عنك: تنتقي نموذجًا يروق لها، وتوصل كل شيء به، وتمضي. ينجح ذلك إلى أن يكفّ عن النجاح — إلى أن يسقط النموذج، إلى أن يُخرج منافس شيئًا أفضل لمهمّة بعينها، إلى أن ترغب في إحضار مفتاحك وإبقاء الكلفة على حسابك، إلى أن تحتاج توليد صور ولا يحسن النموذج الافتراضي ذلك.
الوصفة المعتادة قائمة منسدلة. اختر نموذجًا، استعمله في كل مكان، ودبّر المفاضلات بنفسك. هذا ليس توجيهًا بل إحالة. ويصنع ToRun شيئًا مختلفًا بنيويًّا.
المسار الذي يضع القدرات أولًا
يمرّ كل طلب في ToRun بأربع مراحل قبل أن يمسّ نموذجًا.
١. النمط يحدّد سطح المنتج. حين تفتح جلسة محادثة، أو تطلق مهمّة بحث، فأنت تختار نمطًا. والنمط ليس بطاقة على الواجهة فحسب: إنه يحمل مجموعة محدّدة من القدرات الواجبة والاختيارية. وتحتاج مهمّة البحث أدوات (البحث على الشبكة) وسياقًا طويلًا ومخرَجًا مبنيًّا. أما جلسة المحادثة العادية فتحتاج افتراضيًّا توليد النص وحده.
٢. مجموعة القدرات تصير مصفاة. يمسك ToRun فهرس نماذج من مزوّدين كثر — OpenAI وAnthropic/Claude وGoogle/Gemini وDeepSeek وxAI/Grok وMistral وسواها. ويحمل كل مدخل اتّحاد القدرات التي يدعمها النموذج فعلًا: الإبصار، والأدوات، وتنفيذ الشيفرة، وتوليد الصور، والصوت دخلًا، والصوت خرجًا، وتوليد الفيديو، والتضمينات، وإعادة الترتيب، والبثّ الآني، والاستدلال وغيرها. وتُقابَل مجموعة المرحلة الأولى بهذا الفهرس. والنماذج التي لا تفي بكل القدرات الواجبة تسقط.
٣. ترتيب السعر والجودة يختار الفائز. بين النماذج التي تجتاز المصفاة، يرتّب ToRun بحسب ما هو الطلب حقًّا. يُرتَّب السؤال القصير البسيط بالكلفة، فتنال جوابًا سريعًا رخيصًا. ويُرتَّب الأطول أو الأصعب بالقدرة لكل وحدة كلفة، في مواجهة حدّ أدنى للجودة. وتُرتَّب الجولة التي تحمل صورة بحسب جودة إبصار النموذج، لا بحسب الاستدلال لكل درهم. وينتقل منفّذو سير العمل إلى تقديم الجودة، لأن مسارًا مؤتمتًا يعمل بلا رقيب ينبغي أن يقصد أفضل نتيجة لا أرخص طريق مختصر. أما مستخدمو BYOK فيدخلون التسعير على نحو مختلف، لأن الطلب يمرّ عبر حسابهم لدى المزوّد.
٤. السلاسل البديلة تمتصّ أعطال المزوّدين. إن أعاد النموذج المختار خطأ خدمة، أُعيد تشغيل المسار نفسه مع استبعاده. فيجيب ثاني أنسب نموذج. ولا ترى أنت أي خطأ، ما لم يكن كل المرشّحين الصالحين خارج الخدمة.
مثال ملموس: إبصار مع أدوات
لنفترض أنك ألصقت لقطة شاشة وطلبت من ToRun أن يبحث على الشبكة عن سياق لما تظهره. يمسّ هذا الطلب قدرتين معًا: الإبصار (على النموذج أن يقبل صورة دخلًا) والأدوات (على النموذج أن يستطيع نداء دالّة بحث على الشبكة).
في نهج النموذج الواحد تعلق: إما أن تدعم منصّتك ذلك المزيج أو لا. أما مع التوجيه بالقدرات فيقاطع ToRun المطلبين. ولا يجتاز المصفاة إلا النماذج التي تأكّد دعمها للإبصار ولنداء الأدوات معًا. ومن تلك القائمة القصيرة يختار ترتيبُ السعر والجودة الأفضلَ لنمطك الحالي. وإن كان المرشّح الأول محدودًا أو ساقطًا، خدم التالي الطلبَ دون أن تفعل شيئًا.
عمليًّا لهذا وزن: تبدّلت مجموعة النماذج ذات الإبصار كثيرًا في العام الماضي وستظلّ تتبدّل. والتوجيه بالقدرات يجعل ToRun يأخذ النماذج المضافة حديثًا في الحسبان تلقائيًّا فور دخولها الفهرس، دون أي تحديث من جهتك.
لماذا يغلب هذا الارتهانَ
ليس لمنصّة النموذج الواحد إلا خطّة بديلة واحدة: انتظار المزوّد حتى يصلح العطل. أما المنصّة التي تقدّم القدرات فلديها فهرس. فحين تقع حادثة عند OpenAI، تُخدَم الطلبات التي يقدر عليها Anthropic أو Gemini هناك. وحين يعطي نموذج Mistral جديد نسبة سعر إلى جودة أفضل في المخرَج المبنيّ، دخل ترتيبَ الأنماط المعنية دون هجرة قسرية.
وينطبق المنطق نفسه على BYOK. فحين تضيف مفتاحك لمزوّد ما، تبقى تلك البيانات محصورة داخل طبقة التوجيه. والطلبات التي تلائم نماذج ذلك المزوّد الصالحة يمكنها أن تستعمل مفتاحك بدل حساب ToRun، فتنقل الكلفة إلى علاقتك بالمزوّد في درجة الفوترة الملائمة. ولا يتغيّر مسار التوجيه: يتغيّر فقط أيّ بيانات اعتماد تُستعمل لحظة التنفيذ.
والثمن هو الصدق: لا يستطيع ToRun أن يضمن أن أرخص نموذج سيكون أذكاها لمهمّتك. والترتيب مكشوف — ترى ما اختير ولماذا، ويمكنك تجاوزه. وهذه الشفافية هي المقصد. كل طلب يكتب سجلّ فوترة بالنموذج المستعمل، ووحدة التسعير السارية عند التنفيذ، وتفصيل الكلفة. ويمكنك تدقيق أي نداء بعد أشهر، حتى بعد تغيّر أسعار المزوّد، لأن اللقطة مجمّدة عند اللحظة التي جرى فيها الطلب.
نموذج واحد يصنع كل شيء محضُ اختلاق مريح. وما تريده حقًّا منصّة تجد النموذج المناسب لكل مهمّة وتجعل ذلك الاختيار مقروءًا.