समानार्थक वेक्टर खोज और दोस्त‑और‑प्रेम जीतने के विषय

पूरा खोज परिदृश्य: सटीक, फज़ी, सेमेंटिक, हाइब्रिड — और कब इन्हें एक‑साथ उपयोग करें।

Search केवलएक चीज़ नहीं है, और semantic search बाकी सभी का प्रतिस्थापन नहीं है।

“Find user with email dan@example.com” और “find me articles about debugging as a new engineer” दोनों को खोज कहा जाता है, लेकिन इंजीनियरिंग समस्याओं के रूप में इनके बीच लगभग कोई समानता नहीं है। पहला प्रश्न सही उत्तर देता है और O(log n) इंडेक्स लुकअप के साथ हल होता है। दूसरा सही उत्तर नहीं देता — केवल प्रासंगिकता — और इसे भाषा, इरादा और अर्थ को समझना पड़ता है।

जो इंजीनियर खोज निर्णयों में सबसे अधिक प्रभावी होते हैं — जो तर्क जीतते हैं और सही सिस्टम डिप्लॉय करते हैं — वे पूरे परिदृश्य को समझते हैं। उन्हें पता होता है कि किस टूल को कब उपयोग करना है और क्यों, और वे इसे स्पष्ट रूप से बता सकते हैं।

यह लेख semantic layer को कवर करता है: वेक्टर सर्च वास्तव में क्या करता है, कब यह जीतता है, और कब इसे रास्ते से हटाना चाहिए। उपयोगी संस्करण “सब कुछ एम्बेड करो” नहीं है। यह जानना है कि वेक्टर कब लेक्सिकल, फ़ज़ी, और एक्सैक्ट‑मैच सर्च के साथ हाइब्रिड आर्किटेक्चर में साथ रहने चाहिए।

लेक्सिकल और फ़ज़ी भाग — tsvector, pg_trgm, pg_search — Postgres Text Searching Guide 2026 में है।

Terms at a Glance

Embedding — मॉडल द्वारा उत्पन्न फ्लोटिंग‑पॉइंट संख्याओं की घनी सूची, जो टेक्स्ट (या इमेज, ऑडियो आदि) के टुकड़े को उच्च‑आयामी स्थान में एक बिंदु के रूप में दर्शाती है। अर्थ‑समान सामग्री पास‑पास आती है; असंबंधित सामग्री दूर रहती है।

Lexical search — सटीक शब्द और टोकन मिलान पर आधारित खोज। तेज़, निर्धारक, और ज्ञात शब्दों के लिए सही। समानार्थक शब्द, पैराफ्रेज़, या बहुभाषी समकक्ष नहीं समझता।

Semantic search — टोकन के बजाय अर्थ पर आधारित खोज। “how do I handle timeouts” प्रश्न “configuring retry policies” शीर्षक वाले दस्तावेज़ से मिल सकता है, भले ही कोई शब्द साझा न हो, क्योंकि उनके एम्बेडिंग ज्यामितीय रूप से निकट होते हैं।

Vector — संख्याओं की सूची। खोज संदर्भ में, यह एम्बेडिंग मॉडल का आउटपुट है। “Vector search” क्वेरी वेक्टर के सबसे निकट के वेक्टरों को ज्यामितीय दूरी से खोजता है।

FTS (Full-Text Search) — Postgres का अंतर्निहित लेक्सिकल सर्च, tsvector / tsquery द्वारा संचालित। टेक्स्ट को टोकनाइज़, स्टेम, और कीवर्ड क्वेरी के लिए इंडेक्स करता है। गद्य और सटीक‑शब्द लुकअप में मजबूत; अर्थ से अंधा।

BM25 —लेक्सिकल खोज के लिए एक रैंकिंग एल्गोरिद्म (Elasticsearch, Qdrant और अन्य द्वारा उपयोग किया जाता है)। यह परिणामों को टर्म फ़्रीक्वेंसी को उस टर्म की कॉर्पस में दुर्लभता के विरुद्ध वज़न देकर स्कोर करता है। कच्चे कीवर्ड मिलान से बेहतर; फिर भी लेक्सिकल।

HNSW (Hierarchical Navigable Small World) — वेक्टर खोज के लिए मानक अनुमानित निकटतम‑पड़ोसी इंडेक्स। तेज, हाई‑रिकॉल समानता क्वेरी के लिए एक लेयर्ड प्रॉक्सिमिटी ग्राफ बनाता है। pgvector, Qdrant, Weaviate और अधिकांश अन्य इसे उपयोग करते हैं।

RRF (Reciprocal Rank Fusion) — कई रिट्रीवल सिस्टमों से रैंक्ड परिणाम सूचियों को मिलाने का एल्गोरिद्म। यह केवल रैंक पोज़िशन का उपयोग करता है — स्कोर सामान्यीकरण की आवश्यकता नहीं। FTS और वेक्टर दोनों सूचियों में उच्च रैंक वाला परिणाम वह होता है जिसका संयुक्त स्कोर अधिक होता है, बनिस्बत उस परिणाम के जो केवल एक ही सूची में प्रमुख हो।

What Semantic Search Actually Does

वेक्टर एम्बेडिंग्स टेक्स्ट (या इमेज, ऑडियो आदि) को संख्याओं की सूची में बदलते हैं — उच्च‑आयामी स्थान में एक बिंदु। एम्बेडिंग मॉडल इस तरह प्रशिक्षित किया जाता है कि अर्थ‑संबंधित टेक्स्ट उस स्थान में पास‑पास आए। “Dog” और “canine” निकट आ जाते हैं। “Running a marathon” और “running a Python script” शब्द साझा करने के बावजूद दूर रह जाते हैं।

समानता खोज उस स्थान में उन दस्तावेज़ों को ढूँढ़ती है जिनका अर्थ क्वेरी के अर्थ के सबसे करीब होता है, चाहे शब्दों का सटीक मिलान हो या न हो।

इसका मतलब है:

• “मैं अनुरोध टाइमआउट कैसे कॉन्फ़िगर करूँ?” एक लेख “कनेक्शन लिमिट और रीट्राई पॉलिसी सेट करना” से मेल खा सकता है — कोई कीवर्ड ओवरलैप नहीं, लेकिन अवधारणा में उच्च प्रासंगिकता
• “गर्मियों की शाम के लिए कुछ हल्का” एक वाइन सिफ़ारिश से मिल सकता है, भले ही उत्पाद विवरण में कोई कीवर्ड न हो
• यदि एम्बेडिंग मॉडल बहुभाषी रूप से प्रशिक्षित है, तो अंग्रेज़ी में पूछी गई क्वेरी फ्रेंच, स्पेनिश या जापानी में लिखे प्रासंगिक दस्तावेज़ों से मिल सकती है

लेक्सिकल खोज (tsvector, pg_trgm) यह सब नहीं कर सकती। यह शब्दों और अक्षरों पर काम करती है, अर्थ पर नहीं। ये टूल एक‑दूसरे के विकल्प नहीं हैं — वे अलग‑अलग समस्याओं को हल करते हैं।

जब pgvector जीतता है

RAG बनाना। Retrieval‑Augmented Generation उपयोगकर्ता के प्रश्न के सबसे निकट अर्थ वाले दस्तावेज़ खंडों को पुनः प्राप्त करता है, फिर उन्हें संदर्भ के रूप में भाषा मॉडल को देता है। यह पुनः प्राप्ति चरण एक वेक्टर ऑपरेशन है। पूर्ण‑पाठ खोज (FTS) पैराफ्रेज़, समानार्थक शब्द और अवधारणात्मक मेल को चूक जाएगी, जो एक प्रासंगिक खंड अलग तरीके से व्यक्त कर सकता है। एक स्टैंडअलोन वेक्टर स्टोर की तुलना में pgvector का लाभ यह है कि यह आपके मौजूदा Postgres इंस्टेंस के भीतर चलता है — कोई अलग सेवा तैनात करने, संचालन करने या डेटा सिंक करने की आवश्यकता नहीं।

उपयोगकर्ता यह बताते हैं कि उन्हें क्या चाहिए, न कि क्या खोजा जाए। “नए मैनेजर के रूप में आत्म‑विश्वास बनाने के बारे में लेख” में उन कीवर्ड्स का अभाव है जो प्रासंगिक पोस्ट में लगातार दिखाई दें। “साइड‑इफ़ेक्ट्स को संभालने के लिए हल्का फ्रेमवर्क” दस्तावेज़ में वही शब्द नहीं हो सकते। वेक्टर खोज इरादे को मिलाती है, वर्तनी को नहीं।

समान आइटम ढूँढना। संबंधित उत्पाद, समान सपोर्ट टिकट, डुप्लिकेट बग रिपोर्ट, वे लेख जो आपको भी पसंद आ सकते हैं। “इस मुद्दे के समान समस्याएँ खोजें” एक निकटतम‑पड़ोसी खोज है — आइटम को एम्बेड करें, उसके ज्यामितीय पड़ोसियों को खोजें। एक महत्वपूर्ण चेतावनी: वेक्टर खोज हमेशा परिणाम देती है, चाहे वास्तव में कुछ समान न हो। डेडुप और सिफ़ारिश उपयोग मामलों में न्यूनतम समानता थ्रेशोल्ड (जैसे, कोसाइन समानता ≥ 0.80) से फ़िल्टर करें, ताकि कम‑विश्वास वाले मिलान को अर्थपूर्ण मानकर सामने न लाया जाए।

सेमांटिक डेडुप्लिकेशन। RAG या खोज के लिए सामग्री को इंडेक्स करने से पहले अक्सर आपको कॉर्पस में निकट‑डुप्लिकेट पहचानने होते हैं — कई बार संशोधित लेख, दो बार दर्ज किए गए सपोर्ट टिकट, या काफी हद तक ओवरलैप करने वाले नॉलेज‑बेस एंट्रीज़। दस्तावेज़ों को एम्बेड करें और कोसाइन समानता के आधार पर थ्रेशोल्ड‑फ़िल्टर लागू करके निकट‑डुप्लिकेट को फ़्लैग या मर्ज करें, इससे वे आपके इंडेक्स को दूषित नहीं करेंगे। यह सुनिश्चित करता है कि पुनः प्राप्ति कई लगभग समान खंड नहीं लौटाए और संदर्भ विंडो को पतला न करे।

बहुभाषी खोज। बहुभाषी एम्बेडिंग मॉडल समान अर्थ वाली सामग्री को विभिन्न भाषाओं में निकटवर्ती वेक्टर में मैप करते हैं। स्पेनिश में “perder peso” की क्वेरी अंग्रेज़ी लेख “sustainable weight loss habits” से मिल सकती है — कोई साझा टोकन नहीं, लेकिन वही अंतर्निहित अर्थ। FTS को प्रत्येक भाषा के शब्दकोश कॉन्फ़िगरेशन की आवश्यकता होती है और क्रॉस‑लैंग्वेज क्वेरी को ठीक से संभाल नहीं पाता। pg_trgm भाषा‑निर्पेक्ष है, लेकिन वह ऑर्थोग्राफ़िक है, सेमांटिक नहीं।

pgvector सेट‑अप

एक्सटेंशन इंस्टॉल से लेकर समानता क्वेरी तक, सेट‑अप कुछ ही SQL स्टेटमेंट्स में समेटा जा सकता है:

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- HNSW आमतौर पर मध्यम‑आकार के डेटासेट के लिए पहला इंडेक्स होता है
CREATE INDEX documents_embedding_idx
  ON documents USING hnsw (embedding vector_cosine_ops);

-- सेमांटिक सर्च क्वेरी
SELECT id, title, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

<=> कोसाइन दूरी है। 1 - cosine_distance कोसाइन समानता देता है (1.0 = पूरी तरह समान, 0.0 = लम्बवत)। ivfflat (पुराना, तेज़‑बिल्ड विकल्प) के लिए, प्रारम्भिक बिंदु के रूप में lists = sqrt(row_count) उपयोग करें।

pgvector की सीमाएँ

• सटीक टोकन मिलान — उत्पाद SKU, त्रुटि कोड, फ़ंक्शन नाम। ORD-12345 का कोई सेमांटिक समानता नहीं होती। एम्बेडिंग‑आधारित खोज ORD-12344 या असंबंधित परिणाम दे सकती है। इसके लिए FTS या B‑tree इंडेक्स प्रयोग करें।
• नाम और प्रॉपर नाउन। एम्बेडिंग स्पेस अर्थ के आधार पर व्यवस्थित करता है, वर्तनी के नहीं। उपयोगकर्ता रिकॉर्ड “Micheal Jordan” जरूरी नहीं कि वेक्टर स्पेस में “Michael Jordan” के पास आए।
• छोटे स्ट्रिंग जहाँ अक्षर‑स्तर की समानता अर्थ से अधिक महत्वपूर्ण हो। pg_trgm इसे संभालता है।
• ऐसी क्वेरी जहाँ ठीक वही शब्द उपस्थित होना अनिवार्य हो। ज्ञात‑टर्म मिलान के लिए BM25 और FTS अधिक भरोसेमंद हैं।

हाइब्रिड सर्च: दोनों की आवश्यकता

तकनीकी दस्तावेज़ीकरण सबसे स्पष्ट उदाहरण है जहाँ न तो सेमांटिक खोज और न ही पारंपरिक विधि अकेले पर्याप्त होती हैं।

उपयोगकर्ता जो “how to configure timeouts” खोज रहे हैं, उन्हें अवधारणात्मक मिलान चाहिए: “Setting retry policies and connection limits” शीर्षक वाला लेख में कोई समान कीवर्ड नहीं है, फिर भी वह बिल्कुल वही है जो उन्हें चाहिए।

वही उपयोगकर्ता withRetry(), ECONNRESET, और ERR_SOCKET_TIMEOUT भी खोजते हैं। ये सटीक स्ट्रिंग्स मौजूद होना आवश्यक है — सेमांटिक मिलान इन्हें भरोसेमंद रूप से नहीं ढूँढ़ पाएगा, और एक गलत सकारात्मक (अवधारणात्मक रूप से समान लेकिन गलत API) वास्तव में ग़लत दिशा में ले जा सकता है।

वेक्टर खोज अवधारणात्मक क्वेरी को संभालती है। FTS सटीक शब्दों को संभालती है। दोनों में से कोई भी अकेले दोनों को ठीक से नहीं संभाल सकता।

समाधान है हाइब्रिड सर्च: दोनों को चलाएँ और परिणामों को मिलाएँ।

Reciprocal Rank Fusion

Reciprocal Rank Fusion (RRF) विभिन्न पुनःप्राप्ति प्रणालियों से प्राप्त क्रमबद्ध सूचियों को मिलाने का मानक एल्गोरिदम है। इसे विभिन्न प्रणालियों के स्कोर को सामान्यीकृत करने की आवश्यकता नहीं होती — यह केवल रैंक स्थितियों का उपयोग करता है। एक परिणाम जो दोनों सूचियों में उच्च स्थान पर आता है, वह उस परिणाम से अधिक मजबूत संयुक्त स्कोर प्राप्त करता है जो केवल एक ही सूची में प्रमुख हो।

WITH fts_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY ts_rank(search_vector, query) DESC) AS rank
  FROM documents, to_tsquery('english', $1) query
  WHERE search_vector @@ query
  LIMIT 50
),
vector_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY embedding <=> $2::vector) AS rank
  FROM documents
  ORDER BY embedding <=> $2::vector
  LIMIT 50
),
rrf AS (
  SELECT
    COALESCE(f.id, v.id) AS id,
    COALESCE(1.0 / (60 + f.rank), 0) +
    COALESCE(1.0 / (60 + v.rank), 0) AS rrf_score
  FROM fts_results f
  FULL OUTER JOIN vector_results v ON f.id = v.id
)
SELECT d.id, d.title, rrf.rrf_score
FROM rrf
JOIN documents d ON d.id = rrf.id
ORDER BY rrf_score DESC
LIMIT 10;

हर हर में 60 RRF स्थिरांक है। बड़े मान रैंक‑स्थिति के अंतर को घटाते हैं; छोटे मान उन्हें बढ़ाते हैं। अधिकांश कंटेंट प्रकारों के लिए डिफ़ॉल्ट 60 पर्याप्त रूप से काम करता है।

RRF ts_rank (एक लॉग‑फ़्रीक्वेंसी स्कोर) को कोसाइन दूरी (एक ज्यामितीय माप) के साथ सामान्यीकृत करने की जटिल समस्या से बचाता है। ये दो माप तुलनीय नहीं हैं। RRF केवल यह पूछता है: “यह परिणाम प्रत्येक सूची में कितनी ऊँची रैंक पर आया?”

ट्राइग्राम के साथ हाइब्रिड सर्च भी

जब उपयोगकर्ता मिश्रित कंटेंट पर खोज करते हैं — जहाँ सत्र में व्यक्ति का नाम, कोई अवधारणा, या सटीक शब्द खोजा जा सकता है — तीन‑तरफ़ा फ्यूज़न सभी को संभालता है:

WITH trgm_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY similarity(title, $1) DESC) AS rank
  FROM documents
  WHERE title % $1
  LIMIT 50
),
fts_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY ts_rank(search_vector, to_tsquery('english', $1)) DESC) AS rank
  FROM documents
  WHERE search_vector @@ to_tsquery('english', $1)
  LIMIT 50
),
vector_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY embedding <=> $2::vector) AS rank
  FROM documents
  ORDER BY embedding <=> $2::vector
  LIMIT 50
),
rrf AS (
  SELECT
    COALESCE(t.id, f.id, v.id) AS id,
    COALESCE(1.0 / (60 + t.rank), 0) +
    COALESCE(1.0 / (60 + f.rank), 0) +
    COALESCE(1.0 / (60 + v.rank), 0) AS rrf_score
  FROM trgm_results t
  FULL OUTER JOIN fts_results f ON t.id = f.id
  FULL OUTER JOIN vector_results v ON COALESCE(t.id, f.id) = v.id
)
SELECT d.id, d.title, rrf.rrf_score
FROM rrf
JOIN documents d ON d.id = rrf.id
ORDER BY rrf_score DESC
LIMIT 10;

यह फ़्यूज़न: फजी नाम मिलान (ट्राइग्राम), सटीक कीवर्ड मिलान (FTS), और अवधारणात्मक क्वेरी (वेक्टर) को एक साथ संभालता है। एक ही सर्च बॉक्स तीनों उपयोगकर्ता इरादों को पूरा कर सकता है।

मल्टी-लेयर हाइब्रिड आर्किटेक्चर

वास्तविक अनुप्रयोगों में आमतौर पर एक ही सर्च सतह नहीं होती। उनके पास कई सतहें होती हैं, प्रत्येक की अलग ज़रूरत होती है:

ये कोई काल्पनिक परिदृश्य नहीं हैं। अधिकांश कंटेंट‑हेवी एप्लिकेशन को कम से कम दो अलग-अलग सर्च सतहों की आवश्यकता होती है, जिनकी क्वेरी संरचना अलग होती है। अक्सर लोग एक ही तरीका चुन लेते हैं और उसे हर जगह लागू कर देते हैं — आमतौर पर वेक्टर सर्च, क्योंकि यह फ़ैशनेबल विकल्प है। इससे उन समस्याओं में महंगे एम्बेडिंग बनते हैं जहाँ ट्राइग्राम इंडेक्स तेज़, सस्ता और अधिक सही होता।

नियम‑सार

जब कोई फेल्योर मोड दिखे जिसे वर्तमान लेयर ठीक नहीं कर पा रही हो, तब एक नई लेयर जोड़ें।

• उपयोगकर्ता टाइपो के कारण मिलान नहीं होने की शिकायत करते हैं → pg_trgm जोड़ें
• उपयोगकर्ता अवधारणा द्वारा खोजते हैं और प्रासंगिक परिणाम नहीं मिलते → pgvector जोड़ें
• उपयोगकर्ता सटीक प्रतीक या कोड खोजते हैं और अवधारणात्मक परिणाम मिलते हैं → FTS जोड़ें या जांचें कि क्या आप वेक्टर सर्च पर अधिक निर्भर हैं
• लेटेंसी समस्या बन जाती है → प्री‑फ़िल्टरिंग, अनुमानित इंडेक्स, या समर्पित स्टोर का मूल्यांकन करें

यदि आपको एक समर्पित वेक्टर स्टोर की आवश्यकता है

pgvector कई एप्लिकेशन सर्च को संभाल लेता है, इससे पहले कि आपको दूसरा डेटाबेस चाहिए पड़े। कट‑ऑफ़ लगभग वेक्टर संख्या, इंडेक्स सेटिंग्स, लिखने की दर, फ़िल्टर, हार्डवेयर और समवर्तीता पर निर्भर करता है, इसलिए “10 मिलियन वेक्टर से कम” नियम को बेंचमार्किंग के शुरुआती मान के रूप में लें, न कि उत्पाद सीमा के रूप में। जब आप वास्तव में उससे बाहर निकलते हैं — बहुत उच्च समवर्तीता, बहुत कम p99 लेटेंसी आवश्यकताएँ, अरबों वेक्टर, या गंभीर मल्टी‑टेनेंट अलगाव की जरूरत — तो समर्पित वेक्टर डेटाबेस परिदृश्य व्यापक है और समझने लायक है।

मैट्रिक्स कॉलम वास्तव में क्या दर्शाते हैं

हाइब्रिड सर्च का मतलब है BM25 कीवर्ड सर्च और वेक्टर समानता को एक ही क्वेरी में चलाना, जिसे RRF के माध्यम से मर्ज किया जाता है। बिना इस सुविधा के, आप या तो एक सर्च मोड चुनते हैं या दो क्वेरी को स्वयं फ्यूज़ करते हैं।

Sparse vectors BM25 से आगे जाते हैं। एक SPLADE स्पार्स वेक्टर में लगभग 30,000 आयाम होते हैं (शब्दावली के प्रत्येक टर्म के लिए एक), ≈ 98 % शून्य होते हैं। गैर‑शून्य स्थितियाँ बताती हैं कि कौन‑से टर्म महत्वपूर्ण हैं और उनकी महत्ता कितनी है। “dogs” के लिए क्वेरी “canine” और “pet” को भी वज़न देती है — BM25‑स्तर की सटीकता के साथ वेक्टर इंडेक्स के भीतर टर्म विस्तार। यदि यह कॉलम false है, तो आपको सटीक‑टर्म क्वेरीज़ के लिए एक अलग FTS लेयर की आवश्यकता होगी।

# SPLADE: ~30,000 dims, ~60 non-zero — only relevant vocabulary positions fire
def encode_splade(text: str) -> dict:
    tokens = tokenizer(text, return_tensors="pt", truncation=True, max_length=512)
    with torch.no_grad():
        output = model(**tokens)
    vec = torch.log1p(torch.relu(output.logits)).max(dim=1).values.squeeze()
    return {"indices": vec.nonzero().squeeze().tolist(), "values": vec[vec != 0].tolist()}

SQL / SQL-like वास्तव में फ़िल्टरिंग के बारे में है। फ़िल्टरिंग के बिना वेक्टर सर्च सिर्फ एक डेमो है। आपको अभी भी टेनेंट स्कोप, तिथि रेंज, अनुमतियाँ और श्रेणी फ़िल्टर की जरूरत पड़ेगी। पूर्ण SQL (pgvector, LanceDB) इनको आपके मौजूदा joins के बगल में व्यक्त करता है। प्रयोजन‑निर्मित डेटाबेस JSON फ़िल्टर ऑब्जेक्ट (Qdrant, Pinecone), क्वेरी DSL (Elasticsearch, Milvus) या GraphQL (Weaviate) का उपयोग करते हैं। वे काम करते हैं; फ़िल्टर लॉजिक जटिल होते ही SQL अधिक आकर्षक हो जाता है।

-- pgvector: vector similarity is just another expression
SELECT id, title, 1 - (embedding <=> $1) AS score
FROM documents
WHERE tenant_id = $2
  AND category = ANY($3::text[])
  AND created_at > NOW() - INTERVAL '90 days'
ORDER BY embedding <=> $1
LIMIT 10;

# Qdrant: equivalent filter as a Python object — same result, more ceremony
results = client.query_points(
    collection_name="documents", query=query_embedding,
    query_filter=models.Filter(must=[
        models.FieldCondition(key="tenant_id", match=models.MatchValue(value=tenant_id)),
        models.FieldCondition(key="category",  match=models.MatchAny(any=categories)),
        models.FieldCondition(key="created_at", range=models.DatetimeRange(gte=cutoff)),
    ]),
    limit=10,
)

Multimodal native का अर्थ है कि डेटाबेस गैर‑टेक्स्ट सामग्री के लिए एम्बेडिंग मॉडल स्वयं प्रदान करता है। आप इसे एक रॉ इमेज URL देते हैं; यह वेक्टराइज़ेशन संभाल लेता है। अधिकांश डेटाबेस एम्बेडिंग‑अज्ञेय होते हैं — आप एम्बेडिंग पाइपलाइन खुद नियंत्रित करते हैं। Marqo और Weaviate (CLIP/ImageBind मॉड्यूल के माध्यम से) इस लूप को बंद कर देते हैं।

# Marqo: POST raw images, query with text — no external embedding step
mq.index("products").add_documents(
    [{"id": "shoe-001", "image": "https://cdn.example.com/shoes/001.jpg"}],
    tensor_fields=["image"]
)
results = mq.index("products").search(q="lightweight shoes for summer")
# Returns shoe-001 despite zero keyword overlap — CLIP handles the cross-modal match

Disk-based index एक लागत लीवर है। RAM‑रहित HNSW इंडेक्स को मिलियन 1536‑डायमेंशन वेक्टरों के लिए कई GB RAM की आवश्यकता हो सकती है, जब रॉ वेक्टर, ग्राफ ओवरहेड और मेटाडेटा को गिना जाए। डिस्क‑नेटिव विकल्प (Milvus DiskANN, Elasticsearch DiskBBQ, LanceDB का Lance फ़ॉर्मेट, Turbopuffer का ऑब्जेक्ट स्टोरेज टियर) अक्सर कुछ क्वेरी लेटेंसी को कम इन्फ्रास्ट्रक्चर लागत के बदले में ट्रेड‑ऑफ़ करते हैं। RAG वर्कलोड्स में जहाँ मॉडल लेटेंसी पहले से ही प्रमुख होती है, यह ट्रेड‑ऑफ़ अक्सर बेंचमार्किंग लायक होता है।

Max dimensions आपके आर्किटेक्चर में छिपा एक माइग्रेशन जोखिम है। text-embedding-3-large 3072 डायमेंशन उपयोग करता है, Jina v3 बड़े एम्बेडिंग उत्पन्न कर सकता है, और रिसर्च मॉडल लगातार अधिक आयामों की ओर बढ़ रहे हैं। कुछ मैनेज्ड सर्विसेज कठोर डायमेंशन कैप प्रकाशित करती हैं; अन्य उच्च कैप या सामान्य एम्बेडिंग मॉडल के लिए व्यावहारिक कैप नहीं बतातीं। वर्तमान दस्तावेज़ीकरण को लागू करने से पहले जाँचें। थोड़ा हेडरूम वाला विकल्प चुनें; डायमेंशन सीमा तक पहुँचने के कारण वेक्टर इंडेक्स को माइग्रेट करना अक्सर एक दर्दनाक स्प्रिंट बन जाता है।

परिदृश्य

टेबल में न फिट होने वाली कुछ बातें

Turbopuffer की मल्टी‑टेनेन्ट आर्किटेक्चर बहुत बड़े नेमस्पेस काउंट को संभालने के लिए बनाई गई है। इसका सार्वजनिक पोजिशनिंग और ग्राहक कहानियाँ Notion जैसे बड़े, नेमस्पेस‑हेवी कॉर्पस को उजागर करती हैं। यदि प्रत्येक उपयोगकर्ता या संगठन को अलगाव‑युक्त वेक्टर सर्च चाहिए, तो यह आर्किटेक्चर लागत मॉडल को बदल सकता है, लेकिन फिर भी अपने टेनेंट प्रोफ़ाइल को बेंचमार्क करना न भूलें।

LanceDB का एम्बेडेड मोड “वेक्टर सर्च के लिए SQLite” के सबसे करीब है। यह प्रोसेस में चलता है, सर्वर की आवश्यकता नहीं होती, और Lambda, Cloudflare Workers, तथा एज वातावरण में काम करता है। Lance का कॉलमर फ़ॉर्मेट एम्बेडेड ऑपरेशन को वास्तविक स्केल पर व्यावहारिक बनाता है।

Chroma विकास/परीक्षण और छोटे ऐप डिप्लॉयमेंट में सबसे मजबूत है। यदि आप बहुत बड़े कॉर्पस, हाई‑एवलेबिलिटी, डिस्क‑हेवी ऑपरेशन, या प्रथम‑श्रेणी हाइब्रिड सर्च की तलाश में हैं, तो प्रोटोटाइप को इन्फ्रास्ट्रक्चर में ले जाने से पहले एक प्रोडक्शन‑ओरिएंटेड स्टोर का मूल्यांकन करें।

Vespa वह विकल्प हैजब रिट्रीवल केवल आधा उत्पाद हो। यह लेक्सिकल रिट्रीवल, निकटतम‑पड़ोसी खोज, टेन्सर्स, रैंकिंग एक्सप्रेशन्स, ग्रुपिंग, और ऑनलाइन सर्विंग को मिलाता है। यह शक्ति वास्तविक है, लेकिन संचालन और मॉडलिंग जटिलता भी उतनी ही है। यह खोज/सिफ़ारिश टीमों के लिए अधिक उपयुक्त है बनाम “मेरे CRUD ऐप में सेमेंटिक सर्च जोड़ें”।

ClickHouse तब चर्चा में आता है जब खोज को एनालिटिक्स के साथ जोड़ा जाता है। यदि आपका सच्चाई स्रोत इवेंट्स, लॉग्स, ट्रेसेस, या मीट्रिक्स है, तो ClickHouse वेक्टर दूरी, फ़िल्टरिंग, एग्रीगेशन, और गंभीर फुल‑टेक्स्ट इंडेक्सिंग को एक ही SQL इंजन में रखता है। यह विशेष रूप से वेक्टर डेटाबेस नहीं है, लेकिन अक्सर एनालिटिकल रिट्रीवल के लिए “बोरिंग‑राइट” उत्तर होता है।

स्पार्स वेक्टर वह तरीका है जिससे आप वेक्टर इंडेक्स के अंदर BM25‑गुणवत्ता की कीवर्ड मिलान प्राप्त कर सकते हैं — बिना अलग फुल‑टेक्स्ट इंजन चलाए। Qdrant और Elasticsearch यहाँ विशेष रूप से परिपक्व इम्प्लीमेंटेशन प्रदान करते हैं। यदि हाइब्रिड सर्च महत्वपूर्ण है और दो‑सिस्टम आर्किटेक्चर एक डील‑ब्रेकर है, तो स्पार्स वेक्टर सपोर्ट वह चीज़ है जिसे देखना चाहिए।

जब आप pgvector से आगे बढ़ गए हैं तो चुनें

• प्रति‑टेनेंट अलगाव वाला SaaS प्रोडक्ट → Turbopuffer
• स्केल पर जटिल मेटाडेटा फ़िल्टरिंग → Qdrant
• पहले से Elastic/ELK स्टैक पर → Elasticsearch with DiskBBQ
• AWS माहौल जो ओपन‑सोर्स चाहता है → OpenSearch
• गंभीर रैंकिंग आवश्यकताओं वाला खोज/सिफ़ारिश प्लेटफ़ॉर्म → Vespa
• एनालिटिक्स, ऑब्ज़रवेबिलिटी, लॉग/इवेंट खोज → ClickHouse
• बिलियन‑स्केल ऑन‑प्रेम / सेल्फ‑होस्टेड → Milvus
• एज / सर्वरलेस / मल्टीमॉडल → LanceDB
• छोटा JS ऐप, डॉक्यूमेंट साइट, या एज‑नेटिव सर्च UX → Orama
• जीरो ऑप्स, लागत द्वितीयक → Pinecone
• मल्टीमॉडल‑फ़र्स्ट (इमेज, वीडियो, ऑडियो) → Marqo
• पहले से MongoDB पर → Atlas Vector Search
• पहले से Postgres पर, अधिक हेडरूम चाहिए → Supabase Vector या Neon (दोनों pgvector मैनेज्ड, बेहतर टूलिंग के साथ)

वह एक चीज़ जिसे नहीं करना चाहिए

वेक्टर सर्च को फ़ज़ी टेक्स्ट सर्च के रूप में उपयोग न करें जब सही उत्तर मौजूद हो।

dan@example.com ई‑मेल वाले उपयोगकर्ता को खोजें — यह वेक्टर सर्च समस्या नहीं है। ORD-12345 आईडी वाले ऑर्डर को खोजें — यह भी नहीं है। ORD-12345 को एम्बेड करके कोसाइन समानता से खोज करने से कुछ परिणाम मिलेगा — लेकिन वह गलत भी हो सकता है। एक पहचानकर्ता का एक ही सही उत्तर होता है। पहचानकर्ता पर अनुमानित मिलान एक बग है।

वेक्टर सर्च आपके डेटासेट में सबसे समान वस्तु लौटाता है, भले ही वास्तव में कोई प्रासंगिक न हो। इसे यह पता नहीं होता कि कोई अच्छा उत्तर नहीं मिला। यह संबंधित दस्तावेज़ों के लिए ठीक है, लेकिन सटीक रिकॉर्ड लुक‑अप के लिए गंभीर समस्या बन जाता है, जहाँ एक भरोसेमंद गलत उत्तर खाली परिणाम से भी बदतर होता है।

उसी तरह उल्टा भी लागू होता है: जब उपयोगकर्ता कोई अवधारणा वर्णित कर रहा हो, तब फ़ुल‑टेक्स्ट सर्च (FTS) का उपयोग न करें। “अनिश्चितता के तहत कठिन निर्णय लेने के बारे में लेख” में भरोसेमंद कीवर्ड नहीं होते। FTS या तो शोर लौटाएगा या कुछ नहीं। क्वेरी के आकार के अनुसार सही टूल चुनें।

The Full Picture

अधिकांश उत्पादन खोज प्रणालियों को एक से अधिक परतों की आवश्यकता होती है:

• pg_trgm नामों, टाइपो, ऑटोकम्प्लीट के लिए
• FTS / pg_search कीवर्ड‑आधारित prose खोज के लिए
• pgvector सेमांटिक और अवधारणात्मक क्वेरीज़ के लिए
• RRF fusion उन सतहों के लिए जहाँ उपयोगकर्ता क्वेरी प्रकारों को मिश्रित करते हैं
• Regular indexes सटीक पहचानकर्ताओं, फ़िल्टर और सॉर्टेड सूचियों के लिए

ये प्रतिस्पर्धी उपकरण नहीं हैं। ये परस्परपूरक हैं। एक अच्छी तरह निर्मित खोज प्रणाली प्रत्येक क्वेरी आकार के लिए सही परत चुनती है — और जब क्वेरी आकार ओवरलैप होते हैं, तो कई परतें चलाकर परिणामों को मिलाती है।

वे टीमें जो अच्छे खोज फीचर शिप करती हैं, पूरे स्टैक को समझती हैं। जो नहीं समझतीं, वे वेक्टर डेटाबेस की ओर झुकती हैं, सब कुछ एम्बेड करती हैं, और आश्चर्य करती हैं कि सटीक लुक‑अप कभी‑कभी गलत रिकॉर्ड क्यों लौटाते हैं।