AI Agent'ınız Browser'ı Küçültünce Çalışmaz: Benchmark Puanları Her Şeyi Söylemiyor
Browser Zoom Deneyi: Yapay Zeka Benchmark'larının Karanlık Yüzü
Şöyle bir deney yapabilirsin: En güncel GUI agent'ını al, tanıdık bir web sitesine yönlendir, tarayıcı zoom'unu %70'e düşür. Her şey yerli yerinde—düzen aynı, butonlar aynı yerde, sadece biraz küçük görünüyor.
Model muhtemelen başarısız olacak.
Bu, uç bir senaryo değil. Tam da yapay zeka benchmark'larının ölçtükleri ile üretim ortamında yapay zekadan beklediklerimiz arasındaki uçurumu gözler önüne seriyor. Bir AI destekli tarayıcı asistanı mı inşa ediyorsun, özerk bir web scraper mı, yoksa yeni nesil bilgisayar kullanım agent'ları mı geliştiriyorsun—fark etmez, bu boşluğu anlaman kritik.
Sayıların Arkası
Bugünün GUI modelleri ScreenSpot-v2 gibi testlerde %90'ın üzerinde doğruluk oranları elde ediyor. Seçenekleri değerlendiren bir geliştirici için bu, "problem çözüldü, algı artık dar boğaz değil" anlamına geliyor.
Ama bu sayıların görmedikleri var.
ScreenSpot-v2, diğer GUI testleri gibi dondurulmuş ekran görüntüleri üzerinde çalışıyor. Aynı sayfa, aynı şekilde render edilmiş, her seferinde. Gerçek web siteleri böyle çalışmıyor. Kullanıcılar zoom yapıyor. Ekipler tasarım değişiklikleri gönderiyor. Karanlık mod renk ilişkilerini değiştiriyor. Farklı tarayıcılar aynı CSS'i biraz farklı render ediyor.
Model varyasyonla başa çıkmayı öğrenmemiş—belirli screenshot'ları tanımayı öğrenmiş. O yüksek benchmark puanları, gerçek görsel anlama kapasitesini değil, ezberleme becerisini ölçüyor.
GUI-Perturbed araştırmacıları (Fig, Inc.'den) tam olarak ne kadar benchmark performansının sıradan varyasyonlarla başa çıkabileceğini ölçmeye giriştiler. Yöntemleri buydu: görsel sahneleri kontrollü eksenler boyunca sistematik olarak bozarak doğruluk düşüşünü ölçmek. Buldukları, üretim bilgisayar-kullanım sistemleri inşa eden herkesi rahatsız etmeli.
Üçlü Hizalama Problemi
Sonuçlara dalmadan önce, GUI grounding'ın ne gerektirdiğini konuşalım. Bir model bir ekran görüntüsü görüp "gönder butonuna tıkla" komutunu aldığında, üç farklı hizalama türü eş zamanlı olarak gerçekleşmeli:
Görsel hizalama adı üstünde—piksel örüntülerini arayüz elementleriyle eşleştirmek. Butonun belirli bir şekli, rengi ve boyutu var, modelin bunları tanıması gerekiyor.
İşlevsel hizalama elementin ne yaptığını anlamaktır. Bir giriş alanı bir etiketten farklı görünür, tıklanabilir bir buton statik bir simgeden farklıdır—ortak görsel özellikler taşısalar bile.
Geometrik hizalama uzamsal ilişkileri çözer. "Arama çubuğunun üstündeki buton" veya "Etiketin sağındaki form alanı" demek, şeylerin sadece nasıl göründüğünü değil, birbirine göre nerede olduğunu anlamayı gerektirir.
İşte rahatsız edici kısım: Çoğu benchmark hepsini bir arada ölçüyor. Bir model %85 aldığında, üçünü de başarmış mı yoksa görseli geçip geometriyi tamamen mi rastgele yapmış, bilmiyoruz. Bu önemli çünkü başarısızlık modları farklı ve çözümler de farklı.
Modellerin Gerçekte Kırıldığı Yerler
GUI-Perturbed metodolojisi her hizalama eksenini bağımsız olarak stress-test ediyor. Sonuçlar, bir kırılganlık hiyerarşisi ortaya koyuyor:
Uzamsal Talimatlar Felaket Derecede Zayıf
Bu büyük sorun. Talimatlar "gönder butonuna tıkla"dan "iletişim formunun üstündeki butona tıkla"ya kaydığında, doğruluk modelden modele 27 ila 56 puan düşüyor. 27 puanlık düşüş endişe verici. 56 puanlık düşüş ise herhangi bir üretim kullanımı için eleme niteliğinde.
Model belirli bir butonu doğrudan adlandırıldığında tanıyabiliyor. O butonun uzayda nerede olduğunu sorguladığında, performans çöküyor.
Bu, doğal dil talimatlarının sıklıkla uzamsal referanslar içermesi nedeniyle özellikle sorunlu. "Aşağı kaydır ve forma tıkla" veya "Başlığın altındaki seçeneği işaretle" insanların görevleri tanımlama biçimlerine çok doğal. Mevcut modeller bu talimatlarda neredeyse anında başarısız oluyor.
Görsel Bozulumlar Sert Etki Yapıyor
Zoom deneyi bir sapan noktası değil. Tarayıcı zoom'unu %70'e değiştirmek, test edilen üç modelin tamamında doğruluğu 2 ila 6 puan düşürüyor. Bu felaket değil, ama düşündürücü: Model elementleri belirli bir ölçekte tanımayı öğrenmiş, ölçek değişince bu kalibrasyon bozuluyor.
Gerçek kullanıcılar zoom yapıyor. Farklı monitörler farklı varsayılan DPI ayarlarına sahip. Web uygulamaları cihaza göre farklı fiziksel boyutlarda render ediliyor. Bunlar her gün olan şeyler, düşmanca koşullar değil.
Daha rahatsız edici ima, modellerin nasıl öğrendiğini gösteriyor olması. İnsanlar gibi ölçek-değişmez temsiller oluşturmuyorlar—eğitim zamanındaki çözünürlüklerdeki görünümü ezberliyorlar.
Chain-of-Thought Düşünmenin Bedeli Var
Davranadan önce bir düşünme adımı eklemek, zor ilişkisel görevlerde yardımcı oluyor ama kolay doğrudan görevlerde performansı düşürüyor. Modelin ne zaman düşüneceğini ve ne zaman doğrudan davranacağını bilmesi gerekiyor.
Bu pratik bir deployment sorunu yaratıyor. Her yerde chain-of-thought'u açamazsın ya talimatın ne zaman düşüneceğine karar veren bir router gerekiyor ya da her iki modda da gerçekten iyi olan bir model. Mevcut modeller basit görevleri gereğinden fazla düşünüyor gibi görünüyor.
Post-Training'in Aslında Satın Aldıkları
İşte en düşündürücü bulgu: Daha fazla GUI-odaklı post-training bu sorunların hiçbirini çözmüyor.
Test edilen üç model aynı base checkpoint'i paylaşıyor ama farklı miktarlarda GUI-spesifik fine-tuning'ten geçmiş. Ek eğitim sabit sahne benchmark puanlarını yükseltmiş. Görsel bozulmalara dayanıklılığı, uzamsal akıl yürütmeyi veya zoom hassasiyetini iyileştirmemiş.
Bu, post-training'den gelen benchmark kazanımlarının kısmen illüzyon olabileceği anlamına geliyor—modeller test dağılımında daha iyi performans gösteriyor, temel görevde değil. Genelleştirilebilir yetenekler inşa etmeden benchmark'a daha hassas bir şekilde uyum sağlıyorlar.
Modelleri değerlendiren veya üzerine inşa eden ekipler için bu kritik bir ayrım. "ScreenSpot-v2'de %92 başarıyor" ifadesi, modelin screenshot'larda GUI elementlerini tanıyabildiğini söylüyor. Gerçek web tarama değişkenliğiyle başa çıkıp çıkamayacağı hakkında hiçbir şey söylemiyor.
İnşaatçılar İçin Çıkarımlar
Bilgisayar-kullanım agent'larının üzerine uygulama inşa ediyorsan, bu araştırmadan birkaç şey çıkıyor:
Üretim ortamın değerlendirme ortamından daha zor olacak. Sabit sayfa setine karşı test yapıyorsan, sistemin üretimde nasıl performans göstereceğini ölçmüyorsun. Değerlendirme pipeline'ına bozulma testleri eklemeyi düşün—görevlerini farklı zoom seviyelerinde, CSS varyasyonlarıyla, yeniden tasarlanmış sayfalarda dene.
Uzamsal talimat işleme özel ilgi gerektiriyor. Uygulaman doğal dil talimatları kullanıyorsa ve bunlar uzamsal referanslar içeriyorsa, mevcut genel amaçlı modeller zorlanacak. Talimat formatlarını kısıtlamak, açık koordinat tahmin fallback yolları eklemek veya uzamsal akıl yürütme alt görevleri için uzmanlaşmış modeller kullanmak gerekebilir.
Yeniden tasarım kırılmalarını izle. Hedef web siteleri düzenlerini değiştirdiğinde, agent'ının doğruluğu aniden düşebilir—model kötüleştiği için değil, daha önce görmediği bir görsel konfigürasyonla karşılaştığı için. Element konum stratejilerini önbelleğe almayı ve sapmayı izlemeyi düşün.
Önümüzdeki Yol
Bu araştırma bilgisayar-kullanım agent'larının işe yaramaz olduğu anlamına gelmiyor. Alanın, asıl önemli olanı—benchmark performansı değil, sağlamlılığı—ölçmenin daha iyi yollarına ihtiyacı olduğu anlamına geliyor.
İyi haber, problemlerin artık görünür ve ölçülebilir olması. GUI-Perturbed metodolojisi, modelleri belirli eksenler boyunca stress-test etmenin bir yolunu sunuyor. Bu sistemleri inşa eden veya satın alan biriysen, statik benchmark puanları yerine bozulmaya-dayanıklı değerlendirme sonuçlarını görmek için ısrar et.
Üçlü hizalama problemi—görsel, işlevsel ve geometrik anlamanın birlikte çalışması—gerçek. Üstesinden gelinebilir. Ve bunu çözmek, kullanıcılarının yaşadığı dağınık, değişken dünyada gerçekten işleyen yeni nesil güvenilir AI agent'larının önünü açacak.
Şimdilik, o %90+ benchmark puanlarını bir başlangıç noktası olarak gör, bir varış noktası olarak değil. Kullanıcıların AI asistanı zoom yapılmış bir tarayıcıyla sorunsuz başa çıktığında, sana teşekkür edecekler.