كيفية إجراء Benchmark لنماذج AI من أجل العمل الحقيقي

قِس أداء نماذج AI على العمل الذي تخطط لإطلاقه، لا على leaderboard صُمم لمهمة تخص شخصًا آخر. يمكن لـ benchmark عام أن يحدد مرشحًا قويًا، لكنه لا يستطيع إخبارك بما إذا كان ذلك النموذج سينجز سير عملك بشكل موثوق.

الجمهور: متوسط — المطورون، وفرق المنتجات، والمشترون التقنيون الذين يختارون نموذجًا لتطبيق حقيقي.

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

ما السؤال الذي ينبغي أن يجيب عنه benchmark لنموذج AI؟

ينبغي أن يجيب benchmark مفيد عن سؤال تشغيلي واحد:

تجبر هذه الجملة ستة تفاصيل على الظهور بوضوح:

عادةً ما تثبّت benchmarks العامة تركيبة مختلفة من هذه المتغيرات. ولا تزال Model Cards وملاحظات الإصدارات مفيدة: فهي تضيق قائمة المرشحين وتكشف الوسائط المدعومة، وحدود السياق، والأسعار، وسلوك السلامة المعروف. توضح إصدارات يوليو 2026 هذا الفرق. نشرت OpenAI نتائج واسعة حول القدرات والسلامة لـ GPT-5.6، بينما وثقت Google انخفاض استخدام الرموز والسعر في Gemini 3.6 Flash مقارنةً بنموذج Flash السابق. هذه مؤشرات أولية مفيدة، وليست قياسات لـ prompt أو أدواتك أو بياناتك أو ميزانية أخطائك. (OpenAI، Google)

لماذا يخفي متوسط النقاط الواحد مخاطر الإنتاج؟

تكشف ثلاث benchmarks حديثة المشكلة نفسها من مجالات مختلفة.

يمكن للدرجات الجزئية أن تخفي الفشل الشامل

تقيّم APEX-Accounting النماذج في 160 مهمة محاسبية عبر عشر شركات اصطناعية، باستخدام جداول بيانات وملفات PDF وملفات أخرى. كتب خبراء المحاسبة المهام ومعايير النجاح. شغّل الباحثون تسعة نماذج متقدمة ثماني مرات لكل مهمة، منتجين 11,520 مسارًا.

وصل أقوى نموذج إلى 56.4% وفق مقياس الدرجات الجزئية في الورقة، Mean Criteria@3. ومع ذلك، لم يتجاوز أي نموذج 2.6% في Pass^8، الذي يسأل عما إذا كانت المحاولات الثماني لمهمة ما قد نجحت جميعها. وكان أفضل Pass@8، الذي يسأل عما إذا كانت محاولة واحدة على الأقل من أصل ثماني قد نجحت، هو 21.5%. ولم تُنجز 93 مهمة من أصل 160 إنجازًا مثاليًا من أي نموذج مختبر في أي تشغيل. (APEX-Accounting)

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

يمكن لمخرج صالح أن يفوّت قيد المستخدم

تختبر TREK وكلاء تخطيط السفر في 800 مهمة مقابل قاعدة معرفة اصطناعية تضم 212,530 سجلًا. ويتحقق المقيم من القواعد والحالة النهائية بشكل حتمي بدلًا من مطالبة نموذج لغة آخر بالحكم على الخطة.

أكمل أقوى وكيل مختبر 46.2% من المهام القابلة للتنفيذ بشكل مثالي. وكان خاليًا من الهلوسة في 94.9% وقابلًا للتنفيذ في 86.3%، لكنه استوفى جميع قيود المستخدم في 50.7% فقط. كان النظام قادرًا على إنتاج خطط معقولة وقابلة للحجز، مع تفويت تفضيل ضمني أو متطلب يمتد عبر عدة خطوات. (TREK)

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

قد يكون benchmark نفسه معيبًا

كشف تدقيق أجرته OpenAI على التقسيم العام المكوّن من 731 مهمة في SWE-Bench Pro عن مصدر ثانٍ للثقة الزائفة: بيانات تقييم معيبة. أشار خط أنابيب آلي إلى أن 27.4% من المهام معيبة، بينما صنفت عملية وسم أجراها خمسة مهندسين 34.1% منها كذلك. وشملت المشكلات prompts غير محددة بما يكفي، واختبارات صارمة أكثر من اللازم، واختبارات سمحت بمرور حلول غير مكتملة. وقدّرت OpenAI أن نحو 30% من benchmark كان معيبًا، وسحبت توصيتها السابقة باستخدامه. (تدقيق benchmark من OpenAI)

لا يكون الاختبار الصعب مفيدًا إلا عندما تمر به نتيجة مرجعية معروفة بصحتها، ويفشل فيه ناتج خاطئ للسبب الصحيح.

كيفية إجراء benchmark لنماذج AI في سبع خطوات

1. حدّد القرار قبل الاختبار

اكتب قرار الإنتاج في سطر واحد:

غيّر الأرقام لتناسب منتجك. وحافظ على البنية. فـ benchmark من دون قاعدة قرار يفتح الباب لانتقاء النتائج بعد ظهورها.

افصل بين البوابات الصارمة ومقاييس التحسين:

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

2. ابنِ المهام من العمل، لا من عرض تجريبي

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

يمكن أن تضم المجموعة الأولى العملية 30 إلى 50 مهمة:

هذه النسب قالب بداية، وليست معيارًا إحصائيًا. تحتاج الأنظمة عالية التأثير إلى تغطية أوسع ومراجعة من المجال. احتفظ بمجموعة holdout منفصلة حتى لا يؤدي ضبط prompt إلى الإفراط في ملاءمة benchmark دون ملاحظة.

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

3. حدّد النتائج القابلة للملاحظة

قيّم الأثر أو حالة النظام كلما أمكن:

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

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

4. ثبّت ظروف الاختبار

سجّل الإعداد الكامل لكل تشغيل:

لا تقارن نموذجًا باستخدام prompt مضبوط بنموذج آخر باستخدام prompt عام، إلا إذا كان السؤال تحديدًا هو «أي نظام كامل ينبغي أن نطلقه؟». يجيب benchmark للنموذج وbenchmark للنظام عن سؤالين مختلفين.

تتغير Provider APIs. فعلى سبيل المثال، يذكر دليل النماذج الحالي من Google أن Gemini 3.6 Flash يتجاهل معاملات sampling المهملة، وسيرفضها في الأجيال المستقبلية. يمنع السجل القابل لإعادة الإنتاج تغييرًا صامتًا في الإعداد من الظهور على أنه انحراف في النموذج. (دليل النماذج من Google)

5. أجرِ تجارب متكررة ومزدوجة

شغّل كل مرشح على معرّفات المهام نفسها. تقلل المقارنات المزدوجة الضوضاء الناتجة عن اختلاف صعوبة الاختبارات.

يقيس تشغيل واحد حكاية فردية. أما التشغيلات المتكررة فتكشف التباين:

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

*مرّر كل مرشح عبر المهام والتجارب المتكررة نفسها. قارن النتائج والاتساق وزمن الاستجابة والتكلفة قبل إطلاق محكوم.*

6. افحص حالات الفشل، لا الإجماليات فقط

لكل تجربة فاشلة، خزّن:

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

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

7. طبّق بوابة الإطلاق

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

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

يقلل benchmark المحلي عدم اليقين. لكنه لا يزيل تغير التوزيع، أو تغييرات المزوّد، أو سلوك المستخدمين الجديد، أو أخطاء المقيمين.

بطاقة نقاط تعكس العمل الحقيقي

لا تختزل كل مقياس في رقم موزون واحد مبكرًا جدًا. فقد يخفي رقم واحد فشلًا في السلامة خلف تكلفة أقل أو أسلوب أفضل.

تنسيق بداية قابل لإعادة الإنتاج

خزّن المهام في ملف JSONL ذي إصدارات. أبقِ البيانات الخاصة أو الشخصية خارج المستودع.

{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}

ينبغي أن يفحص المقيم النتيجة، لا أن يبحث عن صياغة مقنعة:

ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };

type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };

function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };

return { passed: Object.values(checks).every(Boolean), checks, }; }

قبل الوثوق بالمهمة، مرّر حلًا مرجعيًا وحلًا خاطئًا عمدًا عبر المقيم. يجب أن ينجح المرجع. ويجب أن تفشل النتيجة الخاطئة للسبب المتوقع.

متى ينبغي استخدام LLM judge؟

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

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

عاير LLM judge مقابل تسميات الخبراء قبل استخدامه على نطاق واسع. فعلت APEX-Accounting ذلك صراحةً: إذ جرى فحص المقيم مقابل 1,687 تسمية بشرية، وحقق F1 قدره 0.970 في تلك الدراسة. وهذا يثبت صلاحية المقيم لمعايير الورقة وبياناتها؛ ولا يجعل المقيم نفسه موثوقًا عالميًا. (APEX-Accounting)

عندما تكون benchmark معيارية مكلفة، يمكن لأخذ العينات التكيفي تقليل تكلفة التقييم. يختار BayesAME العناصر باستخدام أداء النموذج المرجعي التاريخي، ويبلغ عن مقايضات أفضل بين الدقة والتكلفة من عدة baselines عبر benchmarks أكاديمية متعددة. تفترض طريقته الحالية درجات عددية وإشارات تاريخية مفيدة للعناصر. أما بالنسبة إلى مجموعة صغيرة مخصصة حيث يكون التشغيل الكامل ميسورًا، فيظل تشغيل كل مهمة أبسط وأسهل في التدقيق. (BayesAME)

يمكن للأدوات مفتوحة المصدر توفير harness من دون تحديد متطلبات منتجك. يدعم Inspect AI تنفيذ المهام، والتسجيل، وإعادة المحاولات، والتقييم. ويوفر LM Evaluation Harness مجموعة واسعة من المهام الأكاديمية وواجهات النماذج الخلفية. استخدمها عندما تناسبك. وغالبًا ما يكون ملف JSONL ذو إصدارات مع مقيمين خاصين بالمنتج كافيًا لأول benchmark مفيد.

أخطاء شائعة في benchmarking

اختبار المسار السهل فقط

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

تقييم الشرح بدلًا من النتيجة

قد تصف نثرية واثقة إجراءً لم يحدث قط. افحص قاعدة البيانات أو الملف أو استجابة API أو نتيجة الاختبار.

تغيير عدة متغيرات في وقت واحد

إذا غيّرت النموذج وprompt ونظام الاسترجاع والأدوات معًا، فيمكنك مقارنة أنظمة كاملة، لكن لا يمكنك إسناد الفرق إلى النموذج.

الضبط على مجموعة الاختبار

انقل الأمثلة الفاشلة إلى مجموعة التطوير أثناء التكرار. وأكد التغيير على مهام holdout لم تُلمس قبل الإطلاق.

تجاهل التكلفة التي ينشئها الفشل

لا يشمل السعر لكل رمز إعادة المحاولات، أو المراجعة البشرية، أو استدعاءات الأدوات، أو التعافي من إجراء سيئ. قِس التكلفة لكل مهمة ناجحة.

التعامل مع benchmark جديدة باعتبارها حقيقة دائمة

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

فحوص الادعاءات

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

كم عدد الأمثلة التي تحتاج إليها لإجراء benchmark لنموذج AI؟

يمكن لـ 30 إلى 50 مهمة مختارة بعناية أن تكشف الفروق الواضحة وأنماط الفشل. هذا اختبار تجريبي، وليس إثباتًا. وسّع المجموعة عندما تكون القرارات مكلفة، أو تكون الشرائح متنوعة، أو تكون درجات المرشحين متقاربة. أبلغ عن عدم اليقين واحتفظ بمجموعة holdout.

ما الفرق بين pass@k وpass^k؟

يسأل Pass@k عما إذا كانت محاولة واحدة على الأقل من أصل k قد نجحت. ويناسب سير العمل الذي تكون فيه المحاولات المتعددة مقبولة. أما Pass^k فيسأل عما إذا كانت جميع المحاولات k قد نجحت. ويناسب سير العمل الموجه للعملاء أو المؤثر في الآثار الجانبية، حيث يهم الاتساق.

هل ينبغي استخدام LLM لتقييم LLM آخر؟

فقط عندما لا تستطيع الفحوص الحتمية التعبير عن معيار الجودة. اكتب rubric محددًا، وقارن المقيم بتسميات الخبراء، وافحص حالات الاختلاف، وأبقِ البوابات الصارمة الحتمية خارج المقيم.

هل ينبغي أن تحدد التكلفة أم الجودة النموذج الفائز؟

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

قاعدة القرار

قِس سير العمل الذي ستطلقه. قيّم الحالة التي تهمك. كرر المهمة بما يكفي لكشف التباين. افحص حالات الفشل. ثم اختر النموذج الأقل تكلفة الذي يتجاوز كل بوابة صارمة وعتبة الموثوقية المطلوبة.

تساعدك leaderboards في تحديد ما ينبغي اختباره. أما مجموعة مهامك فتحدد ما يستحق حركة المرور في الإنتاج.

المصادر