Mozilla'nın Chrome'un Prompt API'sine karşı çıkışı
(github.com/mozilla)- Tarayıcı içi dil modelini bir web API 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 prompt'ları ve özellikleri Edge'in Phi-4-mini'si gibi belirli uygulamalara göre ayarlarsa, diğer tarayıcılarda veya modellerde kalite düşüşü ya da site erişiminin engellenmesi ortaya çıkabilir
- Mozilla, doğrudan web API olarak göndermek yerine userland doğrulamasından daha fazla geçmesi gerektiğini düşünüyor; erken geri bildirim yolu olarak trial web extension API ve Web Machine Learning grubunun web extension önerisini öne çıkarı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 model ekleme baskısı hissedebilir
- Chrome tarafı JSON schema·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ındaki olumsuz değerlendirmesi
- Prompt API, Blink'in intent-to-prototype sürecinin 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 büyütüyor
- Geliştiriciler belirli bir modele göre prompt'ları ve özellikleri ayarlayabilir; Edge'in Phi-4-mini gibi bir uygulama hedeflenirse diğer tarayıcılarda veya modellerde kalite düşebilir ya da site erişimi engellenebilir
- Doğrudan web API olarak göndermek yerine userland'de daha uzun süre doğrulanması gerektiği düşünülüyor; Mozilla'nın trial web extension API ve Web Machine Learning grubunun web extension önerisi erken geri bildirim toplama kanalı olarak görülüyor
- İlgili tartışmalar ve #1067 temel alınarak Prompt API konusundaki tutum negative olarak işaretlendi
Neden Origin Trial yerine Web Extension tercih edildi?
-
Model seçimi ve standardizasyon zamanlaması
- Model hub'ından tam olarak doğru modeli seçebilme özelliği, sayfa içi işlevler ve tarayıcının belirli bir model seçmemesi açısından temel kabul ediliyor
- Bu yetenek, hızla değişen bir alanın uygulama ayrıntılarını varsayıyor ve henüz standardize edilmeye hazır görülmüyor
- Extension'lar, mevcut öneri kapsamının ötesinde gerçek kullanım kalıplarını hızlıca keşfetmenin ve üç motorun henüz oturmamış semantiklerde uyum sağlayıp gönderme maliyeti olmadan tarayıcılar arası özellik denemenin düşük maliyetli bir yolu olarak görülüyor
-
Kullanıcıya görünen sınırlar
- Add-on kurulumu, kullanıcının genel web özelliklerinin sınırını aştığına dair bir sinyal sayılıyor; burada söz konusu olan paylaşılan cross-origin storage
- Bu değerlendirme, başka bir bağlamdaki WebMIDI Add-On Gated konum ekleme #704 ile benzer bir mantık izliyor
- Söz konusu extension önerisi, sayfaya Prompt benzeri bir API açıyor ve yerel çıkarım ile geliştiricinin belirlediği modeli kullanarak paylaşılan 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ı yanıtlar verdi ve bu, İngiliz aksanlı hoparlör sesiyle uyuşmadı
- Sistem prompt'una İngiliz aksanıyla konuştuğu eklendiğinde bu kez “a'waight guv'nor apples and pears” gibi Amerikalıların İngiliz taklidi bir sonuç çıktı; daha gerçekçi bir İngiliz tonuna yaklaşması için ek ayar gerekti
- Bir model için yapılan düzeltme, başka bir modelde aşırı düzeltmeye dönüşebilir; sorun, markalı voice'larda ya da JSON schema·regex ile ifade edilemeyen çıktı biçimlerinde daha büyüktür
-
Yeni modeller ve tarayıcı güncelleme 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 bir model kullanmak zorunda kalabilir
- Aynı nedenle Chrome'un da kendi modelini güncellemesi zorlaşabilir
-
Model ID tespiti ve tarayıcı dallanması
- Geliştiriciler
LanguageModel.create()ile bir model oluşturupmodel.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 şirketini sorabilir - Örnek dönüş değeri
'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind' - Geliştiriciler belirli modellere özel sistem prompt paketleri hazırlayabilir ve bilinmeyen modelleri engelleyebilir ya da kullanıcıya çıktı kalitesinin düşük olabileceğini bildirebilir
- Bu tür bir akış, kaçınılması gereken 2000'lerin başındaki code branching yaklaşımına geri dönüş olarak görülüyor
- Geliştiriciler
Google politikası ve model tarafsızlığı sorunu
- Chrome belgelerine göre Prompt API kullanılmadan önce Google Generative AI Prohibited Uses Policy kabul edilmelidir
- Bu politikanın bazı kısımları yasal zorunlulukların ötesine geçiyor; örneğin “cinsel açıdan açık içeriği teşvik eden içerik oluşturma veya dağıtma” ve “hükümet veya demokratik süreçlerle ilgili yanıltıcı iddiaları teşvik etme” yasaklar arasında
- Web platformu API'lerinin kullanıcı aracısına göre kullanım kuralları dayatması iyi bir yönelim olarak görülmüyor ve daha fazla API'ye UA'ya özgü kurallar eklenmesi için emsal oluşturabilir
- Kullanıcı bir web sitesindeki makale yorumunda “summarize” düğmesine tıklarsa ve sonuç Google politikasını ihlal ederse, sorumluluğun düğmeye tıklayan kullanıcıda, ihlalli içeriği yazan yorum yazarında ya da bu yorumu kullanıcının UA LLM'ine ileten özelliği geliştiren site sahibinde olup olmadığı belirsiz
- Geliştiriciler, model şartlarına uymak ve model sahibinin hukuki yaptırımlarından kaçınmak için hangi LLM ile iletişim kurduklarını bilmek isteyebilir; bilinmeyen model, bilinmeyen şartlar anlamına gelebileceğinden kullanımın engellenmesi makul bir tercih olabilir
- Belirli bir tarayıcının web site geliştiricilerine bu tür şartları dayatması için bir gerekçe olmadığı ve bu politika sorununun API önerisinin kendisinden ayrı ele alınması gerektiği yönünde bir görüş de var
Chrome tarafındaki güncellemeler ve hafifletici önlemler
- Chrome Prompt API ekibi, blink-dev I2S ve ChromeStatus'taki interoperability and compatibility risks güncellemesini paylaştı
- WebML CG katılımı ve tartışmalarının sürmesi isteniyor; birlikte çalışabilir sampling parameters gibi sonraki deneyler de devam ediyor
- 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çeneğini web geliştiricileri ve kullanıcılar için faydalı hale getirmeyi amaçladığını belirtiyor
- Prompt API yüzeyi, hem Google hem de Microsoft modellerinde belli ölçüde uyumluluk gösterdi ve bilinen JSON schema veya regex'e uyan çıktılar üretmek 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 özgü hack'lere duyulan ihtiyacı azaltan bir hafifletici önlem olarak sunuluyor
- Aşağı akış Chromium projeleri alternatif modelleri ve framework backend'lerini inceliyor; buna Microsoft'un Android MLKit entegrasyon çalışması ve Apple foundational model entegrasyonu için ilk prototipleme dahil
- API'nin trial aşamasında çeşitli model sürümleri deneysel olarak dağıtıldı; model güncellemeleri ve iyileştirmeleri hâlâ gerekli 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 iyi 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çeveyi hedeflediğini söylüyor
Web geliştiricisi desteği gerekçesi ve gönderim eleştirisi
- blink-dev intent to ship belgesi, web geliştiricilerinin tutumunu “Strongly positive” olarak işaretliyor ve gerekçe olarak explainer içindeki stakeholder feedback bölümüne bağlanıyor
- Bu gerekçenin “Strongly positive” değerlendirmesiyle pek örtüşmediği ifade ediliyor
-
Gerekçe olarak sıralanan öğeler
- İki olumlu yanıt içeren GitHub thread
- X üzerinde tek bir gönderi
- Artık mevcut olmayan bir blog yazısı, Server Not Found durumunda
- Hâlâ mevcut olan bir blog yazısı
- Anket geliştiricilere, bu API extension içinde olsa da uygun olup olmayacağını soruyor gibi görünüyor; ancak anketin sayıları veya hedef kitlesi belirtilmiyor
- Kayıp blog yazısı için Wayback Machine bağlantısı üzerinden arşiv kopyası paylaşılıyor
- Belgede “bağımlı olunmaması gerekenler” ve “güvenilebilecekler” büyük şekilde işaretlense bile, bu tavsiyelere uyulursa API'nin olası kullanım alanı o kadar daralabilir ki gerçekte işe yarar bir kullanım kalıp kalmadığı belirsizleşir
- Pratikte, test edilen belirli modelin davranışına belli ölçüde bağımlı olunabilir ve eğer bu model Chrome'un modeli ise site en güncel Chrome'u kullanma uyarısı gösterebilir
- Google'ın tamamlanmamış alanı geniş biçimde tanımlamasına rağmen mevcut hafifletici önlemlerle gönderim için yeterli olduğunu düşünmesi sorun olmaya devam ediyor
Yorum tartışması: alternatifler, zararın ölçümü, sonradan hafifletme
-
Tarayıcı otomasyonu ve Lynx mode
- Hermes Agent ve Qwen3.6 ile işlerin çoğu yapılabildiği, Prompt API'den ziyade browser automation API ve sohbet için Lynx mode'a daha çok dikkat edilmesi gerektiği görüşü var
- Bazı iş akışlarında insan web sitesine giriş yapıyor ve AJAX eklentisiyle dosyaları görünür kılıyor; ardından agent, chromedriver/webdriver üzerinden belge indirme, etiketleme ve özetleme yapıyor
- Bu akış, harici POSIX shell olmadan tarayıcı içinde bütünleşik hâle gelebilir
- Lynx mode sohbeti, agent'ların gördüğü içeriği hızlıca açığa çıkarıyor ve tüm medya varlıklarını indirmeyip render etmediği için iki tarafın da kaynaklarını koruyor
- 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çmeli gösterimi de tartışılıyor
-
Açık web ve FOMO
- Açık web'in chat bot super apps ile aynı şekilde rekabet etmediği ve yok olmayacağı yönünde itirazlar var
- Sürekli FOMO yerine önce neyi temsil etmek istendiğini sormak gerektiği görüşü de mevcut
- Web'in mobile app paradigm'ını yeterince destekleyemediği gibi agentic computing'i hızlı ve etkili biçimde destekleyemezse commerce veya journalism'in açık web dışına kayabileceği endişesine katılmayan bir çizgi de bulunuyor
-
Chromium gönderimi ve zararın ölçülmesi
- Chromium'un blink API owner approver'larından biri Mozilla'nın kaygılarını paylaşsa da deney yapma, hatalardan öğrenme ve rekabeti teşvik eden yolu tercih ediyor
- İleride gerçek zararı değerlendirmek için somut sonuçların tanımlanması gerektiği, EME gibi tartışmalı API gönderim kararlarını 5-10 yıl sonra gerçek sonuçlarla karşılaştırmanın faydalı olduğu belirtiliyor
- Sitelerin Google'a özgü bir modele kilitlenmesi; diğer tarayıcılar gönderim yaptığında görülen site uyumluluk hatalarının sayısı ve boyutu ile Chrome model güncellerken ortaya çıkan hata türleri üzerinden ölçülebilir
- Hatanın “modeli daha akıllı yapmak” mı yoksa “garip bir quirk'i korumak” mı olduğunun ayırt edilmesi ve webcompat.com üzerinde etiketlenerek toplanması öneriliyor
- blink-dev I2S belgesine göre Edge de bu API'yi farklı bir modelle gönderiyor; dolayısıyla erken veriler zaten mevcut
- TOS kaygısına ilişkin zarar metriği, ihlal nedeniyle gerçek dava veya tehdit oluşup oluşmadığı; böyle kanıtların kayıt altına alınması öneriliyor
-
Sonradan hafifletme ve Chrome'un yanıtı
- Olası zararın fiilen doğrulanmasına dayalı yaklaşım makul görülse de bunun ancak zarar ortaya çıktıktan sonra anlamlı hafifletici önlemler varsa işe yarayacağı yönünde itiraz var
- Siteler Google'a özgü bir modele kilitlendiğinde feature unship, aşırı uyarlanmış site prompt'larını bozan model değişiklikleri, rastgele model rotasyonu, cihaz üstü model ağırlıklarının açık standartlaştırılması gibi seçenekler soruluyor
- Başka tarayıcıların Chrome modelinin garip quirk'lerini kopyalamak zorunda kaldığına dair kanıt görülürse, Chromium liderliği düzeyinde Chrome'un bu quirk'i kırması için baskı yapılacağı ifade ediliyor
- Mobile GMail'in hatalı WebKit border image quirks'lerine bağımlı olduğu ve Firefox'un bunu kopyalamaya ihtiyaç duyduğu dönemde Chrome'un düzeltilip GMail'in bozulduğu, ardından GMail'in hızla güncellendiği ve kullanıcıların bunu fark etmediği örneği de aktarılıyor
1 yorum
Hacker News yorumları
Karşı çıkışın gerekçesi oldukça açık görünüyor: prompt ile modelin sıkı biçimde eşleşmesi ve kullanım şartlarındaki model tarafsızlığı sorunu
https://github.com/mozilla/standards-positions/issues/1213 içindeki kişisel örnekte olduğu gibi, ev otomasyonu bildirimleri için bir sistem prompt'u hazırlarken Gemini ilk başta fazla Amerikan tarzında yanıt vermiş; İngiliz aksanıyla konuştuğu söylenince bu kez “a'waight guv'nor apples and pears” gibi bir Amerikalının beceriksiz İngiliz taklidi çıkmış ve daha fazla ayar yapmak gerekmiş
Bu süreçte sistem prompt'u belirli bir modele göre ayarlanıyor; başka modellerin başka quirks'leri olduğundan, bir model için eklenen düzeltme diğerinde aşırı düzeltme olabilir
Modellerin birbirinden farklı olması bu teknolojinin temel özelliği. Tıpkı cihaza ya da yöne göre canvas boyutunun değişmesi, geolocation API doğruluğunun farklılaşması ya da Speech Synthesis seslerinin cihaza göre değişmesi gibi
Bu, yapıcı eleştiriden çok anti-AI duygusu gibi geliyor. Şu anda izin UI'ı gerekebilir ve bir gün low/medium/high gibi IQ seviyeleri bile eklenebilir, ama bunu gerçekten önemseyen geliştiriciler zaten %90 oranında belirli bir modele bağımlı hale gelecek
Zamanla yapay zeka nefreti azalır ve insanların bunun faydalı olduğunu fark etmesiyle, Firefox'ta bu özelliğin olmaması kişisel veri özerkliği açısından bir başarısızlık gibi görünebilir. Sorun Chrome'un ilgili TOU'suysa, bu aslında Firefox'un sorunsuz model şartlarıyla bu özelliği sunması için daha da güçlü bir gerekçe olur
Karşı yazıyı kimin yazdığını bilmiyordum ama meğer Chrome ekibinde uzun süre çalışmış Googler Jake Archibald, Mozilla'ya geçip Chrome API'sine karşı çıkan yazıyı yazmış. Eleştirinin iyi derlenmiş olmasına şaşmamak lazım; bu kez parti çizgisine uymak zorunda olmamak da herhalde rahatlatıcı olmuştur
Hâlâ ekipte kalanlardan duyduğum kadarıyla o açıdan durum katlanarak daha da kötüleşmiş gibi görünüyor
Değişiklik önermek yerine her şeyi çöpe atmaya çalışma havası var; sanki çöpe atılırsa Google Chrome ekibinin bakış açısından başlamadan, baştan itibaren işbirliğiyle yeniden yazılmasını umuyorlar. Ama bunun işe yaradığı pek örnek görmediğim için, doğrudan somut düzeltme önerileri sunmak daha iyi olurdu gibi geliyor
Buna karşıyım
explainer, verilerin hiçbir yere gönderilmeden yerelde işlenebileceğini söylüyor ama o zaman Google Gemini yerel modeli için neden Prohibited Use Policy gerektiği sorusu doğuyor. Google, bilmesinin mümkün olmadığı prompt ve yanıtları neden önemsesin ki
Çevrimdışı LLM erişimi kendi başına iyi görünüyor ama web sitelerinin LLM'i tarayıcıya gömmeye gerek duymadan WebGPU kullanması ya da ML model işleme için WebGPU'nun geliştirilmesi mümkün. Ya da herkes aynı açık kaynak LLM'i kullanmalı
robots.txt'nin zorunlu olmadığı ve tamamen aşılabildiği artık genel kabul gördü; bu da açık web'i fiilen bir dark forest haline getirdi
Tarayıcı oturumunun kurcalanmadığını ya da “trusted” olduğunu doğrulayan yöntemler muhtemelen gelecek. Berbat bir şey ama biraz da bunu kendi elimizle hazırladık
Bir sitenin küçük LLM istekleri göndererek modelin kendisini fingerprinting etmesi mümkün olabilir ama kapatılabiliyorsa bunu büyük bir sorun olarak görmüyorum
Daha geniş açıdan bakınca “web platformu bunu yapabilmemeli” türünde bir kaygı da var. Bu pozisyonda olanlar, kullanıcı kapatabilse bile “LLM yok, o halde tarayıcı desteklenmiyor” diyen sitelerin çıkacağını ve web'in kötüleşeceğini savunabilir
Ama bu sonuçta web sitesi sahibinin, LLM yoksa siteyi kapatma kararıdır; özelliği yapan platformun ya da bakımını üstlenenlerin suçu değildir. Firefox'ta da düzgün çalışmasına rağmen test etmeye üşenip desteği kapatmaya benziyor
Web, PDF ile değil SwiftUI ile rekabet eden dünyanın en başarılı uygulama platformu. “Web'i olduğu gibi statik tutalım” seçeneği bir hayal; gerçek seçenek, web'i kullanıcıların değişen ihtiyaçlarına uyarlamak ya da web'in başarısız olup yerini SwiftUI ya da WinUI'nin almasıdır. İkincisi çok daha kötü
https://news.ycombinator.com/item?id=47960596
Sonuç olarak artık bunu geride bırakma zamanı gelmiş demek. Web tarayıcısından daha iyi çevrimiçi bilgi alışverişi ve medya oynatma biçimleri düşünmemiz gerekiyor. Eğer ürün bizsek, kullandığımız araçlar da reklam gelirini gizlice güvenilmez efendilere akıtan bir proxy gibi davranmak yerine bunu doğrudan yansıtmalı
Üzerine düşündükçe bu kez Google'ın API tasarım tarafına daha yakınım
Prompt ile modelin sıkı biçimde eşleşmesi gerçek bir kaygı ve her gün yaşanan bir sorun. Ama çözüm, kullanıcının tarayıcısındaki model ile değerlendirilecek prompt'u daha da sıkı bağlayan bir API ise, yakında “biz prompt'umuzu yalnızca Gemini'da test ettik, bu yüzden bu site için Chrome gerekiyor” gibi bir durum ortaya çıkar
Daha da kötüsü, “hangi AI modelinin kullanıldığını tespit edememe” olabilir. 2026'da yapılmış bir site 2030'a kadar güncellenmezse bu gayet mümkün
Bu, Mozilla mühendisinin dipten değindiği kullanım şartları sorunuyla da bağlantılı. Belirli AI model şartlarını kabul etmek zorunda bırakmayan tarayıcıların, örneğin iyi bir açık kaynak model kullananların, var olabilmesi için Big Models'in fingerprinting yoluyla ayırt edilememesi daha iyi olur
Elbette birçok site zaten isChrome() benzeri çağrılar yapacaktır. Yine de genel olarak tarayıcı fingerprinting yöntemlerini artıran değişikliklere karşıyım. Modeli anonim tutmanın faydası, Gemini ile Qwen gibi modeller arasındaki küçük farklar yüzünden nadiren ortaya çıkan tuhaf çıktılardan daha büyük
Google neden tarayıcının zaten yapabildiği onca şeydeki yapısal zayıflıkları düzeltmeye büyük kaynaklar ayırmak yerine, sürekli rastgele şeyler ekleyip tarayıcıyı Homermobile'a çevirmeye çalışıyor, anlamıyorum
Statik bloglardan e-ticarete, en gelişmiş web uygulamalarına kadar tüm web platformunda yaşam kalitesini artıracak temel konulara odaklanamaz mı
https://simpsons.fandom.com/wiki/The_Homer
Android ve ChromeOS ile bunu doğrudan deniyorlar ama Chrome, Windows gibi ortamlardaki ortalama kullanıcının bile zamanının çoğunu Google dünyasında geçirmesini sağlıyor
Mevcut LLM ve API harness durumunun, böyle bir API'nin standarda girecek kadar teknik olarak olgun olmadığını güçlü biçimde düşünüyorum
Yine de yapılacaksa en azından site bazlı opt-in izni olmalı ve prompt'un hangi modele gönderildiğini tanımlamanın bir yolu bulunmalı. Sistem prompt'undaki küçük ayarlar bile bu kimliğin parçası sayılmalı
Bir kullanıcı olarak rastgele bir siteyi ziyaret ettiğimde, iznim olmadan bu API üzerinden fingerprinting'e maruz kalmadığımdan emin olmak isterim
Bir geliştirici olarak da kullanıcıların hangi modeli kullandığını bilmek isterim ki modele özel prompt'lar hazırlama seçeneğim olsun
“Tarayıcıların ve işletim sistemlerinin dil modellerine erişmesi giderek daha çok beklenecek” mi? Gerçekten öyle mi?
https://github.com/webmachinelearning/prompt-api/blob/main/R...
Dolayısıyla varsayılanı kapalı olan, kullanıcının isterse açabileceği bir LLM arayüzü sunmak yeterli olur
Böylece Apple'ın OS'ye koyduğu LLM'e kilitlenmek zorunda kalmadan hangi LLM provider'ı kullanacağını seçebilirsin. Örneğin Apple Intelligence'ın erişebildiği şeylere Claude'un da erişebilmesini isterim
Artık “erişmesi beklenecek” yerine “yerleştiriliyor” denebilir gibi. Birçok kişi karıştırıyor gibi göründüğü için proje bakım ekibinin bunu güncellemesi iyi olurdu
Teoride faydalı. Geliştiriciler yerel modellere güvenebilirse daha private ve decentralized bir yapı olur, ayrıca AWS ya da Anthropic'e para gönderme ihtiyacı azalır. Yerel olduğu için çevrimdışı çalışabilmesi ve ücretsiz olması, ancak düşük riskli bazı kullanım alanlarında anlamlı oluyor
Ama pratikte yerel uygulamalarda Apple Foundation Models benimsenmesini neredeyse hiç görmedim. Mac/iOS geliştiricilerinden paylaşacak bir şeyler olan var mı merak ediyorum
Artık her şey giderek daha fazla bikeshed bekliyor. CVE bekleniyor
Açık protokollerin güzel yanı, belirli bir uygulamayı desteklemek ya da kullanmak zorunda olmamanızdır; ama ne olursa olsun tarayıcı tekeli ikilemi sürüyor
ungoogled chromium ve Tor gibi iyi projeler var ama asıl büyük sorun, ortalama kullanıcı adına konuşan ve kitlelerle bağ kurabilen projelerin eksikliği
Konuya uzak kullanıcıların önemli bir kısmı davaya ve mesajın nasıl iletildiğine kayıtsız; özgürlük ve kontrolden çok “eğlenceli” ve sürtünmesi az olan şeylere tepki veriyorlar
Bunu nasıl çözeriz? Tarayıcıyı nasıl yeniden bizim, insanlar tarafından, insanlar için olan bir şeye dönüştürebiliriz? Bunları düşündükçe sadece üzülüyorum
Browser Agent dizesi Chrome ya da Firefox değilse bitmek bilmeyen Cloudflare CAPTCHA'ları ya da 403'lerle karşılaşıyorsun
Sonrasında web uygulamalarını Chrome'un yaptığına göre değil, web standartlarına göre kurmalı ve Firefox ile Safari yetişemiyor diye şikâyet etmemeli
Ortalama insana ulaşan projelere ihtiyaç olduğunu söylerken, aynı zamanda onların özgürlük ve kontrolden çok düşük sürtünmeyi istediğini söyledin. Burada bir çelişki var. Ortalama insan kontrol değil, less friction ile bağ kuruyor
Bu API'nin use case'inin ne olduğunu merak ediyorum
Yerel LLM çalıştırırken benim deneyimim, llama-server başlatmak, gerekirse onu ayrı bir makinede çalıştırmak ve sonra başka uygulamaları OpenAI ya da benzeri bir hizmet yerine o OpenAI uyumlu sunucuya işaret edecek şekilde ayarlamak oluyor
Tarayıcının bir LLM örneği oluşturmasını ya da çalıştırmasını istemem. Çünkü o makinenin LLM örneği çalıştıracak gücü ya da boş kapasitesi olmayabilir
Acaba bu, LLM'siz yaşamayı artık düşünemeyen genç kuşak ile, mahremiyeti ihlal eden bir web tarayıcısını çalıştırmak için süper bilgisayar gereksinimi duymak istemeyen eski kuşak arasındaki fark mı
Bana daha çok insanların tarayıcıya/web'e alternatifler aramaya ve geliştirmeye başlaması gereken nokta gibi geliyor
Sadece önerilen API'nin mevcut haliyle web birlikte çalışabilirliği için neden kötü olduğuna dair açık ve mantıklı gerekçeler sunuyor
Ben şahsen kod yazma yardımı ve ev otomasyonunda LLM kullanıyorum ama bu API'nin web için iyi olduğunu düşünmüyorum
Cevabını bilmiyorum ama Niri/Wayland, GNOME, Windows ve Mac kullandıktan sonra artık döşemeli olmayan masaüstüne ve klavye merkezli olmayan masaüstü pencere yönetimi workflow'una asla geri dönmem