Multi-agent सिर्फ बहुत सारे token खा लेते हैं और context भी बार-बार मिस कर देते हैं? इसलिए मैंने 'newsroom' संरचना अपनाने वाला LLM Wiki बना लिया.

• स्वायत्त multi-agent सिस्टम आजकल बहुत दिख रहे हैं, लेकिन चलाकर देखने पर ये अक्सर 5~10 गुना ज्यादा token खा जाते हैं और context भी बार-बार खो देते हैं। इसलिए मैंने अख़बार के newsroom को मॉडल बनाकर multi-agent की संरचना तैयार की।
• इसमें agent की पाँच भूमिकाएँ हैं, लेकिन LLM अपने हिसाब से निर्णय लेने वाला agent सिर्फ desk (review) है। बाकी या तो writing tasks हैं, या LLM नहीं बल्कि rules के अनुसार चलने वाली Python checks (lint), और task coordination (orchestration) है।
• LLM Wiki की तरह यह मूल दस्तावेज़ पढ़कर source pages बनाता है, वहाँ से व्यक्ति/अवधारणा के draft निकालता है, और फिर उन्हें जोड़कर विषयवार overview, contradictions summary, और synthesis pages के रूप में ऊपर-ऊपर बनाता जाता है। storage बस Markdown files और git में है, और Python tools सब local पर चलते हैं। सिर्फ clone करके भी API key के बिना example graph तुरंत चलाकर देखा जा सकता है।
• अभी GitHub में मौजूद example, 'AI में open source क्या है' वाली बहस को कवर करता है, लेकिन framework खुद किसी एक topic तक सीमित नहीं है.

---

मैंने agents को बस कई हिस्सों में खुला क्यों नहीं छोड़ दिया

• इसे हज़ारों डॉलर खर्च करके असल में चलाने वाले लोगों की राय लगभग एक जैसी थी: ये token बहुत खर्च करते हैं, agent आपस में संदेश भेजते-भेजते context खो देते हैं, और अधूरे काम को भी पूरा दिखा देते हैं।
• इसलिए मैंने इन्हें अपने-आप निर्णय लेने देने के बजाय तय नियमों और context isolation पर ज़ोर दिया। newsroom की उपमा ज़रूर है, लेकिन सच में स्वतंत्र निर्णय लेने वाला LLM सिर्फ desk है; बाकी सब तय काम ही करते हैं।

संभावित आपत्तियों का पहले से जवाब

• दस्तावेज़ लगातार फूलते जाएंगे और आखिरकार बेकार हो जाएंगे: मुझे भी यही सबसे व्यावहारिक चिंता लगती है। इसलिए writing role और pass/fail तय करने वाले desk को पूरी तरह अलग रखा गया है। desk को सिर्फ output और scoring criteria दिखाए जाते हैं; लेखक ने किस इरादे से लिखा, यह नहीं दिखाया जाता। साथ में rule-based linting दस्तावेज़ के बेवजह बढ़ने, duplicate होने, या दिशा खोने जैसी चीज़ों को यांत्रिक रूप से रोकती है। फिर भी मैं यह नहीं कहूँगा कि इससे document bloat पूरी तरह 'रुक' गया है।
• बार-बार editing करने पर errors जमा होते जाते हैं, और अपनी ही feedback से खुद को सुधारते-सुधारते सिस्टम आखिरकार वही पुराने patterns दोहराने लगता है: self-improvement की हर बात के साथ यह संदेह आता ही है, और मुझे भी यह जायज़ लगता है। इसलिए जब desk बार-बार पकड़ में आने वाले defects को guidelines में वापस शामिल किया जाता है, तब हर बार validation के failure cases नए रखे जाते हैं ताकि सिस्टम सिर्फ उसी test set का आदी होकर overfit न हो। यानी हर बार नए, अनदेखे मामलों से जांच की जाती है। synthesis pages की तरफ़ यह जांच भी डाली गई है कि अलग-अलग sources की बातों को कहीं ग़लती से एक ही बात बनाकर तो नहीं मिला दिया गया।
• क्या यह आखिरकार embeddings को manually बदला गया RAG ही नहीं है?: अगर लक्ष्य search है, तो यह आपत्ति सही है। फर्क यह है कि output vector index नहीं बल्कि इंसान के पढ़ने लायक जुड़े हुए documents हैं, और जहाँ sources आपस में मेल नहीं खाते, वहाँ उन्हें ढकने के बजाय अलग contradiction pages में सामने रखा जाता है। हर सवाल पर मूल दस्तावेज़ फिर से खींचकर लाने के बजाय, यह पहले से जमा हुए judgments को बनाए रखने की कोशिश करता है।

पुरानी अवधारणा: Memex

• इसे बनाते समय Vannevar Bush के Memex (1945 में कल्पित linked information machine) और Licklider के 'Man-Computer Symbiosis' जैसे विचारों की धारा ध्यान में थी।
• इसलिए इसमें pages के बीच trail (association path) और अनपेक्षित connections ढूँढने वाला discover feature जोड़ा गया है। मकसद यह नहीं कि सिस्टम अपने-आप index निकाल दे, बल्कि यह कि इंसान खुद चलकर तय कर सके ऐसी राहें छोड़ी जाएँ।

इस्तेमाल करते समय ध्यान देने वाली बातें

• 'API key की ज़रूरत नहीं' कहना आधा ही सही है: tools के भीतर का Python local पर चलता है, इसलिए बाहरी key नहीं चाहिए। लेकिन agents खुद Claude Code पर चलते हैं, इसलिए उसके लिए हर व्यक्ति को अपनी key लगानी होगी (BYOK)।
• public repo में सिर्फ idea और छोटे examples हैं: इसमें 15-node वाला एक English example है, इसलिए सिर्फ clone करके कोई भी वही graph दोबारा बना सकता है। मैं रोज़ाना चलाता आया लगभग 2,300-node वाला असली instance अलग private रखा हुआ है, इसलिए public repo और उसे अलग-अलग समझें।
• कोरियाई मोड (WIKI_LANG=ko): इसमें मुख्य पाठ और दस्तावेज़ के ऊपर का metadata (frontmatter) ही कोरियाई में बदलता है, जबकि document structure दिखाने वाले labels (## Summary, [fact] आदि) जानबूझकर English में ही रहते हैं। यानी यह 'पूरी तरह कोरियाई' नहीं है।

इसे बनाने की वजह और अभी की स्थिति

• इसकी शुरुआत Karpathy द्वारा साझा किए गए LLM Wiki gist पर एक implementation जोड़ने से हुई। इस concept का परिचय पहले GeekNews पर भी आ चुका है: https://hi.news.hada.io/topic?id=28208
• writing और review को अलग करने से क्या सचमुच ढीले-ढाले approval कम होते हैं, और self-improvement loop सच में मदद करता है या नहीं—यह अभी ठोस रूप से मापा गया नतीजा नहीं बल्कि प्रयोग के दौर में एक hypothesis है।