RAG: حين تقرأ النماذج اللغوية بيانات خارجية

المشكلة

تبقى معاملات الـ LLM ثابتة بين تحديثات النموذج. ومن دون مصدر بيانات خارجي، يفتقر النموذج إلى معلوماتك الخاصة أو الحالية، مثل سياسة الاسترداد في شركتك أو مستند رفعته الأسبوع الماضي أو سعر السهم اليوم. وقد يعترف بأنه لا يعرف، أو يختلق إجابة ويقدّمها بثقة تامة (وهذا ما يُسمّى hallucination).

أمّا الـ fine-tuning، أي إعادة تدريب النموذج على بياناتك تحديداً، فمكلِف وبطيء، ولا ينفع أصلاً مع بيانات تتغيّر يومياً. فلا بدّ إذن من حلٍّ أبسط.

الحلّ: RAG

RAG اختصار لـ Retrieval-Augmented Generation (التوليد المعزّز بالاسترجاع). ورغم أن الاسم يبدو معقّداً، فكل ما يفعله هو:

1. يطرح المستخدم سؤالاً
2. ابحث في مستنداتك عن الـ chunks ذات الصلة بذلك السؤال
3. الصِق تلك الـ chunks في الـ prompt إلى جانب السؤال
4. دَع النموذج يجيب مستعيناً بالسياق المُقدَّم

وعلى المستوى العام، فالـ RAG هو "استرجاع + تزويد بالسياق + توليد".

قد تبحث طبقة الاسترجاع في فهرس ثابت أو قاعدة بيانات حيّة أو حتى الويب. يعثر التطبيق على المادة ذات الصلة ويضعها في الـ context window، فيقرؤها النموذج كأي نصّ آخر؛ أمّا النموذج الأساسي فلا ينفّذ ذلك الاسترجاع بنفسه.

إليك شكل الـ context window فعلاً بعد الاسترجاع؛ لاحظ أنّ المستندات المسترجَعة ليست إلا نصّاً إضافياً بجانب بقية المحتوى:

تشبيه اختبار الكتاب المفتوح

تخيّل الـ RAG مثل اختبار بكتاب مفتوح.

الطالب (الـ LLM) لا يحفظ كل كتاب دراسي. بل قبل كل سؤال، تناوله أكثر الصفحات صلةً بالموضوع. فيقرأ المادة المُقدَّمة ويصوغ منها إجابة.

الطالب لم "يعرف" الإجابة، بل قرأها من المادة التي أعطيته إياها. فإن أعطيته الصفحات الخطأ، أعطاك إجابةً خاطئة. وإن أعطيته صفحات فيها معلومات مضلِّلة، اتّبع التضليل.

لكن كيف تبحث؟

حسناً، يحتاج الـ RAG إذن إلى العثور على المستندات الصحيحة. لكن كيف؟ لديك آلاف الصفحات. يسأل مستخدم "How do I get my money back?"، فكيف تعثر على الـ chunk ذي الصلة؟

مطابقة الكلمات المفتاحية وحدها كثيراً ما تُفوّت المطلوب. فقد تنصّ سياسة الاسترداد على "reimbursement procedure" أو "return process"، ولا تطابق أيٌّ من هذه الكلمات عبارة "get my money back". فإن اكتفيت بالبحث عن الكلمات المفتاحية بضغط Ctrl+F، فستفوتك.

هنا يأتي دور الـ embeddings.

الـ embedding يحوّل النص إلى قائمة من الأرقام، ويجعل التمثيلُ المتعلَّم النصوصَ المتقاربة دلالياً متجاورةً في كثير من الأحيان. إنه إشارة مفيدة للتشابه، لا تمثيلاً مثالياً لـ "المعنى".

وهكذا يعمل النظام:

1. تُقسَّم كل مستنداتك إلى chunks صغيرة (فقرات، أقسام، وما إلى ذلك)
2. يُحوَّل كل chunk إلى embedding: بصمة رقمية لمعناه
3. حين يطرح المستخدم سؤالاً، يُحوَّل ذلك السؤال إلى embedding أيضاً
4. يعثر النظام على الـ chunks التي تكون الـ embeddings الخاصة بها الأقرب إلى الـ embedding السؤال

عبارة "How do I get my money back?" و chunk عنوانه "Reimbursement Procedures" لهما embeddings متقاربة، لأنهما يدوران حول الأمر نفسه. فيعثر عليه البحث، رغم أنهما لا يشتركان في كلمة واحدة.

ما لا يفعله الـ RAG

مفاهيم خاطئة شائعة:

• الـ RAG لا يمنح النموذج وصولاً إلى الإنترنت بذاته. قد تستخدم طبقة الاسترجاع مستندات مخزّنة أو مصادر حيّة، لكن النموذج لا يقرأ إلا المادة التي تزوّده بها تلك الطبقة.
• الـ RAG لا يجعل النموذج أذكى. إنه يمنحه سياقاً أوثق صلة، لكن النموذج قد يسيء التفسير أو يقع في الـ hallucination رغم ذلك.
• الـ RAG لا يضمن الدقّة. فإن عثر الـ retriever على الـ chunks الخطأ، فقد يجيب النموذج إجابة غير صحيحة، وأحياناً بثقة لا تستند إلى دليل.

يتيح الـ RAG للنماذج قراءة البيانات الخارجية. لكن ماذا لو أردت أن يتّخذ النموذج إجراءات: أن يرسل بريداً إلكترونياً، أو يبحث عن رحلة طيران، أو يستعلم من قاعدة بيانات في الوقت الفعلي؟ هنا يأتي دور الـ tools and function calling، وهنا تحديداً تبدأ معالجة النصّ تُحدث عواقب ملموسة في العالم الحقيقي.

المصادر

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: البحث التأسيسي للـ RAG
• Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection: مخاطر التعليمات المزروعة داخل المحتوى المسترجَع