अप्रैल 2026 में, Andrej Karpathy ने GitHub Gist लिखा। उन्होंने इसमें एक विधि का वर्णन किया है। वे इस विधि को LLM Wiki कहते हैं।
<p>उसके बाद चार टीमों ने एक ही चीज़ बनाई। Cognition ने DeepWiki बनाया। Factory ने AutoWiki बनाया। LangChain ने OpenWiki जारी किया। Garry Tan ने GBrain जारी किया।</p>
<p>सभी चारों प्रणालियों में विधि एक समान है। एक LLM आपके स्रोत दस्तावेज़ों को एक बार पढ़ता है। वह जानकारी को markdown पेजों में लिखता है। जब स्रोत बदलते हैं तो वह पेजों को सही रखता है। एजेंट इन पेजों को पढ़ता है। एजेंट प्रत्येक प्रश्न के लिए स्रोत दस्तावेज़ों को दोबारा नहीं पढ़ता।</p>
<p>लोग इन प्रणालियों को एजेंट विकी कहते हैं। यह लेख आपको बताता है कि ये क्या हैं। यह बताता है कि प्रत्येक टीम ने क्या बनाया। यह विधि की सीमाएँ बताता है। यह एक महत्वपूर्ण अंतर भी बताता है जिसे बहुत से लोग अनदेखा कर देते हैं।</p>
<h2><strong>विचार: क्वेरी पर नहीं, बल्कि इन्जेस्ट पर संकलन करें</strong></h2>
<p>किसी मॉडल को बड़े दस्तावेज़ सेट देने की सामान्य विधि रिट्रीवल है। आप दस्तावेज़ों को डेटाबेस में रखते हैं। आप दस्तावेज़ों को भागों में विभाजित करते हैं। आप भागों के लिए embeddings बनाते हैं। प्रत्येक प्रश्न के लिए, सिस्टम संबंधित भागों को ढूंढता है।</p>
<p>यह विधि काम करती है। इसमें एक समस्या भी है। सिस्टम परिणामों को संग्रहीत नहीं करता। यह प्रत्येक उत्तर को कच्चे भागों से फिर से बनाता है। दसवाँ उत्तर पहले उत्तर से बेहतर नहीं होता। आप दस बार काम की लागत चुकाते हैं।</p>
<p>एक एजेंट विकी इस लागत को स्थानांतरित करता है। मॉडल एक बार काम करता है, जब वह स्रोत को पढ़ता है। वह परिणामों को पेजों में लिखता है। पेज स्थायी रहते हैं।</p>
<p>जब कोई नया स्रोत आता है तो मॉडल ये कदम उठाता है। वह स्रोत को पढ़ता है। वह संबंधित पेजों को बदलता है। वह सारांशों को सही करता है। वह उस जानकारी को चिह्नित करता है जो पेजों से असहमत है।</p>
<p>दोनों विधियाँ सही हैं। वे दो तरह से भिन्न हैं। पहला अंतर यह है कि आप लागत कब चुकाते हैं। दूसरा अंतर यह है कि प्रश्न के बाद क्या रहता है।</p>
<p>प्रत्येक प्रणाली में एक ही तीन परतें होती हैं।</p>
<p>परत 1 स्रोत दस्तावेज़ हैं। ये आपके लेख, पेपर और रिपॉजिटरी हैं। मॉडल उन्हें पढ़ता है। मॉडल उन्हें नहीं बदलता।</p>
<p>परत 2 विकी है। विकी markdown है। मॉडल पूरी विकी लिखता है। विकी में सारांश, प्रत्येक विषय के लिए पेज और पेजों के बीच लिंक शामिल हैं।</p>
<p>परत 3 स्कीमा फ़ाइल है। यह फ़ाइल मॉडल को विकी की संरचना बताती है। यह यह भी बताती है कि कौन से कार्य करने हैं। सामान्य फ़ाइल CLAUDE.md या AGENTS.md है। यह फ़ाइल मॉडल को विकी का सही रखरखाव करने वाला बनाती है।</p>
<p>सिस्टम तीन कार्य करता है।</p>
<p>इन्जेस्ट: मॉडल एक नया स्रोत पढ़ता है। फिर मॉडल डेटा को प्रत्येक संबंधित पेज पर लिखता है।</p>
<p>क्वेरी: आप विकी से एक प्रश्न पूछते हैं। आप एक अच्छा उत्तर वापस विकी में एक नए पेज के रूप में लिख सकते हैं।</p>
<p>लिंट: मॉडल विकी का परीक्षण करता है। वह असहमत जानकारी ढूंढता है। वह बहुत पुरानी जानकारी ढूंढता है। वह बिना लिंक वाले पेज ढूंढता है।</p>
<h2><strong>यह क्यों काम करता है:</strong></h2>
<p>मानव विकी समय के साथ गलत हो जाती हैं। इसका कारण विशिष्ट है। कठिन हिस्सा स्रोतों को पढ़ना नहीं है। कठिन हिस्सा विचार रखना नहीं है। कठिन हिस्सा रखरखाव है।</p>
<p>रखरखाव में ये कार्य शामिल हैं। आपको पेजों के बीच लिंक को सही करना होगा। आपको सारांशों को सही रखना होगा। आपको प्रत्येक नए दस्तावेज़ की मौजूदा पेजों से तुलना करनी होगी।</p>
<p>यह काम रुकता नहीं है। इस काम का कोई पुरस्कार नहीं है। एक व्यस्त टीम सबसे पहले इस काम को रोकती है। फिर विकी गलत हो जाती है। फिर लोग इसका उपयोग नहीं करते।</p>
<p>एक मॉडल यह काम बिना किसी समस्या के करता है। मॉडल ऊबता नहीं है। मॉडल कोई लिंक नहीं भूलता। मॉडल एक ही कार्य में पंद्रह फ़ाइलें बदल सकता है।</p>
<p>यह विचार पुराना है। Vannevar Bush ने 1945 में Memex का वर्णन किया था। Memex उनके बीच लिंक वाला दस्तावेज़ों का एक व्यक्तिगत भंडार है। Bush के पास रखरखाव का कोई उत्तर नहीं था। मॉडल ही उत्तर है।</p>
<h2><strong>नाम कहाँ से आया</strong></h2>
<p>Karpathy के Gist को सीधे पढ़ें। यह उसके सारांशों से अधिक सटीक है।</p>
<p>वह सामान्य विधि के बारे में यह लिखते हैं: "LLM हर प्रश्न पर शुरू से ज्ञान को फिर से खोज रहा है। कोई संचय नहीं है।"</p>
<p>उनकी विधि जानकारी को पुनः प्राप्त करना नहीं, बल्कि संकलित करना है। फिर "ज्ञान एक बार संकलित किया जाता है और फिर वर्तमान रखा जाता है, हर क्वेरी पर पुनः व्युत्पन्न नहीं किया जाता।" परिणाम "एक स्थायी, संयोजी कलाकृति" है।</p>
<p>आप विकी नहीं लिखते। वह लिखते हैं: "आप कभी (या शायद ही कभी) स्वयं विकी लिखते हैं, LLM यह सब लिखता है और बनाए रखता है।" वह एजेंट और Obsidian का एक साथ उपयोग करते हैं। वह लिखते हैं: "Obsidian IDE है; LLM प्रोग्रामर है; विकी कोडबेस है।"</p>
<p>Gist आकार की एक सीमा देता है। कई सारांश इस सीमा को शामिल नहीं करते। embeddings के बिना विधि "मध्यम पैमाने पर आश्चर्यजनक रूप से अच्छी तरह काम करती है (~100 स्रोत, ~सैकड़ों पेज) और embedding-आधारित RAG बुनियादी ढांचे की आवश्यकता से बचाती है।"</p>
<p>अधिक स्रोतों के लिए, Gist आपको खोज जोड़ने के लिए कहता है। यह उदाहरण के रूप में qmd देता है। Gist qmd को "BM25/वेक्टर हाइब्रिड खोज और LLM पुनः-रैंकिंग के साथ markdown फ़ाइलों के लिए एक स्थानीय खोज इंजन" के रूप में वर्णित करता है।</p>
<p>इस प्रकार नियम आकार के बारे में है। नियम प्रतिस्थापन के बारे में नहीं है। जब स्रोत सेट छोटा हो तो रिट्रीवल बुनियादी ढांचे का उपयोग न करें। जब स्रोत सेट बड़ा हो जाए तो रिट्रीवल जोड़ें।</p>
<h2><strong>प्रयोगशालाओं ने वास्तव में क्या बनाया</strong></h2>
<p>यह वह जगह है जहाँ पैटर्न एक विचार होना बंद कर इंजीनियरिंग बन जाता है, और कार्यान्वयनों के बीच अंतर ही उपयोगी हिस्सा है।</p>
<p><strong>Cognition: DeepWiki, एक सार्वजनिक उपयोगिता के रूप में विकी</strong></p>
<p>Cognition ने इस विधि को GitHub पर सार्वजनिक रिपॉजिटरी पर लागू किया। किसी सार्वजनिक रिपॉजिटरी के URL में github.com को deepwiki.com से बदलें। फिर आपको उस कोडबेस के लिए एक विकी मिलती है। विकी में एक आर्किटेक्चर सारांश, एक फ़ाइल इंडेक्स, एक निर्भरता ग्राफ और खोज होती है। विकी में स्रोत के लिंक होते हैं (Cognition)।</p>
<p>50,000 से अधिक सबसे बड़ी सार्वजनिक रिपॉजिटरी में विकी है। सूची में MCP और LangChain शामिल हैं।</p>
<p>दूसरा बिंदु अधिक महत्वपूर्ण है। विकी उत्पाद नहीं है। विकी एजेंट के लिए रिट्रीवल बुनियादी ढांचा है। Devin कोडबेस में संबंधित कोड खोजने के लिए विकी का उपयोग करता है। DeepWiki इस प्रकार Devin में कोड खोज के नीचे संकलित परत है (Devin Docs)।</p>
<p><strong>Factory: AutoWiki, एक बिल्ड आर्टिफैक्ट के रूप में दस्तावेज़ीकरण</strong></p>
<p>Factory ने इस विधि को सतत एकीकरण पर लागू किया। Factory लिखता है कि दस्तावेज़ीकरण एक बिल्ड आर्टिफैक्ट होना चाहिए, न कि एक अलग प्रोजेक्ट। दस्तावेज़ीकरण स्रोत से आता है। इसमें कोडबेस की संरचना होती है। जब रिपॉजिटरी बदलती है तो यह बदलता है (Factory)।</p>
<p>विकी बनाने की विधि में दो पास हैं। पास 1 एक संरचनात्मक स्कैन है। यह README फ़ाइल, पैकेज मेनिफेस्ट, CI कॉन्फ़िगरेशन और एंट्री पॉइंट पढ़ता है। पास 2 एक सिमेंटिक स्कैन है। यह रूट, API एंडपॉइंट, सेवा क्लासेस, डेटाबेस स्कीमा और फीचर फ्लैग पढ़ता है।</p>
<p>Factory काम को विशेष एजेंटों के बीच विभाजित करता है। प्रत्येक एजेंट को रिपॉजिटरी का एक हिस्सा मिलता है। प्रत्येक एजेंट को एक अच्छा पेज लिखने के लिए पर्याप्त संदर्भ मिलता है। यह विधि एक ज्ञात समस्या को रोकती है: एक अकेला एजेंट एक बड़ी रिपॉजिटरी के लिए खराब दस्तावेज़ीकरण लिखता है।</p>
<p>Factory विकी को बुनियादी ढांचे से सही रखता है, न कि अनुशासन से। /wiki कमांड विकी को फिर से बनाता है। /install-wiki कमांड एक CI वर्कफ़्लो लिखता है। यह वर्कफ़्लो डिफ़ॉल्ट ब्रांच पर प्रत्येक पुश पर विकी को फिर से बनाता है। GitHub के लिए, विकी रिपॉजिटरी के wiki टैब में जाती है (Factory Docs)।</p>
<p><strong>LangChain: OpenWiki, और कोड से सब कुछ तक छलांग</strong></p>
<p>LangChain ने OpenWiki को ओपन-सोर्स सॉफ़्टवेयर के रूप में जारी किया। OpenWiki एक CLI टूल है। यह कोडबेस के लिए एजेंट दस्तावेज़ीकरण लिखता है और बनाए रखता है। LangChain ने फिर OpenWiki Brains जारी किया, जिसमें दो मोड हैं। Code Brain पहला मोड है, एक रिपॉजिटरी के लिए। Personal Brain दूसरा मोड है, आपके अपने स्रोतों के लिए (LangChain)।</p>
<p>Personal Brain महत्वपूर्ण बदलाव है। यह Gmail, Notion, git रिपॉजिटरी, X, Hacker News और वेब सर्च से डेटा पढ़ता है। यह इस सारे डेटा को एक स्थानीय markdown विकी में लिखता है। एजेंट इस विकी को पढ़ता है। विधि एक रिपॉजिटरी के दस्तावेज़ीकरण से आपके काम के दस्तावेज़ीकरण में बदल गई।</p>
<p>प्रत्येक टीम ने आउटपुट के बारे में एक ही निर्णय लिया। आउटपुट किसी व्यक्ति के पढ़ने के लिए पाठ नहीं है। आउटपुट LLM संदर्भ के लिए संरचित markdown है। इसमें शीर्षक, पेजों के बीच लिंक और सारांश हैं। संरचना एक एजेंट को संबंधित जानकारी जल्दी खोजने देती है। विकी का पाठक एक मॉडल है।</p>
<p><strong>GBrain: व्यक्तिगत-पैमाने का ओपन-सोर्स संस्करण</strong></p>
<p>GBrain इस विधि को कोडबेस पर नहीं, बल्कि एक व्यक्तिगत ज्ञान भंडार पर लागू करता है। GBrain git रिपॉजिटरी में markdown का उपयोग करता है। इसमें एक स्कीमा फ़ाइल है। यह स्वचालित रूप से विषयों के बीच लिंक का एक ग्राफ बनाता है।</p>
<p>GBrain दिखाता है कि विधि को बहुत कम बुनियादी ढांचे की आवश्यकता है। इसमें कोई वेक्टर डेटाबेस नहीं है। इसमें कोई सेवा नहीं है। इसमें फ़ाइलें हैं। एक मॉडल फ़ाइलों को बनाए रखता है। एक व्यक्ति फ़ाइलों को पढ़ सकता है।</p>
<h2><strong>तकनीक मैट्रिक्स</strong></h2>
<p>चारों प्रणालियों की एक ही संरचना है। वे git में markdown का उपयोग करते हैं। वे एक स्कीमा फ़ाइल का उपयोग करते हैं। वे इन्जेस्ट पर संकलन करते हैं। वे स्रोत बदलने पर विकी को फिर से बनाते हैं। वे एजेंट के पढ़ने के लिए पेज लिखते हैं। चार टीमों ने चार अलग-अलग समस्याओं को हल किया और एक ही संरचना बनाई। यह सहमति इस बात का अच्छा प्रमाण है कि संरचना सही है।</p>
<p>रखरखाव में सिस्टम भिन्न हैं। Factory रखरखाव CI में करता है। अन्य तीन प्रणालियाँ रखरखाव तब करती हैं जब कोई व्यक्ति कमांड चलाता है। इस प्रकार उनकी विकी केवल अंतिम कमांड जितनी ही सही होती है।</p>
<h2><strong>यह कहाँ रुकता है</strong></h2>
<p>सीमा 1 आकार है। Karpathy यह सीमा देते हैं। embeddings के बिना विधि लगभग 100 स्रोतों के लिए सही है। अधिक पेजों के लिए, आपको एक खोज इंजन जोड़ना होगा। Gist आपको BM25 खोज और वेक्टर खोज का एक साथ उपयोग करने के लिए कहता है।</p>
<p>सीमा 2 सटीकता है। मॉडल इन्जेस्ट पर जानकारी संकलित करता है। एक प्रारंभिक सारांश स्रोत से एक विवरण हटा सकता है। प्रत्येक बाद के उत्तर में यह त्रुटि होती है। कच्चे भागों से रिट्रीवल में यह समस्या नहीं है। आप बार-बार काम की लागत को खोए हुए डेटा के जोखिम से बदलते हैं।</p>
<p>सीमा 3 पुरानी जानकारी है। एक पेज केवल अंतिम अपडेट जितना ही सही होता है। यही कारण है कि Factory विधि महत्वपूर्ण है। एक गलत विकी बिना विकी से भी बदतर है। गलत जानकारी में सही जानकारी का प्रारूप होता है।</p>
<p>सीमा 4 लागत है। आप पेज बनाने के लिए टोकन का भुगतान करते हैं। आप ऐसे पेज बना सकते हैं जिन्हें कोई नहीं पढ़ता। आप उन पेजों को लिंट करने के लिए भी टोकन का भुगतान करते हैं जो बदले नहीं।</p>
<h2><strong>एक विकी मेमोरी नहीं है</strong></h2>
<p>एक अंतर है जिसे आपको जानना चाहिए। इस क्षेत्र में शब्द अभी तक सटीक नहीं हैं।</p>
<p>बहुत से लोग इन प्रणालियों को मेमोरी कहते हैं। LangChain OpenWiki को AI एजेंटों के लिए एक विकी मेमोरी लेयर कहता है। अन्य लोग कहते हैं कि एक विकी एजेंट को मेमोरी देता है। मेमोरी शब्द के यहाँ दो अलग-अलग अर्थ हैं।</p>
<p>पहला अर्थ दस्तावेज़ सेट का ज्ञान है। एक विकी यह करता है। यह आपके दस्तावेज़ों, आपकी रिपॉजिटरी या आपके Gmail में डेटा संकलित करता है। यह आपको बताता है कि दस्तावेज़ों में क्या है।</p>
<p>दूसरा अर्थ उपयोगकर्ता की मेमोरी है। यह अलग डेटा है। इसमें किसी व्यक्ति की प्राथमिकताएँ शामिल हैं। इसमें किसी व्यक्ति के निर्णय शामिल हैं। इसमें वे विधियाँ शामिल हैं जिन्हें एक टीम ने अस्वीकार कर दिया। इसमें वह परिणाम शामिल है जब एक एजेंट ने किसी भिन्न एप्लिकेशन में एक विधि आजमाई।</p>
<p>उपयोगकर्ता की मेमोरी की एक अलग संरचना होती है। यह दस्तावेज़ सेट से नहीं, बल्कि एक व्यक्ति से संबंधित होती है। यह इन्जेस्ट से नहीं, बल्कि इंटरैक्शन से आती है। इसे प्रत्येक उपयोगकर्ता के लिए ये कार्य भी करने होंगे: असहमत जानकारी को सही करना, बहुत पुरानी जानकारी को हटाना, प्रत्येक आइटम का स्रोत रखना, और अनुरोध पर डेटा हटाना।</p>
<p>एक विकी पहला कार्य सही ढंग से करता है। एक विकी दूसरा कार्य नहीं करता। आपकी Gmail विकी एजेंट को बताती है कि आपके Gmail में क्या है। यह एजेंट को यह नहीं बताती कि आपने मंगलवार को एक बातचीत में एक निर्णय बदल दिया। यह एजेंट को यह नहीं बताती कि एक विधि पहले ही आपके लिए विफल हो चुकी है।</p>
<p>एक मेमोरी लेयर दूसरा कार्य करती है। Mem0 एक उदाहरण है। यह प्रत्येक मेमोरी को user_id के साथ रखता है। इस प्रकार मेमोरी व्यक्ति के साथ सत्रों, एप्लिकेशनों और एजेंटों के बीच चलती है। जब कोई तथ्य बदलता है तो यह उस तथ्य को स्थिति में बदलता है। यह हर बार एक नया रिकॉर्ड नहीं जोड़ता।</p>
<p>दोनों प्रणालियाँ विकल्प नहीं हैं। दोनों का उपयोग करें। त्रुटि विकी का उपयोग न करना नहीं है। त्रुटि यह सोचना है कि एक विकी आपको उपयोगकर्ता की मेमोरी देती है।</p>
<h2><strong>सारांश</strong></h2>
<p>एजेंट विकी में विचार सही है। ज्ञान को एक बार संकलित करें। फिर इसे सही रखें। इसे प्रत्येक प्रश्न के लिए फिर से न बनाएं। रखरखाव ने मानव विकी को रोक दिया, और एक मॉडल बिना किसी लागत के रखरखाव करता है। चार टीमों ने कुछ महीनों में एक ही संरचना बनाई। यह मजबूत सबूत है।</p>
<p>ये तीन काम करें। अपने दस्तावेज़ों को पेजों में संकलित करें जब दस्तावेज़ सेट स्थिर हो और आप इसे बार-बार पढ़ते हों। जब दस्तावेज़ सेट बड़ा हो जाए तो रिट्रीवल जोड़ें, जैसा कि Gist आपको बताता है। दस्तावेज़ सेट के ज्ञान और उपयोगकर्ता की मेमोरी के बीच अंतर रखें। एक विकी आपको पहला देता है। एक विकी आपको दूसरा नहीं देता।</p>
<p><strong>In Context #17</strong></p>
<p><em>यह ब्लॉग In Context का हिस्सा है, जो AI Agent मेमोरी और संदर्भ इंजीनियरिंग को कवर करने वाली @mem0ai ब्लॉग श्रृंखला है।</em></p>
<p><em>Mem0 एक बुद्धिमान, ओपन-सोर्स मेमोरी लेयर है जिसे LLMs और AI एजेंटों के लिए डिज़ाइन किया गया है ताकि सत्रों में दीर्घकालिक, व्यक्तिगत और संदर्भ-जागरूक इंटरैक्शन प्रदान किया जा सके।</em></p>
<ul>
<li>अपनी मुफ़्त API कुंजी यहाँ प्राप्त करें: app.mem0.ai</li>
<li>या हमारे ओपन सोर्स GitHub रिपॉजिटरी से mem0 को स्वयं-होस्ट करें</li>
</ul>
<h2><strong>संदर्भ</strong></h2>
<ul>
<li>Andrej Karpathy, LLM Wiki (GitHub Gist, अप्रैल 2026)</li>
<li>qmd: markdown के लिए स्थानीय हाइब्रिड BM25/वेक्टर खोज</li>
<li>Cognition, DeepWiki: किसी भी रेपो के लिए AI डॉक्स</li>
<li>Devin Docs, DeepWiki</li>
<li>Factory, AutoWiki का परिचय</li>
<li>Factory दस्तावेज़ीकरण, AutoWiki अवलोकन</li>
<li>langchain-ai/openwiki (GitHub)</li>
<li>LangChain, विकी मेमोरी</li>
<li>garrytan/gbrain (GitHub)</li>
<li>Vannevar Bush, As We May Think (The Atlantic, 1945)</li>
<li>Mem0</li>
</ul>
