Claude Code ساعد في رفع Legal RAG إلى 0.791، لكن نهائي ARLC 2026 اصطدم بمشكلة الحجم

في تحدي الذكاء الاصطناعي القانوني ARLC 2026، رفع المشارك خلال خمسة أيام و17 تكرارًا درجة خط معالجة RAG من 0.034 إلى 0.791 في مرحلة warmup. ولم يكن العاملَ الحاسم البحثُ الهجين والاسترجاع على مستوى الصفحة وحدهما، بل أيضًا فحصٌ بسيط للصيغة: فحذف .pdf من doc_id أحدث قفزة حادة. لكن في النهائي، ومع 303 وثائق، خسر النظام 42% من نتيجته، إذ أفسد الحجمُ الكبير عملية الاسترجاع (retrieval).

معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
Claude Code ساعد في رفع Legal RAG إلى 0.791، لكن نهائي ARLC 2026 اصطدم بمشكلة الحجم
المصدر: Habr AI. كولاج: Hamidun News.
استمع للمقال
بطاقة الحقائق والأرقام
المعيارالتفاصيل
المصدر الأصليHabr AI ↗
رئيس التحرير
حقيقة رئيسية #1الاسترجاع على مستوى الصفحة بدلًا من المقاطع
حقيقة رئيسية #2BM25 + embeddings + Reciprocal Rank Fusion
حقيقة رئيسية #3OCR كمسار احتياطي للصفحات الفارغة أو الممسوحة ضوئيًا

تُظهر حالة ARLC 2026 بوضوح مدى هشاشة RAG في المهام الواقعية. فقد رفع المشارك، بالتعاون مع Claude Code وخلال خمسة أيام، نتيجة خط المعالجة القانوني من 0.034 إلى 0.791 في مرحلة warmup، ثم اصطدم في النهائي بجدار صلب من مشكلات التوسّع.

من خطأ برمجي إلى قفزة

لم يكن التحدي يتطلب الإجابة عن أسئلة حول الأحكام القضائية والقوانين فحسب، بل تحديد صفحات المصدر بدقة. ولهذا صار grounding مضاعِفًا للتقييم النهائي بأكمله: فحتى مع الإجابات القوية، كانت الإحالات الضعيفة تُصفّر النتيجة تقريبًا. وهذا ما حدث في البداية: أظهرت النسخة الأولى 0.034، مع أن دقة جزء من الإجابات كانت مرتفعة أصلًا.

لم تكن المشكلة في النموذج ولا في الاسترجاع (retrieval)، بل في صيغة المخرجات. أمضى المشارك ثلاث محاولات قبل أن يلاحظ خطأً بسيطًا: كان الحقل doc_id يُرسَل باسم الملف مع .pdf، بينما يتوقع النظام معرّفًا بلا امتداد. وقد رفع هذا الإصلاح الواحد grounding من 0.05 إلى 0.55، والنتيجة الإجمالية من 0.034 إلى 0.438. بعد ذلك بلغ خط المعالجة 0.791 في warmup خلال 17 تكرارًا.

وساعدت رياضيات F-beta مع β=2.5 بصورة منفصلة: فقد أظهرت أن الصفحات الزائدة تضرّ أكثر مما يبدو، وأن كل إحالة زائدة قد تكلّف 10–22% من جودة grounding.

البنية والأساليب

جاءت أفضل نتيجة من خط معالجة يفهرس صفحات PDF كاملة بدلًا من المقاطع (chunks). وهذا خيار مهم في legal RAG: فإذا كان المقياس يتحقق من إصابة صفحة بعينها، فإن التقسيم إلى مقاطع يعقّد الربط العكسي بالصفحة ويولّد ضجيجًا. وللبحث استُخدم مخطط هجين يجمع BM25 مع التضمينات (embeddings) ويدمج النتائج عبر RRF، وأُضيف OCR للمستندات الممسوحة ضوئيًا. فوق ذلك، قيّد المشارك عدد الصفحات في المخرجات، ووجّه أسئلة المقارنة (comparison) التي تتطلب مطابقة وثيقتين عبر مسار منفصل.

  • الاسترجاع على مستوى الصفحة بدلًا من المقاطع
  • BM25 + embeddings + Reciprocal Rank Fusion
  • OCR كمسار احتياطي للصفحات الفارغة أو الممسوحة ضوئيًا
  • تحديد عدد الصفحات في الإجابة بحسب نوع السؤال
  • مسارات سريعة حتمية (deterministic) للحالات البسيطة
«تحقق أولًا من صيغة المخرجات. ثم حسّن الجودة».

ويشكّل دور Claude Code محورًا مستقلًا في هذه الحالة. فبمساعدته كتب المشارك نحو 3000 سطر من الشيفرة في سبع وحدات خلال خمسة أيام، وأنجز 17 نسخة بدلًا من 3–5 نسخ تقريبًا لو عمل يدويًا. وسرّع الوكيل التعديلات وإعادة الهيكلة (refactoring) وتشغيل الإرسالات (submissions) وفحص الفروق (diffs) قبل الإرسال. غير أن القرارات الاستراتيجية بقيت بيد الإنسان: أي المقاييس يُصلَح أولًا، وكيف تُفسَّر حالات التراجع، ومتى يُترك الـ prompt المضبوط دون مساس.

أين انكسر كل شيء

في مرحلة warmup تألّف المجموع من 30 وثيقة و100 سؤال، أما في النهائي فصار 303 وثائق و4244 صفحة و900 سؤال. وهنا تبيّن أن خط معالجة يتصرف جيدًا على مجموعة صغيرة ليس بالضرورة أن ينتقل بالأداء نفسه إلى مجموعة كبيرة.

ظهر أولًا خطأ في الذاكرة المؤقتة (cache): فقد فهرس النظام عن طريق الخطأ وثائق warmup الثلاثين بدلًا من وثائق النهائي الـ 303، فقفز عدد إجابات null إلى 37. وبعد مسح الذاكرة المؤقتة زالت المشكلة، لكن الإخفاق الرئيسي بقي: انخفضت النتيجة النهائية بنسبة 42% لتصل إلى 0.457.

أما الأسباب الجذرية فتبيّن أنها معمارية. فقد بدأت وثيقة DIFC Courts Rules الضخمة تلوّث نتائج البحث في كثير من الاستعلامات القانونية، وأربكت أوراق الاستشارة (consultation papers) ذات الأرقام المتطابقة والسنوات المختلفة عملية إزالة الالتباس (disambiguation)، واستبدل تعبير نمطي (regex) خاص برقم القانون إجاباتِ الغرامات بأرقام القوانين. وبدت محاولة تطبيق حزمة من ثمانية إصلاحات بسرعة معقولة، لكنها في المحصلة أخلّت بتوازن المقاييس: ارتفع جزء من الدقة الحتمية، بينما تراجع grounding والنتيجة الإجمالية أكثر.

تكمن قيمة هذا التحليل في أنه لا يروّج لسحر مساعد الذكاء الاصطناعي. فقد منح Claude Code السرعة، لكنه لم يُعفِ من العمل الهندسي الأساسي: التحقق من الصيغة، واحتساب المقياس، واختبار تغيير واحد في كل مرة، وفحص النظام على حجم قريب من بيئة الإنتاج. ويخلص المشارك إلى استنتاج حاسم: إذا كانت مجموعة التقييم (eval) أصغر من المجموع الفعلي بأضعاف، فأنت لا تختبر الاسترجاع (retrieval)، بل تختبر الحظ.

ماذا يعني ذلك

بالنسبة إلى الفرق التي تبني منتجات RAG، فهذا بمثابة دش بارد. فالفوز لا يذهب إلى أعقد حزمة تقنية، بل إلى الانضباط: صيغة مخرجات دقيقة، ومقياس واضح، وحدّ أدنى من الضجيج في الإحالات، واختبار على حجم واقعي. أما مساعدو البرمجة بالذكاء الاصطناعي فيمنحون بالفعل تسريعًا كبيرًا، لكنهم لا يحلّون بعدُ محلّ التفكير الهندسي والمسؤولية عن القرارات المعمارية.

القصة

أسئلة وأجوبة حول الخبر

ما أبرز التفاصيل حول من خطأ برمجي إلى قفزة؟

لم يكن التحدي يتطلب الإجابة عن أسئلة حول الأحكام القضائية والقوانين فحسب، بل تحديد صفحات المصدر بدقة. ولهذا صار grounding مضاعِفًا للتقييم النهائي بأكمله: فحتى مع الإجابات القوية، كانت الإحالات الضعيفة تُصفّر النتيجة تقريبًا. وهذا ما حدث في البداية: أظهرت النسخة الأولى 0.034، مع أن دقة جزء من الإجابات كانت مرتفعة أصلًا. لم تكن المشكلة في النموذج ولا في الاسترجاع (retrieval)، بل في صيغة المخرجات. أمضى المشارك ثلاث محاولات قبل أن يلاحظ خطأً بسيطًا: كان الحقل doc_id يُرسَل باسم الملف مع .pdf، بينما يتوقع النظام معرّفًا بلا امتداد. وقد رفع هذا الإصلاح الواحد grounding من 0.05 إ

ما أبرز التفاصيل حول البنية والأساليب؟

جاءت أفضل نتيجة من خط معالجة يفهرس صفحات PDF كاملة بدلًا من المقاطع (chunks). وهذا خيار مهم في legal RAG: فإذا كان المقياس يتحقق من إصابة صفحة بعينها، فإن التقسيم إلى مقاطع يعقّد الربط العكسي بالصفحة ويولّد ضجيجًا. وللبحث استُخدم مخطط هجين يجمع BM25 مع التضمينات (embeddings) ويدمج النتائج عبر RRF، وأُضيف OCR للمستندات الممسوحة ضوئيًا. فوق ذلك، قيّد المشارك عدد الصفحات في المخرجات، ووجّه أسئلة المقارنة (comparison) التي تتطلب مطابقة وثيقتين عبر مسار منفصل. الاسترجاع على مستوى الصفحة بدلًا من المقاطع BM25 + embeddings + Reciprocal Rank Fusion OCR كمسار احتياطي للصفحات الفارغة

ما أبرز التفاصيل حول أين انكسر كل شيء؟

في مرحلة warmup تألّف المجموع من 30 وثيقة و100 سؤال، أما في النهائي فصار 303 وثائق و4244 صفحة و900 سؤال. وهنا تبيّن أن خط معالجة يتصرف جيدًا على مجموعة صغيرة ليس بالضرورة أن ينتقل بالأداء نفسه إلى مجموعة كبيرة. ظهر أولًا خطأ في الذاكرة المؤقتة (cache): فقد فهرس النظام عن طريق الخطأ وثائق warmup الثلاثين بدلًا من وثائق النهائي الـ 303، فقفز عدد إجابات null إلى 37. وبعد مسح الذاكرة المؤقتة زالت المشكلة، لكن الإخفاق الرئيسي بقي: انخفضت النتيجة النهائية بنسبة 42% لتصل إلى 0.457. أما الأسباب الجذرية فتبيّن أنها معمارية. فقد بدأت وثيقة DIFC Courts Rules الضخمة تلوّث نتائج البحث ف

ZK
جمال حميدون — مدير المنتجات في Alpina Digital ومدير منتج AlpinaGPT. يبني منتجات الذكاء الاصطناعي منذ 2019. بدأ Hamidun News كمشروع شخصي ثم أصبح مُجمِّعًا إنتاجيًا بأكثر من 6000 قارئ.
✦ Hands-On AI Engineering · Hamidun Academy

Build & Ship Production AI Agents Without Boilerplate Code

Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.

Start 72h Free Trial →Vibe-Coding Intensive
ما رأيك؟
جارٍ تحميل التعليقات…