Bir dokümantasyon asistanı, erişim sisteminde yapılan rutin bir değişikliğin ardından, model aynı kalmasına, hizmetin sağlıklı olmasına ve dağıtım kontrollerinin başarıyla tamamlanmasına rağmen süre sınırı içinde yanıt vermeyi durdurabilir. Bunun nedeni, değişikliğin modele daha büyük bir bağlam göndermesi; bunun da üretimi uzatıp çıkarım sunucusunun önünde istek birikimini artırması olabilir. Oysa uygulama konteynerinin geri alınması, başka bir yerde değiştirilen erişim ayarlarını geri getirmeyebilir.
Bu varsayımsal senaryo, yapay zekâ uygulamalarının işletilmesindeki pratik bir sorunu açıklıyor: Gerçekte ne dağıtıldı? Üretici uygulamalarda sistemin davranışını tek başına model sürümü belirlemez; girdiler, ön işleme, istemler, dizin, gömme modelleri, araç sözleşmeleri ve hizmet ayarları birbirinden bağımsız şekilde değişebilir.
Sürüm sınırlarını netleştirin
Makale, birlikte test edilen tüm bileşenlere ait referansları saklayan sürümlenmiş bir bildirimle başlanmasını öneriyor. Bu bildirim; sürüm tanımlayıcısını, uygulama sürümünü, model sürümünü, istem sürümünü, dizin sürümünü, gömme sürümünü, parçalama ve yeniden sıralama işlem hattını, çalışma ayarlarını, değerlendirme kümesini ve ayrıca önceki sürümü içerebilir.
Bu referanslar incelenebilir ve saklanmış ayarlara veya öğelere işaret etmelidir; gizli bilgilerin değerleri yerine gizli bilgi referansları saklanmalıdır. Çalışma sürümü; belirteç sınırlarını, toplu işlemeyi, zaman sınırlarını ve kaynak dağılımını kapsamalıdır. Araç çağıran uygulamalar ise araç şemalarının ve dönüştürücülerin sürümlerini içermelidir.
Bu bildirim, birebir yeniden üretilebilirliği garanti etmez; dış hizmetler değişebilir, üretim deterministik olmayabilir ve bazı sağlayıcılar sabit model anlık görüntüleri sunmaz. Bu nedenle söz konusu kısıtlar, veriler sürekli değiştiğinde verilerin yakalanma zaman noktası ve dizinleme ayarlarıyla birlikte kaydedilmelidir. Birden fazla ayar deposunu art arda güncellemek atomik bir sürüm oluşturmaz.
Yalnızca model çağrısını değil, görevin tamamını test edin
Bir isteğin HTTP üzerinden başarılı olması, kullanıcının doğru bir yanıt aldığı anlamına gelmez. Değerlendirme kapısı, erişilebilir bir kaynağa atıf yapma, doğru ürün sürümünü dikkate alma ve kanıt bulunmadığında talimat uydurmaktan kaçınma gibi ürün görevlerinin kendisini ölçmelidir.
Makale; normal soruları, önceki başarısızlıkları, belirsiz istekleri, kanıt bulunmayan durumları ve yetki sınırlarını aşma girişimlerini içeren sürümlenmiş bir veri kümesi oluşturulmasını, ayrıca ayarlama için kullanılmamış bir kümenin saklanmasını öneriyor. Şema doğruluğu, araç bağımsız değişkenleri, atıf tanımlayıcıları ve yetki uygulaması için deterministik kontroller uygulanabilir. Anlamsal değerlendirmeler ise açık bir ölçüt ve insan incelemesi gerektirir; başka bir modelin değerlendirmesi durumları sıralamaya yardımcı olabilir, ancak referans gerçekliği değildir.
Sürüm, erişimden üretime ve çıktı doğrulamasına kadar uçtan uca çalıştırılmalı, ardından sonuçlar girdi uzunluğu, diller, ürün sürümleri ve kanıtların yetersiz olduğu durumlar gibi önemli dilimlere göre incelenmelidir. Ayrıca kabul ölçütleri aday sürüm görülmeden önce belirlenmelidir; bunlar arasında hiçbir yetki ihlaline izin verilmemesi, kalite gerilemesi sınırları ve yanıt süresi ile maliyet bütçeleri bulunur.
İş yükünü ve maliyeti kullanıcının gördüğü şekilde ölçün
Yalnızca saniyedeki istek sayısını test etmek yeterli değildir. Testler girdi ve çıktı uzunluklarına, eşzamanlılık düzeylerine, erişim patlamalarına ve sıcak ve soğuk bellek davranışına dağıtılmalıdır. Akışlı yanıtlarda ilk belirtecin ortaya çıkma süresi, sonraki belirteçlerin hızı ve tamamlama süresi birbirinden ayrılmalı; kuyrukta bekleme süresi de ölçülmelidir.
Makale, önce isteklerin uçtan uca izlerinin alınmasını, ardından erişim, yeniden sıralama, kuyruklar, başlatma ve üretim aşamaları ile sonraki çağrıların incelenmesini öneriyor. Farklı aşamalardaki yüzdelik değerler toplanıp tek bir kapsamlı yüzdelik olarak kabul edilmemelidir; çünkü her ölçüm farklı istekleri tanımlayabilir.
Aynı kimlik sürümle birlikte izlerde ve yapılandırılmış istek günlüklerinde ilişkilendirilmeli; kalite, yanıt süresi dağılımları, hatalar, belirteç kullanımı ve alternatif yollara yönlendirme oranları takip edilmelidir. İstek başına daha düşük maliyet, tamamlanan görev için mutlaka daha düşük maliyet anlamına gelmez. Bu nedenle makale, başarısız denemeleri de hesaba katarak başarılı görevin maliyetinin hesaplanmasını ve başarı için alternatif göstergeler kullanıldığında bunun açıkça belirtilmesini öneriyor.
Geri alma işlemi yalnızca model ağırlıklarını değil, bağımlılıkları da geri getirir
Aday sürüm, mevcut sürüm kullanılabilir durumda tutulurken trafiğin sınırlı bir oranına sunulabilir; ancak aşamalı testin başarılı olması, aday ve kontrol sürümüne ait sinyallerin karşılaştırılmasını ve adayın önemli yük dilimlerine maruz kalmasının güvence altına alınmasını gerektirir. Karar sahibinin, durdurma koşullarının ve asgari gözlem süresinin belirlenmesi, ayrıca dağıtım başlamadan önce geri yükleme işleminin gerçekleştirilmesi gerekir.
Aday sürüm erişim dizinini yerinde değiştirdiyse, istekleri eski bir uygulama görüntüsüne yönlendirmek yeterli olmaz. Uyumlu dizin sürümlerinin saklanması veya geri alınabilir bir geçiş tasarlanması gerekir; mevcut silme ve yetki iptali işlemleri de dikkate alınmalıdır. Ayrıca e-posta gönderme veya kayıtları değiştirme gibi araçların yan etkilerini, uygun yineleme kapasitesi ve onay sınırları kullanarak koruyacak bir politika oluşturulmalı; devam eden üretimlerin tasfiyesi veya iptali için de bir politika belirlenmelidir.
Bu yaklaşım neden önemlidir?
Bu önerilerin pratik değeri, yapay zekâ uygulamalarının yönetimini «Hangi modeli kullanıyoruz?» sorusundan daha geniş bir soruya taşımasıdır: Kötü bir yanıt üreten tam sürüm belirlenebilir mi ve bilinen, uyumlu bir sürüm geri getirilebilir mi? Bu, yararlı asgari yapının mevcut bir depo içinde bulunabileceği ve bir sürüm bildirimi, bir değerlendirme görevi, temsili bir yük testi, sürümle ilişkilendirilmiş izler ve fiilen uygulanmış bir geri alma eğitimi olmak üzere beş bileşenden oluşabileceği anlamına gelir.
Kısıtlar da açıktır: Sınırlı bir test kümesini geçmek, güvenlik açıklarının veya nadir başarısızlıkların bulunmadığını kanıtlamaz; ayrıca üretim geri bildirimleri seçicidir ve her zaman yanıtın doğruluğuna eşit değildir. Bu nedenle insan incelemesi ve uygulama, platform ve veri arasındaki temas noktalarında sorumlulukların belirlenmesi, tamamen otomatikleştirilebilecek ekler değil, işletim mimarisinin bir parçası olmaya devam eder.