Postgres में HNSW सूचकांक: वेक्टर खोज के लिए अच्छी तरह से सूचकांक

HNSW का मतलब पदानुक्रमित नौगम्य लघु विश्व है। यह एक ग्राफ इंडेक्स है: प्रत्येक वेक्टर अपने निकटतम पड़ोसियों से जुड़ा एक नोड बन जाता है, जो कई सुपरइम्पोज़्ड परतों में व्यवस्थित होता है। खोज ग्राफ़ के शीर्ष पर, सबसे विरल परत पर शुरू होती है, फिर परत दर परत नीचे सबसे प्रासंगिक पड़ोसियों तक जाती है। इस प्रकार खोज का समय लगभग लघुगणकीय हो जाता है, पंक्तियों की संख्या पर रैखिक नहीं।

IVFFlat, pgvector का दूसरा सूचकांक, अलग तरीके से काम करता है: यह किसी भी चीज़ को अनुक्रमित करने में सक्षम होने से पहले, मौजूदा नमूने पर प्रशिक्षण पास द्वारा निर्धारित सूचियों में वेक्टर स्थान को विभाजित करता है। एचएनएसडब्ल्यू में यह बाधा नहीं है, प्रत्येक प्रविष्टि सीधे ग्राफ़ को समृद्ध करती है, जिससे लगातार बढ़ने वाली तालिका पर काम करना आसान हो जाता है। दूसरी ओर, एक HNSW इंडेक्स अधिक मेमोरी की खपत करता है और समान वॉल्यूम पर समकक्ष IVFFlat की तुलना में इसे बनाने में अधिक समय लेता है।

पीजीवेक्टर ने संस्करण 0.5.0 में एचएनएसडब्ल्यू समर्थन पेश किया है। बाद के संस्करण इस गाइड के लिए उपयोगी क्षमताएं जोड़ते हैं: halfvec प्रकार (0.7.0) को 2000 आयामों से अधिक अनुक्रमित करने के लिए, और hnsw.iterative_scan पैरामीटर (0.8.0) फ़िल्टर किए गए प्रश्नों पर रिकॉल में सुधार करने के लिए। यदि आप निर्णय लेने से पहले पीजीवेक्टर की तुलना एक समर्पित वेक्टर आधार से करते हैं, तो हमारी तुलना पीजीवेक्टर बनाम पाइनकोन, वीविएट और क्यूड्रेंट ट्रेड-ऑफ का विवरण देती है।

पहले स्थापित pgvector के संस्करण की पुष्टि करें। एक एक्सटेंशन जो बहुत पुराना है, इस गाइड में कुछ सुविधाओं को चुपचाप विफल कर देता है, विशेष रूप से halfvec और hnsw.iterative_scan।

SELECT extversion FROM pg_extension WHERE extname = 'vector';

HNSW pgvector 0.5.0 के बाद से अस्तित्व में है। 2000 आयामों से परे एम्बेडिंग को अनुक्रमित करने के लिए आवश्यक halfvecप्रकार के लिए कम से कम संस्करण 0.7.0 की आवश्यकता होती है। hnsw.iterative_scan पैरामीटर संस्करण 0.8.0 का अनुरोध करता है।

On Aurabase projects, the question does not arise: the Postgres image embeds pgvector 0.8.6, both on the shared Postgres cluster (docker/Postgres.Dockerfile, built directly on pgvector/pgvector:0.8.6-pg16-bookworm) and on the Postgres 16 CNPG instances dedicated per project (docker/Postgres.CNPG.Dockerfile, which inherits pgvector 0.8.6 from the official CloudNativePG image). 24 अगस्त, 2026 को दोनों डॉकरफाइल्स में सत्यापित।

कॉलम प्रकार आपके एम्बेडिंग के आकार पर निर्भर करता है, न कि केवल उस मॉडल पर जो उन्हें उत्पन्न करता है। pgvector एक क्लासिक वेक्टर को vectorप्रकार में संग्रहीत करता है, भंडारण में 16,000 आयामों की सीमा के साथ। लेकिन इस प्रकार पर HNSW अनुक्रमण 2000 आयामों तक सीमित है: उससे आगे, CREATE INDEX विफल रहता है।

सामान्य एम्बेडिंग मॉडल अक्सर इस सीमा से अधिक होते हैं: ओपनएआई से टेक्स्ट-एम्बेडिंग-3-लार्ज या Google से जेमिनी-एम्बेडिंग-2 मूल रूप से 3072 आयामों तक का उत्पादन करते हैं। इन वैक्टरों को HNSW के साथ अनुक्रमित करने के लिए, कॉलम को halfvec (भंडारण परिशुद्धता आधा कर दिया गया) पर डालें, जो अनुक्रमण सीमा को 2000 आयामों से भी आगे बढ़ा देता है।

ऑराबेस आरएजी इंजन उत्पादन में इस समझौते को दर्शाता है: समर्थित आयामों के तीन वर्ग (768, 1536, 3072), एक ही embeddingsतालिका के तीन अलग-अलग स्तंभों में संग्रहीत। कॉलम 768 और 1536 को सीधे HNSW में vectorप्रकार पर अनुक्रमित किया गया है। कॉलम 3072 को ::halfvec(3072)कास्ट के माध्यम से अनुक्रमित किया गया है, सटीक रूप से 2000 आयाम कैप को दरकिनार करने के लिए।

CREATE INDEX idx_embeddings_vec_768 ON embeddings
  USING hnsw (embedding_768 vector_cosine_ops)
  WHERE embedding_768 IS NOT NULL;

CREATE INDEX idx_embeddings_vec_1536 ON embeddings
  USING hnsw (embedding_1536 vector_cosine_ops)
  WHERE embedding_1536 IS NOT NULL;

CREATE INDEX idx_embeddings_vec_3072 ON embeddings
  USING hnsw ((embedding_3072::halfvec(3072)) halfvec_cosine_ops)
  WHERE embedding_3072 IS NOT NULL;

For details of ingestion (chunking, call to the embedding provider, insertion), see the RAG pipeline tutorial on pgvector.

पीजीवेक्टर के डिफ़ॉल्ट मानों के साथ, न्यूनतम सिंटैक्स पहले इंडेक्स के लिए पर्याप्त है।

CREATE INDEX ON items
  USING hnsw (embedding vector_cosine_ops);

pgvector फिर m = 16 और ef_construction = 64लागू करता है। इन मानों को स्पष्ट रूप से समायोजित करने के लिए, WITH क्लॉज का उपयोग करें:

CREATE INDEX ON items
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 24, ef_construction = 100);

पैरामीटर m क्या बदलता है?

m कनेक्शन की अधिकतम संख्या निर्धारित करता है जो ग्राफ़ में प्रत्येक नोड प्रति परत बनाए रखता है। एक उच्च मान ग्राफ़ को सघन करता है: रिकॉल बढ़ता है, लेकिन मेमोरी की खपत और निर्माण समय भी बढ़ता है, लगभग रैखिक रूप से। अधिकांश मामलों के लिए डिफ़ॉल्ट (16) उपयुक्त है। 24 या 32 तक जाना विशेष रूप से बड़े एम्बेडिंग पर उचित है, जहां निकट और दूर के पड़ोसियों के बीच अंतर महीन हो जाता है।

ef_construction क्या बदलता है?

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

एक ही तालिका में कई आयाम वर्गों के लिए आंशिक सूचकांक

जब एक तालिका कई वेक्टर कॉलम (एक प्रति आयाम वर्ग, जैसा कि ऑराबेस करता है) संग्रहीत करती है, तो प्रत्येक कॉलम को WHERE colonne IS NOT NULLक्लॉज के साथ अलग से अनुक्रमित करें। यह आंशिक सूचकांक किसी दिए गए लाइन द्वारा उपयोग नहीं किए जाने वाले वर्गों के लिए खाली लाइनों को अनुक्रमित करने से बचाता है, जो सूचकांक के आकार को कम करता है और बिना कुछ भी याद किए इसके निर्माण को गति देता है।

ऑपरेटर वर्ग (vector_cosine_ops, vector_l2_ops या vector_ip_ops) का चयन उस मीट्रिक के अनुरूप होना चाहिए जिस पर एम्बेडिंग मॉडल को प्रशिक्षित किया गया था। सबसे हालिया टेक्स्ट एम्बेडिंग मॉडल को कोसाइन समानता के लिए प्रशिक्षित किया जाता है: vector_cosine_ops (या कास्ट कॉलम पर halfvec_cosine_ops) इसलिए सबसे सुरक्षित डिफ़ॉल्ट विकल्प है।

ef_search प्रत्येक क्वेरी पर सेट होता है, न कि जब इंडेक्स बनाया जाता है। यह खोज के दौरान खोजे गए उम्मीदवारों की सूची का आकार निर्धारित करता है: यह जितना अधिक होगा, लंबी विलंबता की कीमत पर, वापस बुलाना उतना ही बेहतर होगा। pgvector अपना डिफ़ॉल्ट मान 40 पर सेट करता है।

SET LOCAL hnsw.ef_search = 100;

SELECT id, content
FROM embeddings
ORDER BY embedding <=> '[...]'::vector
LIMIT 10;

जैसे ही कोई क्वेरी वेक्टर खोज को इंडेक्स को स्कैन करने के बाद लागू किए गए WHERE फ़िल्टर के साथ जोड़ती है (नेमस्पेस, किरायेदार, या किसी अन्य मेटाडेटा मानदंड पर) तो 40 शायद ही पर्याप्त होता है। The HNSW scan brings back ef_search raw candidates, then the filter discards part of them. If too few candidates survive, the final LIMIT ends up underfilled.

इसलिए ऑराबेस RAG इंजन 40: ef = max(top_k × 4, 64)के निश्चित मान को बनाए रखने के बजाय, अनुरोधित top_kके अनुसार गतिशील रूप से ef_search का विस्तार करता है। 5 निकटतम परिणामों की खोज ef_search = 64का उपयोग करती है; शीर्ष 50 उपयोगों की खोज ef_search = 200। यह फॉर्मूला उन तैनाती के लिए प्रति पर्यावरण चर के अनुसार समायोज्य रहता है जिन्हें एक और रिकॉल/विलंबता ट्रेडऑफ़ की आवश्यकता होती है।

pgvector 0.8 adds a second lever for this same problem: hnsw.iterative_scan. strict_order या relaxed_orderमोड में, खोज धीरे-धीरे अपनी खोज को विस्तृत करती है जब तक कि यह फ़िल्टर करने के बाद पर्याप्त परिणाम एकत्र नहीं कर लेती, बजाय उम्मीदवारों की एक निश्चित सूची पर रुकने के। Aurabase activates it by default in strict_order, but protects the call in a savepoint. On a version of pgvector before 0.8, where this parameter does not exist, the query continues in degraded mode rather than failing.

यह एचएनएसडब्ल्यू इंडेक्स संपूर्ण आरएजी पाइपलाइन का सिर्फ एक टुकड़ा है: चंकिंग, एम्बेडिंग जेनरेशन, अंतर्ग्रहण, फिर खोज। हमारा चरण-दर-चरण ट्यूटोरियल इस पाइपलाइन को पहले सम्मिलन से लेकर समानता क्वेरी तक, pgvector पर शुरू से अंत तक बनाता है। तकनीकी दस्तावेज पोस्टग्रेज़ पर निर्मित ऑराबेस की सभी मूल AI क्षमताओं का भी विवरण देता है।