पाठलाई भेक्टरमा बदल्ने

विचार, एक अनुच्छेदमा

Embedding अर्थको संख्यात्मक representation हो। पाठ "नमस्ते" (नेपाली) embedding मोडेल मा feed गर्नुहोस्, र बाहिर fixed-size संख्याहरूको सूची — सामान्यतया 768, 1024, वा 3072 आयाम — आउँछ। "Hello" (अंग्रेजी) feed गर्नुहोस्, र तपाईंले फरक संख्याहरूको सूची पाउनुहुन्छ, तर numerically पहिलो को नजिक — किनकि मोडेललाई तालिम दिइएको छ कि यी दुई अभिवादनहरू समान अर्थ राख्छन्।

महत्त्वपूर्ण गुण: समान अर्थहरूले समान भेक्टरहरू उत्पादन गर्छन्। फरक अर्थहरूले फरक भेक्टरहरू उत्पादन गर्छन्। Numerical “closeness” (cosine similarity द्वारा मापन गरिएको) semantic closeness बराबर हुन्छ।

बस त्यति नै। Downstream सबै कुरा — semantic search, recommendation, clustering, RAG — त्यो एक गुणमा निर्मित छ।

यसले के सम्भव छ बदल्छ

Traditional keyword search स्पष्ट तरिकाहरूमा असफल हुन्छ:

• "heart attack" को खोजी "cardiac arrest" बारेका कागजातहरू छुटाउँछ यद्यपि तिनको उही अर्थ छ।
• "नेपाली भाषा" को खोजी "the Nepali language" छुटाउँछ — फरक scripts, उही अर्थ।
• "cheap smartphone" को खोजीले "budget mobile phone" भेट्दैन।

Embeddings ले तीनैलाई एकैचोटि समाधान गर्छन्। किनकि "heart attack" र "cardiac arrest" का embeddings numerically नजिक छन्, कागजातहरूमाथिको semantic search ले दुवै surface गर्नेछ। नेपाली/अंग्रेजी संस्करणहरूको उही विचारका लागि पनि। "cheap" र "budget" का लागि पनि।

यो incremental होइन। यो search engine जुनले तपाईंले शाब्दिक रूपमा टाइप गरेको भेट्छ र त्यो जुनले तपाईंले अर्थ लगाएको भेट्छ — बीचको फरक हो।

Embedding compute गर्ने

धेरै प्रदायकहरूले embedding APIs प्रस्ताव गर्छन्। हामी OpenAI को text-embedding-3-small प्रयोग गर्नेछौँ किनकि यो सस्तो, उच्च-गुणस्तर, र multilingual (नेपाली सहित) छ। Anthropic ले हाल आफ्नो जहाज गर्दैन; industry ले प्रायः Claude-based अनुप्रयोगहरूमा पनि embedding चरणका लागि OpenAI को प्रयोग गर्छ।

Setup:

pip install openai numpy

.env फाइल:

OPENAI_API_KEY=sk-...

कल:

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI()


def embed(text: str) -> list[float]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=text,
    )
    return response.data[0].embedding


v = embed("नमस्ते! यो कस्तो छ?")
print(f"Dimensions: {len(v)}")
print(f"First 5:    {v[:5]}")

Output:

Dimensions: 1536
First 5:    [-0.023, 0.014, -0.007, 0.031, -0.019]

प्रति पाठ 1536 संख्या। हरेक पाठले आफ्नो भेक्टर पाउँछ।

Similarity, मापन गरिएको

दुई भेक्टरहरू कति समान छन् मापन गर्ने standard तरिका cosine similarity हो — -1 र 1 (व्यवहारमा, embeddings सामान्यतया सकारात्मक-valued हुन्छन् त्यसैले तपाईं 0 देखि 1 देख्नुहुन्छ) बीचको संख्या:

• 1.0 — identical अर्थ।
• ~0.9+ — धेरै समान अर्थ।
• ~0.7 — सम्बन्धित तर distinct।
• ~0.5 — loosely सम्बन्धित।
• <0.3 — सम्भवतः असम्बन्धित।

सूत्र: दुई भेक्टरहरूको dot product तिनको magnitudes द्वारा भाग गरिएको।

import numpy as np


def cosine_similarity(v1: list[float], v2: list[float]) -> float:
    a = np.array(v1)
    b = np.array(v2)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))


# A few examples
pairs = [
    ("Hello",                    "नमस्ते"),
    ("Hello",                    "Goodbye"),
    ("Kathmandu is the capital", "काठमाडौं नेपालको राजधानी हो"),
    ("Kathmandu is the capital", "cars are fast"),
]

for a, b in pairs:
    sim = cosine_similarity(embed(a), embed(b))
    print(f"{a[:40]:40s} <-> {b[:40]:40s} {sim:.3f}")

तपाईंले यस्तै देख्नुहुनेछ:

Hello                                    <-> नमस्ते                                   0.792
Hello                                    <-> Goodbye                                  0.680
Kathmandu is the capital                 <-> काठमाडौं नेपालको राजधानी हो             0.891
Kathmandu is the capital                 <-> cars are fast                            0.148

यसलाई पढ्नुहोस्। "Hello" र "नमस्ते" ~0.79 समान छन् — मोडेलले सही रूपमा चिन्छ कि तिनको भाषा भर लगभग उही अर्थ छ। "Kathmandu is the capital" अंग्रेजी र नेपाली मा 0.89 छन् — धेरै समान। "Kathmandu is the capital" र "cars are fast" 0.15 छन् — स्पष्ट रूपमा फरक।

संख्याहरूले अर्थ इन्कोड गर्छन्।

“Similar” को वास्तवमै के अर्थ छ

Cosine similarity ले एक विशिष्ट प्रकारको similarity — समग्र अर्थ — capture गर्छ। यसले क्यापचर गर्दैन:

• सत्य। "Sun rises in the east" र "Sun rises in the west" को धेरै उच्च similarity हुन्छ यद्यपि एउटा साँचो र अर्को साँचो होइन। Embeddings ले sentence के बारेमा छ को हेरचाह गर्छन्, यो सही छ कि छैन को होइन।
• Sentiment reversal। "Great product, love it" र "Terrible product, hate it" semantically धेरै समान छन् (दुवै product opinion बारे), केवल विपरीत valence सँग। यसका लागि तपाईंलाई प्रायः separate sentiment models चाहिन्छ।
• सटीक numeric फरक। "5 kg" र "50 kg" embedding space मा नजिक छन् — दुवै weight बारे — तर numerically धेरै फरक। सटीक संख्याहरूमा hinge हुने कामका लागि embeddings प्रयोग नगर्नुहोस्।

अधिकांश practical अनुप्रयोगहरूका लागि — retrieval, clustering, general similarity — embeddings को cosine similarity ठ्याक्कै सही छ। बस यसका blind spots थाहा राख्नुहोस्।

लागत र गति

Embeddings नाटकीय रूपमा LLM कलहरू भन्दा सस्ता छन्:

• text-embedding-3-small: $0.02 प्रति 1M tokens।
• text-embedding-3-large: $0.13 प्रति 1M tokens (राम्रो गुणस्तर, 3072 dims)।

तुलनाका लागि, Claude Haiku input $0.25 प्रति 1M tokens छ — small embedding मोडेल भन्दा 10x भन्दा बढी महँगो। 100,000 कागजातहरू embed गर्ने (भनौँ, 500 tokens प्रत्येक = 50M tokens) को लागत लगभग $1 हो।

Latency पनि राम्रो छ — embedding call सामान्यतया 500ms मुनि फर्किन्छ। र crucially, एक पटक तपाईंले कागजात embed गरेपछि, तपाईंले यसलाई फेरि embed गर्नुपर्दैन। भेक्टरहरू store गर्नुहोस् र सधैँ reuse गर्नुहोस्।

Efficiency का लागि Batching

एक पटकमा एक पाठ embed गर्नु slow र per-request महँगो छ। Batch गर्नुहोस्:

def embed_batch(texts: list[str]) -> list[list[float]]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=texts,
    )
    return [d.embedding for d in response.data]


vectors = embed_batch([
    "नेपाल एक सुन्दर देश हो",
    "काठमाडौं राजधानी हो",
    "Cars are fast",
    "The mountains are beautiful",
])

OpenAI ले प्रति कल ~2048 inputs सम्म स्वीकार्छ। ठूला कागजात collections (हजारौँ chunks) process गर्न, batching essential छ।

विशेष रूपमा नेपाली

text-embedding-3-small ले नेपाली राम्रोसँग सम्हाल्छ। केही अवलोकन:

• Devanagari र Romanised नेपाली लाई पर्याप्त समान चिनिन्छ — एक form मा query ले अर्को form मा कागजातहरू भेट्छ, यद्यपि Devanagari-Devanagari matches जति sharp होइन।
• नेपाली-अंग्रेजी cross-lingual similarity decent छ। "loan" र "ऋण" को similarity ~0.7 छ, एक भाषामा query ले अर्को भाषामा relevant सामग्री surface गर्न पर्याप्त।
• साना नेपाली variants (informal छ, formal हुनुहुन्छ) लाई सम्बन्धित चिनिन्छ। Regional variants कम राम्रोसँग captured — मोडेलले dialectal variants भन्दा धेरै Kathmandu-standard नेपाली देखेको छ।

अधिकांश नेपाली अनुप्रयोगहरूका लागि यो पर्याप्त भन्दा राम्रो छ। जब तपाईंलाई विशेष रूपमा उच्च-गुणस्तर नेपाली चाहिन्छ, dedicated multilingual embedding मोडेलहरू जस्तै intfloat/multilingual-e5-large (open-source, GPU चाहिन्छ) वा Cohere embed-multilingual-v3 (API) ले नेपाली-heavy workloads मा OpenAI को outperform गर्न सक्छन्।

Embedding मोडेलहरूको छोटो taxonomy

सन्दर्भका लागि:

• text-embedding-3-small (OpenAI, API, $0.02/M) — सस्तो workhorse, 1536 dims। Prototyping का लागि default।
• text-embedding-3-large (OpenAI, API, $0.13/M) — उच्च गुणस्तर, 3072 dims। लागत भन्दा गुणस्तर बढी महत्त्वपूर्ण भएमा प्रयोग गर्नुहोस्।
• intfloat/multilingual-e5-large (open-source, HuggingFace) — यदि GPU छ भने निःशुल्क, नेपाली सहित धेरै multilingual कामका लागि best-in-class।
• sentence-transformers/all-MiniLM-L6-v2 (open-source, CPU-friendly) — सानो, छिटो, English-only। Prototypes का लागि ठीक।
• Cohere embed-multilingual-v3.0 (API) — multilingual मा धेरै बलियो, OpenAI को small तुलनीय।
• Voyage AI’s models — domain-specific retrieval (law, medicine, code) का लागि बलियो।

Course 04 का लागि हामी OpenAI को small मोडेल प्रयोग गर्छौँ किनकि यो सरल छ। उत्पादनमा, छनोट गर्नुअघि आफ्नो वास्तविक डाटामा benchmark गर्नुहोस्।

आफ्नो बुझाइ जाँच्नुहोस्

Quick check

—

तपाईंको semantic-search app ले 'a cheap smartphone' बारेका कागजातहरू फर्काउँछ जब user ले 'budget mobile phone' query गर्छन्। भर्खर के भयो?

1. AKeyword search engine ले 'phone' match गर्‍यो।
2. BEmbedding-based semantic search: 'budget mobile phone' र 'cheap smartphone' का धेरै समान embeddings छन् किनकि तिनको लगभग उही अर्थ छ। Cosine similarity ले यो capture गर्‍यो यद्यपि दुई queries ले लगभग कुनै keywords share गर्दैनन् (सम्भवतः 'phone' बाहेक)। यो keyword search माथि embeddings को मौलिक फाइदा हो — अर्थ, शाब्दिक शब्द होइन।
3. CLLM ले सारांश उत्पन्न गर्‍यो।
4. DDatabase ले synonyms indexed गर्‍यो।

Check answer→

Quick check

—

एक टिम सदस्यले embedding similarity प्रयोग गरेर knowledge base विरुद्ध दाबी ('Sun rises in the west') तुलना गर्ने fact-checking system योजना गरिरहेका छन्। यस design को मौलिक समस्या के हो?

1. AEmbeddings fact-checking का लागि धेरै slow छन्।
2. BEmbedding similarity ले *topical* similarity capture गर्छ, truth होइन। 'Sun rises in the west' र 'Sun rises in the east' embedding space मा highly similar छन् — दुवै sun र rising बारे — यद्यपि एउटा साँचो र अर्को गलत छ। Fact-checking लाई reasoning चाहिन्छ, केवल similarity होइन: सम्बन्धित कागजातहरू retrieve गर्नुहोस् (embeddings प्रयोग गरेर), त्यसपछि LLM ले retrieved evidence पढेर दाबीलाई त्यसको विरुद्ध मूल्याङ्कन गरोस्। Embeddings एक्लै तपाईंलाई दाबी गलत छ भन्न सक्दैनन्।
3. CEmbeddings fact-checking का लागि धेरै महँगा छन्।
4. DFact-checking लाई supervised learning चाहिन्छ।

Check answer→

अब के आउँछ

Embedding के हो तपाईंलाई थाहा छ। अर्को खण्ड तिनसँग के गर्ने हो: semantic search — Python का दस लाइनमा तपाईंले अर्थद्वारा query गर्न सक्ने कागजातहरूको index निर्माण गर्ने। यो हरेक RAG प्रणालीको foundation हो, र यो पाठ्यक्रममा तपाईंले सिक्ने सबैभन्दा उपयोगी patterns मध्ये एक हो।