تقييم النماذج الأساسية

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

ما الذي يغطيه هذا الموضوع

• أساليب التقييم الثلاثة: التقييم الآلي مقابل مجموعة بيانات، ونموذج لغوي يعمل حَكَماً، ومراجعون بشر، ومتى يناسب كل واحد
• مهام التقييم في Amazon Bedrock: أنواع المهام والمجموعات الجاهزة مثل TREX و BOLD و Gigaword، وصيغة مجموعة المطالبات المخصَّصة بـ JSONL
• المجموعات المرجعية مثل MMLU و HELM، والفخ في قراءة لوحة الصدارة على أنها ترتيب لما يناسبك
• ROUGE و BLEU و BERTScore محسوبة على جمل حقيقية، والمقاييس التي تحسبها AWS فعلاً لكل نوع مهمة
• تقييم تطبيقات RAG: مهام الاسترجاع فقط والاسترجاع مع التوليد، وملاءمة السياق وتغطيته، والحد بين الأمانة والصحة
• تقييم الوكلاء بـ AgentCore Evaluations: مستويات الجلسة والأثر واستدعاء الأداة، ومعدل نجاح الهدف ودقة اختيار الأداة ومعاملاتها
• المواءمة مع أهداف الأعمال: الإنتاجية وتفاعل المستخدمين وهندسة المهمة، وعتبات القبول، والعيّنة الطبقية، وانجراف البيانات، والمراقبة بعد الإطلاق

لماذا هذا مهم

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

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