💬 NLP

CRANE: Constrained Reasoning Injection for Code Agents via Nullspace Editing

تُعد CRANE طريقةً لتعديل المعلمات دون الحاجة إلى تدريب، حيث تدمج نقاط تفتيش وكلاء الأكواد من نوعي Instruct وThinking عبر تعديل الفضاء الصفري (nullspace editing) لتعزيز أداء الاستدلال طويل المدى واستخدام الأدوات بشكل كبير مع الحفاظ على الكفاءة.

المؤلفون الأصليون: Mingzhi Zhu, Michele Merler, Raju Pavuluri, Stacy Patterson

نُشر 2026-05-15

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Mingzhi Zhu, Michele Merler, Raju Pavuluri, Stacy Patterson

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أن لديك نسختين مختلفتين من مهندس برمجيات عبقري، لنطلق عليهما القائد (The Commander) والفيلسوف (The Philosopher).

القائد (نموذج التعليمات - Instruct Model): هذا المهندس سريع للغاية، يتبع قواعد صارمة، ويعرف تماماً كيفية استخدام الأدوات (مثل المفك أو المترجم البرمجي/Compiler) دون إحداث فوضى. ومع ذلك، قد يتسرع أحياناً لإصلاح مشكلة ما دون فهم المخطط الهندسي بالكامل، مما يؤدي إلى وقوع أخطاء.
الفيلسوف (نموذج التفكير - Thinking Model): هذا المهندس هو خبير في التخطيط. يفكر بعمق، ويأخذ في الاعتبار كل الزوايا، ويمتلك استراتيجيات رائعة للتعافي عندما تسوء الأمور. لكنه أيضاً عرضة لـ "الإفراط في التفكير". قد يقضي ساعات في الجدال حول أفضل طريقة للإمساك بمفك البراغي، مما يهدر الوقت والطاقة، وأحياناً يغرق في أفكاره لدرجة أنه ينسى فعلياً استخدام الأدوات أو اتباع بروتوكولات السلامة.

تقدم الورقة البحثية طريقة جديدة تسمى CRANE (حقن الاستدلال المقيد لوكلاء الكود عبر تعديل الفضاء الصفري - Constrained Reasoning Injection for Code Agents via Nullspace Editing). هدفها هو إنشاء الهجين المثالي: مهندس يمتلك مهارات التخطيط العميقة للفيلسوف مع الحفاظ على انضباط وسرعة القائد.

المشكلة: لماذا لا نقوم بمجرد دمجهم؟

عادةً، إذا أردت دمج نموذجين، فقد تقوم ببساطة بمتوسط أوزانهما (مثل خلط لونين من الطلاء). لكن المؤلفين وجدوا أن الدمج البسيط لا يعمل جيداً هنا.

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

الحل: وصفة CRANE المكونة من ثلاث خطوات

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

1. مرشح الضجيج (تحديد عتبة المقدار - Magnitude Thresholding)

تخيل أن الفرق بين الفيلسوف والقائد هو حقيبة ضخمة تحتوي على آلاف الملاحظات الصغيرة. معظم هذه الملاحظات ليست سوى ضجيج خلفية أو أفكار صغيرة غير مهمة.

ما يفعله CRANE: يقوم برمي الملاحظات الصغيرة والضعيفة ويحتفظ فقط بالملاحظات الكبيرة والجريئة والمهمة. هذا يضمن عدم حقن "تشويش" عشوائي في عقل القائد.

2. بوابة السلامة (بوابة تايلور التحفظية - Conservative Taylor Gate)

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

ما يفعله CRANE: يتحقق من كل ملاحظة مقابل سؤالين:
1. هل تساعد هذه الملاحظة الوكيل على حل المشكلة بشكل أفضل؟
2. هل تكسر هذه الملاحظة قواعد كيفية تحدث الوكيل مع الكمبيوتر؟
النتيجة: يحتفظ فقط بالملاحظات التي تجتاز كلا الاختبارين. إذا كانت الملاحظة تساعد في الاستدلال ولكنها تكسر القواعد، يتم حذفها. هذه هي "بوابة السلامة".

3. الدرع (الإسقاط السيني المتدرج - Graduated Sigmoidal Projection)

حتى مع وجود بوابة السلامة، قد تعبث بعض الملاحظات بالخطأ بـ "زي رسمي" الوكيل — وهو التنسيق المحدد الذي يستخدمه للتحدث مع الكمبيوتر (مثل كود JSON أو هياكل أوامر محددة).

ما يفعله CRANE: يحدد الأجزاء المسؤولة في الدماغ عن ارتداء ذلك الزي الرسمي. ثم ينشئ "درعاً" حول تلك المناطق. إذا حاولت ملاحظة جديدة تغيير شكل الزي، فإن الدرع يدفعها بلطف للعودة، مما يضمن أن الوكيل لا يزال يتحدث لغة الكمبيوتر بشكل مثالي.

النتائج: الوكيل الخارق

اختبرت الورقة البحثية هذا "الوكيل الخارق" الجديد في ثلاثة تحديات برمجية مختلفة (إصلاح الأخطاء في الكود، حل مشكلات البرمجيات، وتشغيل أوامر Shell معقدة).

نجاح أفضل: حل نموذج CRANE مشاكل أكثر بكثير من نموذج "القائد" الأصلي أو نموذج "الفيلسوف" الأصلي. على سبيل المثال، في أحد الاختبارات، حل 66% من المشاكل مقارلة بـ 46% للقائد.
لا عقوبة "الإفراط في التفكير": من الناحية الحاسمة، لم يصبح النموذج بطيئاً أو مسرفاً في الكلام. لم يضع وقته في "التفكير" في دوائر مفرغة. ظل سريعاً وفعالاً، مستخدماً موارد (Tokens) أقل من الفيلسوف الذي يفرط في التفكير.
أفضل من الدمج البسيط: تفوق على جميع الطرق القياسية الأخرى لدمج النماذج، مما يثبت أن نهج "الحقن الجراحي" هذا هو الأفضل.

باختصار

CR_ANE هو تقنية ذكية تأخذ العبقرية الاستراتيجية لنموذج "المفكر" وتحقنها بعناية في نموذج "المنفذ". يستخدم مرشحاً لإزالة الضجيج، وبوابة لضمان السلامة، ودرعاً لحماية قدرة الوكيل على اتباع التعليمات. النتيجة هي وكيل برمجي ذكي، استراتيجي، ومنضبط في آن واحد، يحل المزيد من المشكلات دون إضاعة الوقت أو كسر القواعد.

ملخص تقني: CRANE – حقن الاستدلال المقيد لوكلاء البرمجة عبر تعديل الفضاء الصفري (Nullspace Editing)

1. بيان المشكلة

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

تشير الملاحظات الأخيرة إلى وجود عدم توافق بين نقاط فحص النماذج المزدوجة (paired model checkpoints):

نماذج التعليمات (Instruct Models): هي نماذج موجزة ومنضبطة في استخدام الأدوات، لكنها تفتقر غالبًا إلى التخطيط العميق أو سلوكيات التعافي، مما يؤدي إلى تعديلات سابقة لأوانها أو الدخول في حلقات مفرغة.
نماذج التفكير (Thinking Models): تُظهر قدرات استدلال وتعافي أقوى، لكنها غالبًا ما "تفرط في المداولة"، مما يستهلك عددًا هائلًا من الرموز (tokens) ويؤدي إلى تدهور الأداء عبر انتهاك بروتوكولات الأدوات أو الفشل في اتخاذ الإجراء.

تقنيات دمج النماذج الحالية (مثل Task Arithmetic، TIES، SLERP) تعامل عملية الدمج عادةً كدمج متماثل لنقاط النهاية. وهي ليست مصممة لسيناريو "الوكيل البرمجي" غير المتماثل (asymmetric) حيث الهدف هو حقن سلوكيات استدلال محددة من نموذج "التفكير" في هيكل نموذج "التعليمات" مع الحفاظ بصرامة على واجهة الأدوات الخاصة بنموذج "التعليمات". غالبًا ما يؤدي الدمج الساذج إلى إتلاف دقة البروتوكول المطلوبة لتنفيذ الوكيل للمهام بنجاح.

2. المنهجية: CRANE

إن CREANE (حقن الاستدلال المقيد لوكلاء البرمجة عبر تعديل الفضاء الصفري) هو طريقة لتعديل المعلمات بدون تدريب، تعامل متجه الفرق بين نقطتي فحص "التفكير" و"التعليمات" ( $\delta = \theta_{\text{think}} - \theta_{\text{inst}}$ ) كحوض اتجاهي من تعديلات الاستدلال المرشحة. وتستخدم خط إنتاج مكونًا من ثلاث مراحل لحقن هذه التعديلات بشكل انتقائي مع الحفاظ على سلوك الوكيل:

المرحلة 1: عتبة المقدار (إزالة الضجيج)

يحتوي الـ $\delta$ الخام على إشارات استدلال مفيدة وضجيج في آن واحد. يطبق CRANE قاعدة تشتت (sparsification) متحفظة لإزالة الإحداثيات منخفضة الثقة.

الآلية: يتم تطبيق عتبة مقدار وسيطة حتمية؛ حيث يتم تصفير الإحداثيات التي تقل مقاديرها عن وسيط $|\delta|$ .
إعادة القياس: يتم تغيير حجم المدخلات غير الصفرية المتبقية بمعامل قدره 2 للحفاظ تقريبًا على مقياس التحديث الإجمالي.
الهدف: التخلص من الضجيج منخفض المقدار الذي قد يربك واجهة الوكيل دون تقديم مساهمة في الاستدلال.

المرحلة 2: بوابة تايلور المتحفظة (Conservative Taylor Gate - CTG)

تحدد هذه المرحلة قوة الحقن لكل كتلة معلمات (طبقة ومكون) من خلال تقييم ما إذا كان اتجاه تعديل معين مفيدًا لكل من نقل الاستدلال والحفاظ على استخدام الأدوات.

المعايرة: يتم تعريف دالتين لخسارة مقنعة باستخدام مجموعات معايرة صغيرة:
- $L_R$ (الاستدلال): يقيس الأداء على مطالبات الاستدلال البرمجي الناتجة عن نموذج التفكير.
- $L_A$ (سلوك الوكيل): يقيس الأداء على مطالبات استخدام الأدوات الناتجة عن نموذج التعليمات.
التسجيل: لكل إحداثي $j$ ، يتم حساب درجة التحسن من الدرجة الأولى كالتالي: $s_K(j) = -g_{K,j}\delta_j$ ، حيث $g_K$ هو تدرج الخسارة.
منطق البوابة: يحصل الإحداثي على وزن إيجابي فقط إذا كان التعديل اتجاه هبوط لكلا الخسارتين في وقت واحد:
$p_j = [\min\{s_R(j), s_A(j)\}]_+$
التجميع: يتم تجميع الأوزان لكل كتلة وتطبيعها بالنسبة لكتلة مرجعية (FFN/expert) لتحديد معامل القياس النهائي $S_{\text{CTG}}(c, l)$ .

المرحلة 3: الإسقاط السيجمويدي المتدرج (Graduated Sigmoidal Projection - GSP)

حتى التعديلات المفيدة يمكن أن تعطل رموز التنسيق الحرجة (مثل محددات الأدوات، مخططات JSON، قوالب الدردشة). تعمل هذه المرحلة على كبح التحديثات في الفضاء الجزئي "الحرج للتنسيق".

جمع التنشيط: يتم جمع الحالات المخفية (hidden states) من نموذج التعليمات على المسارات الحرجة للتنسيق (الرموز التي تتحكم في استدعاءات الأدوات والمخططات).
إسقاط القيمة المفردة (SVD): يتم إجراء تحليل القيمة المفردة على مصفوفة التنشيط. الاتجاهات ذات القيم المفردة العالية تقابل اتجاهات المدخلات التي تؤثر بقوة على مخرجات التنسيق الحرجة.
القناع الناعم: بدلاً من الإسقاط في الفضاء الصفري الصلب، يتم تطبيق قناع سيجمويدي في فضاء القيم المفردة. يتم تخفيف الاتجاهات ذات السعة العالية (الحرجة للتنسيق) بشكل كبير، بينما يتم الحفاظ على الاتجاهات ذات السعة المنخفضة. يضمن هذا انتقالًا سلسًا بدلاً من القطع المفاجئ.

يتم حساب النموذج المدمج النهائي كالتالي:
$\theta_{\text{merged}} = \theta_{\text{inst}} + \Pi_{\text{GSP}} \left( \alpha \cdot S_{\text{CTG}} \cdot T(\delta) \right)$

3. المساهمات الرئيسية

صياغة الدمج الاتجاهي: نهج جديد لدمج النماذج لنقاط فحص "التعليمات/التفكير" المزدوجة، حيث يعامل الـ $\delta$ كحوض تعديل مرشح بدلاً من هدف متماثل، مشروط بسلوكيات وكيل محددة.
وصفة CRANE: خط إنتاج مكون من ثلاث مراحل بدون تدريب، يجمع بين استخراج الـ $\delta$ المتناثر، وبوابة تايلور المتحفظة الواعية لاستخدام الأدوات، وإسقاط سيجمويدي حافظ للتنسيق.
التقييم التجريبي: تقييم شامل عبر ثلاثة اختبارات مرجعية (Roo-Eval، SWE-bench-Verified، Terminal-Bench v2) ونطاقين من أحجام النماذج (Qwen3-30B-A3B و Qwen3-Next-80B-A3B).
دراسات الاستئصال (Ablation Studies): تحليل يؤكد أن كل مكون (المشتت، بوابة تايلور، الإسقاط) ضروري لمقايضة الأداء والتكلفة الملحوظة.

4. النتائج التجريبية

يتفوق CRANE باستمرار على كل من نقاط النهاية الفردية وعلى نماذج الدمج القياسية (Task Arithmetic, TIES, SLERP, AIM, LEWIS, RAIN) عبر جميع الاختبارات مع الحفاظ على الكفاءة.

Roo-Eval (البرمجة القائمة على IDE):
- مقياس 30B: حقق 66.2% pass@1، بزيادة قدرها +19.5% عن نموذج التعليمات الأساسي (46.7%) و +19.0% عن أفضل عملية دمج بديلة.
- مقياس 80B: حقق 81.5% pass@1، بزيادة قدرها +8.7% عن نموذج التعليمات.
- الكفاءة: حقق CRANE هذه المكاسب مع عدد إجمالي للرموز (TTC) أقل من نموذج التعليمات الأساسي، مما قلل استخدام الرموز بنحو 60 مليون رمز عند مقياس 30B.
SWE-bench-Verified (مشكلات مستوى المستودع):
- مقياس 30B: حل 122/500 حالة، متفوقًا على نموذج التعليمات (108) وأفضل دمج بديل (113).
- مقياس 80B: حل 180/500 حالة، متجاوزًا نموذج التعليمات (168) وجميع البدائل الأخرى.
- الكفاءة: حل CRANE حالات أكثر بتكاليف إجمالية للرموز أقل من النماذج البديلة.
Terminal-Bench v2 (سير عمل Shell/سطر الأوامر):
- مقياس 30B: حسن pass@1 إلى 7.6% (مقابل 4.8% للتعليمات) و pass@5 إلى 17.9%.
- مقياس 80B: حسن pass@1 إلى 14.8% و pass@5 إلى 30.3%.
- الكفاءة: قلل CRANE وقت التشغيل الفعلي بشكل كبير (على سبيل المثال، 1 ساعة و 58 دقيقة مقابل 2 ساعة و 28 دقيقة للتعليمات عند مقياس 80B) مع الحفاظ على معدلات نجاح عالية.

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

5. الأهمية والادعاءات

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

يؤكد المؤلفون أن هذه المكاسب ليست ناتجة عن زيادة ميزانيات الرموز أو عمليات التشغيل الطويلة؛ بل في الواقع، غالبًا ما يحقق CRANE نتائج متفوقة بعدد أقل من الرموز وأوقات تشغيل أقصر. توفر الطريقة مسارًا عمليًا بدون تدريب لتعزيز أداء الوكيل عبر الاستفادة من نقاط قوة نماذج الاستدلال مع الالتزام الصارم ببروتوكولات الوكيل المنشورة.

القيود المعترف بها:

تفترض الطريقة أن نقطة فحص التفكير توفر استدلالًا مفيدًا ونقطة فحص التعليمات توفر واجهة مفيدة؛ إذا كانت النماذج المستقبلية تتفوق بالفعل في كليهما، فقد تكفي عمليات دمج أبسط.
يجب أن تغطي مجموعات المعايرة سطح الأدوات المستخدم؛ أي تغيير كبير في الأدوات أو التنسيق سيتطلب إعادة معايرة.
يتطلب بناء مسقط GSP عمليات تمرير أمامي (forward passes) على مسارات التنسيق، مما قد يكون مكلفًا حوسبيًا للنماذج الكبيرة جدًا.
لا تزال النتائج في بعض اللغات (Java, Rust) أقل من Python/JS/Go، مما يشير إلى وجود عدم تماثل في التدريب الأساسي للنماذج بدلاً من فشل في طريقة الدمج نفسها.