شرح RAG بالتفصيل: ازاي تخلي ال LLM ترد من الداتا بتاعتك

حابب ان انا اتكلم شويه عن ال RAG بالتفصيل لانها من اهم التقنيات الي لازم تكون فاهمها لو بتبني System بيعتمد علي ال LLMs وعايزه يرد من الداتا بتاعتك انت مش من المعلومات الي اتدرب عليها بس

ال RAG هي اختصار ل Retrieval-Augmented Generation وفكرتها ببساطه اننا قبل منطلب من ال LLM تجاوب علي سؤال اليوزر بنروح ندور الاول فمصادر الداتا بتاعتنا علي المعلومات المرتبطه بالسؤال وبعد كده نحط المعلومات دي جوه ال Prompt ونبعتها لل LLM عشان تعتمد عليها وهي بتطلع الاجابه

يعني بدل متقول لل LLM جاوبني من المعلومات الي جواك انت بتقولها دور فالداتا بتاعتي وهات الاجزاء المهمه منها وبعدين استخدمها وانت بتجاوب

طيب احنا محتاجين RAG ليه اصلا ؟

ال LLM مهما كانت قويه فهي عندها شويه مشاكل لازم تكون واخد بالك منها:

• ممكن المعلومات الي اتدربت عليها تكون قديمه ومش متحدثه
• مش هتكون عارفه الداتا الداخليه بتاعت الشركه او المشروع بتاعك
• ممكن تجاوب بثقه علي حاجه غلط وده الي بنسميه Hallucination
• ممكن تكون المعلومه موجوده عندها ولكن مش بالشكل والتفاصيل الي انت محتاجها
• تدريب الموديل من جديد عشان تضيف معلومات جديده مكلف ومش عملي مع الداتا الي بتتغير باستمرار
• انت ساعات بتكون محتاج تعرف الاجابه دي جت من انهي مصدر عشان تقدر تراجعها وتثق فيها

فال RAG بتساعدنا نجيب المعلومات المناسبه من مصادر احنا عارفينها ونحطها قدام ال LLM وقت الاجابه بدل منسيبها تعتمد علي ذاكرتها بس

ال RAG بيشتغل ازاي ؟

ال RAG System غالبا بيتقسم لمرحلتين اساسيتين:

1. مرحلة تجهيز وتخزين الداتا ودي بنسميها Indexing
2. مرحلة استقبال سؤال اليوزر والبحث والاجابه ودي بنسميها Retrieval and Generation

المرحله الاولي: تجهيز وتخزين الداتا

جمع الداتا من المصادر

اول حاجه بتحدد مصادر الداتا الي ال LLM المفروض تعتمد عليها والمصادر دي ممكن تكون:

• ملفات PDF
• صفحات من ال Website
• مقالات
• Documentation
• Notion
• Google Drive
• Database
• Tickets بتاعت ال Support
• Emails
• API
• ملفات Word او Text
• محادثات قديمه

وهنا مهم جدا تفهم ان جودة ال RAG كلها بتبدا من جودة الداتا لان لو الداتا غلط او قديمه او متكرره فال System هيجيب معلومات غلط مهما كان ال LLM قوي

تنظيف الداتا

بعد متجمع الداتا لازم تنظفها قبل متخزنها يعني مثلا:

• تشيل الاجزاء المكرره
• تشيل ال Headers وال Footers الي ملهاش لازمه
• تتاكد ان النص طالع من ال PDF بطريقه صح
• تحافظ علي العناوين وترتيب المحتوي
• تشيل الصفحات الفاضيه
• تصلح المشاكل الناتجه عن استخراج النص
• تحدد انهي نسخه هي الاحدث لو عندك اكتر من نسخه من نفس الملف

وعلي فكره دي من اكتر المراحل الي ناس كتير بتستهين بيها وبعد كده يفتكروا ان المشكله فال LLM او ال Vector Database وهي بتكون اصلا فالداتا الي دخلت

تقسيم الداتا باستخدام Chunking

احنا مش بناخد الملف كله ونخزنه كقطعه واحده لان لو الملف كبير واليوزر بيسال عن معلومه صغيره جواه مش هنكون محتاجين نبعت كل الملف لل LLM

عشان كده بنقسم المحتوي لاجزاء صغيره بنسمي كل جزء منها Chunk

مثلا لو عندك Documentation كبير ممكن تقسمه حسب:

• العناوين
• الفقرات
• عدد معين من الكلمات او ال Tokens
• الاقسام المنطقيه
• الصفحات
• نوع المحتوي

ولكن ال Chunking مش مجرد انك تقطع النص كل 500 Token وخلاص لان ممكن تقطع جمله من النص او تفصل الشرح عن العنوان بتاعه وساعتها ال Chunk هيفقد جزء من معناه

لازم التقسيم يحافظ علي المعني والسياق بتاع الكلام

طيب ال Chunk Size يكون قد ايه ؟

مفيش رقم واحد مناسب لكل المشاريع لان الموضوع بيعتمد علي:

• نوع الداتا
• طول الاجابات المطلوبه
• طبيعة اسئلة اليوزر
• حجم ال Context Window
• موديل ال Embedding
• طريقة ال Retrieval
• التكلفه وال Latency

ال Chunk الصغير ممكن يكون دقيق فال Search ولكن ميكونش فيه Context كفايه عشان ال LLM تفهم المعلومه

وال Chunk الكبير ممكن يحتوي علي Context اكتر ولكن يدخل معاه كلام مش مرتبط بالسؤال ويقلل دقة ال Retrieval ويستهلك Tokens اكتر

عشان كده لازم تجرب اكتر من Chunk Size وتقيس النتيجه علي اسئلة حقيقيه من اليوزر

استخدام Chunk Overlap

ممكن وانت بتقسم الداتا تخلي فيه جزء بسيط مشترك بين كل Chunk وال Chunk الي بعده وده بنسميه Chunk Overlap

الفكره هنا ان لو معلومه موجوده علي الحدود بين اتنين Chunks متتقطعش ويتفقد معناها

ولكن لو زودت ال Overlap بشكل كبير هتخزن داتا مكرره وهتزود التكلفه وممكن ترجع نفس المعلومه اكتر من مره فالنتيجه

إضافة ال Metadata

كل Chunk لازم يكون معاه معلومات توصفه ودي بنسميها Metadata زي مثلا:

• اسم الملف
• عنوان الصفحه
• اسم الكاتب
• تاريخ النشر
• تاريخ اخر تحديث
• القسم
• اللغه
• نوع المحتوي
• رابط المصدر
• رقم الصفحه
• صلاحيات الوصول
• اسم العميل او الشركه

ال Metadata مهمه جدا لانك ممكن تستخدمها بعد كده فالفلتره

يعني لو اليوزر بيسال عن سياسة الشركه لسنة معينه انت مش عايز تدور فكل الملفات انت ممكن تحدد السنة ونوع الملف الاول وبعد كده تعمل Search جوه النتائج دي

تحويل النص الي Embeddings

بعد منقسم الداتا ل Chunks بناخد كل Chunk ونبعته لموديل اسمه Embedding Model

ال Embedding Model بيحول النص لمجموعه ارقام بتمثل معني النص ودي بنسميها Vector

الفكره ان النصوص الي معناها قريب من بعض غالبا ال Vectors بتاعتها بتكون قريبه من بعض حتي لو مش بيستخدموا نفس الكلمات بالظبط

مثلا اليوزر ممكن يسال:

ازاي ارجع المنتج ؟

وال Documentation مكتوب فيها:

سياسة استرداد الطلبات

رغم ان الكلمات مش هي هي ولكن المعني قريب وال Semantic Search يقدر يساعدنا نوصل للمعلومه المناسبه

تخزين ال Embeddings في Vector Database

بعد منعمل Embedding لكل Chunk بنخزن ال Vector مع النص الاصلي وال Metadata جوه Vector Database

ال Vector Database معموله عشان تقدر تدور بسرعه علي ال Vectors الاقرب لل Vector بتاع سؤال اليوزر

ومن الامثله علي الحلول الي ممكن تستخدمها:

• Pinecone
• Weaviate
• Qdrant
• Milvus
• Chroma
• pgvector

واختيار ال Vector Database مش هو اول حاجه المفروض تشغل بالك بيها لان جودة الداتا وال Chunking وال Retrieval غالبا تاثيرهم اكبر من مجرد اختيار اسم Database مختلف

المرحله التانيه: استقبال السؤال والاجابه عليه

استقبال سؤال اليوزر

لما اليوزر يبعت السؤال مش شرط ان السؤال يكون واضح او كامل

ممكن اليوزر يقول:

طب ارجعه ازاي ؟

وهنا السؤال لوحده مفيهوش Context كفايه ومحتاج تعرف هو بيتكلم عن اي من المحادثه الي قبل كده

عشان كده ساعات بنحتاج نعمل Query Rewriting يعني نخلي ال System يعيد كتابة سؤال اليوزر بشكل واضح ومستقل مع الحفاظ علي قصده

مثلا السؤال يتحول الي:

ازاي اقدر ارجع المنتج الي طلبته من المتجر ؟

تحويل السؤال الي Embedding

بعد منجهز السؤال بنبعته لنفس نوع ال Embedding Model الي استخدمناه مع الداتا عشان يتحول هو كمان ل Vector

بعد كده بنقارن ال Vector بتاع السؤال بال Vectors المتخزنه ونجيب اقرب Chunks ليه

النتائج دي بنسميها Retrieved Documents او Retrieved Chunks

ال Similarity Search

ال Vector Database بتحاول تعرف انهي Chunks اقرب فالمعني لسؤال اليوزر وبتدي لكل نتيجه Score

ولكن خد بالك ان اعلي Score مش معناه ديما ان ال Chunk فعلا فيه الاجابه الصح لان التشابه فالمعني مش هو نفسه الاجابه علي السؤال

ممكن Chunk يكون بيتكلم عن نفس الموضوع ولكنه مفيهوش المعلومه المطلوبه

تحديد عدد النتائج باستخدام Top K

ال Top K هو عدد ال Chunks الي هنرجعها من عملية البحث

لو خليت الرقم قليل ممكن المعلومه المهمه متوصلش لل LLM

ولو خليته كبير ممكن تدخل كلام كتير مش مرتبط بالسؤال وتشتت ال LLM وتزود ال Tokens وال Latency والتكلفه

فلازم تجرب قيمة ال Top K وتقيس هل ال Chunks المطلوبه فعلا بتظهر فالنتائج ولا لا

ال Hybrid Search

مش كل الاسئله ال Semantic Search بيكون هو الاحسن فيها

مثلا لو اليوزر بيدور علي:

• كود منتج
• رقم فاتوره
• اسم Function
• Error Message
• مصطلح تقني محدد

هنا البحث بالكلمات ممكن يكون مهم جدا

عشان كده ممكن نستخدم Hybrid Search الي بيجمع بين:

• Semantic Search باستخدام ال Embeddings
• Keyword Search باستخدام الكلمات الموجوده فعلا فالنص

وبعد كده ندمج النتايج عشان نستفيد من الطريقتين

استخدام Filters قبل ال Retrieval

ممكن نستخدم ال Metadata عشان نحدد نطاق البحث قبل منعمل Similarity Search

مثلا:

• دور فالملفات المنشوره بعد تاريخ معين
• دور فمستندات قسم ال HR بس
• دور فالملفات العربي بس
• دور فالداتا الخاصه بالعميل الحالي
• دور فاخر Version من ال Documentation

الفلتره بتقلل مساحة البحث وبتساعدنا نجيب نتائج ادق ولكن لازم تتاكد ان الفلتر مش ضيق لدرجة انه يمنع المعلومه الصح من الظهور

ال Reranking

بعد منرجع مجموعه من ال Chunks ممكن نستخدم موديل تاني يعملهم Reranking

ال Retriever بيجيب عدد من النتائج المحتمل تكون مرتبطه بالسؤال وبعد كده ال Reranker يبص علي السؤال وكل Chunk بشكل ادق ويرتبهم حسب انهي واحد فعلا هيساعد فالاجابه

يعني ممكن تجيب مثلا عدد اكبر من النتائج فالمرحله الاولي وبعد ال Reranking تختار احسن عدد صغير منهم وتبعته لل LLM

ال Reranking ممكن يحسن الدقه ولكن هيزود ال Latency والتكلفه فلازم تستخدمه لما يكون فعلا بيضيف قيمه

بناء ال Prompt النهائي

بعد منجيب ال Chunks المناسبه بنحطها جوه ال Prompt مع سؤال اليوزر والتعليمات بتاعتنا

ال Prompt النهائي غالبا بيكون فيه:

• دور ال LLM
• تعليمات واضحه للاجابه
• سؤال اليوزر
• ال Context الي رجع من ال Retrieval
• شكل ال Output المطلوب
• تعليمات التعامل مع المعلومه الناقصه
• طلب ذكر المصادر لو ده مطلوب

مثلا ممكن تقول لل LLM:

جاوب علي سؤال اليوزر باستخدام ال Context الموجود فقط ولو الاجابه مش موجوده بوضوح قول ان المعلومات المتاحه مش كافيه ومتخترعش اجابه

هنا لازم تفرق بين حاجتين مهمين:

1. ان ال Retrieval يجيب المعلومه الصح
2. ان ال LLM تستخدم المعلومه دي بطريقه صح

لان ممكن ال Retriever يجيب ال Chunk الصح ولكن ال Prompt يكون ضعيف وال LLM متستخدمهاش كويس

وممكن ال Prompt يكون ممتاز ولكن ال Retrieval مجابش المعلومه اصلا وساعتها ال LLM مش هتقدر تعمل حاجه

توليد الاجابه باستخدام ال LLM

بعد مبنبني ال Prompt النهائي بنبعته لل LLM عشان تطلع الاجابه

المفروض الاجابه تكون مبنيه علي ال Context الي دخل ليها مش علي معلومات تخمنها من عندها

ولكن وجود RAG مش معناه ان ال Hallucination اختفت نهائي لان ممكن:

• ال Retrieval يرجع معلومات غلط
• الداتا نفسها تكون غلط
• ال Context يكون متناقض
• ال LLM تفهم النص غلط
• السؤال يكون مبهم
• ال Prompt ميبقاش محدد التصرف وقت نقص المعلومات
• الموديل يخلط بين معلوماته الداخليه وال Context

عشان كده لازم تختبر ال System كامل مش مجرد كل جزء لوحده

إضافة المصادر وال Citations

من اهم مميزات ال RAG انك تقدر ترجع مع الاجابه المصادر الي اتبنت عليها

ممكن تعرض لليوزر:

• اسم الملف
• رابط المصدر
• رقم الصفحه
• عنوان القسم
• جزء النص المستخدم

ولكن متفترضش ان اي Citation طلعته ال LLM صحيح لمجرد انه شكله مقنع

الاحسن ان ال System يربط كل Chunk بمصدره بشكل واضح وانت تبني ال Citations من ال Metadata الفعليه بدل متسيب ال LLM تخترع اسم مصدر او رابط

ازاي نقيم جودة ال RAG ؟

مينفعش تقيم ال RAG بانك تجرب سؤالين والنتيجه تعجبك وخلاص

لازم تعمل Dataset فيها اسئلة حقيقيه او متوقعه ومع كل سؤال تحدد:

• ايه الاجابه الصحيحه
• انهي مصدر فيه الاجابه
• انهي Chunks المفروض تظهر
• امتي ال System المفروض يقول مش عارف
• شكل الاجابه المقبول

وبعد كده تقيم كل مرحله لوحدها

تقييم ال Retrieval

هنا انت بتسال:

• هل ال Chunk الي فيها الاجابه ظهرت فالنتائج ؟
• ظهرت فترتيب كام ؟
• هل النتائج مرتبطه بالسؤال ؟
• هل فيه Chunks مهمه مخدتش فرصتها ؟
• هل رجعنا Chunks كتير ملهاش علاقه ؟

لو المعلومه الصحيحه مش موجوده فال Context يبقا المشكله غالبا قبل ال Generation

تقييم ال Generation

هنا انت بتسال:

• هل الاجابه صحيحه ؟
• هل الاجابه معتمده علي ال Context ؟
• هل ال LLM اخترعت معلومات مش موجوده ؟
• هل جاوبت السؤال بشكل كامل ؟
• هل التزمت بشكل ال Output المطلوب ؟
• هل قالت انها مش متاكده لما المعلومات كانت ناقصه ؟
• هل المصادر فعلا بتدعم الاجابه ؟

ال End-to-End Evaluation

هنا بنقيم تجربة اليوزر النهائيه كلها:

• هل ال System فهم السؤال ؟
• هل جاب الداتا الصح ؟
• هل الاجابه كانت واضحه ومفيده ؟
• هل الوقت كان مقبول ؟
• هل التكلفه مناسبه ؟
• هل حافظ علي صلاحيات الداتا ؟
• هل يقدر يتعامل مع الاسئله الغريبه والغير متوقعه ؟

اختبر ال RAG وقت ال Out of Distribution

متختبرش ال System علي الاسئله السهله والمتوقعه بس

لازم تضغط عليه بحالات زي:

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

الاختبارات دي هي الي هتوريك ال System فعلا موثوق ولا هو شغال فالديمو بس

مشاكل شائعه فال RAG

الداتا السيئه

لو الداتا قديمه او غلط او متكرره فال RAG هيرجعها لل LLM والموديل ممكن يبني عليها اجابه غلط

Chunking مش مناسب

ممكن المعلومه تتقطع بين اكتر من Chunk او ال Chunk تكون كبيره وفيها مواضيع كتير ملهاش علاقه ببعض

البحث بيرجع كلام قريب ولكن مش الاجابه

التشابه الدلالي ممكن يجيب موضوع قريب من السؤال ولكن من غير المعلومه المطلوبه وهنا ممكن تحتاج Hybrid Search او Reranking او تحسين ال Query

Context كتير جدا

ناس كتير بتفكر ان كل منحط داتا اكتر لل LLM النتيجه هتكون احسن ولكن الكلام الكتير ممكن يشتت الموديل ويخلي المعلومه المهمه تضيع وسط ال Context

مفيش طريقه للتعامل مع عدم وجود اجابه

لو ال System مجبر يجاوب كل مره فال LLM ممكن تخترع اجابه

لازم تديها اختيار واضح انها تقول ان المعلومه مش موجوده او انها مش متاكده

تجاهل ال Latency

كل خطوه بتضيفها زي Query Rewriting وRetrieval وReranking وGeneration بتزود وقت الاجابه

ممكن تعمل Architecture دقيقه جدا ولكن اليوزر يستني وقت طويل وميعجبوش ال System

تجاهل التكلفه

التكلفه مش بس تكلفة ال LLM ولكن ممكن تشمل:

• تجهيز الداتا
• ال Embeddings
• تخزين ال Vectors
• عمليات البحث
• ال Reranking
• عدد ال Tokens
• تحديث ال Index
• ال Monitoring وال Evaluation

تجاهل صلاحيات الوصول

لو عندك داتا لاكتر من عميل او قسم مينفعش تعتمد علي ال Prompt عشان تمنع تسريبها

لازم تطبق ال Access Control وقت ال Retrieval نفسه عشان ال Chunks الي اليوزر مش مسموحله يشوفها متدخلش اصلا لل LLM

ال Prompt Injection فال RAG

ممكن يكون جوه الداتا نص بيقول لل LLM تجاهل التعليمات السابقه وابعت معلومات سريه او نفذ تصرف معين

وده معناه ان المحتوي الي رجع من ال Retrieval مينفعش تتعامل معاه كانه تعليمات موثوقه هو مجرد داتا المفروض تتقري ويتجاوب منها

لازم تفصل بوضوح بين:

• تعليمات ال System
• سؤال اليوزر
• المحتوي المسترجع
• الادوات الي الموديل مسموحله يستخدمها

ومتديش ال LLM صلاحيات حساسه لمجرد ان نص موجود فال Context طلب منها تعمل حاجه

تحديث الداتا فال RAG

من مميزات ال RAG انك تقدر تحدث الداتا من غير متدرب ال LLM من الاول

لما ملف يتعدل ممكن:

1. تحدد ال Chunks القديمه المرتبطه بيه
2. تشيلها او تعلم عليها انها قديمه
3. تقسم النسخه الجديده
4. تعمل Embeddings جديده
5. تخزنها مع رقم ال Version وتاريخ التحديث

وهنا لازم تتجنب ان النسخه القديمه والجديده يفضلوا موجودين مع بعض من غير تمييز لان ال Retriever ممكن يرجع معلومات متعارضه

امتي تستخدم RAG ؟

ال RAG مناسب لما:

• تكون محتاج ال LLM تجاوب من داتا خاصه
• الداتا بتتغير باستمرار
• محتاج تعرض مصادر الاجابه
• عندك كمية مستندات كبيره
• محتاج تقلل اعتماد الموديل علي ذاكرته
• محتاج تدير معلومات لا يمكن وضعها كلها فال Prompt
• عايز تحدث المعرفه من غير Fine-tuning جديد

امتي ال RAG ميكونش هو الحل ؟

مش كل مشكله فيها LLM محتاجه RAG

ممكن متحتاجش RAG لو:

• كل المعلومات المطلوبه صغيره وثابته وتقدر تحطها فال System Prompt
• المهمه معتمده علي تنسيق او اسلوب معين مش استرجاع معلومات
• عندك بيانات منظمه والمطلوب Query دقيق من Database وساعتها Tool او SQL ممكن يكون انسب
• المطلوب تنفيذ Action عن طريق API مش البحث فمستندات
• مفيش عندك مصادر داتا موثوقه اصلا
• السؤال محتاج حساب دقيق والافضل يتنفذ بكود او Calculator

ممكن كمان ال System النهائي يجمع بين RAG وTools وDatabase وAPIs بدل متحاول تحل كل حاجه بال Vector Search

الفرق بين RAG و Fine-tuning

ناس كتير بتتلخبط بينهم ولكن كل واحد فيهم بيحل مشكله مختلفه

ال RAG غالبا بنستخدمه عشان نوصل ال LLM لمعلومات ومصادر خارجيه وقت السؤال

ال Fine-tuning غالبا بنستخدمه عشان نعدل سلوك الموديل او اسلوبه او نخليه يلتزم بنمط معين بشكل افضل

يعني لو عندك معلومات بتتحدث كل يوم غالبا مش منطقي تعمل Fine-tuning كل يوم ولكن تقدر تحدث ال RAG Index

وفي بعض الحالات ممكن تستخدم الاتنين مع بعض:

• Fine-tuning للسلوك وطريقة الاجابه
• RAG للمعلومات والمصادر المتحدثه

تحسين ال Query

ساعات سؤال اليوزر مش بيكون مناسب للبحث بشكل مباشر وعشان كده ممكن نستخدم تكنيكس زي:

Query Rewriting

نعيد صياغة السؤال بشكل واضح مع الحفاظ علي معناه

Multi-Query Retrieval

نطلع اكتر من صيغه للسؤال وندور بكل صيغه وبعد كده ندمج النتائج

Query Decomposition

لو السؤال مركب من اكتر من جزء نقسمه لاسئله اصغر ونجيب معلومات كل جزء لوحده

HyDE

نخلي ال LLM تكتب اجابه افتراضيه للسؤال ونستخدم تمثيلها فالبحث عشان نلاقي المستندات القريبه منها

ولكن كل تكنيك من دول بيضيف تعقيد وتكلفه وLatency فلازم متستخدمهوش لمجرد انه موجود لازم تقيس هل فعلا حسن النتيجه ولا لا

ال Conversation Memory مع RAG

لو عندك Chat System سؤال اليوزر الحالي ممكن يعتمد علي الكلام الي فات

ولكن متبعتش تاريخ المحادثه كله كل مره بشكل عشوائي لان ده ممكن يزود ال Tokens ويدخل معلومات مش مهمه

ممكن تعمل:

• تلخيص للمحادثه
• الاحتفاظ باخر عدد من الرسائل
• استخراج المعلومات المهمه
• تحويل السؤال الحالي لسؤال مستقل
• تخزين معلومات محدده عن اليوزر بصلاحيات واضحه

ولازم تفرق بين Memory المحادثه وبين مصادر المعرفه لان كل واحد ليه استخدام مختلف

ال RAG المتقدم

مع زيادة تعقيد ال System ممكن تلاقي اشكال متقدمه من ال RAG زي:

Parent-Child Retrieval

تبحث باستخدام Chunks صغيره عشان الدقه ولكن لما تلاقي النتيجه ترجع الجزء الاكبر المرتبط بيها عشان ال Context

Contextual Retrieval

تضيف لكل Chunk وصف صغير يوضح مكانها ومعناها جوه المستند قبل متعملها Embedding

Graph RAG

تستخدم العلاقات بين الكيانات والمعلومات عشان تجاوب علي اسئله محتاجه ربط بين اكتر من جزء

Agentic RAG

ال LLM تقرر هتبحث امتي وفين وهل محتاجه تعيد البحث او تستخدم Tool تاني

ولكن كل مزودنا تعقيد كل مزادت الحاجه لل Monitoring وال Evaluation والتحكم فالتكلفه وال Latency

ازاي تبني RAG System شاطر ؟

• ابدا بحالة استخدام واضحه ومحدده
• اجمع اسئلة حقيقيه من اليوزر
• نظف الداتا واتاكد من صحتها
• جرب اكتر من طريقة Chunking
• حافظ علي ال Metadata
• ابدا ب Retrieval بسيط وقيس النتيجه
• استخدم Hybrid Search لو طبيعة الداتا محتاجه
• ضيف Reranking لو اثبت انه بيحسن الدقه
• خلي ال LLM تقول مش عارف لما المعلومات مش كافيه
• اربط الاجابات بالمصادر الحقيقيه
• اختبر الحالات الغريبه مش الاسئله السهله بس
• راقب ال Latency والتكلفه
• سجل ال Queries والنتائج والمشاكل
• اعمل Versioning لل Prompts وال Index وال Evaluation Dataset
• طبق صلاحيات الوصول قبل متدخل الداتا لل LLM
• حسن جزء واحد كل مره عشان تعرف اي تغيير هو الي فرق

ملاحظه مهمه جدا

خد بالك ان ال RAG مش مجرد Vector Database وPrompt وخلاص

ال RAG هو System كامل فيه Data Pipeline وChunking وEmbeddings وRetrieval وReranking وPrompt Engineering وGeneration وEvaluation وSecurity وMonitoring

واكبر غلطه انك تشوف اجابه شكلها كويس فتفترض ان ال System شغال صح

لازم تعرف الاجابه جت منين وهل المصدر صح وهل ال Retrieval جاب المعلومه المناسبه وهل ال LLM التزمت بيها وهل ال System هيعرف يقول مش متاكد لما ميلاقيش الاجابه

فالهدف مش ان ال LLM تجاوب علي كل حاجه ولكن الهدف انها تجاوب اجابه موثوقه من المصادر المتاحه ولما المعلومه متكونش موجوده تقول بوضوح انها مش موجوده