أكبر غلط أشوفه بتطبيقات الـ AI إن الناس تتعامل ويا RAG و Long Context كأنهم نفس الشي. يكولون "أنا أستخدم RAG" بس بالحقيقة هم يحشون كل شي بالـ prompt وخلاص. أو بالعكس، يبنون pipeline كامل من embeddings و vector databases بس المشكلة كلها كانت تنحل بسطرين context.
خلني أشرحلك الموضوع من الصفر، بالتفصيل، ويا مصادر.
كل موديل AI — سواء GPT-4، Claude، Gemini، Llama — متدرب على بيانات عامة من الإنترنت. يعرف شكسبير ويعرف Python بس ما يعرف:
فالسؤال مو "هل الموديل ذكي؟" — السؤال هو: شلون تنطيه المعلومات اللي يحتاجها قبل ما يجاوب؟
وهنا يجي الفرق الجوهري بين الأسلوبين.
RAG يعني Retrieval-Augmented Generation — يعني "جيب المعلومة أول، بعدين خلي الموديل يجاوب."
ملفاتك ──▶ تقسيم (Chunking) ──▶ تحويل لـ Embeddings ──▶ تخزين بـ Vector DB
│
سؤالك ──▶ تحويل لـ Embedding ──▶ بحث بالـ Vector DB ──────────┘
│
▼
أقرب المقاطع (Top-K)
│
▼
الموديل يقرأ المقاطع + سؤالك
│
▼
الجواب 💬بشكل أبسط:
Pinecone، Weaviate، ChromaDB، أو حتى pgvector| السيناريو | ليش RAG أحسن؟ |
|---|---|
| أرشيف ضخم (آلاف أو ملايين الملفات) | الموديل ما يكدر يقرأ كلشي — RAG يجيب بس الـ relevant |
| بيانات تتحدث باستمرار | تحدث الـ index بدون ما تعيد كلشي |
| أسئلة محددة (fact-based) | "شنو سياسة الإرجاع؟" — RAG يلكط الجزء المناسب بالضبط |
| كلفة مهمة | تدفع بس على tokens المسترجعة مو كل الملفات |
| تطبيق يخدم مستخدمين كثار | كل سؤال ياخذ بس جزء صغير من الـ tokens |
أولاً — مشكلة الـ Retrieval Failure:
بحث Liu et al. (2023) بورقتهم “Lost in the Middle” أثبت إن حتى الـ LLMs تضعف لمن المعلومة تكون بنص السياق [1]. نفس المبدأ ينطبق على RAG — إذا الـ retriever ما لكط الـ chunk الصحيح، الموديل ما راح يلكاها حتى لو موجودة بملفاتك.
يعني تخيل عندك wiki فيها 10,000 صفحة والجواب موجود بصفحة واحدة. إذا الـ embedding search ما طلعها بالـ top-K results، الموديل راح يجاوب وكأنها مو موجودة. المعلومة موجودة بس ضايعة.
ثانياً — مشكلة الـ Chunking:
شلون تقسم الملفات؟ هاي مو سؤال بسيط. إذا قسمتها وايد صغيرة، تضيع السياق. إذا قسمتها وايد كبيرة، الـ retrieval يصير غير دقيق. وإذا قطعت بنص فقرة مهمة، الموديل ياخذ نص المعلومة ويطلع جواب ناقص.
ثالثاً — مشكلة الـ Semantic Gap:
أحياناً سؤالك والجواب يستخدمون كلمات مختلفة تماماً. مثلاً تسأل "شلون أرجع المنتج؟" بس بالـ documentation مكتوب "سياسة الاسترداد والاستبدال". الـ embedding search ممكن ما يربط بيناتهم لأن الكلمات مختلفة حتى لو المعنى واحد.
الـ RAG الكلاسيكي مو نهاية القصة. صارت أنواع جديدة:
Graph RAG (Microsoft, 2024):
بدل ما تبحث بس عن text chunks، تبني knowledge graph من الملفات — يعني شبكة علاقات بين الكيانات (أشخاص، مفاهيم، أحداث). بحث Edge et al. أثبت إن GraphRAG يتفوق على RAG العادي بالأسئلة الشمولية مثل "شنو أهم المواضيع بالبيانات؟" [2].
RAG العادي: سؤال ──▶ بحث عن chunks ──▶ جواب
Graph RAG: سؤال ──▶ بحث بشبكة العلاقات ──▶ ملخصات المجتمعات ──▶ جواب أشملHybrid RAG:
يجمع بين keyword search (BM25) و semantic search (embeddings) — يعطيك أفضل من العالمين.
Agentic RAG:
الموديل نفسه يقرر متى يستخدم RAG ومتى لا. يعني بدل ما كل سؤال يروح للـ retriever، الـ agent يقيّم أول إذا يحتاج معلومات خارجية أو لا.
Long Context يعني ببساطة: تحط كل البيانات مباشرة بالـ prompt وتخلي الموديل يتعامل وياها.
ملفاتك (كاملة) + سؤالك
│
▼
┌─────────────┐
│ الموديل │
│ يقرأ كلشي │
│ ويجاوب │
└──────┬──────┘
│
▼
الجواب 💬لا chunking، لا embeddings، لا vector database. بس copy-paste وخلاص.
قبل سنتين، أحسن موديل كان ياخذ 4,000 أو 8,000 token فقط. يعني تقريباً 6-12 صفحة. ما كان ممكن تحط أكثر من هيچ.
هسه الوضع تغير بشكل جذري:
| الموديل | حجم الـ Context Window | تقريباً بالصفحات |
|---|---|---|
| GPT-3.5 (2023) | 4K tokens | ~6 صفحات |
| GPT-4 (2023) | 128K tokens | ~200 صفحة |
| Claude 3.5 (2024) | 200K tokens | ~300+ صفحة |
| Gemini 1.5 Pro | 1M tokens | ~1,500 صفحة |
| Gemini 2.0 | 2M tokens | ~3,000 صفحة |
Google تكول إن مليون token يعادل تقريباً [3]:
| السيناريو | ليش Long Context أحسن؟ |
|---|---|
| تحليل عقد قانوني واحد كبير | الموديل يقرأ كلشي ويربط بين البنود |
| مقارنة بين 3-4 مستندات | يشوف الكل ويلكط التناقضات والفجوات |
| كتاب أو manual واحد | يفهم السياق الكامل مو بس قطع منه |
| سؤال يحتاج ربط بين معلومات متفرقة | RAG ممكن يجيب chunk واحد بس، Long Context يشوف الصورة الكاملة |
| Many-shot learning | تنطي الموديل مئات أو آلاف الأمثلة ويتعلم النمط [4] |
أولاً — الكلفة:
كل token تدفع عليه. إذا عندك ملف 100,000 token وسألت 10 أسئلة، دفعت على مليون token input. بالـ RAG، نفس الـ 10 أسئلة ممكن ياخذون بس 50,000 token total لأنك تسترجع بس المقاطع المطلوبة.
ثانياً — مشكلة “Lost in the Middle”:
بحث Nelson Liu et al. بـ Stanford (2023) أثبت نقطة خطيرة: الموديلات تركز على بداية ونهاية السياق وتضعف بالنص [1]. يعني إذا الجواب بصفحة 750 من 1,500 صفحة، احتمال الموديل يتجاوزها.
أداء الموديل حسب موقع المعلومة بالسياق:
██████████ بداية السياق — أداء عالي ✅
████████ قريب من البداية — أداء جيد
████ نص السياق — أداء ضعيف ❌
██████ قريب من النهاية — أداء متوسط
██████████ نهاية السياق — أداء عالي ✅بس لازم انويه — Google تكول إن Gemini يوصل لدقة ~99% بالـ needle-in-a-haystack tests لمن تبحث عن معلومة واحدة [3]. المشكلة تزيد لمن تبحث عن معلومات متعددة بنفس الوقت.
ثالثاً — الـ Latency:
كل ما كبر السياق، كل ما طال وقت الرد. مو بس ثانية أو ثنتين — ممكن يوصل 30-60 ثانية حق سياق مليون token. وهاي مشكلة بالتطبيقات اللي تحتاج رد سريع.
رابعاً — مشكلة الـ Multiple Needles:
Google نفسها تعترف بهاي النقطة [3]: لمن تبحث عن معلومة واحدة (needle واحدة)، الأداء ممتاز. بس لمن تحتاج تلكط 10 أو 100 معلومة مختلفة من نفس السياق الطويل، الأداء يتراجع بشكل ملحوظ وممكن تحتاج ترسل requests متعددة.
بحث Li et al. (2024) من Google (منشور بـ EMNLP 2024) سوى أشمل مقارنة بين RAG و Long Context [5]. هاي أهم النتائج:
“When resourced sufficiently, LC consistently outperforms RAG in terms of average performance. However, RAG’s significantly lower cost remains a distinct advantage.”
يعني: إذا ما يهمك الفلوس وتريد أفضل جواب، Long Context أحسن. بس إذا تريد توازن بين الأداء والكلفة، RAG لسه عنده مكان.
| المعيار | RAG | Long Context |
|---|---|---|
| الدقة (Accuracy) | جيدة — بس تعتمد على جودة الـ retrieval | أعلى بشكل عام لمن السياق كافي |
| الكلفة | أقل بكثير — تدفع بس على الـ chunks المسترجعة | أعلى — تدفع على كل الـ tokens كل مرة |
| التعقيد التقني | عالي — تحتاج embedding model + vector DB + chunking strategy | منخفض — بس حط الملفات وخلاص |
| حجم البيانات | ملايين الملفات عادي | محدود بحجم الـ context window |
| الربط بين المعلومات | ضعيف — كل chunk معزول | قوي — الموديل يشوف كلشي |
| الـ Latency | أسرع — سياق أصغر = رد أسرع | أبطأ — سياق أكبر = وقت أطول |
| الصيانة | تحتاج — index updates, chunk tuning | تقريباً صفر |
| الـ Freshness | تحتاج تحدث الـ index | تحط آخر نسخة مباشرة |
Li et al. ما وقفوا عند المقارنة — اقترحوا حل اسمه Self-Route [5]:
سؤال المستخدم
│
▼
┌─────────────────────┐
│ RAG يجاوب أول │
│ (كلفة أقل) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ الموديل يسأل نفسه: │
│ "هل أنا واثق من │ نعم ──▶ يرجع الجواب ✅
│ الجواب؟" │
└──────────┬──────────┘
│ لا
▼
┌─────────────────────┐
│ يروح لـ Long Context│
│ (كلفة أعلى بس أدق) │
└──────────┬──────────┘
│
▼
جواب أفضل ✅الفكرة بسيطة: خلي RAG يجاوب أول (لأنه أرخص)، إذا الموديل حس إنه مو واثق، يحول السؤال لـ Long Context. بهالطريقة توفر فلوس على الأسئلة السهلة وتضمن دقة على الأسئلة الصعبة.
واحدة من أهم التطورات اللي غيرت المعادلة هي Context Caching. Google قدمتها ويا Gemini [3] والفكرة هي:
بدل ما تدفع على كل الـ tokens كل مرة تسأل سؤال، تخزن السياق مرة واحدة وتدفع رسوم تخزين بالساعة. بعدين كل سؤال يكلفك بس الـ input/output tokens الجديدة بسعر مخفض (~4x أرخص مع Gemini Flash).
بدون Context Caching:
سؤال 1: 💰💰💰💰 (100K tokens input)
سؤال 2: 💰💰💰💰 (100K tokens input)
سؤال 3: 💰💰💰💰 (100K tokens input)
المجموع: 💰💰💰💰💰💰💰💰💰💰💰💰
مع Context Caching:
Cache: 💰💰 (مرة واحدة + رسوم تخزين بسيطة)
سؤال 1: 💰 (بس السؤال الجديد)
سؤال 2: 💰 (بس السؤال الجديد)
سؤال 3: 💰 (بس السؤال الجديد)
المجموع: 💰💰💰💰💰هاي التقنية خلت Long Context ينافس RAG حتى من ناحية الكلفة بسيناريوهات معينة — خصوصاً لمن عندك ملفات ثابتة وأسئلة كثيرة عليها.
بدل ما أكولك "استخدم هذا" مباشرة، خلني أنطيك framework للقرار:
أقل من 200 صفحة ────────▶ Long Context (ممكن حتى بدون RAG)
200 - 1,000 صفحة ────────▶ يعتمد على السيناريو (اقرأ الباقي)
أكثر من 1,000 صفحة ──────▶ RAG (أو Hybrid)
ملايين الملفات ───────────▶ RAG حتماًأسئلة محددة ("شنو سعر المنتج X؟") ──────▶ RAG أكفأ
أسئلة تحتاج ربط ("قارن بين العقدين") ──▶ Long Context أفضل
أسئلة شمولية ("شنو أهم المواضيع؟") ────▶ Graph RAG أو Long Contextميزانية محدودة + أسئلة كثيرة ──────▶ RAG
ميزانية مرنة + أسئلة قليلة ───────▶ Long Context
ميزانية مرنة + أسئلة كثيرة ───────▶ Long Context + Context Cachingخطأ واحد ممكن يكلفك (قانوني، طبي) ──▶ Long Context (يقرأ كلشي)
مقبول نسبة خطأ بسيطة ─────────────▶ RAG كافيمبرمج واحد أو لا ──────────────────▶ Long Context (بساطة)
فريق مع خبرة ML ──────────────────▶ RAG ممكن يعطيك أداء أفضلالحل: RAG
السبب: حجم البيانات أكبر بكثير من أي context window. تبني index وتخلي الموديل يسترجع التذاكر المشابهة لمن يجي سؤال جديد.
الحل: Long Context
السبب: الملف واحد ومحدود الحجم. المحامي يريد الموديل يقرأ كلشي ويفهم العلاقة بين البنود. إذا استخدمت RAG، ممكن البند اللي يحتاجه يضيع وسط الـ chunks.
الحل: Hybrid (Self-Route)
السبب: بعض الأسئلة بسيطة (RAG يكفي)، وبعضها تحتاج فهم شامل (Long Context أفضل). خلي النظام يقرر.
الحل: Long Context + Context Caching
السبب: ما عندك وقت ولا ميزانية تبني RAG pipeline كامل. حط الـ docs بالـ cache واشتغل.
الحل: Agentic RAG
السبب: تحتاج الموديل يقرر وحده وين يبحث ومتى يسترجع ومتى يكتفي بالـ context الموجود.
Google وصلت لـ 2 مليون token، والباقي يلحقون. ممكن بالسنوات الجاية نشوف 10M أو 100M tokens. بهالحالة، وين RAG؟
حتى لو context window صارت بلا سقف، RAG لسه عنده ميزتين ما تروح:
أغلب الأنظمة الجدية بالمستقبل راح تكون hybrid — تستخدم RAG وLong Context سوا حسب الحاجة. نفس فكرة Self-Route [5] بس أكثر تطوراً.
هسه بس Google تقدمه بشكل رسمي. لمن كل الـ providers يقدمونه، المعادلة الاقتصادية حق Long Context تتغير بالكامل.
القرار الهندسي الصح مو يعتمد على الترند ولا على شنو يكولون بالـ Twitter.
يعتمد على ثلاث أشياء:
إذا عندك كتاب، عقد، أو مجموعة صغيرة من المستندات وتريد تحليل عميق ومقارنة مباشرة — ابدأ بـ Long Context.
إذا عندك wiki، tickets، docs، أو أرشيف كبير وتريد بحث سريع واقتصادي — روح باتجاه RAG.
وإذا تريد أفضل النتائج بدون ما تنجنن — جرب الـ Hybrid approach.
القاعدة الذهبية: ابدأ بـ Long Context (لأنه أبسط). إذا ما كفاك حجماً أو كلفةً، انتقل لـ RAG. وإذا تريد الأفضل، اجمعهم.
[1] Liu, N.F., Lin, K., Hewitt, J., et al. (2023). “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics (TACL). arXiv:2307.03172
[2] Edge, D., Trinh, H., Cheng, N., et al. (2024). “From Local to Global: A Graph RAG Approach to Query-Focused Summarization.” arXiv:2404.16130
[3] Google. (2024). “Long Context — Gemini API Documentation.” ai.google.dev/gemini-api/docs/long-context
[4] Agarwal, R., et al. (2024). “Many-Shot In-Context Learning.” arXiv:2404.11018
[5] Li, Z., Li, C., Zhang, M., Mei, Q., Bendersky, M. (2024). “Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.” EMNLP 2024 Industry Track. arXiv:2407.16833