Gemini’nin “çift kör” testi: Ne Google soruları gördü ne de değerlendiriciler modeli

Google DeepMind, dış değerlendiricilerin test istemlerini Google’a göstermeden ve değerlendiricilere model ağırlıklarını vermeden tescilli bir yapay zekâ modelini sınamaya yönelik bir pilot gerçekleştirdi. 27 Ağustos 2026’da duyurulan çalışmada Gemini 2.5 Flash-Lite; Singapur Yapay Zekâ Güvenliği Enstitüsü, OpenMined, AVERI ve MLCommons ile birlikte değerlendirildi. Google bu çalışmayı, tescilli ve öncü sınıf bir yapay zekâ modelinin dünyadaki ilk “çift kör” değerlendirmesi olarak tanımladı. 1213

Buradaki “çift kör” yaklaşımın temel amacı, iki tarafın da diğerinin hassas varlığına erişememesiydi: Google test sorularını görmedi, dış değerlendiriciler ise Gemini’nin ağırlıklarına ve çıkarım koduna erişmedi.

Gemini pilotunda ne test edildi?

Pilot kapsamında MLCommons’ın AILuminate benchmark ailesinden küçük ve gizli bir istem seçkisi kullanıldı. AVERI’ye göre bu istemler daha önce Google DeepMind’a gösterilmemişti. Testler; siber saldırı desteği, kimyasal ve biyolojik tehlikeler, nefret söylemi, kendine zarar verme ve şiddet suçlarına yönlendirme gibi güvenlik alanlarındaki davranışları incelemeyi amaçladı. 1

Benchmark materyali değerlendirme boyunca gizli kaldı. AVERI istemleri şifreledi; korumalı ortam modeli ve değerlendirme sürecini çalıştırdı; ortaya çıkan yanıtlar daha sonra şifreleri çözülerek üzerinde uzlaşılan ölçütlere göre puanlandı. Pilotun amacı herkese açık bir sıralama tablosu yayımlamak değil, bu değerlendirme yönteminin uygulanabilirliğini göstermekti. Bu nedenle başlık skorları ve temel test istemleri açıklanmadı. 1

Çift kör sistem nasıl çalıştı?

Değerlendirme, Google Cloud Confidential Computing bünyesindeki Confidential Space üzerinde, A3 Confidential VM kullanılarak yürütüldü. Teknik rapora göre Intel TDX, ana makinenin belleğini şifreleyip izole etti. NVIDIA H100 Confidential GPU ise GPU belleğindeki model ağırlıklarını donanım tabanlı şifrelemeyle korudu. Değerlendiricilerin istemleri ile Google’ın model varlıkları, şifreli bağlantılar üzerinden korumalı ortama taşındı. 13

Mimari, iş yükünün yapabileceklerini ve dışarı aktarabileceği verileri sınırlamaya yönelik ek kontroller de içeriyordu. Şifreli veri yolları, donanım güvenlik duvarları, geçici bir enclave yaşam döngüsü ve OpenMined’ın PySyft politika katmanı bu kontroller arasındaydı. Model, çıkarım kodu, istemler ve değerlendirme kodu yalnızca onaylanmış enclave içinde bir araya geldi; burada belirlenen hesaplama çalıştırıldı ve yalnızca sınırlandırılmış çıktılar dışarı gönderildi. 13

Uzaktan doğrulama neden önemliydi?

Şifreleme tek başına içeride hangi yazılımın çalıştığını göstermez. Uzaktan doğrulama (remote attestation) bu belirsizliği azaltmak için kullanıldı. Google ve değerlendiriciler, korunan varlıklarını göndermeden önce bildirilen iş yükünü inceleyebildi ve donanım ile enclave yapılandırmasını tanımlayan doğrulama kanıtını kontrol edebildi. Şifreli istemler ve model varlıkları ancak bu kontrolden sonra ortama teslim edildi. 13

Çalışma tamamlandığında enclave, izin verilen değerlendirme çıktıları ve ölçümleri geri gönderdi; ardından devre dışı bırakıldı. Hedeflenen güven modelinde Google enclave içindeki istemleri okuyamıyor, dış değerlendiriciler de model ağırlıklarını çıkaramıyordu. Bu yaklaşım, yalnızca tarafların test verilerini kaydetmeme veya yeniden kullanmama sözüne dayanmaktan daha güçlü bir koruma sağlıyor. Ancak bütün güven varsayımlarını ortadan kaldırmıyor. 13

Hangi soruna çözüm getirmeyi amaçlıyor?

Yapay zekâ değerlendirmelerinde benchmark kirlenmesi, yani modelin test sorularını daha önce görmüş olması, uzun süredir önemli bir sorun. Bir model test istemlerini eğitim, ince ayar veya önceki değerlendirmeler sırasında gördüyse, sonuçlar gerçek yeteneğini olduğundan daha iyi gösterebilir. MLCommons’a göre güvenilir benchmark’lar temiz veri, belgelenmiş veri kaynağı, dikkatli örnekleme ve sonuçların nasıl üretildiğini anlamaya yetecek şeffaflık gerektiriyor. 2024

Geleneksel yöntemler iki zor seçenek arasında kalıyordu:

• Test istemlerini geliştiriciye vermek: Uygulaması kolaydır; ancak gizli benchmark malzemesinin sızmasına, kaydedilmesine veya sonraki eğitim süreçlerini etkilemesine yol açabilir.
• Model ağırlıklarını değerlendiricilere vermek: Benchmark’ın gizliliğini koruyabilir; fakat öncü modeller için ağırlıklar değerli fikrî mülkiyet ve hassas bir yetenek olduğu için genellikle kabul edilemez.
• Gizli enclave kullanmak: Model ile benchmark, donanım tarafından korunan bir ortamda buluşur; taraflardan hiçbiri diğerinin gizli varlığını açık biçimde elde etmez.

Bu nedenle pilot, test verisinin ve modelin aynı anda korunmasını mümkün kılan makul bir altyapı yaklaşımı ortaya koyuyor. Fakat tek başına elde edilen güvenlik sonuçlarının eksiksiz veya bağımsız olarak kesinleşmiş olduğunu kanıtlamıyor.

Pilotun önemli sınırlamaları

Çalışma teknik açıdan dikkat çekici bir gösterim olsa da sonuçların nasıl yorumlanması gerektiğine dair önemli sınırlar var.

İlk olarak değerlendiriciler enclave’in bildirilen iş yükünü ve model arayüzünü doğrulayabildi; ancak Google’ın tescilli model ağırlıklarını veya çıkarım uygulamasını bağımsız biçimde inceleyemedi. Bu da çalışma zamanının her açıdan tam olarak amaçlandığı gibi davranıp davranmadığının denetlenmesini sınırlıyor. 13

İkinci olarak operasyonel ortam uçtan uca bağımsız şekilde yeniden üretilemedi. Kurulum ve bulut altyapısı, bağımsız bir kuruluş tarafından baştan oluşturulup yeniden çalıştırılmak yerine Google’ın kontrolünde kaldı. Doğrulama süreci de Google Cloud’un donanımına, firmware’ine, servis sistemlerine ve attestation altyapısına dayanıyordu. Donanım destekli doğrulama, yalnızca “kayıt tutmama” sözünden daha güçlü olsa da bu daha geniş tedarik zincirine duyulan güveni ortadan kaldırmıyor. 13

Üçüncü olarak pilot, gizli istemleri ve sayısal sonuçları yayımlamadı. İstemleri gizli tutmak onların gelecekteki test değerini koruyor; ancak aynı zamanda kamu denetimini, modeller arası karşılaştırmayı ve bulguların bağımsız doğrulanmasını zorlaştırıyor. AVERI çalışmayı tam kapsamlı bir kamu benchmark’ı değil, niteliksel ve küçük ölçekli niceliksel bir değerlendirme olarak nitelendiriyor. 1

Neden henüz sektör standardı değil?

Güvenli donanım, değerlendirme sorununun yalnızca bir bölümünü çözüyor. Çift kör testlerin kalıcı bir sektör uygulamasına dönüşmesi için çevresindeki yönetişim yapısının da gelişmesi gerekiyor.

Hukuki ve kurumsal güvenceler, özellikle tehlikeli yetenekleri inceleyen testlerde veri işleme, izin verilen çıktılar, açıklama kuralları, sorumluluk ve erişim konularını netleştirmeli.

Benchmark yönetimi, istemlerin kaynağını, örnekleme yöntemini, etiketlemeyi, belgeleri, yenileme süreçlerini ve kirlenme takibini kapsamalı. MLCommons, bir benchmark’ın yalnızca verileri gizli olduğu için değil; kuruluş ve bakım süreçleri savunulabilir olduğu için güvenilir sayılabileceğini vurguluyor. 2025

Bağımsız yeniden üretilebilirlik, model sağlayıcısı ve bulut işletmecisi dışındaki tarafların derleme sürecini, doğrulama zincirini, çalıştırma politikalarını ve bildirilen sonuçları anlamlı ölçüde denetleyebilmesini gerektirir.

Ölçeklenebilirlik de kritik. Kullanışlı bir standart; farklı geliştiriciler, model mimarileri, bulut ortamları, değerlendiriciler ve benchmark türleri arasında, ayrıca tekrarlanan model sürümlerinde çalışabilmeli. Tek bir donanım yığınına dayanan özel bir iş birliğiyle sınırlı kalmamalı.

Google DeepMind’ın Gemini pilotu, benchmark güvenine verilmiş nihai bir yanıt olmaktan çok, daha zor bir yapay zekâ değerlendirme biçimi için altyapı denemesi olarak görülmeli. Çalışma, gizli test verisini koruma ile tescilli modelleri koruma arasındaki gerilimi azaltmak için gizli bilgi işlemin nasıl kullanılabileceğini gösteriyor. Bunun sektör ölçeğinde güvenilir kanıta dönüşüp dönüşmeyeceği ise yalnızca enclave şifrelemesine değil; bağımsız denetime, sağlam benchmark yönetişimine, hukuki korumalara, tekrarlanabilirliğe ve operasyonel uygulanabilirliğe bağlı olacak. 1320