Pratikte makine öğrenimini (ML) gerçekten kullanmanın en zor yönlerinden biri, doğru miktarda dikkati veri sorununa yönlendirmektir. Bu, makine öğrenimi güvenliği, Yazılıma Güvenlik İnşa Etme ve Makine Öğreniminin Nasıl Güvenli Hale Getirileceği ile ilgili önceki iki Karanlık Okuma sütununda tartıştığım bir şey.
Görüyorsunuz, ML’deki “makine” gerçekten doğrudan bir grup veriden oluşturulmuştur.
Makine öğreniminde yer alan güvenlik riskiyle ilgili erken tahminlerim, veriyle ilgili risklerin genel riskin %60’ından sorumlu olduğu ve geri kalan risklerin (örneğin, algoritma veya çevrimiçi operasyon riskleri) kalan %40’tan sorumlu olduğu yönündeki güçlü iddiayı ortaya koyuyor. 2019’da makine öğrenimi güvenliği üzerinde çalışmaya başladığımda, çoğunlukla veriyle ilgili risklere yeterince dikkat edilmediği için bunu hem şaşırtıcı hem de endişe verici buldum. Ama biliyor musun? Bu tahmin bile bazı şeyleri yanlış yaptı.
Makine öğrenimi yaşam döngüsünün tamamını düşündüğünüzde, verilerle ilgili riskler daha da fazla önem kazanıyor. Bunun nedeni, salt veri maruziyeti açısından, çoğu zaman ML’yi uygulamaya koymanın, ilk etapta ML modelini eğitmekten veya sahaya yerleştirmekten daha fazla veri ortaya çıkarmasıdır. Çok daha fazlası. İşte neden.
Eğitime Dahil Edilen Veriler
Bir ML algoritmasını “eğittiğinizde” (örneğin, basit bir kategorizasyon veya tahmin görevi için denetimli öğrenmeyi kullanarak) kullandığınız veri kümeleri hakkında dikkatli düşünmeniz gerektiğini hatırlayın. Çoğu durumda, makine öğrenimini oluşturmak için kullanılan veriler, hem iş için gizli olan hem de güçlü bir gizlilik yükü taşıyan verileri depolayan bir veri ambarından gelir.
Bir örnek yardımcı olabilir. Bir kredi memurunun bir krediye devam edip etmemeye karar vermesine yardımcı olan bir bankacılık aplikasyonu uygulamasını düşünün. Eldeki ML sorunu, başvuranın krediyi geri ödeyip ödemeyeceğini tahmin etmektir. Kurum tarafından verilen geçmiş kredilerden alınan veriler kullanılarak, bu tahmini yapmak için bir ML sistemi eğitilebilir.
Bu örnekte, algoritmayı eğitmek için kullanılan veri ambarından alınan veriler, hem bazıları korunabilen (örneğin, maaş ve istihdam bilgileri, ırk ve cinsiyet gibi) tamamen özel bilgileri hem de ticari gizli bilgileri içerir. (örneğin, bir kredinin teklif edilip edilmediği ve hangi getiri oranında olduğu gibi).
Makine öğreniminin zorlu veri güvenliği yönü, bu verilerin güvenli, emniyetli ve yasal bir şekilde kullanılmasını içerir. Eğitim, test ve değerlendirme setlerini toplamak ve oluşturmak önemsiz değildir ve bazı riskler taşır. Veriler bir anlamda makine öğrenimi modeline “yerleşik” olduğundan (ve bu nedenle, bazen kasıtsız olarak geri sızmaya tabi olduğundan), eğitimli makine öğrenimi modelinin kendisinin sahaya alınması da bazı riskler taşır.
Örneğimizi doldurmak adına, varsaydığımız ML sisteminin veri ambarı içinde eğitildiğini, ancak bulutta çalıştırıldığını ve kurumun yüzlerce bölgesel ve yerel şubesi tarafından kullanılabileceğini varsayalım.
Açıkça verilere maruz kalma, konu makine öğrenimi olduğunda dikkatlice düşünülmesi gereken bir şeydir.
İşlemlerle İlgili Veriler
Ama bekleyin, dahası var. Tartıştığımız gibi bir ML sistemi sahaya sürüldüğünde, aşağıdaki gibi çalışır. Yeni durumlar, ilk etapta ML modelini oluşturmak için kullanılan aynı tür temsil kullanılarak toplanır ve “sorgular” içine yerleştirilir. Bu sorgular daha sonra, eldeki görevle ilgili bir tahmin veya kategorizasyon döndürmek için bunları girdi olarak kullanan modele sunulur. (Oto-ilişkisel tahmin derken ML insanları bunu kastetmektedir.)
Kredi örneğimize dönersek, bir şubedeki bir kredi memuru aracılığıyla bir kredi başvurusu geldiğinde, bu bilgilerin bir kısmı kredi karar verme sürecinin bir parçası olarak ML modeli üzerinden bir sorgu oluşturmak ve çalıştırmak için kullanılacaktır. Örneğimizde, bu sorgunun hem ticari gizli hem de düzenleyici denetime tabi korunan özel bilgileri içermesi muhtemeldir.
Kurum, kredi arayan yüzbinlerce (hatta belki milyonlarca) müşteriyi büyük olasılıkla ML sistemini iyi bir şekilde kullanacaktır. Şimdi, bileşik sorguların kendilerinin getirdiği veriye maruz kalma riskini düşünün. Bu çok büyük bir veri yığını. Bazı analistler, makine öğrenimi verilerine maruz kalmanın %95’inin bu tür operasyonel maruziyet yoluyla geldiğini tahmin ediyor. Gerçek arızadan bağımsız olarak, operasyonel verilere maruz kalmanın dikkatlice düşünülmesi gereken bir şey olduğu çok açıktır.
Veri Maruziyetini Sınırlama
Makine öğrenimi kullanımında yerleşik olarak bulunan bu operasyonel verilere maruz kalma riski uygun şekilde nasıl azaltılabilir?
Bunu yapmanın çeşitli yolları var. Sorgular ML sistemine giderken şifreleniyor, ardından yalnızca ML üzerinden çalıştırıldıklarında şifreleri çözülüyor olabilir. ML sisteminin nerede çalıştırıldığına ve kimin çalıştırdığına bağlı olarak bu işe yarayabilir. Örnek olarak, Google’ın BigQuery sistemi, bu tür şeyleri yapmak için müşteri tarafından yönetilen anahtarları destekler.
Başka, daha akıllı bir çözüm, sorgu alanlarının temsilini stokastik olarak dönüştürmek, böylece orijinal bilginin doğruluğunu etkilemeden ML’nin karar sürecine maruz kalmasını en aza indirmek olabilir. Bu, makine öğreniminin kararlarını nasıl verdiğine dair bazı bilgiler içerir, ancak çoğu durumda sorguları önemli ölçüde küçültmek için kullanılabilir (ilgili olmayan alanları körleştirir). Protopia AI, eğitim sırasında makine öğrenimi veri riskini ele alan diğer çözümlerle birlikte bu teknik yaklaşımı izliyor. (Tam açıklama, Protopia AI için Teknik Danışmanım.)
Özel çözümden bağımsız olarak ve beni şaşırtan bir şekilde, makine öğrenimindeki operasyonel verilere maruz kalma riski, “yerleşik” eğitim verileriyle bir model oluşturma riskinin çok ötesine geçer. ML güvenliği olgunlaştıkça operasyonel verilere maruz kalma riski bir şeydir ve yakından izlenmesi gereken bir şeydir.
