"%93 Emin Olmak" Bir Olasılık Değil, Yalnızca Bir Metin Dizesidir

Kalibre edilmemiş model skorları, yazılım sistemlerinde otomatikleştirilmiş riskler yaratır.

Demo ve Üretim Hattı Arasındaki Boşluk#

Demo aşamasında modelden yanıtıyla birlikte bir güven skoru (confidence score) döndürmesini istersiniz. Model 0.93 değerini döndürür. Siz de kodunuza if confidence > 0.9: auto_approve() yazar ve geçersiniz.

Ancak üretim (production) ortamında bu sayı, modelin ürettiği sıradan bir metinden ibarettir. Gerçek sonuçlara karşı ölçülmemiştir. Olasılık gibi görünür, olasılık gibi biçimlendirilmiştir ve kodunuz ona bir olasılık gibi davranır. Sahte kesinliğin otomatikleştirilmiş riske dönüşmesi tam olarak böyle gerçekleşir.

Bir güven skorunun gerçekten "güven" kelimesini hak etmesi için kalibre edilmiş olması gerekir: Sistemin yaklaşık %90 emin olduğunu söylediği tüm vakaların kabaca %90'ı gerçekten doğru olmalıdır. Bunu kendi verilerinizle doğrulayana kadar o sayı sadece bir dekorasyondur.

Hata Modu 1: Hiç Test Edilmemiş Eşik Değeri (Threshold)#

Örnek bir senaryo: Bir geliştirici ekip, fatura sınıflandırma işlemini bir LLM üzerinden geçirir ve 0.9 üzerindeki her şeyi otomatik olarak onaylar. Değerlendirme veri setinde (eval set) genel doğruluk %94'tür ve her şey harika görünür.

Ancak ekibin hiç ölçmediği şey, >0.9 dilimi içindeki gerçek doğruluktur. Veriler dilimlenip incelendiğinde, yüksek güven diliminin düşük güven diliminden neredeyse hiç farkı olmadığı görülür; çünkü model neredeyse her çıktı için 0.9+ üretmektedir. Eşik değeri hiçbir şeyi filtrelememiş, sadece ondalık noktası olan bir otomatik onay damgası işlevi görmüştür.

Hata Modu 2: İki Sistemi Gizleyen Tek Bir Doğruluk Sayısı#

Sisteminiz kararları erteleyebiliyorsa (insana devretme, açıklama isteme veya kurallara geri dönme), tek bir sayıyı değil, bir ödünleşimi (trade-off) değerlendiriyorsunuz demektir:

• Kapsama (Coverage): Sistem ertelemek yerine ne sıklıkla doğrudan yanıt veriyor?
• Seçici Doğruluk (Selective Accuracy): Yanıt verdiğinde ne sıklıkla doğru çıkıyor?

Eşik değerini yukarı çektiğinizde kapsama düşerken seçici doğruluğun yükselmesi beklenir. Gerçekten yükselip yükselmediğini ölçmek için aşağıdaki minimal yaklaşımı kullanabilirsiniz:

import numpy as np

def coverage_accuracy_curve(conf, correct, thresholds):
    conf, correct = np.asarray(conf), np.asarray(correct)
    rows = []
    for t in thresholds:
        answered = conf >= t
        coverage = answered.mean()
        sel_acc = correct[answered].mean() if answered.any() else float("nan")
        rows.append((t, round(coverage, 3), round(sel_acc, 3)))
    return rows

def calibration_bins(conf, correct, n_bins=10):
    conf, correct = np.asarray(conf), np.asarray(correct)
    edges = np.linspace(0, 1, n_bins + 1)
    for lo, hi in zip(edges[:-1], edges[1:]):
        m = (conf >= lo) & (conf < hi)
        if m.any():
            print(f"[{lo:.1f}, {hi:.1f}) n={m.sum():4d} "
                  f"stated={conf[m].mean():.2f} actual={correct[m].mean():.2f}")

İlgilendiğiniz aralıklarda modelin iddia ettiği (stated) ve gerçekleşen (actual) değerler birbirinden uzaklaşıyorsa, eşik değeriniz size yalan söylüyor demektir.

Hata Modu 3: Küresel Eşik Değeri (Global Threshold)#

Kalibre edilmiş bir skor bile ortalamada doğru görünürken, kritik alt kırılımlarda tamamen yanlış olabilir.

Örneğin genel tabloda 0.9 dilimi %91 doğru sonuç verebilir. Ancak veriyi dile göre böldüğünüzde İngilizce kayıtlar %95 doğruluktayken, Yunanca ve Almanca kayıtlar çok daha düşük kalabilir. Girdi kalitesine göre böldüğünüzde temiz PDF'ler sorunsuzken, taranmış ve OCR işleminden geçmiş belgeler çökmüş olabilir. Tüm sistemde tek bir küresel eşik kullanmak, yakalamak için insan devri (deferral) mekanizması kurduğunuz hataları ortalamaya kurban eder.

Bu nedenle aynı eğriyi her bir veri dilimi (slice) için ayrı ayrı çalıştırmalısınız:

for slice_name, idx in slices.items():  # örn. görev tipi, dil, kaynak kalitesi
    print(slice_name, coverage_accuracy_curve(conf[idx], correct[idx], [0.7, 0.8, 0.9]))

Yazılım Geliştiriciler İçin Pratik Çıkarımlar#

• Ham LLM çıktılarına güvenmeyin: Modelin metin olarak ürettiği güven skorlarını doğrudan if/else bloklarında olasılık değeri gibi kullanmayın.
• Kalibrasyon testlerini pipeline'a ekleyin: İddia edilen skor ile gerçek başarı oranını (calibration_bins) kendi altın veri setinizde (Golden Dataset) doğrulayın.
• Veriyi alt kırılımlarda (slice) analiz edin: Dil, belge kalitesi veya görev tipi gibi kategoriler için ayrı eşik değerleri belirleyin.

Orijinal makaleye buradan ulaşabilirsiniz.