ما هو RAG ولماذا أصبح ضرورة لكل منتج يعتمد على LLM؟

خلال الشهور الأخيرة سمعنا عبارة Retrieval-Augmented Generation (RAG) في كل مؤتمر تقني. في هذه المقالة نشرح هذا النمط بلغة عملية، ونجيب عن السؤال الأهم: متى نحتاجه فعلًا، وكيف نبنيه بأمان فوق بيانات مؤسستنا؟

لماذا لا نكتفي بالـ LLM وحده؟

نماذج اللغة الكبيرة مذهلة في التوليد، لكنها تحمل ثلاث مشكلات جوهرية:

• الهلوسة (Hallucination): تُنتج إجابات تبدو صحيحة وتكون مُختلَقة.
• قطع المعرفة (Knowledge cutoff): لا تعرف شيئًا بعد تاريخ تدريبها.
• البيانات الخاصّة: لا يمكن للنموذج الوصول إلى بياناتك الداخلية.

ما هو RAG باختصار؟

RAG ببساطة: «قبل الإجابة، ابحث في بياناتك الخاصّة، استخرج السياق، وأعطِه للنموذج». يتكوّن المسار من أربع مراحل:

1. التجميع: نقسّم الوثائق إلى قطع صغيرة (chunks) بحجم 500–1000 token.
2. الفهرسة: نُنتج متجّهات دلالية (embeddings) ونخزّنها في قاعدة متجّهات.
3. البحث: عند وصول سؤال، نحوّله إلى embedding ونبحث عن أقرب القطع.
4. التوليد: نمرّر القطع + السؤال إلى الـ LLM الذي يكتب الإجابة مُسنَدة بمراجع حقيقية.

متى نحتاجه؟

القاعدة العملية: إن كانت الإجابة تعتمد على معرفة داخلية، تتغيّر دوريًا، أو يجب إثبات مصدرها — فأنت تحتاج RAG.

أمثلة شائعة: شات دعم فني فوق قاعدة معرفة الشركة، مساعد داخلي للموارد البشرية يقرأ سياسات الشركة، أو مساعد قانوني يستند إلى عقود حقيقية.

أفضل الممارسات الأمنية

• عزل متجّهات كل عميل (Tenant) في مجموعته الخاصّة.
• وضع سياسات وصول (RBAC) قبل البحث، لا بعده.
• تسجيل كل استعلام + الإجابة لأغراض التدقيق.
• مراقبة drift الجودة أسبوعيًا بمجموعة أسئلة مرجعية.

ماذا نستخدم في برمجيات الريادة الذكية؟

نبني RAG عادة باستخدام pgvector داخل PostgreSQL (يُغنينا عن قاعدة بيانات منفصلة)، طبقة NestJS 10 للـ retrieval، وواجهة Next.js 14 مع streaming للردود. النتائج ثابتة ومراقبتها مباشرة.