LLM-Wiki - LLM का उपयोग करके व्यक्तिगत ज्ञान भंडार बनाना

 (gist.github.com/karpathy)
168 पॉइंट द्वारा GN⁺ 2026-04-05 | 15 टिप्पणियां | WhatsApp पर शेयर करें
  • Andrej Karpathy ने हाल ही में कहा कि वे इन दिनों code से ज़्यादा व्यक्तिगत knowledge repository बनाने पर tokens खर्च कर रहे हैं, और इस LLM-आधारित wiki को बनाने के लिए एक idea guide file सार्वजनिक की है
  • इस file को agent को देने पर वह अपने-आप wiki बनाता है और उसके उपयोग का मार्गदर्शन भी करता है
  • यह ऐसा तरीका है जिसमें LLM खुद wiki लिखता और maintain करता है; हर query पर मूल स्रोत से जानकारी दोबारा निकालने वाले RAG तरीके के विपरीत, इसमें ज्ञान धीरे-धीरे जमा होता हुआ persistent wiki बनता है
  • wiki को Obsidian जैसे tools में खुला रखा जा सकता है, और LLM Markdown files को real time में edit और update करता है; उपयोगकर्ता sourcing और सवाल पूछने पर ध्यान देता है
  • नया source जोड़ने पर LLM उसे पढ़कर मौजूदा wiki में integrate करता है, cross-reference जोड़ता है, और एक source को process करते समय 10~15 wiki pages update कर सकता है
  • व्यक्तिगत health और goal management, research, reading notes, team internal wiki जैसे हर उस क्षेत्र में लागू किया जा सकता है जहाँ ज्ञान समय के साथ जमा होता है
  • wiki maintenance की सबसे बड़ी बाधा रहे bookkeeping cost को LLM लगभग 0 के करीब ला देता है, जिससे वह wiki management समस्या हल होती है जिसे लोग अक्सर बीच में छोड़ देते थे

मुख्य विचार

  • LLM के साथ documents उपयोग करने का ज़्यादातर तरीका RAG (Retrieval-Augmented Generation) है: files का collection upload करें, और query के समय LLM relevant chunks खोजकर जवाब बनाए
    • NotebookLM, ChatGPT file upload, और ज़्यादातर RAG systems इसी तरह काम करते हैं
    • हर बार ज्ञान नए सिरे से निकाला जाता है, यानी knowledge accumulation नहीं होता
  • LLM-Wiki का approach अलग है: LLM मूल source में सीधे खोजने के बजाय persistent wiki को धीरे-धीरे बनाता और maintain करता है
    • नया source जोड़ने पर LLM उसे पढ़ता है, मुख्य जानकारी निकालता है, और उसे मौजूदा wiki में मिलाता है
    • entity pages update करना, topic summary सुधारना, नए data और पुराने दावों के बीच विरोधाभास चिह्नित करना, synthesis को मज़बूत करना
  • wiki एक persistent, compounding artifact है: cross-references पहले से बने होते हैं, contradictions पहले से चिह्नित होती हैं, और synthesis पहले से परिलक्षित होती है
  • वास्तविक उपयोग उदाहरण: एक तरफ LLM agent और दूसरी तरफ Obsidian खुला रखकर, LLM द्वारा किए गए edits को real time में देखना
    • Obsidian = IDE, LLM = programmer, wiki = codebase

उपयोग के क्षेत्र

  • व्यक्तिगत: goals, health, psychology, self-development tracking — journals, articles, podcast notes इकट्ठा करके एक structured self-record बनाना
  • research: कई हफ्तों या महीनों तक papers, articles, reports पढ़ते हुए विकसित होती thesis को समेटने वाला व्यापक wiki बनाना
  • reading: chapters के हिसाब से व्यवस्थित करना, characters, themes, और plot threads के pages बनाना — Tolkien Gateway की तरह हज़ारों interlinked pages एक व्यक्तिगत reader भी बना सकता है
  • business/team: Slack threads, meeting transcripts, project documents, customer calls से LLM द्वारा maintain किया जाने वाला internal wiki बनाना
  • इसके अलावा competitive analysis, due diligence, travel planning, lecture notes, hobby deep-dives जैसे हर उस क्षेत्र में लागू जहाँ ज्ञान जमा होता है

architecture (3 layers)

  • raw sources: curated source documents का collection — articles, papers, images, data files
    • immutable, LLM इन्हें केवल पढ़ता है, modify नहीं करता
    • यही layer source of truth है
  • the wiki: LLM द्वारा बनाए गए Markdown files की directory — summaries, entity pages, concept pages, comparisons, overviews, synthesis
    • LLM इस layer का पूरा मालिक होता है: pages बनाना, source जुड़ने पर update करना, cross-references maintain करना
    • उपयोगकर्ता पढ़ता है, LLM लिखता है
  • the schema: LLM को wiki structure, conventions, और workflow बताने वाला configuration document (Claude Code के लिए CLAUDE.md, Codex के लिए AGENTS.md)
    • यही मुख्य config file LLM को सामान्य chatbot की जगह एक systematic wiki manager बनाती है
    • समय के साथ उपयोगकर्ता और LLM इसे साथ मिलकर विकसित करते हैं

मुख्य operations

  • ingest: नए source को raw collection में जोड़ना और LLM को उसे process करने के लिए कहना
    • LLM source पढ़ता है → मुख्य बिंदुओं पर विचार करता है → wiki में summary page लिखता है → index update करता है → संबंधित entity/concept pages update करता है → log entry जोड़ता है
    • एक source का असर 10~15 wiki pages पर पड़ सकता है
    • आप एक-एक source पर closely involve हो सकते हैं, या कम supervision के साथ batch processing कर सकते हैं
  • query: wiki से प्रश्न पूछने पर LLM संबंधित pages खोजता है और citations के साथ synthesized उत्तर देता है
    • उत्तर Markdown page, comparison table, slide deck (Marp), chart (matplotlib), canvas आदि कई रूपों में हो सकता है
    • अच्छे उत्तरों को wiki में नए pages के रूप में वापस save किया जा सकता है — यानी exploration भी knowledge base का हिस्सा बन जाती है
  • lint: समय-समय पर LLM से wiki की स्थिति जाँचने को कहना
    • जाँच के बिंदु: pages के बीच contradictions, नए sources से replace हो चुके पुराने claims, inbound links के बिना orphan pages, अपने page के बिना महत्वपूर्ण concepts, missing cross-references, और web search से भरे जा सकने वाले data gaps

indexing और logging

  • index.md: content-केंद्रित file — wiki के सभी pages को links, one-line summary, और metadata के साथ catalog करता है
    • query का जवाब देते समय LLM पहले index पढ़ता है और फिर संबंधित pages तक जाता है
    • ~100 sources और सैकड़ों pages के scale पर भी embedding-आधारित RAG infrastructure के बिना अच्छी तरह काम करता है
  • log.md: chronological record — ingest, query, और lint passes का रिकॉर्ड क्रम से रखता है
    • अगर हर entry का prefix एक जैसा रखा जाए तो Unix tools से parse किया जा सकता है
      • उदाहरण: ## [2026-04-02] ingest | Article Title → grep "^## \\[" log.md | tail -5 से हाल की 5 entries देखी जा सकती हैं

वैकल्पिक CLI tools

  • wiki के बढ़ने पर LLM को ज़्यादा efficiently काम कराने के लिए छोटे tools बनाए जा सकते हैं
  • qmd: Markdown files के लिए local search engine — BM25/vector hybrid search और LLM reranking, सब कुछ on-device
    • CLI (जिसे LLM shell out कर सकता है) और MCP server (जिसे LLM native tool की तरह उपयोग कर सकता है) दोनों का support
  • छोटे scale पर केवल index file ही काफ़ी है, और ज़रूरत पड़ने पर LLM की मदद से साधारण search scripts भी सीधे बनाई जा सकती हैं

tips और tool उपयोग

  • Obsidian Web Clipper: web articles को Markdown में बदलने वाला browser extension — raw collection में sources जल्दी जोड़ने के लिए उपयोगी
  • local image storage: Obsidian Settings → Files and links में attachment folder path set करने के बाद shortcut से images को local disk में save किया जा सकता है
    • LLM inline images वाले Markdown को एक बार में नहीं पढ़ सकता, इसलिए पहले text पढ़कर फिर images अलग से देखना बेहतर है
  • Obsidian graph view: पूरे wiki का shape समझने के लिए — relationships, hub pages, और orphan pages देखने में सर्वोत्तम
  • Marp: Markdown-आधारित slide deck format — Obsidian plugin उपलब्ध है, और wiki content से सीधे presentation बनाई जा सकती है
  • Dataview: page frontmatter पर queries चलाने वाला Obsidian plugin — अगर LLM YAML frontmatter (tags, dates, source count) जोड़ दे तो dynamic tables और lists बनाई जा सकती हैं
  • wiki एक Markdown files का git repository है — version history, branching, और collaboration मुफ़्त में मिलते हैं

यह काम कैसे करता है

  • knowledge base बनाए रखने की मुख्य बाधा पढ़ना या सोचना नहीं, बल्कि bookkeeping है: cross-references update करना, summaries को ताज़ा रखना, contradictions चिह्नित करना, और दर्जनों pages में consistency बनाए रखना
  • लोग wiki इसलिए छोड़ देते हैं क्योंकि maintenance burden उसकी value से तेज़ी से बढ़ता है
  • LLM ऊबता नहीं, cross-reference updates भूलता नहीं, और एक बार में 15 files संभाल सकता है → maintenance cost लगभग 0 की ओर चली जाती है
  • यह विचार Vannevar Bush के Memex (1945) से वैचारिक रूप से जुड़ा है: ऐसा knowledge repository जो व्यक्तिगत हो, सक्रिय रूप से curated हो, और जहाँ documents के बीच links खुद documents जितने ही मूल्यवान हों
    • Bush जिस सवाल का हल नहीं कर सके थे — "इसे maintain कौन करेगा?" — उसे LLM संभालता है

इस दस्तावेज़ की प्रकृति

  • यह दस्तावेज़ जानबूझकर abstract रखा गया है — उद्देश्य किसी खास implementation के बजाय विचार को समझाना है
  • directory structure, schema conventions, page formats, tools जैसी details domain, preference, और LLM के अनुसार बदलती हैं
  • सभी components optional और modular हैं — जो चाहिए वही इस्तेमाल करें, जो न चाहिए उसे छोड़ दें
  • इसे LLM agent के साथ share करके और फिर अपनी ज़रूरत के मुताबिक साथ मिलकर उसका version concretize करने की सलाह दी गई है

संबंधित पढ़ाई

15 टिप्पणियां

 
xguru 2026-04-05

इसे इस्तेमाल करने वाला Farzapedia: 2,500 डायरी, नोट्स और संदेशों से बनाई गई व्यक्तिगत Wikipedia

  • LLM का उपयोग करके डायरी, Apple Notes और iMessage बातचीत के 2,500 आइटम को इनपुट के रूप में देकर 400 विस्तृत wiki दस्तावेज़ अपने-आप बनाए गए
  • इसमें दोस्त, startup, रुचि के research क्षेत्र, पसंदीदा anime और उनके प्रभाव तक शामिल हैं, और backlink के ज़रिए आपस में जुड़े हैं
  • wiki को व्यक्तिगत पढ़ने के लिए नहीं बल्कि agent द्वारा उपयोग किए जाने वाले knowledge base के रूप में डिज़ाइन किया गया है, इसलिए file structure और backlink ऐसे रूप में हैं जिन्हें agent आसानी से crawl कर सके
  • Claude Code को wiki से जोड़ा गया है और index.md को entry point बनाया गया है, ताकि query पर agent ज़रूरी पेजों को सीधे explore कर सके
  • उपयोग का उदाहरण: नई landing page पर काम करते समय अगर पूछा जाए, "हाल में मुझे प्रेरित करने वाली images और फिल्मों को देखकर copy और design ideas दो", तो agent Studio Ghibli documentary पर आधारित "philosophy" दस्तावेज़, YC कंपनियों के landing page screenshots वाला "competitors" दस्तावेज़, और सेव की हुई 1970s Beatles goods images तक को मिलाकर जवाब देता है
  • 1 साल पहले RAG-आधारित समान सिस्टम बनाया गया था, लेकिन performance अच्छी नहीं थी, और agent का file system के ज़रिए सीधे explore करना कहीं ज़्यादा प्रभावी निकला
  • नया आइटम (लेख, inspiration image, meeting notes आदि) जोड़ने पर सिस्टम संबंधित 2~3 मौजूदा दस्तावेज़ों को अपने-आप update करता है या नया दस्तावेज़ बना देता है

Karpathy ने बताए LLM Wiki-आधारित personalization के 4 फायदे

  • ऊपर की Farzapedia को LLM Wiki tweet का एक अच्छा वास्तविक उदाहरण बताते हुए, मौजूदा AI personalization तरीके "जितना ज़्यादा इस्तेमाल करो, उतना अपने-आप बेहतर हो जाता है" की तुलना में इस approach के 4 फायदे बताए
  • स्पष्टता (Explicit): memory का परिणाम wiki के रूप में साफ़-साफ़ मौजूद रहता है, और AI क्या जानता है और क्या नहीं, इसे सीधे देखा और मैनेज किया जा सकता है — ज्ञान किसी अपारदर्शी internal system में दबा नहीं रहता बल्कि दिखाई देने वाले रूप में मौजूद रहता है
  • डेटा पर स्वामित्व (Yours): डेटा किसी खास AI provider के system में नहीं बल्कि local computer पर store होता है, और ऐसे locked format में बंद नहीं होता जिसे निकाला न जा सके, इसलिए जानकारी पर पूरा control बना रहता है
  • app से पहले file (File over app): memory markdown, images आदि generic format वाली files के संग्रह के रूप में बनी होती है, इसलिए अलग-अलग tools और CLI के साथ compatible है — agent पूरा Unix toolkit इस्तेमाल कर सकता है, और Obsidian जैसे मनचाहे interface में इसे देखा जा सकता है
  • AI चुनने की आज़ादी (BYOAI): Claude, Codex, OpenCode जैसे मनचाहे AI को स्वतंत्र रूप से जोड़ा जा सकता है — open source AI को wiki पर fine-tune करके केवल डेटा reference करने से आगे बढ़कर weights में ही व्यक्तिगत ज्ञान को समाहित करना भी सिद्धांततः संभव है
  • यह तरीका सबसे सरल नहीं है और file directory management की ज़रूरत पड़ती है, लेकिन agent इसमें काफ़ी हद तक मदद कर सकता है
  • इस बात पर ज़ोर दिया गया कि "agent proficiency 21वीं सदी की core skill है", और सलाह दी गई कि अंग्रेज़ी में निर्देश देने पर कंप्यूटर का काम संभाल लेने वाले इस tool को खुद अनुभव करके देखें
 
dkmin 2026-04-05

साझा करने के लिए धन्यवाद। इसे चलाकर देखा, और यह वाकई हैरान करने वाला है.
लगता है कि कम्युनिटी में आगे भी इससे बेहतर तरीके लगातार सामने आते रहेंगे
 
kurthong 2026-04-06

मैंने भी इसे इम्प्लीमेंट करके देखा है। कई hardware इस्तेमाल करते समय Obsidian vault को GitHub backup के साथ लिंक किया जा सके, इसके लिए थोड़ा-सा और जोड़ा है। Codex और Gemini के लिए parser भी बनाकर शामिल कर दिए हैं। https://github.com/hang-in/seCall
 
kuthia 2026-04-08

काफी साफ़-सुथरा है।
 
trpgfox 2026-04-07

वाह, मुख्य लेख पढ़कर भी समझ नहीं आ रहा था, लेकिन इस GitHub रेफ़रेंस को देखकर अब दिशा दिखने लगी है। सच में बहुत धन्यवाद
 
kurthong 2026-04-06

bm25 कोरियाई सर्च में उतना अच्छा नहीं है, इसलिए हमने अलग से ऐसे guardrails भी लागू किए हैं जो कोरियाई में भी अच्छी तरह सर्च कर सकें।
 
GN⁺ 2026-04-05
Hacker News की राय

  • लगता है कि यह तरीका आखिरकार model collapse तक ले जाएगा
    Nature पेपर को देखें तो, जैसे-जैसे LLM दस्तावेज़ लिखता है, वह मौजूदा सही जानकारी को धीरे-धीरे कम संक्षिप्त ढंग से फिर से लिखता है, और गुणवत्ता लगातार गिरती जाती है
    हैरानी होती है कि Karpathy को यह समस्या दिख नहीं रही। AI कट्टरपंथियों को देखकर लगता है कि उन्होंने किसी तरह की ‘सामान्य समझ’ खो दी है
    जब आपको LLM द्वारा बनाए गए नतीजों से ज़्यादा “मेरी लिखी हुई गुप्त चटनी” पर ज़ोर देने का मन हो, तो खुद से पूछना चाहिए कि ऐसा क्यों है

    • वह लेख LLM को train करने के बारे में नहीं है, बल्कि पहले से प्रशिक्षित मॉडल (ChatGPT या Claude आदि) का इस्तेमाल करके एक personal wiki लिखने के बारे में है
    • Karpathy की टिप्पणी फ्लैग होने के बाद गायब हो गई, लेकिन वह असल में Claude द्वारा लिखे गए लंबे, तंज़ भरे पैराग्राफ को ज्यों का त्यों चिपकाने जैसी थी
      उनका उस तरह प्रतिक्रिया देना निराशाजनक था। यह कहावत याद आती है: “अगर इंसान की तरह बोल नहीं सकते, तो शायद बोलना ही नहीं चाहिए”
      बहुत से होशियार लोग ‘machine में ghost’ देखने लगे हैं और अपनी मानवीय संवेदना खोते जा रहे हैं
      Ezra Klein का “I Saw Something New in San Francisco” लेख इस घटना को अच्छी तरह पकड़ता है
    • मैंने self-updating HTML file बनाने का एक प्रयोग किया था, और इस repository की तरह बहुत साधारण prompt के साथ भी यह बिना चक्र में फँसे काफ़ी अच्छी तरह काम कर गया
    • मेरे अनुभव में LLM claude.md जैसी एक फ़ाइल भी ठीक से maintain नहीं कर पाता। पूरी wiki तो और भी असंभव है

  • मैं इसी तरह की चीज़ management-centric approach से बना रहा हूँ
    यह पूरे workspace की memory को tasks या projects से जोड़ता है, और SPA interface के ज़रिए real-time control देता है
    hmem project देखा जा सकता है
    मैंने मॉडल को research mode में डालकर उसकी internal knowledge व्यवस्थित कराने की कोशिश की, लेकिन अंत में वह LLM soup की तरह अव्यवस्थित हो गया
    coding projects में स्पष्ट requirements, iterative improvement, और अच्छी तरह documented code सबसे प्रभावी रहे। memory बहुत ज़्यादा हो जाए तो उल्टा errors बढ़ते हैं

  • आखिरकार यह समस्या को टालने जैसा लगता है
    wiki को maintain करने के लिए LLM को हर बार source की जगह wiki को फिर से पढ़ना पड़ेगा, और इस प्रक्रिया में secondary errors जमा होते जाएँगे
    बेहतर होगा कि जब 10M context या 1000tps स्तर के next-generation models आ जाएँ, तब यह तरीका अपने-आप अप्रासंगिक हो जाएगा

    • 1M context वाले models पहले से मौजूद हैं, लेकिन लगभग 200k~300k tokens पर memory loss शुरू हो जाता है। 10M context होने पर भी बुनियादी सीमा वही रहेगी
    • मैं खुद Obsidian-based system बनाकर उसके ऊपर structured schema जोड़कर इस्तेमाल कर रहा हूँ
      यह middle layer design intent को पकड़ने और वास्तविक implementation से उसकी दूरी समझने में बहुत उपयोगी है
      पूरी तरह autonomous self-referential system में मुझे कोई खास मूल्य नहीं दिखता। असली मूल्य उस संरचना में है जहाँ इंसान दखल देकर कह सके, “यह ऐसे काम करना चाहिए”
      आखिरकार ये प्रयोग दिलचस्प हैं, लेकिन व्यावहारिक रूप से अर्थहीन लगते हैं। बड़े model providers इससे कहीं तेज़ी से आगे बढ़ रहे हैं, इसलिए अभी simple baseline का इस्तेमाल करना बेहतर लगता है
    • “अगली पीढ़ी के models सब हल कर देंगे” वाला तर्क सही है, लेकिन अगर उसी पर भरोसा करें तो कोई कुछ बनाएगा ही नहीं
    • लक्ष्य हर context को बनाए रखना नहीं है, बल्कि queryable memory बनाना है। एक तरह का ideas के लिए data lake
    • अभी यह कुछ दिलचस्प papers को summarize करने के काम आता है, लेकिन भविष्य में यह पूरे किसी domain को कुछ papers में संकुचित कर देने वाला knowledge condensation tool बन सकता है

  • यह विचार 1960 के Licklider के “Man-Computer Symbiosis” निबंध की याद दिलाता है
    इसमें इंसान goals सेट करता है, और computer hypotheses को models में बदलकर उनकी जाँच करता है, साथ ही iterative calculations संभालता है — यानी Intelligence Amplification की अवधारणा
    मूल लिंक देखा जा सकता है

    • उन्होंने पहले ही collaborative display की अवधारणा का पूर्वानुमान कर लिया था। उन्होंने ऐसी interaction की कल्पना की थी जहाँ व्यक्ति हाथ से बनाया गया graph दिखाए और computer उसे पहचानकर तुरंत अधिक परिष्कृत रूप में प्रदर्शित करे

  • संबंधित विचारों को लागू करने वाले systems की सूची यहाँ है
    मैं commonplace नाम का एक LLM-based knowledge base चला रहा हूँ
    यह system इस तरह डिज़ाइन किया गया है कि LLM theory को पढ़ भी सके और execute भी कर सके, यानी theory ही runtime बन जाती है
    अभी यह काफ़ी कच्चा है, लेकिन मेरे लिए यह तरीका अच्छी तरह काम करता है

  • मैंने codebase के लिए विशेष रूप से ऐसा ही एक tool बनाया है
    llmdoc file changes को hash से detect करता है, और LLM हर file को समझाने वाली एकल इकाई के रूप में summary cache करता है
    इसे CLI से access किया जा सकता है, और code exploration की speed काफ़ी बढ़ जाती है

  • यह मूल रूप से RAG architecture ही है
    vector DB नहीं है, लेकिन semantic connection index बनाकर और hierarchical structure तैयार करके retrieval में मदद करने के लिहाज़ से यह वही बात है
    मैं atomic project बना रहा हूँ, जो wiki synthesis जैसी ही सोच वाला AI knowledge base है

    • RAG में embeddings अनिवार्य नहीं हैं। सिर्फ़ grep search से भी इसे काफ़ी अच्छी तरह लागू किया जा सकता है
    • personal KB के लिए Multimodal KB + Agentic RAG का संयोजन उपयुक्त लगता है
      उदाहरण के लिए DocMason, जो PPT या Excel के diagrams निकालकर Codex जैसे agent से उनका analysis कराता है
    • इसे सिर्फ़ “बस RAG ही है” कहना सही नहीं होगा। यहाँ LLM wiki को सीधे लिखता और maintain करता है, backlinks बनाता है और inconsistencies जाँचता है
      यह retrieval से अधिक knowledge synthesis के करीब है। कुछ वैसा, जैसे LLM खुद अपना Zettelkasten manage कर रहा हो
      project दिलचस्प है, इसलिए मैं इसे ज़रूर देखूँगा
    • शायद ऐसे app के बारे में “मेरे कुछ सवाल हैं” से शुरुआत करना बेहतर होता
      मैं भी LLM-WIKI concept के बारे में लंबे समय से सोच रहा था, लेकिन OP ने इसे कहीं ज़्यादा गहराई से explore किया लगता है। उम्मीद है यह सचमुच दूसरा दिमाग बन सकेगा
    • असल में यह Copilot की custom instruction file जैसा है
      copilot-instructions.md दस्तावेज़ की तरह, यह LLM के संदर्भ के लिए निर्देशों को रखने वाली संरचना है

  • मैंने भी कंपनी के project में ऐसा ही प्रयास किया था
    burnout और परिवार की देखभाल के कारण जब मेरा ध्यान कम हो गया, तो मैंने बहुत-सा काम multi-agent workflow को सौंप दिया
    यह Obsidian-based markdown wiki के इर्द-गिर्द चलता है, लेकिन नतीजे में technical debt का एक नया रूप पैदा हो गया — जैसे दिमाग का कोई हिस्सा खाली हो गया हो
    फिर भी यह wiki workflow इतना addictive है कि इसे रोकना मुश्किल है

    • मुझे भी डर है कि कहीं मैं ‘गहराई से सोचने की क्षमता’ न खो दूँ
    • आप कुछ गलत नहीं कर रहे। बस एक निश्चित complexity के बाद agents wiki को maintain नहीं कर पाते, और developer भी पूरे सिस्टम को समझ नहीं पाता
    • documentation का असली मूल्य उसका output नहीं, बल्कि लिखने की प्रक्रिया में विचारों का व्यवस्थित होना है
      LLM चाहे कितना भी अच्छा output दे, personal wiki में वह process ज़्यादा महत्वपूर्ण है
    • अगर आप सोचने का समय वापस पाना चाहते हैं, तो offline hobby अपनाने की सलाह दूँगा
      मैं बिना फ़ोन के टहलता हूँ या तैराकी करता हूँ ताकि दिमाग खाली हो सके। शारीरिक थकान और मानसिक थकान अलग चीज़ें हैं, इसलिए यह मदद करता है

  • अच्छा लगता है कि इस तरह के approach पर ध्यान दिया जा रहा है
    लेकिन documents और structured data (work items, ADR आदि) को मिलाने पर सिर्फ़ markdown से query करना मुश्किल हो जाता है
    AGENTS.md तरीका folder rules को LLM को सिखाकर इसे संभालता है, लेकिन data जटिल होने पर इसकी सीमा आ जाती है
    इसलिए मैं Binder विकसित कर रहा हूँ
    यह data को structured DB में store करता है, लेकिन उसे bidirectionally synced markdown के रूप में render करता है
    LSP के ज़रिए autocomplete और validation देता है, और agents या scripts CLI या MCP के माध्यम से उसी data तक पहुँचते हैं

  • मैंने VS Code के लिए AS Notes बनाया है
    इसे asnotes.io पर देखा जा सकता है
    यह personal knowledge management system की सुविधाओं को VS Code में integrate करता है, जिससे markdown और wikilinks को आसानी से लिखा, जोड़ा और update किया जा सकता है
    यह mermaid और LaTeX rendering भी support करता है
    इस तरह AI बातचीत के नतीजों को markdown में स्थायी रूप से सुरक्षित रखा जा सकता है, इसलिए यह साधारण Copilot की तुलना में ज़्यादा मूल्यवान लगता है
 
stadia 2026-04-05

साधारण Vault को बस initialize किया, उस एक फ़ाइल को पढ़ने दिया, और जब मैंने कहा कि मैं इस आइडिया को concretize करना चाहता हूँ, तो superpowers की brainstorm skill के साथ पूरा ढांचा तैयार हो गया और CLAUDE.md तथा Obsidian plugin सेटिंग तक पूरी हो गई।
 
sudoeng 2026-04-06

इसे व्यक्तिगत knowledge repository जैसा इस्तेमाल करने का आइडिया मुझे भी काफ़ी दिलचस्प लगता है.
लेकिन AI लगातार जमा होते wiki context को संभाल पाएगा या नहीं, इस बारे में अभी मुझे पूरी तरह यक़ीन नहीं है.
 
kurthong 2026-04-06

बड़े संदर्भ में देखें तो यह पिछली बातचीत की खोज जैसा है, इसलिए अगर संगठन से जुड़ी बातों को अच्छी तरह व्यवस्थित किया जाए तो यह एक अच्छा आइडिया लगता है। वास्तव में, मुझे भी लगा कि यह प्रोजेक्ट को व्यवस्थित करने में काफी मददगार रहा।
 
huturufu 2026-04-05

लगता है कि openclaw के अंदर वही चीज़ आ गई है जिसे मैं implement करना चाहता था। अब इसे इस्तेमाल करना होगा।
 
junghan0611 2026-04-06

आख़िरकार यह विषय भी आ ही गया। मैं लंबे समय से इस विषय पर अपना garden सँवारता रहा हूँ और harness बनाता रहा हूँ, इसलिए मेरे लिए यह बहुत स्वागतयोग्य बात है। कपासी सर का know-how दिलचस्प है। PKM अपने आप में तकनीक की कठिनाई से ज़्यादा, लंबे समय तक व्यक्तिगत रूप से ज्ञान को जमा करने, उसे संरचित करने, और उसे बाहरी बुद्धिमत्ता के साथ साझा करने की प्रक्रिया में, इंसान मानो दोनों के सह-विकास का मॉडल पकड़ने की कोशिश कर रहा है। यानी क्या सवाल फिर से इंसान के पास लौट आया है? शायद यही कि क्या इंसान हमारे साथ रहने के लिए तैयार है? इसका कोई एक सही जवाब नहीं है; हर व्यक्ति को इसे अपने सवालों के साथ खुद बनाना होगा। काफ़ी उम्मीदें जगती हैं। GeekNews, इस ख़बर के लिए धन्यवाद।
 
calvinsnax 2026-04-06

पूर्वाग्रह नहीं रखना चाहिए... लेकिन ऐसे कमेंट्स को देखता हूँ तो कुछ अजीब-सा लगता है।
 
passerby 2026-04-06

बॉट से कमेंट करने की वजह क्या है?
 
hmmhmmhm 2026-04-07

क्या यह बॉट है? एलियन इंटेलिजेंस(???)