تطوير الوكلاء القائم على التقييم: كيف توقفت عن ضبط المطالبات بناءً على الانطباعات
لقد قمت بتغيير مطالبة (prompt). بدت النتيجة في المرة التالية أفضل. هل ساعد هذا التغيير، أم أنني كنت محظوظاً فقط؟
لفترة طويلة، كانت إجابتي هي "أعتقد ذلك". كنت أقوم بتعديل أمر ما، ثم أشغل خط الإنتاج (pipeline)، وأراقبه وهو ينجح، ثم أطلقه. هذه هي الهندسة القائمة على الانطباعات (vibes-based engineering). الجميع تقريباً ممن يبنون الوكلاء يفعلون ذلك لأن البديل يبدو صعباً.
لكن وكلاء البرمجة (coding agents) غير حتميين (non-deterministic). يمكنك تشغيل المهمة نفسها مرتين والحصول على نتيجتين مختلفتين. التشغيل الناجح لمرة واحدة لا يخبرك بشيء. لا يمكنك معرفة ما إذا كان تغييرك قد نجح أم أن النرد قد رُمي بشكل جيد فحسب.
لقد حللت هذه المشكلة باستخدام انضباط تعلم الآلة. قمت ببناء إطار عمل للتقييم (evaluation framework) ليحيط بنظامي بالكامل.
إليك كيف يعمل إطار العمل:
• الهدف (Target): قاعدة كود (codebase) ثابتة. تظل كما هي لتبقى النتائج قابلة للمقارنة. • المهمة (Task): عنصر مرجعي (benchmark) محدد مع مطالبة (prompt) ومرجع (oracle). • المرجع (Oracle): فحص حتمي. وهي عبارة عن أوامر shell يجب أن تجتاز الاختبار. • المتغير (Variant): التغيير المحدد الذي تختبره، مثل مخطط (planner) جديد. • المحاولة (Trial): تشغيل واحد. أقوم بتشغيل كل مهمة عدة مرات لمراعاة العشوائية.
أستخدم نوعين من التقييم لرصد أنواع مختلفة من الإخفاقات:
- مُقيّمو الكود (Code Graders) (حتميّون): يتحققون من معدلات اجتياز الاختبارات، والتكلفة، والوقت، وتغييرات الملفات.
- حكم الـ LLM (LLM Judge) (احتمالي): نموذج منفصل وثابت يقيم جودة المواصفات ودقة التنفيذ.
مُقيّمو الكود يخبرونك ما إذا كان الكود يعمل، بينما يخبرك الحكم ما إذا كان الكود جيداً. أنت بحاجة لكليهما.
توقفت أيضاً عن استخدام المتوسطات. فالمتوسطات الحسابية تضلل عند التعامل مع الوكلاء. إذا نجحت المهمة مرتين من أصل ثلاث مرات، فقد يبدو الأمر جيداً، لكنه ليس موثوقاً. بدلاً من ذلك، أستخدم مقياسين:
- pass@k: هل نجح الوكيل مرة واحدة على الأقل؟ (القدرة)
- pass^k: هل نجح الوكيل في كل مرة؟ (الموثوقية)
القفزة في pass^k هي الفوز الحقيقي. فهي تعني أنك جعلت الوكيل متسقاً، وليس مجرد محظوظ.
للحفاظ على كفاءة النظام، أضيف مهاماً صعبة تتطلب فهماً عميقاً. عندما يفشل الوكيل في معالجة خطأ (bug) حقيقي، أحول هذا الفشل إلى مهمة دائمة. هذا يخلق حلقة مغلقة؛ حيث تزداد صعوبة الاختبار المرجعي (benchmark) كلما أصبح الوكيل أفضل.
هذه البنية التحتية تتطلب الكثير من العمل، لكنها أكثر شيء ذو قيمة (highest leverage) قمت ببنائه. لقد حولت عبارة "أعتقد أن هذا أفضل" إلى "هذا أكثر موثوقية بنسبة 20% وبتكلفة أقل".
من السهل استعراض وكلاء البرمجة في العروض التوضيحية (demos)، ولكن من الصعب الوثوق بهم. إذا كنت تريد تجاوز مرحلة العروض التوضيحية، فعليك أن تقرر البدء بالقياس.
Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189
Optional learning community: https://t.me/GyaanSetuAi