Model değişikliğini bağımlılık güncellemesi gibi test et

Bir mağazanın destek asistanı müşteri e-postalarına taslak yazıyor. Ekip promptu aylar önce o günkü modele göre ayarladı ve iade e-postalarında iade süresinin yazdığını tek tek kontrol etti. Ürün modeli sağlayıcının sürümsüz adıyla çağırıyor. Bir sabah sağlayıcı o adı yeni sürüme taşıyor. Kodda tek satır değişmiyor, kimse bir değişiklik isteği açmıyor. Birkaç gün sonra bir müşteri, iade süresini yazmayan bir e-postayı şikâyete çeviriyor.

Yeni model çoğu işte eskisinden iyi. Yalnız bir vaka grubunda, eskisinin her seferinde yazdığı politika maddesini zaman zaman atlıyor. Bunu kimse ölçmemişti, çünkü kimse modelin değiştiğini bilmiyordu.

Kod kütüphanesi güncellenirken ekip kilit dosyasına, değişiklik notuna ve test sonucuna bakar. Model güncellemesi çoğu zaman bunların hiçbirinden geçmez: sağlayıcı bir takma adı taşır ya da biri model adını “yenisi daha iyi” diye değiştirir. Ürünün davranışını en çok belirleyen bağımlılık model. Sürümü kilitlenmemiş ve testten geçmemiş bir bağımlılık, ürünü ekibin haberi olmadan değiştirir.

Yeni model iyileştirme diye gelir ve iyileştirme test edilmez. Sağlayıcı yeni sürümü daha yüksek puanlarla duyurur, ekip de yükseltmeyi bedava bir kazanç sayar. Yazılımcının kütüphane güncellemesine gösterdiği kuşku model güncellemesinde devreye girmez.

Model aynı promptu başka okur. Ekibin promptu eski modelin onu nasıl okuduğuna göre ayarlanmıştır. Sclar ve arkadaşları prompt biçimine duyarlılığı ölçtüklerinde bir biçimin bir modeldeki başarısının başka bir modeldeki başarısıyla ancak zayıf bir ilişki gösterdiğini¹ buldu. Bir modelde iyi çalışan prompt ötekinde aynı sonucu vermeyebilir.

Üçüncü neden ölçümde. Değerlendirme seti yüzlerce vakanın ortalamasını verir. Yeni model ortalamada önde olup aynı anda eskisinin hep geçtiği bir vaka grubunda düşebilir. Ortalama bu düşüşü yükselişin içinde saklar. Ton, biçim ve kullanıcıya hak verme gibi davranışlar hiç ölçülmüyorsa düşüş panoda hiç görünmez.

Model değişikliği bir bağımlılık güncellemesi gibi ele alınır. Sürümü kilitlidir, kendi değişikliği olarak gelir ve eskisinin geçtiği testlerden geçmeden kullanıcıya ulaşmaz.

1. Sürümü kilitle. Ürün modeli sağlayıcının sabit sürüm adıyla çağırır. Sağlayıcının yeni sürüme taşıdığı takma ad, kilit dosyası olmayan bir bağımlılıktır. Yükseltme kendi değişiklik isteğiyle gelir ve hangi sürümden hangisine, neden geçildiğini yazar.
2. Eskisinin geçtiğini yeniden koştur. Ürünün gerçek işinden seçilmiş vakalar ve her birinde beklenen davranış bir regresyon seti kurar. Yeni model eskisinin geçtiği her vakada yeniden koşar. Rapor ortalamayı da verir, ama asıl satırı düşen vakaların adlı listesidir.
3. Davranışı ayrıca ölç. Doğruluğun yanında biçim, uzunluk, ret oranı, araç çağırma ve kullanıcıya hak verme eğilimi iki model için yan yana durur. Kullanıcı ilk bunları fark eder.
4. Promptu yeni modelle birlikte sına. Değerlendirme modeli tek başına koşturmaz, ürünün kullandığı prompt ve araçlarla birlikte koşturur.
5. Kademeli yay, geri dönüşü hazır tut. Yeni model önce trafiğin küçük bir payına açılır. Eski model aynı ayarla hazır bekler. Düşüş görülürse dönüş tek adım sürer.
6. Kilitli sürümü de izle. Sabit sürüm adı modelin ağırlıklarını sabitler, etrafındaki altyapıyı sabitlemez. Regresyon seti değişiklik anında koştuğu gibi düzenli aralıkla canlı sistemde de koşar.

Yeni modelin ortalamada daha iyi olmasına kimse itiraz etmez. Desen, hangi vakada daha kötü olduğunu kullanıcıdan önce öğrenmeyi ister.

Aynı güncelleme, iki sürüm hattı. Soldaki modeli sağlayıcının takma adıyla çağırıyor ve ortalama puan yükselince trafiğin tamamını yeni modele veriyor. Sağdaki değişikliği sabit sürüm adlarıyla kendi isteğinde getiriyor, eski modelin geçtiği vakaları tek tek koşturuyor ve düşüşü küçük bir trafik payında yakalayıp yayını durduruyor.

Sağlayıcılar kilitlemenin aracını veriyor. OpenAI'ın model sayfaları her modelin sabit sürümlerini (snapshot) listeliyor ve amacını tek cümleyle söylüyor: sabit sürüm modelin belirli bir sürümüne kilitlenmeyi² sağlıyor, böylece performans ve davranış tutarlı kalıyor.

Anthropic'in belgesine göre her Claude model kimliği sabit bir sürümü gösteriyor ve kimliğin ömrü boyunca altındaki model aynı kalıyor³. Aynı belge sınırı da yazıyor. Ağırlıklar sabit, ama modelin etrafındaki sunum altyapısı değişebiliyor ve bu değişiklikler kimlik aynı kalsa da gözlenen davranışta küçük farklar yaratabiliyor.

Google'ın Gemini API belgesi iki yolu yan yana koyuyor. Sabit modeller genelde değişmiyor ve canlıdaki uygulamaların çoğuna belirli bir sabit model öneriliyor. “latest” takma adı ise o model ailesinin her yeni sürümüyle değiştiriliyor⁴. Geriye uyumsuz değişikliklerde Google, takma adın arkasındaki sürümü değiştirmeden iki hafta önce e-postayla haber veriyor.

Kilit sağlayıcının işi, test senin işin. Sabit sürüm yalnız yükseltmenin ne zaman olacağına senin karar vermeni sağlar. O gün geldiğinde neyin bozulduğunu söyleyecek olan kendi regresyon setin.

GPT-4o, Nisan 2025. OpenAI 25 Nisan'da ChatGPT'deki GPT-4o'ya bir güncelleme çıkardı ve modelin belirgin biçimde dalkavuklaştığını görünce geri aldı. Şirketin sonraki açıklaması inceleme sürecini anlatıyor: çevrimdışı değerlendirmeler, uzmanların elle kontrolleri, güvenlik değerlendirmeleri ve küçük bir kullanıcı grubuyla A/B testi. Bu güncellemede çevrimdışı değerlendirmeler “generally looked good”⁵, A/B testi de modeli deneyen az sayıda kullanıcının onu beğendiğini gösteriyordu. Bazı uzman test edenler modelin davranışının biraz tuhaf geldiğini, kendi sözleriyle “felt” slightly off⁵ olduğunu söylemişti. Dağıtımda dalkavukluğu izleyen ayrı bir değerlendirme yoktu. OpenAI olumlu sinyallere bakıp yayına çıktı ve bunu sonradan yanlış karar diye niteledi. Şirketin tespitine göre çevrimdışı değerlendirmeler “weren’t broad or deep enough to catch sycophantic behavior”⁵, A/B testleri de bu davranışı gösterecek doğru sinyalleri taşımıyordu. OpenAI bundan sonra davranış sorunlarını, A/B sonuçları iyi görünse bile yayını durduran sorunlar sayacağını yazdı.

Anthropic, Ağustos-Eylül 2025. Bu kez model değişmedi. Üç altyapı hatası Claude'un cevap kalitesini aralıklı olarak düşürdü, model adları aynı kaldı. En kötü saatte Sonnet 4 isteklerinin %16'sı⁶ etkilendi. Anthropic'in doğrulama süreci elle kontrolleri ve değişikliği önce küçük kanarya gruplarına açmayı da içeriyordu. Şirketin kendi cümlesiyle, koştuğu değerlendirmeler kullanıcıların bildirdiği bozulmayı yakalamadı⁶. Çıkardığı derslerden biri, kalite değerlendirmelerini canlı sistemde sürekli koşturmak.

Chen, Zaharia ve Zou aynı adla sunulan modellerin zaman içinde nasıl değiştiğini dışarıdan ölçtü. GPT-4'ün Mart 2023 sürümü bir sayının asal olup olmadığını %84 doğrulukla⁷ bulurken Haziran sürümü aynı sorularda %51'e⁷ indi. GPT-4 de GPT-3.5 de Haziran'da kod üretirken daha çok biçim hatası yaptı. Yazarlara göre modellerin ne zaman ve nasıl güncellendiği dışarıdan görünmüyordu ve GPT-4'ün kullanıcı talimatlarına uyma becerisinin azalması, gözlenen davranış kaymalarının ortak nedenlerinden biriydi.

İlk iki örnek sağlayıcıların kendi süreci, üçüncüsü iki model ve sınırlı bir görev setiyle yapılmış bir ölçüm. Hiçbiri senin ürününde model değişikliğinin ne sıklıkla regresyon getirdiğini söylemez. Gösterdikleri şu: ortalamaya bakan süreç, en iyi donanımlı ekiplerde de davranıştaki düşüşü kaçırdı.

• 25 Nisan 2025OpenAI, kullanıcıyı memnun etmek için onaylayan GPT-4o güncellemesini geri aldı
• 5 Ağustos 2025Üç altyapı hatası Claude'un cevaplarını model adları değişmeden bozdu

• Düşen vaka listesi. Her model değişikliğinde eski modelin geçip yenisinin düştüğü vakaları adıyla say. Hedef sıfır ya da her biri için yazılı bir karar.
• Takma adla yapılan çağrı. Kodda sağlayıcının yeni sürüme taşıyabileceği adla yapılan model çağrıları. Hedef sıfır.
• Canlıda bulunan regresyon. Şikâyetten ya da destek talebinden çıkan, model değişikliğine bağlı hatalar. Regresyon seti yakalayamadıysa vakayı sete ekle.
• Geri dönüş süresi. Düşüşün görüldüğü andan eski modelin bütün trafiği yeniden aldığı ana kadar geçen süre.
• Davranış farkı. Biçim, uzunluk, ret oranı ve kullanıcıya hak verme eğilimini eski ve yeni model için ayrı raporla.

Üç metin var. Denetim promptu ürünündeki model çağrılarını bulur. Model adının sabit sürüm mü takma ad mı olduğuna, model değişikliğinin canlıya hangi yoldan çıktığına ve değerlendirmenin düşen vakaları ayrıca gösterip göstermediğine bakar, yalnız rapor yazar. Uygulama promptu model adlarını tek yerde kilitler, eski ve yeni modeli aynı setle koşturan bir CI adımı ve kademeli yayın ekler. Önce planı gösterir, onayınla uygular ve takma ad kullanıldığında başarısız olan bir test yazar. Kural kodlama ajanının kendi çalışması için. Senin ajanın da model adını değiştirdiğinde ortalamayla yetinmesin, düşen vakayı göstersin.

Bu depoda bir dil modelini çağıran bir AI özelliği var. Görevin, model değişikliklerinin bir bağımlılık güncellemesi gibi kilitlenip test edilip edilmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Model çağrılarını bul: SDK çağrıları, model adını taşıyan yapılandırma dosyaları, ortam değişkenleri, model yönlendiricileri. Her çağrıda model adı sabit bir sürüm mü (tarih ya da sürüm taşıyan), yoksa sağlayıcının yeni sürüme taşıyabileceği bir takma ad mı ("latest", sürümsüz ad)? Sağlayıcının belgesine bakmadan karar verme, emin değilsen "belirsiz" yaz.
2. Model adı nerede tanımlı: tek yerde mi, dağınık mı? Değiştirmek kod incelemesinden geçiyor mu, yoksa bir panel, veritabanı satırı ya da ortam değişkeniyle mi değişiyor?
3. Değerlendirme seti var mı (eval, golden set, fixture, anlık görüntü testi)? Vakalar gerçek kullanımdan mı alınmış? Her vakada beklenen davranış yazılı mı? Model adı değiştiğinde set CI'da kendiliğinden koşuyor mu?
4. Değerlendirme raporu vaka vaka mı, yalnız ortalama mı? Eski modelin geçip yenisinin düştüğü vakalar ayrıca listeleniyor mu?
5. Biçim, uzunluk, ret, araç çağırma ve kullanıcıya hak verme gibi davranışlar ayrıca ölçülüyor mu, yoksa yalnız doğruluk mu?
6. Promptlar belirli bir modele göre mi ayarlanmış? Model değişince prompt da yeni modelle birlikte sınanıyor mu?
7. Yeni model kademeli açılabiliyor mu (özellik bayrağı, trafik payı)? Eski modele tek adımda dönülebiliyor mu?
8. Aynı set canlı yapılandırmayla düzenli aralıkla koşuyor mu, yoksa yalnız değişiklik anında mı? Puanlayıcı olarak bir model kullanılıyorsa onun sürümü kilitli mi?

Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, olası sonuç (örnek: sağlayıcı takma adı yeni sürüme taşıyınca kimse fark etmeden iade e-postalarındaki politika maddesi düşer) ve önerdiğin düzeltme. Bulguları kullanıcıya en çok dokunan akıştan başlayarak sırala.

Bu depodaki AI özelliğine "model değişikliğini bağımlılık güncellemesi gibi test et" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Model adlarını tek bir yapılandırma dosyasında topla ve her birini sağlayıcının sabit sürüm adıyla yaz. Takma ad kullanılan yerleri listele ve değiştir.
2. Model değişikliği yalnız bu dosyadaki bir değişiklikle olsun. Değişiklik isteği eski ve yeni sürüm adını ve gerekçeyi yazsın, prompt ya da kod değişikliğiyle karışmasın.
3. Gerçek kullanımdan bir regresyon seti kur ya da var olanı kullan. Her vaka girdi, beklenen davranış ve kontrol taşısın: birebir eşleşme, kural ya da puanlayıcı model.
4. Model değiştiğinde seti eski ve yeni modelle koştur. Raporda ortalamanın yanında eskisinin geçip yenisinin düştüğü vakaları adıyla listele. Listede vaka varsa CI'ı durdur, kararı insana bırak.
5. Biçim, uzunluk, ret oranı ve araç çağırma gibi davranış ölçülerini iki model için yan yana raporla.
6. Yeni modeli bir özellik bayrağıyla trafiğin küçük bir payına aç. Eski modele tek adımda dönülebilsin.
7. Aynı seti haftada bir canlı yapılandırmayla koşturan bir iş ekle. Düşüş görürse haber versin.

Uygularken:
- Puanlayıcı model kullanıyorsan onun sürümünü de kilitle, yoksa ölçen şey de değişir.
- Çıktı belirlenimsiz olabilir. Her vakayı birden çok kez koştur ve sonucu oranla raporla.
- Bir test ekle: yapılandırmadaki model adını sürümsüz bir takma adla değiştir ve testin başarısız olduğunu doğrula. Bir de bilinen bir regresyonu taklit eden sahte bir model yanıtıyla raporun düşen vakayı adıyla gösterdiğini doğrula.

## Model değişikliği bir bağımlılık güncellemesidir
- Model adını sağlayıcının sabit sürüm adıyla yaz, yeni sürüme kendiliğinden geçen takma adı kullanma.
- Model adını değiştiren değişikliği prompt ya da kod değişikliğiyle aynı isteğe karıştırma. Ayrı yap, eski ve yeni sürümü yaz.
- Model değiştirdiğinde regresyon setini eski ve yeni modelle koştur ve düşen vakaları adıyla raporla.
- Ortalama puanın yükselmesini tek başına onay sayma.
- Düşen vaka varsa değişikliği canlıya alma, kararı bana bırak.

Tek kişilik bir prototipte ya da her çıktıyı bir insanın okuduğu bir denemede takma ad kullanmak makul. Bu desen, çıktı kullanıcıya ya da başka bir sisteme doğrudan gittiğinde gerekir.

Kilit yükseltmeyi erteler, ortadan kaldırmaz. Her model kimliğinin kendi emeklilik takvimi³ var ve kilitli ürün o tarihte yine yeni modele geçer. Regresyon seti hazır değilse ertelenen iş son gün aceleyle yapılır.

Regresyon seti her şeyi yakalamaz. OpenAI'ın değerlendirmeleri dalkavukluğu görmedi, Anthropic'inkiler altyapı hatalarını. Set canlıda bulunan her regresyonla büyür, uzmanların elle kontrolü de yanında durur. OpenAI'ın kendi dersi, nitel değerlendirmelerin işaret ettiği şeye daha dikkatle bakmak⁵, sayılar iyi görünse bile.

Her değerlendirme koşusu token ve zaman harcar. Model değişikliğinde tam set, aradaki günlerde küçük bir örneklem çoğu ürüne yeter.