आखिरकार कर्पाथी के LLM Wiki gist को पढ़ने का मौका मिल ही गया (हाँ, हाइप ट्रेन में थोड़ा लेट हुआ XD)।
और सच कहूँ तो, पूरा विचार एक बहुत ही सरल चीज़ में सिमट जाता है: "अपडेटेबल RAG"।
1. समस्या
जब LLMs दस्तावेज़ों के साथ काम करते हैं, तो कुछ भी संचित नहीं होता। हर क्वेरी - मॉडल chunks को पुनर्प्राप्त करता है, स्क्रैच से संश्लेषित करता है, भूल जाता है। ज्ञान कभी संकलित नहीं होता। और मेरी राय में, इससे भी ज़्यादा महत्वपूर्ण: डायलॉग से ही लगभग कोई उपयोगी जानकारी नहीं निकाली जाती।
RAG आंशिक रूप से मदद करता है (व्यापक अर्थ में - .md फ़ाइलों का फ़ोल्डर भी RAG ही है), लेकिन मानक पाइपलाइन (जिसका हर कोई उपयोग करता है) में कोई अंतर्निहित अपडेट, डिस्टिलेशन या सेल्फ-क्लीनअप नहीं है। ज्ञान इंडेक्स में एक बार आता है और फिर बेकार पड़ा रहता है। इसी कमी को LLM Wiki पूरा करता है।
कर्पाथी का उलटाव: कच्चे स्रोतों और आपके बीच एक markdown विकी है जिसे एजेंट धीरे-धीरे लिखता और बनाए रखता है। एक बार संकलित करो, हमेशा अपडेटेड रखो।
2. आर्किटेक्चर: 3 परतें
- raw/ - स्रोत, अपरिवर्तनीय। एजेंट यहाँ नहीं लिखता।
- wiki/ - सिस्टम का दिल; markdown पेज (एंटिटीज़, कॉन्सेप्ट्स) जो LLM स्वयं लिखता और क्रॉस-लिंक करता है। मूलतः ग्राफ के आकार का ज्ञान।
- CLAUDE.md - बस वह मैन्युअल जो बताता है कि LLM Wiki कैसे चलाना है। इसमें शामिल है: पेज फ़ॉर्मेट, लिंक कन्वेंशन, इन्जेस्ट फ्लो, लिंट नियम। यही चीज़ क्लॉड को एक चैटबॉट से एक अनुशासित विकी मेंटेनर में बदल देती है।
बिना किसी अतिरिक्त ट्यूनिंग के सैकड़ों पृष्ठों के लिए पर्याप्त:
3. ऑपरेशन्स
तीन ऑपरेशन्स - आप तुरंत उन्हें API फ़ंक्शन के रूप में चित्रित करना चाहेंगे:
- Ingest -> add(source: file | list[file])। एक स्रोत डालें -> एजेंट पढ़ता है -> आपसे चर्चा करता है -> सारांश लिखता है -> इंडेक्स अपडेट करता है -> संबंधित एंटिटी पेजों में संपादन करता है -> लॉग में जोड़ता है। एक स्रोत 10-15 पेजों को छूता है।
- Query -> search(prompt: str)। सबसे महत्वपूर्ण ऑपरेशन। आपके प्रश्न का उत्तर देता है + (मुख्य बात) संश्लेषण को स्वचालित रूप से विकी में नए पेजों के रूप में फ़ाइल करता है। अन्वेषण चैट हिस्ट्री में मरने के बजाय बढ़ता रहता है। अंतर्निहित रूप से यह मूलतः add(source=dialogue) है।
- Lint -> lint()। कोई आर्गुमेंट नहीं। विकी को समय-समय पर चलता है: विरोधाभास, अनाथ पेज, पुराने तथ्य, लुप्त क्रॉस-रेफ़रेंस। ट्रिगर - हर N उपयोगकर्ता संदेशों के बाद, या बदली गई लाइनों के काउंटर पर। /schedule से जोड़ना आसान।
यह मुझे Claude Dreaming की बहुत याद दिलाता है - मुझे लगता है कि Dreaming आंशिक रूप से इस पैटर्न से प्रेरित है (हालाँकि इसके फ़ंक्शन सेट थोड़े अलग हैं)।
4. इंडेक्सिंग
दो विशेष फ़ाइलें विकी को नेविगेट करने योग्य बनाती हैं:
- index.md - वर्तमान स्थिति। प्रत्येक पेज की एक-लाइनर के साथ सूची। एजेंट किसी भी क्वेरी पर पहले इसे पढ़ता है - यह न्यूनतम संदर्भ है "इस विकी में क्या है"।
- log.md - सभी घटनाओं का लॉग, फ्री-फ़ॉर्म। केवल-अपेंड टाइमलाइन। यदि लाइनें एक समान आकार का पालन करती हैं (जैसे
## [YYYY-MM-DD] ingest | title), तो लॉग सादे unix टूल से साफ-साफ grep किया जा सकता है - ऑडिट के लिए उपयोगी।
index.md को और बढ़ाया जा सकता है (vector index, BM25, GraphDB, ...) - मैं इसे एक अलग पोस्ट में कवर करूँगा।
5. निष्कर्ष
यहाँ मैं इसे इस तरह फ्रेम करूँगा: यह RAG और LLM Wiki के बीच कोई चुनाव नहीं है - वे एक ही "कम्पाउंडिंग मेमोरी" अक्ष पर दो बिंदु हैं।
RAG को ज़रूरी नहीं कि vector DB हो - markdown फ़ाइलों का एक फ़ोल्डर भी RAG है।
तो आप LLM Wiki को तीन अतिरिक्त चीज़ों के साथ RAG के रूप में पुनर्व्याख्यित कर सकते हैं:
- एक समरीकरण परत।
- (लगभग) फ्री-फ़ॉर्म लेखन उस समरी स्तर पर संरचना का।
- आवधिक संरचनात्मक ऑडिट + स्व-सुधार (CRON)।
