Show HN: Reor – एक AI नोट-टेकिंग ऐप जो मॉडल्स को लोकली चलाता है

मूल लेख ↗ Hacker News चर्चा ↗

Reor नाम का एक open-source project local Markdown note collections—खासकर Obsidian-style vaults—को AI-augmented knowledge base में बदलने का लक्ष्य रखता है, जिसमें language models पूरी तरह user की machine पर चलते हैं। Commenters semantic search, related-note discovery, और लंबे समय के personal notes पर Q&A जैसे use cases पर चर्चा करते हैं, साथ ही thinking के लिए AI पर ज़रूरत से ज़्यादा निर्भरता, data ownership, और interoperability की चिंताओं पर विचार करते हैं। कई लोग plain-text workflows की privacy और flexibility की सराहना करते हैं, लेकिन local models के साथ mixed परिणाम और तकनीकी समस्याएँ बताते हैं, और multiple vaults, plugins, mobile support, तथा PDFs और front matter जैसे formats की बेहतर handling जैसी features में रुचि व्यक्त करते हैं.

प्रोजेक्ट का अवलोकन और उद्देश्य

  • Reor एक local-first, open-source AI note-taking app है जो Markdown “vaults” पर काम करता है।
  • privacy, offline उपयोग, और plain files इस्तेमाल करने वाले अन्य tools के साथ interoperability पर ज़ोर दिया गया है।
  • कई commenters इसे इस बात का prototype मानते हैं कि desktop software local LLMs को कैसे integrate कर सकता है।

मौजूदा tools और formats के साथ integration

  • Markdown files की directories पर काम करता है; plain text support planned है।
  • Existing Obsidian vaults की ओर point किया जा सकता है; filesystem पर 1:1 operate करता है और vector DB के जरिए changes sync करता है।
  • Users की मांगें:
    • अलग app के बजाय direct Obsidian plugin।
    • Multiple independent vaults / context switching (पहले से PR में)।
    • YAML front matter और Logseq-style outlines की बेहतर handling (current behavior इन्हें mangle कर सकती है)।
    • OneNote, PDFs, browser bookmarks/history के लिए importers।

ज्ञान प्रबंधन में AI की भूमिका

  • इस पर बहस कि क्या AI-assisted organization thinking को बेहतर बनाती है या नुकसान पहुँचाती है:
    • चिंता कि organization को AI पर छोड़ने से active thinking और personal mental models कमज़ोर हो सकते हैं।
    • जवाब: AI inspiration और connections सामने ला सकती है; इसे selectively इस्तेमाल करना चाहिए, crutch की तरह नहीं।
  • कुछ का तर्क है कि personal knowledge graphs humans द्वारा organized होने चाहिए, जबकि LLMs का उपयोग discovery और queries के लिए किया जाए।

Model quality, prompts, और RAG

  • local models के साथ mixed अनुभव:
    • Q&A अक्सर summaries और overviews के लिए मददगार है, लेकिन specifics पर unreliable; related-notes links कमज़ोर हो सकते हैं।
    • छोटे 7B models अक्सर “too dumb” लगते हैं; बड़े models (34B–70B, Mixtral) बेहतर काम करते हैं लेकिन भारी हैं।
  • चर्चा कि chunking मुख्य समस्या नहीं है; prompt design और tuning critical हैं लेकिन उन पर कम ध्यान दिया जाता है।
  • lightweight models को summarization के लिए fine-tune करने, और vector/graph DBs तथा neuro-symbolic approaches explore करने के सुझाव।

Performance, hardware, और stability

  • Linux पर crashes, M1 Macs पर UI lockups, और vaults बड़े होने या context windows overflow होने पर errors की रिपोर्टें।
  • कुछ users को M1/M2 Macs और RTX GPUs पर अच्छे परिणाम मिले; दूसरों को CPU-only बहुत धीमा या unstable लगता है।
  • साफ hardware requirements और बेहतर GPU utilization की माँग।

Data ownership और storage model

  • app-owned databases की बजाय plain Markdown files के उपयोग को मज़बूत समर्थन, ताकि lock-in से बचा जा सके और कई tools enable हों।
  • कुछ का तर्क है कि databases भी share किए जा सकते हैं, लेकिन filesystem-as-database को अधिक सरल और universal माना जाता है।