Bir özellik web'e nasıl girer? Prompt API tartışmasıyla standart süreci

Web’i tek bir şirket yönetmiyor

Bir programlama dilini genelde bir şirket ya da ekip geliştirir. Web farklı. HTML, CSS ve JavaScript’i birkaç tarayıcı motoru birlikte geliştiriyor: Chrome’un Blink’i, Safari’nin WebKit’i ve Firefox’un Gecko’su. Bir özelliğin “web’in parçası” sayılması için bu tarafların uzlaşması gerekiyor.

Syntax’ın 1012. bölümünün konuğu Jake Archibald bu süreci içeriden biliyor. On yıl Chrome’da çalıştı, şimdi Mozilla’da. 1017. bölümde de Wes Bos ve Scott Tolinski, bu süreci nereden takip edebileceğini anlattı.

Bir özelliğin yolculuğu

Kabaca şöyle ilerliyor:

• Öneri. JavaScript için TC39 komitesi aşamalı bir süreç kullanıyor: Aşama 0’dan 4’e, arada bir de 2.7. Aşama 4, özelliğin dile girdiği anlamına geliyor. HTML için WHATWG’ye, CSS için CSS Çalışma Grubu’na (CSSWG) öneriler yapılıyor. Hepsi GitHub’da açık.
• Tarayıcıların görüşü. Mozilla ve WebKit, her öneri için resmi bir “pozisyon” yayınlıyor: destekliyoruz, tarafsızız ya da karşıyız. Bu sayfalar, bir özelliğin gerçekten her yere gelip gelmeyeceğinin en iyi göstergesi.
• Deneme. Chrome yeni özellikleri önce bir bayrak (flag) arkasında ya da “origin trial” ile sınırlı olarak açıyor. Syntax’a göre en değerli geri bildirim bu aşamada geliyor. Henüz değiştirmek mümkünken.
• Testler ve Interop. Web Platform Tests, tarayıcıların aynı davranıp davranmadığını ölçen ortak test paketi. Her yıl yapılan Interop projesinde tarayıcılar, belli özelliklerde bu testleri birlikte geçmeyi hedefliyor.

Sen de katılabilirsin. Developer Signals projesinde, henüz her tarayıcıda olmayan her özellik için bir GitHub konusu var. Bir 👍 bırakmak bile tarayıcılara “bunu istiyoruz” demek. Bu yolculuğu Chrome 150 ile gelen sırasız HTML akışı yazımızda somut bir örnekle izleyebilirsin.

Örnek: Prompt API

Chrome’un Prompt API’si, bir web sayfasının tarayıcıya gömülü küçük bir dil modeline (Gemini Nano) metin gönderip cevap almasını sağlıyor. Chrome 138’den beri web’de kullanılabiliyor. Model cihazda çalışıyor, ilk kullanımda indiriliyor. Belgelere göre profil diskinde en az 22 GB boş alan istiyor.

Mozilla’nın resmi pozisyonu ise “karşıyız”. Pozisyon yazısını Archibald yazdı. Ana gerekçe şu: Bir sistem istemi (system prompt) yazarken onu kullandığın modelin huylarına göre ayarlarsın. Archibald kendi örneğini anlatıyor. Evdeki hoparlör için yazdığı istemi bir modelden diğerine geçince baştan düzeltmek zorunda kalmış.

Web’de bu daha büyük bir sorun. Herkes istemini en yaygın tarayıcının modeline göre yazarsa, başka bir tarayıcı daha iyi bir model kullansa bile sonuçlar daha kötü görünür. Ya Google’ın modelini lisanslamak ya da onun huylarını taklit etmek zorunda kalır. Archibald’a göre geliştiriciler “Sen hangi modelsin?” diye sorup ona göre istem seçmeye başlar. Bu, 2000’lerin tarayıcı tespiti (user agent sniffing) alışkanlığının geri dönüşü olur.

Pozisyonda bir itiraz daha var. Mozilla’nın aktardığına göre Chrome’un belgeleri, bu API’yi kullanmadan önce Google’ın üretken yapay zekâ kullanım kurallarını kabul etmeyi istiyordu. Mozilla’ya göre açık bir web API’si bir şirketin kurallarına bağlı olmamalı.

Archibald, kapsamı dar yapay zekâ API’lerine ise sıcak bakıyor. Örneğin bir çeviri API’si: Ne yapacağı belli, sonuç modelden modele çok değişmiyor. Sitenin kendi modelini getirip tarayıcıda çalıştırdığı diğer yolu LiteRT.js yazımızda anlattık. İşletim sistemine gömülü modelin Mac tarafını da Apfel yazımızda ele aldık.

Düşün

• Bir web özelliğini projende kullanmadan önce hangi kaynağa bakıyorsun? Tarayıcıların pozisyonları bu listede var mı?
• Tarayıcıya gömülü bir yapay zekâ modeli sence bir web standardı olmalı mı, yoksa her site kendi modelini mi getirmeli?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.