पाठ 28 / 28

Revision: Cheat Sheet और Self-Check

पूरे कोर्स के मुख्य विचार दोहराएँ।

Cheat sheet

क्या: vector database = टिकाऊ भंडारण + ANN index + payload filters + अद्यतन + संचालन; परिवार: library, extension (pgvector), समर्पित engine (Qdrant, Milvus, Weaviate, Chroma), managed सेवा। मॉडल: records (id, vector, payload) की collection; प्रति collection समान आयाम और metric; निश्चित IDs। pgvector: vector(n), operators <-> L2, <=> cosine दूरी, <#> ऋणात्मक inner product; ORDER BY ... LIMIT k; operator class मिलाएँ; SQL filters, joins, transactions, RLS, halfvec। Indexes: पहले सटीक scan (ground truth); HNSW (m, ef_construction, ef_search) बनाम IVFFlat (lists, probes); index vectors से बड़ा हो सकता है; सटीक के विरुद्ध recall@k मापें। Filtering: post-filtering बहुत कम rows लौटा सकती है (हमने 0 देखा); iterative scans, partial indexes या partitions, payload indexes वाले filter-जागरूक engines; RRF के साथ hybrid search। Scale: batch idempotent ingestion; hash की key से shard (resharding अधिकांश डेटा हिलाता है); replicate, W + R > N; क्षमता = vectors + links + payload, प्रतियों से गुणा, साथ में गुंजाइश। संचालन: database में tenant अलगाव, TLS और encryption, न्यूनतम विशेषाधिकार; backups और परखे restores; नया मॉडल = shadow तुलना और rollback के साथ नया index; recall, latency percentiles, ताज़गी, लागत मॉनिटर करें। चुनाव: सरल और सटीक से शुरू; समान recall पर अपने डेटा पर तुलना; ईमानदार benchmarks।

त्वरित जाँच: आप HNSW query में `WHERE tenant = 7` filter जोड़ते हैं और tenant 7 का डेटा होने पर भी शून्य rows मिलती हैं। संभावित कारण और सुधार क्या है?

  • Index ने डेटा हटा दिया
  • छोटी उम्मीदवार सूची का post-filtering; iterative scans चालू करें या partial indexes/filter-जागरूक खोज उपयोग करें
  • Vectors filter नहीं हो सकते
  • Server घड़ी ग़लत है
Answer

छोटी उम्मीदवार सूची का post-filtering; iterative scans चालू करें या partial indexes/filter-जागरूक खोज उपयोग करें — Index पहले निकटतम उम्मीदवार लौटाता है; filter फिर उन्हें हटाता है।

त्वरित जाँच: HNSW tuning के बारे में कौन-सा कथन सही है?

  • ef_search का कोई प्रभाव नहीं
  • ef_search बढ़ाने से recall और latency बढ़ती हैं; सटीक खोज के विरुद्ध recall मापें
  • कम ef_search हमेशा recall सुधारता है
  • Recall मापा नहीं जा सकता
Answer

ef_search बढ़ाने से recall और latency बढ़ती हैं; सटीक खोज के विरुद्ध recall मापें — Recall और latency ef_search knob पर समझौता करते हैं।

त्वरित जाँच: आपका cluster हर shard की 3 प्रतियाँ रखता है। कौन-सी write और read settings आपके नवीनतम acknowledged write को पढ़ने की गारंटी देती हैं?

  • कोई मायने नहीं रखता
  • 1 पर लिखें और 1 से पढ़ें
  • 1 पर लिखें और भाग्य से 2 से पढ़ें
  • 2 पर लिखें और 2 से पढ़ें
Answer

2 पर लिखें और 2 से पढ़ें — W + R > N गारंटी देता है कि write और read समूह overlap करते हैं।