عند إنشاء طلبات لتطبيقات حقيقية، يظهر توازن أساسي بين الاختصار والفعالية. عندما تكون جميع العوامل متساوية، يكون الطلب الموجز أسرع وأقل تكلفة وأسهل في الصيانة من الطلب الأطول. ويكون ذلك مهمًا بشكل خاص في بيئات الويب التي يكون فيها وقت الاستجابة وحدود الرموز المميزة مهمة. ومع ذلك، إذا كان طلبك بسيطًا جدًا، قد يفتقر النموذج إلى السياق أو التعليمات أو الأمثلة اللازمة لإنتاج نتائج عالية الجودة.
تتيح لك عملية التطوير المستندة إلى التقييم (EDD) مراقبة هذه المفاضلة وتحسينها بشكل منهجي، كما توفّر عملية قابلة للتكرار والاختبار لتحسين النتائج بخطوات صغيرة وواثقة، ورصد حالات التراجع، ومواءمة سلوك النموذج مع توقعات المستخدمين والمنتجات بمرور الوقت.
يمكن اعتبارها تطويرًا مستندًا إلى الاختبار (TDD)، تم تعديله ليتناسب مع عدم اليقين الذي يميّز الذكاء الاصطناعي. على عكس اختبارات الوحدات المحدّدة، لا يمكن ترميز تقييمات الذكاء الاصطناعي بشكل ثابت لأنّ المخرجات، سواء كانت صحيحة أو غير صحيحة، يمكن أن تتخذ أشكالاً غير متوقّعة.
تساعدك ميزة "اكتشاف البيانات الإلكترونية" أيضًا في جهودك المتعلقة باكتشاف البيانات. وكما أنّ كتابة الاختبارات تساعد في توضيح سلوك إحدى الميزات، فإنّ تحديد معايير التقييم ومراجعة نتائج النماذج يجبرك على مواجهة أي نقص في الوضوح وإضافة المزيد من التفاصيل والبنية تدريجيًا إلى المهام المفتوحة أو غير المألوفة.
تحديد المشكلة
يمكنك صياغة مشكلتك على شكل عقد لواجهة برمجة التطبيقات، بما في ذلك نوع الإدخال وتنسيق الإخراج وأي قيود إضافية. على سبيل المثال:
- نوع الإدخال: مسودة مشاركة مدونة
- تنسيق الإخراج: مصفوفة JSON تتضمّن 3 عناوين مشاركات
- القيود: أقل من 128 حرفًا، استخدام أسلوب ودود
بعد ذلك، اجمع أمثلة على المدخلات. لضمان تنوّع البيانات، عليك تضمين أمثلة مثالية ومدخلات حقيقية غير منظَّمة. فكِّر في الصيغ المختلفة والحالات الهامشية، مثل المشاركات التي تتضمّن رموز إيموجي وبنية متداخلة والكثير من مقتطفات الرموز.
إعداد متوقع
اكتب طلبك الأول. ابدأ بإنشاء مطالبات بدون أمثلة وتضمين تعليمات واضحة وتنسيق الإخراج وعنصر نائب للمتغيّر الخاص بالمحتوى المُدخَل.
ستزيد من تعقيد نظامك وتستخدم مكونات إضافية أو تقنيات طلبات لتحسين نظام الذكاء الاصطناعي. لضمان استخدام وقتنا بكفاءة وتحسين المكوّنات المناسبة، عليك إعداد نظام تقييم.
إنشاء نظام التقييم
في عملية التطوير المستندة إلى الاختبار، تبدأ بكتابة الاختبارات بعد معرفة المتطلبات. مع الذكاء الاصطناعي التوليدي، لا تتوفّر نتائج نهائية يمكن اختبارها، لذا عليك بذل المزيد من الجهد في تصميم حلقة التقييم.
من المحتمل أنّك بحاجة إلى أدوات قياس متعدّدة لتقييم الأداء بفعالية.
تحديد مقاييس التقييم
يمكن أن تكون مقاييس التقييم قطعية، ما يعني أنّ هناك إجابة صحيحة معروفة. على سبيل المثال، يمكنك التحقّق مما إذا كان النموذج يعرض JSON صالحًا أو يخرج العدد الصحيح من العناصر.
ومع ذلك، باستخدام الذكاء الاصطناعي، ستخصّص معظم وقتك لتحديد المقاييس الذاتية النوعية وتحسينها. ويشمل ذلك جودة المخرجات ومدى فائدتها وأسلوبها ومستوى الإبداع فيها. يمكنك البدء بأهداف نجاح أوسع نطاقًا، مثل كيفية تلبية النتائج لتوقعاتك. في النهاية، ستواجه مشاكل محددة ودقيقة تساعدك في تحديد أهدافك بشكل أفضل.
على سبيل المثال، لنفترض أنّ أداة إنشاء العناوين تفرط في استخدام عبارات أو أنماط معيّنة، ما يؤدي إلى ظهور نتائج متكررة وآلية. في هذه الحالة، عليك تحديد مقاييس جديدة لتشجيع التنوّع وتثبيط الاستخدام المفرط للبِنى أو الكلمات الرئيسية. بمرور الوقت، ستستقر مقاييسك الأساسية وستتمكّن من تتبُّع التحسينات.
يمكن أن تستفيد هذه العملية من الخبراء الذين يفهمون شكل الأداء الجيد في نطاق تطبيقك ويمكنهم رصد أوضاع الأعطال الدقيقة. على سبيل المثال، إذا كنت بصدد تطوير مساعد للكتابة، يمكنك التعاون مع منتج محتوى أو محرّر للتأكّد من أنّ تقييمك يتوافق مع وجهة نظره.
اختيار الحكّام
تتطلّب معايير التقييم المختلفة مقيِّمين مختلفين:
- تعمل عمليات التحقّق المستندة إلى الرموز بشكلٍ جيد مع النتائج المحدّدة أو المستندة إلى القواعد. على سبيل المثال، يمكنك فحص العناوين بحثًا عن كلمات تريد تجنُّبها، أو التحقّق من عدد الأحرف، أو التحقّق من صحة بنية JSON. وهي سريعة وقابلة للتكرار ومثالية لعناصر واجهة المستخدم ذات الناتج الثابت، مثل الأزرار أو حقول النماذج.
- ملاحظات المستخدمين ضرورية لتقييم الجوانب الأكثر ذاتية، مثل الأسلوب أو الوضوح أو الفائدة. في المراحل الأولى على وجه الخصوص، تتيح مراجعة نواتج النماذج بنفسك (أو مع خبراء في المجال) إجراء تكرار سريع. ومع ذلك، لا يمكن توسيع نطاق هذا الأسلوب بشكل جيد. بعد إطلاق تطبيقك، يمكنك أيضًا جمع إشارات داخل التطبيق، مثل تقييم بنجوم، ولكنّ هذه الإشارات تكون عادةً غير دقيقة وتفتقر إلى التفاصيل الدقيقة اللازمة للتحسين الدقيق.
- توفّر LLM-as-judge طريقة قابلة للتوسّع لتقييم المعايير الذاتية من خلال استخدام نموذج ذكاء اصطناعي آخر لتسجيل النتائج أو انتقادها. وهي أسرع من المراجعة التي يجريها الفريق، ولكنها لا تخلو من العيوب: ففي حال تنفيذها بشكل بسيط، يمكن أن تؤدي إلى استمرار التحيزات والفجوات المعرفية في النموذج، بل وتعزيزها.
إعطاء الأولوية للجودة على الكمية في تعلُّم الآلة التقليدي والذكاء الاصطناعي القائم على التوقعات، من الشائع الاستعانة بمصادر خارجية لتدوين البيانات. بالنسبة إلى الذكاء الاصطناعي التوليدي، غالبًا ما يفتقر المصنّفون من مصادر جماعية إلى سياق المجال. تكون التقييمات العالية الجودة والغنية بالسياق أكثر أهمية من التقييمات الكثيرة.
التقييم والتحسين
وكلما أسرعت في اختبار طلباتك وتحسينها، أسرعت في التوصّل إلى نتائج تتوافق مع توقّعات المستخدمين. عليك أن تعتاد على التحسين المستمر. حاوِل إجراء تحسين، ثم قيِّم النتائج، وجرِّب شيئًا آخر.
بعد طرح النظام، واصِل مراقبة سلوك المستخدمين ونظام الذكاء الاصطناعي وتقييمهما. بعد ذلك، حلِّل هذه البيانات وحوِّلها إلى خطوات تحسين.
أتمتة مسار التقييم
لتقليل الاحتكاك في جهود التحسين، تحتاج إلى بنية أساسية تشغيلية تعمل على أتمتة التقييم وتتبُّع التغييرات وربط التطوير بالإنتاج. يُشار إلى ذلك عادةً باسم LLMOps. على الرغم من توفّر منصات يمكنها المساعدة في التشغيل الآلي، عليك تصميم سير العمل المثالي قبل الالتزام بحلّ تابع لجهة خارجية.
في ما يلي بعض المكوّنات الرئيسية التي يجب مراعاتها:
- تحديد الإصدار: تخزين الطلبات ومقاييس التقييم ومدخلات الاختبار في نظام التحكّم بالإصدارات تعامَل معها كرموز برمجية لضمان إمكانية إعادة إنتاجها وسجلّ تغييرات واضح.
- التقييمات المجمّعة الآلية: يمكنك استخدام عمليات سير العمل (مثل GitHub Actions) لإجراء التقييمات على كل تعديل في الطلب وإنشاء تقارير مقارنة.
- التكامل المستمر/التسليم المستمر (CI/CD) للمطالبات: يمكنك التحكّم في عمليات النشر من خلال عمليات التحقّق المبرمَجة، مثل الاختبارات المحدّدة أو تقييمات نماذج اللغات الكبيرة (LLM) أو الضوابط، وحظر عمليات الدمج عند تراجع الجودة.
- تسجيل البيانات وإمكانية المراقبة في مرحلة الإنتاج: تسجيل المدخلات والمخرجات والأخطاء ووقت الاستجابة واستخدام الرموز المميزة مراقبة الانحراف أو الأنماط غير المتوقّعة أو الارتفاعات الحادة في حالات الفشل
- إدخال الملاحظات: جمع إشارات المستخدمين (الإعجاب، إعادة الكتابة، التخلي) وتحويل المشاكل المتكررة إلى حالات اختبار جديدة
- تتبُّع التجارب: تتبُّع إصدارات الطلبات وإعدادات النماذج ونتائج التقييم
تكرار التغييرات الصغيرة والمستهدَفة
يبدأ تحسين الطلبات عادةً بتحسين لغة الطلب. وقد يعني ذلك جعل التعليمات أكثر تحديدًا أو توضيح النية أو إزالة الغموض.
احرص على عدم الإفراط في التكيّف. من الأخطاء الشائعة إضافة قواعد ضيقة جدًا لإصلاح مشاكل نماذج التصحيح. على سبيل المثال، إذا استمرت أداة إنشاء العناوين في إنتاج عناوين تبدأ بعبارة الدليل الشامل، قد يكون من المغري حظر هذه العبارة بشكل صريح. بدلاً من ذلك، يجب تلخيص المشكلة وتعديل التعليمات ذات المستوى الأعلى. قد يعني ذلك أنّك تركّز على الأصالة أو التنوّع أو أسلوب تحريري معيّن، ما يتيح للنموذج تعلُّم التفضيل الأساسي بدلاً من استثناء واحد.
هناك طريقة أخرى وهي تجربة المزيد من تقنيات الطلبات والجمع بين هذه الجهود. عند اختيار أسلوب، اسأل نفسك: هل يمكن حلّ هذه المهمة بشكل أفضل من خلال القياس (التعلم من أمثلة قليلة) أو الاستدلال خطوة بخطوة (سلسلة الأفكار) أو التحسين التكراري (التفكير الذاتي)؟
عندما ينتقل نظامك إلى مرحلة الإنتاج، يجب ألا يتباطأ مسار تطوير المنتجات المستند إلى البيانات. بل يجب أن تتسارع. إذا كان نظامك يعالج مدخلات المستخدم ويسجّلها، يجب أن تصبح هذه المدخلات مصدر المعلومات الأكثر قيمة. أضِف أنماطًا متكرّرة إلى مجموعة التقييم، وحدِّد باستمرار أفضل خطوات التحسين التالية ونفِّذها.
الخلاصات الرئيسية
يمنحك تطوير الطلبات المستند إلى التقييم طريقة منظَّمة للتعامل مع حالة عدم اليقين التي تتسم بها تكنولوجيات الذكاء الاصطناعي. من خلال تحديد مشكلتك بوضوح وإنشاء نظام تقييم مخصّص وتكرار التحسينات الصغيرة والمستهدَفة، يمكنك إنشاء حلقة ملاحظات تعمل على تحسين نتائج النموذج بشكلٍ ثابت.
الموارد
في ما يلي بعض المراجع المقترَحة إذا أردت تنفيذ LLM-as-judge:
- مقارنة إمكانات النماذج اللغوية الكبيرة مع ميزة التلخيص
- يمكنك الاطّلاع على دليل "حامل حسين" حول استخدام نماذج اللغة الكبيرة كحكم.
- يمكنك قراءة الورقة البحثية: A Survey on LLM-as-a-Judge.
إذا كنت مهتمًا بتحسين طلباتك بشكل أكبر، يمكنك الاطّلاع على مزيد من المعلومات حول التطوير المراعي للسياق. ويُفضّل أن يتولّى هذه المهمة مهندس متخصص في تعلُّم الآلة.
اختبِر معلوماتك
ما هو الهدف الأساسي من التطوير المستند إلى التقييم؟
لماذا نستخدم نماذج أكبر لتقييم نظام من جهة العميل؟
ما هي المشكلة المحتملة لاستخدام النماذج اللغوية الكبيرة كحكم للتقييم؟
أيّ مكوّن هو جزء من مسار تقييم آلي مُقترَح؟
عند اختيار الحكّام لنظام التقييم، ما هي القيود الرئيسية لاستخدام ملاحظات المستخدمين؟