35 Üretimde Değerlendirme

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 35. bölüm. Kitabın henüz sormadığı bir soruyu cevaplamak üzere tasarlanmış tek bir ölçüm: hiçbir şey değişmediğinde bir değerlendirme puanı ne kadar oynuyor? 100 maddelik Türkçe bir bilgi çıkarma süiti kullanıldı; maddeler şablondan üretildiği için doğru cevaplar baştan biliniyor. Süit üç prompt (istem) altında beşer kez koşuldu: yayındaki prompt, bir kuralı silinmiş sürümü ve kuralları yalnızca yeniden sıralanmış sürümü. Bölüm 22 bir değerlendirme kümesini boyutlandırdı. Bu bölüm o kümeyi okuyan değerlendirme kapısının (evaluation gate: puanı eşiğin altında kalan değişikliğin birleştirilmesini engelleyen kontrol) gürültü tabanını (noise floor: hiçbir şey değişmediğinde puanın oynama payı) ölçüyor. Yazılım: ollama 0.24.0, qwen2.5:7b servis ediyor; Python 3.14.5, Apple Silicon.

Öğrenme hedefleri. Bu bölümün sonunda:

bir değişikliği çevrimdışı değerlendirmeden A/B testine uzanan merdivene yerleştirebilir ve her basamağın neyi yakalayıp neyi yakalayamadığını söyleyebilirsiniz;
kapınızın raporladığı hiçbir puana güvenmeden önce kendi gürültü tabanınızı ölçebilirsiniz;
gerilemeleri engelleyip gürültüyü engellemeyen bir kapı eşiği tasarlayabilirsiniz;
kozmetik görünen bir prompt düzenlemesinin kozmetik bir değişiklik olmayabileceğini fark edebilirsiniz;
gerçek trafikten bir altın küme (golden set: doğru cevapları doğrulanmış değerlendirme örnekleri) derleyebilir ve onun ne zaman bayatladığını anlayabilirsiniz;
canlı trafiğin tamamını puanlamadan bir örneklemini puanlayabilirsiniz;
kullanıcı geri bildirimini olduğu gibi, yani yanlı bir örneklem olarak ele alabilir ve bir A/B testinin örneklem büyüklüğünü test başlamadan önce hesaplayabilirsiniz;
bir panoda aynı görünen üç kayma türünü birbirinden ayırt edebilirsiniz.

35.1 Merdiven ve her basamağın yakalayabildiği

Şimdiye kadar sistemleri hep kapalı bir odada, dış dünyadan yalıtılmış hâlde değerlendirdik. Üretim, tüm tasarımı değiştiren bir kısıt ekliyor: değerlendirdiğiniz şey, siz onu değerlendirirken zaten kullanıcılara hizmet ediyor. Bu da değerlendirmeyi tek seferlik bir olay olmaktan çıkarıp bir merdivene çeviriyor. Aşağıdaki tablo basamakları en ucuzdan en pahalıya doğru sıralıyor ve her basamak kendisinden sonrakinden daha azını görüyor.

Beş basamak, bir değişikliğin tırmanması gereken sırayla
basamak	neye mal olur	neyi yakalar	neyi göremez
Çevrimdışı değerlendirme	saniyeler, kullanıcı yok	aklınıza gelen vakalarda gerilemeleri	süitinizin içermediği her şeyi
CI kapısı	tek bir CI koşusu	birleştirmeden önce kötü bir değişikliği	değişikliğin gerçek kullanıcılara yarayıp yaramadığını
Gölge	çift çıkarım, kullanıcıya etki yok	canlı girdilerde çökmeleri, gecikmeyi, bozuk çıktıyı	kullanıcılar üzerindeki etkiyi — çıktı kimseye servis edilmiyor, dolayısıyla davranış, memnuniyet ya da sonraki eylem hakkında hiçbir şey gözlenemiyor
Kanarya	gerçek kullanıcıların bir dilimi	bir arıza henüz yalnızca birkaç kullanıcıya ulaşırken kalite arızalarını (Bölüm 33)	küçük etkileri — dilim onları çözecek kadar büyük değil
A/B testi	günler ve gerçek maruziyet	değişikliğin gerçekten işe yarayıp yaramadığını	hızlı ilerleyen gerilemeleri — koruma metrikleri ve bir durdurma kuralı eklemediyseniz (eklemelisiniz); başlattığınız bir A/B testini sonuna kadar sürdürmek zorunda değilsiniz

Basamak adlarından dördü mühendislik jargonu. CI (continuous integration, sürekli entegrasyon), koda önerilen her değişiklik ana sürüme birleştirilmeden (merge) önce kendiliğinden koşan kontrollerin bütünüdür; CI kapısı da bu birleştirmeyi reddedebilen bir kontroldür. Gölge dağıtımda yeni sürüm canlı isteklerin bir kopyasını alır, ama cevapları yalnızca saklanır, hiçbir kullanıcıya gösterilmez. Kanarya yeni sürümü önce gerçek kullanıcıların küçük bir payına sunar; böylece bir arıza erkenden görülür ve geri alınır (ikisini de Bölüm 33.9 anlatıyor). A/B testi kullanıcıları eski sürüm (A) ile yenisi (B) arasında rastgele böler ve sonuçları karşılaştırır; Bölüm 35.7 bir A/B testinin örneklem büyüklüğünü hesaplıyor.

Hata bir basamağı atlamak değil. Bir basamağa, göremeyeceği bir şey hakkında inanmak. Temiz koşan bir gölge dağıtımı size yeni prompt’un çökmediğini söyler; tek başına cevapların daha kötü olup olmadığı hakkında bir şey söylemez, çünkü kimse bir tanesine bakmadı. Cevaplara kimsenin bakmamış olması ise yöntemin sınırı değil, bir tercih: gölge çıktıları saklanır ve sonradan bir referansa karşı, doğrulanmış bir hakemle ya da bir örneklemi okuyarak puanlanabilir. Gölgenin asla veremeyeceği şey, kullanıcıların bu cevaplara nasıl tepki vereceğidir. Yeşil bir CI kapısı da size değişikliğin süitinizdeki vakaları geriletmediğini söyler; bu, kullanıcılarınız hakkında değil, süitiniz hakkında bir iddiadır.

Bu bölüm çoğunlukla ikinci basamakla ilgili, çünkü takımların belirli ve ölçülebilir bir biçimde yanlış yaptığı basamak o.

35.2 Bir prompt değişikliği bir kod değişikliğidir

Prompt, bir LLM sisteminde küçük bir değişiklikle en büyük etkiyi yaratan ama en az incelenen parçadır. Bir metin dosyasıdır; davranışı çoğu kod yeniden düzenlemesinden (refactoring) daha fazla değiştirir; ve genellikle bir dalda (branch) düzenlenir, incelemede üstünkörü okunur ve “bence sorun yok” onayıyla birleştirilir.

Bunu düzelten disiplin, yazılım testinden olduğu gibi ödünç alınmıştır:

Süit depoda (repository) durur, sınadığı prompt’un yanında ve onunla birlikte taşınır.
Kapı prompt’taki her değişiklikte koşar; belirli bir takvime göre ya da biri hatırladığında değil.
Kapı birleştirmeyi engeller, yoksa o bir kapı değil bir panodur ve panolar hiçbir şeyi durdurmaz.
Bir üretim arızası, düzeltme birleştirilmeden önce süitte bir vakaya dönüşür — ve bu vakanın düzeltmeden önce başarısız olduğu, sonra geçtiği doğrulanır; bu, Bölüm 30’un regresyon disiplininin prompt’lara uygulanmış hâlidir.

Bunların tamamı yazılım mühendisliğinden alınmış standart pratik ve hiçbiri zor kısım değil. Zor kısım şu: bir değerlendirme puanı rastgele bir değişkendir, bir birim testi değildir. assert add(2, 2) == 4 her seferinde aynı cevabı döndürür. Bir süit puanı ise her koşuda aynı çıkmaz ve öyleymiş gibi kurulmuş bir kapı ya değişiklikleri rastgele engeller ya da gerilemeleri geçirir. Hangisini alacağınız, neredeyse hiç kimsenin ölçmediği bir sayıya bağlı: hiçbir şey değişmediğinde puan ne kadar oynuyor?

35.3 Kapının gerçekte görebildiği

Öyleyse ölçün. Süit, boşlukları (slot) rastgele doldurulan beş şablondan üretilmiş 100 Türkçe müşteri mesajı — sipariş kodu, gün, ay, şehir, tutar. Doğru cevaplar elle etiketlenmedi; mesajları üretme biçimimiz gereği baştan biliniyor. Dolayısıyla tartışılacak bir etiketleme hatası yok. Görev, mesajdan JSON’a bilgi çıkarma: mesaj başına beş alan, koşu başına 500 alan kararı. Puanlama alan başına tam dizgi eşleşmesiyle yapılıyor; alan doğruluğu (field accuracy) bu 500 kararın doğru olan yüzdesi. Buna ek olarak madde başına daha katı bir ölçü var: beş alanın beşi de doğruysa madde tam eşleşme (exact match) sayılıyor.

Üç prompt, hepsi aynı beş alanı çıkarıyor:

A — yayına alınan. Altı kural: biri çıktı biçimi üzerine, sonra alanların listelendiği sırada her alan için bir tane.
B — bir kural silinmiş. city kuralı çıkarılmış olarak A ile aynı. Bu, bir inceleyicinin onaylayıp geçtiği türden bir gerileme; burada, ölçümün bir şey saptayabildiğini gösteren bir kontrol olarak yer alıyor.
C — aynı kurallar yeniden sıralanmış. A ile bayt bayt aynı altı kural, ters sırada listelenmiş. Eklenen kural yok, çıkarılan yok, sözcük değişikliği yok. İncelemede hiç yorum almadan onaylanan türden bir düzenleme bu.

Süit, her prompt’la 0,7 sıcaklıkta beşer kez koşuldu; A ile ayrıca 0 sıcaklıkta iki koşu yapıldı.

35.3.1 Gürültü tabanı yaygın kanının iddia ettiğinden küçük

Prompt A, aynı modele karşı aynı süitin beş özdeş koşusu. Bu bölümdeki çıktılar programın yazdığı gibi İngilizce ve ondalık ayırıcısı nokta: field accuracy alan doğruluğu, exact match tam eşleşme, sd koşular arası standart sapma, delta iki prompt arasındaki fark.

prompt A, temp 0.7, five runs
  field accuracy   95.4  95.4  95.6  95.8  96.0     mean 95.64   sd 0.26
  exact match      80    81    81    82    82       mean 81.20   sd 0.84

Özdeş koşular arasındaki en büyük fark, alan doğruluğunda 0,60 puan. Bu, gürültü tabanının bir kestirimi; bir üst sınır değil. Beş çekilişin aralığı altıncısı için tavan değildir. Bu sd değerinde iki yeni koşu arasındaki fark, denemelerin yaklaşık %10’unda 0,60 puanı aşıyor; elli koşuda — bir CI kapısının birkaç ayda biriktirdiği sayı — beklenen en geniş açıklık 0,60 değil 1,17 puan. Beş koşu, standart sapmayı kestirmeye de zar zor yetiyor: dört serbestlik dereceli \(\chi^2\) dağılımından \(\sigma\) için elde edilen %95 güven aralığı 0,16’dan 0,75’e uzanıyor; üst ucu alt ucunun 4,8 katı.

Yani aralığı değil sd = 0,26’yı yazın, çünkü ölçeklenen nicelik sd. Taban yine de küçük. Değerlendirme kapılarına yöneltilen alışıldık itiraz, LLM puanlarının kapı kurmak için fazla gürültülü olduğudur; bu büyüklükte bir süit ve bu türden bir görev için bu itiraz düpedüz yanlış. Gürültüyü varsaymak yerine ölçmek gerekir, çünkü yanılgı iki yöne de işler: yaygın kanı burada gürültüyü abartıyor, döngüde bir hakemin bulunduğu daha zor bir görevde ise hafife alabilir (Bölüm 22’de küçük bir hakem, adayların sırası değiştirildiğinde maddelerin %38’inde hükmünü değiştirdi).

35.3.2 Silinen kural apaçık görünür

city kuralı eksik olan prompt B’nin A’yla karşılaştırması:

                    A       B      delta
  field accuracy   95.64   79.80   -15.84 pt   = 26x the noise floor
  exact match      81.20   21.40   -59.80 pt   = 30x the noise floor

  per field (of 100)      A      B
    order_id             100    100
    day                   91     86
    month                 99     98
    city                 100     29     <-- the deleted rule
    amount                88     86

Burada hiçbir incelik yok ve dâhil edilmesinin amacı da bu: bir kuralı kaldıran bir değişiklik gürültü tabanının 26 katı bir fark yaratıyor ve bunu her kapı yakalar. (Buradaki ve bölümdeki her “kat”, beş koşunun 0,60 puanlık aralığına göredir; koşular arası sd’ye göre bu fark yaklaşık 60 kat.) Gerilemenin tek türü bu olsaydı kapı tasarımı ilginç olmazdı.

35.3.3 Kozmetik düzenleme kozmetik değil

Prompt C aynı altı kuralı yeniden sıralıyor ve başka hiçbir şeyi değiştirmiyor.

                    A       C      delta
  field accuracy   95.64   92.24   -3.40 pt   = 5.7x the noise floor
  exact match      81.20   72.00   -9.20 pt   = 4.6x the noise floor

  per field (of 100)      A      C
    order_id             100    100
    day                   91     74     <-- the entire regression
    month                 99     99
    city                 100     99
    amount                88     89

Başka hiçbir yerine dokunulmamış altı kuralı yeniden sıralamak, alan doğruluğunda 3,4 puana ve tam eşleşmede 9,2 puana mal oldu; kaybın neredeyse tamamı da tek bir alanda toplandı. Bu değişikliğin kolayca onaylanıp geçmesinin sebebi, farkın (diff) hiç yeni metin içermemesi: her satır zaten vardı, yalnızca sıraları değişti. Bir inceleyicinin tepki verebileceği hiçbir içeriğin olmadığı tek değişiklik türü bu. Kurallar aynı kurallar.

O iki sayıdan hangisi istatistiksel bir testten sağ çıkıyor, hangisi çıkmıyor? İki prompt altında da aynı 100 madde koşuldu, yani karşılaştırma eşleştirilmiş (paired: aynı maddenin iki prompt altındaki sonuçları yan yana konuyor). Her prompt’un madde bazlı sonuçları elde; saklanmayan, bir maddenin A altındaki sonucunu aynı maddenin C altındaki sonucuna bağlayan eşleştirme. Ama marjinal toplamlar (her prompt’un kendi doğru sayısı: 91 ve 74) cevabı sınırlıyor. Uyumsuz madde, iki prompt’un anlaşamadığı maddedir: birinde doğru, ötekinde yanlış. day alanında A’da 91 doğruya karşı C’de 74, tek yönde net 17 uyumsuz karar bırakıyor. Bu marjinal toplamlarla tutarlı her dağılımda McNemar’ın kesin testi (Bölüm 22’nin yalnızca uyumsuz maddelere bakan eşleştirilmiş testi) 1,5 × 10⁻⁵ ile 0,006 arasında bir p değeri veriyor. Yani o gerileme, eşleştirme nasıl olursa olsun gerçek. Tam eşleşme farkı ise o kadar iyi durmuyor: 81’e karşı 72, net 9 uyumsuz karar bırakıyor ve aynı tarama 0,004 ile 0,24 arasında herhangi bir p değeri veriyor. Kimsenin kaydetmediği eşleştirmeye bağlı olarak bu fark anlamlı da çıkabilir, hiçbir şey ifade etmeyebilir de. Madde bazında sonuçları saklayın; bunun hiçbir maliyeti yok ve bir iddiayla bir anekdot arasındaki fark bu.

“Prompt mühendisliği”nin mühendislik diye anılmaya direnmesinin nedeni bu: prompt’un bir arayüzü yok, dolayısıyla hiçbir düzenlemenin yerel kaldığı kanıtlanamıyor. Sıralama davranışı belirliyor, ama gözle görülmüyor.

Arıza kipi adlandırılacak kadar belirli. Ayrı bir incelemede 40 madde iki prompt altında da koşuldu ve yanlış çıkan her day değerine tek tek bakıldı (want beklenen gün, got modelin verdiği gün, amount aynı mesajdaki tutar):

  prompt A:  day wrong on  4/40 — 4 of 4  are the leading digits of the amount
  prompt C:  day wrong on 13/40 — 13 of 13 are the leading digits of the amount

    want day 18   got  6   amount   6.842,50
    want day 12   got  1   amount   1.289,50
    want day 26   got  5   amount   5.669,99
    want day  8   got 29   amount     290,50

Bu incelemede, iki prompt altında da, yanlış olan her day değeri tutarın baştaki rakamlarıydı. Model bir alanı bir diğerine sızdırıyor ve amount kuralını day kuralının üstüne taşımak bunun sıklığını kabaca üçe katlıyor. Hata baştan beri oradaydı — prompt A’da maddelerin %10’unda — ve yeniden sıralama onu büyüttü.

Bu, “yeniden sıralamak risklidir”den çok daha yararlı bir bulgu. Gerilemenin bir mekanizması olduğunu, mekanizmanın alan bazlı dökümde görünür olduğunu ve yalnızca toplu bir puan raporlayan bir süitin, önemli olup olmadığını anlamanın hiçbir yolu olmadan 3,4 puanlık bir salınım göstereceğini söylüyor. Alan bazlı ya da kategori bazlı sayılar raporlayın, yoksa toplam puana bakarak harekete geçemezsiniz.

35.3.4 Sıcaklık 0 yeniden üretilebilirlik sağlar, doğruluk değil

Prompt A, 0 sıcaklıkta iki kez:

  field accuracy   95.20   95.20      per-item results byte-identical
  exact match      80      80

Kusursuz biçimde yeniden üretilebilir: yalnızca aynı puan değil, 100 maddenin her birinde aynı sonuç. Bu bir kapı için değerli, çünkü koşudan koşuya oynamayı ortadan kaldırıyor ve başarısız bir koşuyu bir dizüstü bilgisayarda yeniden üretilebilir kılıyor.

İki çekince var. Sıcaklık 0, 95,20 aldı ve bu, 0,7 sıcaklığın 95,40–96,00 aralığının tamamının altında oturuyor — greedy (açgözlü) kod çözme (decoding) olası çıktılardan yalnızca birini verir, en iyisini değil. Ve hiçbir şeyi düzeltmiyor: baştaki rakam hatası greedy kod çözmede de sürdü. day alanı 100’de 90 doğru çıktı ve 10 ıskalamanın 8’i aynı tutar sızıntısıydı. Belirlenimcilik bir kapıyı yeniden üretilebilir kılar; doğru kılmaz. Kullanıcılarınıza da muhtemelen 0 sıcaklıkta hizmet edilmiyor, dolayısıyla 0 sıcaklıklı bir kapı yayına almadığınız bir yapılandırmayı ölçüyor.

İki sınır daha, “gürültü yok” ifadesinin “her fark gerçektir” anlamına gelmesini engelliyor. Birincisi, bayt bayt aynı sonuç bu düzeneğin bir özelliği: tek bir yerel sunucu, istekleri tek tek cevaplıyor. Barındırılan API’ler ve birçok isteği toplu işleyen sunucular 0 sıcaklıkta bile çoğu zaman biraz farklı metin döndürür; bunu kendi düzeneğinizde deneyin, Bölüm 18 de bunu öneriyor. İkincisi, anlamı hiç değiştirmeyen bir düzenleme bile greedy çıktıyı birkaç maddede değiştirir. Dolayısıyla farklı iki prompt’un 0 sıcaklıktaki koşuları arasındaki küçük bir fark yine de rastlantı olabilir ve yukarıdaki eşleştirilmiş teste yine ihtiyaç duyar.

35.4 Kapıyı doğru durumlarda tetiklenecek biçimde tasarlamak

Bir gürültü tabanı verildiğinde kapı bir eşik kararıdır. Akla ilk gelen eşik yanlıştır ve neden yanlış olduğu öğreticidir. Bir eşiğin nasıl davrandığını görmek için her prompt’un ölçülen madde bazlı sonuçları, aşağıdaki tabloların her hücresi için 2.000 kez yeniden örneklendi. Her çekiliş, gerçek bir kapının yaptığı gibi bir baseline (referans alınan taban koşu) ile yeni bir koşuyu karşılaştırıyor; tablolar kapının ne sıklıkla tetiklendiğini gösteriyor. Kaynağa dair bir çekince: varyantlar arasındaki madde bazında eşleştirme saklanmadı (yukarıya bakın), dolayısıyla bu yeniden örnekleme A ile C arasında madde madde eşleştirilmiş olamaz. Aşağıdaki oranları eşleştirilmiş bir kapının ölçülmüş işletim karakteristikleri olarak değil, bir eşiğin nasıl davrandığının örneği olarak okuyun.

Yeni puan ne zaman düşükse engelleyen bir kapı
süit boyutu	naif kapı: A’ya karşı A (yanlış engelleme)	A’ya karşı B (yakalandı)	A’ya karşı C (yakalandı)
20	%22,9	%100	%93,0
50	%35,6	%100	%99,6
100	%42,5	%100	%100

Naif kapı — yeni koşu baseline’dan düşük puan alırsa engelle — gerilemelerin neredeyse hepsini yakalıyor ve hiçbir şeyi değiştirmemiş değişikliklerin %42,5’ini engelliyor. Daha kötüsü, süit büyüdükçe kötüleşiyor: 20 maddede iki koşu sıklıkla tam olarak berabere kalıyor ve beraberlikler geçiyor; 100 maddede tam beraberlikler seyrek, dolayısıyla karşılaştırma yazı tura atmaya yakınsıyor. Kararsız (flaky) bir kapıya daha fazla test vakası ekleyerek karşılık veren bir takım onu daha da kararsız yapıyor.

Bu yeniden örnekleme deneyinde bir puanlık bir eşik, yanlış engelleme oranını düşürdü:

Yalnızca yeni puan bir puandan fazla düşükse engelle
süit boyutu	1 puanlık eşik: A’ya karşı A (yanlış engelleme)	A’ya karşı B (yakalandı)	A’ya karşı C (yakalandı)
20	%20,5	%100	%90,8
50	%6,6	%100	%96,2
100	%4,3	%100	%99,4

100 maddede kapı, hiçbir şey yapmayan değişikliklerin %4,3’ünü engelliyor ve yeniden sıralanmış prompt’u hâlâ yeniden örneklemelerin %99,4’ünde yakalıyor. Artık süit boyutu, olması gerektiği gibi, yardım ediyor. Genelleşen kural:

Gürültü tabanına karşı sinyal, alan doğruluğu

İlginç olan vaka silinen kural değil, yeniden sıralanmış prompt. Farkta (diff) yeni satır yok; yalnızca mevcut satırların sırası değişti. Buna rağmen gerileme beş koşuluk aralığın neredeyse altı katı ve tümüyle tek bir alanın içinde.

Eşiği ölçtüğünüz gürültü tabanından, pay bırakarak belirleyin. Süitinizi değişmemiş bir sisteme karşı beş kez koşun ve koşular arası sd’yi kaydedin — aralığı değil; aralık, gelecekteki koşuların aşacağı beş çekilişlik bir kestirim. Gözlenen aralığın hemen üstüne konan bir eşik pek işe yaramıyor: bu sd’de iki yeni koşu arasındaki fark onda bir olasılıkla 0,60 puanı geçiyor. Pratikte işe yarayan kural kabaca 4 × sd ve burada bu, yukarıda kullanılan 1,0 puanlık eşik.

Pay bu kadar geniş, çünkü sd’nin kendisi de belirsiz. Beş koşuluk sd kesin olsaydı, iki koşu arasındaki farkın standart sapması \(\sqrt{2}\times\)sd olurdu ve \(k \times\) sd’lik bir eşik, hiçbir şey yapmayan değişikliklerin yaklaşık \(\Phi(-k/\sqrt{2})\) kadarını yanlışlıkla engellerdi (\(\Phi\), standart normal dağılımın birikimli dağılım fonksiyonu): 2 × sd’de kabaca %8, 3 × sd’de %2, 4 × sd’de %0,2. Yukarıdaki yeniden örnekleme ise 1,0 puanda %4,3 buldu — o %0,2’nin yirmi katı. Bu sonuç, koşular arası gerçek sd’nin 0,26’dan çok 0,45’e yakın olduğunu düşündürüyor. (Formülü %4,3 için çözerken puanın 0,2’lik adımlarla ilerlediği, yani “bir puandan fazla” düşüşün en az 1,2 puan demek olduğu hesaba katılırsa sd ≈ 0,45; bu ayrıklık yok sayılırsa ≈ 0,41 çıkıyor.) Her iki değer de 0,16–0,75 \(\chi^2\) güven aralığının rahatça içinde. Beş koşuluk bir kestirimin dört katı, kestirim düşük çıktığında bile yanlış engellemeleri birkaç yüzdede tutan şeydir. Bu, insanların görmezden gelmeyi öğrendiği bir kapıyı güvendikleri bir kapıya çeviren yirmi dakikalık bir deney. Alışkanlıkla atlanan bir kapı hiç kapı olmamasından kötüdür, çünkü atlanmış kontrol kayıtlara başarılı bir kontrol gibi, yeşil bir onay işaretiyle geçer.

35.5 Altın kümenin bir yaşam döngüsü var

Yukarıdaki süit şablonlardan üretilmişti. Bu, gürültü tabanını ölçmek için yerinde bir seçim; şablonların tanımladığı yetenekleri sınamak için de yararlı. Ama üretim kalitesini temsil etmiyor: süitte yalnızca o şablonların içerdiği olgular var, başka hiçbir şey yok. Gerçek bir altın küme gerçek trafikten gelir ve durağan bir ürün değildir.

Arızalardan doğar. İlk maddeler gerçekten bozulmuş vakalar olmalı. Bölüm 34’ün izleri ham madde: birinin şikâyet ettiği koşu, girdileri zaten kaydedilmiş bir senaryodur.

Eldeki kolay örneklerden değil, kasıtlı olarak örneklenmeli. Trafik ağır kuyrukludur, dolayısıyla tekdüze örnekleme (her isteğe aynı seçilme şansını veren rastgele örnekleme) size en yaygın isteğin yüz varyasyonunu verir. Katmanlandırın — niyete, uzunluğa, dile, müşteri kesimine göre — ve seyrek ve zor vakaları bilerek fazladan örnekleyin (oversampling); yoksa küme, tam da üretimin olmadığı biçimde kolay olur.

Kişisel veri taşır ve bu bir karardır. Gerçek trafik gerçek müşteriler içerir. Bölüm 34’ün maskeleme argümanı burada da geçerli: takma adlandırmayı (pseudonymisation) tek seferde yapabileceğiniz tek yer, kümenin depoya girmesinden önceki andır; yükümlülükleri Bölüm 38 kapsıyor. Altın küme, uzun bir saklama süresi olan bir üretim verisi kopyasıdır; veri politikanızın düzenlediği şey de budur.

Yaşlanır ve arıza sessizdir. İki mekanizma var. Küme, içindekileri düzelttikçe kolaylaşır, dolayısıyla sabit kalan bir puan her çeyrek daha az anlam taşır — Bölüm 22’nin açık benchmark’lar (kıyaslama) için anlattığı doygunluğun aynısı, kendi deponuza gelmiş hâli. Trafik de kümenin altından kayar: kullanıcılar yeni ifadeler bulur, üründe yeni özellikler yayına alınır ve küme geçen yılın ürününü betimler. Altı aydır değişmemiş bir altın küme kararlı değil, bayattır. Tazelemeye rutin iş olarak bütçe ayırın: son arızalardan maddeler ekleyin ve her maddenin ne zaman girdiğini kaydedin. Artık hiçbir sürümün hata yapmadığı maddeleri çıkarın, ama yalnızca kümenin güncel trafiği temsil etmek için örneklenmiş kısmından. Gerçek bir arıza olarak giren maddeler regresyon testidir ve kümede kalır.

Boyutu kişisel tercihle değil, Bölüm 22’nin aritmetiğiyle belirlenir. O bölümün hesabına göre, maddelerin %80’ini doğru yapan bir sistemde %80 güçle 30 madde hiçbir farkı saptayamıyor; 100 madde 13,4 puanlık, 1.000 madde 4,8 puanlık bir farkı saptayabiliyor. Bu sayılar %80’lik bir baseline değerine ait; onları ödünç almak yerine aritmetiği kendi metriğiniz için yeniden yapın. Buradaki tam eşleşme %81’de, o değere yakın; yeniden sıralanmış prompt ona 9,2 puana mal oldu — eşleştirme olmadan sistem başına 100 maddenin saptayabileceği 13,4 puandan az. Alan doğruluğu farklı bir durum: %96 civarında binom varyansı \(p(1-p)\), %80’deki değerinin yaklaşık dörtte biri. Bu süitin koşu başına 500 alan kararı var ve aynı hesaba göre sistem başına 500 eşleştirilmemiş karar, %95,6’dan ancak yaklaşık 4,4 puanlık bir düşüşü saptayabiliyor (1.000 kararla bu eşik yaklaşık 2,9 puana iner). Yeniden sıralamanın 3,4 puanlık düşüşü bunun altında kalıyor. Yine de aynı 100 madde üzerindeki kapı, yeniden sıralanmış prompt’ta yeniden örneklemelerin %99,4’ünde tetikleniyor.

O iki sayı farklı soruları cevaplıyor; onları ayrı tutmak gerekir. 13,4 ile 4,8 en küçük saptanabilir etki (minimum detectable effect, MDE) değerleri: yeni bir örneklemden bilinmeyen bir etkiyi kestirmenin belirsizliğini taşıyorlar. %99,4 ise bir karar kuralının işletim karakteristiği: bu sabit 100 madde ve bu ölçülmüş ortalama fark verildiğinde eşik ne sıklıkla tetikleniyor? Bu oran, gözlenen 3,40 puanın gerçek etki olduğunu varsayıyor; dolayısıyla istatistiksel güç değildir ve bu süitin ötesine genellenemez. İkisini de raporlayın — operasyon için kapının yanlış engelleme ve yakalama oranları, gerilemenin gerçek olduğu iddiası için yukarıdaki eşleştirilmiş test. Bu örneklem büyüklüğünde ikincisini mümkün kılan şey eşleştirme; bir kapının yeni örneklemler yerine özdeş maddeler üzerinde koşuları karşılaştırmasının nedeni de bu.

35.6 Canlı trafiği tamamını puanlamadan puanlamak

Çevrimdışı değerlendirme, sistemin topladığınız vakaları başarıyla işleyip işlemediğini sorar. Çevrimiçi değerlendirme ise şu anda gelen vakaları başarıyla işleyip işlemediğini sorar. Hepsini puanlayamazsınız — hakem, yargıladığı modelle aşağı yukarı aynı büyüklükteyse her isteği yargılamak çıkarım maliyetini kabaca ikiye katlar — dolayısıyla soru neyin örnekleneceği.

Önce ucuz sinyaller, çünkü hakem gerektirmiyorlar ve tüm trafiği kapsıyorlar: şema geçerliliği ve ayrıştırma oranı (Bölüm 18), reddetme oranı, gecikme ve token sayıları (Bölüm 34), araç hata oranı, yeniden deneme oranı ve adım tavanına takılıp kesilme (Bölüm 33). Bunların hiçbiri size bir cevabın iyi olup olmadığını söylemez; ama bir şey bozulduğunda hepsi keskin biçimde oynar.

Ardından bir örneklem üzerinde hakem kullanılır; örneklem üç parçadan oluşur:

küçük tekdüze bir dilim — trafiğin sabit bir yüzdesi; böylece baseline zaman içinde karşılaştırılabilir kalır;
zaten yanlış görünen her şey — hatalar, yeniden denemeler, tavana çarpmalar, olumsuz oylar, aktarmalar (escalation: vakayı daha güçlü bir modele ya da bir insana aktarma);
başka türlü hiç görmeyeceğiniz seyrek vakaların katmanlandırılmış bir dilimi.

İki disiplin sayıyı kullanılabilir kılıyor. Çevrimiçi hakemi Bölüm 22’nin çevrimdışı bir hakemi denetlediği gibi denetleyin: bu, aynı ölçüm aracı, yalnızca daha az gözetim altında. Sırayı değiştirdiğinizde maddelerin %38’inde hükmünü değiştiren bir hakem bunu üretimde de yapar. İkincisi, hakemin sürümünü ve prompt’unu puanın yanına kaydedin, çünkü bir hakem yükseltmesi tüm seriyi kaydırıyor; Bölüm 32’nin sabitleme argümanı modele olduğu kadar değerlendiriciye de geçerli.

35.7 Kullanıcı geri bildirimi ve A/B testleri

İki kanıt türü daha yalnızca üretimde var: kullanıcıların size söyledikleri ve sistemi altlarında değiştirdiğinizde yaptıkları.

Kullanıcı geri bildirimi bir metrik değil, yanlı bir örneklemdir. Açık sinyaller — başparmak yukarı ya da aşağı, yıldız puanı, yazılı bir şikâyet — kullanıcıların küçük bir azınlığından gelir ve bu azınlık rastgele değildir: canı sıkılanlar ya da çok memnun kalanlar, cevabını alıp çıkıp gidenlerden daha sık oy verir. Bu bir seçim yanlılığıdır (selection bias) ve olumsuz oy oranının trafiğinizi değil, tıklamayı seçen kullanıcıları betimlediği anlamına gelir. Örtük sinyaller — kullanıcının cevabı yeniden ürettirmesi, kopyalaması, düzenlemesi, aynı soruyu yeniden sorması, konuşmayı yarıda bırakması ya da bir insan istemesi — herkesi kapsar, ama her biri birden fazla anlama gelebilen bir vekil göstergedir: yeniden üretme “yanlış” da demek olabilir, “bir başka hâlini göster” de. Olumsuz oy ayrıca “yanlış” ile “istediğim bu değildi”yi karıştırır: doğru bir reddetme ya da kullanıcının hoşuna gitmeyen isabetli bir cevap da olumsuz oy toplar. Bir sistemi doğrudan olumlu oy için eniyilerseniz Bölüm 9’un ödül istismarıyla (reward hacking) yeniden karşılaşırsınız: hoşa giden cevaplar yükselir, doğru ama hoşa gitmeyen cevaplar düşer. Oran arayüzle de oynar — daha kolay erişilen bir düğme, kalite hiç değişmeden oranı değiştirir. Dolayısıyla geri bildirimi önceki alt bölümdeki gibi kullanın: şüpheli vakaları hakeme ve insanlara gönderen bir örnekleyici ve altın küme adayı kaynağı olarak — kalite puanı olarak değil.

A/B testi, diğer basamakların açık bıraktığı soruyu cevaplar: değişiklik gerçek kullanıcılara yarıyor mu? Bunu yapabilen tek basamak odur, çünkü rastgele atama iki grubu, aldıkları sürüm dışında her bakımdan benzer kılar. Test başlamadan önce dört karar yazıya geçirilir:

Rastgeleleştirme birimi. Genellikle istek değil kullanıcı; böylece bir kişi aynı konuşmada iki farklı davranışla karşılaşmaz. Analizi de aynı düzeyde yapın: bir kullanıcının istekleri birbiriyle ilişkilidir, dolayısıyla 5.000 kullanıcıdan gelen 50.000 isteği 50.000 bağımsız gözlem saymak standart hatayı olduğundan küçük, sonucu olduğundan kesin gösterir.
Tek bir birincil metrik — değişikliğin oynatması beklenen sonuç; örneğin insana aktarılmadan çözülen konuşmaların payı. Onu veriyi gördükten sonra seçmek, Bölüm 22’nin uyardığı çoklu karşılaştırma problemidir: yeterince metriğe bakarsanız biri rastlantıyla 0,05’in altında bir p değeri verir.
Koruma metrikleri (guardrail metrics) — birincil metriğin peşindeyken kötüleşmemesi gerekenler: gecikme, konuşma başına maliyet, aktarma oranı, şikâyet oranı. Bu ad A/B testi terminolojisine aittir; Bölüm 37’nin çalışma zamanı korkuluğuyla karıştırmayın. Yine de açıkça aşılmış bir koruma metriği testi aynı hızla durdurmalıdır.
Örneklem büyüklüğü ve durdurma kuralı.

Örneklem büyüklüğü yine Bölüm 22’nin aritmetiğidir, ama kullanıcı sonuçları üzerindeki gerçek etkiler küçüktür ve sayılar büyür. İki bağımsız grup için, \(p_1\)’den \(p_2\)’ye bir değişimi %80 güçle ve iki yönlü %5 anlamlılık düzeyinde saptamak için

\[ n \approx \frac{(1{,}96 + 0{,}84)^2 \,\bigl[p_1(1-p_1) + p_2(1-p_2)\bigr]}{(p_1 - p_2)^2} \]

kadar kullanıcı gerekir — kol başına. Konuşmaların şu an %20’si bir insana aktarılarak bitiyorsa ve bunu %18’e indirmeyi umuyorsanız, bu kol başına yaklaşık 6.000 kullanıcı eder; bir puanlık bir değişimi, %20’den %19’a, saptamak içinse kol başına yaklaşık 24.600. Görmek istediğiniz etkiyi yarıya indirmek örneklemi yaklaşık dört katına çıkarır, çünkü fark paydada karesiyle yer alır. Günde 5.000 uygun kullanıcı eşit bölünürse bir puanlık test yaklaşık on gün sürer — A/B testinin yavaş basamak olmasının nedeni bu.

Durdurma kuralı da örneklem büyüklüğü kadar önemlidir. p değerine her gün bakıp ilk p < 0,05’te durmak — ara bakış (peeking) — yanlış pozitif oranını (birinci tür hata oranını) %5’in çok üstüne çıkarır: iki kolun özdeş olduğu bir A/A testinin on eşit aralıklı ara bakışla yapılan benzetiminde, koşuların yaklaşık %19’u bakışlardan birinde 0,05 eşiğinin altına indi. Süreyi önceden sabitleyip sonda bir kez test edin ya da tekrarlı bakışlar için tasarlanmış ardışık (sequential) bir test kullanın: önceden planlanmış birkaç ara analizle grup ardışık tasarımlar (ör. O’Brien–Fleming sınırları) ya da Bölüm 22.5’te anılan her zaman geçerli (always-valid) ardışık testler. Süreyi sabitlerken yenilik ve alışkanlık etkilerini (novelty / primacy effect) de hesaba katın: kullanıcılar yeni bir davranışa ilk günlerde merakla fazla, alıştıkları eskisini aradıkları için az tepki verebilir; bu yüzden ilk birkaç günde ölçülen etki kalıcı olmayabilir ve süre en az bir tam haftalık döngüyü kapsamalıdır. Koruma metrikleri ise tersi bir nedenle sürekli izlenir: zarar yüzünden erken durmak ucuzdur, sahte bir kazanç ise yayına çıkar. İlk gerçek testten önce de tüm hattan bir A/A testi geçirin — bu, bu bölümün gürültü tabanı ölçümünün deney platformuna uygulanmış hâlidir. Her testte ayrıca örneklem oranı uyumsuzluğunu (sample ratio mismatch, SRM) kontrol edin: kollara düşen kullanıcı sayıları tasarlanan orandan (ör. 50/50) basit bir ki-kare testinin yakalayacağı kadar sapıyorsa rastgeleleştirme ya da kayıt tutma bozuktur ve sonuç okunmamalıdır.

35.8 Bir panoda birbirinin aynı görünen üç kayma türü

Bir kalite metriği düşüyor. Panoda aşağı inen tek bir çizgi var; arkasında ise birbirinden bağımsız üç neden ve bunların üç ayrı çözümü olabilir.

Aynı çizgi, üç neden
ne kımıldadı	neye benziyor	nasıl anlarsınız	ne yaparsınız
Model	belirli bir günde, tüm trafikte ani bir düşüş	`gen_ai.request.model` değişmezken `gen_ai.response.model` değişti (Bölüm 34)	sürümleri sabitleyin (Bölüm 32); altın kümeyi ikisine karşı yeniden koşun
Girdiler	bazı kesimlerde yoğunlaşmış kademeli bir kayış	girdi dağılımı kımıldadı: yeni ifadeler, uzunluklar, diller, yeni bir müşteri	altın kümeyi tazeleyin; sistem değişmedi, iş değişti
Sistem	bir dağıtıma bağlayabileceğiniz ani bir düşüş	bir sürümle hizalanıyor (Bölüm 33)	kapının yakalaması gerekirdi; kaçan vakayı ekleyin

Bunları ayıran şey cevaplayan modeli ve girdi dağılımını kaydetmektir; onlar olmadan üçü de “kalite düştü”dür ve karşılık bir tahmindir. Ayırt edici kanıt ucuz ve önceden toplanmalı — geçen ayın girdi dağılımını olay sonrasında yeniden kuramazsınız.

Girdilerin kaydığını nasıl görürsünüz? Yakın dönemin trafiğini bir referans penceresiyle birkaç ucuz betimleyici üzerinden karşılaştırın: girdi uzunluğu, dil, her niyetin payı (bir sınıflandırıcıdan ya da Bölüm 11’deki gibi girdi embedding’lerinin (gömme) kümelerinden) ve embedding uzayında hiçbir altın küme maddesine yakın olmayan girdilerin payı. Gruplanmış sayımlar üzerinde bir ki-kare testi, hatta payların zaman içindeki basit bir grafiği, hangi kesimin büyüdüğünü gösterir; son betimleyici ayrıca altın kümenizin kapsamadığı yeni girdileri işaret eder. İzleme panolarında bu karşılaştırmalar çoğu zaman hazır adlarıyla karşınıza çıkar: kovalara ayrılmış bir betimleyicinin iki penceredeki paylarını tek sayıya indiren PSI (population stability index) ve embedding dağılımları gibi çok boyutlu örneklemler için MMD (maximum mean discrepancy) türünden iki örneklem mesafeleri.

Adlandırılmayı hak eden dördüncü bir vaka var, çünkü çoğu zaman en yaygını o: hiçbir şey kaymadı ve metriğiniz gürültülü. Gürültü tabanı bunun için var. Ölçülen gürültü tabanı 0,6 puan olan sabit bir süiti her hafta yeniden koştuğunuzda puan 0,5 oynuyorsa, bu bir sinyal değildir. Çevrimiçi bir puanın tabanı daha da yüksektir, çünkü her hafta farklı istekler üzerinde hesaplanır: koşudan koşuya oynamanın üstüne sıradan örnekleme hatasını da taşır. Geçme oranı %80 olan, hakemle puanlanmış 500 isteklik bir örneklem için bu yaklaşık 1,8 puanlık bir standart hatadır — haftalık bir salınımı kayma diye okumadan önce bunu hesaplayın.

35.9 Belirsiz vakaları insanlara yönlendirmek

Otomatik puanlama tam da en çok gerektiği yerde yetersiz kalıyor: sistemin emin olmadığı, hakemin güvenilmez olduğu ya da yanılmanın maliyetinin yüksek olduğu vakalarda. Onlar insanlara gider ve boru hattı, üretime doğrultulmuş hâliyle Bölüm 5’in boru hattıdır.

Bunu işe yaratan şey, yönlendirmenin birinin izlediği bir kuyruk değil, yazılı ve ölçülmüş bir politika olmasıdır. Üç girdi buna karar veriyor: elinizde varsa model belirsizliği, hakemler arasında ya da bir hakemle bir kural arasında uyuşmazlık ve riskin büyüklüğü, yani yanlış kararın maliyeti — bir iade, bir tıbbi talep ve bir kargo sorgusu aynı titizliği hak etmiyor. Bu politikanın uygulatılması (enforcement) ise Bölüm 37’nin konusu.

İnsan incelemesinin çıktısı tek bir ürün değil üçtür ve takımlar rutin olarak yalnızca ilkini yakalar: o vakaya dair anlık karar; altın küme için etiketli bir madde; ve aynı arıza üçüncü kez göründüğünde, üçüncü bir düzeltme yerine sistemde bir değişiklik. İnsan incelemesi yalnızca karar üretiyorsa, bir geri besleme döngüsü değil elle işleyen bir süreç satın almışsınızdır.

Bundan çıkan maliyet modelini açıkça söyleyelim, çünkü bir bütçe sahibine gerekçeyi sunan şey o: inceleme kapasitesi sabittir, dolayısıyla soru hiçbir zaman “insanlar bunu kontrol etmeli mi” değil, “elimizdeki insanlar trafiğin hangi dilimine baksın”dır. Bu da yönlendirmeyi apaçık bir amacı olan bir kaynak tahsis problemi yapıyor — onlara, hükümlerinin bir sonucu değiştirdiği vakaları gönderin.

35.10 Bu kısmın kurmaya çalıştığı döngü

Bu kısımdaki her bölüm aynı döngünün bir halkasıydı. Döngünün tamamı şöyle:

Servis edin (Bölüm 31) ve yönlendirin (Bölüm 32).
Arıza atlatılabilir olacak biçimde dağıtın (Bölüm 33).
Ölçüm düzeneği kurun (Bölüm 34); böylece bir şikâyetten ilgili span’e ulaşılabilsin.
O span’i bir teste çevirin — bu bölüm ve Bölüm 30’un disiplini.
Bir sonraki değişikliği o testten geçirin; kapının eşiği ölçülmüş bir gürültü tabanından belirlenmiş olsun.
Canlı trafiği örnekleyin, kimsenin bildirmediği arızaları bulmak için.
Belirsiz olanları insanlara yönlendirin ve etiketlerini 4. adıma geri besleyin.

Döngü egzotik değil. Olgun herhangi bir yazılım sisteminin işletme ritmi bu, bu ortam için iki ayarla: testler belirlenimci değil istatistiksel ve sınanan ürün, kimsenin kod olarak düşünmediği bir metin dosyası.

35.11 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. İlk üçü bölümün ölçümlerini taşıyor — gürültü tabanı, kozmetik olmayan kozmetik düzenleme ve büyüdükçe kötüleşen kapı. Son üçü, yeşil bir kapının neye inanmanıza izin verip vermediğiyle ilgili.

1. LLM değerlendirme puanları bir birleştirme kararında kullanılamayacak kadar gürültülü mü?

İki cevaptan birine inanmadan önce ölçün. Burada değillerdi.

Aynı prompt, aynı 100 maddelik süit üzerinde beş kez koşuldu; sd = 0,26 verdi ve alan doğruluğunda 0,60 puan yayıldı. Gürültü tabanı bu ve kapı kurulacak kadar küçük — ama eşiği aralıktan değil, pay bırakarak sd’den belirleyin; çünkü beş çekilişin aralığı, altıncı koşunun bazen aşacağı bir kestirim. İşleyen kural kabaca 4 × sd.

Sayı göreve özgü ve döngüde bir hakemle (Bölüm 22’de küçük bir hakem, adayların sırası değiştirildiğinde maddelerin %38’inde hükmünü değiştirdi) ya da daha küçük bir süitle büyük olasılıkla daha büyük çıkar. Taşınabilir kısım 0,26 değil; yirmi dakikalık bir deneyin — değişmemiş sistemi beş kez koş, yayılımı kaydet — bir tartışmanın yerine bir eşik koyması.

2. Bir meslektaşınız bir prompt’taki kuralları yeniden sıralıyor. Aynı kurallar, aynı sözcükler. Güvenli mi?

Hayır ve bu, bölümün merkezî ölçümü.

Altı kuralı yeniden sıralamak — eklenen yok, çıkarılan yok, sözcük değişikliği yok — alan doğruluğunda 3,40 ve tam eşleşmede 9,20 puana mal oldu. Bir farkı “kaç kat” diye verirken neye göre olduğunu söyleyin: bu, beş koşuluk 0,60 puanlık aralığın kabaca altı katı ve koşular arası 0,26’lık sd’nin yaklaşık on üç katı. Bu bölümdeki her “× gürültü” sayısı aralığa göredir, çünkü okurun tek bir yeni koşuyu karşılaştırdığı şey odur; sd ise eşiği kurmak için kullanılacak sayıdır. Gerilemenin tamamı tek bir alandaydı: day 100’de 91’den 74’e düştü.

Mekanizma adlandırılabilir. 40 maddelik bir incelemede, her iki prompt altında da yanlış olan her day tutarın baştaki rakamlarıydı — model bir alanı bir diğerine sızdırıyor ve amount kuralını day kuralının üstüne taşımak bunu üçe katladı. Hata yayına alınan prompt’ta da vardı (maddelerin %10’unda); yeniden sıralama onu büyüttü.

Prompt’un bir arayüzü yok, dolayısıyla hiçbir düzenlemesinin yerel kaldığı kanıtlanamıyor. Prompt değişikliklerini de bir kapıdan geçirmenin gerekçesi bu.

3. Değerlendirme kapınız kararsız (flaky). Daha fazla test vakası mı eklemelisiniz?

Tek başına hayır — naif bir kapıyla daha fazla vaka onu daha da kararsız yapar.

Ölçüldü: yeni puan ne zaman düşükse engelleyen bir kapı, hiçbir şey yapmayan değişikliklerin 20 maddede %22,9’unu, 50’de %35,6’sını ve 100’de %42,5’ini yanlışlıkla engelliyor. Küçük boyutlarda iki koşu sıklıkla tam olarak berabere kalıyor ve beraberlikler geçiyor; süit büyüdükçe tam beraberlikler kayboluyor ve karşılaştırma yazı tura atmaya yakınsıyor.

Önce bir eşik ekleyin. Bir puanda ve 100 maddede yanlış engellemeler %4,3’e düşüyor ve yeniden sıralanmış prompt hâlâ yeniden örneklemelerin %99,4’ünde yakalanıyor — ve artık ek vakalar beklediğiniz gibi yardım ediyor. Eşiği yuvarlak bir sayıdan değil, ölçtüğünüz gürültü tabanından belirleyin.

4. Kapı 0 sıcaklıkta mı koşmalı?

İki gerçek sınırı olan gerçek bir fayda.

0 sıcaklıkta buradaki iki koşu madde bazında bayt bayt aynıydı — yalnızca aynı puan değil, 100’ün hepsinde aynı sonuç. Bu, bu düzenekte koşudan koşuya oynamayı kaldırıyor (toplu işleyen ya da barındırılan servislerde bu kadar kesin olmayabilir) ve başarısız bir kapı koşusunu bir dizüstü bilgisayarda yeniden üretilebilir kılıyor; bu çok değerli.

Ama greedy kod çözme 95,20 aldı, 0,7 sıcaklığın 95,40–96,00 aralığının tamamının altında: olası çıktılardan yalnızca biri, en iyisi değil. Ve hiçbir şeyi düzeltmedi — baştaki rakam hatası hâlâ oradaydı. Ayrıca muhtemelen kullanıcılarınıza 0 sıcaklıkta hizmet etmiyorsunuz, dolayısıyla kapı yayına almadığınız bir yapılandırmayı ölçüyor.

Makul çözüm: yeniden üretilebilirlik için kapıyı 0 sıcaklıkta koşun ve gerçekten servis ettiğiniz örneklemeli yapılandırmayı ayrıca izleyin.

5. Altın kümenizin puanı altı aydır sabit. İyi haber mi?

Neredeyse kesinlikle değil — bir değerlendirme programının sessizce öldüğü en yaygın yol bu.

Aynı anda iki şey oluyor. Küme, içindekileri düzelttikçe kolaylaşıyor, dolayısıyla sabit bir puan sağlıklı bir sistemi değil çözülmüş bir kümeyi yansıtıyor: Bölüm 22’nin benchmark doygunluğu, kendi deponuza gelmiş hâli. Ve trafik altından kayıyor — yeni ifadeler, yeni özellikler, yeni müşteriler — dolayısıyla küme geçen yılın ürününü betimliyor.

Bayat bir küme, hiç küme olmamasından kötüdür, çünkü yeşil bir onay işareti üretir. Bir yerine iki küme tutun: yalnızca büyüyen bir regresyon kümesi — bir maddenin oradaki yerini bir zamanlar gerçek bir arıza olarak hak ettiği ve tam da eski bir hata fark edilmeden geri dönmesin diye sonsuza kadar kaldığı küme — ve güncel trafikten örneklenip bir takvime göre tazelenen bir temsilî küme. Artık hiçbir sürümün hata yapmadığı maddeleri çıkarmak ikincisi için doğru, birincisi için yanlıştır. Her maddenin ne zaman girdiğini kaydedin ve tazelemeyi bir proje değil, rutin iş olarak ele alın.

6. Bu ay kalite 4 puan düştü. Ne bozuldu?

Dört aday ve önceden toplanmış kanıt olmadan bunları olay sonrasında ayıramazsınız.

Model kımıldadı — tek bir günde ani bir düşüş, gen_ai.request.model değişmezken gen_ai.response.modelin değişmesi olarak görünür (Bölüm 34). Girdiler kımıldadı — bazı kesimlerde kademeli bir kayış; sistem değişmedi, iş değişti. Sistem kımıldadı — bir dağıtımla aynı zamana denk gelen ani bir düşüş ve kapınızın içermediği bir vaka. Ya da hiçbir şey kımıldamadı ve metrik gürültülü.

Gürültü tabanını kullanarak önce dördüncüyü eleyin. Sonra cevaplayan model ve girdi dağılımı diğer üçünü ayırıyor — ikisi de ucuz ve ikisi de geriye dönük yeniden kurulamaz.

35.12 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Aşağıdaki sorular bu kitabın baştan sona kullandığı iki güvenilir açık kaynakta tekrar tekrar geçiyor; bunlara bu bölümün kendi ölçümünün cevaplanabilir kıldığı sorular da ekleniyor.

35.12.1 Problemi anlayıp anlamadığınızı sınayanlar

S: Bir LLM sistemini CI’da değerlendirmek, birim testleri koşmaktan nasıl farklı?

İddia belirlenimci değil istatistiksel. Bir birim testi her koşuda aynı cevabı döndürür; bir süit puanı rastgele bir değişkendir, dolayısıyla bir kapının eşiğe ve eşiğin ölçülmüş bir gürültü tabanına ihtiyacı var. Onu nasıl elde edeceğinizi söyleyin: değişmemiş sistemi aynı süit üzerinde beş kez koşun ve yalnızca en geniş açıklığı değil, koşular arası sd’yi de kaydedin. Burada 100 maddede sd = 0,26 puan, gözlenen aralık 0,60 puandı — kapı kurulacak kadar küçük; bu da alışıldık varsayımın tam tersi. Eşik kabaca 4 × sd’ye konur, çünkü sonraki koşular beş koşuluk aralığı aşacaktır.

S: Bir prompt değişikliği yalnızca mevcut talimatları yeniden sıralıyor. Değerlendirme koşusu gerekir mi?

Evet ve insanları ikna eden vaka bu. Başka hiçbir düzenleme yapmadan altı kuralı yeniden sıralamak burada alan doğruluğunda 3,4 ve tam eşleşmede 9,2 puana mal oldu — gürültü tabanının yaklaşık altı katı — ve gerilemenin tamamı tek bir alanın içindeydi. Prompt’un bir arayüzü yok, dolayısıyla hiçbir düzenleme kanıtlanabilir biçimde yerel değil ve bir inceleyicinin kozmetik bir prompt değişikliğini davranışsal olandan okuyarak ayırmasının hiçbir yolu yok.

S: Bir altın kümeyi nasıl boyutlandırırsınız?

Saptamanız gereken farktan, Bölüm 22’nin aritmetiğiyle: %80 doğru bir sistemde %80 güçle 100 madde 13,4 puanlık, 1.000 madde 4,8 puanlık bir farkı saptayabiliyor — ve bunu kendi baseline değeriniz için yeniden hesaplayın, çünkü %96 doğrulukta varyans yaklaşık dört kat küçüktür. Sonra kapı açısından önemli olan ayrımı belirtin: bunlar eşleştirilmemiş en küçük saptanabilir etkiler, oysa bir kapı iki koşuyu aynı maddeler üzerinde karşılaştırıyor. %99,4’lük yakalama oranını eşleştirmenin kanıtı diye sunmayın. O oranın arkasındaki yeniden örnekleme, maddeleri prompt’lar arasında eşleştiremedi. Üstelik gözlenen 3,4 puanlık düşüşü gerçek etki kabul ediyor. Yani eşleştirilmiş bir kapıyı ölçmüyor, bir eşiğin davranışını örnekliyor. Eşleştirmenin gerçekten sağladığı şey, aynı maddeler üzerinde bir test: McNemar testi, marjinallerle tutarlı her eşleşmede day gerilemesini gerçek buluyor. Tam eşleşme farkını ise ancak saklanmış madde bazlı sonuçlar netleştirebilir.

35.12.2 Bir tane koşup koşmadığınızı sınayanlar

S: Değerlendirme kapınız iyi değişiklikleri engelliyor ve insanlar onu elle aşmaya başladı. Düzeltin.

Gevşetmek yerine önce teşhis edin: alışıldık neden eşiği olmayan bir kapıdır. Böyle bir kapı burada 100 maddede hiçbir şey yapmayan değişikliklerin %42,5’ini yanlışlıkla engelledi — ve süit büyüdükçe kötüleşiyor, çünkü tam beraberlikler seyrekleşiyor. Eşiği ölçülmüş gürültü tabanından belirleyin; bir puanlık eşikte yanlış engelleme oranı %4,3’e düştü ve kapı gerçek bir gerilemeyi hâlâ yeniden örneklemelerin %99,4’ünde yakaladı. Sonra bunun neden acil olduğunu söyleyin: alışkanlıkla aşılan bir kapı hiç olmamasından kötüdür, çünkü aşma işlemi kayıtlara yeşil bir onay işareti olarak geçer.

S: Çevrimdışı değerlendirmeler yeşil ve kullanıcılar şikâyet ediyor. Ne yaparsınız?

Yanlışlanan hipotezin süit olduğunu kabul edin. İzlere gidin (Bölüm 34), şikâyet edilen koşuları bulun ve arıza sınıfının süitte hiç var olup olmadığına bakın — genellikle yoktur; bu da bir puanlama değil, bir derleme problemidir. O vakaları ekleyin, sonra neden yok olduklarını sorun: ağır kuyruklu bir dağılımdan kolayda örnekleme (convenience sampling: eldeki, ulaşması kolay örnekleri almak) mı, yoksa bayatlamış bir küme mi. Son bir olasılığı da kontrol edin: çevrimdışı metriğin, kullanıcıların umursamadığı bir şeyi ölçüyor olması.

S: Bir LLM hakemiyle üretim trafiğinin ne kadarını puanlarsınız ve hangisini?

Tamamını değil: benzer büyüklükte bir hakemle her isteği yargılamak çıkarım maliyetini kabaca ikiye katlar. Bedava sinyalleri trafiğin tamamında toplayın — ayrıştırma oranı, reddetmeler, gecikme, araç hataları, tavana çarpmalar — sonra üç örtüşen örneklemi yargılayın: karşılaştırılabilir bir baseline için sabit tekdüze bir dilim, zaten yanlış görünen her şey ve seyrek vakaların katmanlandırılmış bir dilimi. Sonra iki disiplin: çevrimiçi hakemi bir çevrimdışı hakemi denetlediğiniz gibi denetleyin ve sürümünü sabitleyip kaydedin, çünkü bir hakem yükseltmesi tüm seriyi kaydırır.

S: Ürün ekibi, olumsuz oy oranını ana kalite metriği yapmak istiyor. Ne dersiniz?

Bunun bir ölçüm değil, yanlı bir örneklem olduğunu. Yalnızca küçük ve kendi kendini seçen bir azınlık tıklar; olumsuz oy “yanlış” ile “hoşa gitmeyen”i karıştırır; oran arayüzle birlikte oynar. Onu eniyilemek, doğru cevaplar yerine hoşa giden cevapları ödüllendirir. Onu vakaları hakeme ve inceleyicilere yönlendiren bir örnekleyici olarak tutun; kaliteyi hakemle puanlanmış tekdüze bir örneklemle ölçün — belirli bir değişiklik içinse boyutu önceden hesaplanmış, koruma metrikleri ve durdurma kuralı ilk bakıştan önce sabitlenmiş bir A/B testiyle.

35.13 2026 alet çantası

Ölçüm için bir model, bir puanlama döngüsü ve Python’ın standart kütüphanesi yetti; dolayısıyla birinci tablo kısa. İkincisini iki katman olarak okuyun: bir süiti koşup puanlayan düzenekler (harness) ve ayrıca koşuları saklayarak onları zaman içinde karşılaştırmanızı sağlayan platformlar — bir altın kümenin yaşam döngüsünün gerçekte ihtiyaç duyduğu şey ikinci grup.

Bu sayıların geldiği yığın. Python 3.14.5, Apple Silicon
kütüphane	kullanılan sürüm	burada ne işe yarıyor
`ollama`	0.24.0	1.700 süit maddesinin tamamı için `qwen2.5:7b` servis ediyor
`pytest`	9.1.1	bu bölümün disiplininin ödünç aldığı kapı; süit sıradan testler olarak koşuyor

Bilmeye değer, yukarıda kullanılmadı:

Daha geniş ekosistem, yazım anındaki sürümler
proje	sürüm	ne zaman başvurursunuz
`promptfoo`	0.122.2	iddialar (assertion) ve bir CI koşucusuyla bildirimsel prompt test süitleri; bu bölümden çalışan bir kapıya en kısa yol
`inspect-ai`	0.3.261	Birleşik Krallık YZ Güvenliği Enstitüsü’nün (AI Security Institute; eski adıyla AI Safety Institute) değerlendirme çerçevesi; birleştirilebilir parçalar olarak çözücüler ve puanlayıcılar, yeniden üretilebilirlikte güçlü
`deepeval`	4.2.0	pytest iddiaları olarak paketlenmiş değerlendirme metrikleri; kapıyı bir test olarak kurma yaklaşımına doğrudan uyuyor
`ragas`	0.4.3	sınanan şey bir RAG hattıyken erişime özgü metrikler (Bölüm 20)
`langfuse`	4.15.1	izler, veri kümeleri ve değerlendirme koşuları tek yerde; böylece bir altın küme ile geldiği izler bağlı kalıyor
`arize-phoenix`	20.5.0	yerelde koşabileceğiniz açık kaynak izleme artı değerlendirme; izden teste adımı için yararlı
`braintrust`	0.36.0	koşuları sürümler arasında zaman içinde karşılaştırmak üzere kurulmuş barındırılan değerlendirme platformu

35.14 Lab: kapınıza güvenmeden önce onu ölçün

35.14.1 Adım 1 — doğru cevaplarını etiketlemediğiniz bir süit kurun

Umursadığınız bir görevde, boşlukları rastgele doldurulan şablonlardan üretilmiş elli ila yüz madde. Etiketlemek yerine üretmenin amacı, etiketleme hatasının gürültü tabanı ölçümünü kirletememesi. Prompt’un yanında, depoda tutun.

35.14.2 Adım 2 — gürültü tabanınızı ölçün

Değişmemiş sistemi süit üzerinde beş kez koşun ve hem en geniş açıklığı hem standart sapmayı kaydedin. Bunu herhangi bir kapı mantığı yazmadan önce yapın. Eşiği kabaca sd’nin dört katına koyun. Beş koşu tabanı ancak gevşek biçimde sabitliyor — dört serbestlik dereceli \(\chi^2\) dağılımından \(\sigma\) için elde edilen %95 güven aralığı, gerçek sd’yi kestirimin yaklaşık 0,6 katı ile 3 katı arasında herhangi bir yere koyuyor — dolayısıyla eşik kararı sınırdaysa yirmi kez koşun. Sayıyı, kapının eşiğinin tanımlandığı yere, tarih ve model sürümüyle birlikte yazın.

35.14.3 Adım 3 — incelemede onaylayacağınız bir gerileme yapın

Silinmiş bir kural değil — o fazla kolay. Talimatları yeniden sıralayın ya da bir cümleyi anlamını değiştirmeden yeniden yazın. Beş kez koşun. Farkı gürültü tabanınızın bir katı olarak raporlayın ve yalnızca toplamı değil, alan bazlı ya da kategori bazlı sayıları raporlayın.

35.14.4 Adım 4 — mekanizmayı bulun

Değişiklik puanı kımıldattıysa nasıl kımıldattığını bulun. Yanlış öngörüleri yazdırın ve bir örüntü arayın; bu bölümde yanlış olan her dayin tutarın baştaki rakamları olduğu ortaya çıktı. Adlandırılmış bir mekanizması olan bir gerileme bir test vakasına dönüşür; yalnızca bir sayı olan bir gerileme bir tartışmaya dönüşür.

35.14.5 Adım 5 — kapıyı kurun ve yanlış engelleme oranını ölçün

Süiti CI’a bağlayın; böylece bir birleştirmeyi engelleyebilsin. Sonra hiçbir şeyi değiştirmeyen değişiklikler gönderin ve onları ne sıklıkla engellediğini kaydedin — deneme sayısını ihtiyaç duyduğunuz hassasiyete göre seçin, çünkü beş deneme yetmez: beşte sıfır engelleme bile %95’lik Wilson güven aralığının üst sınırını %43’te bırakır ve bu, “birkaç yüzde” ile “felaket”i ayırt edemez. Birkaç yüzdelik bir oranı ayırt etmek yüz mertebesinde deneme ister; etkisiz değişiklik (no-op) yalnızca boşluk karakteri değiştiren bir commit ve betikle yapılan bir yeniden koşuysa bu ucuzdur. Ölçülen oran birkaç yüzdenin üstündeyse eşiğiniz fazla sıkı — kapıyı aşma düğmesine değil, adım 2’ye dönün.

35.14.6 Adım 6 — bir de 0 sıcaklıkta koşun

Yeniden üretilebilirliği ve puanı karşılaştırın. Madde bazlı sonuçlarınızın koşular arasında özdeş olup olmadığını ve greedy puanın örneklenmiş aralığınızın içinde mi altında mı oturduğunu doğrulayın. Kapının hangi yapılandırmayı kullandığına kasıtlı olarak karar verin ve nedenini yazın.

35.14.7 Teslim edilecekler

Arkasındaki beş koşu puanıyla birlikte ölçtüğünüz gürültü tabanı; incelemede görünmez bir düzenlemenin farkı, o tabanın bir katı olarak, alan bazlı dökümle; onun için bulduğunuz mekanizma; gerekçesiyle birlikte kapınızın eşiği; ve ölçülmüş yanlış engelleme oranı — etkisiz değişiklik deneme sayısı ve %95’lik Wilson üst sınırıyla birlikte. İhtiyaç duyduğunuz oranı ayırt edecek kadar deneme kullanın (adım 5); beş deneme bunu yapamaz.

35.15 Alıştırmalar

Kendi gürültü tabanınız. Değişmemiş bir sistemi gerçek değerlendirme kümeniz üzerinde beş kez koşun. Koşular arası sd’yi ve en geniş açıklığı raporlayın; ikisini takımınızın iddia ettiği son iyileştirmenin boyutuyla karşılaştırın. İddia tabandan küçükse bunun ne anlama geldiğini söyleyin.
Görünmez düzenleme. Üretimdeki bir prompt’u alın ve talimatlarından hiçbirini değiştirmeden yeniden sıralayın. İki sürümü de beş kez koşun. Farkı alan bazlı sayılarla ve bir inceleyicinin yönü öngörüp öngöremeyeceğiyle birlikte raporlayın.
Eşik taraması. Yeniden örneklenmiş koşuları kullanarak, 20, 50 ve 100 süit boyutları için yanlış engelleme oranını ve yakalama oranını eşiğe karşı çizin. Çalışma noktanızı seçin ve bir paragrafta gerekçelendirin.
Eşleştirmeye karşı güç. Ölçtüğünüz gerilemeyi %80 güçte çözmek için gereken eşleştirilmemiş örneklem büyüklüğünü hesaplayın (Bölüm 22), sonra eşleştirilmiş kapınızın onu denemelerin %95’inde yakaladığı süit boyutuyla karşılaştırın. Farkı açıklayın.
Altın küme yaşı. Değerlendirme kümenizdeki her madde için ne zaman eklendiğini, regresyon maddesi mi temsilî madde mi olarak girdiğini ve son çeyrekte herhangi bir sürümün o maddede hata yapıp yapmadığını kaydedin. Hiçbir sürümün hata yapmadığı temsilî maddeleri çıkarın, regresyon maddelerinin hepsini tutun ve her türden kaç madde kaldığını raporlayın.
İzden teste. Üç gerçek üretim şikâyeti alın, izlerini bulun (Bölüm 34) ve her birini bir süit vakasına çevirin. Sonra özgün süitin o arıza sınıfında bir şey içerip içermediğini kontrol edin.
Üç kayma. Bir model değişikliğini, bir girdi dağılımı değişikliğini ve bir sistem değişikliğini ayırmaya yetecek kadar ölçüm düzeneği kurun. Sonra her birinden birini benzetin ve panonuzun onları birbirinden ayırdığını doğrulayın. Hangi kanıtı önceden toplamak zorunda kaldığınızı not edin.
Bir A/B testini boyutlandırın, sonra ara bakış yapın. Sisteminizin kaydettiği evet/hayır türünden bir sonucu seçin; bir ve iki puanlık bir değişimi %80 güçte saptamak için kol başına kaç kullanıcı gerektiğini (Bölüm 35.7) ve bunun sizin trafiğinizde kaç gün sürdüğünü hesaplayın. Sonra verinin her onda birinden sonra kontrol edilen bir A/A testini benzetin ve p < 0,05’te ne sıklıkla bir fark “bulduğunu” raporlayın.

35.16 Daha derine

Okumadan önce: mevcut değerlendirme süitinizi değiştirmeden iki kez koşun ve iki sayıya bakın. Hangi farkların gerçek olduğunu söyleyip söyleyemeyeceğiniz bu bölümün konusunun tamamı.

Bu bölüm hiçbir makaleye atıf vermiyor, dolayısıyla alışıldık iki tablo yerine tek bir tablo var. Üzerinde durduğu istatistiksel temeller Bölüm 22’de; aşağıdaki ise onları bir kapıya çeviren aletler.

Bu bölümün ötesi
kaynak	ne olduğu
`promptfoo`	bir CI koşucusuyla bildirimsel prompt değerlendirmeleri; bu bölümden bir birleştirmeyi engelleyen bir kapıya en kısa yol
`inspect_ai`	Birleşik Krallık YZ Güvenliği Enstitüsü’nün (AI Security Institute) çerçevesi; çözücüleri puanlayıcılardan nasıl ayırdığını görmek için okuyun; ev yapımı düzeneklerin çoğunda eksik olan soyutlama budur
`deepeval`	pytest iddiaları olarak değerlendirme metrikleri — kapıyı bir test olarak kurma yaklaşımının kütüphane hâli
`ragas`	sınanan sistem bir RAG hattı olduğunda erişime özgü metrikler (Bölüm 20)
`langfuse`	tek bir sistemde izler, veri kümeleri ve değerlendirme koşuları; bir altın kümeyi geldiği izlere bağlı tutan da budur
`phoenix`	yerelde koşabileceğiniz açık kaynak izleme ve değerlendirme; izden teste adımını çalışmanın en ucuz yolu
`braintrust-sdk`	değerlendirme koşularını sürümler arasında zaman içinde karşılaştırmak üzere düzenlenmiş barındırılan bir platform
`openai/evals`	erken ve çokça kopyalanmış bir değerlendirme kaydı; çoğunlukla başkalarının süitlerini nasıl belirttiğini okumak için yararlı

35.17 Akılda kalması gerekenler

Bir prompt değişikliği bir kod değişikliğidir ve bir değerlendirme puanı bir birim testi değildir. Süit depoda yaşar, her prompt değişikliğinde koşar ve birleştirmeyi engeller — ama iddia istatistikseldir, dolayısıyla kapının bir eşiğe ve eşiğin neredeyse hiç kimsenin ölçmediği bir sayıya ihtiyacı vardır.
Gürültü tabanınızı ölçün; yirmi dakikalık bir deney. Aynı 100 maddelik süitin beş özdeş koşusu, alan doğruluğunda koşular arası 0,26 puanlık bir sd ve 0,60 puanlık bir gözlenen aralık verdi. Bu, kapı kurulacak kadar küçük ve yaygın kanıyla çelişiyor. Eşiği aralıktan değil sd’den belirleyin (kabaca 4 × sd), çünkü sonraki koşular aralığı aşacaktır — ve ölçülmüş bir taban olmadan sonraki hiçbir fark yorumlanamaz.
Kozmetik bir prompt düzenlemesi kozmetik bir değişiklik değildir. Hiçbir şey eklemeden, çıkarmadan ve yeniden yazmadan altı kuralı yeniden sıralamak alan doğruluğunda 3,40 ve tam eşleşmede 9,20 puana mal oldu — gürültü tabanının yaklaşık altı katı — ve gerilemenin tamamı tek bir alanda oturdu, day 91’den 74’e düştü. Prompt’un bir arayüzü yok, dolayısıyla hiçbir düzenlemesinin yerel olduğu kanıtlanamaz.
Yalnızca bir toplam değil, alan bazlı sayılar raporlayın. 40 maddelik bir incelemede her iki prompt altında da yanlış olan her day tutarın baştaki rakamlarıydı: model bir alanı bir diğerine sızdırıyor ve amount kuralını day kuralının üstüne taşımak bunu üçe katladı. Toplam bir salınım gösterdi; döküm bir mekanizma gösterdi ve yalnızca bir mekanizma teste dönüşür.
Eşiği olmayan bir kapı süitiniz büyüdükçe kötüleşir. Yeni puan ne zaman düşükse engellemek, hiçbir şey yapmayan değişikliklerin 20 maddede %22,9’unu ve 100 maddede %42,5’ini yanlışlıkla engelledi, çünkü tam beraberlikler yok oluyor ve karşılaştırma yazı tura atmaya yakınsıyor. 100 maddede 1 puanlık bir eşik %4,3 yanlış engelleme veriyor ve yeniden sıralanmış prompt’u hâlâ yeniden örneklemelerin %99,4’ünde yakalıyor.
Sıcaklık 0 yeniden üretilebilirlik sağlar, doğruluk değil. İki koşu madde bazında bayt bayt aynıydı — ama greedy kod çözme 95,20 aldı, 95,40–96,00 örneklenmiş aralığının tamamının altında ve baştaki rakam hatası hâlâ oradaydı. Ayrıca muhtemelen servis etmediğiniz bir yapılandırma.
Altın kümenin bir yaşam döngüsü var ve bayatlık sessiz. Gerçek arızalardan doğar, eldeki kolay örneklerden değil katmanlandırılarak örneklenir ve kişisel veri taşır. İçindekileri düzelttikçe kolaylaşır ve trafik altından kayar; dolayısıyla altı aydır değişmemiş bir küme kararlı değil bayattır — ve yine de yeşil bir onay işareti üretir.
Canlı trafiği katmanlar hâlinde puanlayın. Her şeyde bedava sinyaller — ayrıştırma oranı, reddetmeler, gecikme, araç hataları, tavana çarpmalar — sonra üç örtüşen örneklemde bir hakem: sabit tekdüze bir dilim, zaten yanlış görünen her şey ve seyreklerin katmanlandırılmış bir dilimi. O hakemi denetleyin ve sürümünü sabitleyip kaydedin, çünkü bir hakem yükseltmesi tüm seriyi kaydırır.
Kullanıcı geri bildirimi örnekler, ölçmez. A/B testleri ölçer, ama yavaş. Oylar kendi kendini seçen bir azınlıktan gelir ve hoşa giden cevapları ödüllendirir; onları puan olarak değil, vakaları yönlendirmek için kullanın. Bir A/B testi kullanıcıları rastgele böler; tek bir birincil metriği, koruma metriklerini ve durdurma kuralını önceden sabitler ve büyük bir örneklem gerektirir: %20’den bir puanlık bir değişim kol başına yaklaşık 24.600 kullanıcı ister; her gün yapılan on ara bakış ise %5’lik yanlış pozitif oranını yaklaşık %19’a çıkarır.
Üç kayma bir panoda birbirinin aynı görünür. Model kımıldadı, girdiler kımıldadı ya da sistem kımıldadı — yalnızca cevaplayan model ve girdi dağılımı ile ayrılabilirler ve ikisi de önceden kaydedilmeli. Önce dördüncü olasılığı eleyin: hiçbir şeyin kımıldamadığı ve metriğin gürültülü olduğu.