Boolean Retrieval | Print Study Guide

🔍 1. مقدمة وتطبيقات الـ IR (Intro & Apps)

Information Retrieval (IR) is finding material (usually documents) of an unstructured nature (usually text) that satisfies an information need from within large collections. هاض هو التعريف الجوهري للمادة. الفكرة ببساطة إن الـ IR مش مجرد "بحث عن كلمات"، هو عملية العثور على المواد (غالباً مستندات نصية) ذات الطبيعة Unstructured (غير منظمة) اللي بتلبي حاجة معلوماتية (Information Need) من بين مجموعات بيانات ضخمة.

تطبيقات عملية (Real-world Apps):

• Web Search: زي جوجل ومحركات البحث العالمية.
• E-mail Search: البحث في بريدك الإلكتروني عن رسائل قديمة.
• Laptop Search: البحث السريع في ملفات جهازك الشخصي.
• Corporate Knowledge Bases: البحث في وثائق الشركات ومستودعات المعرفة.
• Legal IR: البحث القانوني في آلاف القضايا والدساتير (مجال ضخم ومعقد).

⚙️ 2. الفرضيات والهدف (Assumptions)

Collection: A set of documents (Corpus). Assume it is static for now. الـ Collection (أو الـ Corpus) هي "مجموعة المستندات" اللي النظام رح يبحث فيها. حالياً بنفترض إنها Static (ثابتة)؛ يعني ما في إضافة أو حذف مستندات أثناء العمل.

Goal: Retrieve documents relevant to the user's info need and help them complete a task. الهدف مش بس "تطابق كلمات"، الهدف الحقيقي هو جلب مستندات Relevant (ذات صلة) فعلاً باللي بده إياه اليوزر، ولازم المعلومة تساعد اليوزر إنه Complete a task (يخلص المهمة) اللي بيده.

⚖️ 3. تقييم الجودة (How good are the docs?)

Precision: Fraction of retrieved docs that are relevant to the user's need. الـ Precision (الدقة): هي مقياس "نظافة" النتائج. لو السيستم طلعلك 10 ملفات، وطلع منهم بس 3 مفيدين، هون الدقة منخفضة (3/10).
💡 بتجاوب على سؤال: "اللي طلعلي صح؟"

Recall: Fraction of relevant docs in collection that are retrieved. الـ Recall (الاستدعاء): هي مقياس "شمولية" البحث. لو المكتبة فيها 100 ملف مفيد، والسيستم لقى بس 20، هون الاستدعاء ضعيف (20/100).
💡 بتجاوب على سؤال: "لقينا كل الموجود؟"

Precision
بتهتم بـ: "الدقة"

Recall
بتهتم بـ: "الشمولية"

🎭 4. حالة شكسبير (The Shakespeare Case)

Query: Brutus AND Caesar but NOT Calpurnia. هاض هو المثال الكلاسيكي اللي بنبني عليه فهمنا. تخيل إنك في مكتبة فيها كل أعمال شكسبير، وبدك تطلع المسرحيات اللي اجتمع فيها بروتس وقيصر مع بعض، بس بشرط ما يكون لاسم كالبورنيا أي ذكر فيها.

The "grep" Approach: Linear Scanning. أول فكرة بتخطر على بال المبرمج هي استخدام أداة grep. السيستم بيمسك كل الملفات وببلش "يمسح" الكلام سطر بسطر (Linear Scan). لو لقى الكلمات المطلوبة بيعطيك النتيجة.

Why it fails for modern IR? ليش ما بنستخدم هالطريقة في محركات البحث؟
1. Slow: لو الداتا كبرت وصارت "مليارات" الملفات، الـ grep رح يحتاج وقت طويل جداً (سنوات أحياناً) ليعطيك نتيجة.
2. No Ranking: الـ grep ما برتبلك مين "أفضل" مستند، هو بس بيحكيلك "موجود" أو "مش موجود". إحنا بدنا السيستم يحكيلنا مين أهم ملف نقرأه أولاً.

📊 5. مصفوفة التواجد (Incidence Matrix)

1 if play contains word, 0 otherwise. الحل هو بناء جدول بسيط: 1 إذا الكلمة موجودة بالمسرحية، 0 إذا مش موجودة.

Term	Antony and Cleopatra	Julius Caesar	The Tempest	Hamlet	Othello	Macbeth
Antony	1	1	0	0	0	1
Brutus	1	1	0	1	0	0
Caesar	1	1	0	1	1	1
Calpurnia	0	1	0	0	0	0
Cleopatra	1	0	0	0	0	0
mercy	1	0	1	1	1	1
worser	1	0	1	1	1	0

So we have a 0/1 vector for each term. صار لكل كلمة Incidence Vector (مثلاً سطر Caesar هو: 110111).

To answer query: take the vectors for Brutus, Caesar and Calpurnia (complemented) → bitwise AND. عشان نجاوب السؤال، بنعمل عملية "منطقية" بسيطة:

1. بنجيب الـ Vector تبع بروتس (Brutus).
2. بنجيب الـ Vector تبع قيصر (Caesar).
3. بنجيب الـ Vector تبع كالبورنيا (Calpurnia) وبنقلبه (الواحد بتصير صفر والصفر بتصير واحد) وده اللي بنسميه Complement.
4. بنعمل عملية AND لهم كلهم.

VECTOR MATH
// Vector Math from Slide:

                1 1 0 1 0 0 (Brutus)AND

                1 1 0 1 1 1 (Caesar)AND

                1 0 1 1 1 1 (NOT Calpurnia - 010000 flipped)
1 0 0 1 0 0 (Result)

Answers to query: النتيجة (100100) معناها إن المسرحيات رقم 1 ورقم 4 هي الجواب (Antony and Cleopatra & Hamlet).

📜 الاقتباسات الحرفية من المسرحيات:

• Antony and Cleopatra, Act III, Scene ii:
"...found Julius Caesar dead... found Brutus slain."

• Hamlet, Act III, Scene ii:
"I did enact Julius Caesar... Brutus killed me."

⚠️ 6. المجموعات الضخمة (Bigger Collections)

Consider N = 1 million documents, each with about 1000 words. بعد ما شفنا مثال شكسبير (اللي عنده كذا قليل)، خلينا نفكر المثال شوي للوقع الحقيقي اللي بنتعامل معه:

بعد ما حللنا مثال مسرحيات شكسبير (اللي عندنا فيهم 6 مسرحيات)، خلينا نتعامل مع أرقام واقعية:

• عدد المستندات: N = مليون مستند
• كل مستند فيه حوالي 1000 كلمة وسطياً

Avg 6 bytes/word including spaces/punctuation → 6GB of data in the documents. لو افترضنا إن الكلمة الواحدة (مع المسافات وعلامات الترقيم) بتاخد 6 بايت في المتوسط:

CALCULATION
// حساب حجم البيانات الأصلية:

                1,000,000 مستند × 1,000 كلمة × 6 بايت = 6 مليار
                    بايت

                = 6GB من النصوص الخام (Text)

Say there are M = 500K distinct terms among these. من وسط كل هالكلمات (مليار كلمة)، لو افترضنا إن الكلمات الفريدة (اللي ما بتتكرر) هي M = نصف مليون كلمة (يعني الـ Vocabulary).

🚫 7. ليش ما بنقدر نبني المصفوفة؟ (Can't Build the Matrix)

500K × 1M matrix has half-a-trillion 0's and 1's. لو حاولنا نعمل مصفوفة تواجد (Incidence Matrix) لهالبيانات، بنضطر نبني جدول بالحجم التالي:

MATRIX SIZE
// حجم المصفوفة:

                500,000 كلمة (صفوف) × 1,000,000 مستند (أعمدة)

                = نصف تريليون خلية (500 مليار
                    خلية)!

// لو كل خلية بتاخد 1 بايت بس:

                500,000,000,000 بايت = ~500 GB 😱

💡 المشكلة: لو حاولنا نعمل مصفوفة لكتكسبير (Incidence Matrix) لهالبيانات الضخمة، رح يحتاج مستحيل كمبيوتر يقدر يحجز مساحة لهيك جدول ضخم. لهيك مارح نقدر نستخدم هالطريقة!

But it has no more than one billion 1's. العجيب إنها بتعرف إنه المصفوفة هاي مارح يكون فيها أكثر من مليار واحد (1) فقط!

ليش؟ لأنه إحنا عندنا مليار كلمة إجمالي (1M مستند × 1000 كلمة)، وكل كلمة رح تحط "1" في خلية واحدة بس. يعني من أصل 500 مليار خلية، بس مليار خلية فيها "1"، والباقي (499 مليار) كلهم أصفار! 🤯

Why? Matrix is extremely sparse. هاي بنسميها Sparse Matrix (مصفوفة هشة/متفرقة):

99.8%

من المصفوفة أصفار

0.2%

بس فيها "1"

يعني بنضيع مئات الجيجابايتات عشان نخزن أصفار ما إلنا داعي فيها!

What's a better representation? We only record the 1 positions. 🎯 الحل الذكي: بدل ما نخزن المصفوفة الكاملة، بنسجل بس الأماكن اللي فيها "1"!

الحل الذكي: بنسجل بس الأماكن اللي فيها "1". أي في مش مستطيله بنعرف أوتوماتيكاً إن "0". هاي هي التمهيد للفهرس المقلوب (Inverted Index). هاي هو التمهيد للـ Inverted Index اللي رح نشوفه بالصفحة الجاية!

📖 8. الفهرس المقلوب (Inverted Index)

For each term t, we must store a list of all documents that contain t. هاي هو جوهر الـ IR الحديث. بدل ما ندور في كل الملفات عن الكلمة، بنعمل "فهرس" عن الطلقة. بنخزن قائمة بكل المستندات اللي ذكرت فيها هاي الكلمة.

Identify each doc by a docID, a document serial number. عشان نوفر مساحة وما نكرر أسماء الملفات الطويلة، بنعطي لكل مستند رقم تعريف فريد بنسميه docID (زي رقم تسلسلي).

Can we used fixed-size arrays for this? هل بنقدر نستخدم مصفوفات ثابتة الحجم (fixed-size arrays) لتخزين هاليانات؟

Brutus ➔ 1 2 4 11 31 45 173 174

Caesar ➔ 1 2 4 5 6 16 57 132

Calpurnia ➔ 2 31 54 101

What happens if the word Caesar is added to document 14? ⚠️ المشكلة: لو استخدمنا Fixed-size array، وأضفنا كلمة جديدة (مثلاً رقم 14)، رح نضطر نعيد ترتيب المصفوفة بالكامل ونحجز مساحة جديدة. هاي عملية بطيئة ومكلفة!

🔗 9. تفاصيل الـ Inverted Index

We need variable-size postings lists. بما إن لستة المستندات ممكن تطول أو تقصر، بنحتاج Postings Lists بحجم متغير.

On disk, a continuous run of postings is normal and best. على الهارد ديسك، الأفضل نخزن ورا بعض (Continuous) عشان السرعة.

In memory, can use linked lists or variable length arrays. في الرام (In memory)، بنستخدم Linked Lists (عشان سهولة الإضافة) أو Variable length arrays.

Dictionary

Brutus

Caesar

Calpurnia

→

Postings

1 2 4 11 31 45 173 174

1 2 4 5 6 16 57 132

2 31 54 101

هيك بنكون "عكسنا" المصفوفة: بدل ما نروح من المستند للكلمات، بنروح من الكلمة للمستندات (لهيك اسمه Inverted).

🏗️ 10. بناء الفهرس المقلوب (Construction)

هاي السلايد بتحكي عن الـ "Pipeline" أو الـ "خط الإنتاج" اللي بنتبعى عشان نحول من جزء ملفات نصية لفهرس مرتب وجاهز للبحث.

1. Documents to be indexed المرحلة الأولى: البداية هي الملفات الأصلية النصية زي جملة مثلاً: "Friends, Romans, countrymen."

Tokenizer (Token stream) الـ "المقطّع": بيمسك الجملة وبيقطعها لكلمات منفصلة بنسميها "Tokens":
[Friends] | [Romans] | [Countrymen]

Linguistic modules (Modified tokens) هون الشغل الحقيقي لغوياً: بنعمل أشياء مثل:
• Lowercase: تحويل كل الأحرف لصغيرة.
• Stemming: إرجاع الكلمة لأصلها (حذف الـ s مثلاً).
النتيجة كلمات "معدّلة": [friend] | [roman] | [countryman]

Indexer (Inverted index) المرحلة الأخيرة: بناء الفهرس. بناخد الكلمات المعدّلة وبنربطها بأرقام المستندات اللي ظهرت فيها:

FINAL INDEX

                friend → 1 → 4

                roman → 1 → 2

                countryman → 13 → 16

🔧 11. المراحل الأولية لمعالجة النصوص

قبل ما نبني الفهرس وندخن البيانات، لازم نمر بمراحل "تنظيف وتحضير" عشان يكون جاهز للبحث. هاي بنسميها "Text Processing".

• Tokenization: Cut character sequence into word tokens 1. التقطيع (Tokenization):
المرحلة الأولى هي تقطيع سلسلة الحروف لكلمات منفصلة ("Tokens").

مثال: التعامل مع "John's"

                    الحكي ما يكون في التفاصيل مثل: هل "John's" والكلمات المركبة مثل "state-of-the-art" هل نعتبرهم كلمة
                    واحدة ولا كلمتين؟ هاي قرار تقني مهم.
                

• Normalization: Map text and query term to same form 2. التوحيد (Normalization):
الهدف هو توحيد شكل الكلمات في النص وفي سؤال المستخدم (Query) عشان يتطابقوا.

مثال: You want U.S.A and USA to match

                    لو المستخدم بكتب "U.S.A" لازم يلاقي كل المستندات اللي فيها "USA" (بدون نقاط)، يعني بنطبق نفس
                    "التنظيف" على الاثنين.
                

• Stemming: We may wish different forms of a root to match 3. الاشتقاق (Stemming):
إرجاع الكلمة لأصلها (الجذر) بحيث نعتبر كل صيغ نفس النتيجة.

مثال: authorize, authorization

                    لو المستخدم بحث بكلمة "authorization"، بدنا السيستم يطلع بالمستندات اللي فيها "authorize" بردو،
                    لأنهم من نفس النتيجة.
                

• Stop words: We may omit very common words (or not) 4. كلمات التوقف (Stop Words):
الكلمات "المملة" جداً واللي ما بتضيف معنى بحثي حقيقة ممكن نحذفها لتوفير المساحة.

مثال: the, a, to, of

                    كلمات مثل "the" أو "a" موجودة في كل مكان، فمافيش داعي نخزن الملايين (لاحظة: الموضوع فيه خلاف، لأنه
                    في استعلامات بتحتاجهم).
                

📝 12. خطوات عمل الـ Indexer (بالتفصيل)

Indexer steps: Token sequence بعد ما خلصنا الـ Processing، الـ Indexer بيبلش يشتغل. أول خطوة هي إن يجمع كل لستة (Modified token, Document ID) pairs.

Sequence of (Modified token, Document ID) pairs. بعد ما خلصنا الـ Processing، الـ Indexer بيبلش يشتغل. أول خطوة هي إن يجمع كل لستة زوج مرتب (الكلمة، رقم المستند). هاي مثال عملي من السلايدات:

Doc 1

"I did enact Julius Caesar I was killed i' the Capitol; Brutus killed me."

Doc 2

"So let it be with Caesar. The noble Brutus hath told you Caesar was ambitious"

🔄 13. الترتيب (Sort by Terms)

Sort by terms (At least conceptually) and then docID هاي هو "القلب النابض" للعملية ("Core indexing step"). بنرتب القائمة اللي عطاها أبجدياً حسب الكلمات.

ليش بنرتب؟ عشان كل الكلمات المتشابهة يجوا تحت بعض، وهيك بصير سهل علينا حداً لدمجها ونعرف وين تكررت.
بدون ما نلف على كل الداتا كل مرة.

Term	docID
ambitious	2
brutus	1
brutus	2
caesar	1
caesar	2
...	...

📚 14. القاموس والقوائم (Dictionary & Postings)

• Multiple term entries in a single document are merged. لو الكلمة تكررت بنفس المستند (زي تكرر في مستند 2)، ما بنخزن رقم المستند مرتين. بنعمل "Merge" عشان نوفر مساحة.

• Split into Dictionary and Postings هون بنفصل الشغل لزبطين: القاموس ("Dictionary") اللي فيه الكلمات ومعلوماتها، والقوائم الطويلة ("Postings") اللي فيها أرقام المستندات.

• Doc. frequency information is added. بنضيف معلومة إضافية مهمة جداً بنسميها الـ "Document Frequency". هاي بتحكيلنا: "كم مستند في فيه هاي الكلمة؟" (مش كم مرة تكررت، بس كم مستند).

Dictionary Entry (Term | Freq)

ambitious 1

brutus 2

caesar 2

mercy 3

→

Postings Lists

2

1 2

1 2 5

Where do we pay in storage? 🤔 وين بندفع في المساحة؟ لازم نفهم إن الداتا مقسومة بشكل من 3 أجزاء رئيسية:

Lists of docIDs

هاي هو الـ "Postings" وهو اللي بياخد أكبر مساحة لأنه بيحتوي على أرقام المستندات.

Pointers

الأسهم اللي بتربط كل كلمة في القاموس مع بداية لستة الـ Postings. بياخد مساحة متوسطة.

Terms and counts

هاي هو الـ "Dictionary" بيخزن فيه الكلمات وعدد تكراراتها.

� 15. معالجة الاستعلامات (Query Processing: AND)

Query processing: AND بعد ما بنينا الفهرس، صار وقت البحث! لو المستخدم طلب مستندات فيها الكلمتين مع بعض ("AND")، كيف الجهاز بيلاقي عليهم؟ هاي هو التسلسل:

Consider the query: **Brutus AND Caesar** صار وقت البحث، لو المستخدم طلب مستندات فيها الكلمتين مع بعض (AND)، كيف الجهاز بيلاقي عليهم؟ هاي هو التسلسل:

1. Locate Brutus in the Dictionary: Retrieve its postings. الخطوة 1: بندور على كلمة Brutus في القاموس ونجيب لستة الـ Postings تبعتها.

2. Locate Caesar in the Dictionary: Retrieve its postings. الخطوة 2: نفس الشي، لكن هالمرة للكلمة الثانية Caesar.

3. "Merge" the two postings (intersect the document sets). الخطوة 3: بندمج اللستتين مع بعض ونطلع بس "التقاطع" (الأرقام الموجودة في التنتين).

Brutus

2 → 4 → 8 → 16 → 32 → 64 → 128

Caesar

1 → 2 → 3 → 5 → 8 → 16 → 21

النتائج المشتركة

2 8 16

💡 الأرقام المشتركة (2, 8, 16) هي المستندات اللي فيها Brutus AND Caesar مع بعض!

🔄 13. خوارزمية الدمج (The Merge Algorithm)

How to efficiently solve AND queries? Intersect postings. عشان نحل عملية AND بذكاء، بدل ما نبحث في كل الملفات، بنعمل دمج (Merge) للقوائم.

Time Complexity: O(x + y) where x, y are list lengths. الوقت المطلوب هو خطي (Linear Time)، يعني بنمشي مرة وحدة بس على القوائم. هاض هو سر سرعة محركات البحث.

الفكرة الأساسية:
بنمشي بـ Pointers (مؤشرات) على القائمتين في نفس الوقت:
1. لو الأرقام تساوت ➔ Match Found! بنسجل الرقم وبنمشي المؤشرين.
2. لو رقم أصغر من الثاني ➔ بنمشي مؤشر القائمة الأصغر خطوة لقدام.

🎯 14. مفهوم الدمج بصرياً (Visual Merge)

تخيل عندك قائمتين مرتبتين، وبدك تطلع الأرقام المشتركة بينهم:

Brutus:

2 4 8 16 32

Caesar:

1 2 3 5 8 16

النتيجة:

2 8 16

⚡ 15. تحسين الاستعلامات (Query Optimization)

What if we have multiple terms in a query? لو عندنا أكثر من كلمتين في الاستعلام، كيف بنحسّن الأداء؟

القاعدة الذهبية: ابدأ بأصغر قائمة!

لو عندك استعلام: Brutus AND Caesar AND Calpurnia
بدل ما تدمج بالترتيب، رتب القوائم من الأصغر للأكبر:

                    ✓ Smart: Start with smallest list (Calpurnia: 3
                    docs)

                    ✗ Slow: Start with largest list (Caesar: 1000 docs)
                

💡 كل ما القائمة أصغر، كل ما الدمج أسرع. هاي استراتيجية بسيطة بس بتوفر وقت كثير!

💻 14. كود الخوارزمية (Intersect Algorithm)

PSEUDOCODE
INTERSECT(p1, p2):

                  answer = []
while p1 != nil and p2 != nil:
if docID(p1) == docID(p2):

                      ADD(answer, docID(p1))

                      p1 = next(p1)

                      p2 = next(p2)
else if docID(p1) < docID(p2):

                          p1 = next(p1)
else:

                          p2 = next(p2)
return answer
            

ببساطة:
• إذا الرقمين تساووا: سجل الرقم وحرك المؤشرين من الاثنين.
• إذا واحد أصغر: حرك المؤشر تبعه بس عشان نلحق بالثاني.

📊 16. مثال خطوة بخطوة (Step-by-Step)

هاي مثال شامل يوضحلك كيف الخوارزمية بتمشي خطوة بخطوة بين لستتين:

                    p1 = [1, 3, 5, 7, 9, 11]

                    p2 = [2, 3, 6, 7, 10, 11]

Step	Pointer in p1	Pointer in p2	Comparison	Action Taken
1	1	2	1 < 2	Move p1
2	3	2	3 > 2	Move p2
3	3	3	Match!	Add 3, Move both
4	5	6	5 < 6	Move p1
5	7	6	7 > 6	Move p2
6	7	7	Match!	Add 7, Move both
7	9	10	9 < 10	Move p1
8	11	10	11 > 10	Move p2
9	11	11	Match!	Add 11, Move both

Final Answer: [3, 7, 11]

🧠 15. العمليات المنطقية المعقدة (OR / NOT)

كيف بنحل الـ OR والـ NOT؟

OR (Union): Merge lists and take ALL unique IDs. الإتحاد (OR): بنمشي على القائمتين وبناخد أي رقم بنشوفه بأي لستة (مع عدم التكرار).

NOT (Complement): Take IDs NOT in the list. النفي (NOT): هاض أصعب شوي، لازم نمشي على لستة المستندات "الكلية" ونشيل منها الأرقام الموجودة في لستة الكلمة المنفية.

تنبيه: عملية المستندات (NOT) ممكن تطلع نتائج مرعبة إذا ما تقيدت بـ AND (مثلاً: ابحث عن كل شي "مش قيصر"). عشان هيك الـ Boolean Model كلاسيكي جداً وصارم.

⚡ 14. تحسين الاستعلامات (Query Optimization)

What is the best order for query processing? لما يكون عندك استعلام فيه أكثر من كلمة مربوطين بـ **AND**، الترتيب اللي بتنفذ فيه العمليات بفرق كثير في السرعة. هاض هو "التحسين".

Core Rule: **Process in order of increasing freq**

القاعدة الذهبية: **بلش دايماً من أصغر قائمة (أقل تكرار).**
ليش؟ عشان النتيجة الوسيطة (Intermediate result) تصل صغيرة قدر الإمكان، وما تتعب المعالج بدمج قوائم ضخمة على الفاضي.

هاض هو السبب إنه بنحتفظ بالـ **document freq** في القاموس (Dictionary) مخصوص عشان السرعة. بقدر بسرعة أعرف الترتيب الصح قبل ما بدأ عملية الدمج.

📊 15. مثال التحسين (Optimization Example)

**Brutus AND Calpurnia AND Caesar**

الترتيب الأمثل للتنفيذ هو: **(Calpurnia AND Brutus) AND Caesar**

بنبدأ بـ Calpurnia لأن عالمة الـ Postings بتبعها أصغر في (فيها بس رقمين). وهيك بنضمن إن أصغر كمية بيانات هي اللي بتمشي في المعالجة.

تتبع التنفيذ خطوة بخطوة:

الخطوة 1: (Calpurnia AND Brutus)
بنقاطع قائمة Calpurnia {13, 16} مع قائمة Brutus {2, 4, 8, 16, 32, 64, 128}
Result 1 = {16} ← الرقم المشترك الوحيد هو **16**

الخطوة 2: (Result 1 AND Caesar)
هسا بنقاطع النتيجة اللي طلعت معنا {16} مع قائمة Caesar {1, 2, 3, 5, 8, 16, 21, 34}
برضه الرقم المشترك الوحيد هو **16**

النتيجة النهائية للاستعلام: {16}

🎯 16. تحسين عام (More general optimization)

طيب، كيف بترتب الأمور لو كان الاستعلام فيه عمليات **OR** حوالي الـ **AND**؟ مثلاً:

(madding OR crowd) AND (ignoble OR strife)

القاعدة بتصل نفسها: **بس بنس كيف بنقدر حجم كل مش كلمة واحدة؟**

1. Get doc. freq.'s for all terms.

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

2. Estimate the size of each OR by the sum of its doc. freq.'s.

بنقدر حجم كل قوس (**OR**) عن طريق "جمع" تكرارات الكلمات اللي جواته. (عملية الإيجاد مستحيل تتعدى المجموع).

3. Process in increasing order of OR sizes.

بنرتب الأقواس من اللي مجموعه أصغر للي مجموعه أكبر ونبدأ الـ AND بينهم.

مثال بالأرقام عشان توضح الصورة:

                    تخيل السرعة كانت التكرارات كالتالي:

                    • madding: 50 | crowd: 100 → (Sum = 150)

                    • ignoble: 20 | strife: 30 → (Sum = 50)

القرار السريع رح بنفذ القوس الثاني (ignoble OR strife) بيطلعه مع القوس الأول. هيك بنضمن دايماً من "الأصغر للأكبر" عشان توفر وقت.

📋 17. النموذج المنطقي (Boolean Retrieval Model)

Boolean queries: Exact match هاض الموديل هو الأب الروحي لأنظمة البحث. الفكرة بسيطة إنك بتبني استعلام (Query) عبارة عن تعبير منطقي.

• Boolean Queries use AND, OR and NOT to join query terms.

بنستخدم العمليات المنطقية AND, OR, NOT عشان نربط بين الكلمات.

• Views each document as a set of words.

الموديل بيشوف كل مستند كأنه "مجموعة" من الكلمات، ما بيهمه الترتيب ولا تكرار الكلمة، الهم إنها موجودة أو لا.

• Is precise: document matches condition or not.

هاض الموديل "دقيق جداً" ما المستند: يطابق الشرط بالضبط يا لا، ما فيه "تقريبة" أو "شبهه".

📚 18. السياق التاريخي (Historical Context)

ليش مهم ندرسه؟

• كان هو الأداة التجارية الأساسية للبحث لمدة **3** عقود** (30 سنة).

• كثير أنظمة بحث بتستخدمها لحتى اليوم، مثل:

                    - **Email** لما بدك تدور على ايميل "من فلان" و "عن موضوع
                    كذا".

                    - **Library catalog** فهارس المكتبات الضخمة.

                    - **macOS Spotlight** ميزة البحث السريع في الـ Mac.

ملاحظة: هاض هو أبسط موديل (Simplest model) ممكن تبني عليه نظام IR.

🧩 19. مثال معقد (Complex Logical Query)

أحياناً الاستعلام بيكون أعقد ويحتوي على أكثر من عملية مع بعض. هاض مثال شامل من السلايدات يوضح كيف بتحل استعلام زي هاض:

(Brutus OR Caesar) AND NOT Calpurnia

القوائم المتاحة:

Postings lists:

                • Brutus = {1, 2, 4, 5, 8}

                • Caesar = {2, 3, 5, 6, 8, 9}

                • Calpurnia = {2, 5, 10}

                • All Docs = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}

Step 1: Compute Brutus OR Caesar (Union)

عملية الـ **OR** يعني إيجاد: نجمع كل الأرقام الموجودة في اللستتين بدون تكرار.

                    Result = {1, 2, 3, 4, 5, 6, 8, 9}
                

Step 2: Compute NOT Calpurnia (Complement)

عملية الـ **NOT** يعني "النفي": ناخد كل المستندات الموجودة في السيستم **ما عدا** اللي فيها Calpurnia.

                    Result = {1, 3, 4, 6, 7, 9}
                

Step 3: Intersect the results (AND)

بعد أخر خطوة وهي الـ **AND** يعني نطلع بس: نتيجة الخطوة الأولى والثانية عشان نطلع الأرقام المشتركة بس.

                    Final Result = {1, 3, 4, 6, 9}
                

هاض المثال يوضحلك كيف العمليات المنطقية بتتشغل مع بعض في الواقع العملي!

🚀 20. النماذج المنطقية المطورة (Extended Boolean)

Extended Boolean retrieval models النماذج المطورة بتضيف أدوات جديدة فوق الـ AND, OR التقليديين، وأهم هاي الأدوات هو **معامل القرب (Proximity Operator)**.

What is a Proximity Operator?

هو وسيلة بنحدد فيها إن الكلمتين لازم يكونوا **قراب من بعض** في المستند عشان نعتبر إن البحث ناجح. مش بس موجودين في نفس الملف، لا، لازم "المسافة" بينهم تكون صغيرة.

📏 21. كيف بنقيس "القرب"؟ (Measuring Closeness)

• By number of words (Distance) بعدد الكلمات الفاصلة: يعني بنحدد عدد مسموح من الكلمات بينهم بس.

                مثال: Apple /3 Banana ➔ يعني لازم تلاقي الكلمتين وبينهم 3 كلمات كحد أقصى.
            

• By structural units (Same sentence/paragraph) بوحدات هيكلية: يعني نحدد إن الكلمتين لازم يكونوا في نفس الوحدة.

                مثال: Justice /s Peace ➔ يعني في نفس الجملة (Sentence).

                أو: Justice /p Peace ➔ يعني في نفس الفقرة (Paragraph).

⚖️ 22. قواعد WestLaw (General Rules)

نظام **WestLaw** هو أكبر خدمة بحث قانوني تجاري في العالم (بدأت من 1975). هاي هي القواعد العامة للاستعلامات فيه:

Operator	Type	Meaning / Explanation	Example
!	Wildcard	بلاقي الكلمات اللي الها نفس الجذر.	disab! (disabled, disability)
/s	Proximity	الكلمات لازم تكون في نفس الجملة.	law /s enforcement
/p	Proximity	الكلمات لازم تكون في نفس الفقرة.	host /p responsib!
/n	Proximity	مسافة n من الكلمات بينهم.	employment /3 place
()	Grouping	بجمع الكلمات المترابطة مع بعض.	(responsib! liab!)
(space)	Implicit OR	تلقائياً بيعتبر الفراغ هو OR.	work-site work-place

🔍 مثال 1: متطلبات الوصول لذوي الإعاقة

                disab! /p access! /s work-site work-place (employment /3
                    place)
            

المعامل	الشرح
disab!	بجيب أي كلمة بتبلش بـ disab مثل (disabled, disability).
/p	بيضمن إن "disab!" و "access!" يظهروا في نفس الفقرة.
/s	بيضمن إن "access!" تظهر في نفس الجملة مع "work-site" أو "work-place".

🍺 مثال 2: مسؤولية المضيف عن الضيوف المخمورين

host! /p (responsib! liab!) /p (intoxicat! drunk!) /p guest

ببحث عن كلمة بتبلش بـ host، وفي نفس فقرتها المسؤولية (responsib أو liab)، وفي نفس الفقرة كلمات السكر، وبالنهاية كلمة guest.

مثال تطبيقي (كيف المحرك بيشوف الفقرة):

The court found that the host bears full responsibility for the accident. The evidence showed that multiple guests were clearly drunk, reaching a state of intoxication that establishes strict liability.

💡 ليش هاي الفقرة رح تطلع في النتائج؟
لأن كل جزء في الاستعلام لقى كلمة بتناسبه بنفس الفقرة، وكل الشروط تحققت (موجود host, guest, drunk, liability).

📝 16. الخلاصة (Summary)

Summary: Boolean Retrieval Model

بشكل عام، هاض النموذج هو أبسط وأقدم النماذج في علم استرجاع المعلومات، ويضل هو الأساس لأي نظام بحث.

🔹 المميزات (Pros)

• Very efficiently implemented: التنفيذ البرمجي لـ هاض النموذج سريع جداً وما بياخد موارد كبيرة.
• Predictable, easy to explain: النتائج متوقعة، وسهل تشرح لليوزر ليش هاض الملف طلعله.
• Structured queries: بدعم الاستعلامات المنظمة اللي فيها شروط دقيقة.
• Works well for experts: ممتاز لما يكون الباحث عارف شو اللي بده اياه بالضبط.

🔸 العيوب (Cons)

• Binary decision: النظام يا أبيض يا أسود: يا المستند بحقق الشرط أو ما بحققه.
• No ranking: ما في ترتيب للنتائج، الكل اله نفس الدرجة.
• Complex for average users: صعبة على اليوزر العادي، وبيشوفها معقدة.
• Simplistic queries: أغلب الناس بتكتب استعلامات بسيطة ما بتستفيد منه.
• Feast or Famine: يا بيطلعلك نتائج هائلة بتضيع فيها، يا ما بيطلعلك ولا شي.

💡 :الرسالة الأخيرة

تذكر دايماً.. الـ **Inverted Index** هو القلب النابض لأي محرك بحث، وبدونه مستحيل نقدر نبحث في ملايين النصوص خلال أجزاء من الثانية!

🏁 الخاتمة (Conclusion)

بهيك بنكون خلصنا أساسيات الـ Boolean Retrieval.
الموضوع الجاي رح يكون عن الـ Ranked Retrieval وكيف بنرتب النتائج.

QudahWay