نماذج الاستدلال تُدرَّب ولا تُوجَّه بالـ Prompt

هذا رأي دافعت عنه بشكل ضعيف في غداء جماعي مع الفريق العام الماضي، وازددت قناعة به منذ ذلك الحين: إذا كان تصورك لنموذج الاستدلال هو “نموذج LLM عادي طُلب منه أن يفكر خطوة بخطوة”، فأنت لا تفهم نماذج الاستدلال أصلاً، وهذا الفهم الخاطئ يكلفك بصمت مالاً ودقة في بيئة الإنتاج. نماذج الاستدلال ليست تقنية prompting. إنها نتاج تدريب. سلوك سلسلة التفكير الذي يجعلها جيدة في الرياضيات والبرمجة ينشأ من التعلم المعزز مع مكافآت قابلة للتحقق، وليس من أي شيء تكتبه في system prompt. استوعبت هذه الفكرة بشكل صحيح بعد أن عملت على المادة نفسها التي يغطيها Sebastian Raschka في دورته الجديدة التي تستغرق 11 ساعة لبناء نموذج استدلال: تحميل نموذج Qwen3 أساسي صغير، وبناء verifier، وتشغيل GRPO، ثم مراقبة تزايد طول مسارات الاستدلال وارتفاع الدقة. وبمجرد أن تراه يحدث داخل حلقة التدريب الخاصة بك، لن تستطيع تجاهله.

دعني أدافع عن هذا الادعاء بشكل صحيح، ثم أتراجع عنه في الموضع الذي يستحق التراجع، لأن هناك نقطة واحدة يؤثر فيها الـ prompting فعلاً، وادعاء غير ذلك سيكون نوعاً آخر من الضجيج.

لماذا يتهاوى تصور “فقط وجّهه بالـ prompt”

القصة الشائعة تسير هكذا: في عام 2022 اكتشف باحثون أن إضافة عبارة “لنفكر خطوة بخطوة” إلى الـ prompt حسّنت دقة الحساب بشكل ملحوظ، وهكذا وُلد prompting سلسلة التفكير. وهذا صحيح بقدر ما تذهب إليه القصة. ما تغفله هو ما حدث بعد ذلك، إذ أخذت المختبرات ذلك السلوك وثبّتته في الأوزان باستخدام التعلم المعزز. النموذج الحديث للاستدلال لا يحتاج إلى تعويذتك خطوة بخطوة، فهو يولّد مسارات استدلال موسعة افتراضياً، لأنه دُرِّب على ذلك، وكوفئ على إنتاج مسارات تنتهي بإجابات صحيحة.

يمكنك التحقق من ذلك بنفسك عبر تجربة تستغرق فترة بعد الظهر. خذ نموذجاً أساسياً، فنموذج Qwen3 بحجم 0.6B يعمل بشكل جيد ويشتغل على وحدة GPU استهلاكية واحدة، ثم قيّمه على MATH-500 مرة مع سلسلة التفكير ومرة بدونها. ستحصل على تحسن متواضع. الآن جرّب النسخة المدرّبة بـ RLVR من عائلة النموذج نفسها. الفارق بين الحالتين لن يكون مجرد تحسن، بل سيكون قفزة حادة. لا يوجد system prompt كُتب يسد هذه الفجوة. وهذا هو جوهر ادعائي من الناحية التجريبية: القدرة موجودة في الأوزان، والأوزان وصلت إلى هذه الحالة عبر التدريب، لا عبر ترتيبات ذكية للرموز أثناء الاستدلال.

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

الـ verifier هو الحيلة كلها

عندما كنت مهندس ML، كان الجزء من RLHF الذي يبدو دائماً ملعوناً قليلاً هو نموذج المكافأة. تدرّب شبكة عصبية منفصلة لتقليد تفضيلات البشر، ثم تحسّن السياسة ضدها، وبعدها تقضي بقية المشروع في مكافحة reward hacking، إذ تجد السياسة مخرجاً منحرفاً يحصل على درجة عالية من نموذج المكافأة بينما يكون عديم الفائدة للبشر الحقيقيين. إنها علاقة عدائية مدمجة في البنية نفسها.

التعلم المعزز مع مكافآت قابلة للتحقق (RLVR) يتجاوز هذه المشكلة تماماً، وبناء verifier من الصفر يجعلك تقدّر مدى أناقة هذه الخطوة. في الرياضيات، الـ verifier برنامج حتمي ومملّ: يستخرج الإجابة النهائية من مخرجات النموذج، ويوحّدها (يتعامل مع الكسور والأعداد العشرية والأشكال المكافئة مثل 1/2 مقابل 0.5)، ثم يتحقق من التكافؤ الرياضي. الإجابة الصحيحة تحصل على مكافأة واحدة، والخاطئة على صفر. لا يوجد نموذج مكافأة متعلم يمكن استغلاله. إشارة المكافأة هنا هي الحقيقة المطلقة.

لهذا السبب تفوقت نماذج الاستدلال في الرياضيات والبرمجة أولاً. كلا المجالين يأتيان مع verifiers رخيصة وموثوقة: فاحصات تكافؤ رمزي للرياضيات، واختبارات وحدة للبرمجة. لا تحتاج إلى مُعلّقين بشريين يرتبون المخرجات، بل تحتاج إلى دالة Python تعيد قيمة منطقية. والنتيجة العملية لمن يبني استدلالاً متخصصاً في مجاله واضحة: إذا استطعت كتابة verifier لمجالك، فغالباً تستطيع تدريب نموذج استدلال له. أما إذا كانت الصحة في مجالك مسألة ذوق، كنصوص التسويق مثلاً، فستبقى عالقاً مع RLHF ومتاعبه في reward hacking.

عنق الزجاجة في الاستدلال ضمن مجال جديد ليس الحوسبة أو البيانات. إنه قدرتك على كتابة معنى “الصحيح” في صورة برنامج.

من التفاصيل التي أحبها في بناء الـ verifier أولاً، قبل أي تدريب، أنه يؤدي مهمتين. المُقيِّم نفسه الذي يقيّم نموذجك الأساسي على MATH-500 للتقييم، يصبح دالة المكافأة أثناء RL. وعندما تنفذه بنفسك تلاحظ كم من العمل الدقيق يقوم به، فاستخراج الإجابة مهمة شائكة فعلاً، لأن النماذج تعبر عن الإجابات النهائية بعشرات الصيغ، ومستخرج هش يفسد إشارة المكافأة بصمت. نموذج يكتب “إذن x = 7” قد يُصنَّف خطأً إذا كان تعبيرك النمطي يبحث فقط عن الإجابات المحاطة بـ boxed. الـ verifiers المهملة تُنتج سياسات مهملة. هذا النوع من الدروس لا تتعلمه أبداً من قراءة الأوراق البحثية.

ماذا يفعل GRPO فعلياً بالأوزان

حلقة التدريب نفسها، في صورتها المبسطة المبنية من الصفر، مدمجة بشكل مدهش. Group Relative Policy Optimization، الخوارزمية التي نشرتها DeepSeek، تُسقط شبكة الناقد (critic) التي جعلت PPO يستهلك ذاكرة كبيرة. بدلاً من تعلم دالة قيمة، تولّد مجموعة من الإجابات للـ prompt نفسه، ثم تقيّمها كلها بالـ verifier، وتحسب ميزة كل إجابة نسبةً إلى متوسط المجموعة. الإجابات الأفضل من متوسط المجموعة ترفع احتمالات رموزها، والأسوأ تخفضها.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

التطبيقات الواقعية تضيف عقوبة KL للحفاظ على عدم ابتعاد السياسة كثيراً عن النموذج المرجعي، إضافة إلى clipping مستعار من PPO، لكن الهيكل الموضح أعلاه هو الفكرة الجوهرية بصدق. وما يجعل مشاهدتها ساحرة أنك لا تخبر النموذج بأي شيء عن أسلوب الاستدلال. أنت تكافئ فقط الإجابات النهائية الصحيحة. ومع ذلك، مع مرور التدريب تزداد أطوال الإجابات. يبدأ النموذج بإنتاج تصحيحات ذاتية في منتصف المسار، مثل “انتظر، دعني أتحقق”، لأن المسارات التي تتضمن سلوك التحقق أكثر احتمالاً لأن تنتهي بإجابات صحيحة، والإجابات الصحيحة هي الشيء الوحيد الذي يكسب المكافأة. أسلوب سلسلة التفكير حل ناشئ لمسألة التحسين، وليس سلوكاً صممه أحد. لهذا أقول إنه مُدرَّب وليس مُوجَّهاً بالـ prompt: النسخة الحقبة الـ prompting من هذا السلوك كانت البشر يقلدون ما اكتشفه RL لاحقاً بمفرده.

هناك ملاحظة هندسية عملية مخفية هنا تتجاوزها دورة الضجيج: نموذج 0.6B مع وحدة GPU جيدة يكفي لرؤية هذه الديناميكية بشكل حقيقي. ستحصل على تحسن قابل للقياس في MATH-500 من GRPO على عتاد تستأجره بضعة دولارات في الساعة. لن تحصل على نموذج من الطراز الرائد، وهذا لا بأس به، فليست هذه غاية التمرين.

التوسع وقت الاستدلال: حيث تحل الحوسبة محل التدريب (جزئياً)

قبل أن يحدث أي RL، توجد مجموعة من التقنيات التي تحسّن الإجابات مع تجميد الأوزان: أخذ عينات متعددة من المرشحين باستخدام temperature وtop-p، ثم دمجها. Self-consistency هي الأداة الأساسية، إذ تولّد k إجابة وتأخذ تصويت الأغلبية على الإجابات النهائية. وهي تنجح بشكل مدهش، وتنجح حتى على النماذج الأساسية، وهذا أول شق في ادعائي الافتتاحي سأعترف به: الحوسبة وقت الاستدلال محور تحسين حقيقي ومستقل.

لكن انظر إلى ما تتطلبه هذه التقنيات فعلاً. تصويت الأغلبية لا يساعد إلا إذا كان نموذجك يملك احتمالاً غير تافه لإنتاج إجابات صحيحة أصلاً، فالتصويت يضخم إشارة موجودة، لكنه لا يخلق إشارة من العدم. والاختيار القائم على التسجيل (ترتيب المرشحين حسب log-probability للتسلسل) له الخاصية نفسها. وحلقات التحسين الذاتي، حيث ينتقد النموذج إجابته ويراجعها، تتضح أنها ضعيفة بشكل مخيب على النماذج الأساسية، لأن النقد الذاتي الصادق قدرة بحد ذاتها يثبّتها RL. كل حيلة وقت استدلال تتركب مع التدريب، ولا شيء منها يحل محله. والسبب في أن الأنظمة الرائدة تجمع نماذج مدرّبة بـ RL مع توسيع وقت الاستدلال هو أن أثرهما يتضاعف ولا يتجمع.

جانب التكلفة مهم للممارسين. Self-consistency مع k=16 يكلف ستة عشر ضعف تكلفة الاستدلال. وما إذا كانت هذه صفقة جيدة يعتمد كلياً على منحنى الدقة مقابل التكلفة لديك، والطريقة الوحيدة الصادقة للإجابة هي رسم دقة MATH-500 مقابل عدد المرشحين بنفسك. تناولنا سؤالاً مشابهاً حول مكان إنفاق الحوسبة في مقالتنا عن نماذج الفئة الخفيفة وكفاءة الاستدلال، والفكرة المتكررة أن “إنفاق المزيد من الحوسبة” له ثلاثة معانٍ مختلفة على الأقل، وهي غير قابلة للتبادل.

التقطير، والمكان الوحيد الذي يبقى فيه الـ prompting

المرحلة الأخيرة في خط الأنابيب المبني من الصفر هي التقطير: تأخذ مسارات الاستدلال الطويلة لنموذج قوي (عادة كبير) وتضبط نموذجاً أصغر عليها مباشرة، باستخدام التعلم الخاضع للإشراف البسيط. لا RL، ولا verifier داخل الحلقة. هكذا صُنعت كثير من نماذج الاستدلال الصغيرة والرخيصة التي ستنشرها فعلاً. وهذا يعزز الأطروحة بدلاً من أن يقوضها، فسلوك الاستدلال ما زال يأتي من بيانات تدريب أنتجها نموذج مدرّب بـ RL، لكنه انتقل عبر نزول التدرج بدلاً من المكافأة. القدرة لا تُحقن أثناء الـ prompt أبداً، بل تُثبَّت دائماً بالتحسين.

إذن أين ينكسر ادعائي المعاكس؟ هنا، بصدق: الـ prompting ما زال مهماً على الهوامش، والهوامش ليست صفراً. ضوابط جهد الاستدلال، أي إعدادات الميزانية المنخفضة والمتوسطة والعالية للتفكير التي تتيحها النماذج الحالية، هي أدوات تحكم وقت الاستدلال تبادل الدقة بالزمن والتكلفة بشكل ملموس. وقيود المخرجات المنظمة، وخطوط الأنابيب التي تدمج verifier، وconstrained decoding، كلها تقنيات على مستوى الـ prompt والأطر لها قيمة حقيقية، كما ناقشنا في مقالتنا عن constrained decoding. وإذا كنت عالقاً بنموذج أساسي ولا تستطيع تدريب أي شيء، فما زال prompting سلسلة التفكير يكسب نقاطاً حقيقية في التقييمات. “مُدرَّب لا مُوجَّه بالـ prompt” ادعاء عن مكان نشأة القدرة الأصلي، وليس ادعاءً بأن خيارات وقت الاستدلال لا تهم.

لماذا يتفوق البناء على القراءة عنه

ظهر اعتراض وجيه في الأماكن المعتادة: ألا يشبه درس بناء نموذج استدلال بنفسك دليلاً لبناء معالج CPU بنفسك، ممتعاً لكنه غير مفيد، بما أن تدريبات الإنتاج الحقيقية تحتاج إلى عناقيد حوسبة وبيانات خاصة؟ أعتقد أن هذا يخطئ الهدف من التمرين، وأقول الشيء نفسه عن درس بناء shell الكلاسيكي، الذي أشدنا به في ماذا يعلمك بناء Shell عن Unix لهذا السبب تحديداً. لا أحد يكتب shell ليحل محل bash. تكتبه لأن fork وexec والأنابيب ومعالجة الإشارات تتوقف عن كونها تجريدات حفظتها، وتصبح آليات أمسكتها بيدك.

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

• كتابة الـ verifier علّمتني أن جودة المكافأة مشكلة هندسة برمجيات، فحالات التوحيد الطرفية تشوّه التدريب بصمت، و“المكافأة هي الحقيقة المطلقة” صحيحة فقط بقدر دقة مستخرج الإجابات لديك.
• تطبيق حساب log-probability للتسلسل (مع ما يتطلبه ذلك من ألعاب الاستقرار العددي) فكّ الغموض عن نصف دوال الخسارة في أدبيات post-training. كلها تختزل إلى مقارنة مدى احتمالية الإجابات تحت سياسات مختلفة.
• مشاهدة طول الإجابات يزداد أثناء GRPO دون أي توجيه قضت على آخر قناعة متبقية لدي بأن أسلوب الاستدلال سلوك سطحي. إنه ما يجده التحسين عندما تكون الصحة هي الهدف الوحيد.
• رسم دقة مقابل عدد المرشحين في self-consistency أعطاني حدساً حقيقياً لصفقة الدقة مقابل التكلفة، وهو ما لم تفعله أي جدول معايير من قبل.

القلق بشأن الحوسبة مبالغ فيه أيضاً لغرض التعلم. الأجزاء الأولى، مثل تحميل نموذج أساسي، والتوليد المتدفق مع KV caching، وبناء الـ verifier، وتشغيل MATH-500، تقع ضمن نطاق الحاسوب المحمول أو قريباً منه. يحتاج GRPO إلى GPU، لكن وحدة واحدة فقط، وإذا استأجرتها بالساعة فهي أرخص من معظم الكتب الدراسية. ما لا يمكنك تكراره في المنزل هو الحجم، والحجم فعلاً تخصص مختلف، وهذا أحد الأساطير حول محرك الاستدلال الخاص بـ DeepSeek الذي اختبرناه: مكدس الخدمة لدى مختبر رائد يحل مشكلات لا توجد أصلاً على نطاق الدروس التعليمية، والعكس صحيح.

الخلاصة العملية

إذا أخذت شيئاً واحداً من كل هذا، فليكن رؤية تتمحور حول الـ verifier. مكدس الاستدلال الحديث يتكون من: نموذج أساسي، وبرنامج يحدد معنى “الصحيح”، وخوارزمية RL تحسّن ضده، وتقنيات وقت استدلال تضاعف النتيجة. يقع الـ prompting على الحافة الخارجية لهذا النظام، يوجّه قدرة أنشأها التدريب. الفرق الذي تفهم ذلك تنفق جهدها حيث يتراكم الأثر: verifiers أفضل، وتصميم مكافآت أفضل، وحلقات تقييم أفضل، مثل تلك التي ناقشنا أنها مفقودة من معظم معايير الذكاء الاصطناعي التي تغفل العمل الحقيقي. أما الفرق التي لا تفهم ذلك فتظل تعدّل system prompts وتتساءل لماذا تتوقف الدقة عند حد معين.

ادعائي على طاولة الغداء يصمد مع استثناء واحد: نماذج الاستدلال مُدرَّبة، لا مُوجَّهة بالـ prompt، لكن الحاضنة التي تبنيها حولها، بما فيها الـ prompts، هي ما يحدد مقدار القدرة المُدرَّبة التي تستخلصها فعلاً. ابنِ النسخة الصغيرة بنفسك في وقت ما. إحدى عشرة ساعة من البرمجة المتابعة ثمن زهيد لكي لا تتشوش بشأن هذا مرة أخرى.