RAG: التقنية التي تمنح الذكاء الاصطناعي ذاكرة عملية

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

لكن خلف هذا الانبهار ظهرت مشكلة جوهرية لم تستطع العروض التسويقية إخفاءها طويلاً:

النموذج اللغوي قد يتحدث بثقة، لكنه لا يعرف بالضرورة ما تحتويه ملفات المؤسسة، ولا ما تم الاتفاق عليه أمس، ولا أين توجد أحدث نسخة من العقد، ولا أي تقرير يجب الاعتماد عليه.

قد يكون النموذج قادراً على شرح قانون معقد، أو كتابة برنامج، أو تلخيص موضوع عام، لكنه عندما يُسأل:

ما آخر سعر اعتمده العميل؟

أو:

ما البند المتعلق بإنهاء العقد أثناء فترة التجربة؟

أو:

ماذا قال مدير المشروع في الاجتماع الأخير؟

فإنه يواجه حدوداً واضحة. المعلومات المطلوبة قد تكون موجودة داخل ملف PDF، أو رسالة بريد إلكتروني، أو جدول Excel، أو تسجيل صوتي، أو عرض PowerPoint، أو قاعدة بيانات داخلية لم يسبق للنموذج أن شاهدها.

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

ما هو RAG؟

RAG هو اختصار لعبارة:

Retrieval-Augmented Generation

أي:

التوليد المعزّز باسترجاع المعلومات.

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

يمكن تشبيه الأمر بصحفي استقصائي ذكي جداً، لكنه لا يحفظ كل الوثائق في رأسه.

عندما تطلب منه إعداد تقرير عن قضية ما، لا يبدأ بالكتابة من ذاكرته مباشرة، بل يذهب إلى الأرشيف، ويفتش في الملفات، ويقارن بين الوثائق، ويستخرج المقاطع المهمة، ثم يكتب التقرير مستنداً إلى الأدلة.

هذه هي وظيفة RAG تقريباً:

سؤال المستخدم
      ↓
البحث في المصادر
      ↓
استخراج المعلومات ذات الصلة
      ↓
إرسالها إلى النموذج
      ↓
إنشاء إجابة مدعومة بالمصادر

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

لماذا لا يكفي النموذج اللغوي وحده؟

النماذج اللغوية تُدرّب على كميات ضخمة من النصوص، لكنها لا تملك تلقائياً وصولاً إلى ملفات المستخدم الخاصة أو بيانات شركته الداخلية.

حتى لو كان النموذج قوياً، فإنه لا يعرف تلقائياً:

• العقود التي وقعتها المؤسسة.
• الرسائل التي وصلت صباح اليوم.
• الأسعار الحالية للمنتجات.
• ملفات المشاريع الداخلية.
• قرارات الاجتماعات.
• السياسات التشغيلية الخاصة بالشركة.
• المواد الدراسية الخاصة بالطالب.
• آخر نسخة من تقرير مالي.
• حالة مشروع محدد.

وعندما لا يجد النموذج معلومات كافية، قد يرفض الإجابة، أو يعطي إجابة عامة لا تناسب السياق، أو يخمّن إجابة تبدو مقنعة لكنها قد تكون خاطئة.

الاحتمال الثالث هو الأخطر؛ لأن الخطأ لا يبدو دائماً كخطأ. قد يأتي بصياغة واثقة ومنظمة تجعل المستخدم يثق به.

RAG لا يقضي تماماً على الأخطاء، لكنه يقلل مساحة التخمين عبر إجبار النظام على الرجوع إلى مصادر فعلية قبل الإجابة.

كيف يعمل RAG عملياً؟

لنفترض أن شركة لديها مجموعة من العقود والسياسات والتقارير، ويسأل أحد الموظفين:

ما مدة الإشعار المطلوبة لإنهاء عقد الموظف أثناء فترة التجربة؟

يبدأ النظام بتحليل السؤال، ثم يبحث عن الملفات التي يحتمل أن تحتوي الإجابة. قد يجد عقد الموظف، وسياسة الموارد البشرية، ونسخة قديمة من لائحة داخلية، ورسالة بريد مرتبطة بالتوظيف.

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

القيمة هنا ليست فقط في صياغة الجواب، بل في قدرة النظام على الإشارة إلى الملف والصفحة أو البند الذي استند إليه.

Embeddings: تحويل المعنى إلى أرقام

أحد المكونات الأساسية في أنظمة RAG هو ما يُسمى Embeddings.

الـEmbedding هو تمثيل رقمي للنص. لا يتم تحويل الكلمات إلى أرقام اعتباطية، بل إلى متجه رياضي يمثل معناها تقريباً.

على سبيل المثال، قد تكون العبارتان:

إنهاء عقد الموظف خلال فترة التجربة.

و:

هل يمكن فصل الموظف في الأشهر الأولى من التوظيف؟

مختلفتين في الكلمات، لكن معناهما متقارب. يحول نموذج الـEmbedding كل عبارة إلى مجموعة أرقام، ويستطيع النظام قياس مدى قرب المعنى بين السؤال والمقاطع المخزنة.

لكن استخدام الـEmbeddings لكل شيء ليس حلاً سحرياً. عندما يكون لدى المستخدم ملايين الملفات، فإن تضمين كل فقرة في كل ملف قد يؤدي إلى ارتفاع التكلفة، وزيادة حجم قاعدة البيانات، وبطء الفهرسة، وصعوبة تحديث الملفات، وتشويش نتائج البحث.

من RAG التقليدي إلى الفهرسة الهرمية

في الأنظمة الصغيرة، يمكن تقسيم كل مستند إلى مقاطع، ثم عمل Embedding لكل مقطع. لكن هذا النهج يبدأ في الانهيار عندما تكون الملفات كثيرة ومتنوعة.

الحل الأكثر كفاءة هو الفهرسة الهرمية:

المستوى الأول: ما الملف المناسب؟
المستوى الثاني: ما القسم المناسب؟
المستوى الثالث: ما المقطع الدقيق؟

يتم إنشاء بطاقة تعريف خفيفة لكل ملف تحتوي على اسم الملف، ونوعه، وعنوانه، ووصفه المختصر، وموضوعاته الرئيسية، والكيانات المذكورة، والأقسام أو الشرائح أو الأوراق، وتاريخ الإنشاء والتعديل، وحالة الملف، ومصدره، وصلاحيات الوصول إليه.

ثم يتم عمل Embedding لهذه البطاقة الصغيرة، وليس بالضرورة لكل محتوى الملف.

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

هذا يشبه مكتبة ضخمة لا تنسخ كل صفحات الكتب داخل الفهرس، بل تسجل عنوان كل كتاب وموضوعاته وفصوله ومكانه على الرف. عند الحاجة فقط، يتم فتح الفصل المناسب.

النموذج الموحّد للملفات

من أكبر التحديات في المشاريع الواقعية أن المستخدمين لا يرفعون ملفات نصية فقط. قد تحتوي المنظومة على PDF وWord وPowerPoint وExcel وCSV وصور وملفات ممسوحة ضوئياً وبريد إلكتروني وتسجيلات صوتية وفيديو وملفات برمجية وقواعد بيانات.

لكل نوع طبيعة مختلفة. ملف Excel ليس مقالة طويلة، وتسجيل الاجتماع ليس عقداً، وصورة الفاتورة ليست ملف Word، والعرض التقديمي قد يحمل المعلومة الأساسية داخل رسم بياني.

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

بالنسبة إلى PDF قد تُحفظ الصفحات والعناوين والجداول وحالة المسح الضوئي. وبالنسبة إلى Excel تُحفظ أسماء الأوراق والأعمدة وعدد الصفوف والنطاق الزمني. وبالنسبة إلى الصوت تُحفظ مدة التسجيل والمتحدثون والموضوعات والتوقيتات.

الواجهة موحدة، لكن طريقة معالجة كل نوع تبقى متخصصة.

لماذا لا يجوز تحويل جميع الملفات إلى نص؟

من الأخطاء الشائعة تحويل كل شيء إلى نص، ثم وضعه داخل Vector Database. قد يبدو ذلك بسيطاً، لكنه يؤدي إلى فقدان البنية الأصلية للمعلومات.

في Excel، مثلاً، قد يحتوي الملف على مئات الآلاف من الصفوف. تحويلها إلى نص ثم البحث فيها دلالياً ليس الطريقة الصحيحة لحساب المبيعات أو مقارنة التكاليف.

إذا سأل المستخدم:

كم بلغت مبيعات دبي في شهر يونيو؟

فالأفضل أن يحول النظام السؤال إلى استعلام بيانات، لا إلى بحث دلالي داخل نص طويل.

القاعدة العملية هي:

• النصوص تستخدم البحث النصي والدلالي.
• الجداول تستخدم SQL أو محركات تحليل البيانات.
• الصور تستخدم OCR ونماذج الرؤية.
• الصوت يستخدم التفريغ الزمني.
• الفيديو يستخدم النص والصوت والإطارات.
• الكود يستخدم تحليل الرموز والبنية.
• البريد الإلكتروني يستخدم تسلسل المحادثة والمرفقات.

ليس الهدف تخزين كل شيء بالطريقة نفسها، بل تقديم واجهة واحدة فوق عدة محركات متخصصة.

Watchdog: حارس الملفات

في المشاريع العملية، لا يكفي بناء فهرس مرة واحدة. الملفات تتغير باستمرار. قد يدخل عقد جديد، أو تُعدّل نسخة من تقرير، أو يُحذف ملف، أو يصل مرفق عبر البريد.

لهذا يمكن إنشاء خدمة مراقبة تسمى Watchdog أو Change Detector، وظيفتها اكتشاف إنشاء الملف وتعديله وحذفه ونقله وإعادة تسميته.

لكن الـWatchdog لا ينبغي أن يقوم بالمعالجة الثقيلة بنفسه. دوره يشبه موظف الاستقبال الذي يعلن وصول الطرد، ثم يرسله إلى القسم المختص.

File added or modified
        ↓
Watchdog detects event
        ↓
Job Queue
        ↓
Ingestion Worker
        ↓
Parser
        ↓
Metadata extraction
        ↓
Light indexing

عندما يدخل ملف جديد، يمر عبر Pipeline تشمل اكتشاف النوع الحقيقي، والتحقق من اكتمال الرفع، وحساب البصمة، وفحص الملف أمنياً، واختيار Parser مناسب، واستخراج المعلومات الرئيسية، وإنشاء بطاقة موحدة، وفهرسة الوصف والعناوين.

أما الفهرسة العميقة فيمكن تأجيلها إلى حين احتياج المستخدم للملف.

الفهرسة البطيئة عند الطلب

تُعرف هذه الفكرة باسم Lazy Indexing أو On-Demand Indexing.

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

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

RAG في الشركات

مساعد للموظفين

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

تحليل العقود

يستطيع النظام استخراج مدة العقد، وشروط الإنهاء، والتجديد التلقائي، وبنود المسؤولية، ومقارنة نسختين. لكن في الاستخدام القانوني، يجب أن يعرض البند والصفحة والنسخة والتاريخ، لا أن يكتفي بإجابة عامة.

إدارة المشاريع

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

دعم العملاء

يمكن ربط النظام بدليل المنتج وسياسات الضمان وتذاكر الدعم. عندما يرسل العميل مشكلة، يبحث الوكيل عن المنتج والإصدار والحالات المشابهة والحل المعتمد، ثم يصيغ رداً مخصصاً.

البحث في البريد والاجتماعات

قد يسأل المدير: ماذا اتفقنا مع العميل بشأن موعد التسليم؟ فيبحث النظام في البريد ومحاضر الاجتماعات والتسجيلات والمرفقات، ثم يعرض الاتفاق والزمن والمصدر.

هذه القدرة تحول الأرشيف المؤسسي من مخزن غير مستغل إلى ذاكرة تشغيلية.

RAG في التعليم

لدى الطالب عادة كتب وشرائح وتسجيلات وصور سبورة وواجبات واختبارات سابقة وملاحظات شخصية وأوراق بحثية.

يمكن لنظام RAG أن يبني خريطة معرفية لهذه المصادر، ثم يسمح للطالب بالسؤال:

• اشرح هذا المفهوم من محاضراتي فقط.
• أنشئ اختباراً من الفصلين الثالث والرابع.
• أين شرح الدكتور هذه المعادلة؟
• ما المواضيع التي لم أراجعها بعد؟

الفرق بين مساعد تعليمي عام ونظام مبني على RAG هو أن الثاني يعمل داخل منهج الطالب الفعلي.

إنشاء اختبارات مخصصة

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

اكتشاف الفجوات

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

هنا يتحول RAG من أداة لاسترجاع المعلومات إلى مكوّن داخل نظام تعلم تكيفي.

RAG في البحث الأكاديمي

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

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

RAG في الأنظمة التقنية

يمكن استخدامه داخل فرق البرمجيات للبحث في مستودعات الكود، ووثائق API، وسجلات الأعطال، وPull Requests، وIssues، وتصاميم النظام، وقرارات العمارة التقنية.

يسأل المطور: أين يتم التحقق من صلاحيات المستخدم؟ فيستخدم النظام بحث الرموز وتحليل AST، بدلاً من البحث النصي وحده.

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

ما علاقة RAG بدائرة التعلم الذاتي؟

RAG وحده لا يعني أن الوكيل يتعلم ذاتياً. RAG يمنح الوكيل القدرة على الوصول إلى المعرفة، أما دائرة التعلم فتسمح له بتحسين طريقة استخدام هذه المعرفة.

لنفترض أن المستخدم يسأل عن السعر الحالي للنشر المحلي. يختار النظام ملف PDF قديماً، بينما السعر الأحدث موجود في Excel. يصوب المستخدم الخطأ.

إذا كان النظام يحتفظ فقط بالإجابة النهائية، فلن يتعلم شيئاً. أما إذا سجل مسار الاسترجاع، فسيعرف السؤال، والملفات المرشحة، والملف المختار، وتاريخ كل ملف، ونوع المصدر، وتصحيح المستخدم، والمصدر الصحيح.

ثم يستطيع استنتاج قاعدة: في الأسئلة المتعلقة بالسعر الحالي، أعطِ أولوية للملفات المنظمة الحديثة والمعتمدة، وتجنب المسودات القديمة.

هذه ليست عملية تدريب للنموذج نفسه، بل تحسين لسياسة الاسترجاع.

ذاكرة المعرفة وذاكرة الخبرة

في الوكيل المتقدم، يوجد نوعان من الذاكرة:

ذاكرة المعرفة

تحتوي على العقود والملفات والسياسات والجداول والرسائل والمحاضرات والوثائق.

ذاكرة الخبرة

تحتوي على الملف الذي نجح سابقاً، والأداة المستخدمة، والخطأ الذي حدث، وتصحيح المستخدم، والاستراتيجية التي حققت نتيجة أفضل.

عندما يأتي سؤال جديد، يبحث الوكيل في كليهما:

السؤال
 ├── البحث عن المعرفة
 └── البحث عن تجارب سابقة مشابهة

هنا يبدأ النظام في التصرف كوكيل يتعلم، لا كمجرد واجهة بحث.

أنواع الأخطاء التي يجب أن يتعلم منها النظام

القول إن الإجابة خاطئة لا يكفي. يجب تصنيف الخطأ:

• فهم خاطئ للسؤال.
• اختيار مصدر خاطئ.
• اختيار نسخة قديمة.
• استخراج صفحة خاطئة.
• فشل قراءة جدول.
• تجاهل مرفق.
• اختيار أداة غير مناسبة.
• توليد استنتاج غير موجود في المصدر.
• عدم مراعاة صلاحية الوصول.
• إرسال سياق أكثر من اللازم.
• نقص المعلومات المسترجعة.

كل نوع من الأخطاء يقود إلى تحسين مختلف.

التقييم قبل التعلم

من الأخطاء الخطيرة السماح للوكيل بتعديل سلوكه بناءً على كل تصحيح منفرد. قد يكون المستخدم مخطئاً، أو تكون المعلومة حساسة، أو يكون التصحيح خاصاً بحالة واحدة.

لذلك يجب تقسيم التعلم إلى ثلاث درجات:

تعلم فوري وآمن

مثل حفظ تفضيل المستخدم، وتسجيل التصحيح، وإضافة اسم بديل لمشروع، وتفضيل ملف اختاره المستخدم داخل المهمة.

تعلم يحتاج تكراراً

مثل تعديل أوزان ترتيب النتائج، وتفضيل نوع ملف معين، وتغيير استراتيجية Chunking، وتحسين اختيار الأدوات.

تعلم يحتاج مراجعة بشرية

مثل تغيير سياسات الشركة، وتعديل الصلاحيات، وحذف المعرفة، واعتماد حقيقة مالية، وتغيير قواعد الامتثال أو الـPrompt الرئيسي.

التعلم الذاتي الآمن ليس حرية غير محدودة، بل تحسين مضبوط وقابل للمراجعة والتراجع.

ما الذي يمكن قياسه؟

حتى نعرف ما إذا كان النظام يتحسن، يجب استخدام مؤشرات واضحة:

• نسبة اختيار الملف الصحيح.
• نسبة العثور على القسم الصحيح.
• Recall@K.
• دقة الإجابات المدعومة بمصادر.
• نسبة استخدام وثائق قديمة.
• عدد تصحيحات المستخدم.
• معدل إعادة السؤال.
• متوسط Tokens المستخدمة.
• متوسط زمن الوصول إلى الإجابة.
• نجاح تنفيذ الأدوات.
• دقة اختيار نوع المصدر.
• نسبة الإجابات التي تحتوي مرجعاً دقيقاً.
• تكلفة معالجة الملف والإجابة الواحدة.

يمكن أن يبدأ النظام بمتوسط 7,000 Token لكل سؤال، ثم ينخفض إلى 2,000 Token بعد تحسين الاسترجاع، مع ارتفاع دقة اختيار المصدر. هذا تحسن حقيقي يمكن قياسه.

الأخطاء الشائعة في مشاريع RAG

تضمين كل شيء

تقوم بعض الفرق بتقسيم كل الملفات وإنشاء Embeddings لملايين المقاطع قبل أن تعرف ما يحتاجه المستخدم. النتيجة تكلفة عالية وفهرس ضخم ونتائج مشوشة وصعوبة في التحديث.

الاعتماد على Vector Search فقط

البحث الدلالي ممتاز، لكنه ليس بديلاً عن البحث بالكلمات والفلاتر والتاريخ والحالة والصلاحيات ونوع المستند والبيانات المنظمة والمطابقة الدقيقة للأسماء.

تجاهل النسخ

قد توجد عدة نسخ من الملف: Draft وReviewed وApproved وFinal وArchived. إذا لم يفهم النظام دورة حياة الوثيقة، قد يقدم نسخة قديمة باعتبارها الحقيقة.

فقدان المصدر

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

إهمال الصلاحيات

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

استخدام LLM لكل خطوة

يمكن للأنظمة التقليدية تنفيذ اكتشاف نوع الملف، واستخراج Metadata، وحساب Hash، واكتشاف التكرار، والبحث النصي، وتنفيذ SQL، وفلترة النتائج بتكلفة أقل. يستخدم LLM فقط عندما يضيف فهماً حقيقياً.

البنية العملية لنظام RAG متقدم

Sources
├── Filesystem
├── Object storage
├── Email
├── Cloud drives
├── Databases
└── APIs
       ↓
Change detection
       ↓
Queue
       ↓
Ingestion pipeline
       ↓
Type-specific parsers
       ↓
Unified document model
       ↓
Lightweight catalog
       ↓
Hybrid retrieval
       ↓
Deep parsing on demand
       ↓
Reranking
       ↓
LLM or agent
       ↓
Answer with evidence
       ↓
Evaluation and feedback
       ↓
Learning loop

وقد تشمل التقنيات PostgreSQL لتخزين Metadata، وPostgreSQL Full-Text Search، وpgvector، وObject Storage، وRedis، وWorkers، وOCR، وDuckDB أو Polars، وSpeech-to-Text، ونماذج الرؤية، وReranker.

لا تحتاج المؤسسة إلى عشرات الخدمات من اليوم الأول. يمكن البدء كتطبيق Modular Monolith، ثم فصل الأجزاء عند نمو الحمل.

من البحث إلى الوكيل

المرحلة الأولى من RAG تجيب عن السؤال: أين توجد المعلومة؟ لكن الوكيل المتقدم يتجاوز ذلك إلى: ماذا ينبغي أن أفعل بالمعلومة؟

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

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

هل RAG هو ذاكرة الذكاء الاصطناعي؟

يمكن القول إنه جزء من الذاكرة، لكنه ليس الذاكرة كلها. RAG يمثل ذاكرة خارجية قابلة للبحث.

أما الذاكرة الكاملة فقد تشمل معرفة المؤسسة، وتاريخ المحادثات، والحالات السابقة، وتفضيلات المستخدم، وقواعد العمل، والتصحيحات، ونتائج تنفيذ الأدوات، وقرارات البشر، وتقييمات الجودة.

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

الخلاصة

القيمة الحقيقية لـRAG لا تكمن في أنه يسمح للنموذج بقراءة ملفات PDF، بل في أنه ينقل الذكاء الاصطناعي من عالم الإجابات العامة إلى عالم المعرفة الخاصة القابلة للتحقق.

RAG الناجح لا يعني وضع كل المستندات في قاعدة Vector، بل يعني بناء منظومة تعرف:

• ما الملفات الموجودة؟
• ماذا يحتوي كل ملف؟
• أي نسخة هي الأحدث؟
• ما المصدر الأكثر موثوقية؟
• ما طريقة البحث المناسبة؟
• ما الجزء الذي يجب إرساله إلى النموذج؟
• كيف نعرض الدليل؟
• كيف نتعلم من الأخطاء؟

المعادلة النهائية ليست:

Files + Embeddings = RAG

بل:

فهم الملفات
+ فهرسة هرمية
+ استرجاع هجين
+ توجيه حسب نوع المصدر
+ سياق محدود
+ مصادر قابلة للتحقق
+ تقييم مستمر
= نظام RAG عملي

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

عندها لا يصبح السؤال: هل يستطيع الذكاء الاصطناعي قراءة الملفات؟ بل: هل يستطيع فهم أي ملف يحتاجه، والعثور على المعلومة الصحيحة، واستخدامها في الوقت المناسب، ثم تحسين طريقة عمله بعد كل تجربة؟

هذه هي الحدود الحقيقية التي يحاول RAG تجاوزها.