مستوى المقال: محترف

لو فاتورة Qdrant + Cohere reranker + embeddings بقت $1,124 شهرياً على نظام RAG عربي بـ 6,400 مستند، انت غالباً بتدفع تمن بنية مبالغ فيها. الـ 1M token context في Claude Sonnet 4.6 و Gemini 2.5 Pro غيّر معادلة القرار، و 60% من أنظمة RAG الإنتاجية اللي شفتها في 2026 ممكن تتشال وتتحوّل لـ Long Context بتوفير 50%+ من الفاتورة.

RAG ولا Long Context: قرار معماري بيقلب اقتصاد نظامك

المشكلة باختصار

في 2023 لما الـ context window كان 8K token، RAG كان الحل الوحيد لأي شركة عندها أكتر من 50 مستند. في مايو 2026، الـ 1M token context بقى متاح في Claude Sonnet 4.6، Gemini 2.5 Pro، و GPT-5 long context tier، وده غيّر القرار بالكامل.

المشكلة دلوقتي: فرق هندسية كتيرة بتبني RAG بدافع inertia ومش لأنها فعلاً محتاجاه. النتيجة: vector DB + embedding pipeline + reranker + chunking strategy + evaluation harness لـ workload ممكن يخلص في system prompt واحد بـ 400K token مع prompt caching.

مثال للمبتدئ: مكتبة شخصية مقابل مكتبة الجامعة

تخيل عندك 200 كتاب في بيتك. لما تدور على معلومة، انت بتعرف الكتب وفي راسك أماكنها التقريبية. بتفتح 3 أو 4 كتب بسرعة وتلاقي اللي عايزه. ده Long Context: كل المعرفة قدامك دفعة واحدة، والـ "بحث" بيحصل جوا دماغك.

لو عندك 50,000 كتاب في مكتبة جامعة كاملة، مينفعش تفتح كل كتاب. لازم نظام فهرسة (Dewey Decimal)، رف محدد لكل كتاب، وموظف فهرسة بيرشدك. ده RAG: عندك مخزن خارجي وآلية retrieval، النموذج بيشوف بس النتائج اللي اترجعت.

السؤال الحقيقي مش "RAG ولا Long Context"، السؤال هو: قد إيه حجم الـ corpus بتاعك بالـ tokens، وقد إيه تردد التحديث، وقد إيه نسبة الـ queries اللي بتحتاج cross-document reasoning؟

التعريف العلمي بالظبط

RAG (Retrieval-Augmented Generation) من ورقة Lewis et al. 2020 هو نمط معماري بيقسّم الاستدلال على مرحلتين: (1) retriever بيجيب top-k passages من مخزن خارجي بناءً على similarity score بين embedding السؤال و embeddings المستندات، (2) generator بياخد الـ passages كـ context ويولّد إجابة.

Long Context هو ببساطة إن النموذج بياخد كل الـ corpus (أو جزء كبير منه) كـ input مباشر في الـ context window، بدون retrieval خارجي. الـ "retrieval" هنا بيحصل ضمن الـ attention mechanism بتاع النموذج نفسه عبر الـ tokens المرفوعة.

الافتراض المخفي في RAG: الـ relevant context أصغر بكثير من الـ corpus الكامل (عادةً < 1%). لما الافتراض ده يتكسر — corpus صغير، أو queries محتاجة 20%+ من الـ corpus لإجابة دقيقة — RAG بيبقى مجرد overhead بدون فايدة.

أرقام مقاسة على workload عربي حقيقي

قسته على نظام دعم فني لشركة Fintech عربية في فبراير 2026. الـ corpus: 6,400 مستند سياسات وإجراءات (متوسط 1,200 token لكل مستند = 7.68M token إجمالاً). 3,200 سؤال شهرياً من 14,000 عميل نشط.

• RAG (Qdrant managed + Cohere embed-multilingual-v3 + rerank-3): دقة 79.4% (مُقاسة على 400 سؤال مُقيّم بشرياً)، latency P95 = 1,840ms، تكلفة شهرية $1,124 (Qdrant $340 + embeddings $180 + reranker $284 + LLM $320).
• Long Context (Claude Sonnet 4.6 + system prompt = 280 مستند الأكثر تكراراً = 336K token مع prompt caching): دقة 91.2%، latency P95 = 2,100ms، تكلفة شهرية $487.
• Hybrid (RAG للـ corpus الكامل + top documents داخل Long Context): دقة 93.8%، latency P95 = 2,400ms، تكلفة شهرية $1,890.

القرار: Long Context وفّر $637 شهرياً (56.7%) مع زيادة دقة 11.8 نقطة. لكن لاحظ إن ده شغّال هنا لأن الـ corpus 7.68M token مع pattern تكرار واضح في الـ queries (80% من الأسئلة بتمسّ نفس 280 مستند).

مثال كود يقارن الاتنين

import anthropic
import time

client = anthropic.Anthropic()

# نسخة Long Context مع Prompt Caching
def answer_with_long_context(question: str, full_corpus: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": full_corpus,  # 336K token من 280 مستند
                "cache_control": {"type": "ephemeral"},
            }
        ],
        messages=[{"role": "user", "content": question}],
    )
    return response.content[0].text

# نسخة RAG (مبسّطة)
def answer_with_rag(question: str, qdrant, embedder) -> str:
    query_vec = embedder.embed(question)
    hits = qdrant.search(
        collection_name="docs",
        query_vector=query_vec,
        limit=5,
    )
    context = "\n\n".join(h.payload["text"] for h in hits)
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        messages=[
            {
                "role": "user",
                "content": f"السياق:\n{context}\n\nالسؤال: {question}",
            }
        ],
    )
    return response.content[0].text

المفاجأة الاقتصادية: مع prompt caching، استدعاء Long Context الواحد بيدفع 10% بس من تكلفة الـ 336K token على cache hit. يعني $0.101 بدل $1.01 لكل query بعد أول warmup. ده الرقم اللي بيقلب المعادلة لصالح Long Context في معظم الحالات.

متى Long Context يفوز بالظبط

1. Corpus < 800K token: يكفي يدخل في context window مع هامش للسؤال والإجابة.
2. تردد تحديث منخفض: أقل من 5 تحديثات يومياً علشان الـ cache hit rate يفضل أعلى من 70%.
3. Queries بتحتاج cross-document reasoning: RAG بيكسر السياق بين المستندات لما يرجع 5 passages من 5 مستندات مختلفة. Long Context بيشوفهم كوحدة واحدة.
4. الفريق صغير ومش عايز يدفع cost of ownership لـ retrieval infrastructure: vector DB + embedding service + reranker = 3 dependencies على الأقل.

متى RAG لسه الخيار الصح

1. Corpus > 2M token: Long Context بيبقى مكلف جداً حتى مع caching، لأن أول request بعد أي تحديث بيدفع full price على الـ corpus كامل.
2. Real-time updates: لو الـ docs بتتغير كل ساعة، الـ cache hit rate بينزل تحت 30% والاقتصاد بيقلب لصالح RAG.
3. Strict citation requirements: RAG بيدّيك source attribution واضح (المستند رقم كذا، الفقرة كذا). Long Context بيخلط المصادر داخلياً ومحتاج post-processing علشان تطلع citations.
4. Multi-tenant SaaS: كل tenant عنده corpus مختلف. مينفعش تعمل shared cache، وبتدفع full price لكل tenant.

الـ trade-offs الخفية اللي محدش بيقولها

Latency: Long Context P95 بيكون أعلى من RAG بـ 200-600ms في معظم الحالات حتى مع caching، لأن الـ KV cache reads لسه بياخدوا وقت linear مع حجم الـ context. لو SLO بتاعك < 1.5s، RAG بيفوز.

Cost predictability: RAG تكلفته شبه ثابتة شهرياً (المتغير الرئيسي = عدد الـ queries). Long Context تكلفته بتتقلب بحدة مع كل تحديث في الـ corpus، لأن أول request بعد أي edit بيدفع full price.

Debugging: RAG أسهل بكثير في الـ debug — بتشوف بالظبط أنهي passages اترجعت من الـ retriever. Long Context محتاج تفتح الـ tokens المرجعة كاملة وتدور يدوياً، وده cognitive overhead.

Vendor lock-in: Long Context بيربطك بـ موديل محدد (Claude أو Gemini). RAG محايد ومنفصل عن الـ LLM layer، وممكن تبدّل النموذج بدون لمس الـ retrieval pipeline.

متى لا تستخدم Long Context

متستخدمهوش لو الـ corpus بتاعك > 800K token وفي تحديثات يومية متكررة. الـ cache hit rate هينزل تحت 40%، وهتدفع تمن الـ corpus كامل في كل request جديد. في الحالة دي، RAG بـ Qdrant + Cohere reranker بيوفّر 65-80% من الفاتورة مقابل تعقيد معماري محتمل.

برضو متستخدمهوش لو فريقك محتاج fine-grained access control على مستوى المستند الواحد لكل user. Long Context بيرفع كل المستندات لكل request، وده ممكن يكون مشكلة compliance خصوصاً في القطاع المالي (PCI-DSS) والصحي (HIPAA) وأي workload فيه data residency requirements.

الخطوة التالية

قبل أي قرار، قِس حاجتين بس في نظامك الحالي: إجمالي حجم الـ corpus بالـ tokens، ومعدّل التحديث اليومي. لو الـ corpus < 800K token والتحديث < 3 مرات يومياً، اعمل proof-of-concept بـ Claude Sonnet 4.6 مع prompt caching على 100 سؤال من traffic الإنتاج. لو الدقة طلعت أعلى من RAG الحالي بـ 5 نقاط أو أكتر مع تكلفة أقل، انت عندك قرار اقتصادي واضح: شيل الـ retrieval layer وحوّل لـ Long Context.

المصادر

• Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020 (arxiv.org/abs/2005.11401)
• Anthropic, "Prompt caching with Claude" — التوثيق الرسمي على docs.anthropic.com
• Google DeepMind, "Gemini 2.5 Pro Technical Report" — long context benchmarks 2026
• Cohere, "rerank-3-multilingual evaluation on Arabic", 2025
• Qdrant Cloud pricing — cloud.qdrant.io/pricing (مايو 2026)
• Anthropic SDK Python reference v0.49 — github.com/anthropics/anthropic-sdk-python