Kanıtın kapsamı

Bir tablodaki öğeleri sıralayan program için matematiksel kanıtın başlangıcı, tablonun neyi koruması gerektiğidir. WIRED’ın verdiği örnekte sıralamadan önce ve sonra aynı öğeler bulunmalı, yalnızca düzenleri değişmelidir. Biçimsel doğrulama, programın bu tür kesin davranış tanımlarına uyup uymadığını denetliyor. Yapay zekânın kanıt üretmeye yardım ettiği bir dünyada beni ilgilendiren ölçüm sorusu burada başlıyor: Denetleyicinin kabul ettiği önerme, kullanıcının önem verdiği davranışı ne kadar kapsıyor? Kanıtın kapsamını belirleyen, başlangıçta yazılmış bu koşullar.[1]

Stanford araştırmacısı Chuyue Sun’ın Ağustos ayında katıldığı &Truth, bu süreci otomatikleştirmek üzere kamuya açıldı. Sun’ın araştırması, Signal’daki konuşmaları şifreleyen kodun bir bölümünü ele alıyor. Bu sınır önemli: şifreleme kodunun belirli bölümünü doğrulamak, uygulamanın bütün davranışlarını kapsayan bir değerlendirmeye kendiliğinden dönüşmez. Haberde aktarılan hızlı tamamlanma, kanıt hazırlama işinin harcadığı çabayla ilgili bir bulgu. Güvencenin genişliği ise hangi kodun hangi koşullara göre denetlendiğine bağlı kalıyor. Çaba ile kapsam aynı sonucu ölçmüyor.[1]

Koşulu kim yazıyor?

Girişimlerin planı, programın nasıl davranması gerektiğini tanımlayan işlerin önemli bölümünü yapay zekâya yaptırmak. Başka otomatik adımlar da kodu Lean, Rocq ve Isabelle gibi matematik araçlarının denetleyebileceği biçime çevirebiliyor. Böylece iki ayrı soru beliriyor: Kod yazılı koşulu sağlıyor mu ve yazılı koşul amaçlanan işi doğru anlatıyor mu? Benim yorumum, ikinci sorunun otomasyonla birlikte daha görünür hâle gelmesi gerektiği. Denetleyicinin verdiği olumlu yanıtın anlamı, ona sunulan koşul içinde anlaşılabilir; koşulun atladığı davranışları kapsadığı varsayılamaz.[1]

Proofcraft’ın June Andronick ve Gerwin Klein üzerinden dile getirdiği kaygı tam bu noktada: yapay zekânın yazdığı tanımlar sonuçlara dayanaksız güven yaratabilir. Buradan çıkardığım olası mekanizma, tanımdaki eksikliğin başarılı bir kanıtla birlikte görünmez kalması. Bunun makul alternatifi, ekiplerin gerekli koşulları doğru yazması ve otomasyonun yalnızca zahmetli kanıt hazırlığını azaltmasıdır. Bu durumda hız kazancı gerçek bir yöntem katkısı olur. Hangi açıklamanın geçerli olduğunu anlamak için, kabul edilmiş kanıtla birlikte denetlenen davranış tanımını da görmek gerekir.[1]

Bulunan hatanın yeri

Uzmanların karşıt deneyimleri de hangi sorunun sorulduğuna bağlı olarak okunmalı. Amazon Web Services’ten Byron Cook, biçimsel doğrulamanın büyük hataları erken giderdiğini söylüyor. Apple’ın güvenlik ekibi corecrypto kitaplığında başka türlü bulunamayacak sorunlar yakaladığını belirtiyor. Antithesis yöneticisi Wilson ise şirketinin doğrulanmış savunmalarında kendi aracıyla ek hatalar bulduğunu aktarıyor. Bu anlatımlar, yararlı kanıt ile geride kalan hataların bir arada bulunabildiğini gösteriyor; hangi yaklaşımın her koşulda üstün olduğunu ölçen ortak bir deney sunmuyor.[1]

Bu nedenle incelemek isteyeceğim örnek, aynı kod parçasına ait davranış tanımı, kabul edilen kanıt ve sonradan bulunan hatayı birlikte göstermeli. Hata tanımın dışında kalan bir davranıştan mı, bilgisayarın çalışmasına ilişkin bir varsayımdan mı kaynaklanıyor? WIRED’ın aktardığı kullanıcı hatası ve donanım arızası kaygıları, bu ayrımın neden somutlaştırılması gerektiğini anlatıyor. Kanıtın hangi soruyu çözdüğünü anlaşılır kılıyor. Benim için otomatik doğrulamanın değerini değerlendirmek, bu sınırı kanıtın kendisi kadar okunabilir hâle getirmekle başlıyor.[1]