لماذا تخلّصنا من 70% من قاعدة بيانات الشركة دون كتابة سطر واحد من الكود: التشريح الهندسي لأنظمة RAG في المؤسسات

• نسبة المشكلات في البيانات: 70-80% من جميع حالات فشل RAG المؤسسي (30% إصدارات قديمة، 20% تكرارات، 15% نتائج OCR معطوبة)
• حالة فعلية من تنظيف قاعدة بيانات: تقليص العدد من 12000 إلى 3800 وثيقة أدى إلى ارتفاع كبير في دقة البحث
• الزيادة الناتجة عن Tool-based RAG: حتى +70% في جودة الإجابة عند الانتقال من البحث الأعمى المسبق (pre-query) إلى function calling
• معاملات تجزيء اللوائح التنظيمية: Parent-Child (جزء بحثي فرعي (child) من 200-300 رمز (token)، وجزء سياقي أصلي (parent) من 1500-2000)

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

يحاول العملاء حل هذه المشكلة عبر تغيير النموذج اللغوي الكبير أو استخدام البحث الرسومي (GraphRAG) الرائج. لكن خبرتي العملية تُظهر نسبة ثابتة: 80% من مهام الشركات تُحل بشكل ممتاز بواسطة نظام RAG متقدم كلاسيكي يعتمد على البيانات الوصفية (metadata) دون الحاجة إلى GraphRAG المعقد للغاية، في حين أن 70-80% من جميع حالات الفشل تكمن في هندسة البيانات، لا في أوزان الشبكة العصبية.

لماذا يُصدر نظام RAG المؤسسي هلوسات ويعثر على لوائح تنظيمية قديمة؟

بين مجلد الوثائق المؤسسية والإجابة الصحيحة للنموذج تقع أربع نقاط اختناق جوهرية:

1. فوضى في مجموعة المدخلات (هندسة البيانات): عندما يرفع العميل لنا 10000 ملف مؤسسي، يتبيّن أن 30% منها إصدارات قديمة دون تواريخ، و20% نسخ مكررة تقريبًا بالكامل، و15% عبارة عن ملفات PDF ممسوحة ضعيفة الجودة مع فوضى ناتجة عن OCR وتذييلات متكررة. في إحدى عمليات التطبيق، من بين 12000 وثيقة سُلّمت لنا موصوفة بأنها «فعلية»، تبقّى بعد التدقيق 3800 وثيقة فقط بالضبط.

قمنا فقط بحذف ثلاثة أرباع «مقبرة الملفات» (عروض تقديمية من عام 2020 ومسودات)، وارتفعت جودة النتائج بشكل مضاعف دون كتابة سطر واحد من الكود. القاعدة الأساسية للتحقق في الأسبوع الأول: فحص نسبة الملفات التي يتجاوز تاريخ تعديلها سنة واحدة. 2.

فشل البحث المتجهي في اللغة الروسية: نموذج `text-embedding-3-large` القياسي من OpenAI غالبًا ما يتعثّر مع المصطلحات التقنية الروسية. وبحسب قياساتنا، تحقق نماذج `multilingual-e5-large` و`jina-embeddings-v3` دقة ملحوظة أعلى على اللوائح التنظيمية المكتوبة بالسيريلية. علاوة على ذلك، يضيع البحث المتجهي البسيط عند استعلامات من نوع «البند 4.

2.1 من الأمر رقم 47» — وهنا يصبح إلزاميًا استخدام بنية هجينة `بحث متجهي + بحث لغوي BM25` مع إعادة ترتيب (reranking) لاحقة. 3.

تدهور صامت دون رصد: تُحدَّث قاعدة البيانات، وبعد شهرين تنخفض الدقة. بالإضافة إلى الثلاثية الأساسية لمقاييس RAGAS (`Faithfulness`، `Answer Relevancy`، `Context Recall`)، ظهر في الإصدار v0.2 مقياس حاسم للشركات هو `Noise Sensitivity` — مدى ثبات الإجابة أمام سياق مشوّش.

وأرخص مؤشر مبكر لرصد عطل RAG في بيئة التشغيل الفعلية هو رسم بياني أسبوعي لمتوسط طول الإجابة بالرموز (tokens): فحين يتوقف النموذج عن العثور على الحقيقة الدقيقة، يبدأ «بالحشو» وتضخيم الفقرات قبل 2-3 أسابيع من ظهور أولى شكاوى المستخدمين. 4. حدّ بنيوي: يعمل RAG مع لقطات ثابتة من البيانات ولا يُعدّ بديلًا عن قاعدة بيانات معاملاتية (CRUD) لمخزون المستودعات أو الأسعار الحيّة.

كيف يتم تقطيع الأجزاء (chunking) بشكل صحيح للوائح التنظيمية والكود وأسئلة FAQ؟

حشر ملف PDF من 80 صفحة في متجه واحد، أو تقطيع الوثائق دون الاحتفاظ بالبيانات الوصفية (المصدر، التاريخ، القسم، المؤلف)، هو طريقة مضمونة لتدمير البحث. لا يوجد حجم موحّد للجزء (chunk)، بل نختار الاستراتيجية بحسب طبيعة الوثيقة:

• العقود القانونية واللوائح الداخلية: استراتيجية `Parent-Child`. يتم البحث عبر جزء فرعي ضيّق (child) من 200-300 رمز (أقصى دقة في المطابقة)، ويُدرَج في موجّه النموذج (prompt) جزء أصلي واسع (parent) من 1500-2000 رمز لتجنّب فقدان الشروط والاستثناءات.
• الوثائق التقنية وأوصاف واجهات البرمجة (API): نافذة ثابتة الحجم (`Fixed-size`) من 500 رمز مع تداخل (`overlap`) قدره 100 رمز، لتجنّب تقطيع الفكرة إلى نصفين.
• كود المصدر في المستودعات (repositories): تقطيع دلالي صرف وفق حدود الدوال والفئات (classes).
• الدلائل القصيرة وقواعد الأسئلة الشائعة (FAQ): طريقة `Sentence window` — نبحث بجملة واحدة، ونُقدّم للنموذج نافذة من `±N` من الجمل المجاورة.

ما العمل عمليًا: لماذا يتفوّق

Tool-based RAG على البحث المدمج (native) بنسبة 70%؟

في التطبيقات البسيطة، يكون البحث مثبّتًا بشكل جامد قبل كل استدعاء للنموذج (Native RAG): يكتب المستخدم في المحادثة «مرحبًا، كيف حالك؟»، فتسحب المنظومة بطاعة خمسة أجزاء عشوائية من النظام الأساسي للشركة من قاعدة البيانات المتجهية، مستهلكة الرموز (tokens) ومشوّشة النموذج دون طائل.

لقد حوّلنا البنية إلى Tool-based RAG: محرك البحث متصل بالنموذج كأداة خارجية عبر `function calling`. يقرّر الوكيل (agent) بنفسه إن كان يحتاج إلى الذهاب إلى قاعدة المعرفة، ويعيد صياغة سؤال المستخدم بنفسه إلى استعلام بحث دقيق، ويقوم عند الحاجة بـ 2-3 استدعاءات موجّهة إلى مجموعات مختلفة. في مشاريعنا، هذا الانتقال وحده يحقق زيادة تصل إلى 70% في جودة الإجابات، كما أن يومين يُخصّصان لكتابة محلّل (parser) نظيف يحوّل ملفات DOCX/PDF إلى صيغة Markdown بنيوية، يوفران أشهرًا من الصراع مع الهلوسات. نستعرض بالتفصيل كل خبايا تصميم RAG على pgvector وأدوات الوكلاء (agentic tools) في دوراتنا الهندسية في [Hamidun Academy](https://academy.hamidun.com) وفي تحليلات البنية في [Vibe Club](https://hamidun.com/club).