لم يعد «التوليد المعزز بالاسترجاع» مجرد موضوع بحثي مثير للفضول منذ سنوات. ففي عام 2026، أصبح هذا هو الأسلوب الافتراضي لتزويد نموذج اللغة الكبير (LLM) بوثائقك الخاصة دون الحاجة إلى دفع تكاليف لضبط النموذج أو المخاطرة بأن يبتكر النموذج إجابات من تلقاء نفسه. هذا النمط سهل الوصف، لكنه مليء بالتحديات عند التنفيذ: ابحث عن النص المناسب، وقدمه للنموذج، ودع النموذج يكتب الإجابة.
هذا دليل إنشاء، وليس دراسة استقصائية. وبنهاية هذا الدليل، ستعرف بالضبط المكونات التي يحتاجها مسار RAG فعال في عام 2026، والأدوات وإصدارات النماذج المحددة التي يجب عليك استخدامها، بالإضافة إلى مخطط برمجي بسيط يمكنك تشغيله محليًّا أو عبر واجهة برمجة تطبيقات (API). لقد تحققنا من صحة كل رقم إصدار وسعر ومعيار أداء مذكور أدناه مقارنةً بالمصادر الحالية — لأن أسوأ خطأ في RAG هو ذلك الذي تنسخه من منشور مدونة كُتب لمكتبات العام الماضي.
أبرز الاستنتاجات
- ست مراحل، بالترتيب: التقسيم، التضمين، التخزين، الاسترجاع، إعادة الترتيب، التوليد. إذا تخطيت مرحلة إعادة الترتيب، فستكون نتائجك الأولى أسوأ بشكل ملحوظ؛ أما إذا تخطيت مرحلة التقييم، فلن تدرك ذلك أبدًا.
- التقسيم الممل هو الأفضل. تفوق التقسيم التكراري عند حوالي 512 توكن مع تداخل يتراوح بين 10 و201 TP3T على تقنية التجميع الدلالي المتطورة (بدقة 691 TP3T مقابل 541 TP3T) في اختبار أداء عام 2026. ابدأ من هناك.
- التضمينات: nomic-embed-text (768 بُعدًا، مجاني، محلي) للنماذج الأولية؛ OpenAI text-embedding-3-large ($0.13/1 مليون رمز، 3072 بُعدًا) أو Voyage-3.5 للحصول على جودة عالية على نطاق واسع.
- قاعدة بيانات Vector: pgvector إذا كنت تستخدم Postgres بالفعل؛ Qdrant الإصدار 1.18 (Apache 2.0، Rust) عندما تحتاج إلى بحث سريع مع تصفية؛ Chroma للعمل المحلي السريع.
- الأطر: LangChain 1.x (بيئة تشغيل LangGraph) للتدفقات القائمة على الوكلاء، وLlamaIndex 0.14.x للتطبيقات التي تعتمد بشكل كبير على عمليات الاسترجاع — ويمكنك تشغيل مسار معالجة مفيد في حوالي 40 سطرًا دون الحاجة إلى أي منهما.
- أضف أداة إعادة ترتيب. يُحسّن كل من Cohere Rerank 3.5 ($2 لكل 1,000 عملية بحث) أو أداة BGE-reranker-v2-m3 مفتوحة المصدر (مجانية، تستغرق حوالي 50–100 مللي ثانية على وحدة معالجة الرسومات) من دقة ترتيب النتائج الأكثر صلة (top-k) بتكلفة منخفضة.
كيف يعمل مسار RAG فعليًّا
يتألف نظام RAG من مرحلتين. الفهرسة يحدث ذلك مرة واحدة (أو كلما طرأت تغييرات على مستنداتك): تقوم بتقسيم الملفات المصدرية إلى أجزاء، وتحويل كل جزء إلى متجه باستخدام نموذج التضمين، ثم تخزين تلك المتجهات في قاعدة بيانات. الاستعلام يحدث هذا في كل طلب: تقوم بتضمين سؤال المستخدم، وتحديد المقاطع الأكثر تشابهاً، وإعادة ترتيبها (اختياريًّا)، ولصق أفضلها في موجه، ثم استدعاء نموذج اللغة الكبير (LLM).
هذه هي الفكرة برمتها. تكمن الهندسة في التفاصيل — حجم القطعة، ونموذج التضمين، وعدد النتائج المطلوب استرجاعها، وما إذا كان يجب إعادة الترتيب، وكيفية قياس مدى فعالية أي من هذه العناصر. إذا كنت ترغب في الاطلاع على الخلفية النظرية قبل البدء في البناء، فإن شرح RAG تتناول المقالة السابقة الجانب النظري؛ أما هذه المقالة فتتناول عملية التوصيل. وإذا كنت لا تزال مترددًا بين استخدام RAG وتخصيص النموذج نفسه، فإن مقارنة بين «الضبط الدقيق» و«RAG» وهو المكان المناسب للبدء — بالنسبة لمعظم الفرق التي تزود نماذج اللغة الكبيرة (LLM) ببيانات خاصة ومتغيرة، يُعد RAG الحل الأقل تكلفة والأسهل في الصيانة.
الخطوة 1: قسّم مستنداتك إلى أجزاء
تواجه نماذج التضمين قيودًا تتعلق بسياق النص، والأهم من ذلك أنها تفقد دقتها عند معالجة المقاطع الطويلة. ولذلك، يتم تقسيم المستندات إلى أجزاء. إن الإجماع الذي تم التوصل إليه في عام 2026، المدعوم بمعايير قياسية وليس مجرد انطباعات، يفتقر إلى البريق: استخدم أداة تقسيم الأحرف التكرارية التي تستهدف تقريبًا 512 رمزًا مع تداخل يتراوح بين 10 و20% (50–100 توكن).
أظهر تقييم أُجري في فبراير 2026 على 50 وثيقة حقيقية أن التقسيم التكراري البسيط عند 512 رمزًا حقق دقة استرجاع بلغت 69%، في حين أن التقسيم الدلالي — الذي يحاول التقسيم بناءً على الحدود الدلالية — حقق دقة لم تتجاوز 54%. والسبب بسيط: أنتج التقسيم الدلالي أجزاء يبلغ متوسط حجمها 43 وحدة، وهي أصغر من أن توفر للنموذج سياقًا كافيًا للإجابة. وفي الوقت نفسه، وجدت دراسة منفصلة أجريت في يناير 2026 باستخدام استرجاع SPLADE أن التداخل أضاف تكلفة فهرسة دون فائدة قابلة للقياس على مجموعة البيانات الخاصة بها. النتيجة الصريحة: ابدأ بمجموعات متكررة ذات حجم ثابت، ولا تلجأ إلى التقسيم الدلالي أو على مستوى الصفحة إلا إذا أثبتت مقاييس التقييم الخاصة بك أنك بحاجة إلى ذلك في مستنداتك المحددة.
الخطوة 2: اختيار نموذج التضمين
هذا هو القرار الأكثر أهمية في خط أنابيب الغاز، والفارق بين الخيارات واضح. وفيما يلي الخيارات التي تستحق الدراسة في منتصف عام 2026، مع الأرقام المؤكدة.
| النموذج | الأبعاد | السياق | السعر / مليون توكن | ملاحظات |
|---|---|---|---|---|
| nomic-embed-text الإصدار 1.5 | 768 (MRL 64–768) | 8,192 | مجاني (محلي) | 274 ميغابايت؛ الاختيار المحلي الافتراضي |
| mxbai-embed-large | 1024 | 512 | مجاني (محلي) | 670 ميغابايت؛ جودة أعلى، سياق موجز |
| BGE-M3 | 1024 + متفرق | 8,192 | مجاني (محلي) | رخصة MIT، أكثر من 100 لغة |
| OpenAI text-embedding-3-small | 1536 | 8,191 | $0.02 | خط أساس API منخفض التكلفة |
| OpenAI text-embedding-3-large | 3072 | 8,191 | $0.13 | $0.065 عبر واجهة برمجة تطبيقات المعالجة المجمعة (Batch API) |
| Voyage-3.5 | 2048 (MRL 256–2048) | 32,000 | $0.06 | يتفوق على 3-large بنحو 8% في عملية الاسترجاع |
| تضمين Gemini | 3072 | — | واجهة برمجة التطبيقات (API) | أعلى النتائج في MTEB v2 (~68.3) |
بالنسبة للنموذج الأولي، ابدأ محليًّا باستخدام nomic-embed-text — إنه سريع ومجاني، ويمكن تخزينه على كمبيوتر محمول بسعة 16 جيجابايت، ويُقال إنه يتفوق على النسخة الأقدم من OpenAI text-embedding-ada-002. أما على صعيد الإنتاج، فقد لحق مجال البرمجيات مفتوحة المصدر بالركب حقًّا: يُعد BGE-M3، المرخص بموجب ترخيص MIT، الحصان الرابح الذي تعتمد عليه معظم حزم البرمجيات المُستضافة ذاتيًا بشكل افتراضي، في حين يتصدر كل من Voyage-3.5 وGemini Embedding اختبارات الأداء الخاصة بواجهات برمجة التطبيقات (API) المُدارة. القاعدة الوحيدة التي تهم هي: مهما كان النموذج الذي تستخدمه لتضمين مستنداتك، يجب عليك تضمين استعلاماتك باستخدام النموذج نفسه. إن دمج النماذج يؤدي إلى تدمير عملية الاسترجاع دون أن يلاحظ أحد.
الخطوة 3: تخزين المتجهات في قاعدة بيانات المتجهات
بمجرد الحصول على التضمينات، يجب تخزينها في مكان يدعم البحث السريع عن أقرب الجيران. وستتوفر لديك ثلاث مستويات معقولة في عام 2026.
اختر هذه المنتجات
- pgvector 0.8 إذا كنت تستخدم Postgres بالفعل. فباستخدام فهرس HNSW، يوفر هذا النظام زمن انتقال p95 يتراوح بين رقم واحد إلى رقمين من الميلي ثانية عند معالجة مليون متجه. وقد أضاف الإصدار 0.8 عمليات المسح التكرارية بحيث تعرض الاستعلامات المُصفاة عددًا كافيًا من النتائج. ولا يتطلب ذلك أي بنية تحتية جديدة.
- Qdrant الإصدار 1.18 (Apache 2.0، Rust) عندما يكون التصفية أمرًا مهمًا. تعالج خوارزمية ACORN الخاصة به (التي أُضيفت في الإصدار 1.16) المشكلة الكلاسيكية المتمثلة في أن “التصفية تقلل من معدل الاسترجاع” من خلال توسيع نطاق البحث HNSW في ظل مرشحات تقييدية، وتُعد من أقوى الخيارات المتاحة للبحث المُصفى. يكفي أمر Docker واحد للاستضافة الذاتية.
- Chroma لإنشاء النماذج الأولية المحلية. أفضل تجربة للمطورين، ووضع التشغيل المدمج، وبدون عمليات — حل مثالي إلى أن تتجاوز قدراته.
انتبه إلى
- تُحسب تكلفة الخدمات المُدارة حسب الاستخدام، وهذا ما يفاجئ الكثيرين: عند 100 مليون متجه، يمكن لـ Pinecone تشغيل $5,000+ شهريًّا، مقارنةً بـ Qdrant أو pgvector المُستضافين ذاتيًّا على أجهزتك الافتراضية الخاصة، واللذين يعتبران أرخص بكثير. قم بإجراء تدقيق قبل التوسع.
- تستغرق عمليات إنشاء مؤشر HNSW وقتًا طويلاً عند العمل على نطاق واسع، ويمكن أن يصل حجم المؤشر إلى حوالي 8 جيجابايت لمليون متجه بـ 1536 بُعدًا (استخدم halfvec لتقليل هذا الحجم إلى النصف تقريبًا).
- تؤثر أجهزة التخزين بشكل كبير على معدل الإنتاجية: حقق نفس إعداد pgvector حوالي 410 QPS على محركات أقراص SSD السحابية مقابل 2,150 QPS على محركات أقراص NVMe.
يوجد تحليل أكثر تفصيلاً في موقعنا دليل قاعدة بيانات المتجهات, ، لكن بالنسبة لمعظم الفرق، فإن خيارات الاختيار محدودة: إذا كنت تستخدم Postgres بالفعل → pgvector؛ إذا كنت بحاجة إلى تصفية مكثفة أو مليارات المتجهات → Qdrant أو Milvus؛ إذا كنت في مرحلة التجريب فقط → Chroma.
الخطوة 4: استرجاع النتائج وإعادة ترتيبها
تتم عملية الاسترجاع في استدعاء واحد: يتم تضمين الاستعلام، ثم يُطلب من قاعدة البيانات تقديم أقرب k مقاطع (عادةً ما تكون k في نطاق 20–50). لكن تشابه المتجهات الخام أداة غير دقيقة. أ إعادة الترتيب — وهو مشفر متقاطع يقوم بتقييم كل زوج من الاستعلام والوثيقة على حدة — يعيد ترتيب تلك النتائج المرشحة ويبرز النتائج ذات الصلة الحقيقية قبل وصولها إلى النموذج.
النمط القياسي: استرجاع أفضل 50 نتيجة باستخدام مشفر ثنائي الاتجاه، ثم إعادة الترتيب، والاحتفاظ بأفضل 5–10 نتائج. تكلفة Cohere Rerank 3.5 هي $0.002 لكل عملية بحث ($2 لكل 1,000 عملية) وتضيف عادةً زمن انتقال يتراوح بين 100 و300 مللي ثانية. إذا كان لديك وحدة معالجة رسومات (GPU) وترغب في تكلفة صفرية لكل استعلام، فإن البرنامج مفتوح المصدر BGE-reranker-v2-m3 يستغرق التنفيذ حوالي 50–100 مللي ثانية ويدعم المحتوى متعدد اللغات. يُعد إعادة الترتيب أحد التحسينات التي تحقق أقصى فائدة بأقل جهد ممكن — فمعظم مسارات المعالجة التي “تستخرج بيانات غير مفيدة” تغفل هذه الخطوة.
الخطوة 5: توسيع نطاق المطالبة وإنشاء النص
الآن قم بتجميع الموجه: تعليمات قصيرة للنظام تطلب من النموذج أن يجيب فقط استنادًا إلى السياق المقدم، والمقاطع المعاد ترتيبها، وسؤال المستخدم. ثم قم باستدعاء نموذج اللغة الكبير (LLM) الخاص بك.
بالنسبة لنموذج الإنشاء، يمكنك الاختيار بين الطريقة المحلية أو واجهة برمجة التطبيقات (API). محليًّا عبر Ollama, the 2026 sweet spot is an 8B-class model — Qwen3 8B أو لَامَا 3.1 بسعة 8 مليارات معلّمة at Q4_K_M quantization — which fits in 8–12GB of VRAM and runs at 40+ tokens/second on a modern GPU. Qwen3 14B (~8–9GB at Q4) is a strong step up with a 128K context window for stuffing in more retrieved text. For a hosted, higher-ceiling option, a frontier API model works well; our دليل استخدام روبوت الدردشة Claude API يسير عبر هذا المسار من البداية إلى النهاية. تذكير مفيد من الممارسين: بالنسبة لـ RAG، عادةً ما تكون جودة الاسترجاع أكثر أهمية من حجم النموذج — فالأجزاء النظيفة، مقترنةً بمُدمج جيد ونموذج لغوي كبير الحجم (LLM) صغير، تتفوق على نموذج ضخم يُغذى بسياق رديء.
الخطوة 6: مخطط برمجي بسيط
فيما يلي نموذج كامل لخط أنابيب محلي يستخدم LangChain 1.x وChroma وOllama. يقوم هذا النموذج بفهرسة مستند والإجابة على سؤال — دون الحاجة إلى مفاتيح API.
# pip install langchain langchain-community langchain-chroma langchain-ollama
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_chroma import Chroma
# 1. Load + chunk (~512 tokens, ~15% overlap; sizes are in characters)
docs = TextLoader("handbook.txt").load()
chunks = RecursiveCharacterTextSplitter(
chunk_size=2000, chunk_overlap=300
).split_documents(docs)
# 2. Embed + 3. Store
embeddings = OllamaEmbeddings(model="nomic-embed-text")
store = Chroma.from_documents(chunks, embeddings)
# 4. Retrieve (top 4)
retriever = store.as_retriever(search_kwargs={"k": 4})
# 5. Augment + generate
llm = ChatOllama(model="qwen3:8b")
question = "What is the refund window?"
context = "nn".join(d.page_content for d in retriever.invoke(question))
prompt = (f"Answer using ONLY the context. If it's not there, say so.nn"
f"Context:n{context}nnQuestion: {question}")
print(llm.invoke(prompt).content)
هذه هي الحلقة بأكملها. لإضافة إعادة الترتيب، أدخل مسترد الضغط السياقي مع استخدام مشفر متقاطع بين الخطوتين 4 و5. مع LlamaIndex 0.14.x، عادةً ما يتطلب نفس التدفق كودًا أقل بفضل تجريدات الاسترجاع المصممة خصيصًا لهذا الغرض — وهو الخيار الأفضل للتطبيقات التي تعتمد بشكل كبير على الاسترجاع، بينما يتألق وقت تشغيل LangGraph من LangChain عندما تحتاج إلى وكلاء متعددي الخطوات يحفظون الحالة. (يُعد اختيار طبقة التنسيق موضوعًا بحد ذاته؛ انظر مقارنة بين أطر عمل الوكلاء المعتمدين على الذكاء الاصطناعي.)
الخطوة 7: التقييم — لا تتخطى هذه الخطوة
الفرق بين النسخة التجريبية والمنتج الحقيقي يكمن في القياس. والأداة القياسية هي RAGAS, ، والذي يقيّم مدى الدقة في التعبير (هل التزمت الإجابة بالسياق؟)، ودقة السياق، واسترجاع السياق باستخدام نموذج لغوي كبير (LLM) كمعيار تقييم. قم بإنشاء مجموعة صغيرة تتألف من 20 إلى 50 زوجًا من الأسئلة والأجوبة مستمدة من مستنداتك الفعلية، وقم بتشغيل البرنامج عليها بعد كل تغيير.
وهذه هي الطريقة التي تتيح لك أيضًا اتخاذ كل قرار سابق بأمانة. هل يجب عليك التحول إلى التجميع الدلالي؟ أم إضافة أداة إعادة الترتيب؟ أم رفع قيمة k من 4 إلى 8؟ لا تعتمد على التخمين — قم بتغيير متغير واحد، وأعد تشغيل RAGAS، واحتفظ بالتغيير فقط إذا تحسنت النتائج. فبدون هذه الحلقة، فإنك تقوم بالضبط بشكل عشوائي.
الأسئلة الشائعة
كم تبلغ تكلفة تشغيل خط أنابيب RAG؟
تكلفة إنشاء النموذج الأولي شبه مجانية. باستخدام تقنيات التضمين المحلية من Ollama وChroma، و نموذج لغوي كبير محلي, ، فإن التكلفة الوحيدة التي تتحملها هي تكلفة الكهرباء. وعلى نطاق واسع، تتمثل الفواتير الرئيسية في قاعدة بيانات المتجهات (تعد مثيل Qdrant أو pgvector المُستضاف ذاتيًا على جهازك الافتراضي الخاص أرخص بكثير من العروض المُدارة، التي قد تتجاوز تكلفتها $5,000 شهريًّا عند معالجة 100M متجه)، وإذا كنت تستخدم واجهات برمجة التطبيقات (APIs)، فإن تكلفة التضمينات (تبلغ تكلفة OpenAI text-embedding-3-large $0.13 لكل مليون رمز) بالإضافة إلى مكالمات التوليد.
هل أحتاج إلى قاعدة بيانات متجهة، أم يمكنني استخدام قاعدة بيانات عادية؟
أنت بحاجة إلى البحث المتجهي، ولكن ليس بالضرورة إلى منتج مخصص لهذا الغرض. يضيف pgvector هذه الميزة إلى PostgreSQL ويتعامل مع مليون متجه بزمن انتقال منخفض عند مستوى p95 (بضعة مللي ثانية على NVMe، وأعلى من ذلك على SSD السحابي)، لذا إذا كنت تستخدم Postgres بالفعل، فيمكنك تجنب إنشاء بنية تحتية جديدة تمامًا. استخدم قاعدة بيانات مخصصة مثل Qdrant عندما تحتاج إلى تصفية مكثفة للبيانات الوصفية أو معالجة مليارات المتجهات.
ما هو حجم القطعة الذي ينبغي أن أستخدمه؟
ابدأ بحوالي 512 رمزًا مع تداخل يتراوح بين 10 و20% باستخدام أداة تقسيم متكررة. أظهر اختبار أداء أجري عام 2026 أن هذه الطريقة تفوقت على التجزئة الدلالية بنسبة 69% مقابل 54% من حيث دقة الاسترجاع. لا تنتقل إلى طرق التجزئة الأكثر تعقيدًا إلا إذا أظهرت مقاييس التقييم الخاصة بك أنها مفيدة في المستندات المحددة الخاصة بك.
هل هناك حاجة فعلاً إلى أداة إعادة ترتيب؟
ليس بهدف جعل شيء ما يعمل، بل لأنها واحدة من أرخص طرق تحسين الجودة المتاحة. استرجع مجموعة واسعة (أفضل 50)، وأعد ترتيبها باستخدام Cohere Rerank 3.5 أو أداة BGE-reranker-v2-m3 مفتوحة المصدر، واحتفظ بأفضل 5 إلى 10 منها. معظم مسارات المعالجة التي تبرز أجزاء غير ذات صلة تفتقد ببساطة إلى هذه الخطوة.
هل يمكنني إنشاء RAG بدون LangChain أو LlamaIndex؟
نعم. تتكون الحلقة الأساسية — التضمين، والبحث، والمطالبة، والتوليد — من حوالي 40 سطرًا من لغة بايثون العادية التي تستدعي نموذج التضمين الخاص بك، وعميل قاعدة بيانات المتجهات، ونموذج اللغة الكبير (LLM) مباشرةً. توفر الأطر (Frameworks) الوقت في عمليات التحميل وإعادة الترتيب والتنسيق التفاعلي، لكنها اختيارية، كما أن البناء من الصفر يمنحك التحكم الكامل في كل خطوة.
هل يجب أن أستخدم نموذجًا محليًّا أم واجهة برمجة تطبيقات (API) للتوليد؟
يُعد الاستخدام المحلي (عبر Ollama، باستخدام طراز 8B مزود بذاكرة VRAM سعة 8–12 جيجابايت) خيارًا رائعًا للخصوصية والتحكم في التكاليف والاستخدام دون اتصال بالإنترنت. تتيح لك واجهة برمجة التطبيقات (API) الحصول على جودة أعلى دون أي عمليات. تقوم العديد من الفرق بإنشاء نماذج أولية محليًّا لإجراء عمليات التكرار بتكلفة منخفضة، ثم تختار طريقة النشر بناءً على حساسية البيانات والميزانية.
كيف يمكنني الحفاظ على تحديث الفهرس مع تغير المستندات؟
أعد تضمين المحتوى وقم بـ«upsert» (الإدراج أو التحديث) فقط لما تغير، بدلاً من إعادة بناء كل شيء. قم بتتبع هاش المحتوى أو تاريخ التعديل لكل مستند مصدر، وعند التحديث، احذف الأجزاء القديمة الخاصة بذلك المستند وأدرج الأجزاء الجديدة. تدعم معظم قواعد البيانات المتجهة عمليات «upsert» والحذف باستخدام تصفية البيانات الوصفية، مما يجعل التحديثات التراكمية عملية بسيطة ومباشرة.
الخلاصة
يُعد بناء مسار RAG في عام 2026 أمرًا سهلًا حقًّا: ست مراحل، وعدد قليل من الأدوات الناضجة، وحوالي 40 سطرًا من التعليمات البرمجية لإنشاء نموذج أولي فعال. ولا تكمن العقبات في البنية — بل في الإعدادات الافتراضية. استخدم مقاطع مملة مكونة من 512 رمزًا، وقم بمطابقة الاستعلام ومُدمجي المستندات، وأضف أداة إعادة الترتيب، ولا تقم أبدًا بالضبط دون إشراك RAGAS في العملية. ابدأ محليًا ومجانًا باستخدام nomic-embed-text وChroma ونموذج Ollama سعة 8B؛ وقم بترقية المكونات الفردية إلى pgvector أو Qdrant أو Voyage أو واجهة برمجة تطبيقات (API) متطورة فقط عندما تشير أرقام التقييم الخاصة بك — وليس منشورًا على مدونة — إلى ذلك. احرص على إجراء عملية الاسترجاع بشكل صحيح، وسوف يوصلك النموذج الصغير إلى أبعد مما تتخيل.
