Chrome के Prompt API पर Mozilla का विरोध

 (github.com/mozilla)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • ब्राउज़र के भीतर के language model को web API के रूप में उजागर करने वाला Prompt API सामान्य रूप में उपयोगी हो सकता है, लेकिन यह model-specific behavior के हिसाब से implementation को बढ़ावा देकर interoperability risk बढ़ाता है
  • अगर developer Edge के Phi-4-mini जैसी किसी खास implementation के मुताबिक prompts और features को tune करते हैं, तो दूसरे browsers या models में quality degradation हो सकती है या साइट एक्सेस ब्लॉक हो सकता है
  • Mozilla का मानना है कि इसे सीधे web API के रूप में ship करने के बजाय userland validation से और गुजरना चाहिए, और trial web extension API तथा Web Machine Learning group के web extension proposal को शुरुआती feedback path के रूप में रखा गया है
  • अगर system prompts किसी खास model की quirk के हिसाब से फैलते हैं, तो नए models भी खराब लग सकते हैं, और browsers पर Google model या quirk-compatible model शामिल करने का दबाव बन सकता है
  • Chrome पक्ष ने JSON schema·regex आधारित response constraints, WebML CG discussions, और alternative model experiments जैसी mitigations पेश की हैं, लेकिन Mozilla की Prompt API पर स्थिति negative के रूप में दर्ज है

Prompt API पर Mozilla का नकारात्मक आकलन

  • Prompt API की समीक्षा Blink के intent-to-prototype के बाद Mozilla standards-positions में की गई, और explainer webmachinelearning/prompt-api README से जुड़ा है
  • Mozilla का feedback लगभग Writing Assistance APIs #1067 जैसा ही है; सामान्य रूप में Prompt API उपयोगी हो सकता है, लेकिन यह model-specific behavior को प्रोत्साहित कर interoperability risk बढ़ाता है
  • Developers किसी खास model के हिसाब से prompts और features को tune कर सकते हैं, और यदि वह Edge के Phi-4-mini जैसी implementation को target करता है, तो दूसरे browsers या models में quality गिर सकती है या site access block हो सकता है
  • इसे सीधे web API के रूप में ship करने के बजाय userland में अधिक समय तक validate किया जाना चाहिए, और Mozilla का trial web extension API तथा Web Machine Learning group का web extension proposal शुरुआती feedback जुटाने के रास्ते माने गए हैं
  • संबंधित चर्चाओं और #1067 के आधार पर Prompt API की स्थिति negative के रूप में चिह्नित की गई है

Origin Trial की तुलना में Web Extension को प्राथमिकता देने के कारण

  • model selection और standardization timing

    • model hub से सटीक model चुनने की क्षमता अहम मानी जाती है, क्योंकि page-level features और browser किसी खास model को चुनें, यह जरूरी नहीं होना चाहिए
    • यह क्षमता तेजी से बदलते क्षेत्र की implementation details पर निर्भर करती है, इसलिए इसे अभी standardize करने के लिए तैयार नहीं माना गया
    • Extension, मौजूदा proposal की सीमा से बाहर जाकर वास्तविक usage patterns को तेज़ी से explore करने का तरीका देता है, और तीनों engines को अभी-अधपकी semantics पर align करके ship करने की coordination cost के बिना browsers के बीच features का low-overhead experiment संभव बनाता है

  • user-visible boundaries

    • Add-on install करना इस बात का संकेत है कि user सामान्य web feature boundaries से बाहर जा रहा है; यहां shared cross-origin storage इसका उदाहरण है
    • यह तर्क दूसरे संदर्भ में WebMIDI Add-On Gated स्थिति जोड़ना #704 जैसी सोच से मिलता-जुलता है
    • यह extension proposal page को Prompt जैसी API surface देता है, local inference और developer-specified models का उपयोग करके shared model storage तथा शुरुआती user feedback जुटाने की संरचना बनाता है

एक ही model पर स्थिर हो जाने का जोखिम

  • system prompts और model quirks

    • system prompts अक्सर उपयोग में मौजूद model की quirk के हिसाब से बार-बार tune किए जाते हैं
    • home automation guidance text बनाने वाले एक system prompt में Gemini model ने शुरुआत में बहुत American-style जवाब दिए, जो UK-style speaker voice से मेल नहीं खाते थे
    • जब system prompt में जोड़ा गया कि यह British voice में बोलता है, तो “a'waight guv'nor apples and pears” जैसी American-style British imitation निकलने लगी, और इसे ज्यादा वास्तविक British शैली के करीब लाने के लिए अतिरिक्त tuning करनी पड़ी
    • किसी एक model के लिए किया गया correction दूसरे model में overcorrection बन सकता है, और branded voice या ऐसे output formats में यह समस्या और बढ़ती है जिन्हें JSON schema या regex से व्यक्त नहीं किया जा सकता

  • नए models और browser update का बोझ

    • अगर मौजूदा models की quirks के हिसाब से tuned system prompts व्यापक रूप से फैल जाते हैं, तो बेहतर नए competing models भी developers और users को खराब लग सकते हैं
    • interoperability बनाए रखने के लिए Mozilla और Apple को Google model license करना पड़ सकता है, या Google model के quirk-compatible model शामिल करने पड़ सकते हैं
    • इसी कारण Chrome के लिए भी अपने models को update करना मुश्किल हो सकता है

  • model ID detection और browser branching

    • Developers LanguageModel.create() से model बना सकते हैं और model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') जैसे prompt से model ID, नाम, version और source company पूछ सकते हैं
    • एक उदाहरण response है 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Developers किसी खास model के लिए system prompts के bundles बना सकते हैं, और unknown models को block कर सकते हैं या users को बता सकते हैं कि output quality कम हो सकती है
    • इसे ऐसे early-2000s code branching की वापसी माना गया है, जिससे बचना चाहिए

Google policy और model neutrality की समस्या

  • Chrome docs के अनुसार Prompt API का उपयोग करने से पहले Google Generative AI Prohibited Uses Policy को acknowledge करना होता है
  • इस policy के कुछ हिस्से कानून की सीमा से आगे जाते हैं; जैसे “sexually explicit content को promote करने वाले content का generation या distribution” और “government या democratic processes से जुड़े misleading claims को promote करना” निषिद्ध उपयोगों में शामिल हैं
  • web platform API का user agent के हिसाब से usage rules मांगने की दिशा सही नहीं मानी जाती, क्योंकि यह आगे और APIs पर UA-specific rules जोड़ने की मिसाल बन सकती है
  • अगर user किसी website पर article comment के “summarize” पर क्लिक करता है और उसका परिणाम Google policy का उल्लंघन बनता है, तो यह स्पष्ट नहीं है कि जिम्मेदार कौन है: बटन दबाने वाला user, उल्लंघनकारी content लिखने वाला comment author, या वह website owner जिसने ऐसा feature बनाया जो comment को user के UA LLM तक भेजता है
  • Developers model terms का पालन करने और model owner की legal action से बचने के लिए यह जानना चाह सकते हैं कि वे किस LLM से बात कर रहे हैं; unknown model का मतलब unknown terms हो सकता है, इसलिए usage block करना एक व्यावहारिक विकल्प बन सकता है
  • किसी खास browser के पास website developers पर ऐसी terms लागू करने का आधार नहीं है, और यह policy issue API proposal से अलग तरीके से संभाला जाना चाहिए, ऐसा भी तर्क है

Chrome पक्ष के updates और mitigation उपाय

  • Chrome Prompt API पक्ष ने blink-dev I2S और ChromeStatus के interoperability and compatibility risks पर update साझा किए
  • वे WebML CG में भागीदारी और चर्चा जारी रखना चाहते हैं, और interoperable sampling parameters जैसे follow-up experiments भी चलते रहे हैं
  • Chrome पक्ष ने कहा कि उनका उद्देश्य web platform की दीर्घकालिक सेहत और neutrality बनाए रखते हुए browser और OS द्वारा उपलब्ध कराए गए Language Model को web developers और users के लिए उपयोगी विकल्प बनाना है
  • Prompt API surface ने Google और Microsoft दोनों models में कुछ हद तक compatibility दिखाई है, और known JSON schema या regex के अनुरूप output देने के लिए objective response constraints लागू किए जा रहे हैं
  • इन constraints को unpredictable output से निपटने के लिए model-specific hacks की आवश्यकता कम करने वाले mitigation के रूप में देखा जा रहा है
  • downstream Chromium projects alternative models और framework backends की खोज कर रहे हैं, जिसमें Microsoft की Android MLKit integration और Apple foundational model integration की शुरुआती prototyping शामिल है
  • API trial phase में कई model versions को प्रयोगात्मक रूप से deploy किया गया, और model updates तथा improvements की निरंतर आवश्यकता मानी गई; साथ ही नए Gemma 4 open models support की भी जांच हो रही है
  • अलग-अलग underlying architectures में अधिक interoperable behavior tuning के लिए categorical sampling modes भी explore किए जा रहे हैं
  • Blink-dev के Interoperability and Compatibility पाठ के अनुसार, इस तकनीक का उपयोग करने वाले developers के लिए behavior और response variability पहले से ज्ञात अपेक्षा है, और API का लक्ष्य browsers और models में consistent web platform approach के लिए एक interoperability framework बनाना है

web developer समर्थन के आधार और shipping पर आलोचना

  • blink-dev intent to ship में web developers की स्थिति “Strongly positive” बताई गई है, और आधार के रूप में explainer के stakeholder feedback को जोड़ा गया है
  • कहा गया है कि यह आधार “Strongly positive” जैसी रेटिंग से मेल नहीं खाता

  • आधार के रूप में गिनाई गई चीजें

    • एक GitHub thread जिसमें 2 positive replies हैं
    • X पर एक single post
    • एक blog post जो अब मौजूद नहीं है, Server Not Found स्थिति में
    • एक blog post जो अभी उपलब्ध है
    • survey शायद developers से यह पूछता था कि अगर यह API extensions में हो तो क्या वह पर्याप्त होगा; survey के numbers या target audience का उल्लेख नहीं है
    • हट चुकी blog post का archived संस्करण Wayback Machine link से साझा किया गया
    • भले ही docs में “किन चीजों पर depend नहीं करना चाहिए” और “किन चीजों पर भरोसा किया जा सकता है” को प्रमुखता से दिखाया जाए, अगर उस guidance का पालन किया जाए तो API के संभावित उपयोग इतने सीमित हो सकते हैं कि उसका वास्तविक उपयोग बचता है या नहीं, यह स्पष्ट नहीं है
    • व्यवहार में tested specific model के behavior पर कुछ हद तक निर्भर रहा जा सकता है, और अगर वह model Chrome का model है तो site users को latest Chrome इस्तेमाल करने का संदेश दिखा सकती है
    • Google जिस क्षेत्र को अभी अधूरा मान रहा है, उसे व्यापक रूप से पहचानते हुए भी मौजूदा mitigations को shipping के लिए पर्याप्त मानना, यही मुख्य समस्या बनी हुई है

comments चर्चा: alternatives, impact measurement, और post-hoc mitigation

  • browser automation और Lynx mode

    • Hermes Agent और Qwen3.6 के साथ अधिकांश काम संभव था, और एक धारा का मत है कि Prompt API की तुलना में browser automation API तथा chat के लिए Lynx mode पर ज्यादा ध्यान देना चाहिए
    • कुछ workflows में व्यक्ति website पर login करता है और AJAX extension से files को visible बनाता है, जिसके बाद agent chromedriver/webdriver से documents download, tagging और summarization करता है
    • यह workflow बाहरी POSIX shell के बिना browser के अंदर integrated हो सकता है
    • Lynx mode chat, agents को दिखाई देने वाली चीजों को तेजी से surface करता है, और सभी media assets को download या render किए बिना दोनों पक्षों के resources बचाता है
    • HTML स्तर पर अधिक granular robots tagging, Lynxmode shell और मौजूदा browser के बीच handoff, तथा agent-driven browser में old-school Google AdWord style links को selective रूप से दिखाने जैसे विचार भी साथ आए

  • open web और FOMO

    • एक प्रतिवाद यह है कि open web, chat bot super apps जैसी चीजों से उसी तरह प्रतिस्पर्धा नहीं करता, और न ही वह गायब होने वाला है
    • यह भी कहा गया कि लगातार FOMO से पहले यह पूछना चाहिए कि आप किस चीज़ का प्रतिनिधित्व करना चाहते हैं
    • जिस चिंता में कहा जाता है कि यदि web, mobile app paradigm की तरह agentic computing को जल्दी और प्रभावी ढंग से support नहीं कर पाया तो commerce या journalism open web के बाहर चला जाएगा, उस पर भी पूर्ण सहमति नहीं दिखी

  • Chromium shipping और impact measurement

    • Chromium के blink API owner approvers में से एक ने Mozilla की चिंताओं से सहमति जताई, लेकिन experiments, mistakes से learning, और competition को बढ़ावा देने वाला रास्ता ज्यादा पसंद किया
    • आगे वास्तविक impact का मूल्यांकन करने के लिए concrete outcomes तय करने होंगे; EME जैसे विवादास्पद API shipping decisions को 5–10 साल बाद वास्तविक परिणामों से तुलना करना उपयोगी रहा है, ऐसा संदर्भ दिया गया
    • अगर sites Google-specific model पर स्थिर हो जाती हैं, तो उसका impact दूसरे browsers के ship करने पर आने वाले site compat bugs की संख्या और पैमाने, तथा Chrome द्वारा model update करने पर पैदा होने वाले bugs की प्रकृति से मापा जा सकता है
    • bug “model को और smart बनाना” है या “अजीब quirk को preserve करना”, इसे अलग करना चाहिए, और webcompat.com पर label लगाकर ऐसे मामलों को इकट्ठा करने का सुझाव दिया गया
    • blink-dev I2S के अनुसार Edge भी इस API को अलग model के साथ ship कर रहा है, इसलिए initial data पहले से मौजूद है
    • TOS concerns के लिए impact metric यह होगा कि क्या violations के कारण वास्तव में lawsuits या legal threats हुए; ऐसे evidence को record के रूप में इकट्ठा करने की बात आई

  • post-hoc mitigation और Chrome response

    • संभावित नुकसान को पहले वास्तविक रूप से देखना एक वैध तरीका है, लेकिन विरोध में कहा गया कि यह तभी उपयोगी है जब नुकसान होने के बाद meaningful mitigation उपलब्ध हो
    • अगर sites Google-specific model पर स्थिर हो जाएँ, तो क्या feature unship किया जा सकता है, क्या overly tuned site prompts को तोड़ने वाले model changes किए जा सकते हैं, क्या random model rotation संभव है, या on-device model weights का open standardization किया जा सकता है—ऐसे प्रश्न उठाए गए
    • अगर यह प्रमाण मिले कि दूसरे browsers को Chrome model की अजीब quirks कॉपी करनी पड़ रही हैं, तो Chromium leadership की स्थिति से Chrome को उन quirks को तोड़ने के लिए push करने की बात कही गई
    • एक उदाहरण भी दिया गया: Mobile GMail buggy WebKit border image quirks पर निर्भर था; जब Firefox को उसे कॉपी करने की जरूरत महसूस हुई, तो Chrome को ठीक करके GMail को तोड़ा गया, और GMail ने जल्दी update कर लिया, इसलिए users को इसका पता तक नहीं चला

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.