İşe yarayanı bozmadan dil modeli nasıl değiştirilir?

Model sağlayıcıdan gelen bildirim kısa ve naziktir. Müşteri e-postası asistanınızın üzerinde çalıştığı model kullanımdan kaldırılacak ve belirtilen bir tarihten sonra bu modele giden istekler çalışmayacaktır. Önerilen yeni modelin daha iyi olduğu söyleniyor. Sizin vakalarınızda daha iyi olup olmadığını ise henüz kimse söyleyemez.

Bu bildirim gelecek; fiyat değişiklikleri ve daha iyi seçenekler de. Dil modeli değiştirmeyi ilk günden planlayın. Değerlendirme seti, modelden bağımsız bir katman ve paralel çalıştırmalarla geçiş, gözü kapalı atılan bir adım değil, bir test sonucu olur.

Modeli neden birden fazla kez değiştireceksiniz?

Çünkü değiştirme nedenleri dışarıdan, başkalarının takvimine göre gelir:

• Kullanımdan kaldırma bildirimleri. Sağlayıcılar eski modelleri kullanımdan kaldırır. Bildirim süresi, yol haritanızın ihtiyacına göre değil, sözleşme koşullarında ne yazıyorsa odur.
• Fiyat değişiklikleri. Daha ucuz bir model eşiklerinizi karşılar hale gelmiş olabilir ya da kullandığınız model pahalanabilir.
• Kalite kazanımları. Daha yeni ya da daha küçük bir model, kendi örneklerinizde zor vaka türlerinizi ya da Türkçe metinlerinizi daha iyi işleyebilir.
• Veri konumu (data residency). Verinin belirli bir bölgede, kendi bulutunuzda ya da kendi sunucularınızda işlenmesi gerekliliği, farklı bir sağlayıcı ya da açık ağırlıklı bir model anlamına gelebilir.

Yıllarca çalışan bir sistem bunların birkaçıyla karşılaşır. Model değiştirmeyi olağan bakım olarak görün ve sistemi buna göre tasarlayın.

Bir sistemi taşımayı ne kolaylaştırır, ne zorlaştırır?

Dört şey işi kolaylaştırır:

• Modelden bağımsız bir katman. Uygulama kodu, “yanıt taslağı oluşturma” ya da “fatura bilgisi çıkarma” gibi kendi arayüzünüzü çağırır; yapılandırma da her görevi bir modele, bir prompta ve ayarlara eşler.
• Model başına saklanan promptlar. Her görevin her model için sürümlenmiş bir promptu vardır; böylece yeni model, eskisini bozmadan kendine göre ayarlanmış bir prompt alır.
• Başlangıç ölçümü alınmış bir değerlendirme seti. “Bugünkü kadar iyi”nin ne demek olduğunu vaka türü vaka türü bilirsiniz.
• Kodda doğrulama. Çıktılar bir şemaya göre kontrol edilir; böylece bir biçim farkı ERP’de hatalı veri olarak değil, bir doğrulama hatası olarak ortaya çıkar.

İşi zorlaştıranlar ise şunlardır: koda işlenmiş, sağlayıcıya özgü özellikler; deneme yanılmayla ayarlanmış ve nedeni kayda geçmemiş promptlar; tek bir modelin ifade biçimine bağlı ayrıştırma ve başlangıç ölçümünün olmaması. İyi yapıldığında bir görevi başka bir modele taşımak, bir yapılandırma değişikliği ve bir test çalıştırmasından ibarettir.

Yeni model eskisiyle nasıl karşılaştırılır?

Adayları, mevcut modeli başlangıç ölçümü olarak alıp değerlendirme setinde yan yana çalıştırın: önce mevcut promptlarla, sonra her aday için uyarlanmış promptlarla. Kaliteyi, doğrulama hatalarını, görev başına maliyeti ve en yavaş isteklerin yanıt süresini vaka türüne ve dile göre ayırarak karşılaştırın.

Sonra ayrışmaları okuyun. Eski ve yeni modelin farklı yanıt verdiği vakalardan bir örneklem alın ve süreç sahibiyle inceleyin. Bazen yeni model haklıdır ve referans yanıt eskimiştir; bazen de ortalama iyileşirken önemli bir vaka türü sessizce kötüleşmiştir. Karşılaştırma, her vaka türü için bir tablo ve süreç sahibinin imzaladığı bir karar olduğunda tamamlanır.

Değerlendirme seti varsa geçiş gözü kapalı atılan bir adım değil, bir test sonucudur.

Model değişince promptlar neden değişmeli?

Çünkü modeller aynı kelimeleri farklı okur. Biri biçim talimatlarını daha harfiyen izler, bir diğeri daha uzun yanıtlar yazar, bir üçüncüsü örnekleri kopyalanacak şablonlar gibi görür. Reddetme davranışı, üslup ve belirsiz vakaların ele alınışı da değişir.

Değişiklikler promptla da sınırlı kalmaz. Çıktı ayrıştırma; farklı tarih biçimleri, alan sırası ya da kaçış karakterleri yüzünden bozulabilir. Araç çağırma kuralları farklıdır. Yanıt süresi, istek sınırları (rate limit) ve bağlam penceresi boyutu değişir; bu yüzden zaman aşımlarının ve toplu işlem boyutlarının ayarlanması gerekir. Her geçişte bunların hepsi için mühendislik zamanı ayırın; bu süre nadiren sıfırdır. Uyarlanan her promptu, kendi değerlendirme çalıştırmasına bağlı yeni bir sürüm olarak saklayın; promptları kod gibi sürümlemeyi anlatan notumuz bunu ayrıntılı açıklıyor.

Yeni bir model güvenle nasıl devreye alınır?

Aşama aşama; her aşamanın başlamadan önce yazılmış bir çıkış kriteri olur:

1. Çevrimdışı. Değerlendirme seti, önemli her vaka türünde anlaşılan eşikleri geçer.
2. Gölge mod. Yeni model canlı trafikte paralel çalışır; çıktıları kaydedilir ve karşılaştırılır, asla kullanılmaz.
3. Kademeli geçiş. Önce tek bir kuyruk, kanal ya da vaka türü geçer; bu sırada müdahale oranını ve doğrulama hatalarını izlersiniz. Ardından bir sonraki geçer.
4. Geri dönüş yolu açık tam geçiş. Eski yapılandırma, eski model gerçekten kullanımdan kalkana kadar hazır bekler; böylece geri almak bir yapılandırma değişikliğinden ibaret olur.

Kademeli geçiş sırasında her gün kullandığınız sinyalleri izleyin; bunları canlıdaki bir yapay zeka sisteminde neyin izleneceğini anlatan notumuzda bulabilirsiniz.

Temsili bir vaka olarak yukarıdaki kullanımdan kaldırma bildirimine dönelim. Ekip değerlendirme setini iki aday üzerinde çalıştırır: sağlayıcının önerdiği yeni model ve şirketin kendi bulutunda çalışan açık ağırlıklı bir model. Açık ağırlıklı model kalitede eşleşir ama uzun yazışmalarda yanıt süresi eşiğini kaçırır. Önerilen yeni model, Türkçe şikayet e-postaları dışında her yerde geçer; o e-postalardaki taslakları, üslup rehberinin izin verdiğinden daha katıdır. Ekip yalnızca o prompta doğru üsluba dair iki gerçek örnek ekler, seti yeniden çalıştırır ve geçer. Canlı e-postalarda gölge mod sonucu doğrular. Trafik kuyruk kuyruk taşınır; eski yapılandırma kullanımdan kaldırma tarihine kadar hazır tutulur.

Sözleşmeler ve mimari, kullanımdan kaldırılan modeller için ne söylemeli?

İmzalamadan önce bu soruları satın alma ekibine ve hukuk danışmanınıza götürün; çünkü yanıtlar sağlayıcıdan sağlayıcıya farklıdır ve zamanla değişir:

• Bir model kullanımdan kaldırılmadan ne kadar önce bildirim yapılıyor ve bu süre sözleşmede yazılı mı?
• Belirli bir model sürümüne sabitlenebiliyor musunuz ve bir model adının arkasındaki değişiklikler duyuruluyor mu?
• Veriler nerede işleniyor ve bölge ya da sağlayıcı değiştirirseniz ne değişir? Yanıtı veri koruma görevliniz (DPO) de görmeli.
• Ayrılırken yanınızda neleri götürebilirsiniz: kayıtları, değerlendirme sonuçlarını, ince ayar (fine-tuning) yapılmış bir modeli?

Mimaride katmanı, promptları ve değerlendirme setini kendi varlıklarınız olarak tutun, her önemli görev için test edilmiş bir yedek model belirleyin ve her kayıt satırına model kimliğini yazın.

Model değişikliği nasıl prova edilir?

En önemli yapay zeka görevinizi seçin ve bir deneme yapın: Görevi yapılandırma üzerinden ikinci bir modele yönlendirin ve değerlendirme setini çalıştırın. Bu bir öğleden sonranızı alıyorsa bir sonraki kullanımdan kaldırma bildirimine hazırsınız. Bir proje gerektiriyorsa o projeyi bildirim gelmeden yapın. Yapay zeka güvenilirliği hizmetimiz canlı sistemleri model değiştirmeye hazır tutar; bunu mümkün kılan modelden bağımsız katman ve değerlendirme seti ise veri ve yapay zeka altyapısı çalışmalarımızda kurulur.