Sketch-and-Verify: Structured Inference-Time Scaling via Program Sketching
تقدم الورقة البحثية استراتيجية "الرسم المبدئي والتحقق" (Sketch-and-Verify)، وهي استراتيجية فعالة من حيث التكلفة لتوسيع نطاق الاستدلال في نماذج الأكواد الصغيرة، تتفوق على أخذ العينات المسطحة عبر حصر مسودات خوارزمية متنوعة وملئها بعدة مرشحات، رغم أنها لا تستطيع استبدال أداء مستويات النماذج الأقوى بشكل كامل.
تخيل أنك تحاول حل لغز صعب، ولكن ليس لديك سوى روبوت صغير وغير مكلف لمساعدتك. هذا الروبوت سريع ورخيص، لكن لديه عادة سيئة: عندما يحاول حل مشكلة ما، فإنه في أغلب الأحيان يختار نفس الطريقة الخاطئة في التفكير. إذا طلبت منه المحاولة 100 مرة، فسيعطيك فقط 100 نسخة مختلفة قليلاً من نفس الإجابة الخاطئة.
هذه هي المشكلة التي تحاول ورقة البحث "Sketch-and-Verify" (التخطيط والتحقق) حلها. إنها تقدم طريقة جديدة لاستخدام ذلك الروبوت الصغير الرخيص بحيث يمكنه حل المزيد من المشكلات دون الحاجة إلى ترقية إلى روبوت ضخم ومكلف للغاية.
إليك كيفية عمل هذه الطريقة، مقسمة إلى خطوات بسيطة:
1. المشكلة: "الأغنية القديمة ذاتها"
عادةً، عندما نطلب من الذكاء الاصطنا_ي كتابة كود برمجي، فإننا نقول فقط: "حاول 100 مرة وأعطني الأفضل منها".
الخلل: إذا كانت الفكرة "الافتراضية" للذكاء الاصطنا_ي خاطئة، فإن طلب المحاولة 100 مرة يشبه مطالبة شخص بكتابة 100 نسخة مختلفة من أغنية سيئة. قد تغير الكلمات أو الإيقاع، لكن اللحن لا يزال خاطئاً. يقع الذكاء الاصطنا_ي في حلقة مفرغة من التغييرات "الجمالية" (مثل تغيير أسماء المتغيرات أو التنسيق) دون أن يجرب أبداً نهجاً مختلفاً جوهرياً.
2. الحل: "المهندس والمعماري والبنّاء"
يقترح المؤلفون عملية مكونة من خطوتين تسمى Sketch-and-Verify. بدلاً من طلب كتابة الكود كاملاً من الذكاء الاصطنا_ي فوراً، قاموا بتقسيم المهمة إلى دورين:
الخطوة 1: المهندس المعماري (المخطط - The Sketch) أولاً، نطلب من الذكاء الاصطنا_ي أن يعمل كمهندس معماري. نقول له: "لا تكتب الكود بعد. فقط اذكر 5 طرق مختلفة تماماً لحل هذه المشكلة."
مثال: "الاستراتيجية أ: استخدم خريطة (Map). الاستراتيجية ب: قم بترتيب القائمة أولاً. الاستراتيجية ج: استخدم حلقة تكرار (Loop)."
بمجرد أن يختار الذكاء الاصطنا_ي استراتيجية ما، يقوم برسم "مخطط أولي" (Sketch) يحتوي على ثغرات. المخطط يحتوي على الهيكل الرئيسي (الجدران والسقف) ولكنه يترك التفاصيل المحددة (لون الطلاء، مقبض الباب) كفراغات فارغة يرمز لها بـ ??.
لماذا يساعد هذا: هذا يجبر الذكاء الاصطنا_ي على التوقف والتفكير في مسارات مختلفة قبل البدء في البناء. إنه يضمن أن الذكاء الاصطنا_ي يستكشف "أحياء" مختلفة من الحلول بدلاً من مجرد المشي في دوائر داخل نفس الحي.
الخطوة 2: البنّاء (الملء - The Fill) الآن، لكل مخطط أولي، يعمل الذكاء الاصطنا_ي كبنّاء. يقوم بملء الثغرات ?? لإنشاء برنامج كامل.
إذا صنع الذكاء الاصطنا_ي 5 مخططات ومالأ كل منها 10 مرات، فلديه الآن 50 برنامجاً مختلفاً تماماً للاختبار.
ولأن المخططات كانت مختلفة، فإن هذه البرامج الخمسين متنوعة هيكلياً. إنها ليست مجرد إعادة كتابة لنفس الفكرة؛ بل هي مناهج مختلفة حقاً.
الخطوة 3: المفتش (التحقق - Verify) أخيراً، نقوم بتشغيل كل هذه البرامج عبر اختبار ما. نحتفظ بالبرامج التي تعمل ونختار الأفضل بينها.
3. النتائج: الرخيص مقابل الغالي
اختبر الباحثون هذه الطريقة على اختبار برمجة قياسي يسمى HumanEval+ باستخدام ثلاث نسخ من ذكاء Google Gemini الاصطنا_ي:
Lite: النموذج الصغير، الرخيص، والسريع.
Flash: النموذج المتوسط.
Pro: النموذج الكبير، الغالي، والذكي.
النتائج الكبرى:
بالنسبة للروبوت الرخيص (Lite): كانت طريقة "Sketch-and-Verify" بمثابة نقطة تحول.
إذا طلبنا من روبوت Lite المحاولة 100 مرة بالطريقة العادية (العينات المسطحة - Flat Sampling)، فقد حل حوالي 53% من المشكلات الصعبة.
إذا استخدمنا طريقة "Sketch-and-Verify" (صنع 10 مخططات وملء كل منها 10 مرات)، فقد حل 79% من المشكلات الصعبة.
القياس: الأمر يشبه قولك لطالب: "لا تكتب 100 مقال حول نفس الموضوع. اكتب 10 مخططات لـ 10 مواضيع مختلفة، ثم املأها". الطالب يتعلم أكثر ويحصل على درجة أفضل بنفس القدر من الجهد.
بالنسب بالنسبة للروبوت الغالي (Pro): لم تساعد الطريقة كثيراً.
روبوت Pro ذكي جداً بالفعل، وفكرته "الافتراضية" عادة ما تكون صحيحة. إجباره على رسم مخططات لاستراتيجيات مختلفة أدى في الواقع إلى جعل أدائه أسوأ قليلاً لأنه تشتت عن حدسه الأفضل.
القاعدة: إذا كان لديك روبوت فائق الذكاء، اتركه يفكر بعمق (Greedy). أما إذا كان لديك روبوت رخيص، فاستخدم "Sketch-and-Verify" لإجباره على التفكير بإبداع.
4. الخلاصة
تجادل الورقة البحثية بأن Sketch-and-Verify هي طريقة ذكية لاستثمار قوة الحوسبة الإضافية عندما تكون عالقاً مع نموذج ذكاء اصطنا_ي أصغر وأرخص.
ليست سحراً: هي لا تجعل النموذج الضعيف أقوى من النموذج القوي. إذا كنت تستطيع تحمل تكلفة نموذج "Pro" الغالي، فاستخدمه فحسب.
إنها استراتيجية: إذا كان يجب عليك استخدام النموذج الرخيص (بسبب الميزانية أو السرعة)، فإن هذه الطريقة هي أفضل وسيلة لاستخراج أقصى أداء ممكن منه. إنها تمنع الذكاء الاصطنا_ي من الوقوع في الروتين وتجبره على استكشاف حلول مختلفة، تماماً مثل جلسة عصف ذهني بشري.
باختاً: لا تطلب من الذكاء الاصطنا_ي أن يحاول بجهد أكبر فحسب؛ بل اطلب منه أن يحاول بشكل مختلف.
ملخص تقني: الرسم التخطيطي والتحقق: توسيع الاستدلال الهيكلي أثناء وقت التنفيذ عبر رسم المخططات البرمجية
1. بيان المشكلة
تتناول الورقة قيدًا تشغيليًا محددًا يواجه الممارسين: عند اختيار نموذج كود صغير وفعال من حيث التكلفة (مثل Gemini 3.1 Flash Lite) لأسباب تتعلق بزمن الاستجابة أو الميزانية، كيف يمكن تخصيص قدر محسوب إضافي محدود أثناء وقت الاختبار لتحسين الدقة؟
تعتمد الأساليب القياسية على أخذ العينات المسطح (توليد N من البرامج المرشحة المستقلة واختيار الأفضل عبر التنفيذ). ويجادل المؤلفون بأن أخذ العينات المسطح غير فعال لأنه يعامل فضاء البرامج ككتلة متجانسة. غالبًا ما تخصص النماذج اللغوية الكبيرة (LLMs) كتلة احتمالية عالية لاستراتيجية خوارزمية "نموذجية" واحدة. وبناءً على ذلك، حتى مع درجة حرارة عالية أو N كبيرة، فإن مجموعة المرشحين الناتجة تفتقر إلى التنوع الهيكلي؛ فهي تتكون في الغالب من متغيرات تجميلية سطحية (اختلاف أسماء المتغيرات، التنسيق) لنفس الاستراتيجيات الـ 2–3. وإذا كانت استراتيجية النموذج الافتراضية غير صحيحة لمشكلة معينة، فمن المرجح أن يفشل أخذ العينات المسطح في اكتشاف الحل الصحيح بغض النظر عن عدد العينات.
2. المنهجية: SKETCHVERIFY
يقترح المؤلفون SKETCHVERIFY، وهي طريقة تعيد هيكلة حساب وقت التنفيذ عبر تحليل فضاء البحث إلى استراتيجية خوارزمية وتفاصيل تنفيذ. مستوحاة من رسم المخططات البرمجية (Solar-Lezama, 2008, 2013) والعمل السابق على اختبار المترجمات المدعوم بالنماذج اللغوية الكبيرة (OBsmith, Jiang et al., 2026b)، تعمل هذه الطريقة عبر أربع مراحل:
المرحلة 1: توليد المخطط (التحفيز القائم على الفئة أولاً)
حصر الفئات: يتم توجيه النموذج اللغوي الكبير لسرد K من الاستراتيجيات الخوارزمية المختلفة جوهريًا (مثل "الجدول الهاشي - hash map"، "المؤشران - two pointers"، "البرمجة الديناميكية - dynamic programming") بلغة طبيعية. هذا يجبر النموذج على التفكير في فضاء الاستراتيجية قبل كتابة الكود.
رسم المخطط (Sketching): لكل استراتيجية، يولد النموذج اللغوي برنامجًا جزئيًا (مخططًا) حيث تكون الخوارزمية، وهياكل البيانات، وتدفق التحكم محددة بالكامل، ولكن يتم استبدال تفاصيل التنفيذ (التعبيرات، الشروط، حدود الحلقات) بعلامات استفهام ??. الهدف هو وجود 4–8 ثغرات في كل مخطط.
الابتكار الرئيسي: تمنع هذه العملية ذات الخطوتين النموذج التوليدي من التركيز على استراتيجية افتراضية واحدة، مما يضمن تنوعًا هيكليًا عبر المخططات الـ K.
المرحلة 2: الملء
يتم ملء كل مخطط صالح M من المرات لإنتاج K×M من البرامج الكاملة.
لتشجيع التباين داخل مخطط واحد، يتم اشتراط أن يكون كل ملء ثالث مشروطًا بالملء السابق مع الطلب منه تقديم تنفيذ مختلف.
المرحلة 3: التحقق
يتم تصفية المرشحين للتأكد من قابلية التجميع والخلو من الانهيارات أثناء التنفيذ.
يتم تنفيذ المرشحين الناجين على D من مدخلات الاختبار المتنوعة (التي تم توليدها عبر نهج مشابه قائم على المخططات).
يتم إنشاء بصمة تنفيذ لكل مرشح: وهي عبارة عن متجه من أزواج (الحالة، المخرجات). تشير البصمات المتطابقة إلى التكافؤ السلوكي.
المرحلة 4: الاختيار
يتم تجميع المرشحين حسب بصمات التنفيذ الخاصة بهم.
يتم اختيار الكتلة الأكبر (التي تمثل الإجماع السلوكي الأكثر قوة) كمرشح.
من الكتلة الأكبر، يتم إرجاع البرنامج الأقصر (مبدأ نصل أوكام). قاعدة الاختيار هذه مطابقة لعمل "التصويت الدلالي" (Semantic Voting) المتزامن، مما يعزل فائدة التوليد المهيكل عن آلية الاختيار.
3. المساهمات الرئيسية
إطار عمل SKETCHVERIFY: يقدم سياسة "داخل الفئة" (within-tier) للأداء مقابل التكلفة تطبق رسم المخططات البرمجية على توسيع وقت التنفيذ. إنه يحلل فضاء البحث إلى K (استراتيجيات) و M (تنفيذات)، محققًا منحنى توسيع (pass@1) أكثر حدة من أخذ العينات المسطح على النماذج الضعيفة.
تحليل باريتو للتكلفة والجودة: يقدم تحليلًا دقيقًا على معيار HumanEval+، وتحديدًا بإعادة تحليل "مجموعة فرعية صعبة" مكونة من 19 مشكلة فشل فيها نموذج Lite (النموذذي/الجشع) في اجتياز الاختبار.
داخل الفئة: يتفوق الرسم التخطيطي على أخذ العينات المسطح عند تساوي عدد المرشحين. في المجموعة الفرعية الصعبة، يستعيد Lite Sketch (K=2,M=5) نسبة 58% من المشكلات مقابل 26% لأخذ العينات المسطح (N=10). وحتى مع زيادة الميزانية بمقدار 3 أضعاف، فإن أخذ العينات المسطح (N=50) يصل فقط إلى 47%، ولا يزال يخسر أمام تكوين الرسم التخطيطي الأرخص.
عبر الفئات: الرسم التخطيطي لا يحل محل ترقية النموذج. النماذج الأقوى (مثل Gemini Pro الجشع) تتفوق على تكوينات Lite+Sketch في كل من التكلفة والدقة. الرسم التخطيطي هو مكمل لترقية الفئة وليس بديلًا لها.
التفكيك القائم على الفئة: يقترح استراتيجية تحفيز محددة (سرد أسماء الاستراتيجيات قبل الكود) والتي تعد حاسمة لتوليد تنوع هيكلي بدلاً من المتغيرات التجميلية.
توصيف المقايضة بين K و M: من خلال مسوحات التوسيع، يوضح المؤلفون أن العلاقة بين K و M ليست خطية أحادية الاتجاه. التخصيصات المختلطة (مثل K=2,M=5) غالبًا ما تتفوق على التطرفات (الخالصة المسطحة K=1 أو الخالصة المخططة M=1)، ومجرد زيادة K لا يؤدي دائمًا إلى مكاسب خطية (على سبيل المثال، K=5,M=10 كان أداؤه أقل من K=2,M=5 في بعض المقاييس).
القابلية للتركيب: يثبت أن التوليد المهيكل يتوافق بسلاسة مع الاختيار القائم على التنفيذ (التصويت الدلالي). تعمل الطريقة كمولد لمجموعة مرشحين متنوعة، بينما يظل المختار محايدًا تجاه طريقة التوليد.
4. النتائج التجريبية
المعايير: تم التقييم على HumanEval+ (164 مشكلة بايثون مع مجموعات اختبار معززة). تمت الإشارة إلى التحقق عبر المعايير الأخرى مثل MBPP+ و LiveCodeBench كعمل مستقبلي.
النماذج: ثلاثة مستويات من نماذج Gemini (Pro, Flash, Flash Lite) عند مستويات تفكير منخفضة.
أداء المجموعة الفرعية الصعبة (19 مشكلة حيث يفشل Lite الجشع):
Lite Sketch (K=10,M=10): حقق 79% pass@1.
Lite Flat (N=100): حقق 53% pass@1.
Lite Sketch (K=2,M=5): حقق 58% pass@1 (بتكلفة أقل من Flat N=50).
Flash/Pro Greedy: يتفوق على جميع تكوينات Lite، مما يؤكد أن قدرة النموذج هي المحرك الأساسي للدقة.
منحنيات التوسيع: على مجموعة HumanEval+ الكاملة، يصل أخذ العينات المسطح لنموذج Lite إلى التشبع عند ~89% pass@1. أما SKETCHVERIFY فيكسر هذا السقف، ليصل إلى 93% عند K=10,M=10. ومع ذلك، في نماذج Flash و Pro، حيث تقترب النماذج من التشبع، تكون المكاسب من الرسم التخطيطي هامشية أو غير موجودة مقارنة بفك التشفير الجشع.
5. الأهمية والادعاءات
تضع الورقة SKETCHVERIFY كـ سياسة أداء مقابل التكلفة داخل الفئة الواحدة، وليس كتحسين شامل للدقة.
قاعدة الممارس: إذا كان هناك فئة نموذج أقوى متاحة، فاستخدم فك التشفير الجشع على تلك الفئة. إذا كنت مقيدًا بنموذج أضعف (بسبب زمن الاستجابة، أو النشر، أو الميزانية)، فإن SKETCHVERIFY هو الطريقة الأكثر فعالية من حيث التكلفة لإنفاق وقت حساب إضافي أثناء الاختبار.
الآلية: تنجح الطريقة من خلال فرض استكشاف استراتيجيات خوارزمية مختلفة (التنوع الهيكلي) صراحةً، بدلاً من الاعتماد على عشوائية أخذ العينات المسطح للعثور بالصدفة على نهج جديد.
القيود: يقر المؤلفون بوجود قيود تشمل الاعتماد على عائلة نماذج واحدة (Gemini)، ومستوى تفكير واحد، وحقيقة أن جودة المخطط محدودة بتوزيع الاستراتيجية الخاص بالنموذج نفسه (إذا لم يستطع النموذج تصور الاستراتيجية الصحيحة، فلن يتمكن الرسم التخطيطي من توليدها). كما يشيرون إلى زيادة قدرها ~7% في عدد الرموز (tokens) لمرحلة توليد المخطط.
تخلص الورقة إلى أنه بينما يعد الرسم التخطيطي فعالًا للغاية للنماذج الضعيفة التي تعاني من نقص التنوع الاستراتيجي، فإنه ليس حلًا سحريًا للنماذج التي وصلت بالفعل إلى سقف قدراتها أو للمشكلات التي تقع استراتيجيتها الصحيحة تمامًا خارج معرفتها الكامنة.