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