تقييمات النماذج اللغوية الكبيرة: لماذا أصبح اختبار الذكاء الاصطناعي أهم مهارة في

فجوة الجودة التي لا يتحدث عنها أحد

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

باختصار: تقييم النماذج اللغوية الكبيرة (LLM Evals) — القياس المنهجي لما إذا كانت أنظمة الذكاء الاصطناعي تعمل لحالات الاستخدام الإنتاجية المحددة — أصبح أهم عنق زجاجة بين الاستثمار في الذكاء الاصطناعي وتحقيق القيمة منه، وأسرع مهارة مهنية نمواً في الصناعة.

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

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

ما هي التقييمات فعلاً (وما ليست عليه)

التقييم هو عملية منهجية وقابلة للتكرار لقياس ما إذا كانت مخرجات نظام الذكاء الاصطناعي تستوفي معايير جودة محددة لمهمة بعينها. هذا التعريف يبدو بسيطاً. تطبيقه بشكل صحيح صعب للغاية.

التقييمات ليست مقاييس معيارية (Benchmarks). المقاييس المعيارية — مثل MMLU وHumanEval وSWE-bench — تقيس القدرات العامة للنموذج عبر مهام موحدة. تجيب عن السؤال: “ما مدى ذكاء هذا النموذج بشكل عام؟” التقييمات تجيب عن سؤال مختلف جذرياً: “هل يؤدي هذا النموذج هذا الشيء المحدد بشكل جيد بما يكفي لمستخدمينا؟” نموذج يحقق 92% في MMLU قد يهلوس 15% من كتالوج منتجاتك. المقياس المعياري لا يستطيع إخبارك بذلك. فقط تقييم مبني لهذا الغرض يستطيع.

التقييمات ليست اختبارات وحدة (Unit Tests). اختبار الوحدة يؤكد أن دالة تُعيد مخرجاً متوقعاً لمدخل معين. مخرجات النماذج اللغوية الكبيرة غير حتمية ومتغيرة الصيغة وغالباً لها إجابات مقبولة متعددة. لا يمكنك كتابة assertEqual(llm_output, expected_output) والاكتفاء بذلك. أُطر التقييم يجب أن تتعامل مع المطابقة الضبابية والتشابه الدلالي والتقييم متعدد الأبعاد والعينات الإحصائية عبر مئات أو آلاف حالات الاختبار.

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

التحول الذي يحدد لحظة التقييم في 2026 هو الانتقال من “هل يعمل النموذج؟” — سؤال تجيب عنه المقاييس المعيارية والعروض التوضيحية — إلى “كيف نقيس بشكل منهجي ما إذا كان يعمل لحالة استخدامنا؟” — سؤال تجيب عنه خطوط أنابيب تقييم مخصصة يبنيها أشخاص يفهمون كلاً من التكنولوجيا والمجال.

الدراسات التي أثبتت المشكلة

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

تتبعت مبادرة بحثية من Stanford استخدام أدوات البرمجة بالذكاء الاصطناعي عبر أكثر من 100,000 مهندس برمجيات في أكثر من 600 شركة. وجدت الدراسة أن أدوات البرمجة بالذكاء الاصطناعي زادت إنتاجية المطورين بنسبة 15 إلى 20 بالمائة في المتوسط — لكن مع تباين هائل. تفوق الذكاء الاصطناعي في المهام البسيطة الجديدة بمكاسب إنتاجية من 30 إلى 40 بالمائة، لكنه قد يُقلل الإنتاجية فعلياً للمهام المعقدة في قواعد الكود الناضجة. النتيجة الإجمالية أخفت مشكلة أعمق: حسب طريقة قياس الإنتاجية، تروي النتائج قصصاً مختلفة تماماً.

بشكل منفصل، أجرت تجربة معشاة مضبوطة صارمة من METR (أبحاث تقييم النماذج والتهديدات) دراسة على 16 مطوراً مفتوح المصدر ذوي خبرة يُنجزون 246 مهمة حقيقية في مستودعات ساهموا فيها لسنوات. باستخدام نماذج حدودية شملت Cursor Pro مع Claude 3.5 و3.7 Sonnet، وجدت الدراسة أن أدوات الذكاء الاصطناعي جعلت هؤلاء المطورين ذوي الخبرة أبطأ بنسبة 19 بالمائة — رغم أن المطورين اعتقدوا أنهم أسرع بنسبة 20 بالمائة. فجوة الإدراك كانت لافتة بقدر النتيجة نفسها.

في المقابل، تُظهر بيانات GitHub نفسها معدل قبول يقارب 30 بالمائة لاقتراحات Copilot، لكن معدل القبول لا يقول شيئاً عما إذا كان الكود المقبول صحيحاً أو آمناً أو قابلاً للصيانة.

المشكلة لم تكن أن الأدوات فشلت. المشكلة أن لا أحد حدد ما يعنيه النجاح بدقة كافية لإنتاج إجابة حاسمة. ما الذي يُعتبر “إنتاجية”؟ أسطر الكود؟ الميزات المُطلقة؟ الأخطاء المُدخلة؟ الوقت للدمج؟ كل مقياس يروي قصة مختلفة، وبدون إطار تقييم شامل يلتقط الصورة الكاملة، بقيت الصناعة تتجادل حول الحكايات.

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

انفجار الأدوات

إدراك أن التقييمات هي عنق الزجاجة أنتج جيلاً جديداً من الأدوات المصممة خصيصاً لقياس جودة الذكاء الاصطناعي.

DeepEval برز كإطار عمل رائد مفتوح المصدر مصمم خصيصاً لتقييم خطوط أنابيب RAG وتطبيقات النماذج اللغوية الكبيرة. يوفر أكثر من أربعة عشر مقياساً مدمجاً تشمل الأمانة (هل يبقى المخرج مؤسساً على السياق المسترجع؟)، والصلة (هل وجد نظام الاسترجاع المستندات الصحيحة؟)، واكتشاف الهلوسة، وتقييم السمّية، ومقاييس مخصصة خاصة بالمجال. يتكامل DeepEval مباشرة مع pytest وخطوط أنابيب التكامل والنشر المستمر (CI/CD)، معاملاً التقييمات كاختبارات وحدة — نموذج مألوف لمعظم المطورين. مقاييسه ذاتية الشرح تخبر المطورين بالتحديد لماذا لا يمكن أن تكون الدرجة أعلى، محوّلة التقييم إلى تغذية راجعة قابلة للتنفيذ.

Qodo (المعروفة سابقاً بـ CodiumAI، تأسست في 2022) اتخذت نهجاً مختلفاً، مركزة على جودة الكود المُولّد بالذكاء الاصطناعي. إصدارها 2.0 في فبراير 2026 قدّم بنية مراجعة كود متعددة الوكلاء مع وكلاء متخصصين في الصحة والأمان والأداء وإنفاذ المعايير. رؤية Qodo هي أن الكود المُولّد بالذكاء الاصطناعي يحتاج إلى فحوصات جودة مُعايرة بالذكاء الاصطناعي — أدوات التحليل الساكن التقليدية لم تُصمم لأنماط الفشل التي يُظهرها الكود المُولّد بالنماذج اللغوية الكبيرة. صنّفت Gartner شركة Qodo كشركة ذات رؤية في مربعها السحري لعام 2025 لمساعدي البرمجة بالذكاء الاصطناعي.

Braintrust، الموثوقة من فرق Notion وStripe وVercel وAirtable، بنت التقييم كميزة أساسية في منصتها لتطوير الذكاء الاصطناعي. Arize AI تقدم Phoenix، مجموعة أدوات مفتوحة المصدر لمراقبة النماذج اللغوية الكبيرة في الإنتاج. LangSmith توفر قدرات تقييم ضمن منظومة LangChain. Weights & Biases أضافت Weave لتقييم النماذج اللغوية الكبيرة إلى جانب تتبع تجارب التعلم الآلي الراسخ لديها. النمط متسق: كل منصة إنتاجية جادة للذكاء الاصطناعي تعامل الآن التقييم كميزة أساسية وليس فكرة لاحقة.

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

التقييمات كرأس مال مهني

ما يجعل لحظة التقييم لافتة ليس الأدوات فحسب. بل التداعيات المهنية. جادل Hamel Husain، مهندس تعلم آلي محترم عمل في GitHub وOuterbounds، بأن كتابة التقييمات هي أهم مهارة منفردة لبنّائي المنتجات العاملين في الذكاء الاصطناعي. أنشأ مع Shreya Shankar أشهر دورة تقييم في الصناعة، مدرّباً أكثر من 2,000 مهندس ومدير منتج — بما في ذلك فرق في OpenAI وAnthropic. استدلاله بنيوي: القدرة على تحديد ما يعنيه “جيد” لنظام ذكاء اصطناعي، ثم قياسه بشكل منهجي، ثم تحسين النظام بناءً على تلك القياسات، هي المهارة التي تفصل الفرق التي تطلق ذكاءً اصطناعياً موثوقاً عن الفرق التي تطلق عروضاً توضيحية. أشار Husain إلى أنه في عمله الاستشاري، يُنفق 60 إلى 80 بالمائة من وقت التطوير في مشاريع الذكاء الاصطناعي على تحليل الأخطاء والتقييم.

هذه ليست مهارة هندسية تقليدية. كتابة تقييمات جيدة تتطلب فهم المجال بعمق كافٍ لتحديد معايير الجودة التي لا يستطيع مهندس غير خبير تحديدها. تتطلب فهم الإحصاء بما يكفي لمعرفة متى تكون الدرجة ذات معنى ومتى تكون ضوضاء. تتطلب فهم أنماط فشل النماذج اللغوية الكبيرة — الهلوسة والتملّق وانتهاكات الصيغة وعدم الاتساق عبر التشغيلات — بما يكفي لتصميم اختبارات تلتقطها.

أظهر Brendan Foody، الرئيس التنفيذي لشركة Mercor البالغ من العمر اثنين وعشرين عاماً وأصغر مؤسس أمريكي لشركة أحادية القرن، حجم الفرصة. Mercor، التي نمت من مليون دولار إلى 500 مليون دولار في الإيرادات السنوية في سبعة عشر شهراً، توظف أكثر من 30,000 خبير مجال لتقييم مخرجات نماذج الذكاء الاصطناعي لعملاء تشمل OpenAI وAnthropic وستة من شركات Magnificent Seven التكنولوجية. تُقدّر الشركة الآن بـ 10 مليارات دولار. أطروحة Foody بسيطة: كل شركة تنشر ذكاءً اصطناعياً تحتاج لإثبات أنه يعمل، ولا أي منها تقريباً تمتلك القدرة الداخلية للقيام بذلك بدقة. الشركات التي توفر هذا الإثبات — عبر الأدوات أو الاستشارات أو خدمات التقييم المُدارة — تستحوذ على طلب لم يكن موجوداً تقريباً قبل عامين.

النصيحة المهنية الناشئة من هذا التحول محددة: تعلم كتابة مجموعات بيانات التقييم، وتعلم تصميم معايير التسجيل، وتعلم أُطر مثل DeepEval وBraintrust، وتعلم كيفية إيصال نتائج التقييم للمعنيين غير التقنيين. الشخص الذي يستطيع الدخول إلى اجتماع والقول “درجة أمانة خط أنابيب RAG لدينا انخفضت من 0.87 إلى 0.72 بعد آخر تحديث للنموذج، إليكم تحليل السبب الجذري، وإليكم الإصلاح” — هو حالياً أحد أكثر الأشخاص قيمة في أي منظمة تنشر ذكاءً اصطناعياً.

مفارقة النموذج اللغوي الكبير كحَكَم

أكثر تقنيات التقييم اعتماداً في 2026 هي أيضاً الأكثر إزعاجاً فلسفياً: استخدام نموذج لغوي كبير لتقييم مخرجات نموذج لغوي كبير آخر. نمط النموذج اللغوي الكبير كحَكَم — حيث يُقيّم نموذج حدودي ما إذا كان رد نموذج إنتاجي دقيقاً وذا صلة ومنظماً بشكل جيد — أصبح إجابة الصناعة العملية لمشكلة الحجم. لا يمكن أن يراجع البشر كل مخرج. لكن يمكن لنموذج قوي مراجعتها.

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

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

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

كيف تبدو الممارسة الجيدة للتقييم

المنظمات التي اكتشفت التطوير المدفوع بالتقييم تتشارك مجموعة أنماط تستحق التدوين.

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

أدِر نسخ تقييماتك كالكود. مجموعات بيانات التقييم ومعايير التسجيل وإعدادات العتبات يجب أن تعيش في نظام التحكم بالنسخ إلى جانب كود التطبيق. عندما تغيّر أمراً (prompt)، يجب أن تستطيع تشغيل مجموعة التقييم ورؤية ما إذا تحسنت الجودة أو تدهورت قبل أن يصل التغيير إلى الإنتاج.

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

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

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

الحقيقة غير المريحة

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

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

الفرق التي تستثمر في قدرات التقييم الآن لا تقوم بعمل روتيني. إنها تبني البنية التحتية التي ستفصل منتجات الذكاء الاصطناعي التي تنجو من منتجات الذكاء الاصطناعي التي كانت مجرد عروض توضيحية باهظة الثمن.

الأسئلة الشائعة

المصادر والقراءات الإضافية

• Why AI Evals Are the Hottest New Skill for Product Builders — Hamel Husain & Shreya Shankar, Lenny’s Podcast
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR
• DeepEval: Open-Source LLM Evaluation Framework — GitHub
• Why Experts Writing AI Evals Is Creating the Fastest-Growing Companies in History — Brendan Foody, Lenny’s Podcast
• LLM Evals: Everything You Need to Know — Hamel Husain
• LLM-as-a-Judge: A Complete Guide — Evidently AI
• Stanford Software Engineering Productivity Research — AI Impact