वेक्टर सर्च हर RAG सिस्टम और हर याद रखने वाले एजेंट पर लगा वह खामोश स्केलिंग टैक्स है। embedding सिर्फ बढ़ते हैं, और किसी बिंदु पर मेमोरी का बिल क्वांटाइज़ेशन के लिए मजबूर कर देता है — वेक्टर छोटे करो, recall में एक चोट खाओ। 11 मई को जारी Qdrant 1.18 में TurboQuant जुड़ा, और जो फ्रेमिंग मायने रखती है वह वही है जो इसकी अपनी डॉक्यूमेंटेशन सबसे आगे रखती है: "क्या हम वेक्टर छोटे कर सकते हैं" नहीं, बल्कि "क्या हम उन्हें उनकी ज्यामिति तोड़े बिना छोटा कर सकते हैं"। यही सही सवाल है, क्योंकि recall ज्यामिति है — अगर क्वांटाइज़ेशन दूरियों को असमान रूप से विकृत करता है, तो आपके निकटतम पड़ोसी निकटतम रहना बंद कर देते हैं।
TurboQuant का तंत्र है कंप्रेशन से पहले लगाया गया एक रैंडम ऑर्थोगोनल रोटेशन, फिर एक तय codebook। embedding अनिसोट्रॉपिक होते हैं — मुट्ठी भर डाइमेंशन अधिकांश वेरिएंस उठाते हैं (जिस DBpedia OpenAI सेट पर वे बेंचमार्क करते हैं, उसमें सबसे तेज़ और सबसे कमज़ोर डाइमेंशन के बीच 233.5x का अनुपात है)। स्केलर क्वांटाइज़ेशन हर डाइमेंशन को बराबर मानता है, इसलिए मरे डाइमेंशन पर बिट बर्बाद करता है और जीवित को भूखा रखता है। product quantization इसे प्रति-सबस्पेस codebook से ठीक करता है, पर उन्हें प्रति-डेटासेट ट्रेनिंग चाहिए और डेटा खिसकने पर वे पुराने पड़ जाते हैं। TurboQuant का रोटेशन पहले वेरिएंस को सभी डाइमेंशन पर समान रूप से फैला देता है, इसलिए एक तय समान codebook अब लगभग इष्टतम है — और चूँकि रोटेशन रैंडम और स्थिर है, पूरी चीज़ data-oblivious है। कोई ट्रेनिंग नहीं, इंजेस्ट पर कोई रीकैलिब्रेशन नहीं। संख्याएँ, 1536-डाइमेंशन DBpedia पर: TQ 4-bit ~8x कंप्रेशन पर recall@10 0.965 (rescoring के साथ 0.996), लेटेंसी 6.4ms बनाम float32 की 7.6ms, स्टोरेज 72 MB जहाँ स्केलर क्वांटाइज़ेशन को 144 चाहिए। ईमानदार चेतावनियाँ भारी हैं। सुर्खियों वाला 32x TQ 1-bit है, जिसे लेखक सीधे "सुरक्षित विकल्प नहीं" कहता है — recall ढह जाता है। उपयोगी संख्या 4-bit पर 8x है। 0.996 recall rescoring पर टिका है, जिसका मतलब री-रैंक के लिए पूरे वेक्टर रखना, स्टोरेज के फायदे का कुछ हिस्सा वापस देना। बाइनरी क्वांटाइज़ेशन कच्चे थ्रूपुट में अब भी तेज़ है; TurboQuant पैमाने पर recall स्थिरता में जीतता है (0.965 जहाँ बाइनरी 100K पर 0.78 तक गिरता है), गति में नहीं। और इसे ठीक एक डेटासेट पर परखा गया — एक अधिकतम अनिसोट्रॉपिक डेटासेट, जो रोटेशन-आधारित विधि के लिए सबसे अनुकूल स्थिति है। ज़्यादा सपाट, आइसोट्रॉपिक embedding पर रोटेशन आपको बहुत कम देता है, और वह स्थिति मापी नहीं गई।
यह इकोसिस्टम के साथ जो करता है वह है तेज़ रफ्तार की कमोडिटाइज़ेशन का पैटर्न: Google Research का ICLR 2026 का एक नतीजा हफ्तों में एक ओपन-सोर्स वेक्टर DB में एक लाइन का कॉन्फ़िग फ्लैग बन जाता है। पूरी RAG और agent-memory परत को लगभग इष्टतम, बिना-कैलिब्रेशन क्वांटाइज़ेशन मिलता है, और टीम में किसी को क्वांटाइज़ेशन सिद्धांत समझने की ज़रूरत नहीं। यह उन प्रबंधित वेक्टर DB विक्रेताओं पर भी दबाव डालता है जिनकी पिच में "हम आपके लिए कंप्रेशन ट्यून करते हैं" शामिल है — जब data-oblivious क्वांट एक `bits=4` पैरामीटर है, वह ट्यूनिंग खाई पतली हो जाती है। data-oblivious गुण ही product quantization के बजाय इसे चुनने की खास वजह है: लंबे जीवन वाली एजेंट मेमोरी के लिए जहाँ embedding वितरण आपके इंजेस्ट करते-करते खिसकता है, PQ के सीखे codebook कैलिब्रेशन से बाहर हो जाते हैं और आप दोबारा ट्रेन करते हैं; TurboQuant का रोटेशन परवाह नहीं करता कि आपका डेटा कैसा दिखता है, इसलिए दोबारा ट्यून करने को कुछ नहीं।
सोमवार सुबह, अगर आप पैमाने पर वेक्टर सर्च चलाते हैं: Qdrant 1.18 में TQ 4-bit (1-bit नहीं) को opt-in चालू करें और 8x पर भरोसा करने से पहले अपने खुद के कॉर्पस पर recall@k मापें, rescoring के साथ और बिना। लेखक का अपना निर्देश ही चालू करने योग्य है — ये संख्याएँ अधिकतम अनिसोट्रॉपिक DBpedia से हैं, और आपका embedding वितरण शायद ज़्यादा सपाट है, जो ठीक वहीं है जहाँ रोटेशन सबसे कम भुगतान करता है। 8x-पर-0.965 को सत्यापित करने योग्य एक सीमा मानें, मान लेने योग्य संख्या नहीं। और अगर आपकी दूरी मीट्रिक L1/मैनहैटन है, तो इसे छोड़ दें — TurboQuant को वहाँ पूर्ण पुनर्निर्माण चाहिए और गति का लाभ वाष्पित हो जाता है; स्केलर क्वांटाइज़ेशन ज़्यादा सुरक्षित विकल्प बना रहता है।