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، وهنا تحديداً تبدأ معالجة النصّ تُحدث عواقب ملموسة في العالم الحقيقي.