सेमांटिक वेक्टर सर्च और दोस्त तथा प्रेमियों को जीतने के लिए अन्य विषय

संपूर्ण सर्च लैंडस्केप: एक्जैक्ट, फ़ज़ी, सेमांटिक, हाइब्रिड — और इन्हें कब लेयर करें।

सर्च एक ही चीज़ नहीं है, और सेमांटिक सर्च बाकी सबकी जगह नहीं ले सकता।

“ईमेल dan@example.com वाले यूज़र को खोजो” और “मुझे नए इंजीनियर के रूप में डीबगिंग पर लेख दिखाओ” — दोनों को सर्च कहा जाता है, लेकिन इंजीनियरिंग समस्याओं के रूप में इनमें लगभग कुछ भी समान नहीं है। पहले का एक सही जवाब है और O(log n) इंडेक्स लुकअप। दूसरे का कोई सही जवाब नहीं है — केवल रिलेवेंस है — और इसके लिए भाषा, इरादा और अर्थ को समझने की ज़रूरत होती है।

वे इंजीनियर जो सर्च के फ़ैसलों पर सबसे ज़्यादा प्रभावी तर्क देते हैं — जो बहस जीतते हैं और सही सिस्टम शिप करते हैं — वे पूरे लैंडस्केप को समझते हैं। उन्हें पता होता है कि किस टूल को कब और क्यों इस्तेमाल करना है, और वे इसे साफ़-साफ़ समझा भी सकते हैं।

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

लेक्सिकल और फ़ज़ी आधी तस्वीर — tsvector, pg_trgm, pg_search — Postgres Text Searching Guide 2026 में है।

मुख्य शब्द एक नज़र में

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

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

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

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

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

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

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

RRF (रैसिप्रोकल रैंक फ्यूजन) — कई रिट्रीवल सिस्टम से रैंक किए गए परिणाम सूचियों को मर्ज करने का एक एल्गोरिदम। केवल रैंक स्थिति का उपयोग करता है — स्कोर सामान्यीकरण की आवश्यकता नहीं। एक परिणाम जो FTS और वेक्टर दोनों सूचियों में ऊँचा रैंक करता है, उसे एक मज़बूत संयुक्त स्कोर मिलता है जो केवल एक में हावी होने वाले से बेहतर होता है।

सेमांटिक सर्च वास्तव में क्या करता है

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

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

इसका मतलब है:

• “How do I configure request timeouts?” एक लेख से मैच कर सकता है जिसका शीर्षक “Setting connection limits and retry policies” है — कोई ओवरलैपिंग कीवर्ड नहीं, उच्च अवधारणात्मक प्रासंगिकता
• “Something light for a summer evening” प्रोडक्ट विवरण में कोई कीवर्ड दिखाई दिए बिना वाइन सिफ़ारिश से मैच कर सकता है
• अंग्रेज़ी में एक क्वेरी फ्रेंच, स्पेनिश या जापानी में प्रासंगिक दस्तावेज़ों से मैच कर सकती है यदि एम्बेडिंग मॉडल बहुभाषी रूप से प्रशिक्षित था

लेक्सिकल सर्च (tsvector, pg_trgm) यह कुछ भी नहीं कर सकता। यह शब्दों और अक्षरों पर काम करता है, अर्थ पर नहीं। ये टूल इंटरचेंजेबल नहीं हैं — वे अलग-अलग समस्याएँ हल करते हैं।

जब pgvector बेहतर होता है

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

उपयोगकर्ता बताते हैं कि उन्हें क्या चाहिए, न कि क्या सर्च करना है। “Articles about building confidence as a new manager” में कोई ऐसे कीवर्ड नहीं हैं जो विश्वसनीय रूप से प्रासंगिक पोस्ट में दिखाई दें। “A lightweight framework for handling side effects” शायद दस्तावेज़ में उन सटीक शब्दों का उपयोग नहीं करता। वेक्टर सर्च इरादे से मैच करता है, वर्तनी से नहीं।

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

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

बहुभाषी सर्च। बहुभाषी एम्बेडिंग मॉडल भाषाओं में समानार्थी सामग्री को नज़दीकी वेक्टर में मैप करते हैं। स्पेनिश में “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 is usually the first index to try for moderate-size datasets
CREATE INDEX documents_embedding_idx
  ON documents USING hnsw (embedding vector_cosine_ops);

-- Semantic search query
SELECT id, title, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

<=> cosine distance है। 1 - cosine_distance cosine similarity देता है (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 सटीक शब्दों को संभालता है। कोई भी अकेले दोनों को अच्छी तरह नहीं संभालता।

समाधान हाइब्रिड सर्च है: दोनों चलाओ और परिणामों को फ्यूज़ करो।

रैसिप्रोकल रैंक फ्यूजन

रैसिप्रोकल रैंक फ्यूजन (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 (एक लॉग-आवृत्ति स्कोर) को cosine distance (एक ज्यामितीय माप) के विरुद्ध सामान्यीकरण की कठिन समस्या से बचता है। वे तुलनीय नहीं हैं। 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 काफी अनुप्रयोग सर्च को संभालता है इससे पहले कि आपको एक और डेटाबेस की आवश्यकता हो। रफ़ कटऑफ़ वेक्टर गणना, इंडेक्स सेटिंग्स, लेखन दर, फ़िल्टर, हार्डवेयर और समवर्तिता पर निर्भर करता है, इसलिए किसी भी “10M वेक्टर से कम” नियम को एक प्रारंभिक धारणा के रूप में मानें जिसे बेंचमार्क करना है, न कि एक उत्पाद सीमा। जब आप वास्तव में इससे बाहर निकल जाते हैं — बहुत उच्च समवर्तिता, बहुत कम p99 विलंबता आवश्यकताएँ, अरबों वेक्टर, या गंभीर मल्टी-टेनेंट अलगाव आवश्यकताएँ — समर्पित वेक्टर डेटाबेस लैंडस्केप व्यापक है और समझने योग्य है।

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

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

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

# SPLADE: ~30,000 dims, ~60 non-zero — केवल प्रासंगिक शब्दावली स्थितियाँ सक्रिय होती हैं
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) इसे आपके मौजूदा जोइन के बगल में व्यक्त करता है। उद्देश्य-निर्मित डेटाबेस JSON फ़िल्टर ऑब्जेक्ट (Qdrant, Pinecone), एक क्वेरी DSL (Elasticsearch, Milvus), या GraphQL (Weaviate) का उपयोग करते हैं। वे काम करते हैं; SQL अधिक आकर्षक बन जाता है क्योंकि फ़िल्टर तर्क जटिल हो जाता है।

-- pgvector: वेक्टर समानता बस एक और अभिव्यक्ति है
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: एक Python ऑब्जेक्ट के रूप में समकक्ष फ़िल्टर — समान परिणाम, अधिक औपचारिकता
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,
)

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

# Marqo: कच्ची इमेज POST करो, टेक्स्ट से क्वेरी करो — कोई बाहरी एम्बेडिंग चरण नहीं
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")
# शून्य कीवर्ड ओवरलैप के बावजूद shoe-001 लौटाता है — CLIP क्रॉस-मोडल मिलान को संभालता है

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

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

8 मई, 2026 को सार्वजनिक प्रोजेक्ट दस्तावेज़ों और प्रोडक्ट पेजों के विरुद्ध अंतिम बार सत्यापित। नीचे दी गई तालिका को एक निर्णय सहायक के रूप में देखें, वर्तमान सीमाओं, मूल्य निर्धारण और प्रबंधित-सेवा सुविधा ध्वजों की जाँच करने के विकल्प के रूप में नहीं।

लैंडस्केप

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

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

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

Chroma dev/test और छोटे ऐप तैनाती में सबसे मज़बूत है। यदि आप बहुत बड़े कॉर्पस, HA, डिस्क-भारी संचालन, या फर्स्ट-क्लास हाइब्रिड सर्च को लक्षित कर रहे हैं, तो प्रोटोटाइप को इंफ्रास्ट्रक्चर में बढ़ाने से पहले एक उत्पादन-उन्मुख स्टोर का मूल्यांकन करें।

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

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

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

चुनना जब आप pgvector से आगे निकल चुके हैं

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

वह एक चीज़ जो नहीं करनी है

उन चीज़ों के लिए फ़ज़ी टेक्स्ट सर्च के रूप में वेक्टर सर्च का उपयोग न करें जिनके सही जवाब होते हैं।

“मुझे ईमेल dan@example.com वाला उपयोगकर्ता खोजो” एक वेक्टर सर्च समस्या नहीं है। “ID ORD-12345 वाला ऑर्डर खोजो” भी नहीं। ORD-12345 को एम्बेड करना और cosine similarity से खोजना कुछ लौटाएगा — लेकिन यह ग़लत हो सकता है। एक पहचानकर्ता का एक सही जवाब होता है। एक पहचानकर्ता पर अनुमानित मिलान एक बग है।

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

वही दूसरी दिशा में लागू होता है: उन क्वेरी के लिए FTS का उपयोग न करें जहाँ उपयोगकर्ता एक अवधारणा का वर्णन कर रहा है। “articles about making hard decisions under uncertainty” में कोई विश्वसनीय कीवर्ड नहीं हैं। FTS या तो शोर लौटाएगा या कुछ नहीं। क्वेरी आकार के लिए सही टूल का उपयोग करें।

पूरी तस्वीर

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

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

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

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