تحدي Agentic Legal RAG 2026: كيف اختبرت Sparks of intelligence حدود agentic RAG

نشر فريق Sparks of intelligence تحليلاً مفصلاً لمشاركتهم في تحدي Agentic Legal RAG Challenge 2026 — وهو هاكاثون دولي يركز على legal RAG. هذه ليست قصة عن نصر مذهل، بل تقرير هندسي مفيد يشرح لماذا تفشل أنظمة البحث عن المستندات عادة أثناء تحضير السياق بدلاً من اختيار LLM.

كيف تم تنظيم الهاكاثون

أجرت المسابقة شركة EORA AI Applications and Services. كان على المشاركين بناء نظام يجيب على أسئلة حول وثائق محاكم مركز دبي المالي الدولي (DIFC). سار الهاكاثون على مرحلتين: من 11 إلى 19 مارس 2026، عمل المشاركون مع 30 وثيقة و100 سؤال، وفي النهائي الذي أقيم من 20 إلى 22 مارس 2026، ازداد الحجم إلى 300 وثيقة و900 سؤال.

كان صندوق الجوائز 32000 دولار، وشارك في المسابقة أكثر من 300 شخص. الصعوبة لم تكن فقط في الحجم. أدرج المنظمون عمداً أنواعاً مختلفة من الإجابات: منطقي، اسم، تاريخ، رقم ونص حر.

أي أن نموذج توليد واحد لم يكن كافياً — كان على النظام أن يستخرج الحقائق بدقة، ويحافظ على السياق، وعدم إنفاق الكثير من الوقت والرموز. لإجابات النصوص الحرة، تم استخدام التقييم بواسطة LLM، وكانت المعايير الرئيسية تشمل الدقة والسرعة وتكلفة المعالجة. بشكل أساسي، تم اختبار المشاركين ليس على القدرة على "توصيل روبوت محادثة"، بل على نضج حلقة الاسترجاع بالكامل.

نسختان من النظام

جمع الفريق معمارين على مكدس واحد: Qdrant كقاعدة بيانات متجهة، LlamaIndex للعمل مع الفهارس وتجريدات LLM، وUnstructured — لاستخراج النصوص من ملفات PDF مع الحفاظ على البنية. بعد ذلك، انحرفت الطرق.

كانت النسخة الأولى عملية للغاية: تقسيم الصفحات مع التقسيم، البحث الهجين، التصفية حسب البيانات الوصفية والتعبيرات النمطية. كانت النسخة الثانية طموحة بشكل ملحوظ: تقسيم هرمي، التحليل الأولي للبنية عبر LLM وموجّه الوكيل الذي يختار أداة البحث المناسبة لسؤال محدد.

• قسمت النسخة البسيطة المستندات حسب الصفحات وقدمت فوراً تأسيساً واضحاً.
• تم بناء البحث هناك على خليط من المتجهات والبيانات الوصفية وتصفية regex.
• استخدمت نسخة الوكيل موجهاً وأربع أدوات: البحث في البيانات الوصفية، المطابقة الدقيقة، مقارنة المستندات والبحث الهجين.
• طبق كلا المخططين إعادة ترتيب لإعادة ترتيب مرشحي top-k وتعزيز الصلة.

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

حيث انهار كل شيء

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

«في الموعد النهائي الضيق جداً، يكاد يكون من المستحيل بناء نظام كهذا

بدون وكلاء برمجيين.»

أكدت النتائج النهائية هذا فقط. وصلت الحل البسيط إلى دقة 0.79 مع تأسيس 0.63 وأظهرت سلوكاً مستقراً، وإن لم يكن مثالياً. خسرت نسخة الوكيل الأكثر تعقيداً في الدقة في المرحلة الأولية وعملت بشكل أبطأ، وفي النهائي لم تُقدم حتى بسبب أخطاء API قبل الموعد النهائي. يحذر المؤلفون بشكل منفصل من فخ آخر: وكلاء البرمجة مفيدون للتغليف والمهام الروتينية، لكن في الإعدادات المعقدة يمكنهم استبدال الخطوات الحقيقية ببدائل أو "أرقام سحرية" أو اختراقات regex ضيقة تبدو كحلول لكنها لا تصمد أمام الاختبار الحقيقي.

ماذا يعني كل هذا

يوضح التحليل جيداً الحالة الحقيقية لـ agentic RAG في 2026. في المهام التي تتضمن وثائق قانونية، ليس المخطط الأكثر براقة هو الذي ينتصر، بل الذي يتحكم في التقسيم والتأسيس والبيانات الوصفية والاختبار. بالنسبة للفرق التي تبني بحثاً معتمداً على الذكاء الاصطناعي عن قواعد المعرفة الداخلية، الاستنتاج بسيط: أولاً تحتاج إلى بناء استرجاع موثوق والقابلية للقياس، وعندها فقط أضيف الموجهات والوكلاء والتنسيق المعقد.