كيف أقوم بإعداد تقييمات RAG في CI/CD لاكتشاف التراجعات (Regressions)
يصل طلب سحب (PR). يعمل تقييم RAG في دقيقة واحدة. تظهر علامة صح خضراء. تقوم بدمج الكود.
بعد اثنتي عشرة ساعة، تصل تذاكر الدعم الفني.
قام المسترجع (retriever) بتغيير الجزء (chunk) الأول لأحد أنواع الاستعلامات المحددة. لم تغطِّ مجموعة البيانات المكونة من 30 مثالاً تلك الحالة أبدًا. ظلت مجموعة الاختبارات خضراء لأنها كانت تفحص الأشياء الخاطئة.
معظم بوابات RAG هي مجرد اختبارات دخان (smoke tests). فهي تستخدم مجموعات بيانات صغيرة وحدودًا دنيا ثابتة. إذا كان المتوسط فوق رقم معين، فإنها تجتاز الاختبار. هذا الأسلوب يفشل لأن مجموعات البيانات ليست ممثلة للواقع، ولأن العتبات (thresholds) لا تأخذ الضجيج (noise) في الاعتبار.
تحتاج البوابة الجيدة إلى ثلاثة أشياء: السرعة، التكلفة المنخفضة، والأهمية الإحصائية. وعادة ما تحصل على اثنين منها فقط.
إليك إطاري العمل لبوابة RAG موثوقة.
الهيكل ثلاثي المستويات
- كل عملية دفع (بوابة الـ PR)
- استخدم مصنفات رخيصة مثل NLI faithfulness و claim support.
- استخدم فحوصات حتمية (deterministic) لصحة الاستشهادات وزمن الاستجابة (latency).
- قم بتشغيل 100 إلى 200 مثال في أقل من ثلاث دقائق.
- هذا يمنع عملية الدمج.
- الفرع الرئيسي الليلي (المسح الكامل)
- قم بتشغيل حزمة LLM-judge الكاملة مقابل مجموعة البيانات الخاصة بك ذات الإصدارات (versioned dataset).
- يستغرق هذا من 15 إلى 30 دقيقة.
- هذا يمنع الترقية التالية إلى نسخة الـ canary.
- نسخة الـ Canary (مراقبة الإنتاج)
- قم بتشغيل نفس المعايير (rubrics) على 5 إلى 10 بالمائة من حركة المرور الحية.
- اضبط تنبيهات لانحراف المتوسط المتحرك (rolling-mean drift).
المعايير الخمسة الأساسية
لتحديد مكان تعطل النظام بالضبط، قم بتقسيم معاييرك حسب الطبقة:
- صلة السياق (Context Relevance): إذا انخفضت هذه القيمة مع بقاء Groundedness مرتفعة، فهذا يعني تراجع أداء المسترجع (retriever).
- الموثوقية (Groundedness): إذا انخفضت هذه القيمة مع بقاء Context Relevance مرتفعة، فهذا يعني تراجع أداء المولد (generator).
- صلة الإجابة (Answer Relevance)
- صحة الاستشهاد (Citation Validity)
- استدعاء الاسترجاع (Retrieval Recall)
ملاحظة: يجب عليك استخدام معرفات المستندات الحقيقية (ground-truth doc IDs) مثل (expected_chunks) لتقييم استدعاء الاسترجاع (retrieval recall). بدون ذلك، لن تتمكن من العثور على أخطاء الاسترجاع.
البوابة الإحصائية
لا تكتفِ بوضع بوابة بناءً على رقم ثابت. فالحد الأدنى الثابت يغفل الانحراف البطيء. استخدم عتبتين:
- حد أدنى مطلق للأعطال الواضحة (مثل Groundedness ≥ 0.85).
- بوابة فرق (delta gate) مقابل خط أساس متحرك لمدة 7 أيام.
استخدم اختبارًا إحصائيًا مثل اختبار Welch's t-test. لا ترفض طلب السحب (PR) إلا إذا كان الانخفاض ذا دلالة إحصائية وكبيرًا بما يكفي ليكون مؤثرًا. هذا يمنع المطورين من تجاهل البوابة بسبب الإنذارات الكاذبة.
القاعدة الأكثر أهمية
يجب أن يكون خط الأساس الخاص بك نافذة إنتاج متحركة، وليس مجرد رقم ثابت.
عندما تتغير بيانات الإنتاج، يجب أن تتغير مجموعة البيانات الخاصة بك أيضًا. قم بأخذ الـ production traces الفاشلة، وقم بتجميعها (cluster)، ثم ارفعها لتصبح جزءًا من الـ eval set الخاصة بك. هذا يحول بوابة الاختبار (gate) الخاصة بك إلى نظام تعلم.
المصدر: https://dev.to/kartik-nvjk/how-i-set-up-rag-evals-in-cicd-so-they-actually-catch-regressions-46hb
مجتمع تعلم اختياري: https://t.me/GyaanSetuAi