Bir büyük dil modeli temiz bir kıyaslamada güçlü sonuçlar elde ederken, üretim ortamında kullanıcılar için gerçekten önem taşıyan belirsiz durumlarda başarısız olabilir. GitHub’ın 25 Ağustos 2026 tarihinde Mariko Wakabayashi ve Zixiao Chen tarafından kaleme alınan materyalde sunduğu temel ders budur. Materyal, GitHub secret scanning kapsamında yanlış pozitifleri azaltmaya yardımcı olan, büyük dil modeline dayalı bir sistemi değerlendirme deneyimine dayanmaktadır.
Sır taraması, yazılım deposuna eklenmiş olabilecek belirteçler ve anahtarlar gibi kimlik bilgilerini arar. Ancak bazı dizeler gerçek kimlik bilgileri olmadan da sırlara benzeyebilir ve bu durum geliştiricilerin işlem gerektirmeyen uyarıları incelemesine yol açar. Bu nedenle ekip için soru, modelin tek bir dizeyi sınıflandırıp sınıflandıramadığı değil; güvenliğe duyarlı bir iş akışını güvenli kılacak yeterli geri çağırma düzeyini korurken gürültüyü azaltıp azaltamayacağıydı.
Modeli seçerek değil, ürün kararıyla başlayın
GitHub, istemi değiştirmeden, bağlam eklemeden veya modeli değiştirmeden önce değerlendirmenin desteklemesi gereken kararı tanımlamayı öneriyor. Sır taraması durumunda hedef, yanlış pozitifleri azaltmak ve kesinliği artırmaktı; geri çağırma ise güvenlik kısıtı olarak kullanıldı. Gerçek bir kimlik bilgisini yanlışlıkla gizlemek, bir geliştiriciden ek bir uyarıyı incelemesini istemekten daha tehlikeli olabilir.
Uygulamada değerlendirme ölçütleri üç katmana ayrıldı: yanlış pozitifleri azaltmayı ve kesinliği ölçen, kullanıcı yararını değerlendiren temel sonuç; geri çağırmadan oluşan güvenlik kısıtı; ayrıca yanıt süresi, maliyet, güvenilirlik ve üretim ortamıyla uyumluluğu kapsayan operasyonel sınırlar. Böylece kesinlikteki iyileşme, geri çağırmada kabul edilemez bir düşüşe yol açıyor veya sistemi yavaş, pahalı ya da entegrasyonu zor hâle getiriyorsa otomatik olarak başarı sayılmıyor.
Değerlendirmeyi tekrarlanabilir bir entegrasyon testi hâline getirin
Değerlendirme, kullanıma sunulmadan önce gerçekleştirilen tek bir adım değildir. İstemler, modeller, girdilerin oluşturulma biçimi ve bunları çevreleyen sistem mantığı sürekli değişir; herhangi bir değişiklik iyileşmeye, gerilemeye veya hata örüntüsünün başka bir yere taşınmasına neden olabilir. Bu nedenle GitHub, her önemli değişiklikten sonra değerlendirmeyi yeniden çalıştırdı ve her seferinde istemin, modelin, veri kümesinin ve sistem ayarlarının sürümünü kaydetti.
Ekip ayrıca her deneyde tek bir temel değişkeni izole etti; model yükseltmesini onunla test etmeden önce istem değişikliğini bilinen bir temel karşılaştırdı. İstemler ve değerlendirme ayarları kod gibi ele alındı: sürümlendi, değişiklikler belgelendi ve önceki ayarların yeniden çalıştırılabilmesi ve geri alınabilmesi sağlandı. Bu uygulama, iyileşmenin veya gerilemenin nedenini bilmek ve bunu yanlışlıkla son değişikliğe atfetmemek için imkân sağlar.
Üretim görevini taklit edin ve yalnızca temiz verilere güvenmeyin
Çevrim dışı değerlendirme sonuçları, gerçek göreve benzediğinde daha yararlı olur. Sır taramasında model mutlaka yalıtılmış bir değere bakmaz; çevresindeki kod ve eksik veya dağınık olabilen destekleyici bilgilerle birlikte bir aday üzerinde çalışır. İstenen adayı değerlendirmek yerine, kod içindeki deneme amaçlı bir belirteç gibi güvenlikle daha ilişkili görünen başka bir değere odaklanabilir.
Bu nedenle üretim görevinin özellikleri korunmalıdır. Bunlar; değerlendirilen aday, çevresindeki bağlam, destekleyici bilgiler, girdilerin biçimlendirilme ve kısıtların uygulanma biçimi ile daha geniş sistem mantığını içerir. Değerlendirme gerçeğe kıyasla daha açık örnekler ve daha eksiksiz bağlam kullanıyorsa, sonuç sistemin dağıtım sırasında karşılaşacağı durumdan daha kolay bir sorunu yansıtabilir.
Etiketleri ve verileri incelenebilir kanıtlar olarak ele alın
Üründe belirli bir eylemin sonucu, güvenilir bir temel gerçekliği temsil ettiği anlamına gelmez. Sır taramasında bir uyarının kapatılması, kimlik bilgisinin döndürülmüş, riskin kabul edilmiş veya bir iş akışı başlatmak amacıyla uyarının kapatılmış olduğu anlamına gelebilir; ayrıca uyarı yanlış sınıflandırılmış da olabilir. Bu durumlar iş akışı verilerinde birbirine benzer görünür, ancak değerlendirmede aynı soruya yanıt vermez.
Üretim verilerini kullanmadan önce etiketin nasıl oluşturulduğu, değerlendirme sorusuyla eşleşip eşleşmediği ve farklı sonuçların tek bir kategoride birleştirilip birleştirilmediği bilinmelidir. GitHub, her etiketin doğru olduğunu varsaymak yerine önemli veya belirsiz kategoriler için insan incelemesi öneriyor. Sentetik veriler ve açık kıyaslamalar, özellikle eksik bağlam, alışılmadık biçimlendirme ve kimlik bilgilerine benzeyen yakın değerler gibi nadir durumlarda kapsam boşluklarını kapatabilir; ancak üretime yakın verileri tamamlamalı, onların yerini almamalıdır.
Hataları analiz edin ve değerlendirici modeli dikkatle kullanın
Toplam metrikler ekibe sistemin iyileşip iyileşmediğini söyler, ancak bir sonraki adımda neyin değiştirilmesi gerektiğini açıklamaz. Bu nedenle GitHub, yanlış pozitif ve yanlış negatif örneklerini inceledi ve bunların olası nedenlerini model, istem, girdiler, işlem hattı, veri kümesi veya etiketler kapsamında sınıflandırdı. Bu sınıflandırma genel bir kalite sorununu belirli bir mühendislik görevine dönüştürür: daha iyi girdi çerçevelemesi, farklı bağlam oluşturma, veri temizliği veya daha açık bir ürün politikası.
İnsan incelemesinin yükünü azaltmak için başka bir büyük dil modeli değerlendirici olarak kullanılabilir; açık durumları işleyebilir ve belirsiz durumları sıralayabilir. Ancak çıktıları referans gerçek değildir; hata yapabilir veya değerlendirilen modelle yanlış nedenle aynı sonuca varabilir. Daha güvenli yaklaşım, düşük güvenli, çelişkili veya etkisi yüksek durumları insanlara yönlendirmek; değerlendiricinin yüksek güvenle sınıflandırdığı durumlardan düzenli olarak örnekler almak; ayrıca değerlendirici ile sistem ve incelemeciler arasındaki farklılıkları izlemek, istemini sürümlemek ve değerlendirmektir.
Deney gerçekte neyi kanıtladı?
GitHub, değerlendirilen çevrim dışı veri kümesinde yanlış pozitiflerde %95 azalma sağladığını ve geri çağırmayı belirlenen güvenlik kısıtı içinde tuttuğunu bildirdi. Ancak şirket bu sonucu, sistemin her üretim senaryosunda aynı şekilde davranacağının kanıtı olarak sunmadı. En önemli değer, sonuca nasıl ulaşıldığını anlamaktı: gerçek göreve daha yakın bir değerlendirme, yeniden üretilebilir temel çizgiler ve belgelenmiş hata örüntüleri.
certi.news’in editoryal değerlendirmesi: Buradaki asıl değişiklik yeni bir model sunmak değil, LLM sistemlerinin değerlendirilmesini açık bir karar, güvenlik sınırları ve operasyonel kısıtlarla bağlantılı sürekli bir mühendislik sürecine dönüştürmektir. Bu, yazılım, güvenlik ve geliştirici araçları ekipleri için önemlidir; çünkü tek bir metriğin iyileştirilmesi, geri çağırmada tehlikeli bir düşüşü veya maliyette artışı gizleyebilir. Buna karşılık sonuç, değerlendirme kümesiyle, etiketlerin kalitesiyle ve çevrim dışı test ile üretim davranışı arasındaki ortadan kaldırılamayan farkla sınırlı kalır. Bu nedenle değerlendirmeler, kontrollü bir üretim denemesine geçiş için temel oluşturur; kullanıma sunulduktan sonra riskleri izlemeye alternatif değildir.