- Jeff Dean की 3 अरब vector query समस्या के कारण, optimal map-reduce solution को खुद implement करने की प्रक्रिया पर आधारित एक technical experiment record
- 768-आयामी float32 vectors के 3 अरब सेट और 1,000 query vectors के dot product की naive implementation से शुरुआत कर, numpy vectorization और float32 conversion के जरिए चरणबद्ध performance improvement हासिल किया गया
- 3,000 vectors के आधार पर naive तरीका लगभग 2 सेकंड से vectorization के बाद 0.01 सेकंड, और float32 लागू करने पर 0.0045 सेकंड तक घट गया
- 3 अरब scale तक विस्तार करने पर result matrix के लिए लगभग 8.6TB memory की जरूरत पड़ती है, जिससे OOM समस्या आती है; batch processing, memory mapping, Rust/C rewrite, SimSIMD जैसी अतिरिक्त optimization की जरूरत होती है
- यह रेखांकित किया गया है कि technical solution से भी अधिक कठिन मुख्य चुनौती requirements definition है (return format, machine specs, compression allowance आदि)
समस्या की शुरुआत
- Jeff Dean और 3 अरब vector query समस्या पर हुई चर्चा को देखकर, optimal map-reduce solution को खुद implement करने की कोशिश से शुरुआत हुई
- vector
n dimensions वाले floating-point numbers की array होते हैं, और vector search का उपयोग अर्थ की दृष्टि से समान शब्दों या items को खोजने के लिए किया जाता है
- search, recommendation, और Cursor जैसे generative search applications में embeddings के उपयोग का यह एक सामान्य pattern है
Naive implementation
- शुरुआती मान्यता: 3 अरब target (document) vectors और लगभग 1,000 query vectors, सभी disk पर
.npy format में stored हैं
- vector dimension 768 है, जो कई similarity-based embedding query models में इस्तेमाल होने वाला सामान्य आकार है
- हर query vector को सभी document vectors से तुलना कर dot product निकालने और result लौटाने वाले double-loop तरीके का उपयोग
- पहले 3,000 vectors पर test करने पर, M2 MacBook पर लगभग 2 सेकंड लगे (जो 3 अरब की तुलना में 10 लाख गुना छोटा scale है)
Vectorized optimization
- numpy के matrix multiplication operation (
vectors_file @ query_vectors.T) से double loop को बदलने वाला vectorized approach लागू किया गया
- 3,000 vectors के आधार पर समय 0.0107 सेकंड तक काफी कम हुआ
- 30 लाख vectors तक scale बढ़ाने पर 12.85 सेकंड लगे
float32 conversion
- data को
np.float32 में बदलकर अतिरिक्त optimization किया गया
- 3,000 vectors के आधार पर समय 0.0045 सेकंड तक घटा
- 30 लाख vectors पर लगभग 13 सेकंड लगने के आधार पर, 3 अरब पर इसका 1,000 गुना यानी लगभग 3,216 मिनट लगने का अनुमान है
Performance comparison summary
- Naive method (3,000 vectors): 1.9877 सेकंड
- Vectorized method (3,000 vectors): 0.0107 सेकंड
- Vectorized method (30 लाख vectors): 12.8491 सेकंड
- float32 method (3,000 vectors): 0.0045 सेकंड
OOM समस्या और आगे की optimization दिशा
- 3 अरब objects को float32 (4 bytes) में process करने के लिए जरूरी memory: लगभग 8.6TB, और execution के दौरान OOM होता है
- Jeff Dean द्वारा सुझाई गई दिशा में अतिरिक्त optimization की जरूरत:
- generator और batch comparison operations के जरिए code में बदलाव
- निश्चित interval पर disk पर write करना या memory mapping का उपयोग
- Rust या C में system-level optimization code का rewrite
- SimSIMD जैसी large-scale vector similarity comparison के लिए dedicated library का उपयोग
Requirements definition का महत्व
- आगे optimization से पहले, समस्या के भीतर कई अस्पष्ट बिंदु सामने आए:
- क्या एक single query vector से 3 अरब पूरे dataset पर एक बार query कर पूरा result लौटाना है, या top-k ANN search करना है
- क्या original vectors भी साथ लौटाने हैं, और similarity के आधार पर re-ranking की जरूरत है या नहीं
- क्या 1,000 query vectors से पूरे dataset पर एक बार query करनी है
- क्या vectors पहले से memory में हैं, disk से एक-एक करके पढ़े जाते हैं, या streaming approach है
- क्या इसे local पर चलाना है, machine specs क्या हैं, और GPU उपलब्ध है या नहीं
- embedding size का result representation और input-output vector size पर क्या असर है
- क्या float64 से float32 में compression accuracy के लिहाज से स्वीकार्य है
- क्या यह one-off project है, और इसे बनाने के लिए कितना समय दिया गया है
- technical solution से भी बढ़कर सबसे कठिन काम requirements को सटीक रूप से define करना है
अभी कोई टिप्पणी नहीं है.