🔢 धडा 02 — Text ते vectors: प्रत्येक text ला जागा देणे

📍 तुम्ही इथे आहात: 8 पैकी धडा 02 · मागे: lesson-01-why-vector-db · पुढे: lesson-03-similarity

📦 या ब्रँचमध्ये काय आहे

धडा 01, आणि प्रवेशाचा विधी: text चे निर्देशांकांमध्ये रूपांतर कसे होते — आपल्या toy ची पद्धत, खरी पद्धत, आणि त्या दोघांमधली दरी (जी तुम्ही आधीच मुद्दाम अपयशी होताना पाहिली आहे).

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

Hall मध्ये बसायला निर्देशांक लागतात. ते देण्याच्या दोन पद्धती:

आपल्या toy ची पद्धत — शब्द मोजा 🔤 (vectordb.py embed()): hall मध्ये 256 दिशा आहेत; प्रत्येक शब्द (hash करून) त्यांपैकी एका दिशेला धक्का देतो; लांब documents ओरडू नयेत म्हणून normalize करा. वेगवान, कोणतीही जादू नाही — आणि जवळचेच पाहणारे (nearsighted): दोन texts तेव्हाच जवळ बसतात जेव्हा त्यांच्यात अक्षरशः तेच शब्द असतात. "pupils" आणि "students" वेगवेगळ्या आकाशगंगांमध्ये बसतात (demo मधला 0.00!). या कुटुंबाने — bag-of-words, TF-IDF, BM25 — अनेक दशके search चालवला आणि आजही hybrid search चा keyword अर्धा भाग तेच चालवतात.

खरी पद्धत — सगळे वाचलेल्या model ला विचारा 🧠 (AI शाळा L02+L04): embedding model — एक प्रशिक्षित neural network — text ला ठरावीक लांबीच्या vector मध्ये बदलते (model नुसार शेकडो ते हजारो निर्देशांक) जिथे दिशांचा अर्थ अर्थ असतो: अब्जावधी उदाहरणांमधून शिकलेले, म्हणून "pupils" "students" च्या शेजारी बसते, "refund my order" हे "I want my money back" च्या शेजारी, वेगळ्या शब्दरचनेतही आणि वेगळ्या भाषांमध्येही.

सुंदर design तथ्य: तुम्ही कोणती पद्धत निवडली याची database ला पर्वा नसते. Vectors आत, शेजारी बाहेर. आपले embed() हे एक function आहे — त्याच्या जागी model call ठेवा आणि course मधली प्रत्येक इतर ओळ तरीही चालते. (हे वेगळेपण — embedder विरुद्ध store — हीच industry ची architecture पण आहे.)

🗺️ आकृती

flowchart LR
    text["📝 'Class 3A has twelve students'"]
    subgraph toy["🔤 toy: hashed word counts"]
        h["each word bumps 1 of 256 buckets<br/>→ normalize"]
        lim["😬 nearsighted: shared WORDS only"]
    end
    subgraph real["🧠 real: embedding model"]
        m["trained network → fixed-size vector<br/>(hundreds–thousands of dims) · directions = MEANING"]
        win["'pupils' ≈ 'students' ✅"]
    end
    v["🗺️ a seat: [0.12, -0.08, …]<br/>the DB takes it from here —<br/>either way"]
    text --> toy --> v
    text --> real --> v

❓ काय

Dimensions: प्रत्येक निर्देशांक म्हणजे बदलाची एक दिशा. Toy: एक hash bucket (अर्थहीन पण सुसंगत). शिकलेले: text चा अंदाज लावण्यासाठी model ला उपयोगी वाटलेल्या दिशा (औपचारिकता, विषय, सूर… — कधीच label केलेल्या नाहीत, आपोआप उगवलेल्या).
Normalization (_normalize): प्रत्येक vector ची लांबी 1 करा म्हणजे similarity दिशेची तुलना करते, document च्या लांबीची नाही — यातूनच धडा 03 ची स्वच्छ cosine युक्ती तयार होते.
त्याच model चा नियम ⚠️: query vectors आणि document vectors एकाच embedder मधून आले पाहिजेत — वेगवेगळ्या halls मधल्या जागांची तुलना होत नाही. परिणाम: embedding model बदलले → सगळे पुन्हा embed करा (धडा 08 मधली operational अडचण).
Embeddings फक्त text साठी नाहीत: images, audio, code, products — कशालाही जागा मिळू शकते (AI शाळा L12 ची multimodal गोष्ट).

🤔 का

Embedder निवडणे म्हणजेच तुमच्या product साठी "सारखे" याचा अर्थ निवडणे — retrieval च्या दर्जाची कमाल मर्यादा इथे ठरते, database मध्ये नाही. आणि toy/खरे यांमधली दरी माहीत असली की तुम्ही दोन्ही चुकांपासून वाचता: शब्द-vectors ना समानार्थी शब्द समजतील अशी अपेक्षा करणे, आणि कामाला फक्त नेमका keyword match पुरेसा असताना model-embedding चा खर्च भरणे.

🧪 करून पाहा

python3 vectordb/demo.py     # re-read the 😬 section knowing WHY now
python3 -c "
import sys; sys.path.insert(0,'vectordb')
from vectordb import embed, cosine
print('students vs student :', round(cosine(embed('students'), embed('student')),2))
print('students vs pupils   :', round(cosine(embed('students'), embed('pupils')),2))
"
# even the plural is a different word to a hash! (real embedders handle both)

⏭️ पुढे

दोन जागा — त्या नेमक्या किती जवळ आहेत? Similarity चे गणित: cosine, dot, distance, आणि कधी कोणते वापरायचे.

git checkout lesson-03-similarity

🔢 Lesson 02 — Text to vectors: giving every text a seat

📍 You are here: Lesson 02 of 8 · Previous: lesson-01-why-vector-db · Next: lesson-03-similarity

📦 What's in this branch

Lesson 01, plus the entry ritual: how text becomes coordinates — our toy's way, the real way, and the gap between them (which you already watched fail on purpose).

🧒 Explain like I'm 5

To sit in the hall you need coordinates. Two ways to assign them:

Our toy's way — count the words 🔤 (vectordb.py embed()): the hall has 256 directions; every word (hashed) bumps one of them; normalize so long documents don't shout. Fast, zero magic — and nearsighted: two texts sit close only if they share literal words. "pupils" and "students" sit in different galaxies (the demo's 0.00!). This family — bag-of-words, TF-IDF, BM25 — powered search for decades and still powers the keyword half of hybrid search.

The real way — ask a model that has read everything 🧠 (AI school L02+L04): an embedding model — a trained neural network — maps text to a fixed-length vector (hundreds to thousands of coordinates, depending on the model) where the directions mean meaning: learned from billions of examples, so "pupils" sits beside "students", "refund my order" beside "I want my money back", across phrasing and even languages.

The beautiful design fact: the database doesn't care which way you chose. Vectors in, neighbors out. Our embed() is one function — swap in a model call and every other line of the course still runs. (That separation — embedder vs store — is the industry's architecture too.)

🗺️ Diagram

flowchart LR
    text["📝 'Class 3A has twelve students'"]
    subgraph toy["🔤 toy: hashed word counts"]
        h["each word bumps 1 of 256 buckets<br/>→ normalize"]
        lim["😬 nearsighted: shared WORDS only"]
    end
    subgraph real["🧠 real: embedding model"]
        m["trained network → fixed-size vector<br/>(hundreds–thousands of dims) · directions = MEANING"]
        win["'pupils' ≈ 'students' ✅"]
    end
    v["🗺️ a seat: [0.12, -0.08, …]<br/>the DB takes it from here —<br/>either way"]
    text --> toy --> v
    text --> real --> v

❓ What

Dimensions: each coordinate is a direction of variation. Toy: a hash bucket (meaningless but consistent). Learned: directions the model found useful for predicting text (formality, topic, tone… — never labeled, just emergent).
Normalization (_normalize): scale every vector to length 1 so similarity compares direction, not document length — sets up lesson 03's clean cosine trick.
Same model rule ⚠️: query vectors and document vectors must come from the SAME embedder — seats from different halls don't compare. Corollary: change your embedding model → re-embed everything (lesson 08's operational gotcha).
Embeddings aren't just for text: images, audio, code, products — anything can get a seat (AI school L12's multimodal story).

🤔 Why

Choosing an embedder IS choosing what "similar" means for your product — retrieval quality ceilings live here, not in the database. And knowing the toy/real gap protects you from both errors: expecting word-vectors to understand synonyms, and paying model-embedding costs when exact keyword match was all the job needed.

🧪 Try it

python3 vectordb/demo.py     # re-read the 😬 section knowing WHY now
python3 -c "
import sys; sys.path.insert(0,'vectordb')
from vectordb import embed, cosine
print('students vs student :', round(cosine(embed('students'), embed('student')),2))
print('students vs pupils   :', round(cosine(embed('students'), embed('pupils')),2))
"
# even the plural is a different word to a hash! (real embedders handle both)

⏭️ Next

Two seats — how close are they, exactly? Similarity math: cosine, dot, distance, and which to use when.

git checkout lesson-03-similarity

← Previouswhy vector db Next →similarity

This page is the lesson's README from the lesson-02-text-to-vectors branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.