SearchQwen3-8B من علي بابا والحجة لصالح وكلاء البحث الصغار

أطلقت فرقة PAI في Alibaba Cloud نموذج SearchQwen3-8B على Hugging Face تحت رخصة Apache 2.0، وهو نموذج يضم 8.19 مليار معامل ومصمم للبحث والتصفح متعددي الخطوات. يمتلك نافذة سياق تبلغ 40,960 رمزًا (token)، وهو لا يولّد نصًا حرًا بقدر ما يصدر استدعاءات أدوات مُهيكلة ينفذها نظام بحث خلفي.

هذا التأطير هو المقصد. النموذج وكيل بحث، وليس محرك بحث. يقرر ما الذي يبحث عنه، وبأي ترتيب، وكيف يوفّق بين ما يعود. وأنت من يوفّر النظام الخلفي.

يهُمّ هذا التمييز لأنه يفصل بين مهمتين كثيرًا ما تُجمعان معًا في معظم النقاشات حول البحث بالذكاء الاصطناعي. الاسترجاع مشكلة بنية تحتية: فهرس، ودالة ترتيب، وطريقة لزحف المحتوى الطازج. أما التخطيط فمشكلة استدلال: أن تقرر أن هذا السؤال يحتاج ثلاث عمليات بحث، وأن الرابعة زائدة، وأن المصدرين الأولين متناقضان. إن SearchQwen3-8B هو تمامًا النوع الثاني من الأنظمة، ولهذا لن يجيب عن سؤال بمفرده أبدًا، ولهذا يمكن إدراجه في منظومة استرجاع قائمة دون استبدالها.

كيف بُني

نهج التدريب هو التفصيل التقني المثير للاهتمام. تم تقطير SearchQwen3-8B باستخدام EasyDistill 2.0 على مسارات بحث كانت متوائمة مع البيئة ومتحققة من قِبل الحلّال. وبدلًا من التدريب على سجلات بحث كتبها البشر، تولّد العملية مسارات في بيئة حية وتحتفظ بتلك التي حلّت المهمة فعليًا.

التحقق من قِبل الحلّال هو ما يجعل ذلك ناجعًا. لا يكون المسار ذا قيمة كبيانات تدريب إلا إذا انتهى إلى إجابة صحيحة، وصحة الإجابة قابلة للتحقق في كثير من مهام البحث على نحو لا ينطبق على التوليد المفتوح. وهذا يمنح خط المعالجة مرشحًا موثوقًا، ولهذا كانت المكاسب المعلنة كبيرة إلى هذا الحد.

وأُطلق إلى جانبه نموذج أصغر شقيق هو SearchQwen2.5-3B بنافذة سياق تبلغ 32,768 رمزًا، وهو أيضًا مقطّر باستخدام EasyDistill 2.0 وSynSearch-Data.

الأرقام المعلنة

تُفيد بطاقة النموذج بتحسّن دقة محكّم LLM مقارنةً بنموذج Qwen3-8B الأساسي تحت واجهة استدعاء الأدوات نفسها. في الأسئلة متعددة الخطوات، ترتفع دقة استدعاء الأدوات من 24.50 إلى 35.42. وفي البحث العميق عمومًا، ترتفع من 40.31 إلى 50.31.

وبالنسبة إلى نموذج 3B، فإن القفزات المعلنة أكبر نسبيًا: 48.58 في الأسئلة متعددة الخطوات مقابل 36.10 لنموذج Qwen2.5-3B-Instruct الأساسي، و21.40 في البحث العميق مقابل 7.05.

كل هذه الأرقام مُعلنة من الشركة ولم تُقيَّم بصورة مستقلة، وهذا مهم في مجال فرعي يكون فيه التقييم سهل التلاعب بصورة غير معتادة. تكافئ معايير البحث معرفة المصادر التي يجب الوثوق بها، والنموذج المضبوط بدقة على مسارات متحققة من الحلّال سيُحسَّن لصالح ما اعتبره الحلّال صحيحًا. ويظل التقييم المستقل مقابل معايير مثل GAIA وHotpotQA هو الإشارة التي يجب متابعتها.

وتستحق الأرقام المطلقة أيضًا نظرة ثانية قبل أن يتعامل معها أي شخص على أنها جاهزة للإنتاج. فالقفزة من 24.50 إلى 35.42 في الأسئلة متعددة الخطوات تحسّن نسبي كبير، ومع ذلك تعني أن النموذج يخطئ في نحو محاولتين من كل ثلاث تحت ذلك المحكّم. التقطير على مسارات متحققة يحقق مكاسب حقيقية، لكنه لا ينتج نظامًا يمكن الوثوق به دون خطوة تحقق خاصة به.

لماذا تهمّ وكلاء البحث الصغار

المنطق الاستراتيجي وراء إصدار وكيل بحث بحجم 8B، وآخر بحجم 3B إلى جانبه، يتعلق باقتصاديات النشر. فوكيل البحث يُستدعى كثيرًا وغالبًا على نحو متوازٍ، مما يجعل تكلفة API لكل رمز قيدًا حقيقيًا. والنموذج الذي يعمل على عتاد متواضع ولا يكلف شيئًا لكل استدعاء يغيّر التطبيقات القابلة للتنفيذ.

يمكن لفريق دعم يريد أن يبحث وكيل عن سؤال عميل عبر وثائق داخلية ومصادر عامة أن يشغّل SearchQwen3-8B على بنيته التحتية الخاصة. ويمكن لمجموعة بحثية تحتاج إلى تجميع نتائج من مصادر كثيرة دون إرسال استعلامات إلى طرف ثالث أن تفعل الشيء نفسه. لا تتطلب أي من الحالتين استدلالًا بمستوى النماذج الرائدة. بل تتطلبان استخدامًا موثوقًا للأدوات وتكلفة هامشية منخفضة.

وهناك حجة تتعلق بالحوكمة أيضًا. فوكيل البحث المستضاف ذاتيًا يبقي أنماط الاستعلام داخل المؤسسة، وهذا مهم لأي جهة في قطاع منظم قد تكشف أسئلتها ما تعمل عليه.

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

تستحق هذه المقايضة أن تُقال بوضوح لأنها أكثر الطرق شيوعًا لفشل عمليات النشر هذه. ترى الفرق نموذجًا بحجم 8B بأرقام معايير قوية وتفترض أن الجزء الصعب قد أُنجز. عمليًا، النموذج هو النصف السهل. فطبقة الاسترجاع تحدد الأدلة التي يمكن أن يراها الوكيل، ولا قدر من قدرة التخطيط يعوّض نظامًا خلفيًا يعيد نتائج قديمة أو غير ذات صلة. نموذج التخطيط يقرر متى ينظر. والنظام الخلفي يقرر ما الذي يجده البحث.

واجهة استدعاء الأدوات هي المنتج الفعلي

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

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

ما يجب متابعته

هناك إشارتان ستحددان ما إذا كان هذا الإصدار مهمًا. الأولى هي تقييم مستقل يؤكد المكاسب المعلنة، لأن قيمة طريقة التقطير تعتمد على صمود التحقق فعليًا. والثانية هي ما إذا كانت Alibaba PAI ستطلق مجموعة بيانات التدريب SynSearch-Data أو إطار عمل EasyDistill 2.0. إذا أصبح الاثنان عامّين، فتوقّع موجة من نماذج الوكلاء المقطّرة من فرق أخرى، ما سيجعل الوكلاء الصغار المتخصصين الخيار الافتراضي بدلًا من أن يكونوا مجالًا متخصصًا ضيقًا.

وهناك نمط أوسع يستحق الملاحظة في التوقيت. تُصدر علي بابا وكلاء صغارًا متخصصين تحت رخص متساهلة بينما تُبقي المختبرات الرائدة أفضل نماذجها خلف واجهات API. هذه استراتيجية متعمدة: استقطاب المطورين الذين يهتمون بنشر شيء يتحكمون به، وترك اقتصاديات الاستدعاء لواجهة API مستضافة تتعامل مع كل من عداهم. ويعتمد نجاح ذلك على ما إذا كانت الاستضافة الذاتية توفر المال فعلًا عند النطاق الذي تعمل به الفرق، وهو أمر غير بديهي حال حساب البنية التحتية وعمل الاسترجاع المذكور أعلاه.

في الوقت الحالي، يُعدّ وكيل بحث برخصة Apache 2.0 المتساهلة وبلا رسوم لكل استدعاء إضافة مفيدة إلى الرف. لن يحل محل النماذج الرائدة في الاستدلال الصعب. ولا يحتاج إلى ذلك. فمعظم استدعاءات وكلاء البحث روتينية، والعمل الروتيني هو أفضل مرشح لنموذج صغير.