GitHub, secret scanning'deki yanlış pozitifleri azaltmak için bir LLM'i nasıl değerlendirdiğini anlattı

GitHub, LLM tabanlı bir sistemi umut verici bir prototipten production'a taşımanın mühendislik derslerini, secret scanning çalışmalarını vaka olarak kullanarak paylaştı. GitHub Blog'a göre temel uyarı şu: Bir dil modeli temiz bir benchmark üzerinde iyi performans gösterebilir, ama gerçek trafik geldiğinde önemli olan vakalarda zorlanabilir.

GitHub, benchmark'ların ve özenle hazırlanmış veri kümelerinin prototip aşamasında hâlâ yararlı olduğunu belirtiyor: ekiplere modelleri karşılaştırmada, ilk bir prompt'u test etmede ve bir fikrin makul olup olmadığını değerlendirmede yardımcı oluyorlar. Ancak bir sistem production'a yaklaştıkça değerlendirme sorunu değişiyor. Gerçek girdiler belirsizdir, etiketler tutarsız olabilir, bağlam eksik veya kesik olabilir, değerlendirme kümesi production dağılımıyla örtüşmeyebilir ve nadir kenar durumları yaygın hata kaynaklarına dönüşebilir. Çevrimdışı metriklerdeki iyileşmeler production'daki davranışın iyileşmesine dönüşmeyebilir.

GitHub'ın çözmeye çalıştığı sorun

Secret scanning, bir repository'ye commit edilmiş olabilecek token ve key gibi kimlik bilgilerini tespit ediyor. Bazı aday dizgiler gerçek kimlik bilgisi olmadıkları halde secret'e benzediği için geliştiriciler, düzeltme gerektirmeyen uyarıları inceleyerek zaman harcayabiliyor. Bu yüzden GitHub'ın sorusu, bir LLM'in bir dizgiyi soyut olarak doğru sınıflandırıp sınıflandıramayacağı değil; onun etrafında kurulmuş bir sistemin gürültülü uyarıları azaltıp azaltamayacağı ve aynı zamanda bir güvenlik iş akışında güvenli kalacak kadar yeterli recall'ı koruyup koruyamayacağıydı.

Modele değil, ürün kararından başlayın

Bir LLM sistemi beklenen performansı göstermediğinde içgüdü prompt'u yeniden yazmak, bağlam eklemek, başka bir akıl yürütme adışı yerleştirmek veya model değiştirmektir. GitHub, ekiplerin önce değerlendirmenin desteklemesi gereken kararı tanımlaması gerektiğini savunuyor: hangi hatalar kabul edilebilir, hangi metrikler ürün kararını belirliyor ve hangi güvenlik sınırları korunmalı.

Secret scanning için gerçek bir kimlik bilgisini yanlışlıkla bastırmak, bir geliştiriciden bir ekstra uyarıyı incelemesini istemekten daha ağır sonuçlar doğurduğu için precision ve recall birbirinin yerine kullanılabilir olarak görülmedi. GitHub kriterlerini üç seviyede düzenledi. Birincil sonuç, yanlış pozitiflerin azaltılması ve precision'dı. Recall bir güvenlik kısıtı olarak hizmet etti: bir deney, olası herhangi bir düşüş önceden tanımlanmış kabul edilebilir aralıkta kaldığı sürece ilerleyebiliyordu. Latency, maliyet, güvenilirlik ve production uyumluluğu ise bir sonucun dağıtımının pratik olup olmadığını belirleyen operasyonel güvenlik sınırları olarak işlev görüyordu.

Bu çerçeve, her metriğin birbiriyle ikame edilebilir olarak ele alınmasını engelliyor. GitHub bu noktayı varsayımsal deney sonuçlarıyla örnekliyor: recall güvenlik sınırının altına düşen büyük bir precision kazancı reddedilirken, sınır içinde kalan orta düzey bir kazanç testlere devam ediyor. Yazıdaki sayılar açıkça örnek niteliğinde, ama karar mantığı asıl içerik.

Çevrimdışı değerlendirmeyi integration testing gibi ele alın

Prompt'lar, modeller, girdi oluşturma ve çevresindeki mantık sürekli değiştiği için GitHub, çevrimdışı değerlendirmeyi tek seferlik bir kapı değil uçtan uca bir integration test olarak ele aldı. Anlamlı bir değişiklik yapıldığında değerlendirme yeniden çalıştırıldı ve her çalışma, prompt, model, veri kümesi sürümü ve sistem yapılandırması kaydedildi; böylece sonuçlar bilinen bir baseline ile karşılaştırılabiliyordu.

Bu disiplin belirli soruları yanıtlanabilir kılıyor: yeni bir prompt recall'ı düşürmeden precision'ı iyileştirdi mi, bir model yükseltmesi veri kümesi genelinde mi yardım etti yoksa yalnızca belirli kategorilerde mi, girdi oluşturmadaki bir değişiklik bir hata örüntüsünü düzeltirken başka birini mi ortaya çıkardı. Bu olmadan, GitHub'a göre ekipler farklı koşullar altında üretilmiş sonuçları karşılaştırıyor ve başarıyı yanlış değişikliğe atfediyor.

Tekrarlanabilirlik tek başına yeterli değil. GitHub aynı anda büyük bir değişkeni değiştirip birleştirmeden önce prompt revizyonunu model yükseltmesinden ayrı değerlendirdi; çünkü eşzamanlı değişiklikler bir iyileşmenin ya da gerilemenin nedenini belirsizleştiriyor. Prompt'lar ve değerlendirme yapılandırmaları kod gibi sürümlendi; önceki yapılandırmalar yeniden üretilebilir tutuldu ve rollback mümkün kaldı.

Model yükseltmelerini yeniden test etmeye devam edin

GitHub ayrıca zayıf sonuçlara prompt'a daha fazla talimat yığarak yanıt vermemek konusunda uyarıyor. Bazen karmaşıklık modele aittir: daha güçlü bir model, eski bir modelin yoğun ayarlama yapmasından daha basit bir prompt'la daha iyi performans gösterebilir ve daha basit prompt'lar anlaması, test etmesi ve sürdürmesi daha kolaydır. Yükseltmeler de yine dikkatli değerlendirme gerektirir; çünkü yeni bir model bir kategoriyi iyileştirirken başka yerlerde geriletebilir ve maliyeti, latency'yi, çıktı biçimlendirmesini ya da mevcut pipeline ile uyumluluğu değiştirebilir. GitHub'ın yazdığına göre değerlendirme süreci, düzenli olarak çalıştırılabilecek kadar ucuz ve tekrarlanabilir olmalı.

Neden önemli

LLM'ler hakkındaki kamuya açık tartışma büyük ölçüde benchmark puanlarına dayanıyor, ama production sistemleri dağınık girdilerle ayakta kalıyor ya da düşüyor. GitHub'ın yazısı, güvenlik açısından kritik bir iş akışında konuşlandırılmış bir LLM'in somut, adı geçen bir hesabı ve onun çerçevesi — birincil sonuç, bir güvenlik kısıtı ve operasyonel güvenlik sınırları, aynı anda tek bir değişken değiştirilerek tekrarlanabilir şekilde değerlendirilir — kod analizi, geliştirici araçları, veri analizi ve diğer alanlara taşınabilir. Güvenlikte yapay zekâ benimseyen ekipler için en keskin çıkarım şu: yanlış pozitif ile gözden kaçan gerçek bir kimlik bilgisi arasındaki maliyet asimetrisi metriklere ve eşiklere açıkça kodlanmalı, sezgiye bırakılmamalı; ayrıca değerlendirme bir kez aşılan bir engel değil, süregiden bir mühendislik disiplinidir.