جدول المحتويات
- 1. مراجعة: حدود RAG الساذج
- 2. لمحة عن خط أنابيب RAG الحديث
- 3. ① التقطيع إلى أجزاء (chunking) (الأهم)
- 4. ② اختيار نموذج embedding
- 5. ③ اختيار قاعدة بيانات متجهية (مقارنة)
- 6. ④ البحث الهجين (BM25 + المتجه)
- 7. ⑤ إعادة الترتيب (retrieve-then-rerank)
- 8. أطر العمل (LlamaIndex/LangChain)
- 9. RAG مقابل السياق الطويل
- 10. ملاحظات حول الانتقال للإنتاج
- الخلاصة
- الأسئلة الشائعة
أنت تفهم ما هو RAG. لكن عند البناء الفعلي، يصطدم كثيرون بجدار: "يعمل نوعاً ما، لكن الإجابة الجوهرية مختلّة." والسبب يكون دائماً تقريباً نفسه — إنه ما يزال "RAG الساذج": تقطيع المستند باستهتار وإجراء بحث متجهي بسيط.
لقد تجاوز RAG العملي في 2026 ذلك بوضوح. المفاتيح هي خط أنابيب متعدد المراحل: "تقطيع ذكي ← الـ embedding المناسب ← بحث هجين (كلمات مفتاحية + متجه) ← إعادة ترتيب." وبوصف هذا المقال متابعة التنفيذ للمقال 030، فإنه يغطي الكيفية الملموسة لكل مرحلة، واختيار قاعدة البيانات المتجهية (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus)، وأطر العمل، وحتى "هل ما زلنا بحاجة إلى RAG في عصر الـ 1M توكن؟" — أساسيات تنفيذ أكثر تقدّماً.
المراحل الخمس لـ RAG الحديث
— من RAG الساذج إلى RAG يعمل في الإنتاج
أكبر مكسبين للدقة: البحث الهجين (BM25 + المتجه) وإعادة الترتيب.
مجرد إضافة هذين الاثنين يصحّح إلى حد كبير مشكلة "الإجابة مختلّة" في RAG الساذج.
* أسماء الأدوات والطرق وأرقام المقاييس مبنية على مصادر رسمية وعدة منصات تقنية (حتى 2026). يتطور هذا المجال بسرعة وتتغير أفضل الخيارات. أرقام المقاييس منقولة عن مصادرها وتتفاوت بحسب البيانات والظروف. قيّم على بياناتك الخاصة (أدناه) قبل الاختيار.
1. مراجعة: حدود RAG الساذج
إن RAG في حدّه الأدنى هو "تقطيع المستند ← تحويله لمتجهات عبر embeddings ← تخزينه في قاعدة بيانات متجهية ← تحويل السؤال لمتجه وجلب أقرب الأجزاء ← تمريرها إلى الـ LLM للإجابة." هذه هي أساسيات RAG. لكن هذا "RAG الساذج" يعاني من نقاط ضعف نمطية.
- أجزاء غير متقنة: القطع في منتصف الجملة، مما يكسر المعنى.
- البحث المتجهي فقط: ضعيف في المصطلحات الدقيقة مثل أسماء المنتجات أو أرقام الطُرز (يلتقط/يفوّت أشياءً قريبة دلالياً لكنها مختلفة لفظياً).
- تمرير الأعلى N كما هي: تُدفن العناصر الأكثر صلة فعلاً.
إن RAG العملي في 2026 يسحق هذه الثلاثة بـ "التقطيع الذكي" و"البحث الهجين" و"إعادة الترتيب." لنمضِ بالترتيب.
2. لمحة عن خط أنابيب RAG الحديث
يتضمن تدفق بيانات RAG الإنتاجي مسارين: التحضير (الفهرسة) ووقت الاستعلام (البحث والتوليد).
مرحلتان
التحضير (دون اتصال): تقطيع المستند بذكاء ← تحويله لمتجهات عبر embeddings ← تخزينه في قاعدة بيانات متجهية (مع بناء فهرس كلمات مفتاحية في الوقت نفسه).
وقت الاستعلام (متصل): جلب أعلى 50-100 بالبحث الهجين (BM25 + المتجه) ← التضييق إلى قِلّة بإعادة الترتيب ← تمريرها إلى الـ LLM لتوليد الإجابة.
الفرق عن RAG الساذج هو وجود "④ البحث الهجين" و"⑤ إعادة الترتيب" من عدمه. هاتان المرحلتان ترفعان دقة البحث إلى مستوى عملي.
3. ① التقطيع إلى أجزاء (chunking) (الأهم)
من الإنصاف القول إن التقطيع يحدّد نصف جودة RAG. إليك الاستراتيجيات الرئيسية.
| الاستراتيجية | ماذا تفعل | مناسبة لـ |
|---|---|---|
| recursive بـ 512 توكن | الخيار الافتراضي العملي. أُبلِغ عنها كالأولى من بين 7 استراتيجيات في مقياس فبراير 2026 | عند الشك، اعتمد هذا |
| semantic | القطع حيث يتحوّل المعنى، بحيث يكون كل جزء متماسكاً موضوعياً | المستندات التقنية الكثيفة |
| structural | احترام العناوين وكتل الكود وأقسام HTML | التوثيق والكود |
| parent-child (هرمي) | البحث بدقة على أجزاء صغيرة؛ وإرجاع الجزء الأب المحيط عند الإجابة | الموازنة بين الدقة والسياق |
إذا كانت المشكلة في فقدان السياق عند الحدود، فإن Contextual Retrieval (إرفاق سياق المستند كاملاً بكل جزء) أو Late Chunking يساعد. تُبلِغ Anthropic بأن Contextual Retrieval + إعادة الترتيب خفّضا فشل الاسترجاع ضمن أعلى 20 بنسبة تصل إلى 67% (رقم منقول). الترتيب الواقعي: ابدأ بـ "recursive 512"، وأضف semantic / parent-child / Contextual Retrieval إذا قصُرت الدقة.
4. ② اختيار نموذج embedding
يحوّل نموذج embedding الأجزاء إلى متجهات — وهو أساس دقة البحث.
- الخيار الافتراضي الآمن: OpenAI text-embedding-3-large. توازن جيد بين جودة الاسترجاع وسهولة التكامل.
- خيارات أخرى: Cohere وVoyage وembeddings من Gemini ونماذج OSS متنوعة.
- مهم: كثير من embeddings مفتوحة المصدر كافية تماماً للإنتاج عند دمجها مع البحث الهجين + إعادة الترتيب. لا تهوس بالـ embedding وحده.
الفكرة هي معاملة "الـ embedding كجزء واحد من خط البحث بأكمله." فبدلاً من استبداله بـ embedding باهظ، غالباً ما تكون إضافة البحث الهجين وإعادة الترتيب أكثر جدوى من حيث التكلفة.
5. ③ اختيار قاعدة بيانات متجهية (مقارنة)
تخزّن قاعدة البيانات المتجهية المتجهات وتبحث فيها. إليك روّاد 2026 بحسب طابع كلٍ منها.
| القاعدة | الطابع / نقطة القوة | لمن هي |
|---|---|---|
| Chroma | أصيلة للذكاء الاصطناعي، محلية أولاً، واجهة Python بسيطة | الأفراد/إثباتات المفهوم لبناء نماذج RAG أولية بأسرع وقت |
| pgvector | امتداد لـ Postgres. لا قاعدة بيانات ثانية، واتساق معاملاتي | الفرق التي تستخدم Postgres بالفعل |
| Qdrant | زمن استجابة منخفض (p50 ~4ms؛ منقول مقابل Milvus ~6ms / Pinecone ~8ms) | المهتمون بالسرعة، الإنتاج |
| Pinecone | مُدارة بالكامل. صفر بنية تحتية، تبدأ بمفتاح API فقط | من يريد تولّي التشغيل، السحابة أولاً |
| Weaviate | بطلة البحث الهجين (BM25 + متجه + بيانات وصفية في استعلام واحد) | مستخدمو البحث الهجين بكثافة |
| Milvus | بمستوى المؤسسات، تتعامل مع مليارات المتجهات | النطاق الضخم جداً |
محاور الاختيار: "النطاق، مُدارة مقابل مستضافة ذاتياً، المكدّس الحالي، الميزانية." عند الشك — Chroma للنماذج الأولية، وpgvector إن كان لديك Postgres، وQdrant/Pinecone لإنتاج متوازن، وWeaviate للهجين المكثف. بالنسبة لمعظم أحمال عمل RAG، تُعدّ Pinecone / Weaviate / Qdrant خيارات قوية.
6. ④ البحث الهجين (BM25 + المتجه)
ما يصلح أكبر نقطة ضعف في RAG الساذج — وهي الضعف في المصطلحات الدقيقة — هو البحث الهجين. فهو يدمج BM25 (بحث الكلمات المفتاحية/اللفظي) مع البحث المتجهي الكثيف.
دمج اللفظي + الدلالي
يُبلَغ أن دمج الاثنين عبر Reciprocal Rank Fusion (RRF)
يتفوّق باستمرار على أيٍّ من المقاربتين منفردة (NDCG أعلى).
عملياً، الأسهل استخدام قاعدة بيانات تُرجع نتائج هجينة في استعلام واحد، مثل Weaviate. اترك ضبط الدرجات الصعب لـ RRF (دمج قائم على الترتيب) ولن ينكسر. والنتيجة: بحث قوي في كلٍّ من المصطلحات الدقيقة وإعادة الصياغة.
7. ⑤ إعادة الترتيب (retrieve-then-rerank)
المعيار في 2026 هو "مرحلتان: الاسترجاع بشكل واسع أولاً ← ثم التضييق (إعادة الترتيب)."
- المرحلة 1 (الاسترجاع): جلب أعلى 50-100 بسرعة باستخدام bi-encoder (embeddings).
- المرحلة 2 (إعادة الترتيب): باستخدام cross-encoder، إعطاء درجة لـ (السؤال، الجزء) معاً والتضييق إلى القِلّة الأكثر صلة فعلاً.
أدوات إعادة الترتيب الشائعة هي Cohere Rerank 3.5 وVoyage rerank-2.5 وBGE reranker-v2 وJina Reranker v2. تضيف إعادة الترتيب نحو 50-200ms من زمن الاستجابة والتكلفة، لكن لأن الأجزاء المُمرَّرة إلى الـ LLM تصبح قِلّة منتقاة، فإنها غالباً ما تقلّل استهلاك الـ LLM للتوكنات وتخفّض التكلفة الإجمالية. على صعيدَي الدقة والتكلفة معاً، تتحوّل إعادة الترتيب إلى مرحلة "لا سبب لعدم إضافتها."
8. أطر العمل (LlamaIndex/LangChain)
استخدام إطار عمل أسرع من كتابة كل شيء بنفسك. إليك توزيع المهام في 2026.
- LlamaIndex: مركّز على الاسترجاع. قوي في فهرسة المستندات وجودة البحث والتكرار السريع لـ RAG.
- LangChain / LangGraph: جانب التنسيق (التحكّم). سير العمل المعقّد وتنسيق الوكلاء.
- النمط المدمج: عملياً، يستخدم كثيرون LlamaIndex كطبقة استرجاع وLangGraph كطبقة تحكّم.
لاحظ أنه مؤخراً، مع توحيد الأدوات عبر MCP وصعود Agent SDKs، ثمة اتجاه نحو وكلاء يبنون خطوط الأنابيب أثناء التشغيل دون أطر LLM ثقيلة. ومع ذلك، إن كنت تصقل جودة البحث، تظل عائلة LlamaIndex قوية. لبناء الوكلاء عموماً، انظر كيفية بناء وكيل ذكاء اصطناعي.
9. RAG مقابل السياق الطويل
"مع نافذة سياق بحجم 1M توكن، ألا يمكنني حشو كل شيء وتخطّي RAG؟" — سؤال شائع. الجواب "لا، RAG لا يُستبدَل."
فخّ "احشُ كل شيء"
- غير اقتصادي في التوكنات: إرسال سياق ضخم زائد في كل مرة مكلف.
- lost in the middle: تميل المعلومات في منتصف النص الطويل إلى التجاهل.
- التشتيت: كلما زادت المعلومات غير ذات الصلة، انخفضت جودة الإجابة.
القاعدة الإرشادية: استخدم السياق الطويل للمجموعات الصغيرة والتكرار السريع، وأضف prompt caching مبكراً للسياق المتكرر المستقر، وأضف RAG لحظة أن تصبح "الحداثة، النطاق، إثبات المصدر" متطلبات. إن "مجرد حشوه في نافذة السياق" هو "مجرد إضافة قاعدة بيانات متجهية" الجديد — ليس دواءً لكل داء. اقرن هذا بفهم نافذة السياق.
10. ملاحظات حول الانتقال للإنتاج
- ابنِ منظومة تقييم أولاً: "تحسّن نوعاً ما" لا يمكن تحسينه. قِس دقة الاسترجاع كمّياً بمجموعة من الأسئلة التمثيلية × المصادر المتوقّعة وقارن مع كل تغيير.
- المراقبة: راقب باستمرار معدّل إصابة الاسترجاع، والصلة بعد إعادة الترتيب، ومدى استناد الإجابة إلى المصادر.
- تصميم التكلفة: تأتي الفوترة من الـ embeddings وإعادة الترتيب والـ LLM. تقليص توكنات الـ LLM عبر إعادة الترتيب هو موفّر التكلفة المعياري. انظر توفير التوكنات.
- الحداثة وإثبات المصدر: صمّم بحيث تنعكس تحديثات البيانات (إعادة الفهرسة) وإرفاق المصدر دائماً (أيّ مستند) بالإجابات — مفتاح لمكافحة الهلوسة.
- البيانات السرّية: انتبه عند تحويل المستندات الداخلية لمتجهات ووضعها خارجياً. انظر إرشادات استخدام الذكاء الاصطناعي في الشركات.
الخلاصة
تطوّر RAG العملي من "التقطيع والبحث المتجهي" الساذج إلى خط أنابيب متعدد المراحل: "تقطيع ذكي ← embedding ← قاعدة بيانات متجهية ← بحث هجين ← إعادة ترتيب." وأكبر مكسبين للدقة هما البحث الهجين (دمج BM25 + المتجه عبر RRF) وإعادة الترتيب (retrieve-then-rerank) — ومجرد إضافة هذين الاثنين يصحّح إلى حد كبير "الإجابة المختلّة."
أما قواعد البيانات المتجهية: Chroma للنماذج الأولية، وpgvector إن كان لديك Postgres، وQdrant/Pinecone للإنتاج، وWeaviate للهجين المكثف. وأما أطر العمل: LlamaIndex للاسترجاع، وLangChain/LangGraph للتحكّم. وحتى عند 1M توكن، لا يُستبدَل RAG — إن احتجت الحداثة والنطاق وإثبات المصدر، فهو RAG. وأمر أخير لا بدّ منه: "ابنِ مجموعة التقييم أولاً." لا يمكنك تحسين ما لا تستطيع قياسه. التزم بذلك وسيتطوّر RAG لديك بثبات من "يعمل نوعاً ما" إلى "يعمل في الإنتاج."
قراءات ذات صلة: ما هو RAG (الأساسيات)، وما هي نافذة السياق، وكيفية بناء وكيل ذكاء اصطناعي، وClaude Agent SDK، وما هو MCP.
الأسئلة الشائعة
س. دقة RAG لديّ منخفضة. ماذا أُصلح أولاً؟
ج. إضافة الأمرين — "البحث الهجين" و"إعادة الترتيب" — هي الأكثر فعالية. فالبحث المتجهي البسيط وحده ضعيف في المصطلحات الدقيقة مثل أرقام الطُرز والأسماء العَلَم، وتُدفن الأجزاء الأكثر صلة. والدمج مع BM25 (عبر RRF) + إعادة ترتيب بـ cross-encoder يرفع جودة البحث إلى مستوى عملي. إن لم يكفِ ذلك بعد، فأعد النظر في التقطيع.
س. أيّ قاعدة بيانات متجهية أختار؟
ج. Chroma للنماذج الأولية، وpgvector إن كان لديك Postgres بالفعل هما بدايتان سهلتان. لإنتاج متوازن، Qdrant (زمن استجابة منخفض) أو Pinecone (مُدارة بالكامل)؛ وللبحث الهجين المكثف، Weaviate؛ وللنطاق الضخم جداً، Milvus. اختر بحسب النطاق وتفضيل التشغيل والمكدّس الحالي والميزانية.
س. ما حجم الجزء المناسب؟
ج. نحو 512 توكن مع تقطيع recursive خيار افتراضي عملي (أُبلِغ أنه قرب القمة في مقاييس 2026). للمستندات التقنية، semantic (القطع بحسب المعنى)؛ وللتوثيق/الكود، structural (احترام العناوين/الكود)؛ وللدقة مع السياق، parent-child. ابدأ بـ 512 واضبط أثناء التقييم.
س. مع نافذة 1M توكن، أليس RAG غير ضروري؟
ج. لا يصبح غير ضروري. فحشو كل شيء في السياق يُسقط الجودة عبر عدم الكفاءة في التوكنات، و"lost in the middle"، والتشتيت. استخدم السياق الطويل للمجموعات الصغيرة والنماذج الأولية، وRAG حالما تصبح الحداثة والنطاق وإثبات المصدر متطلبات — هذا هو التقسيم الواقعي.
س. LangChain أم LlamaIndex — أيّهما أستخدم؟
ج. LlamaIndex إن كنت تصقل جودة البحث؛ وLangChain/LangGraph للتحكّم المعقّد وتنسيق الوكلاء. عملياً، يجمع كثيرون بينهما — "LlamaIndex كطبقة استرجاع، وLangGraph كطبقة تحكّم." ومؤخراً ثمة اتجاه أيضاً للتجميع بخفّة عبر Agent SDKs، فاختر بحسب متطلباتك.
