نوافذ السياق وصلت الآن إلى مليون وحدة نصية (token)، أي ما يعادل بضعة آلاف من الصفحات تقريباً، وهذا يكفي لوضع دليل شركة كامل، أو عقود سنة كاملة، أو قاعدة أكواد متوسطة الحجم في طلب واحد. لذلك يتكرر في 2026 سؤال منطقي: هل ما زلت تحتاج RAG (التوليد المعزّز بالاسترجاع)، بكل ما فيه من تقطيع للمستندات وتضمينات وقواعد بيانات متجهية؟ أم تستطيع ببساطة وضع كل شيء في الطلب؟
الإجابة الصادقة هي "يعتمد"، لكنه يعتمد على أشياء تستطيع قياسها: حجم قاعدة معرفتك، وكم مرة تتغير، وكم سؤالاً تطرح في الدقيقة، وكم يكلّفك الجواب الخاطئ. يشرح هذا الدليل ما تقوله الأبحاث عن السياقات الطويلة، وأين يبقى الاسترجاع متفوقاً، وحسبة التكلفة مع التخزين المؤقت للطلبات، ومثالاً مُختبراً بلغة Python يُظهر فشلاً في الاسترجاع وكيف يحله إصلاح بسيط.
الطريقتان، كل واحدة في فقرة
السياق الطويل يعني إرسال المادة كاملة مع كل سؤال. النموذج يرى كل شيء، فلا يضيع شيء بسبب استرجاع سيئ. لكنك تدفع مقابل كل وحدة نصية ترسلها، وقد تنخفض الجودة كلما كبر حجم المدخلات.
RAG يعني تقسيم مستنداتك إلى مقاطع وفهرستها، ثم عند السؤال ترسل فقط المقاطع القليلة الأرجح أن تحتوي الإجابة. التكلفة منخفضة لكل سؤال، ويناسب أي حجم، لكن إذا اختار نظام الاسترجاع المقاطع الخاطئة، فلن يرى النموذج الإجابة أبداً.
ماذا تقول الأبحاث عن المدخلات الطويلة جداً؟
النافذة الأكبر لا تعني الاستخدام الموثوق لها. ثلاث نتائج تستحق المعرفة:
- الضياع في المنتصف. وجد Liu وزملاؤه (من ستانفورد وشركائها، في دراسة نُشرت في مجلة TACL) أن النماذج تستخدم المعلومة أفضل ما يكون حين تكون في بداية المدخلات أو نهايتها، وأن الأداء ينخفض بوضوح حين تكون الفقرة المهمة في منتصف سياق طويل.
- الطول المُعلن مقابل الطول الفعلي. اختبار RULER من NVIDIA (2024) قيّم عشرة نماذج تدّعي كلها سياقاً من 32 ألف وحدة أو أكثر. أربعة فقط حافظت على أداء مقبول عند 32 ألف وحدة، مع أن كلها تقريباً نجحت في اختبار "الإبرة في كومة القش" البسيط.
- تآكل السياق. دراسة Chroma في يوليو 2025 على 18 نموذجاً، منها GPT-4.1 وClaude 4 وGemini 2.5، وجدت أن الأداء يصبح أقل موثوقية كلما زاد طول المدخلات، حتى في المهام البسيطة. والمادة غير المتعلقة بالسؤال أضرّت بالنتائج: أداء النماذج كان أفضل بوضوح مع مقتطف مركّز منه مع سجل المحادثة الكامل الذي يحتوي الإجابة نفسها.
النماذج الأحدث تتعامل مع المدخلات الطويلة أفضل من تلك التي شملتها الدراسات، والشركات تواصل التحسين. لكن الاتجاه ثبت عبر كل جيل اختُبر حتى الآن: كلما زاد النص غير المهم، قلّت موثوقية الإجابات. السياق الطويل قدرة تُستخدم بوعي، لا سبب للتوقف عن اختيار ما يدخل في الطلب بعناية.
ماذا تقول الأبحاث عن RAG مقابل السياق الطويل؟
دراسة في 2024 لباحثين من Google DeepMind وجامعة ميشيغان (Li وزملاؤه، "Retrieval Augmented Generation or Long-Context LLMs?") قارنت بين الطريقتين مباشرة. حين توفرت للنماذج موارد كافية، تفوّق السياق الطويل على RAG في متوسط جودة الإجابات. لكن RAG كان أرخص بكثير. والطريقة الهجينة التي اقترحوها، Self-Route، تجعل النموذج يحاول أولاً بالمقاطع المسترجعة ويقرر إن كان يستطيع الإجابة، ولا تذهب إلى السياق الطويل الكامل إلا الأسئلة التي لم يستطع الإجابة عنها. وهكذا بقيت الجودة قريبة من السياق الطويل بتكلفة أقل بكثير.
الدرس العملي: هذه ليست منافسة بفائز واحد. أفضل الأنظمة في 2026 تجمع بين الطريقتين.
أخطاء الاسترجاع قابلة للإصلاح: المقاطع ذات السياق
الضعف الكلاسيكي في RAG هو المقاطع التي تفقد معناها حين تُقتطع من المستند. مقطع يقول "The limit is 30 days from the purchase date" لا يذكر الاسترداد، فقد لا يجده سؤال عن الاسترداد. تناول مقال Anthropic عن "Contextual Retrieval" (سبتمبر 2024) هذه المشكلة تحديداً، بإضافة وصف قصير خاص بالمستند إلى كل مقطع قبل فهرسته. وفي اختباراتهم، مقاسةً بنسبة الأسئلة التي لم يكن المقطع الصحيح فيها ضمن أول 20 نتيجة:
- التضمينات ذات السياق وحدها خفّضت أخطاء الاسترجاع بنسبة 35% (من 5.7% إلى 3.7%).
- وإضافة BM25 ذي السياق (البحث بالكلمات) خفّضتها بنسبة 49% (إلى 2.9%).
- وإضافة خطوة إعادة الترتيب (reranking) خفّضتها بنسبة 67% (إلى 1.9%).
ويعطي المقال نفسه قاعدة عملية مفيدة: إذا كانت قاعدة معرفتك أقل من نحو 200 ألف وحدة نصية (قرابة 500 صفحة)، فغالباً تستطيع الاستغناء عن RAG تماماً، ووضعها كاملة في الطلب، واستخدام التخزين المؤقت للطلبات لإبقاء التكلفة منخفضة.
مثال مُختبر: فشل واحد، وإصلاح واحد، وحسبة التكلفة
السكربت التالي لا يحتاج أي مكتبات ولا مفتاح API. يقوم بثلاثة أشياء: يشغّل بحثاً صغيراً بالكلمات (BM25) على مستندين لسياستين، مرة بدون عنوان سياقي لكل مقطع ومرة معه؛ ويقارن تكلفة السؤال الواحد بين السياق الطويل (مع التخزين المؤقت) وRAG؛ ويطبّق قاعدة توجيه بسيطة. الأسعار توضيحية (3 دولارات لكل مليون وحدة إدخال، مع معاملات التخزين المؤقت المنشورة من Anthropic: 1.25 ضعفاً لكتابة ذاكرة مؤقتة لمدة 5 دقائق، و0.1 للقراءة منها في أغلب النماذج). ضع مكانها الأسعار الحقيقية لنموذجك.
"""RAG vs long context: a small, dependency-free demo.
1) BM25 retrieval over chunks, with and without a contextual header.
2) Cost per query: long context (with prompt caching) vs RAG.
3) A simple router that picks a strategy.
"""
import math, re
from collections import Counter
# --- 1. Toy knowledge base: two policy documents split into chunks ---------
DOCS = {
"Refund policy": [
"Customers can request their money back for annual plans.",
"The limit is 30 days from the purchase date.",
"After that, credit is offered instead of cash.",
],
"Shipping policy": [
"Orders inside the UAE arrive in 2 to 4 working days.",
"The limit is 5 kg per parcel for standard delivery.",
"Express delivery is available in Dubai and Abu Dhabi.",
],
}
def tokenize(text):
return re.findall(r"[a-z0-9]+", text.lower())
class BM25:
def __init__(self, docs, k1=1.5, b=0.75):
self.docs = [tokenize(d) for d in docs]
self.n = len(self.docs)
self.avgdl = sum(map(len, self.docs)) / self.n
self.df = Counter(t for d in self.docs for t in set(d))
self.k1, self.b = k1, b
def score(self, query, i):
d, tf, s = self.docs[i], Counter(self.docs[i]), 0.0
for t in tokenize(query):
if t not in tf:
continue
idf = math.log(1 + (self.n - self.df[t] + 0.5) / (self.df[t] + 0.5))
s += idf * tf[t] * (self.k1 + 1) / (tf[t] + self.k1 * (1 - self.b + self.b * len(d) / self.avgdl))
return s
def top(self, query, k=1):
return sorted(range(self.n), key=lambda i: -self.score(query, i))[:k]
plain, contextual = [], []
for title, chunks in DOCS.items():
for c in chunks:
plain.append(c)
contextual.append(f"[{title}] {c}") # contextual header prepended
query = "What is the time limit for a refund?"
for name, chunks in (("plain chunks", plain), ("contextual chunks", contextual)):
idx = BM25(chunks).top(query, k=1)[0]
print(f"{name:18} -> {chunks[idx]}")
# --- 2. Cost per query (illustrative prices, USD per million input tokens) --
PRICE = 3.00 # base input price, illustrative
WRITE_5M = 1.25 # 5-minute cache write multiplier
READ = 0.10 # cache read multiplier
def lc_cost(corpus_tokens, queries_per_window):
"""Whole corpus in the prompt, cached: one write, then reads."""
write = corpus_tokens * PRICE * WRITE_5M
reads = corpus_tokens * PRICE * READ * (queries_per_window - 1)
return (write + reads) / queries_per_window / 1e6
def rag_cost(chunk_tokens=500, k=8):
"""Only the top-k retrieved chunks go into the prompt."""
return chunk_tokens * k * PRICE / 1e6
print()
print(f"{'corpus':>10} {'queries/5min':>13} {'long ctx $/q':>13} {'RAG $/q':>9}")
for corpus in (50_000, 150_000, 800_000):
for q in (1, 20):
print(f"{corpus:>10,} {q:>13} {lc_cost(corpus, q):>13.4f} {rag_cost():>9.4f}")
# --- 3. A simple router ------------------------------------------------------
def choose(corpus_tokens, fits_window=1_000_000, changes_daily=False):
if corpus_tokens > fits_window:
return "RAG (corpus does not fit)"
if corpus_tokens <= 200_000 and not changes_daily:
return "long context + prompt caching"
return "RAG, or hybrid: retrieve, then send whole matching documents"
print()
for c, ch in ((80_000, False), (150_000, True), (600_000, False), (5_000_000, False)):
print(f"{c:>9,} tokens, changes daily={ch!s:5} -> {choose(c, changes_daily=ch)}")النتيجة، عند التشغيل بتاريخ 2026-10-07:
plain chunks -> The limit is 5 kg per parcel for standard delivery.
contextual chunks -> [Refund policy] The limit is 30 days from the purchase date.
corpus queries/5min long ctx $/q RAG $/q
50,000 1 0.1875 0.0120
50,000 20 0.0236 0.0120
150,000 1 0.5625 0.0120
150,000 20 0.0709 0.0120
800,000 1 3.0000 0.0120
800,000 20 0.3780 0.0120
80,000 tokens, changes daily=False -> long context + prompt caching
150,000 tokens, changes daily=True -> RAG, or hybrid: retrieve, then send whole matching documents
600,000 tokens, changes daily=False -> RAG, or hybrid: retrieve, then send whole matching documents
5,000,000 tokens, changes daily=False -> RAG (corpus does not fit)ثلاثة أمور تستحق الانتباه:
- فشل الاسترجاع حقيقي وصامت. عند السؤال عن المدة المسموحة للاسترداد، أعادت المقاطع العادية حد الوزن في سياسة الشحن، أي إجابة خاطئة واثقة تنتظر أن تحدث. إضافة عنوان المستند لكل مقطع أصلحت ذلك، دون أي تغيير في النموذج.
- التخزين المؤقت يغيّر حسبة السياق الطويل، لكن مع وجود طلبات متكررة فقط. مجموعة من 150 ألف وحدة نصية تكلّف نحو 0.56 دولار للسؤال إذا سألت مرة واحدة، ونحو 0.07 دولار إذا تشاركت 20 سؤالاً نافذة التخزين نفسها. والذاكرة المؤقتة تدوم دقائق فقط، لذلك يهم أن تكون الطلبات منتظمة.
- يبقى RAG الأرخص لكل سؤال (نحو 0.012 دولار لثمانية مقاطع من 500 وحدة هنا)، وهو الخيار الوحيد حين تصبح المادة أكبر من النافذة.
تكلفة المخرجات واحدة في الحالتين ولم تُحتسب هنا. (للصورة الكاملة عن فواتير الوكلاء، راجع كيف تخفّض تكلفة وكلاء الذكاء الاصطناعي.)
متى تستخدم كل طريقة؟
استخدم السياق الطويل (مع التخزين المؤقت) حين:
- تكون المادة صغيرة إلى متوسطة، تقريباً أقل من 200 ألف وحدة نصية.
- نادراً ما تتغير، فيبقى الجزء المخزّن مؤقتاً صالحاً.
- تحتاج الأسئلة ربطاً عبر المستند كله: "ما الذي تغيّر بين هذين العقدين؟"، "لخّص كل المخاطر المذكورة في أي مكان".
- يكون الخطأ مكلفاً، وتفضّل أن تدفع أكثر لكل سؤال على أن تفوتك فقرة.
استخدم RAG حين:
- تكون قاعدة المعرفة كبيرة، أو تكبر باستمرار، أو أكبر من أي نافذة سياق.
- يتغير المحتوى كثيراً (كتالوج منتجات، تذاكر دعم، أسعار).
- تتعامل مع أسئلة كثيرة في الدقيقة وتهمك تكلفة السؤال الواحد.
- لا يحق لكل المستخدمين رؤية كل المستندات. الاسترجاع يسمح بالتصفية حسب الصلاحيات قبل أن يصل أي شيء إلى النموذج، وهذا أكثر أماناً بكثير من إرسال كل شيء والأمل في ألا يذكره النموذج.
- تحتاج إلى عرض المصادر. المقاطع المسترجعة تجعل الاستشهاد طبيعياً.
استخدم الطريقة الهجينة حين تريد الاثنين: استرجع لتجد المستندات الصحيحة، ثم أرسل تلك المستندات كاملة بدل مقاطع صغيرة. وهذا غالباً أفضل خيار افتراضي لقواعد معرفة الشركات، لأنه يحتفظ بتكلفة الاسترجاع المنخفضة والتحكم بالصلاحيات، ويعطي النموذج سياقاً كافياً للتفكير.
ست قواعد صالحة في الحالتين
- ضع السؤال بعد المادة، وضع أهم المستندات قرب البداية أو النهاية، لا في المنتصف.
- اطلب من النموذج اقتباس الفقرة التي اعتمد عليها قبل الإجابة. هذا سهل التحقق، ويقلل الإجابات المختلقة.
- اجمع بين البحث بالكلمات والبحث الدلالي. رموز المنتجات والأسماء والأرقام تُوجد غالباً بالكلمات لا بالتضمينات.
- أضف سياقاً للمقاطع: على الأقل عنوان المستند وعنوان القسم، كما يُظهر المثال.
- خزّن المحتوى الثابت مؤقتاً، وضع كل ما يتغير (التواريخ، وبيانات المستخدم) في نهاية الطلب، بعد الجزء المخزّن.
- قِس الاسترجاع منفصلاً عن الإجابات. جهّز مجموعة اختبار صغيرة من أسئلة حقيقية مع الفقرة التي تجيب عن كل منها، وتحقق كم مرة تُسترجع الفقرة الصحيحة. (دليلنا عن اختبار وكلاء الذكاء الاصطناعي يشرح الطريقة.)
ملاحظة عن المحتوى العربي
البحث بالكلمات في العربية أصعب منه في الإنجليزية: البادئات مثل "ال" و"و"، والضمائر المتصلة، والكتابات المختلفة للكلمة نفسها (أ/ا/إ، ة/ه، ى/ي)، كلها تقلل التطابق. إذا كانت مستنداتك بالعربية، فوحّد الحروف قبل الفهرسة، واستخدم نموذج تضمين مُختبراً على العربية، وأضف المصطلحات التقنية بالعربية والإنجليزية معاً. ثم اختبر بأسئلة حقيقية من مستخدميك، وباللهجة التي يكتبون بها فعلاً. (المزيد في دليلنا للذكاء الاصطناعي بالعربية.)
الخلاصة
نوافذ المليون وحدة لم تُنهِ RAG، بل غيّرت مكان الخط الفاصل. لبضع مئات من الصفحات التي نادراً ما تتغير، ضع كل شيء في الطلب وخزّنه مؤقتاً. ولأي شيء أكبر، أو أسرع تغيراً، أو حساس للصلاحيات، أو كثير الطلبات، استرجع أولاً ثم أعطِ النموذج المستندات المهمة كاملة. وفي الحالتين، قِس: فشل الاسترجاع يبدو تماماً مثل إجابة واثقة حتى تتحقق منه.
المصادر: Liu وآخرون، "Lost in the Middle: How Language Models Use Long Contexts"، مجلة Transactions of the ACL (2024)؛ Hsieh وآخرون، "RULER: What's the Real Context Size of Your Long-Context Language Models?" (NVIDIA، 2024)؛ Chroma، "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (يوليو 2025)؛ Li وآخرون، "Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach"، مسار الصناعة في مؤتمر EMNLP (2024)؛ Anthropic، "Introducing Contextual Retrieval" (سبتمبر 2024)؛ توثيق التخزين المؤقت للطلبات من Anthropic (راجعناه في أكتوبر 2026). المثال يستخدم أسعاراً توضيحية.