الـ Retrievers المتقدمة — لما البحث البسيط ميكفيش

الاسترجاع البسيط بيعمل حاجة واحدة: بياخد سؤالك زي ما هو، بيحوّله لـ Embedding، وبيجيب أقرب Chunks في المعنى.

المشكلة؟ «زي ما هو» دي. السؤال الحقيقي ساعات بييجي بكلمات مختلفة عن كلمات المستندات، أو فيه شرط البحث الدلالي مش بيفهمه، أو الإجابة أكبر من الـ Chunk اللي اتلقى.

الـ Retrievers المتقدمة كلها فكرة واحدة: حط شوية ذكاء قبل البحث أو بعده. قبل البحث: عدّل السؤال أو ترجمه لشروط. بعد البحث: كبّر النتيجة أو رتّبها أحسن. البحث نفسه — الـ Vector Store — هو هو مبيتغيرش.

<!-- Field 6: Real-world analogy (Layer 2) -->

تخيّل أمينين مكتبة:

الأول مبتدئ. بتقوله «عايز حاجة عن فلوس الأجازات» فبيدوّر حرفيًا على كلمة «فلوس الأجازات». الكتاب المطلوب اسمه «احتساب بدل الإجازات السنوية»؟ معلش، مش هيلاقيه. طلبت «مقالات 2024»؟ هيجيبلك أي حاجة «قريبة في المعنى» من غير ما يبص على سنة النشر. ولما يلاقي الصفحة الصح، بيقصها لك قصاصة صغيرة من نصها — من غير باقي الفصل اللي بيكمّل المعنى.

التاني خبير. بياخد طلبك ويعيد صياغته كذا مرة بمترادفات مختلفة قبل ما يدوّر (ده Multi-Query). بيسمع «مقالات 2024» فبيفهم إن «2024» دي فلتر مش كلمة بحث — بيروح لرف السنة دي وبيدوّر جواه (ده Self-Query). ولما يلاقي القصاصة المناسبة، بيجيبلك الفصل كله اللي هي منه (ده Parent-Document).

نفس المكتبة. نفس الكتب. الفرق كله في الذكاء اللي حوالين البحث.

<!-- Field 7: Simple example -->

مثال حقيقي — أربع طرق البحث البسيط بيقع بيها

Knowledge Base بتاع HR فيه سياسات الشركة. شوف الأربع أسئلة دول:

خد بالك: في الحالات الأربعة الموديل هيجاوب — بثقة. المشكلة مش في التوليد. المشكلة قبل ما الموديل يشوف أي حاجة أصلًا.

<!-- Field 8: How it works (Layer 3) -->

التلات Patterns بيتدخلوا في نقطتين من الـ Pipeline اللي أنت عارفها:

1. قبل البحث (Query side): بدل ما السؤال يدخل زي ما هو — Multi-Query بيولّد منه كذا صيغة، و Self-Query بيترجمه لـ فلتر منظّم + نص بحث. 2. بعد البحث (Result side): بدل ما النتيجة تتسلم زي ما هي — Parent-Document بيستبدل الـ Chunk الصغير بالسياق الأكبر اللي هو جزء منه.

الـ Vector Store والـ Embeddings والتوليد؟ كلهم زي ما هم. عشان كده الـ Patterns دي بتتركب على أي نظام RAG شغال من غير ما تكسر حاجة.

<!-- Field 9: Step-by-step explanation — the three patterns in detail -->

الـ Patterns التلاتة — واحد واحد

### 1) Multi-Query Retrieval — «اسأل السؤال بكذا طريقة»

• بيصلّح إيه: اختلاف الألفاظ (فشل #1) والسؤال المتعدد الزوايا (فشل #4).
• بيشتغل إزاي: قبل البحث، نداء LLM واحد بيولّد 3–4 صيغ بديلة للسؤال بمفردات مختلفة. بتعمل بحث بكل صيغة، وبتدمج النتايج مع إزالة التكرار.
• مثال مصغّر: «الأجازات بتتحسب إزاي؟» بيتولد منه: «طريقة احتساب رصيد الإجازة السنوية» + «vacation balance calculation policy» + «كام يوم إجازة بيستحقها الموظف؟». الصيغة التانية هي اللي هتضرب على مستند الـ HR الرسمي — والتالتة بتغطي لو المستندات أصلًا بالإنجليزي.
• 💸 التمن: نداء LLM إضافي (وبالتالي +Latency قبل ما البحث يبدأ أصلًا) + 3–4 عمليات بحث بدل واحدة + Chunks أكتر داخلة الـ Prompt لو مش بتشذّب. الحساب الكامل تحت في قسم التكلفة.

### 2) Self-Query Retrieval — «الموديل يترجم السؤال لفلتر + بحث»

• بيصلّح إيه: أسئلة الـ Metadata (فشل #2) — «هات مقالات 2024 عن X»، «قرارات قسم كذا»، «تذاكر الـ priority العالي».
• بيشتغل إزاي: نداء LLM بياخد السؤال + وصف حقول الـ Metadata عندك، وبيطلع حاجتين: فلتر منظّم (year = 2024) + نص بحث دلالي («الشغل الـ Remote»). الفلتر بيتنفذ كـ Metadata Filtering عادي، والبحث الدلالي بيشتغل جوه النتايج المفلترة بس.
• مثال مصغّر: «هات قرارات الـ HR بتاعة 2024 عن الـ Remote» ← filter: {type: "hr-decision", year: 2024} + query: "سياسة العمل عن بعد". دلوقتي مستحيل ترجع قرارات 2021 — الفلتر قصّهم قبل البحث أصلًا.
• ⚠️ الشرط المسبق اللي محدش بيقوله: الـ Pattern ده جودته = جودة الـ Metadata بتاعتك. لو المستندات متخزنة من غير year و type نضاف ومتسقين، الموديل هيولّد فلاتر على حقول مش موجودة — والنتيجة صفر نتايج أو زبالة. صمم الـ Metadata وقت الـ Ingestion الأول.
• 💸 التمن: نداء LLM إضافي لكل سؤال + شغل صيانة على Schema الـ Metadata.

### 3) Parent-Document Retrieval — «دوّر بالصغير، رجّع الكبير»

• بيصلّح إيه: الـ Chunk الأصغر من الإجابة (فشل #3).
• بيشتغل إزاي: وقت الـ Ingestion بتقطّع مرتين: Chunks صغيرة (150–300 Token) بتتعملها Embeddings — لأن الصغير أدق في البحث. وكل Chunk صغير بيشاور على Parent أكبر (القسم أو الصفحة، 1,000–1,500 Token) متخزن في Store عادي جنبه. وقت السؤال: البحث بيحصل في الصغير، واللي بيتحط في الـ Prompt هو الـ Parent.
• مثال مصغّر: البحث بيلقط «الخطوة 3: تسليم العهدة» (دقة عالية لأن الـ Chunk مركّز) — والموديل بياخد قسم «إجراءات إنهاء التعاقد» كامل بخطواته الخمسة. البحث كسب دقة الصغير، والإجابة كسبت اكتمال الكبير.
• 💸 التمن: مفيش نداءات إضافية — التمن هنا مختلف: تخزين مضاعف (Store تاني للـ Parents) و Context أكبر بكتير داخل للموديل في كل سؤال — يعني Input Tokens أكتر، يعني فلوس. ولو عملت الـ Parents ضخمة أوي، رجعت بنفسك لمشكلة «المعلومة بتتوه في النص».

### طيب و Reranking و Query Rewriting؟

دول قرايبهم اللي أنت قابلتهم قبل كده — ومش هنعيد شرحهم:

• Reranking بيشتغل على ترتيب النتايج بعد ما رجعت: النتايج موجودة بس الأحسن مش الأول. (مفهوم Reranking & advanced retrieval.)
• Query Rewriting بيصلّح سؤال ناقص سياق المحادثة: «طيب والمخفضة؟» محتاج يتحول لسؤال كامل قبل البحث. (مفهوم Multi-turn RAG.)

الأربعة بيتكاملوا: Rewriting بيصلّح صياغة السؤال، Multi-Query بيوسّع تغطيته، Self-Query بيترجم شروطه، Parent-Document و Reranking بيحسّنوا اللي راجع.

<!-- Field 10: Visual explanation -->

بالرسم

فين كل Pattern بيتدخل في الـ Pipeline:

                    ┌─────────────────────────────────────────────────┐
User question ────► │  QUERY SIDE — before the search                 │
                    │                                                 │
                    │  Multi-Query : 1 question ──► N phrasings       │
                    │  Self-Query  : question ──► filter + query text │
                    └───────────────────────┬─────────────────────────┘
                                            ▼
                              Vector store search (unchanged)
                                            ▼
                    ┌─────────────────────────────────────────────────┐
                    │  RESULT SIDE — after the search                 │
                    │                                                 │
                    │  Parent-Document : small chunk ──► big parent   │
                    │  Reranking       : re-order results             │
                    │                    (separate concept)           │
                    └───────────────────────┬─────────────────────────┘
                                            ▼
                              Augment + Generate (unchanged)

لاحظ إن الصندوق اللي في النص — البحث نفسه — مكتوب جنبه unchanged. ده جوهر الموضوع: أنت مش بتغيّر البحث، أنت بتحسّن اللي داخل له واللي خارج منه. وعشان كده تقدر تركّب أي Pattern منهم لوحده، النهارده، على النظام اللي عندك.

<!-- Field 11: Technical explanation (Layer 4) -->

أول حاجة تثبتها: الأسماء دي أسماء Patterns مش Features في مكتبة. اتشهرت من التوثيق بتاع الـ Frameworks (LangChain و LlamaIndex بيقدموها جاهزة بنفس الأسماء تقريبًا)، بس كل واحدة فيها فكرة تتكتب في 15–30 سطر كود عادي. لو فاهم الفكرة، تقدر تنفذها بإيدك أو تستخدم الجاهز — وأنت فاهم اللي بيحصل جواه (وده قرار مفهوم «تبني الـ RAG بإيه؟» كامل).

تاني حاجة: التلاتة بيتجمعوا في معادلة واحدة. الاسترجاع البسيط هو:

answer(question) = generate(question, search(embed(question)))

الـ Patterns بيحقنوا دوال في النص:

Multi-Query      : search(embed(q))  ──►  merge(search(embed(v)) for v in variants(q))
Self-Query       : search(embed(q))  ──►  search(embed(text(q)), filter=parse(q))
Parent-Document  : search(...)       ──►  parents(search(...))

تالت حاجة — الترتيب اللي تجرب بيه مش عشوائي. ابدأ بالأرخص تشغيليًا: Parent-Document (مفيش نداءات إضافية وقت السؤال) → Multi-Query (نداء واحد إضافي) → Self-Query (نداء إضافي + استثمار في الـ Metadata). ده لو التشخيص بيسمح — التشخيص أولًا دايمًا.

<!-- Field 13: Code example (D-4 provider-agnostic, CR-4 Arabic surround) -->

على مستوى التشغيل — وإزاي تعرف إنه اشتغل أصلًا

الـ Pattern اتركّب. دلوقتي السؤال الوحيد المهم: حسّن ولا لأ؟ والإجابة عمرها ما تكون «حاسس إنه أحسن» — الإحساس ده هو اللي بيخلي أنظمة تدفع ضعف الفلوس على تحسين وهمي.

الطريقة المنهجية (وهي نفسها فلسفة Evaluating RAG systems):

1. Golden Set صغير: 20–30 سؤال حقيقي — من الـ Logs بتاعتك مش من خيالك — وجنب كل سؤال: الـ Chunks اللي المفروض تترجع (أو على الأقل المستند الصح). 2. قيس الاسترجاع لوحده، قبل التوليد: لكل سؤال — هل الـ Chunk الصح ظهر في النتايج؟ (Hit Rate)، وفي أنهي ترتيب؟ نسبة الملائم وسط اللي رجع (Precision) ونسبة اللي جبته من الملائم الموجود (Recall). 3. خد Baseline بالبحث البسيط. رقم واحد: «Hit Rate = 62%». 4. ركّب Pattern واحد بس. قيس تاني. طلع 81%؟ الـ Pattern كسب مكانه. طلع 64% والتكلفة زادت 60%؟ شيله — بدون ندم. 5. سجّل التكلفة والـ Latency مع كل قياس. التحسين اللي بيدفّعك 3× عشان +2% مش تحسين — قرار خاسر بمقياس واضح.

💡 نصيحة: الخطوة 4 بالذات — واحد واحد. لو ركّبت تلات Patterns مرة واحدة والجودة اتحسنت، مش عارف مين اللي حسّن. ولو باظت، مش عارف مين اللي خرّب. عزل المتغيرات ده مش ترف علمي — ده اللي هيوفرلك أسابيع Debugging.

<!-- Field 16: When to use it (Layer 7a) — the symptom → pattern decision table -->

الكود

ده Multi-Query كامل من غير أي Framework — الفكرة عريانة، بأي Provider وأي Vector Store:

# ---------- MULTI-QUERY RETRIEVAL: the whole pattern, no framework ----------
question = "How are vacation days calculated?"

# 1) One extra LLM call: rephrase the question from different angles
variants_prompt = f"""Rewrite this question in 3 different ways.
Use different vocabulary in each rewrite. One question per line.

Question: {question}"""

variants = llm.generate(variants_prompt).strip().splitlines()
all_queries = [question] + variants              # 4 queries total

# 2) Search with every phrasing (parallelize these in production)
seen_ids, merged = set(), []
for q in all_queries:
    for chunk in vector_store.search(embed(q), top_k=3):
        if chunk.id not in seen_ids:             # 3) de-duplicate
            seen_ids.add(chunk.id)
            merged.append(chunk)

# 4) Cap the final set, then continue like any normal RAG pipeline
top_chunks = merged[:6]
answer = generate_grounded_answer(question, top_chunks)

تلات حاجات خد بالك منهم:

• السطر `merged[:6]` هو خط الدفاع عن فلوسك. من غيره، 4 استعلامات × 3 نتايج ممكن يدخّلوا 12 Chunk في الـ Prompt — والفاتورة والتشتيت معاهم. الدمج لازم يتبعه تشذيب.
• إزالة التكرار مش رفاهية. الصيغ المختلفة لنفس السؤال غالبًا هترجّع نفس أقوى الـ Chunks — وده في حد ذاته إشارة جودة: اللي بيظهر في كل الصيغ هو الأملأ للعين.
• نداء الـ Variants ممكن يكون بموديل أرخص. إعادة صياغة سؤال مش محتاجة أقوى موديل عندك — دي أول فرصة توفير هتقابلك.

<!-- Field 12: Developer perspective (API-level reality) — includes "how to know it worked" per brief, ties to eval philosophy -->

تمرين (45–60 دقيقة، على مشروعك الحالي):

1. افتح الـ RAG Knowledge Assistant بتاعك واجمع 20 سؤال حقيقي — لو عندك Logs استخدمها، لو لسه، اكتب أسئلة بصياغات مستخدم حقيقي مش بصياغات مستنداتك. 2. لكل سؤال سجّل: المستند اللي المفروض يترجع. مبروك — ده أول Golden Set ليك. 3. قيس الـ Hit Rate بالبحث البسيط. اكتب الرقم. ده الـ Baseline. 4. بص على الأسئلة اللي فشلت وصنّفها بجدول «العرض→العلاج» فوق: كام واحدة Vocabulary Mismatch؟ كام واحدة Metadata؟ كام واحدة Chunk صغير؟ 5. نفّذ Pattern واحد — اللي بيصلّح أكبر فئة فشل عندك — بإيدك زي كود Multi-Query فوق. قيس تاني، وقارن بالرقم المكتوب.

اللي هتتعلمه من الخطوة 4 بالذات — إن أنماط الفشل عندك مش موزعة بالتساوي — هو الدرس الحقيقي في الصفحة دي.

<!-- Field 27: Interview questions -->

<!-- Field 15: Common misconceptions -->

مفاهيم غلط منتشرة

1) «Retriever أعقد = نتايج أحسن» — ❌ أكتر فكرة غلط في الموضوع ده كله. كل Pattern بيصلّح نمط فشل معين — لو النمط ده مش موجود عندك، الـ Pattern بيضيف تكلفة و Latency وساعات Noise (نتايج زيادة بتشتت الموديل) من غير أي مكسب. التعقيد مش ميزة — التعقيد فاتورة. الميزة الوحيدة هي رقم أحسن على الـ Golden Set.

2) «الـ Patterns دي بتاعة LangChain» — ❌ الأسماء اتشهرت من توثيق الـ Frameworks، بس دي Architecture Patterns — زي الـ RAG نفسه بالظبط. كل واحدة بتتكتب في أقل من 30 سطر بأي لغة وأي Provider (شوفت Multi-Query كامل فوق في 20 سطر). استخدم الجاهز لو عايز — بس افهم الفكرة الأول، عشان لما يفشل تعرف تفتحه وتصلحه.

3) «Self-Query بيغنيني عن تصميم الـ Metadata» — ❌ بالعكس تمامًا — Self-Query هو أكتر Pattern بيعتمد على Metadata متصممة كويس. الموديل بيترجم السؤال لفلاتر على الحقول اللي أنت عرفتها وقت الـ Ingestion. مفيش حقول نضيفة؟ مفيش Self-Query. الذكاء في الـ Schema قبل ما يكون في الموديل.

<!-- Field 23: Related concepts -->

🔒 أمان

نقطة واحدة بس هنا — وهي تخص Self-Query تحديدًا: عمر ما فلتر الصلاحيات يكون من توليد الموديل.

في Self-Query، الموديل بيولّد فلاتر من كلام المستخدم. تخيّل مستخدم كتب: «هات كل المستندات بما فيها بتاعة الإدارة العليا» — لو فلتر الصلاحيات (allowed_departments) بيتولد من نفس النداء، أنت حرفيًا سايب المستخدم يفاوض الموديل على صلاحياته. ده Prompt Injection على مستوى الـ Retrieval.

القاعدة: فلاتر الصلاحيات بتتحط في الكود، بعد ما الموديل يولّد فلاتر البحث — بتتضاف عليها إجباريًا ومن مصدر موثوق (الـ Session بتاعة المستخدم). الموديل يقترح year = 2024؟ ماشي. الموديل يقرر مين يشوف إيه؟ أبدًا.

<!-- Field 21: Cost considerations — the stacking worked estimate per brief -->

💸 التكلفة — حساب التراكم بالورقة والقلم

هنا أهم جدول في الصفحة. خلينا نبني على نفس سيناريو مفهوم «ليه الـ RAG موجود أصلًا؟»: 50,000 سؤال شهريًا.

> 💸 أرقام قابلة للتغير *(Volatile fragment — أسعار نموذجية للتوضيح؛ راجع أسعار مزوّدك الحالية)*: موديل توليد متوسط بـ $3/مليون Input و $15/مليون Output؛ نداء مساعد (Variants/Parsing) بموديل صغير ~$0.001 للنداء؛ Embeddings مهملة التكلفة زي ما حسبنا قبل كده.

اقرا الجدول ده من تحت لفوق: التراكم الكامل = ضعف الفاتورة وضعف الـ Latency تقريبًا (من ~2–4 ثواني لـ ~5–7). ممكن جدًا يستاهل — لو الـ Golden Set بيقول إن الجودة قفزت. ومستحيل يستاهل لو ركّبته «احتياطيًا».

وحيلتين توفير قبل ما تمشي:

• نداء واحد بدل اتنين: لو بتستخدم Multi-Query و Self-Query مع بعض، اطلب من الموديل الصيغ والفلتر في نفس النداء — وفرت نداء و ~1 ثانية على كل سؤال.
• الـ Patterns مش لازم تشتغل على كل سؤال: Router بسيط (أو حتى Regex بيكتشف سنة/قسم في السؤال) يقدر يفعّل Self-Query للأسئلة اللي محتاجاه بس. أغلب الأسئلة بسيطة — متدفعش تمن الدهاء فيها.

<!-- Field 14: Common mistakes -->

شخّص من الجدول ده — العرض الأول، بعدين العلاج:

⚠️ خد بالك من السطر الأخير. لو الأساس بايظ — Chunking أعمى أو Embedding Model مش مناسب للغة بياناتك — أي Pattern هتركّبه فوقه بيلمّع الزبالة مش بيصلّحها. الـ Patterns دي تحسين على أساس سليم، مش بديل عنه.

<!-- Field 17: When NOT to use it (Layer 7b) -->

• النظام لسه بيتبني: أول نسخة من أي RAG تبقى بالبحث البسيط. دايمًا. محتاج Baseline تقيس عليه قبل أي دهاء.
• مفيش قياس: لو معندكش Golden Set، مش وقت Patterns — وقت بناء Golden Set. التحسين من غير قياس اسمه تخمين بفلوس.
• الفشل مش عندك: مستخدمينك بيسألوا أسئلة مباشرة بألفاظ المستندات نفسها؟ الـ Top-k البسيط كفاية، وأي إضافة تمن من غير مقابل.
• الـ Latency عندك مقدسة: لو الـ SLA بتاعك ضيق، نداء LLM إضافي قبل البحث ممكن يكون رفاهية متتحملش — ساعتها فكّر في Hybrid Search أو تحسين الـ Chunking الأول (بيصلّحوا كتير من نفس الأعراض بصفر نداءات إضافية).
• سؤال Metadata نادر: لو سؤال «هات بتاع 2024» بيظهر مرة في الشهر، متبنيش Self-Query عشانه — حط الفلاتر في الـ UI وخلي المستخدم يختارها بنفسه. أرخص وأضمن.

<!-- Field 18: Alternatives -->

البدايل — قبل ما تركّب Retriever متقدم

<!-- Field 19: Trade-offs -->

الموازنات

<!-- Field 20: Security considerations -->