التفكير المرئي (CoT) لا يحسّن توليد شيفرات SQL وpandas بشكل شامل: دراسة جديدة

اختبر باحثون إحدى أكثر نصائح هندسة الموجّهات (prompting) رواجاً، «دع النموذج يفكّر بصوت عالٍ»، على مهمة يمكن التحقق منها موضوعياً: توليد شيفرة تحليلية قابلة للتشغيل. تقارن الورقة الأولية arXiv 2610.10639 بين SQL وPython (pandas) على طلبات متطابقة. لم يجد المؤلفون مكسباً شاملاً في الدقة من سلسلة الاستدلال المرئية (Chain-of-Thought)، ولا فائدة مستقرة من الاستدلال «بلغة المهمة». ويتوقف التأثير على الشخصية (persona) في الموجّه، واللغة المستهدفة، وإعدادات النموذج، ووضع الاستدلال الداخلي.

كيف صُمّمت التجربة

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

جمعت التجربة بين عدة عوامل:

• صياغة الشخصية في الموجّه؛
• اللغة المستهدفة: SQL أو Python (pandas)؛
• صيغة CoT المرئي، بما فيها الاستدلال بتمثيل اللغة المستهدفة؛
• بادئات ضابطة؛
• التوليد المباشر دون استدلال مرئي؛
• إعدادات الاستدلال الداخلي للنموذج.

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

ماذا أظهرت النتائج

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

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

ماذا تفعل الفرق التي تبني text-to-SQL والوكلاء التحليليين

لا ينبغي اعتبار الموجّه «think step-by-step» قيمة افتراضية. يجب اختباره على بياناتكم الخاصة كما يُختبر أي معامل آخر. وفيما يلي الحد الأدنى من الممارسات المستخلصة من الدراسة:

• احتفظوا بالتوليد المباشر دون CoT مرئي كخط أساس إلزامي، وقارنوا به بحسب نتيجة تنفيذ الاستعلامات.
• اختبروا الموجّه مع النموذج والشخصية واللغة المستهدفة ووضع thinking معاً. فنقل الإعدادات بين التوليفات غير موثوق.
• أضيفوا بادئات ضابطة للتمييز بين فائدة الاستدلال وأثر القالب الطويل.
• في نماذج الاستدلال (reasoning)، تحققوا على حدة مما إذا كان CoT المرئي يعيق الاستدلال الداخلي.
• لا تدرجوا نصائح مثل «فكّر في SQL» في موجّه النظام دون قياس على مخططكم.

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