अगर हर कोई एक ऐप भेजता है, तो हम वॉइस भेजेंगे: वेबसाइटों को वॉइस ऐप्स में बदलना

पिछले पंद्रह वर्षों में कभी, वेब ने चुपचाप तय कर लिया कि हर महत्वपूर्ण साइट को एक मोबाइल ऐप की भी ज़रूरत है। इसलिए नहीं कि HTML काम करना बंद कर दिया — बल्कि इसलिए कि एक ऐप एक नियंत्रित सतह है: क्रियाओं का एक क्यूरेट किया गया समूह, कोई क्रोम नहीं जिसे आपने नहीं चुना, एक ऐसा इंटरफ़ेस जो बातचीत के एक ही तरीक़े के लिए बना है।

हमें लगता है कि वही क़दम उपयोगकर्ताओं के एक अलग समूह और इंटरफ़ेसों के एक अलग समूह के लिए उठाए जाने की प्रतीक्षा में है। अगर हर कोई अपनी साइट को एक Android ऐप में बदलता है, तो हम साइटों को वॉइस ऐप्स में बदल सकते हैं — और कमांड-लाइन ऐप्स में, और स्क्रीन-रीडर-नेटिव प्रवाहों में। वही विचार, उल्टी दिशा: किसी साइट को एक ऐसी सतह में लपेटिए जो इस बात के लिए बनी हो कि आप उससे कैसे बातचीत करना चाहते हैं, सिवाय इसके कि सतह किसी टचस्क्रीन के बजाय आपकी आवाज़ और आपका टर्मिनल है।

वेब कान से मुश्किल से ही इस्तेमाल-योग्य है

माउस वाले किसी दृष्टिवान उपयोगकर्ता के लिए, एक आधुनिक साइट ठीक है। पर आवाज़ से, या किसी स्क्रीन रीडर के ज़रिए, या किसी टर्मिनल से ब्राउज़ करने वाले किसी व्यक्ति के लिए, अधिकांश वेब एक शत्रुतापूर्ण माहौल है: अनंत-स्क्रॉल दीवारें, कुकी बैनर, पॉप-अप, ऐसे मेनू जिन्हें एक पॉइंटर चाहिए, तीन परतों की इंटरैक्टिव कबाड़ के नीचे दबी सामग्री। जानकारी उसमें है। उसे हाथों के बिना बाहर निकालना दयनीय है।

सामान्य जवाब है “साइटों को अधिक सुलभ होना चाहिए,” और होना भी चाहिए। पर हम पूरे वेब को विनम्रता से माँगकर ठीक नहीं करने वाले। जो हम कर सकते हैं वह है उन साइटों को लीजिए जो मायने रखती हैं और हर एक के लिए एक साफ़, बोला जाने वाला इंटरफ़ेस बनाइए — जैसे ऐप स्टोर्स ने टच के लिए किया, पर वॉइस और CLI के लिए, और खुले तौर पर।

दो परतें: पहले एक साफ़ API, फिर एक वॉइस स्किल

इनमें से हर वॉइस ऐप एक-दूसरे पर टिके दो हिस्से हैं, और हम दोनों पहले से बनाते हैं।

परत एक — एक टाइप्ड क्लाइंट जो किसी साइट को API में बदल देता है। यह ठीक-ठीक हमारा स्क्रेपिंग और API-रिवर्स-इंजीनियरिंग कार्य है: किसी ऐसी साइट के भीतर पहुँचिए जिसका कोई इस्तेमाल-योग्य सार्वजनिक इंटरफ़ेस नहीं है और भंगुर HTML के बजाय संरचित, टाइप्ड ऑब्जेक्ट वापस दीजिए — verbs, स्क्रेपिंग नहीं:

from py_bandcamp import BandCamp

for release in BandCamp.search_albums("king gizzard"):
    artist = release.work.credits[0].entity.name if release.work.credits else ""
    print(release.work.title, artist, release.uri)

नीचे की रेकी और एंटी-बॉट ट्रांसपोर्ट टूलिंग उस पहुँच को साइट बदलने पर भी काम करता रखती है। वह क्लाइंट अपने आप में पहले से उपयोगी है: किसी टर्मिनल उपयोगकर्ता के लिए API ही वेबसाइट का सुलभ संस्करण है — हमारा SoundCloud क्लाइंट तो nds भी भेजता है, जो बिना किसी ब्राउज़र के संगीत खोजने और चलाने वाला एक कमांड-लाइन ऐप है। एक बार जब कोई साइट API बन जाती है, तो वह एक दृश्य कलाकृति होना बंद कर देती है और कुछ ऐसी बन जाती है जिसे कोई मशीन — या कोई वॉइस पाइपलाइन — चला सकती है।

परत दो — एक OVOS प्लगइन जो उस API को बोलता है। क्लाइंट के ऊपर एक OpenVoiceOS प्लगइन बैठता है जो बोले गए इंटेंट्स को API कॉल्स से मैप करता है और परिणामों को हमारी ऑफ़लाइन TTS आवाज़ों से सुनाता है। यह जान-बूझकर प्रति साइट एक विशेष स्किल नहीं है — वह रास्ता दर्जनों एक-बार-के स्किल्स तक ले जाता है जिन्हें कोई बनाए नहीं रख सकता। किसी भी मीडिया-आकार की चीज़ के लिए यह एक OCP प्रदाता प्लगइन है: एक छोटा अडैप्टर जो किसी साइट की search-and-play सतह को पूरे Open Common Play फ़्रेमवर्क के सामने उजागर करता है, ताकि “search”, “play”, “next”, और “resume” पहले से वैसे ही काम करें जैसे वे हर दूसरे स्रोत के लिए करते हैं। साइट अपना ख़ुद का इंटरफ़ेस गढ़ने के बजाय एक समान वॉइस इंटरफ़ेस में गिर जाती है।

परिणाम: “Play the SomaFM Groove Salad channel.” “Search Bandcamp for Creative-Commons ambient.” वेबसाइट, कुछ ऐसी में बदली हुई जिसे आप देखे बिना इस्तेमाल कर सकते हैं — और हर साइट के लिए एक नई व्याकरण सीखे बिना।

LLMs के युग में, एक टाइप्ड API एक प्राकृतिक-भाषा UI बनने की प्रतीक्षा में है

एक दूसरा कारण है कि यह आकार अब पाँच साल पहले की तुलना में अधिक मायने रखता है। एक साफ़, टाइप्ड क्लाइंट ठीक वही है जो किसी बड़े भाषा मॉडल को किसी वेबसाइट का प्राकृतिक-भाषा फ़्रंट-एंड बनने के लिए चाहिए।

किसी LLM को प्रलेखित फ़ंक्शनों का एक समूह दीजिए — search_albums, get_recommendations, stream_url — और वह ख़ुशी-ख़ुशी “find me something like Naxatras but heavier” को सही कॉल्स में अनुवाद कर देगा, उन्हें चेन करेगा, और परिणाम वापस बोल देगा। संरचित API कठिन हिस्सा है; उसके ऊपर की संवादात्मक इंटरफ़ेस तेज़ी से कुछ ऐसी होती जा रही है जिसे मॉडल बस प्रदान कर देता है, बशर्ते जो टूल उसे थमाए जाएँ वे अच्छे-टाइप्ड हों और जो लौटाते हैं उसके बारे में ईमानदार हों। अव्यवस्थित HTML किसी LLM को पकड़ने के लिए कुछ नहीं देता। एक टाइप्ड क्लाइंट उसे एक नियंत्रण सतह देता है।

तो हमारे वेबसाइट क्लाइंट एक SKILL.md भेजते हैं — API क्या करता है, उसके verbs, उसके रिटर्न प्रकार, और उदाहरण कॉल्स का एक सादी-भाषा विवरण, जो किसी एजेंट के पढ़ने के लिए लिखा गया है। किसी LLM-चालित असिस्टेंट को उसकी ओर इंगित कीजिए और क्लाइंट एक ऐसा टूल बन जाता है जिसे मॉडल तुरंत इस्तेमाल कर सकता है: कोई ग्लू कोड नहीं, कोई विशेष एकीकरण नहीं, बस “यह साइट क्या कर सकती है, शब्दों में।” एक दस्तावेज़ किसी स्क्रेपर को कुछ ऐसा बना देता है जिसे कोई भाषा मॉडल आपकी ओर से चला सकता है।

यह वही संरचित डेटा है जो एक साथ तीन फ़्रंट-एंड को परोसता है: टर्मिनल उपयोगकर्ताओं के लिए एक CLI, हाथ-मुक्त उपयोग के लिए एक OCP/वॉइस प्लगइन, और प्राकृतिक-भाषा नियंत्रण के लिए एक LLM टूल। API एक बार बनाइए; उसे तीन तरह पहनिए।

यह उन लोगों के लिए सबसे अधिक क्यों मायने रखता है जो स्क्रीन नहीं देख सकते

अंधे और अल्प-दृष्टि उपयोगकर्ताओं के लिए यह कोई सुविधा-फ़ीचर नहीं — यह पहुँच और बहिष्करण के बीच का अंतर है। एक स्क्रीन रीडर केवल वही पढ़ सकता है जिसे कोई पेज साफ़-सुथरे ढंग से उजागर करे, और अधिकांश पेज नहीं करते। एक समर्पित वॉइस ऐप पेज को पूरी तरह छोड़ देता है: वह संरचित डेटा तक जाता है और उसे बोलता है, एक ऐसे प्रवाह में जो कोड की पहली पंक्ति से ही सुनने के लिए डिज़ाइन किया गया है।

यह वही सिद्धांत है जो हमारे ऑडियो-प्रथम गेम्स के पीछे है — कानों के लिए बने, आँखों के लिए नहीं, जिनमें अंधे खिलाड़ी बाद की सोच के बजाय प्राथमिक दर्शक हैं। वेबसाइटों के लिए वॉइस ऐप्स उसी सिद्धांत को गेम्स से बाक़ी वेब तक विस्तृत करते हैं।

एक बार में एक साइट — पर दिशा एक वॉइस ब्राउज़र है

यह रहा ईमानदार हिस्सा: कोई सार्वभौमिक शॉर्टकट नहीं है। आप “वेब” को एक ही झटके में वॉइस-सक्षम नहीं कर सकते, क्योंकि हर साइट अपनी ख़ुद की उलझन है। इसे प्रति साइट करना ही पड़ता है — एक क्लाइंट, एक स्किल, एक बार में इंटेंट्स का एक सावधानी से मैप किया गया समूह। यह एक सीमा जैसा लगता है, और अल्पकाल में है भी।

पर देखिए कि संचय किस ओर इंगित करता है। हम जिस भी साइट को लपेटते हैं वह वेब का एक और कोना है जो अब वॉइस और CLI से पहुँच-योग्य है। इनमें से पर्याप्त को आपस में जोड़िए — एक समान मेटाडेटा शब्दावली, एक साझा वॉइस परत, “search / open / read / play / next” इंटेंट्स का एक सुसंगत समूह — और आप अब अलग-अलग स्किल्स के ढेर को नहीं देख रहे। आप एक वॉइस ब्राउज़र की शुरुआत देख रहे हैं: बोलकर वेब में घूमने का एक तरीक़ा, जहाँ अलग-अलग साइटें बस ऐसे गंतव्य हैं जो पहले से जानते हैं कि जवाब कैसे देना है।

मोबाइल युग की शर्त यह थी कि इस्तेमाल के लायक़ साइट एक ऐप के लायक़ है। हमारी शर्त यह है कि इस्तेमाल के लायक़ साइट एक आवाज़ के लायक़ है। हम इन्हें एक बार में एक बना रहे हैं, खुले तौर पर, और इनमें से हर एक वेब को उन लोगों के लिए थोड़ा और ब्राउज़-योग्य बनाता है जिन्हें दृश्य वेब पीछे छोड़ गया।

चाहते हैं कि कोई विशिष्ट साइट एक वॉइस या CLI ऐप में बदल जाए — सुलभता के लिए, आपके उत्पाद के लिए, या बस इसलिए कि उसका होना चाहिए? चलिए बात करते हैं।