Mozilla'nın Chrome'un Prompt API'sine itirazı

• Tarayıcı içindeki dil modellerini bir web API'si olarak sunan Prompt API, genel biçimiyle faydalı olabilir; ancak modele özgü davranışlara göre uygulamaları teşvik ederek birlikte çalışabilirlik riskini büyütüyor
• Geliştiriciler Edge'in Phi-4-mini'si gibi belirli bir uygulamaya göre prompt'ları ve işlevleri ayarlarsa, başka tarayıcılarda veya modellerde kalite düşüşü ya da site erişiminin engellenmesi ortaya çıkabilir
• Mozilla, bunu doğrudan bir web API'si olarak göndermek yerine userland doğrulamasından daha fazla geçmesi gerektiğini düşünüyor; deneme amaçlı web extension API'si ile Web Machine Learning grubunun web extension önerisini ilk geri bildirim kanalları olarak konumlandırıyor
• Sistem prompt'ları belirli bir modelin quirk'lerine göre yayılırsa, yeni modeller de kötü görünebilir ve tarayıcılar Google modeli ya da quirk uyumlu modeller ekleme baskısı altında kalabilir
• Chrome tarafı JSON schema ve regex tabanlı yanıt kısıtları, WebML CG tartışmaları ve alternatif model denemeleri gibi hafifletici önlemler sundu; ancak Mozilla'nın Prompt API konusundaki duruşu negative olarak işaretlendi

---

Mozilla'nın Prompt API hakkında olumsuz değerlendirmesi

• Prompt API, Blink'in intent-to-prototype duyurusunun ardından Mozilla standards-positions içinde incelendi ve explainer, webmachinelearning/prompt-api README belgesine bağlanıyor
• Mozilla'nın geri bildirimi, Writing Assistance APIs #1067 ile neredeyse aynı; genel biçimde bir Prompt API faydalı olabilir, ancak modele özgü davranışları teşvik ederek birlikte çalışabilirlik riskini artırıyor
• Geliştiriciler belirli bir modele göre prompt'ları ve işlevleri ayarlayabilir; Edge'in Phi-4-mini gibi uygulamalar hedef alınırsa başka tarayıcılarda veya modellerde kalite düşebilir ya da site erişimi engellenebilir
• Bunu doğrudan bir web API'si olarak göndermek yerine userland içinde daha uzun süre doğrulamak gerektiği düşünülüyor; Mozilla'nın trial web extension API yaklaşımı ile Web Machine Learning grubunun web extension önerisi ilk geri bildirim toplama yolu olarak öne çıkıyor
• İlgili tartışmalar ve #1067 temel alınarak Prompt API'ye ilişkin duruş negative olarak işaretlendi

Neden Origin Trial yerine Web Extension tercih ediliyor?

• Model seçimi ve standardizasyon zamanlaması

  • Model hub'dan doğru modeli seçme yeteneği, sayfa içi işlevlerde ve tarayıcının belirli bir modeli seçmemesinde kilit unsur olarak görülüyor
  • Bu yetenek, hızla değişen bir alanın uygulama ayrıntılarına dayanıyor ve henüz standartlaştırılmaya hazır kabul edilmiyor
  • Extension'lar, mevcut öneri kapsamının ötesindeki gerçek kullanım kalıplarını hızlıca keşfetmek ve üç motorun henüz oturmamış anlamları eşleştirerek dağıtım yapmasının koordinasyon maliyeti olmadan tarayıcılar arası işlev denemek için düşük maliyetli bir yol sunuyor

• Kullanıcıya görünen sınırlar

  • Add-on kurulumu, kullanıcının normal web özelliklerinin sınırlarının dışına çıktığını gösteren bir işaret olarak görülüyor; burada örnek paylaşımlı cross-origin storage
  • Bu değerlendirme, başka bir bağlamdaki WebMIDI Add-On Gated pozisyon eklemesi #704 ile benzer bir mantık izliyor
  • Söz konusu extension önerisi, sayfaya Prompt'a benzer bir API sunuyor; yerel çıkarım ve geliştiricinin belirlediği modelleri kullanarak paylaşımlı model deposu ve erken kullanıcı geri bildirimi elde etmeyi amaçlıyor

Tek bir modele kilitlenme riski

• Sistem prompt'ları ve model quirks

  • Sistem prompt'ları, üzerinde çalışılan modelin quirk'lerine göre tekrar tekrar ayarlanma eğiliminde
  • Ev otomasyonu yönergeleri üretmek için kullanılan bir sistem prompt'unda Gemini modeli başlangıçta çok Amerikan tarzında yanıt verdi ve İngiliz aksanlı hoparlör sesiyle uyumlu değildi
  • Sistem prompt'una İngiliz aksanıyla konuşması istendiğinde bu kez “a'waight guv'nor apples and pears” gibi Amerikan bakışıyla yapılmış bir İngiliz taklidi çıktı; daha doğal bir İngiliz tonuna çekmek için ek ayarlama gerekti
  • Bir model için yapılan düzeltme, başka bir modelde aşırı düzeltmeye dönüşebilir; özellikle markalı voice'lar veya JSON schema ile regex kullanılarak ifade edilemeyen çıktı biçimlerinde sorun büyüyebilir

• Yeni modeller ve tarayıcı güncellemelerinin yükü

  • Mevcut modellerin quirks'lerine göre ayarlanmış sistem prompt'ları yaygınlaşırsa, daha iyi yeni rakip modeller bile geliştiricilere ve kullanıcılara kötü görünebilir
  • Mozilla ve Apple, birlikte çalışabilirlik için Google modelini lisanslamak ya da Google modeliyle quirk uyumlu modeller kullanmak zorunda kalabilir
  • Aynı nedenle Chrome'un da kendi model güncellemelerini yapmakta zorlanabileceği belirtiliyor

• Model ID tespiti ve tarayıcıya göre dallanma

  • Geliştiriciler LanguageModel.create() ile bir model oluşturup model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') gibi bir sorguyla modelin ID'sini, adını, sürümünü ve üretici şirketini isteyebilir
  • Dönen örnek değer 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
  • Geliştiriciler belirli modellere özel sistem prompt paketleri hazırlayabilir; bilinmeyen modelleri engelleyebilir veya kullanıcıya çıktı kalitesinin düşük olabileceğini söyleyebilir
  • Bunun, kaçınılması gereken bir 2000'lerin başı tarzı code branching yaklaşımına dönüş riski taşıdığı vurgulanıyor

Google politikası ve model tarafsızlığı sorunu

• Chrome dokümanına göre Prompt API'yi kullanmadan önce Google Generative AI Prohibited Uses Policy kabul edilmeli
• Bu politikanın bazı bölümleri yasal gerekliliklerin ötesine geçiyor; örneğin “cinsel açıdan açık içeriği teşvik eden içerik üretimi veya dağıtımı” ile “hükümet ya da demokratik süreçlerle ilgili yanıltıcı iddiaların teşviki” yasaklı kullanım alanları arasında
• Web platformu API'lerinin UA'ya özgü kullanım kuralları gerektirmesi sağlıklı görülmüyor ve bunun daha fazla API'ye UA bazlı kurallar eklenmesi için emsal oluşturabileceği düşünülüyor
• Kullanıcı bir web sitesinde bir haber yorumunun altındaki “summarize” düğmesine tıklayıp sonuç Google politikasını ihlal ederse, sorumluluğun düğmeye tıklayan kullanıcıda, ihlalli içeriği yazan yorum sahibinde ya da bu yorumu kullanıcının UA içindeki LLM'ine ileten özelliği yapan site sahibinde mi olduğu belirsiz
• Geliştiriciler, model kullanım şartlarına uymak ve model sahibinin hukuki yaptırım riskinden kaçınmak için hangi LLM ile iletişim kurduklarını bilmek isteyebilir; bilinmeyen modeller bilinmeyen şartlar anlamına gelebileceğinden, bunların kullanımını engellemek makul bir seçenek haline gelebilir
• Belirli bir tarayıcının web sitesi geliştiricilerine bu tür şartlar dayatması için bir gerekçe olmadığı ve bu politika meselesinin API önerisinin kendisinden ayrı ele alınması gerektiği de ifade ediliyor

Chrome tarafındaki güncellemeler ve hafifletici önlemler

• Chrome Prompt API ekibi, blink-dev I2S ve ChromeStatus üzerindeki interoperability and compatibility risks güncellemesini paylaştı
• WebML CG içindeki katılım ve tartışmaların sürmesini istediklerini, birlikte çalışabilir sampling parameters gibi devam deneylerinin de sürdüğünü belirtiyorlar
• Chrome tarafı, web platformunun uzun vadeli sağlığını ve tarafsızlığını korurken tarayıcı ve işletim sistemi tarafından sağlanan Language Model seçeneklerini web geliştiricileri ve kullanıcılar için faydalı hale getirme motivasyonunu vurguluyor
• Prompt API yüzeyi, hem Google hem Microsoft modellerinde bir ölçüde uyumluluk göstermiş durumda; ayrıca bilinen JSON schema veya regex kalıplarına uyan çıktılar için nesnel yanıt kısıtları uygulanıyor
• Bu kısıtlar, öngörülemeyen çıktılarla başa çıkmak için modele özel hack'lere duyulan ihtiyacı azaltan bir hafifletme yöntemi olarak sunuluyor
• Aşağı akıştaki Chromium projeleri alternatif modelleri ve framework backend'lerini araştırıyor; buna Microsoft'un Android MLKit entegrasyonu ve Apple foundational model entegrasyonu için erken prototipleme de dahil
• API deneme aşamasında birden fazla model sürümü deneysel olarak dağıtıldı; model güncellemeleri ve iyileştirmeleri gerekmeye devam ediyor ve daha yeni Gemma 4 open models desteği de araştırılıyor
• Farklı temel mimariler üzerinde daha birlikte çalışabilir davranış ayarı için categorical sampling modes da inceleniyor
• Blink-dev'deki Interoperability and Compatibility ifadesi, bu teknolojiyi kullanan geliştiriciler için davranış ve yanıt değişkenliğinin bilinen bir beklenti olduğunu ve API'nin tarayıcılar ile modeller genelinde tutarlı bir web platformu yaklaşımı için birlikte çalışabilir bir çerçeve hedeflediğini söylüyor

Web geliştirici desteği gerekçesi ve dağıtıma yönelik eleştiriler

• blink-dev intent to ship metni, web geliştiricilerinin tutumunu “Strongly positive” olarak işaretliyor ve gerekçe olarak explainer içindeki stakeholder feedback bölümünü gösteriyor
• Ancak bu gerekçenin, “Strongly positive” değerlendirmesiyle pek örtüşmediği ifade ediliyor

• Gerekçe olarak listelenen maddeler

  • İki olumlu yanıt içeren bir GitHub thread
  • X üzerinde tek bir gönderi
  • Artık erişilemeyen bir blog yazısı, durumu Server Not Found
  • Hâlâ erişilebilir bir blog yazısı
  • Anket geliştiricilere bu API'nin extension içinde bulunmasının yeterli olup olmadığını soruyor gibi görünüyor; ancak ankette sayı veya katılımcı profili belirtilmiyor
  • Silinmiş blog yazısı için Wayback Machine bağlantısı üzerinden arşiv kopyası paylaşılıyor
  • Dokümanda “bağımlı olunmaması gerekenler” ile “güvenilebilecekler” çok belirgin yazılsa bile, bu önerilere uyulduğunda API'nin mümkün kullanım alanının gerçek anlamda işe yarayıp yaramadığı belirsiz kalıyor
  • Uygulamada, test edilen belirli bir modelin davranışına bir ölçüde güvenilebiliyor; model Chrome'un modeli ise site kullanıcıya en güncel Chrome'u kullanmasını söyleyebilir
  • Google'ın henüz olgunlaşmamış alanları geniş biçimde kabul etmesine rağmen mevcut hafifletmelerin shipping için yeterli olduğunu düşünmesi temel sorun olarak görülüyor

Yorum tartışmaları: alternatifler, zararın ölçülmesi ve sonradan hafifletme

• Tarayıcı otomasyonu ve Lynx mode

  • Hermes Agent ve Qwen3.6 ile çoğu işin yapılabildiği, Prompt API yerine browser automation API ile sohbet için Lynx mode'a daha fazla odaklanılması gerektiği görüşü de var
  • Bazı iş akışlarında insan kullanıcı web sitesine giriş yapıyor, AJAX uzantısıyla dosyaları görünür hale getiriyor; ardından agent chromedriver/webdriver üzerinden belge indirme, etiketleme ve özetleme yapıyor
  • Bu yaklaşımın, harici bir POSIX shell olmadan tarayıcı içinde bütünleşik hale gelebileceği belirtiliyor
  • Lynx mode chat, agent'ların gördüklerini hızlıca ortaya koyarken tüm medya varlıklarını indirmeyip render etmediği için iki tarafın da kaynak tüketimini azaltıyor
  • HTML düzeyinde daha ayrıntılı robots etiketleme, Lynxmode shell ile mevcut tarayıcı arasında handoff ve agent-driven browser içinde eski usul Google AdWord tarzı bağlantıların seçici gösterimi gibi fikirler de tartışılıyor

• Açık web ve FOMO

  • Açık web'in chat bot super apps ile aynı şekilde rekabet etmediği ve ortadan kaybolmayacağı yönünde karşı görüşler var
  • Sürekli FOMO ile hareket etmek yerine önce neyi temsil etmek istendiğini sormak gerektiği de savunuluyor
  • Web'in mobile app paradigm'ını yeterince destekleyemediği gibi, agentic computing alanını hızlı ve etkili biçimde destekleyemezse ticaretin ya da gazeteciliğin açık web dışına kayacağı endişesine katılmayan bir çizgi de mevcut

• Chromium shipping'i ve zararın ölçülmesi

  • Chromium'un blink API owner approver'larından biri Mozilla'nın kaygılarını paylaştığını, ancak deney yapmayı, hatalardan öğrenmeyi ve rekabeti teşvik eden bir yolu tercih ettiğini söyledi
  • İleride gerçek zararı değerlendirmek için somut sonuçların tanımlanması gerektiği; EME gibi tartışmalı API dağıtım kararlarının 5-10 yıl sonraki gerçek sonuçlarla karşılaştırılmasının yararlı olduğu bağlamı veriliyor
  • Sitelerin Google'a özgü modellere kilitlenmesinin zararı, diğer tarayıcılar aynı özelliği dağıttığında karşılaştıkları site uyumluluğu hatalarının sayısı ve büyüklüğü ile Chrome model güncellerken oluşan hata türleri üzerinden ölçülebilir
  • Hataların “modeli daha akıllı hale getirmekten” mi yoksa “garip quirk'leri korumaktan” mı kaynaklandığını ayırmak ve bunları webcompat.com üzerinde etiketleyerek toplamak öneriliyor
  • blink-dev I2S bilgisine göre Edge de bu API'yi farklı bir modelle dağıtıyor; dolayısıyla erken veriler zaten mevcut
  • TOS endişeleri için zarar metriğinin, ihlal yüzünden gerçek dava ya da hukuki tehdit ortaya çıkıp çıkmadığı olduğu ve böyle kanıtların kayda geçirilmesi gerektiği söyleniyor

• Sonradan hafifletme ve Chrome'un yanıtı

  • Olası zararları gerçekten gözlemleme yaklaşımı makul bulunsa da, bunun ancak zarar ortaya çıktıktan sonra anlamlı hafifletme seçenekleri varsa yararlı olacağı yönünde karşı görüş var
  • Siteler Google'a özgü modellere kilitlenirse; özelliğin geri çekilmesi, aşırı uyarlanmış site prompt'larını bozan model değişiklikleri, rastgele model rotasyonu veya cihaz üstü model ağırlıklarının açık standartlaştırılması gibi seçenekler soru olarak sıralanıyor
  • Diğer tarayıcıların Chrome modelinin tuhaf quirk'lerini kopyalamak zorunda kaldığına dair kanıt çıkarsa, Chromium liderliği pozisyonundan Chrome'u bu quirk'leri kırmaya zorlayacağı ifade ediliyor
  • Mobile GMail'in hatalı WebKit border image quirks'lerine bağımlı olduğu ve Firefox'un bunu kopyalama ihtiyacı duyduğu bir durumda, Chrome'un düzeltilip GMail'in kırıldığı; GMail'in de hızlı güncellenmesi sayesinde kullanıcıların bunu fark etmediği örneği hatırlatılıyor