بقلم: يوسف | محرر أدوات الذكاء الاصطناعي · صوت تحريري بإشراف بشري
كل مطوّر بنى نظام RAG يعرف المشكلة: تُغيّر معامل واحداً، يتحرك الرقم قليلاً، فلا تعرف إن كانت التحسينات حقيقية أم مجرد ضجيج إحصائي. rag-ci يحلّ هذه المعضلة بأن يجعل سؤال “هل تراجع الأداء فعلاً؟” سؤالاً يجيب عنه الكود تلقائياً، قبل أن يُدمج أي pull request.
الفكرة مباشرة: الأداة تقيس كل تعديل على pipeline الـ RAG مقارنةً بـ baseline محفوظ، وتُوقف البناء فقط حين يكون التراجع ذا دلالة إحصائية وفوق حدٍّ مؤثر في آنٍ معاً. الدليل الأبسط على ذلك يظهر في أمر واحد يعمل دون مفتاح API ودون تنزيل أي شيء: uvx rag-ci demo. الأمر يبني corpus اصطناعياً من 144 وثيقة و144 سؤالاً مربوطاً بمواضع أحرف في النصوص، ثم يقيس السيناريوين (وفقاً لمستودع rag-ci): baseline بـ chunk_size=240 حقق recall@3 = 0.951 بفاصل ثقة [0.917, 0.986]، بينما تقليصه إلى chunk_size=120 أسقط الرقم إلى 0.736 بفاصل [0.667, 0.806] — أي انخفاض بمقدار 0.215 بمستوى دلالة p=0.0000. النتيجة: exit code 1، والـ pull request محجوب.
ما يميّز rag-ci عن أدوات كـ promptfoo و ragas و DeepEval هو نقطة واحدة جوهرية: هذه الأدوات تقارن رقماً بعتبة ثابتة، بينما rag-ci تقارن تشغيلين على نفس الأسئلة تماماً وتُبلّغ بمستوى الثقة في الفارق. الدقة الإحصائية التي استخدمها الأكاديميون في T2-RAGBench و HetDocQA — paired bootstrap بـ 10,000 عيّنة إعادة وفاصل ثقة 95% — وصلت الآن إلى أداة يشغّلها أي مطوّر من سطر أوامر.
الجانب الآخر لهذا المنطق لا يقل أهمية: الأداة ترفض الإنذار الكاذب بنفس الصرامة. في مجموعة مرجعية من ستة أسئلة فقط، تقليص top_k إلى 1 خفّض recall@3 من 0.833 إلى 0.667 — أي تراجع بـ 0.167. لكن rag-ci لم تحجب البناء، لأن فاصل الثقة [-0.500, 0.000] يمتد ليشمل الصفر؛ ست حالات لا تكفي للجزم. الأداة تقول بصراحة: وسّع مجموعة الأسئلة الذهبية وسيضيق الفاصل حتى يُشغّل التنبيه. منطق مصمَّم ليتحمّله الفريق طويلاً — أداة تُنذر على ضجيج تُعطَّل خلال أسبوع.
وهذا المنطق ذاته يفيد في الكشف عن “تحسينات وهمية”؛ بحث Beyond the Reranker وجد أن كثيراً من تقنيات الاسترجاع تتوقف عن الإضافة حين يكون reranker قوي موجوداً، وأن الفرق بين 0.71 و0.74 قد يبدو تقدماً لكنه في الغالب ضجيج — وفرق الفاصل الإحصائي هو ما يُثبت أو ينفي ذلك.
للبدء مع rag-ci في pipeline حقيقي، المسار يسير عبر هذه الخطوات:
- شغّل
uvx rag-ci demoلرؤية التراجع يُكتشف فوراً دون أي إعداد، ثمuvx rag-ci initلبناء ملف adapter يربط الأداة بـ pipeline الخاص بك. - ولّد أسئلة ذهبية بـ
uvx "rag-ci[generate]" golden gen— هذه الخطوة وحدها تحتاجANTHROPIC_API_KEY؛ كل ما عداها يعمل بلا نموذج خارجي. راجعdocs/golden-sets.mdللتفاصيل. - راجع الأسئلة المولَّدة وقبلها أو عدّلها بـ
uvx rag-ci golden review، ثم احفظها فيtests/golden.jsonl. - شغّل
uvx rag-ci runلتسجيل baseline مع فواصل الثقة، وuvx rag-ci gateلتحديد ما إذا كان الفارق الجديد يستوجب حجب البناء. - استخدم
uvx rag-ci sweepلمقارنة إعدادات متعددة — الأداة تطبّق successive halving بدلاً من grid search، وتفصل بين معاملات وقت الفهرسة ومعاملات الاستعلام لتُعيد بناء الفهرس مرات أقل. إضافة--extrapolate-toتُسقط نتائج corpus جزئي إلى حجم كامل — لكنها ترفض التسقيط إن كانت النقاط المقيسة لا تدعمه. - لتقييم جودة الإجابات لا مجرد الاسترجاع، أضف
--judgeإلى أمر run، وشغّلuvx rag-ci judge calibrateأولاً للتحقق من موثوقية الـ judge قبل الاعتماد عليه.
دمج الأداة في GitHub Actions لا يتجاوز ثلاثة أسطر إضافية في ملف YAML: تحديد مسار adapter و golden set واستخدام الـ action الرسمي Nokimalos/rag-ci@v0.5.0. الـ gate يُصدر exit code 1 عند تراجع حقيقي و exit code 2 حين يتعذّر إجراء مقارنة موثوقة — كأن يكون baseline مسجَّلاً على مجموعة أسئلة مختلفة. GitLab يستقبل نفس المنطق عبر allow_failure: exit_codes في مستند docs/gitlab-ci.md، وهو تمييز لا تستطيع GitHub Actions التعبير عنه بنفس الدقة.
نقطة التصميم الأذكى هي أن ground truth مرتبط بمقاطع النصوص الأصلية لا بالـ chunks — ما يعني أن تغيير chunk_size لا يكسر مجموعة الأسئلة الذهبية، وهو ما يجعل الـ sweep ممكناً أصلاً. الأداة بلا رأي في إطار RAG الذي تستخدمه: تكتب ملف adapter واحداً، وتبقى البنية التحتية ملكك. الأداة مفتوحة المصدر بترخيص MIT وتتطلب Python 3.12+.
