منظومة التقييم التي أستخدمها لإطلاق وكلاء الذكاء الاصطناعي دون خوف

جدول المحتويات

محدّث في يونيو 2026.

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

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

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

ابدأ بمجموعة اختبارات مبنية من إخفاقات حقيقية

المنظومة لا تكون أفضل من حالات اختبارها، وأفضل حالات الاختبار تأتي من الإنتاج، لا من خيالك. في كل مرة يفشل فيها وكيل في الواقع، ألتقط المُدخل بدقّة (أُسجّل كل تشغيل بمعرّف تتبّع — انظر كيفية تنقيح وكيل في الإنتاج) وأحوّله إلى حالة تقييم:

interface EvalCase {
  id: string;
  input: AgentInput;        // المُدخل الإنتاجي الدقيق
  expected?: string;        // الحقيقة المرجعية، حين توجد
  assertions: Assertion[];  // فحوص صارمة يجب أن تنجح
  rubric?: string;          // لحكَم النموذج اللغوي، حين يكون المُخرَج مفتوحًا
}

ممارستان تهمّان هنا. اسحب من الإنتاج، كي تختبر تقييماتك ما يتعطّل فعلًا، لا ما خمّنتَ أنه قد يتعطّل. وغطِّ النطاق — المسار السعيد، والحالات الحدّية، والمُدخلات الخصامية، والمُدخلات الفارغة/المشوّهة التي تسبّب إخفاقات صامتة. مجموعة اختبارات من 30 إلى 50 حالة مختارة بعناية تلتقط أكثر بكثير من 500 حالة كسولة. أُفضّل امتلاك 40 حالة تمثّل كل منها نمط إخفاق حقيقيًا على ألف حالة تختبر جميعها المسار السهل ذاته.

قيّم بالتأكيدات أولًا، ثم بحكَم نموذج لغوي كبير

ليس كل مُخرَج يحتاج إلى نموذج لتقييمه. ألجأ إلى أرخص مُقيِّم ينجح.

تأكيدات صارمة لكل ما هو مُهيكَل. هل يُحلَّل المُخرَج بوصفه JSON صالحًا؟ هل يحتوي الحقل المطلوب؟ هل التاريخ المُستخرَج ضمن المدى؟ هل استدعى الأداة الصحيحة بالوسائط الصحيحة؟ هذه حتمية، ومجانية، وقاطعة — اكتب منها قدر ما تستطيع.

const assertions: Assertion[] = [
  (out) => isValidJSON(out),
  (out) => parse(out).category in ALLOWED_CATEGORIES,
  (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1,
];

حكَم نموذج لغوي كبير للبقية المفتوحة — النبرة، والإفادة، و”هل أجاب هذا عن السؤال فعلًا”. هنا تُعطي نموذجًا المُدخل والمُخرَج ومعيار تقييم، وتطلب منه أن يُسجّل درجة. قاعدتان تُبقيان الحكَم أمينًا: اجعل معيار التقييم محدّدًا (سلّم من 1 إلى 5 بمراسٍ موصوفة يتفوّق على “قيّم الجودة”)، واستخدم نموذجًا قويًا حكَمًا — فالحكم مهمة استدلال، لذا هذا موضع أدفع فيه بسرور مقابل Sonnet حتى حين يعمل الوكيل نفسه على Haiku وفق حساب التكلفة. معيار تقييم مبهم أو حكَم ضعيف يمنحك ضوضاء تبدو كإشارة.

شغّل المنظومة قبل كل تغيير

توجد المنظومة للإجابة عن سؤال واحد: هل جعل هذا التغيير الوكيل أفضل أم أسوأ؟ لذا أُشغّلها قبل كل تعديل توجيه، أو استبدال نموذج، أو تغيير أداة.

# خط الأساس على main
npm run eval -- --suite=booking-agent > baseline.json

# أجرِ التغيير، ثم أعد التشغيل
npm run eval -- --suite=booking-agent > candidate.json

# قارن
npm run eval:diff baseline.json candidate.json

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

ضع بوابة انحدار ودعها تحجب

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

const PASS_THRESHOLD = 0.90; // يجب أن تنجح 90% من الحالات
if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) {
  throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`);
}

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

احسب حساب اللاحتمية في التسجيل

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

تخفيفان. شغّل التقييمات عند temperature: 0 لتقليص التباين (لن يُزيله كليًا). وللحالات التي رأيتها ترتعش، شغّلها N مرة وخذ معدّل النجاح، لا نجاحًا/فشلًا واحدًا. حالة تنجح 9 من 10 في حال أفضل من حالة تنجح 5 من 10 وإن أمكن لكلتيهما إظهار تشغيل أخضر واحد. هذا هو مبدأ الكمّ-فوق-الحكاية ذاته الذي أستخدمه عند تنقيح الإخفاقات المتقطّعة — تشغيل واحد رأي، وخمسون تشغيلًا بيانات.

أغلق الحلقة بمراقبة الإنتاج

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

تلك الحلقة الراجعة هي المنتج الحقيقي. أي مجموعة تقييم بمفردها تتقادم؛ أما العملية التي تحوّل كل إخفاق إنتاج إلى اختبار دائم فتزداد قوّة كل أسبوع. هكذا ينتقل وكيل من “مخيف اللمس” إلى شيء أعيد هيكلته عصر يوم جمعة دون أن يرفّ لي جفن.

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

ما الذي يدخل في مجموعة تقييم لوكيل ذكاء اصطناعي؟

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

هل ينبغي أن أستخدم نموذجًا لغويًا لتقييم مُخرَجات الوكيل؟

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

كيف أمنع تغيير توجيه من تعطيل الإنتاج بصمت؟

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

كيف أتعامل مع اللاحتمية في التقييمات؟

شغّل عند درجة حرارة 0 لتقليل التباين، وللحالات التي ترتعش، شغّلها مرات عدّة وسجّل معدّل النجاح بدل تشغيل واحد. حالة تنجح 9 من 10 مرّات أسلم من حالة تنجح 5 من 10، حتى لو أظهر تشغيل واحد كلتيهما خضراء.