Vector Space Model | Study Guide

🎯 01. Ranked Retrieval (Detailed Breakdown)

Thus far, our queries have all been Boolean.

لغاية اللحظة هاي، كل اللي درسناه كان بيعتمد على الـ **Boolean queries**؛ يعني إما (موجود) أو (غير موجود).

Documents either match or don’t.

هون ما في حل وسط؛ الملف يا بحقق الشرط كامل وبطلع بالنتائج، يا ما بحققه وبختفي.

Good for expert users with precise understanding of their needs and the collection.

هاض الأسلوب ممتاز للناس الـ Expert (الخبراء)؛ اللي عارفين بالضبط شو الكلمات اللي بدهم إياها وعارفين كيف يركبوها مع بعض.

Also good for applications: Applications can easily consume 1000s of results.

كمان ممتاز للبرامج والتطبيقات؛ لأن الكمبيوتر ما عنده مشكلة يقرأ 1000 نتيجة ويحللهم بسرعة البرق.

Not good for the majority of users.

بس المشكلة الحقيقية وين؟ إنه هاد النظام فاشل مع أغلب المستخدمين العاديين.

Most users incapable of writing Boolean queries (or they think it’s too much work).

أغلب الناس ما بيعرفوا يكتبوا `AND` و `OR` و `NOT` بتعقيد، وحتى لو بيعرفوا، بيحسوا إنه الموضوع "غلبة" وبدهم طريقة أسهل.

Most users don’t want to wade through 1000s of results (particularly true of web search).

ما في حدا فينا بدخل على جوجل وبقعد يقلب بـ 1000 صفحة؛ إحنا بدنا "الزبدة" تطلع بأول 5 نتائج.

⛈️ 02. Problem with Boolean search: feast or famine

Boolean queries often result in either too few (=0) or too many (1000s) results.

هاي هي المشكلة الأشهر: يا بتطلع لك غابة من النتائج (Feast) وما بتلاقي حالك، يا بتطلع لك صحراء ناشفة (Famine) بصفر نتائج.

[ EXAMPLE CASE STUDY ]

Query 1: "standard user dlink 650" ➔ 200,000 hits

Query 2: "standard user dlink 650 no card found" ➔ 0 hits

It takes a lot of skill to come up with a query that produces a manageable number of hits.

عشان تطلع "عدد معقول" من النتائج، لازم تكون فنان في صياغة الاستعلام، وهذا صعب على الكل.

AND gives too few; OR gives too many.

قاعدة ذهبية: الـ AND بتصعّب الشروط فبطلع نتائج قليلة، والـ OR بتسهلها فبطلع نتائج مبالغ فيها.

📈 03. Ranked Retrieval Models & Solutions

🧠 03. Ranked Retrieval Models

Rather than a set of documents satisfying a query expression, in ranked retrieval, the system returns an ordering over the (top) documents in the collection for a query.

بدلاً من إرجاع "مجموعة" من الملفات اللي بس بتحقق الشرط (زي الـ Boolean)، نظام الـ **Ranked Retrieval** برجع لك "ترتيب" (Ordering) لأفضل الملفات في المكتبة بالنسبة لسؤالك.

Free text queries: Rather than a query language of operators and expressions, the user’s query is just one or more words in a human language.

**استعلامات النص الحر (Free Text):** هون المستخدم مش مضطر يتعلم لغة برمجة أو يحط `AND/OR`. كل اللي عليه يكتب كلمات عادية بلغة البشر (زي ما بتعمل بجوجل)، والسيستم بفهمها.

In principle, there are two separate choices here, but in practice, ranked retrieval has normally been associated with free text queries and vice versa.

من الناحية النظرية، "طريقة البحث" و "طريقة كتابة السؤال" شيئين منفصلين، بس فعلياً وبالتطبيق العملي، الـ **Ranked Retrieval** دايماً مرتبط بالـ **Free Text Queries**؛ يعني الاثنين صاروا وجهين لعملة واحدة.

🛡️ 04. Feast or Famine: NOT a problem here!

When a system produces a ranked result set, large result sets are not an issue.

لما السيستم يعطيك نتائج "مرتبة"، بطلت كثرة النتائج مشكلة! ليش؟

Indeed, the size of the result set is not an issue. We just show the top k (≈ 10) results.

الحجم مش مهم، إحنا بس بنعرض للمستخدم أول k نتيجة (مثلاً أفضل 10 نتائج)، والباقي بكون موجود بس مش طاوش المتصفح فيهن.

We don’t overwhelm the user.

هيك إحنا بنحمي المستخدم من إنه "ينعجق" أو يغرق بآلاف المعلومات غير المفيدة.

Premise: the ranking algorithm works.

**الافتراض الأساسي:** طبعاً كل هاض الحكي بفترض إن "خوارزمية الترتيب" شاطرة وعارفة فعلاً شو هي أفضل النتائج عشان تحطها فوق.

⚖️ 05. Scoring: The Basis of Ranking

We wish to return in order the documents most likely to be useful to the searcher.

هدفنا الأساسي هو ترتيب الملفات حسب "منفعتها" للمستخدم؛ يعني اللي بيفيده أكثر بطلع فوق.

How can we rank-order the documents in the collection with respect to a query?

**السؤال الجوهري:** كيف ممكن أرتب آلاف الملفات بالنسبة لسؤال (Query) معين؟ كيف أعرف مين أهم من مين؟

Assign a score – say in [0, 1] – to each document. This score measures how well document and query "match".

**الحل:** نعطي "علامة" (Score) لكل ملف، غالباً بتكون بين 0 و 1. هاي العلامة هي مقياس لقديش الملف والـ Query "متطابقين" أو راكبين على بعض.

📏 06. Take 1: Jaccard Coefficient

A common measure of overlap of two sets A and B.

أول فكرة لحساب العلامة هي "معامل جاكارد" (Jaccard)؛ وهو ببساطة بقيس "التداخل" أو "التشابه" بين مجموعتين.

jaccard(A, B) = |A ∩ B| / |A ∪ B|

(التقاطع ÷ الاتحاد) = (المشترك ÷ كل العناصر بدون تكرار)

✔ jaccard(A, A) = 1 (Match 100%)

✘ jaccard(A, B) = 0 if A ∩ B = 0

📍 ملاحظة: المجموعات مش شرط تكون بنفس الحجم، والنتيجة دايماً بتطلع رقم بين 0 و 1.

📝 Example: Computing Jaccard Score

Query: ides of march
Document 1: caesar died in march
Document 2: the long march

خلينا نحسبها مع بعض:

- **للملف الأول:** المشترك بس كلمة واحدة (march). المجموع الكلي للكلمات الفريدة هو (ides, of, march, caesar, died, in) يعني 6 كلمات.
النتيجة: 1 / 6 = 0.166

- **للملف الثاني:** المشترك برضو بس (march). المجموع الكلي هو (ides, of, march, the, long) يعني 5 كلمات.
النتيجة: 1 / 5 = 0.2

⚠️ 07. Issues with Jaccard for scoring

It doesn’t consider term frequency (how many times a term occurs in a document).

**مشكلة التكرار:** جاكارد ما بهمه قديش تكررت الكلمة؛ يعني لو ملف فيه كلمة "march" مرة واحدة، وملف ثاني فيه كلمة "march" مية مرة، جاكارد بعطيهن نفس الأهمية (لأنه بشوف بس هي موجودة أو لأ).

Rare terms in a collection are more informative than frequent terms. Jaccard doesn’t consider this information.

**مشكلة الكلمات النادرة:** بالمنطق، الكلمة النادرة (زي "ides") بتدل على موضوع الملف أكثر من الكلمات العامة (زي "in"). جاكارد ما عنده "ميزان" يفرق بينهم؛ الكل عنده سواسية.

We need a more sophisticated way of normalizing for length.

**مشكلة طول الملف:** إحنا محتاجين طريقة أذكى وأكثر تعقيداً عشان "نوازن" بين الملفات الطويلة والقصيرة (Normalizing for length)، مش بس قسمة بسيطة على الاتحاد.

🎯 08. Towards better Scoring (One-term query)

لحتى نلاقي حل أحسن، خلينا نفكر ببحث بكلمة واحدة (One-term query) ونحدد شروطنا:

1. If the query term does not occur in the document: score should be 0

منطقياً، إذا الكلمة مش موجودة أبداً بالملف، علامته لازم تكون "صفر".

2. The more frequent the query term in the document, the higher the score (should be).

كل ما تكررت الكلمة أكثر، لازم علامة الملف "ترتفع". هاد هو أساس الـ **Term Frequency** اللي رح ندرسه.

We will look at a number of alternatives for this.

عشان نحقق هاي الشروط، رح ندرس كذا طريقة بديلة عن جاكارد تكون أعدل وأدق.

🔄 Recall: Binary Term-Document Matrix

Each document is represented by a binary vector ∈ {0, 1}^|V|

تذكروا من الشباتر الماضية، كنا نمثل كل ملف كـ **Binary Vector** (سهم من الأصفار والوحدات). يا الكلمة موجودة (1) يا مش موجودة (0).

Term	Antony & Cleo	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

📊 Evolution: Term-Document Count Matrices

Consider the number of occurrences of a term in a document. Each document is a count vector.

التطور الجديد: بدل ما نسجل بس "موجود أو لأ"، صرنا نسجل **عدد تكرارات** الكلمة (Count). هيك الملف بصير عبارة عن **Count Vector**.

Term	Antony & Cleo	Julius Caesar	The Tempest	Hamlet	Othello	Macbeth
Antony	157	73	0	0	0	0
Brutus	4	157	0	1	0	0
Caesar	232	227	0	2	1	1
Calpurnia	0	10	0	0	0	0
Cleopatra	57	0	0	0	0	0
mercy	2	0	3	5	5	1
worser	2	0	1	1	1	0

هون بلشنا الجد! الملف بطل مجرد "وحدات وأصفار"، صار اله **شخصية** بناءً على تكرار كل كلمة فيه.

👜 09. Bag of words model

Vector representation doesn’t consider the ordering of words in a document.

بنموذج الـ **Vectors**، إحنا ما بنهتم بترتيب الكلمات بالملف. الملف بالنسبة إلنا "كيس" كلمات!

"John is quicker than Mary"
"Mary is quicker than John"

الجملتين هذول الهن نفس الـ Vector بالظبط!

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

This is a step back: The positional index was able to distinguish these two documents.

**ملاحظة ذكية:** هاي تعتبر "خطوة لورا"؛ لأن الـ **Positional Index** اللي درسناه زمان كان بقدر يفرق بينهم، بس هون خسرنا هاي الميزة.

🔢 10. Term frequency (tf)

The term frequency tf_{t,d} of term t in document d is defined as the number of times that t occurs in d.

الـ **tf** هو ببساطة عدد مرات ظهور كلمة (t) في ملف (d).
(بمجال الـ IR، كلمة Frequency معناها Count - يعني "عدَد" مش "تردّد").

Raw term frequency is not what we want:

العدد الخام (Raw count) مش دايماً بكون عادل.
• ملف فيه الكلمة 10 مرات **أهم** من ملف فيه الكلمة مرة وحدة.
• بس هل هو أهم بـ **10 أضعاف**؟ أكيد لأ!

Relevance does not increase proportionally with tf.

📈 11. Log-frequency weighting

عشان نحل مشكلة الزيادة الكبيرة، بنستخدم الـ **Log** عشان "نهدّي" الأرقام:

w_t,d = 1 + log₁₀ tf_t,d (if tf > 0)

tf=1 ➔ w=1 tf=2 ➔ w=1.3 tf=10 ➔ w=2 tf=1000 ➔ w=4

Score = ∑_{t∈q∩d} (1 + log tf_{t,d})

العلامة النهائية للملف هي **مجموع** أوزان الكلمات المشتركة بينه وبين السؤال.
* إذا ما في ولا كلمة مشتركة، العلامة بتخلص بـ **صفر**.

📊 Rare Terms & idf weighting (Continued)

💎 12. Rare terms are more informative

Rare terms are more informative than frequent terms.

الكلمات النادرة دايماً بتعطي معلومة أدق عن محتوى الملف. تذكروا الـ **Stop words** (زي "the", "a")؛ هاي موجودة بكل مكان وما بتفيدنا بالتمييز.

"Consider a term like **arachnocentric**..."

لو دورت على كلمة غريبة زي "arachnocentric" (اللي بتخص العناكب)، ولقيتها في ملف، فبنسبة **100%** هاد الملف اله علاقة بموضوعك.

We want a high weight for rare terms.

📊 13. Collection vs. Document frequency

Collection Frequency (cf)

مجموع تكرار الكلمة في كل المكتبة (ظهورها الإجمالي).

Document Frequency (df)

عدد الملفات اللي ظهرت فيها الكلمة (لو مرة وحدة).

Word	Collection freq (cf)	Document freq (df)
insurance	10440	3997
try	10422	8760

🤔 **مين أحسن للبحث؟** كلمة (insurance) مجموعها زي (try) تقريباً، بس هي موجودة بملفات **أقل** (df أصغر)، يعني هي نادرة أكثر وبتعطي وزن أعلى!

⚖️ 14. idf weight (The Inverse Logic)

df_t is an inverse measure of the informativeness of t.

الـ **df** هو مقياس عكسي للأهمية؛ كل ما قل عدد الملفات اللي فيها الكلمة، زادت أهميتها.

idf_t = log₁₀(N / df_t)

N = Total number of documents in collection

We use log(N/df_t) instead of N/df_t to “dampen” the effect of idf.

ليش استخدمنا **log**؟ عشان "نهدّي" (Dampen) التأثير الناتج عن القسمة، وما يعطي وزن "انفجاري" للكلمات شديدة الندرة.

🔢 15. idf example (Suppose N = 1,000,000)

لو افترضنا إن مكتبتنا فيها **مليون ملف** (N = 10⁶)، شوف كيف الـ **idf** بيتغير حسب ندرة الكلمة:

Term	df_t	idf_t
calpurnia	1	6
animal	100	4
sunday	1,000	3
fly	10,000	2
under	100,000	1
the	1,000,000	0

✔ لاحظ: كلمة "the" موجودة بكل الملفات، فصار الـ **idf** تبعها صفر (يعني ما الها قيمة بالتمييز).

🎯 16. Effect of idf on ranking

One-term queries (e.g., "iPhone")

الـ **idf** ما بياثر على ترتيب النتائج لو كنت بتبحث عن **كلمة واحدة**. ليش؟ لأن العلامة رح تنضرب بنفس الرقم لكل الملفات، فالتريب بضل زي ما هو.

Multi-term queries (e.g., "capricious person")

هون الـ **idf** بطل الدوري! كلمة "capricious" نادرة جداً مقارنة بكلمة "person".
السيستم رح يعطي وزن "مرعب" لكلمة **capricious** وبخليها هي المتحكمة بالترتيب، لأنها هي اللي بتميز الملف فعلاً.

🚀 17. The Legendary: tf-idf weighting

The tf-idf weight of a term is the product of its tf weight and its idf weight.

وصلنا لأشهر نظام أوزان في تاريخ البحث: هو ببساطة حاصل **ضرب** وزن الـ **tf** في وزن الـ **idf**.

w_t,d = (1 + log tf_t,d) × log₁₀(N / df_t)

⭐ **ليش هو الأفضل؟**
1. بزيد كل ما زاد تكرار الكلمة في الملف (tf).
2. بزيد كل ما كانت الكلمة "نادرة" في كل المكتبة (idf).

📈 Scoring & Weight Matrices (Continued)

🎯 18. Score for a document given a query

Score(q,d) is the sum over terms t in both q and d.

العلامة النهائية للملف (d) مقارنة بالسؤال (q) هي حاصل **مجموع** أوزان الـ tf-idf لكل الكلمات المشتركة بينهم.

Score(q,d) = ∑_t∈q∩d tf.idf_t,d

ملاحظة: هناك أنواع (Variants) كثيرة لحساب الـ tf-idf، بتعتمد على:
• هل استخدمنا الـ **Log** في حساب الـ tf؟
• هل أعطينا أوزان للكلمات اللي في السؤال (Query) نفسه؟

🧱 19. Binary ➔ Count ➔ Weight Matrix

Each document is now represented by a real-valued vector of tf-idf weights ∈ R^|V|.

هون وصلنا للمرحلة النهائية في تمثيل البيانات: بطلت مصفوفة أصفار ووحدات، وصارت مصفوفة **أرقام حقيقية (Weights)** بتعبر عن قوة كل كلمة في كل ملف.

Term	Antony & Cleo	Julius Caesar	The Tempest	Hamlet	Othello	Macbeth
Antony	5.25	3.18	0	0	0	0.35
Brutus	1.21	6.1	0	1	0	0
Caesar	8.59	2.54	0	1.51	0.25	0
Calpurnia	0	1.54	0	0	0	0
Cleopatra	2.85	0	0	0	0	0
mercy	1.51	0	1.9	0.12	5.25	0.88
worser	1.37	0	0.11	4.15	0.25	1.95

💡 **الزبدة:** كل ملف صار عبارة عن سهم (Vector) من الأرقام الحقيقية في فضاء كبير جداً (R^|V|). هاي هي نواة الـ **Vector Space Model**.

📐 Documents & Queries as Vectors

🚀 20. Documents as vectors

Standard representation: |V|-dimensional vector space. Terms are axes of the space.

تخيل معي إن كل كلمة في اللغة هي **محور (Axis)** في فضاء ضخم جداً. الملف هون بصير عبارة عن **سهم أو نقطة** في هاض الفضاء.

High-dimensional

أبعاد خيالية! بمحركات البحث مثل Google، بنحكي عن **ملايين الأبعاد** (بعدد الكلمات).

Very Sparse

المتجهات "فاضية" (**Sparse**)؛ لأن الملف الواحد فيه كلمات معدودة مقارنة بملايين الكلمات باللغة.

🔍 21. Queries as vectors

Key idea 1: Do the same for queries: represent them as vectors in the space.

**الفكرة الجوهرية الأولى:** ليش ما نعامل "السؤال" زي ما بنعامل "الملف"؟
بنمثل السؤال بـ **Vector** (سهم) في نفس الفضاء اللي فيه الملفات. هيك بصير السؤال "نقطة" والمطالبة "نقطة" ثانية.

Key idea 2: Rank documents according to their proximity to the query in this space.

**الفكرة الجوهرية الثانية:** ترتيب الملفات (Ranking) بصير حسب **قربها** من سهم السؤال.
الملف اللي "سهمه" قريب من "سهم" سؤالك، هو اللي بطلعلك أول واحد.

proximity = similarity of vectors

الـ **Proximity** (القرب) هون هو نفسه الـ **Similarity** (التشابه) بين المتجهات.

proximity ≈ inverse of distance

قاعدة عامة: القرب هو "عكس" المسافة؛ كل ما زاد القرب، قلّت المسافة والعكس صحيح.

📏 Proximity & Distance Problems

📏 22. Formalizing vector space proximity

First cut: Euclidean distance?

لأول وهلة، شو أسهل طريقة نقيس فيها القرب؟ إننا نحسب **المسافة الإقليدية (Euclidean Distance)** بين رؤوس الأسهم.

Why Euclidean Distance is a BAD Idea?

The case of Query (q) and Document (d2):

تخيل لو كان عندنا سؤال (**q**) وملف (**d2**) بيحكوا عن نفس المواضيع بالظبط (مثلاً العناكب).

The Euclidean distance between q and d₂ is **large**, even though the distribution of terms in the query q and the distribution of terms in the document d₂ are **very similar**.

المشكلة: لأن الملف (**d2**) طويل جداً (فيه تكرار كبير للكلمات)، سهمه بكون "طويل كثير" وطالع لبره. بينما السؤال (**q**) بكون سهمه "قصير".
النتيجة؟ المسافة بين "راس" سهم q و "راس" سهم d2 رح تطلع **كبيرة جداً**، والسيستم رح يحكيلك "هذول ما الهم دخل ببعض" مع إنهم توأم في المحتوى!

📢 الزبدة من السلايد: المسافة الإقليدية بتعتمد على **طول المتجه** (كمية الكلمات)، وإحنا بدنا شي يعتمد على **اتجاه المتجه** (محتوى الكلمات). لهيك الـ Euclidean هون "Bad Idea".

🧭 Angles & Cosine Similarity Introduction

📐 23. Use angle instead of distance

Thought experiment: take a document d and append it to itself. Call this document d'.

**تجربة فكرية:** لو جبنا ملف (d) وكررناه مرتين (لزقناه بنفسه) وسميناه (d').

"Semantically" d and d' have the same content.

من حيث "المعنى"، الملفين d و d' بيحكوا عن نفس المحتوى 100%.

The Euclidean distance between the two documents can be quite large.

بس المسافة الإقليدية (Euclidean) بينهم رح تطلع **كبيرة جداً** (بسبب زيادة الطول).

The angle between the two documents is 0, corresponding to maximal similarity.

لكن **الزاوية** بينهم هي **صفر**، وهذا بعطيك "أقصى درجات التشابه" (Maximal Similarity).

Key idea: Rank documents according to angle with query.

**الخلاصة:** خلينا نرتب النتائج حسب **الزاوية** مع السؤال بدل المسافة.

📈 24. From angles to cosines

The following two notions are equivalent:

المفهومين هذول متكافئين تماماً في الترتيب:

1. Rank documents in decreasing order of the angle between query and document.

2. Rank documents in increasing order of cosine(query,document).

Cosine is a monotonically decreasing function for the interval [0º, 180º].

دالة الكوساين هي "دالة تناقصية" (بتقل قيمتها كل ما زادت الزاوية) في المدى من 0 لـ 180 درجة.

θ ➔ cos(θ)

❓ **But how should we be computing cosines?**
كيف ممكن نحسب الكوساين برمجياً وبسرعة؟ (هذا اللي رح نعرفه بالسلايد الجاي)

📏 Length Normalization

📏 25. Length normalization

A vector can be (length-) normalized by dividing each of its components by its length – for this we use the L₂ norm:

عشان نوحّد المقاييس وما يظلمنا طول الملف، بنعمل إشي اسمه **Length Normalization**. العملية بتتم بتقسيم كل رقم في المتجه على "طول المتجه" نفسه، واللي بنسميه **L₂ norm**.

||x||₂ = √ Σ_i x_i²

Dividing a vector by its L₂ norm makes it a unit (length) vector (on surface of unit hypersphere)

لما تقسم السهم على طوله، بصير طوله إجباري (1)، وهيك بصير السهم "عضو" على سطح كرة وهمية بنسميها الـ **Unit Hypersphere**.

✨ 26. The Perfect Equality

Effect on the two documents d and d' (d appended to itself) from earlier slide: they have identical vectors after length-normalization.

**تذكّر ملف d و d'؟** بعد عملية الـ normalization، السهمين رح يصيروا **مطابقين تماماً** فوق بعض، لأنه اتجاههم واحد!

Long and short documents now have comparable weights.

هات من الأخر: بطل فيه فرق بين ملف طويل وملف قصير، الأوزان صارت قابلة للمقارنة والعدل رجع للسيستم!

🧪 The Cosine Calculation & Formula

🧮 27. cosine(query,document)

cos(q,d) =

q • d |q| |d|

Σ_i=1^|V| q_id_i √ Σ q_i² √ Σ d_i²

• q_i is the weight of term i in the query
• d_i is the weight of term i in the document

• **q_i**: هو وزن الكلمة رقم (i) في السؤال.
• **d_i**: هو وزن الكلمة رقم (i) في الملف.

cos(q,d) is the cosine similarity of q and d... or, equivalently, the cosine of the angle between q and d.

النتيجة هي "تشابه الكوساين"، وبالمعنى الهندسي هي جيب تمام الزاوية المحصورة بين سهم السؤال وسهم الملف.

⚡ 28. Cosine for length-normalized vectors

For length-normalized vectors, cosine similarity is simply the dot product (or scalar product):

لو كنا أصلاً عاملين **normalization** للمتجهات (يعني طولهم 1)، القانون بصير تافه وبسيط: هو مجرد **الضرب النقطي**!

cos(q,d) = q • d = Σ q_id_i

💡 الزبدة: إذا كان كل واحد طوله (1)، اضرب كل رقم باللي قباله واجمع، وهيك خلصنا!

📚 29. The Data (Term Frequencies)

Sense and Sensibility (SaS), Pride and Prejudice (PaP), Wuthering Heights (WH).

بدنا نقيس التشابه بين 3 روايات عالمية باستخدام الكلمات: (affection, jealous, gossip, wuthering).

term	SaS	PaP	WH
affection	115	58	20
jealous	10	7	11
gossip	2	0	6
wuthering	0	0	38

📎 **ملاحظة:** للتبسيط، في هاض المثال مش رح نستخدم الـ **idf**، بس رح نعتمد على التكرار.

🔢 30. Step 1: Log-frequency weighting

أول خطوة: بنحوّل التكرارات الخام لأوزان باستخدام القانون: w = 1 + log₁₀(tf).

w = 1 + log₁₀(115) ≈ 1 + 2.06 = 3.06

term	SaS	PaP	WH
affection	3.06	2.76	2.30
jealous	2.00	1.85	2.04
gossip	1.30	0	1.78
wuthering	0	0	2.58

⚖️ 31. Step 2: After length normalization

ثاني خطوة: بنخلّي طول كل "سهم" رواية يساوي **1**. كيف؟ بنحسب الـ L2 Norm ونقسم عليه.

L₂ Norm (SaS) = √ (3.06² + 2.00² + 1.30² + 0²) ≈ √ 15.05 ≈ 3.88

هسا بنقسم كل وزن في عمود SaS على قيمة الـ Norm اللي طلعناها (3.88):

Normalized Weight = 3.06 / 3.88 ≈ 0.789

term	SaS	PaP	WH
affection	0.789	0.832	0.524
jealous	0.515	0.555	0.465
gossip	0.335	0	0.405
wuthering	0	0	0.588

🎯 32. Step 3: Final Cosine Similarity

آخر خطوة: بنضرب كل رقم باللي قباله (Dot Product) للأعمدة الـ **Normalized**:
لتشابه روايتي **SaS** و **PaP**:

cos(SaS, PaP) = (0.789 × 0.832) + (0.515 × 0.555) + (0.335 × 0) + (0 × 0)

≈ 0.656 + 0.286 + 0 + 0 = 0.94

Breakdown of Dot Products (Log Weights):

• dot(SaS, PaP) ≈ 12.1
(3.06×2.76) + (2.00×1.85) + (1.30×0) + (0×0)

• dot(SaS, WH) ≈ 13.4
(3.06×2.30) + (2.00×2.04) + (1.30×1.78) + (0×2.58)

*هنا بنضرب أوزان الـ Log (الجدول 2) ببعضها قبل ما نحولها لأطوال (1).

Final Cosine Scores:

• cos(SaS, PaP) ≈ 0.94
• cos(SaS, WH) ≈ 0.79
• cos(PaP, WH) ≈ 0.69

📢 **الزبدة:** رواية SaS و PaP تقريباً **تطابق تام (0.94)**؛ لأنهم بيحكوا عن نفس الحب والمشاعر. بينما WH هي الأبعد عنهم (0.69).

⚙️ 33. The CosineScore(q) Algorithm

هذا الـ **Pseudocode** بيوصف الخطوات اللي السيستم بيعملها عشان يحسب الـ Scores لكل الملفات:

ALGORITHM V6.3

COSINESCORE(q)

1
2
3
4
5
6
7
8
9
10

float Scores[N] = 0
float Length[N]
for each query term t
  do calculate w_t,q and fetch postings list for t
    for each pair(d, tf_t,d) in postings list
      do Scores[d] += w_t,d × w_t,q
Read the array Length
for each d
  do Scores[d] = Scores[d] / Length[d]
return Top K components of Scores[]

💡 الفكرة ببساطة: السيستم بيمشي على كل كلمة في السؤال، وبجمع الأوزان من الملفات اللي فيها هاي الكلمات (Postings). وبالآخر بنقسم النتيجة على طول الملف عشان الـ **Normalization**، وبنعطي الـ **Top K**.

🛠️ 34. Implementation & Optimization

1 Scoring Strategies

Previous algorithm scores **Term-At-A-Time (TAAT)**. Can be adapted to **Document-At-A-Time (DAAT)**.

الخوارزمية أعلاه بتمشي **كلمة بكلمة (TAAT)**؛ بنخلص كل شغل أول كلمة قبل ما ننتقل للثانية. بس في أنظمة تانية بتمشي **ملف بملف (DAAT)**.

2 Efficiency: Storing Weights

Storing w_t,d in each posting is expensive (floating point).

تخزين الأوزان جاهزة (كسور عشرية) في الـ Postings بيستهلك مساحة عملاقة ومكلفة.

✅ الحل: بنخزن الـ **tf_t,d** في الـ Posting، وبنخزن الـ **idf_t** مرة وحدة في رأس القائمة (Head).

3 Top K Results

Extract the top K items using a **Priority Queue** (e.g., a **Heap**).

عشان نطلع أعلى **K** نتائج بدون ما نرتب كل الملفات الضخمة، بنستخدم **Priority Queue** أو **Heap** عشان السرعة.

📊 37. SMART Weighting Table

الـ **tf-idf** إله أنواع وأشكال كثير، وكل نوع بنعطيه "حرف" عشان نميزه. هاد الجدول بيلخصهم:

Normalization	Document Frequency (idf)	Term Frequency (tf)
n (none): 1	n (no): 1	n (natural): tft,d
c (cosine): 1 / √Σw²	t (idf): log(N/dft)	l (logarithm): 1 + log(tft,d)
u (pivoted unique): 1/u	p (prob idf): log((N-df)/df)	a (augmented): 0.5 + ...
b (byte size): 1/ChLen^α		b (boolean): 1 if tf > 0
		L (log ave): complex log

🏷️ 38. The SMART Notation Breakdown (ddd.qqq)

ddd

Document Weighting
(وزن الملفات)

•

qqq

Query Weighting
(وزن السؤال)

Document (lnc)

• l: wf = 1 + log₁₀(tf)
• n: weight = wf (No idf)
• c: Norm = w / √Σw²

Query (ltc)

• l: wf = 1 + log₁₀(tf)
• t: weight = wf × idf
• c: Norm = w / √Σw²

🧪 Walkthrough: lnc.ltc Example

Product	Doc (lnc)			Query (ltc)			Term
Product	n'lize	tf-wt	tf-raw	n'lize	idf	tf-wt	Term
0	0.52	1	1	0	2.3	0	auto
0	0	0	0	0.34	1.3	1	best
0.27	0.52	1	1	0.52	2.0	1	car
0.53	0.68	1.3	2	0.78	3.0	1	insurance

⚖️ lnc.ltc: Formal Laws & Scenarios

⚖️ 39. The Mathematical Law (Algorithm)

الآن رح نحول "الشرح" لقوانين رياضية واضحة، عشان تعرف السيستم كيف بشتغل برمجياً:

1. الأوزان الأساسية (Raw Weights)

• Query (ltc): w_q = (1 + log tf_q) × idf
• Doc (lnc): w_d = 1 + log tf_d

2. التوحيد (Normalization)

V_norm = w / √(Σ w²)

3. النتيجة النهائية (The Score)

Final Score = Σ (V_norm,q × V_norm,d)

📝 40. Detailed Solution Walkthroughs

الآن رح نطبق القوانين الثلاثة (الوزن، التوحيد، النتيجة) على 3 حالات مختلفة عشان تضمن العلامة كاملة:

📍 Scenario 1: The Slide Example (Complex) Most Important

Setting: Q: "best car insurance", D: "car insurance auto insurance"
Given IDFs: best=1.3, car=2.0, insurance=3.0 (auto is ignored as it's not in Q)

الخطوة 1: حساب الأوزان الخام (Raw Weights)
• للسؤال (ltc):
   - insurance: (1+log 1) × 3.0 = 3.0
   - car: (1+log 1) × 2.0 = 2.0
• للـملف (lnc):
   - insurance: 1 + log 2 = 1.3
   - car: 1 + log 1 = 1.0
الخطوة 2: حساب التوحيد (Normalize)

• طول متجه السؤال: √(1.3²+2²+3²) ≈ 3.83
• طول متجه الملف: √(1²+1²+1.3²) ≈ 1.92

• للسؤال: insur = 3.0 / 3.83 = 0.78 | car = 2.0 / 3.83 = 0.52
• للـملف: insur = 1.3 / 1.92 = 0.68 | car = 1.0 / 1.92 = 0.52
الخطوة 3: ضرب القيم المتشابهة (Dot Product)

Score = (0.52 × 0.52)_car + (0.78 × 0.68)_insur = 0.27 + 0.53 = 0.80

📍 Scenario 2: Duplication & Identical Matching

السؤال: شو بصير لو الملف عبارة عن كلمة مكررة 100 مرة؟
المثال: Q: "car", D: "car car car ... (100 times)"
القاعدة الذهبية: الـ **Cosine Normalization** وظيفته الأساسية إلغاء أثر تكرار الكلمات وطول الملف.
1. وزن "car" برقم كبير جداً قبل التوحيد.
2. في التوحيد، رح تقسم الوزن على طول المتجه (نفسه في حالتنا).
3. النتيجة دائماً هي 1.0.

📍 Scenario 3: Partial Match (The Vector Length)

المسألة: Q: "fast car", D: "fast", idf: fast=2, car=3
1. طول متجه السؤال كامل: √(2² + 3²) = 3.61.
2. وزن fast الموحد بالسؤال: 2 / 3.61 = 0.55.
3. وزن fast الموحد بالملف: 1.0.
Final Score: 0.55 × 1.0 = 0.55

🚀 Scoring, Term Weighting & Vector Space

The Old Way: Boolean

The New Way: Scoring

📋 This Chapter: Our Learning Roadmap