- Meta Superintelligence(MSI) का पहला शोध परिणाम REFRAG मौजूदा RAG(Retrieval-Augmented Generation) संरचना में बड़ा सुधार करके 30 गुना तेज़ response speed हासिल करने वाला एक नया approach है
- इसका मुख्य विचार document fragments को tokens की बजाय ऐसे ‘Chunk Embedding’ रूप में बदलना है जिसे LLM सीधे समझ सके, और ज़रूरत पड़ने पर उसका केवल कुछ हिस्सा restore करने के लिए एक policy network लाना है
- इससे KV cache और attention cost में बड़ी कमी आती है, और first-token response delay (TTFT) घटता है, जिससे UX बेहतर होता है और साथ ही operating cost भी कम होती है
- पेपर model architecture innovation की बजाय system·application layer की efficiency पर फोकस करता है, और ऐसी तकनीकी दिशा दिखाता है जिससे तुरंत ROI हासिल किया जा सके
- यह बड़े models की performance limitations और cost issues को bypass करते हुए, आगे AI products की economics को फिर से परिभाषित करने की क्षमता दिखाता है
MSI के पहले पेपर के सार्वजनिक होने की पृष्ठभूमि
- Meta Superintelligence(MSI) research lab ने industry के top talent और असाधारण salary packages की वजह से काफी ध्यान खींचा है
- MSI का अपने पहले पेपर के लिए practical RAG(retrieval-augmented generation) विषय चुनना काफी असामान्य है
- industry को उम्मीद थी कि MSI foundation models की performance improvement या नई architecture development पर ध्यान देगा, लेकिन उसने ऐसा practical और economic-impact वाला विषय चुना जिसका असर तुरंत दिख सकता है
- RAG AI agents, search, customer support, summarization जैसी commercial services का core component है, और response latency व cost का business model पर सीधा असर पड़ता है
- यह पेपर RAG-आधारित AI products की cost और latency को बड़े पैमाने पर कम करने का तरीका सुझाता है, जिससे तुरंत ROI (investment return) पैदा किया जा सकता है
REFRAG की तकनीकी संरचना
- 1. मौजूदा RAG तरीका vector DB से संबंधित documents (chunks) खोजता है, और LLM उन सभी chunks को पूरे token form में लेकर process करता है
- 2. REFRAG में documents को chunks में split (लगभग 128 tokens) करने के बाद, हर chunk को lightweight encoder embedding single vector में बदलता है और उसे LLM के embedding space में project करता है
- इन embeddings को पहले से calculate करके cache किया जा सकता है
- 3. जब user query आती है, तब संबंधित chunks retrieve किए जाते हैं
- ज़्यादातर chunks embedding form में LLM को भेजे जाते हैं, और
- RL-based policy network द्वारा चुने गए बहुत कम chunks को ही full token sequence के रूप में expand करके भेजा जाता है
- 4. यह policy network RL (reinforcement learning) objective के साथ optimize किया जाता है, ताकि सीमित budget के भीतर वही chunks चुने जाएँ जिन्हें expand करना ज़रूरी है
- इसे generation quality बनाए रखते हुए perplexity घटाने वाले reward function से train किया जाता है
- 5. LLM इनपुट में मिली token sequence (query + expanded chunks) और कई single-vector placeholders (compressed chunks) को मिलाकर text generation करता है
- नतीजतन LLM को “query + restore किए गए कुछ tokens + कई embedding vectors” मिलते हैं, और वह छोटे input से वही output generate कर सकता है
- इस संरचना के कारण cache usage, attention computation, और initial response time सभी में बड़ी कमी आती है
तकनीकी महत्व और मुख्य insight
- पेपर का मुख्य बिंदु यह है कि policy network, RAG process के भीतर कम महत्वपूर्ण chunks को प्रभावी ढंग से compress करता है, और सिर्फ ज़रूरी हिस्सों को expand करने की policy अपनाता है
- इससे भी महत्वपूर्ण छिपी हुई insight यह है कि “अगर embeddings पहले से LLM की internal layers में बनती हैं, तो उन्हें दोबारा natural language में खोलने की ज़रूरत नहीं; embedding को सीधे भेजा जा सकता है”
- यानी LLM जिस representation space को पहले से समझता है, उसमें data को सीधे process करके redundant compression step हटाया जा सकता है, और accuracy loss के बिना speed को बहुत बढ़ाया जा सकता है
- इसे इस नज़रिए से संक्षेप में कहा जा सकता है: “tokens को optimize मत करो, token की अवधारणा ही बदल दो”
मौजूदा AI value chain में इसका महत्व
- LLM क्षेत्र में innovation के दो vector की तुलना
- model-level innovation: नई architecture, बड़ा model, नई pre-training
- high risk, high return, लंबी timeline, और बड़े capital की ज़रूरत
- application/system-level efficiency: inference optimization, retrieval techniques, orchestration
- कम जोखिम, तुरंत ROI, और direct monetization संभव
- REFRAG इसी दूसरे रास्ते पर है, और प्रति GPU throughput बढ़ाने, operating cost घटाने, और UX सुधारने जैसा स्पष्ट ROI देता है
- enterprise और product teams REFRAG approach को वास्तव में adopt करके प्रति GPU throughput बढ़ोतरी, infra cost reduction, और UX enhancement का तुरंत test कर सकते हैं
- यह तरीका retriever और reranker के साथ स्वतंत्र रूप से combine किया जा सकता है, इसलिए मौजूदा RAG pipeline में इसे लचीले ढंग से लागू किया जा सकता है
- खासकर vectorDB market में competition बढ़ने के बीच, Pinecone की संभावित sale जैसी industry movements के संदर्भ में RAG efficiency improvement एक बेहद समयोचित research topic है
संभावित सीमाएँ
- training और engineering complexity
- encoder + projection जोड़ना पड़ता है और LLM को embeddings समझने के लिए train करना होता है (reconstruction pre-training + SFT)
- selective policy RL problem के रूप में stable हो सकती है, लेकिन development complexity बढ़ाती है
- compression limits
- बहुत aggressive compression से आखिरकार downstream quality घट सकती है
- embedding size और expansion frequency के बीच trade-off मौजूद है
- freshness issue
- precomputed chunk embeddings static corpus के लिए उपयुक्त हैं
- जो data बार-बार बदलता है, उसके लिए embedding recalculation pipeline या hybrid strategy की ज़रूरत हो सकती है
- use-case specific considerations
- summarization लगभग अनुमानाधारित हो सकती है, जबकि precision-critical tasks (legal reasoning, exact citation, sensitive medical facts) के लिए सावधानी से evaluation ज़रूरी है
- ऐसे मामलों में कम compression budget की ज़रूरत पड़ सकती है
निष्कर्ष और संकेत
- पेपर का मूल प्रश्न: "token cost को optimize करने की कोशिश करने के बजाय, अगर पूरी तरह अलग तरह के tokens इस्तेमाल किए जाएँ तो क्या होगा?"
- REFRAG “LLM द्वारा पढ़े जाने वाले tokens की अवधारणा को फिर से परिभाषित” करके, RAG की structural limits को कम करता है और AI products की unit economics बदलने वाला practical innovation पेश करता है
- आगे की विस्तार-क्षमता
- अगर LLM READ पक्ष में embedding-native बन सकता है, तो क्या WRITE पक्ष में भी embedding-native बनकर पूरे agent को 30 गुना तेज़ किया जा सकता है?
- embedding models की token-per-cost लगभग शून्य है — क्या यह किसी दूसरी architecture की ओर जाकर token pricing को बहुत कम करने जैसा है? इसके downside क्या हैं?
- REFRAG यह याद दिलाता है कि हर innovation बड़े models से ही नहीं आती
- बड़े scale पर RAG को सस्ता और तेज़ बनाना product economics पर सीधा lever है
- industry उन teams को reward करेगी जो ऐसी जीत को operationalize कर सकें
1 टिप्पणियां
Hacker News प्रतिक्रिया
यह समझाया गया है कि इस पेपर का सुपरइंटेलिजेंस से कोई संबंध नहीं है; इसे उस टीम ने प्रकाशित किया था जो संगठनात्मक पुनर्गठन से पहले इस पर शोध कर रही थी, और नाम बदलने के बाद पेपर जारी हुआ। कई लोगों ने अनुमान लगाया था कि Meta अब पेपर प्रकाशित नहीं करेगा और OpenAI की तरह हो जाएगा, लेकिन Meta अब भी तेज़ी से पेपर प्रकाशित कर रहा है और open-weight मॉडल जारी कर रहा है
इस बात पर ज़ोर दिया गया है कि Meta जो जारी करता है वह open source नहीं, बल्कि open-weight मॉडल है। यहाँ तक कि इन weights के लाइसेंस भी Apache 2 से अधिक सख्त हैं
इस बात पर भी ज़ोर दिया गया है कि MSL (वह टीम) केवल कुछ मशहूर लोगों से मिलकर नहीं बनी है
RAG(Retrieval-Augmented Generation) पर चर्चा में इसके कई अर्थों में इस्तेमाल होने से भ्रम महसूस हो रहा है। मेरे लिए RAG वह सिस्टम है जिसमें पहले से परिभाषित दस्तावेज़ संग्रह के हर टुकड़े को vector embedding में बदला जाता है और ज़रूरत पड़ने पर केवल कुछ खास टुकड़ों को context में शामिल किया जाता है। या फिर LLM chat interface में keyword से web search करके केवल संदर्भित दस्तावेज़ों को अस्थायी रूप से context में डालने की सुविधा। सोच रहा हूँ कि लंबे context window के समर्थन के बाद क्या होगा। अगर सारी जानकारी एक साथ context में डाल दी जाए, तो विविधता घटने की चिंता है; इससे consistency में मदद मिल सकती है, लेकिन आख़िर में कौन-सी जानकारी रखनी है और कौन-सी हटानी है, यह तय करने का तरीका भी क्या RAG ही नहीं होगा? किसी विशेषज्ञ की व्याख्या सुनना चाहता हूँ
तकनीकी रूप से RAG बाहरी retrieval से generation को सहारा देने वाली हर तकनीक है। लेकिन आम तौर पर इसका अर्थ सीमित होकर vector DB वाले तरीक़े तक रह जाता है। बड़े context window में सारी जानकारी भर देना व्यावहारिक नहीं है। processing में ज़्यादा समय लगता है, और जानकारी बहुत अधिक होने पर मॉडल के लिए ज़रूरी जानकारी ढूँढना मुश्किल हो जाता है। नतीजतन, जहाँ low latency चाहिए या memory सीमाएँ हों, वहाँ ‘क्लासिक’ RAG तरीका अब भी उपयोगी है
मुख्य बात adaptability है। RAG और non-RAG के बीच बड़ा अंतर यह है कि index बनाते समय सवाल पता होता है या नहीं, और retrieved documents के बीच आपसी तुलना तथा सवाल को और विभाजित करने की क्षमता है या नहीं। Non-RAG एक अधिक सामान्य दृष्टिकोण है और deep learning optimization के लिए आसान है, क्योंकि यह multi-layer non-causal transformer आदि के ज़रिए सवाल और दस्तावेज़ों को एक साथ देखता है। दूसरी ओर RAG तेज़ और सस्ता है, लेकिन बाहरी टूल इस्तेमाल करने के कारण end-to-end training कठिन होती है (RL जैसी reward learning की ज़रूरत पड़ती है)। RAG में दस्तावेज़ स्वतंत्र होते हैं और indexing के समय सवाल ज्ञात नहीं होता। Hybrid रूप में RAG के output को Non-RAG में डालकर संयोजन करने का तरीका भी है। Non-RAG को बड़े dataset चाहिए, लेकिन अगर पूरे web को train कराया जाए तो performance लगातार बेहतर हो सकती है। specific case में performance सुधारना भी अपेक्षाकृत आसान है। RAG की ताकत input control और structured data में है, और यह worst case से बचाने में सहायक है, लेकिन best case सुधारना कठिन है
मेरा मानना है कि context में अनंत मात्रा में जानकारी नहीं डाली जा सकती। मेरे अनुभव में GPT-5 कुछ पन्नों के बाद ही जल्दी भ्रमित हो जाता है। इतनी बड़ी मात्रा डालने पर भी वह उसे याद नहीं रख पाता
मुझे नहीं लगता कि वास्तव में कोई कह रहा है कि “RAG मर चुका है।” पूरे इंटरनेट को LLM context में डालना असंभव है, और जितना अधिक डालेंगे, लागत उतनी ही बढ़ेगी
Meta में शीर्ष स्तर के लोग थे, लेकिन लगता है कि उनकी क्षमता का पूरा उपयोग नहीं हो पाया। मेरी नज़र में अगर केवल performance metrics पर ज़रूरत से ज़्यादा ज़ोर न देकर शोधकर्ताओं को autonomy दी जाए, तो AI प्रतिस्पर्धा में और आगे निकला जा सकता है। नई टीम को देखकर लगता है कि उसमें systems बनाने में सक्षम लोग और पैसे में अधिक रुचि रखने वाले लोग केंद्र में हैं। सच कहें तो किसी भी big tech research lab में यह प्रवृत्ति साफ़ दिखती है। ये संगठन बहुत ज़्यादा risk-averse हो गए हैं। पहले शोधकर्ताओं को स्वतंत्रता दी जाती थी, और उसी से आज का Silicon Valley बना। मुझ सहित सैकड़ों ML researchers autonomy और resources मिलें तो इससे कम वेतन पर भी खुशी से काम करना चाहेंगे। Meta को अभी जो पैसा वह निवेश कर रहा है, उसे थोड़ा अधिक विविध तरीक़े से इस्तेमाल करते हुए उन सिद्धांतों पर लौटने की ज़रूरत है जिन्होंने Silicon Valley को बढ़ाया
मेरे हिसाब से, जैसे-जैसे प्रतिस्पर्धी बढ़ते हैं, ‘वास्तविक प्रतिभाशाली’ लोगों की तुलना में सिस्टम को अच्छी तरह समझकर खेलना जानने वाले लोग शीर्ष पर बने रह जाते हैं। GAFAM में नौकरी के आवेदन या Tinder के उदाहरणों में भी ऐसी प्रवृत्ति दिखती है
मुझे नहीं लगता कि corporate labs द्वारा शोधकर्ताओं को स्वतंत्रता देने से वास्तव में कारोबार को मदद मिलती है। Bell Labs या Microsoft Research जैसे उदाहरण देखें तो बहुत शानदार शोध हुए, लेकिन कंपनी के मुख्य व्यवसाय से उनका जुड़ाव बहुत कम था। मुद्दा यह है कि AI research Meta को प्रत्यक्ष revenue या competitiveness देने के बजाय सामूहिक ज्ञान ही बढ़ा रहा है। कंपनी के नज़रिए से यह तरीका बहुत उपयुक्त नहीं बैठता। उल्टा अगर शोधकर्ता बनें भी, तो आज academia में भी छात्र प्रबंधन और बैठकों में काफ़ी समय चला जाता है
AI की प्रगति की रफ़्तार धीमी पड़ गई है, इस दावे पर संदेह है। पूछा गया है कि इसे किस आधार पर मापा जा रहा है। जो लोग वास्तव में इस क्षेत्र को follow कर रहे हैं, उनके लिए इस दावे से सहमत होना मुश्किल है
Meta के दबाव वाले माहौल में भी, हमेशा यह जिज्ञासा रही कि क्या बहुत ऊँचा वेतन पाने वाले गणितज्ञों के पास वास्तव में स्वतंत्र रूप से सोचने का समय होगा
Alex Wang का चयन दिलचस्प लगा। बेहतरीन AI lab CEOs बहुत हैं, और Wang में कुछ असाधारण बातें हैं, लेकिन वास्तविकता में यह लगभग MTurk और market timing की कहानी थी। AGI का नेतृत्व करने वाले CEO के रूप में वह उपयुक्त नहीं लगता
यह बात अप्रत्याशित लगी कि नई lab का पहला पेपर इतना व्यावहारिक और यथार्थवादी RAG पर था। आम तौर पर नई lab में शुरुआत में लोग अपने-अपने पुराने विषयों पर कुछ पेपर प्रकाशित करते हैं, और जब teamwork तथा synergy पर्याप्त बन जाती है, तभी वास्तव में innovative research निकलती है। ऐसे महत्वपूर्ण ‘पहले पेपर’ को बहुत ज़्यादा अर्थ देने से शुरुआत से ही अनावश्यक दबाव बढ़ सकता है
यह जानने की जिज्ञासा है कि Meta की superintelligence team से आया यह पेपर वास्तव में उसी टीम में सीधे योजनाबद्ध हुआ था, या फिर पहले से काम कर रहे लोग team बदलने के बाद इसे प्रकाशित कर रहे थे। अनुमान है कि पहला मामला अधिक संभावित है
RAG पेपर पर एक YouTube व्याख्या वीडियो को संक्षेप में साझा किया गया है वीडियो लिंक
पेपर के graphs और tables में TF-IDF या साधारण शब्द ओवरलैप जैसी मौजूदा, आसान और सांख्यिकीय context compression तकनीकों से तुलना तुरंत दिखाई नहीं दी। उद्योग में ऐसे सरल तरीक़े बहुत महत्वपूर्ण होते हैं, क्योंकि performance लगभग समान रहते हुए वे जानकारी की मात्रा को 10 गुना तक घटा सकते हैं
ऐसा ही एक विचार सोचकर लागू करने का अनुभव रहा है। आगे चलकर LLM के लिए विभिन्न embedding formats को और आसानी से संभालने योग्य बनाने हेतु, इसे सरल करने वाला framework चाहिए
RAG से संबंधित open-source project का लिंक साझा किया गया है REFRAG
लेख का शीर्षक बहुत सनसनीखेज़ है, इसलिए अधिक सूचनात्मक और कम clickbait शीर्षक की इच्छा जताई गई है