Spegel - LLM की मदद से वेबपेज को फिर से संरचित करने वाला टर्मिनल ब्राउज़र

• Spegel एक ऐसा ब्राउज़र है जो HTML वेबपेज को LLM prompt में बदलता है और उसे टर्मिनल में Markdown रूप में दिखाता है
• यूज़र prompt के आधार पर पेज को रीयल-टाइम में कस्टम रूप से बदल सकता है, ताकि केवल महत्वपूर्ण जानकारी संक्षेप में दिखाई जाए
• इसका मुख्य काम करने का तरीका है HTML crawling → LLM prompt processing → Markdown conversion और output
• Textual-आधारित TUI के साथ सहज और हल्का टर्मिनल UI देता है, और view व prompt को config file से आसानी से मैनेज और रीयल-टाइम में बदला जा सकता है
• Lynx, Links2, Browsh जैसे मौजूदा टर्मिनल ब्राउज़र से अलग यह LLM का उपयोग करके यूज़र-कस्टमाइज़्ड content optimization पर विशेष रूप से केंद्रित है
• pip install spegel से इसे आसानी से इंस्टॉल किया जा सकता है, और यह open source है, इसलिए विभिन्न प्रयोगों और विस्तार के लिए उपयुक्त है

---

प्रोजेक्ट अवलोकन और विशेषताएँ

• Spegel टर्मिनल में चलने वाले वेब ब्राउज़र का एक प्रकार है, जो HTML को LLM को भेजकर यूज़र-परिभाषित prompt से पेज को फिर से संरचित करता है
• आउटपुट को Markdown में बदला जाता है और Textual-आधारित टर्मिनल UI में सहज रूप से दिखाया जाता है
• यह JS को सपोर्ट नहीं करता और केवल GET requests को संभालने वाला एक minimal डिज़ाइन अपनाता है
• LLM prompt customization के जरिए कई तरह के conversion view सपोर्ट करता है (जैसे: recipe summary, मुख्य action पर ज़ोर आदि)

निजीकरण और उपयोग के उदाहरण

• prompt और view को यूज़र config (~/.spegel.toml) में स्वतंत्र रूप से मैनेज किया जा सकता है
• उदाहरण:
  • recipe से केवल ingredients और मुख्य steps निकालना
  • जटिल व्याख्या को ELI5 स्टाइल में सरल बनाना
  • ज़रूरत पड़ने पर कई views को एक साथ रजिस्टर करके तेज़ी से स्विच करना

काम करने का तरीका

• Spegel HTML को लाता है और उसे config file के prompt के साथ LLM को भेजता है
• LLM के परिणाम को Markdown में बदलकर, Textual के जरिए टर्मिनल में render किया जाता है
• prompt और view को ब्राउज़िंग के दौरान भी रीयल-टाइम में समायोजित किया जा सकता है
• परिणाम को line-by-line stream करता है, और Markdown format errors से बचाने के लिए buffering लागू की गई है

मौजूदा टर्मिनल ब्राउज़रों से अंतर

• Lynx, Links2, Browsh आदि केवल HTML संरचना को ही टर्मिनल में दिखाते हैं
• Spegel, LLM-आधारित conversion के जरिए अनावश्यक जानकारी हटाने और optimized view देने पर केंद्रित है
• आधुनिक वेबसाइटें CSS और JS पर बहुत निर्भर होती हैं, इसलिए टर्मिनल वातावरण में अव्यवस्थित लग सकती हैं; Spegel केवल मुख्य content निकालकर फोकस और accessibility बेहतर बनाता है

इंस्टॉलेशन और उपयोग

• pip से आसान इंस्टॉलेशन:
  pip install spegel
• चलाना:
  spegel <URL>
• config file (~/.spegel.toml) को कस्टमाइज़ करना आवश्यक है, उदाहरण के लिए GitHub देखें
• source code और contribution: https://github.com/simedw/spegel

संदर्भ

• यह अभी Proof-of-Concept चरण में है, इसलिए कुछ फीचर अधूरे हैं और कुछ हिस्से अभी कच्चे हैं
• POST requests सपोर्ट नहीं हैं, और form input जैसी चीज़ों के लिए आगे विस्तार के विचार चल रहे हैं
• यह पारंपरिक टर्मिनल ब्राउज़र का सीधा विकल्प कम, और LLM+TUI आधारित content personalization की खोज के लिए एक प्रयोग ज़्यादा है

[GN⁺]

Hacker News की राय

• मुझे लगता है यह तकनीक वाकई दिलचस्प आइडिया है। यह ब्राउज़र को पूरी तरह रिप्लेस नहीं करेगी, लेकिन deterministic search और prompt को मिलाकर web browsing का बिल्कुल अलग तरीका बना सकती है। अगर इसे command-line tool के रूप में दिया जाए तो शायद और बेहतर लगेगा।

  • अगले चरण के रूप में मैं एक साथ कई "tabs" संभालने वाला फीचर सोच सकता हूँ। उदाहरण के लिए tab 1 में news A की रिपोर्ट, tab 2 में news B, tab 3 में Wikipedia, और फिर इन स्रोतों का summary बनाकर reference links तैयार करना। लेकिन सवाल यह है कि क्या ऐसा workflow सपोर्ट करने के लिए कोई मॉडल पर्याप्त रूप से stable है। नवीनतम SOTA models में भी सीमाएँ महसूस होती हैं।

  • ऊपर जैसा, यानी कई मीडिया स्रोतों की रिपोर्ट एक साथ दिखाकर summary और references देना, मुझे लगता है कि मूल रूप से Ground News यही करता है। मेरा उनसे कोई संबंध नहीं है, बस Kurzgesagt के वीडियो में उन्हें sponsor के रूप में देखा था। UI में निश्चित रूप से अंतर हो सकता है।

  • मेरा विचार यह होगा कि कई tabs/views एक साथ दिखाने पर भी उन्हें उसी source के भीतर रखा जाए। उदाहरण के लिए एक tab में CLI के लिए optimized मूल प्रस्तुति, और दूसरे tab में सिर्फ fact-checking पर फोकस हो, जैसे Google या Brave से दावों का आधार खोजना। ऐसे experiments बहुत मजेदार होंगे।

  • इसे ऐसे भी देख सकते हैं कि एक LLM पूरी ताकत से LLM-आधारित SEO spam बना रहा है, और दूसरा LLM उसे ऊपर-ऊपर summarize करके वापस उगल रहा है। क्या शानदार भविष्य है।

• यह कि किसी मशहूर recipe site से सिर्फ recipe निकालने वाला उदाहरण सबसे पहले आता है, मुझे बहुत क्लासिक दृश्य लगा। व्यक्तिगत रूप से तो मैं ऐसे प्रोजेक्ट को तुरंत recommend करना चाहूँगा। यह काफी ingenious प्रोजेक्ट लगता है।

  • फिर से यही LLM trend दिखता है: जो चीज़ पहले से मौजूद थी, उसकी नई व्याख्या करके उसे कहीं ज़्यादा खराब और non-deterministic बना देना। schema.org/Recipe जैसे standard structures पहले से मौजूद थे।

  • Recipe extraction के दौरान content, ingredients या quantities का random रूप से बदल जाना दिलचस्प है। मुझे लगता है LLM की प्रकृति इस छोटे से microcosm में बहुत अच्छी तरह सामने आती है, हालांकि यह ज़्यादातर comments की अपेक्षा से बिल्कुल अलग दिशा है।

  • पहले से ऐसे extensions मौजूद हैं जो LLM के बिना deterministic तरीके से सिर्फ recipe निकाल देते हैं। उदाहरण के लिए Chrome का Recipe Filter extension, जो पेज में recipe पहचानते ही उसे popup में दिखाता है।

• मुझे यह पसंद है कि LLM बीच में आकर Google के हालिया SEO-optimized writing trend और SEO structure को bypass कर देता है। सारी अनावश्यक चीज़ें हटाकर सिर्फ recipe निकालना LLM के लिए बहुत उपयुक्त use case लगता है। मुझे लगता है आगे LLM को filter की तरह सक्रिय रूप से इस्तेमाल करने वाले और उदाहरण आएँगे। बेशक, अगर HTML से सीधे recipe निकाली जा सके तो बेहतर होगा, लेकिन SEO युद्ध इतना बढ़ चुका है कि वह व्यावहारिक रूप से असंभव हो गया है।

  • अगर LLM का उपयोग सब अनावश्यक चीज़ें हटाने के लिए हो रहा है, तो यह भी सोचना चाहिए कि LLM recipe को अप्रत्याशित तरीके से बदल भी सकता है। जहाँ errors की बिल्कुल गुंजाइश नहीं है, ऐसे error-intolerant environment में ऐसे probabilistic software पर भरोसा करना समझ से बाहर है।

  • मैं कुछ सालों से ऐसे भविष्य की उम्मीद कर रहा था। Search-embedded LLM tools पहले से मौजूद हैं, और कई searches को जोड़कर process करने की क्षमता वास्तव में शक्तिशाली है। लेकिन Spegel बिल्कुल अलग तरीका है। मुझे लगता है भविष्य के ad blockers छोटे और efficient local LLM होंगे। उदाहरण के लिए timeline को chronological order में sort करना, UI बदलना, सिर्फ कुछ items दिखाना जैसी कई transformations संभव होंगी। Low-quality comments को अपने-आप छिपाना भी। जब LLM बीच में proxy या agent की तरह काम करेगा, तब यह सब संभव होगा। मुझे लगता है यह दिशा advertisers के लिए काफी असुविधाजनक होगी।

  • यह भी ध्यान में रखना चाहिए कि web browsing के दौरान LLM को प्रति मिनट लाखों tokens process करने पड़ सकते हैं, और इसका computational cost बहुत बड़ा होगा।

  • एक LLM अनावश्यक चीज़ें बना रहा है, और दूसरा LLM फिर उन्हें हटाता जा रहा है। लगता है जैसे यह बिना किसी गलतफहमी के चलता हुआ एक चक्रीय ढाँचा है।

• मुझे लगता है कि कम जटिल models, यहाँ तक कि LSTM-आधारित मॉडल भी, DOM को स्कैन करके सिर्फ ज़रूरी हिस्से चुनें और उन्हें सीधे browser में दिखाने लायक data structure के रूप में इकट्ठा करें, तो संभावना है। और लेखक की मौजूदा LLM-आधारित toolchain का उपयोग करके training data भी आसानी से बनाया जा सकता है।

  • लेकिन आज के web में, जहाँ content JS से देर से render होता है, सिर्फ DOM traversal की सीमा है। JS पूरी तरह load होने और सभी requests खत्म होने के बाद ही ज़रूरी data मिलता है, और उस स्थिति में तो आप लगभग browser renderer ही चला रहे होते हैं।

• लगता है बहुत से लोग इस बात को नज़रअंदाज़ कर रहे हैं कि html सिर्फ शुरुआत है। अगर web page को किसी दूसरे view में बदला जा सकता है, तो वास्तव में मॉडल को मिलने वाले किसी भी input को बदला जा सकता है। PDF, images वाले zip, बड़े json — कुछ भी view में बदला जा सकता है। आखिरकार महत्वपूर्ण चीज़ html input नहीं, बल्कि output view है।

• spegel में -p option जोड़ने का सुझाव।

  spegel -p "extract only the product reviews" > REVIEWS.md
  

  यानी prompt-आधारित तरीके से सिर्फ मनचाही जानकारी निकालने की सुविधा।

• मेरा मानना है कि हर बार पेज को नए सिरे से rewrite करने के बजाय, एक बार विज़िट पर उसे Markdown में बदलकर उसके साफ़-सुथरे versions आपस में साझा किए जाएँ, तो computation rebuilding कम हो सकती है।

  • चूँकि हर user की ज़रूरतें और prior knowledge अलग होती हैं, इसलिए चाहे कितना भी साफ़ shared material बना लिया जाए, अंत में individual customization की प्रक्रिया बची रहेगी। फिर भी P2P cache, जैसे IPFS, global dedup cache की तरह data preservation, availability और resource savings में मदद कर सकते हैं।

  • Cache headers का उपयोग server यह बताने के लिए करता है कि client को जानकारी कितने समय तक cache करने की अनुमति है। मुझे लगता है client side पर भी ऐसा cache layer जोड़ना अच्छा होगा जो इन headers का पालन करे।

  • अगर लक्ष्य consistent layout है, तो पिछली page के Markdown output को example के रूप में मॉडल के साथ देना, यानी one-shot example, भी संभव हो सकता है।

  • इस प्रोजेक्ट का उद्देश्य ही "personalized prompt-based view" है, इसलिए कम-से-कम default prompt के outputs को cache करके इस्तेमाल करना ठीक रहेगा।

• यह मुझे सचमुच एक शानदार POC लगा, और इसमें मेरे रोज़ इस्तेमाल वाले Chrome extension "reader view" जैसी काफी समानता है।
  reader view extension link

• आइडिया बहुत शानदार है और accessibility के लिहाज़ से भी इसकी क्षमता बड़ी लगती है।

  • लेकिन LLM non-deterministic है, और accessibility ऐसा क्षेत्र है जहाँ सबसे पहले reliability और predictability की गारंटी चाहिए — यही समस्या है।

• मेरे retired AI agent का एक पुराना वीडियो है जो web pages को real time में transform करके दिखाता है।
  HN को My Little Pony में बदलने का demo (video)
  लगभग 37 सेकंड से परिणाम देखे जा सकते हैं।
  मैंने एक open-source Chrome extension भी बनाया था, इसलिए दिलचस्पी हो तो ChromeGPT देख सकते हैं।

[laeyoung]

spegel -p "extract only the product reviews" > REVIEWS.md

अगर सिर्फ यह option होता, तो इसे कई तरह से इस्तेमाल करने के आइडिया आते, लेकिन लगता है कि अभी यह मौजूद नहीं है।