Fable 5 وOpus 4.8 وSonnet 4.6: كيف نقارن نماذج LLM بإنصاف على شيفرتنا الخاصة

عندما يصدر نموذج جديد، يجيب الإعلان عن سؤال «إلى أي حد هو أفضل في الاختبارات المعيارية» — ولا يجيب عن السؤال الوحيد الذي يهمني: ما الذي سيغيّره في عملي. أجريت تجربة مضبوطة: ثلاثة نماذج من Claude — Fable 5, Opus 4.8 و Sonnet 4.6 — تلقّت مهمة متطابقة حرفيًا لتدقيق قاعدة شيفرة هذه المدونة، كل منها في نسخة معزولة من المستودع، ووفق معايير تقييم متفق عليها مسبقًا. في المقال — المنهجية نفسها التي يمكن تكرارها على أي مشروع، والنتائج، وبشكل منفصل — كيف انكسرت التجربة مرتين وما الذي علّمتنا إياه.

لماذا لا تجيب الاختبارات المعيارية عن سؤالي

للاختبارات المعيارية العامة مشكلتان، وكلتاهما جوهرية. الأولى — تلوث البيانات: تتسرب أمثلة الاختبار إلى مجموعات التدريب، فيتذكر النموذج الإجابات جزئيًا بدلًا من حل المهمة. وهذا ليس شكًا هامشيًا، بل موضوع اتجاه بحثي كامل: مراجعة Xu وزملائه (2024) تنظم أبحاث تلوث الاختبارات المعيارية، و مراجعة EMNLP 2025 توثّق استجابة الصناعة — الانتقال من الاختبارات الثابتة إلى المولّدة ديناميكيًا.

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

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

تصميم التجربة: أمر واحد، ثلاثة عوالم معزولة

كانت المهمة لجميع النماذج الثلاثة متطابقة حرفيًا — اختلف فقط اسم الفرع ومجلد النتائج. أربع مراحل: تدقيق نظام المقالات ثنائي اللغة للمدونة مع إثبات كل نتيجة في صورة файл:строка مع اقتباس الشيفرة؛ اختيار حلول لأهم ثلاث نتائج مع وصف المقايضات؛ تنفيذ إصلاح واحد مع التحقق الذاتي؛ ملاحظة عن النتائج بالروسية والإنجليزية. دورة كاملة من العمل الهندسي، لا «سؤال وجواب» معزول — وهذا النهج توصي به Anthropicأيضًا: تقييم الوكلاء على مهام من منتج حقيقي، وفق معايير متفق عليها قبل التشغيل.

ثلاث قواعد جعلت المقارنة نزيهة:

العزل. عمل كل نموذج في git worktree منفصل — نسخته الخاصة من دليل العمل مع فرعه الخاص. لم يكن بوسع النماذج فعليًا رؤية نتائج بعضها أو إعاقة بعضها.

الحماية من الهلوسة — في الأمر نفسه. السطر المحوري في المهمة: «النتيجة المختلقة (شيفرة غير موجودة، سطر خاطئ) أسوأ من غياب النتيجة». بدون هذا الحافز، يميل النموذج الذي يُطلب منه إيجاد مشكلات إلى «إيجادها» في كل الأحوال. ومعه — كل نتيجة ملزمة بأن تصمد أمام تحقق يدوي.

استبعاد التلميحات من التقييم. في المستودع ملف CLAUDE.md يصف المزالق المعروفة للمشروع — مثل المسارات النسبية إلى الأصول التي تنكسر على عناوين URL ذات بادئة لغوية. النماذج الثلاثة تقرأ هذا الملف، لذا فإن مثل هذه النتائج «مجانية»: تُحتسب للدقة، لا للعمق.

المعايير: تقييم ما يمكن التحقق منه يدويًا فقط

قبل التشغيل ثبّتُ ستة محاور بخمس نقاط لكل منها: دقة التدقيق (تحقق يدوي من عينة النتائج عبر файл:строка)، العمق (نتائج مؤكدة غير موجودة في التلميحات)، جودة التفكير في المقايضات، الشيفرة وواقعية التحقق الذاتي، جودة النص الروسي والإنجليزي، الانضباط (صفر أسئلة للإنسان، ولا انتهاك واحد للقيود). المبدأ نفسه كما في مراجعة الشيفرة الجيدة: كلما قل اعتماد المحور على الذوق وزداد على حقيقة قابلة للتحقق، زادت الثقة به.

كيف انكسر كل شيء في المرة الأولى

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

“وكلاء AI المتوازون في مجلد واحد ليسوا تجربة متوازية. إنهم صراع واحد كبير بثلاثة مؤلفين.”

– الاستنتاج الذي كلفني إعادة التشغيل

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

النتائج: أين تتشابه النماذج وأين تختلف

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

بعد ذلك تبدأ الاختلافات:

	Fable 5	Opus 4.8	Sonnet 4.6
الاكتشافات المؤكدة	11	5	9
فريدة وغير بديهية	3	1	2
التحقق الذاتي من الإصلاح	عرض تكاملي على قاعدة بيانات مؤقتة، xmllint، إسناد اختبار فاشل ليس ملكه	linter + عرض؛ التقط خطأه الخاص	linter فقط وقائمة المسارات
الرموز / الوقت	164k / 21 دقيقة	101k / 12 دقيقة	131k / 12 دقيقة
النتيجة حسب المعايير (من 30)	30	24	25,5

الاختلافات النوعية أكثر إفادة من الدرجات. Opus 4.8 — هو الوحيد الذي لم يلاحظ العنوان المعطوب Content-Type في sitemap (وقد وجده الآخران) وتركه في إصلاحه الخاص؛ كما تسربت إلى نصه الروسي كلمة إنجليزية — «и even путь к картинке». أما Sonnet 4.6 فقد أنجزت إصلاحًا صحيحًا، لكن تحققها الذاتي كان تصريحيًا: linter بدلًا من التشغيل. وتميزت Fable 5 تحديدًا في التحقق الذاتي: اكتشفت أن php على جهازي هو غلاف حول حاوية docker مثبتة على الدليل الرئيسي، فأعادت بناء جميع الفحوصات عبر حاويات لمرة واحدة، وشغّلت إصلاحها تكامليًا على قاعدة بيانات مؤقتة. الفرق بين «لقد فعلت» و«لقد أثبتت أنني فعلت» هو المحور الأكثر تمييزًا لمهام الوكلاء.

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

حَكَم من بين المشاركين

أجرى التقييم حسب المعايير Fable 5 — النموذج نفسه الذي شارك في المقارنة. هذه ثغرة منهجية، ويجب الحديث عنها بصراحة: حكّام LLM يبالغون منهجيًا في تقييم نصوصهم الخاصة، ويزداد هذا الميل قوة كلما تعرف النموذج على نصوصه أكثر — وقد بيّن ذلك بحث Panickssery وزملائه في NeurIPS 2024. ويمكن تخفيف التحيز بطريقتين، وقد استخدمت كلتيهما: أولًا، إبعاد المعايير قدر الإمكان عن محاور الذوق نحو الحقائق القابلة للتحقق — دقة الأسطر، واكتمال الإصلاح، والكلمة الأجنبية المتسربة لا تعتمد على أهواء الحَكَم؛ وثانيًا، الإعلان الصريح عن تضارب المصالح وإحالة المحاور الخلافية إلى تحقق متقاطع من نموذج آخر أو إنسان. أما المحاور الذاتية في نتيجتي — جودة النص وجودة الاستدلال — فينبغي قراءتها مع هذا التصحيح.

حدود الصدق

تشغيل واحد لكل نموذج هو n=1: الاختلافات بدرجة أو درجتين لا تعني شيئًا، ولا يجدر الوثوق إلا بالفجوات النوعية — خطأ فائت، عمق التحقق الذاتي. تقيس التجربة ثلاثة نماذج على مهمة واحدة في نطاق واحد؛ ولا يلزم من ذلك أن «Fable 5 أفضل عمومًا». وينبغي تذكر التكلفة: أنفق النموذج الأعلى رموزًا أكثر بـ1.6 مرة ووقتًا يقارب الضعف مقارنة بأكثر المشاركين اقتصادًا، كما أن سعر رمزه أغلى في ذاته — وبالنسبة للمهام المنتظمة، هذه حجة وزنها معتبر لصالح نماذج أبسط.

ما آخذه لنفسي

اختزلت المنهجية إلى قائمة تحقق قصيرة تصلح لأي مشروع وأي نماذج:

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

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

المصادر والمراجع

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — تنظيم منهجي لمشكلة تلوث المعايير القياسية؛ والحجة الرئيسية لصالح الاختبارات على كودك الخاص.
• قياس أداء النماذج اللغوية الكبيرة في ظل تلوث البيانات: من التقييم الثابت إلى التقييم الديناميكي (EMNLP 2025) — كيف تبتعد الصناعة عن الاختبارات الثابتة نحو الديناميكية؛ تجربتي هي حالة خاصة من الاختبار الديناميكي.
• إزالة الغموض عن تقييمات وكلاء الذكاء الاصطناعي (Anthropic Engineering, 2026) — ممارسة تقييم الوكلاء: مهام من منتج حقيقي، معايير قابلة للتحقق، التمييز بين المسار والنتيجة.
• مقيّمو النماذج اللغوية الكبيرة يتعرفون على مخرجاتهم الخاصة ويفضلونها (NeurIPS 2024) — لماذا يبالغ النموذج الحَكَم في تقييم نفسه وما العمل حيال ذلك.
• تشغيل جلسات متوازية باستخدام worktrees (Claude Code Docs) — آلية العزل القياسية لجلسات الوكلاء المتوازية، والتي بدونها انهار التشغيل الأول للتجربة.