تنتهي معظم دروس RAG عند مرحلة دفتر الملاحظات (notebook). حيث يتم تحميل بعض ملفات PDF المنقحة، وتقسيم النص كل ألف حرف، وحشو الأجزاء في قاعدة بيانات متجهية (vector database)، وتسمية ذلك بنية نظام (architecture). في عصر يوم الجمعة، يعمل هذا العرض التوضيحي بشكل مثالي. ولكن في بيئة الإنتاج، يتحول نفس المسار بهدوء إلى عبء تقني.

إن عنق الزجاجة الحقيقي في أنظمة الاسترجاع نادرًا ما يكون النموذج أو الأوامر (prompts). بل هو عملية الإدخال (ingestion). لا يمكن لمسار RAG إلا استرجاع ما تم تغذيته به، وإذا كانت التغذية مشوشة، أو قديمة، أو غير مكتملة، فسيقدم النموذج معلومات غير منطقية بثقة تامة. عندما يشتكي المستخدمون من أن البوت قد "هلوس" (hallucinated)، فإن الخطأ غالبًا ما يكمن في مراحل سابقة بعيدة في مسار البيانات الذي لا يراقبه أحد عن كثب.

فخ السبورة البيضاء

تجعل المخططات الهيكلية عملية الإدخال تبدو وكأنها سهم واحد مكتوب عليه "Documents → Vector DB". لكن الواقع أكثر تعقيدًا. فأنظمة المصدر تتغير دون إشعار، وتصاميم HTML تخضع لإعادة تصميم، والروابط (URLs) تعيد التوجيه إلى صفحات هبوط عامة، وإطارات عمل JavaScript تستبدل المحتوى بعد استجابة HTTP الأولية. إن التعامل مع الإدخال كمهمة إعداد لمرة واحدة هو الخطأ الأول؛ فهي مشكلة هندسة بيانات مستمرة تستحق نفس الدقة التي يتطلبها أي مسار ETL.

لماذا تكون إخفاقات RAG عادةً ناتجة عن فشل في التغذية

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

يتكرر هذا النمط باستمرار. تضيع الفرق ساعات في ضبط درجة الحرارة (temperature) و top-k بينما تكون مجموعة النصوص (corpus) مليئة بتذييلات التنقل، والبيانات الصحفية المكررة، والأجزاء التي تقسم الجداول إلى نصفين. قبل أن تقوم بتحسين عملية التوليد (generation)، قم بمراجعة ما يُسمح لنظامك بمعرفته.

سبعة فخاخ تدمر عملية الإدخال

1. التشغيل الأول هو مجرد خدعة

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

2. الزحف ليس هو عملية الإدخال

جلب ملفات HTML هو الجزء السهل. الزحف الخام يلتقط كل شيء: لافتات ملفات تعريف الارتباط (cookie banners)، والأشرطة الجانبية لـ "المقالات ذات الصلة"، ومربعات الإعلانات، وإشعارات حقوق النشر في التذييل. إذا قمت بتقسيم ملف HTML الخام هذا بشكل ساذج، فسيحمل كل جزء من النص معه أجزاء من قائمة التنقل. عندما يسأل المستخدم عن حدود معدل واجهة برمجة التطبيقات (API rate limits)، قد يظهر المسترجع جزءًا يتكون بنسبة 40% من روابط الشريط الجانبي. الاستخراج النظيف أمر بالغ الأهمية. يجب عليك تحديد منطقة المحتوى الرئيسية، وإزالة النصوص النمطية (boilerplate)، وحذف العناصر التي تتكرر في كل صفحة. وإلا، فأنت لا تبني قاعدة معرفية، بل تبني محرك بحث لعناصر واجهة الموقع (website chrome).

3. التقسيم (Chunking) يكسر المعنى

التقسيم ذو الحجم الثابت (Fixed-size chunking) هو الخيار الافتراضي في كل دليل تشغيل سريع تقريبًا، وهو أمر خطير. إذا قمت بتقسيم مستند بناءً على عدد الأحرف فقط، فستقوم بقطع الجداول من المنتصف، وفصل الخطوتين 4 و5 في إجراء مرقم، وتشريد النقاط النقطية عن عناوينها. الجزء الذي يحتوي فقط على النصف الثاني من جدول الأسعار لا فائدة منه دلاليًا. التقسيم المدرك للبنية (Structure-aware chunking) يحترم التنسيق الأصلي. قم بتحليل تسلسل العناوين، وحافظ على الجداول سليمة قدر الإمكان، وقسم النصوص عند حدود الفقرات تحت نفس عنوان H2 أو H3. حافظ على القوائم داخل جزء واحد إذا كانت قصيرة بما يكفي. الهدف ليس الحصول على كتل متساوية الحجم، بل الحصول على وحدات ذات معنى متماسكة.

4. مشكلة الحداثة

إن أخذ لقطة ثابتة لويكي داخلي هو الوضع البسيط، أما الاستيعاب المستمر من الويب المباشر فهو أمر صعب. تحتاج إلى معرفة متى تم جمع الصفحة لآخر مرة، وما إذا كانت قد تغيرت منذ ذلك الحين، ومدة صلاحية المعلومات. البيانات القديمة لا تعني دائمًا وجود تاريخ قديم ظاهر؛ فأحيانًا تقوم الصفحة بتحديث نصها مع الاحتفاظ بنفس عنوان URL، لذا لن يلاحظ نظامك ذلك أبدًا بدون استخدام "content hashing" (تجزئة المحتوى). ضع قواعد تحديث واضحة بناءً على مدى تقلب المصدر. فقد يحتاج تدفق البيانات المالية إلى فحوصات كل ساعة، بينما قد تحتاج صفحة "عن الشركة" إلى فحوصات ربع سنوية. سجل الطوابع الزمنية وحدد حدود "وقت الصلاحية" (time-to-live)، خاصة إذا كان نطاق عملك يتضمن إرشادات منظمة أو حساسة للسلامة حيث يمكن للحقائق القديمة أن تسبب ضررًا حقيقيًا.

5. تلوث التكرار (Duplicate Pollution)

المواقع الإلكترونية مليئة بالتكرار. يظهر وصف المنتج نفسه في صفحة الفئة، وصفحة المنتج، وصفحة هبوط ترويجية. والبيان الصحفي نفسه يوجد تحت /news/ و /press/ و /blog/. البحث المتجهي (Vector search) لا يقوم بإزالة التكرار تلقائيًا. إذا وُجدت عشر قطع (chunks) متطابقة تقريبًا في قاعدة بياناتك، فقد تحجب النتائج المتنوعة وذات الصلة في عملية الاسترجاع (top-k retrieval). تحتاج إلى تتبع المصدر الأصلي (canonical tracking) أو إزالة تكرار المحتوى قبل عملية التضمين (embedding). إذا قالت قطعتان الشيء نفسه، فاحتفظ بالمصدر الموثوق وتخلص من النسخ. فالمسترجع (retriever) لديك لديه مساحات محدودة، فلا تضيعها سدى.

6. فقدان البيانات الوصفية (Missing Metadata)

قاعدة البيانات المتجهية بدون بيانات وصفية (metadata) ليست سوى محرك بحث نصي كثيف يفتقر إلى ذاكرة السياق. يعتمد الاسترجاع الذكي على إشارات التصفية والترتيب التي لا تستطيع التضمينات الخام (raw embeddings) توفيرها. قم بتخزين عنوان URL للمصدر، وتاريخ الالتقاط، وفئة المستند، ورقم الإصدار. إذا كنت تستوعب وثائق API، فإن تحديد الإصدارات أمر ضروري؛ فبدونه، قد تدمج الاستعلامات مواصفات الإصدار الأول (v1) والثاني (v2) في إجابة واحدة. وإذا كنت تستوعب سياسات الموارد البشرية، فإن التصنيف حسب المنطقة أو القسم يتيح لك تصفية النتائج قبل وصولها إلى النموذج. البيانات الوصفية تحول كومة من النصوص إلى نظام معرفي منسق.

7. فجوات JavaScript

المواقع الحديثة لا ترسل محتواها في حمولة HTML الأولى، بل ترسل هيكلًا (skeleton) ثم تقوم بملئه (hydrate) عبر استدعاءات JavaScript. قد لا يرى طلب HTTP بسيط سوى أيقونة تحميل وهيكل تخطيطي. إذا لم تتمكن خطوط المعالجة (pipeline) لديك من تنفيذ JavaScript، فستقوم باستيعاب صفحات فارغة أو أجزاء ناقصة دون أن تدرك وجود خطأ ما. استخدام متصفح بدون واجهة (headless browser) يحل مشكلة التصيير (rendering) ولكنه يطرح مشكلات جديدة: استهلاكًا أكبر للذاكرة، وإنتاجية أبطأ، وحواجز كشف البوتات. اختر التنازلات التي ستقبل بها بعناية، ولكن لا تتظاهر بأن ما يعادل أمر curl البسيط كافٍ لكل مصدر.

قائمة مراجعة عملية للاستيعاب

إذا كنت تقوم ببناء أو مراجعة تدفق بيانات RAG، فابدأ من هنا:

  • التحقق من تغطية المصدر والترقيم (pagination). قد تسرد خريطة الموقع (sitemap) أول عشر مقالات فقط في فئة ما. قم بالزحف بعمق وتحقق من أن المحتوى المرقم أو المحمل ديناميكيًا قد تم التقاطه بالفعل.
  • إزالة النصوص النمطية (boilerplate) قبل تقسيم المحتوى (chunking). جرد عناصر التنقل، والإعلانات، والتذييلات، وإخلاء المسؤولية القانونية المتكرر. إذا ظهرت عبارة في كل صفحة، فهي مجرد ضجيج.
  • استخدام تقسيم للمحتوى يراعي الهيكل (structure-aware chunking). احترم العناوين، والقوائم النقطية، والجداول. قم بالتقسيم بناءً على الحدود الدلالية (semantic boundaries)، وليس عدد الأحرف.
  • إرفاق بيانات وصفية غنية. قم بتضمين URL، وتاريخ الالتقاط، وفئة المحتوى، والإصدار. اجعل هذه الحقول قابلة للتصفية في استعلامات الاسترجاع الخاصة بك.
  • تحديد ترددات التحديث بناءً على تقلب البيانات. المصادر سريعة التغيير تحتاج إلى إعادة زحف متكررة، بينما الأرشيفات الثابتة لا تحتاج لذلك.
  • مراقبة مجموعة البيانات (corpus)، وليس فقط حالة المهمة. يمكن لخط المعالجة أن ينتهي برمز الحالة صفر (code zero) بينما ينتج بيانات غير مفيدة. قم بمراجعة عينات من القطع (chunks) المخزنة بانتظام للتحقق من الانحراف والجودة.
  • تحديد قواعد للإصدارات والحذف. عندما تتم إزالة صفحة مصدر، احذف القطع الخاصة بها. وعندما يتم تحديثها، قم باستبدالها أو إصدار نسخ منها. البيانات اليتيمة (Orphaned data) هي قاتل صامت.

الحقيقة المرة حول التضمينات

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

تبدأ جودة الاسترجاع من طبقة الاستيعاب. هذه الطبقة هي التي تحدد ما إذا كان نظام RAG الخاص بك أداة مفيدة أم مجرد كاذب واثق لديه قاعدة بيانات متجهية خلفه.

الخلاصة الحقيقية

توقف عن قياس صحة عملية استيعاب البيانات عبر لوحات تحكم مسارات البيانات وحدها. فنجاح المهام وخلو السجلات من الأخطاء لا يضمنان جودة مجموعة البيانات. افتح قاعدة البيانات واقرأ الأجزاء (chunks) الفعلية التي سيسترجعها المستخدمون. إذا كان النص مليئاً بإشعارات حقوق النشر، والجداول المجزأة، وصفحات السياسات القديمة، فإن مشكلتك ليست في الـ LLM. أصلح مصدر البيانات أولاً؛ فكل ما سواه ليس سوى محاولة لضبط نموذج يعمل فوق بيانات رديئة.