كيف نختبر ميزات النماذج اللغوية: المجموعات الذهبية والنموذج الحَكَم وبوابات التقييم في التكامل المستمر

أهم النقاط

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

المجموعة الذهبية (golden set) ملف خاضع لإدارة الإصدارات يضم مدخلات حقيقية مقترنة بالخصائص التي يجب أن تحققها مخرجاتها. في فريقنا يتحوّل كل عطل في الإنتاج داخل ميزة ذكاء اصطناعي إلى سطر جديد في هذا الملف.

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

أسلوب النموذج الحَكَم (LLM-as-judge) هو استدعاء ثانٍ لنموذج يقيّم مخرجات النموذج الأول وفق معايير مكتوبة. لا يكون الحَكَم جديرًا بالثقة إلا إذا ثُبِّت معرّف نموذجه، وطُرحت معاييره كأسئلة ثنائية (نعم/لا)، وقُورنت أحكامه بتصنيفات بشرية.

نضبط بوابة التكامل المستمر على الانحدار لا على الكمال: يفشل البناء عندما تنخفض نسبة النجاح تحت خط أساس محفوظ في المستودع، ورفع خط الأساس يتم عبر التزام (commit) خاضع للمراجعة.

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

لماذا لا يمكن اختبار ميزة نموذج لغوي بالطريقة المعتادة؟

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

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

ما هي المجموعة الذهبية ومن أين تأتي حالاتها؟

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

قاعدتان في التخزين أثبتتا جدواهما. الأولى: احفظ الحالات كملف JSON أو JSONL بجوار الموجّه الذي تختبره، حتى تكون قائمة الحالات قابلة للمراجعة داخل طلب الدمج. الثانية: احفظ الموجّه في ملف مستقل بدل وضعه داخل نص برمجي مضمّن في معالج المسار، حتى يظهر تعديل الموجّه ونتائج تقييمه في الفرق (diff) نفسه. هذه الخطوة وحدها تحوّل عبارة «أحدهم عدّل الموجّه» من حدث غير مرئي إلى حدث قابل للمراجعة.

برمجيًا، تدور حزمة اختبارات Vitest على ملف الحالات وتستدعي generateObject من حزمة Vercel AI SDK بمعرّف نموذج مثبّت، ودرجة حرارة صفر، وموجّه النظام المحفوظ في المستودع، ومخطط Zod يصف التذكرة. تتحقق generateObject من مطابقة مخرجات النموذج للمخطط قبل إرجاعها، فيُرمى خطأ عند أي انحدار في الشكل بدل تسربه إلى التحقق التالي. ثم يدور تحقق ثانٍ على كل رقم طلب مُعاد ويشترط وجوده في الرسالة الأصلية — وهو فحص الاستناد الذي كان سيكتشف عطل المعرّفات المخترعة عندنا.

متى نستخدم فحصًا حتميًا بدل النموذج الحَكَم؟

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

شكل المخرجات وصحة JSON: حتمي عبر التحقق من مخطط Zod. التحقق من المخطط دقيق تمامًا، فلا يمكن للحَكَم إلا أن يكون أسوأ وأغلى.

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

المحتوى الممنوع — تسريب موجّه النظام، والروابط الداخلية، وأسماء المنافسين: حتمي عبر قائمة منع بالتعابير النمطية. خصائص الأمان يجب أن تكون قاطعة لا احتمالية.

قيود اللغة والطول والتنسيق: حتمي. عدّ الكلمات ونطاقات الحروف في يونيكود يمكن حسابها ببساطة.

هل أجابت المخرجات فعلًا عن السؤال: النموذج الحَكَم. هذا يتطلب فهمًا ولا يعبّر عنه أي مُسنَد.

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

كيف نمنع انحراف النموذج الحَكَم؟

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

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

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

كيف نشغّل التقييمات في التكامل المستمر دون دفع تكلفة عند كل طلب دمج؟

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

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

ما نسبة النجاح التي يجب أن تُفشل البناء؟

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

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

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

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

س: هل نحتاج إلى إطار عمل مخصص للتقييم من البداية؟

ج: لا. يكفي Vitest أو مشغّل الاختبارات المدمج node:test مع ملف حالات بصيغة JSON للأشهر الأولى. أما أدوات مثل Promptfoo وEvalite وBraintrust فتستحق التبني حين تحتاج إلى إدارة مجموعات البيانات، وتتبّع النتائج عبر التشغيلات، وواجهة لمراجعة اختلافات الحَكَم.

س: كم حالة يجب أن تضم المجموعة الذهبية؟

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

س: هل تجعل درجة الحرارة صفر مخرجات النموذج حتمية؟

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

س: هل يجب أن يكون النموذج الحَكَم هو نفسه النموذج المولّد للإجابة؟

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

س: كيف نمنع تكاليف التقييم من التضخم مع نمو الفريق؟

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