Model, veri ve istem sürümlemesi kurmak

Sürümleme tartışması çoğunlukla "hangi modeli kullanıyoruz" sorusuyla başlar ve orada biter. Oysa üretimdeki çıktıyı belirleyen tek bir eksen değil; birbirinden bağımsız değişebilen en az beş eksen var ve bunların herhangi biri sessizce kaydığında sonucu kimse açıklayamıyor. İlk iş, bu eksenleri yazılı hâle getirmek ve her birinin sahibini belirlemek.

Beş ayrı sürüm alanını beş ayrı yerde tutmak, teoride yeterli görünür; pratikte bir olay incelemesinde bunları bir araya getirmek saatler alır. Koşu kimliği bu birleştirme işini önceden yapar: tek bir dizeyi arattığınızda hangi model, hangi istem, hangi veri ve hangi parametrelerle çalışıldığı tek kayıttan çıkar.

{
  "kosu_kimligi": "destek-yaniti-r7",
  "istem": {
    "dosya": "istemler/destek-yaniti.md",
    "surum": "g:9f2ab41"
  },
  "model": {
    "saglayici": "<saglayici-adi>",
    "cozulmus_kimlik": "<takma-ad-degil-cozulmus-kimlik>",
    "sicaklik": 0.2
  },
  "veri": {
    "anlik_goruntu": "bilgi-tabani-2026-09-14",
    "icerik_ozeti": "sha256:<ozet>"
  },
  "dizin": {
    "gomme_modeli": "<gomme-model-kimligi>",
    "dizin_surumu": "idx-14"
  }
}

Doğrulama adımı: hâlihazırda çalışan bir yapılandırmayı elinize alın ve eksen listesindeki her eksenin kimlik kaydında bir karşılığı olduğunu tek tek görün. Karşılığı bulunmayan eksen, kimliğe eklenmesi gereken alandır. Bu denetimi kimliği üretim kaydına iliştirmeden önce yapın; sonraya bırakmak, dolmuş kayıtların üstünde şema değişikliği demektir.

Doğrulama adımı: rastgele bir üretim kaydı seçin, koşu kimliğini alın ve yalnızca bu kimlikle çalışarak ortamı yeniden kurmayı deneyin. Eksik kalan her alan, kimliğe eklenmesi gereken bir eksendir.

Veri sürümlemesinin en yaygın yanılgısı, veriyi tarihle etiketlemenin yeterli olduğunu sanmaktır. Kaynak tablo değiştirilebilir olduğu sürece "14 Eylül verisi" ifadesi bir sürüm değil bir niyet beyanıdır: geriye dönük bir düzeltme yapıldığında aynı tarih artık aynı satırları göstermez. Sürüm, içeriğin kendisinden türeyen bir özet olmalı.

• Satır kümesi: hangi kayıtların dâhil olduğu, kimliğiyle sabit.
• Şema: alan adları ve tipleri; şema değişimi de sürüm değişimidir.
• Filtre: hangi koşulla süzüldüğü, sorgunun kendisi dâhil.
• Kesim anı: verinin hangi ana kadar okunduğu.
• İçerik özeti: yukarıdakilerden üretilen ve karşılaştırılabilir tek değer.

Ödünleşim şurada: tam kopya almak depolama maliyeti üretir, yalnızca kimlik listesi tutmak ise kaynak silindiğinde yeniden üretilemez hâle gelir. Karar ölçütü basit — veri kümesini yeniden üretmek zorunlu bir yükümlülükse tam kopya, yalnızca karşılaştırma yapacaksanız kimlik listesi ve özet yeter.

Panelden düzenlenen istem, üç şeyi birden kaybettirir: değişiklik farkı, inceleme ve geri alma. Bunların üçü de kod deposunda bedava geliyor. İstemi depoya taşımanın maliyeti bir günlük iş; panelde bırakmanın maliyeti, ilk ciddi olayda "dün ne yazıyordu" sorusuna cevap verememek.

• Sistem istemi ve rol tanımı.
• Araç adları, açıklamaları ve parametre şemaları — model davranışını istem kadar etkiler.
• Beklenen çıktı şeması veya biçim talimatı.
• Örnek (few-shot) blokları ve seçilme kuralı.
• Kaçış metni: modelin cevap veremediğinde ne diyeceği.

Takma adlar — "en yeni", "kararlı", "varsayılan" gibi işaretçiler — geliştirme hızını artırır ama sürüm kaydını çürütür. Kayda takma adı yazdığınızda, aylar sonra o kaydın hangi modeli gösterdiğini söyleyemezsiniz. Doğrusu, çağrı anında takma adın çözüldüğü kimliği okuyup kendi tablonuza yazmak.

Doğrulama adımı: aynı isteği birkaç hafta arayla koşturup kaydedilen çözülmüş kimlikleri karşılaştırın. Kimlik değişmişse, sizin hiçbir değişiklik yapmadığınız bir sürüm geçişi yaşanmış demektir ve değerlendirme sonuçlarınız artık aynı sistemi anlatmıyor.

Sürümleme, laboratuvarda değil üretim kaydında işe yarar. Bir kullanıcı "model saçmaladı" dediğinde elinizde yalnızca zaman damgası varsa, o anda hangi istem ve hangi model sürümünün çalıştığını tahmin etmek zorunda kalırsınız. Koşu kimliği bu tahmini ortadan kaldırıyor.

1. 1Şikâyet gelir

   Kullanıcı veya destek ekibi bir yanıt kimliğiyle birlikte kaydı açar.

2. 2Yanıt kaydı okunur

   Kayıttaki koşu kimliği alınır; metin içeriğine bakmaya gerek kalmaz.

3. 3Bileşen sürümleri çözülür

   Model künyesi, istem sürümü, veri anlık görüntüsü ve dizin sürümü tek sorguda gelir.

4. 4Ortam yeniden kurulur

   Aynı bileşenlerle koşu tekrarlanır; davranış üretilebiliyorsa sorun yapılandırmadadır.

5. 5Karar verilir

   Düzeltme mi geri alma mı gerektiği, tahmine değil yeniden üretime dayanır.

Kapının işlevi kalite ölçmek değil, ölçülmemiş bir değişikliğin yayına geçmesini engellemek. Bu ayrım önemli: kapı, değerlendirme kümesinin kendisinden bağımsız olarak, kaydın eksiksiz olduğunu ve karşılaştırmanın yapıldığını doğrular. Kapıyı elle çalıştırılan bir kontrol listesi olarak kurarsanız, yoğun bir haftada atlanır.

1. 01Hangi eksenlerin değiştiği otomatik çıkarıldı mı?
2. 02Yeni koşu kimliği üretildi ve bütün alanları dolu mu?
3. 03Değerlendirme kümesi hem eski hem yeni sürümde koşturuldu mu?
4. 04Sonuç farkı, kabul edilebilir aralık olarak önceden yazılmış eşiklerle karşılaştırıldı mı?
5. 05Geri dönülecek önceki koşu kimliği kayıtlı mı?

Geri alma, yazıldığında kolay görünen ama denenmediğinde neredeyse hiç çalışmayan bir yetenektir. Tatbikatın amacı, geri almanın mümkün olduğunu kanıtlamak değil; hangi adımın elle müdahale gerektirdiğini ve toplam sürenin ne olduğunu ortaya çıkarmak. Bu iki bilgi olmadan bir olay sırasında "geri alalım" demek bir plan değil bir temennidir.

1. 1Hedef kimliği seç

   Bilinen iyi durumdaki koşu kimliğini kayıttan al.

2. 2Bileşimi bütün olarak uygula

   Model, istem, veri ve dizin sürümlerini tek paket hâlinde geri yükle.

3. 3Uyumu doğrula

   Gömme modeli değişmişse dizinin de geri alınması gerekir; vektörler aynı uzayda değildir.

4. 4Duman testi koştur

   Küçük bir sorgu kümesiyle sistemin yanıt ürettiğini ve biçimin doğru olduğunu gör.

5. 5Süreyi yaz

   Baştan sona geçen dakikayı kaydedin; olay planındaki gerçekçi hedef budur.