İstek kapısında yeni bilgi
llama.cpp kullanan bir uygulama, modelin adını öğrenmekle artık yetinmek zorunda değil. 0.6.0 sürümünde sunucunun model listesi, desteklenen girdi ve çıktı türlerini bir mimari nesnesi içinde bildiriyor. Metinle birlikte görüntü gönderen istemci açısından değişen yer tam burası: isteği hazırlayan yazılım, karşıdaki modelin hangi tür girdiyi kabul ettiğini sorgulayabiliyor. Aynı sürüm, gömme vektörü üreten arayüze türü açıkça belirtilmiş görüntü, ses ve video girdileri ekliyor. Gömme vektörü, veriyi sayısal bir temsile dönüştüren çıktı; bu yolun sohbet yanıtıyla aynı iş olduğu varsayılamaz.[1]
Bu bilgi, bir entegrasyon kararını uygulamanın içinde tutulan model adları listesinden sunucuyla yapılan görüşmeye taşıyor. İstemci, kendi görevine uygun girdi türünü model adından tahmin etmek yerine arayüzün verdiği özelliklere bağlayabilir. Buradaki kazanç, uygulamanın hangi istek yolunu seçtiğinin daha açık hale gelmesi. Bunun bedeli de istemcinin yeni alanları gerçekten kullanması: eski bir istemci bu bilgiyi okumadığında karar hâlâ kendi içinde kalıyor. Model değiştirme özgürlüğünün pratik sınırı, isim listesinden çok bu özellik sözleşmesine uyumda yatıyor.[1]
İçeride değişen veri yolu
Sunucuya gelen isteğin altında ikinci bir değişiklik var. Yeni genişletilmiş toplu işleme arayüzü, belirteçler ile gömme vektörlerini birlikte taşıyor ve belirteç başına ek durum alıyor. Örnek uygulamalar, tahmine dayalı çözümleme, çoklu ortam araçları ve sunucu bu arayüze taşınmış. Yani değişiklik yalnızca bir dış uç noktaya eklenen seçenekten ibaret değil; projenin kendi istemcileri de yeni veri yoluna geçmiş durumda. Geliştiricinin sürüm notlarında izleyebildiği somut ayrım, kabul edilen içeriğin nasıl bir işleme girdisine dönüştüğü.[1]
Entegrasyonu yöneten ekip için çalışma alanı, modeli seçmekten girdinin içinden geçtiği yolu sahiplenmeye genişliyor. Sunucunun yeni özellikleri bildirmesi ile iç arayüzün değişmesi aynı isteğin farklı aşamalarına dokunuyor. Hazır sunucuyu kullanan uygulama dış sözleşmeye odaklanabilir; kitaplık düzeyinde entegrasyon yapan ekip ise toplu işleme arayüzünü de kendi koduyla buluşturmak durumunda. Kontrolün daha fazla katmanını elinde tutmak, değişiklikleri inceleme işini de o katmanlara dağıtıyor. Bu ayrım, hazır bir hizmet kullanmakla yerel çalışma düzenini sürdürmek arasındaki gerçek iş bölümünü görünür kılıyor.[1]
Oturumun kaldığı yer
İsteğin yolu, yanıt üretildikten sonra da devam ediyor: oturumun durumu saklanıyor ve daha sonra geri yükleniyor. Bu sürümde oturum biçiminin sürüm değeri 11’e, dizi durumunun değeri 4’e çıkıyor. Başarısız geri yüklemeden sonra temizleme ve önbellek rotasyonu uyuşmazlığına ilişkin düzeltmeler de var. Sunucu eksik çoklu ortam girdisini reddediyor. Bu değişiklikler, yalnızca hangi modelin çalıştığını değil, yarım kalmış bir isteğin veya saklanmış durumun hangi koşullarda tekrar ele alındığını da entegrasyonun parçası yapıyor.[1]
Yerel model çalıştırmanın kontrolü böylece somut bir bakım sorumluluğuna bağlanıyor. Aynı ekip girdi yolunu, sunucu özelliklerini ve saklanan durumu yönetiyorsa sürüm geçişi bu üç noktayı birlikte ele almayı gerektiriyor. Hazır sunucu kullanan ve oturum saklamayan bir uygulamada yük daha dar kalabilir. Benim bu sürümden çıkardığım karar ölçüsü şu: yerel çalışmayı seçerken yalnızca çalıştırılabilen modelleri saymak yerine uygulamanın hangi arayüzlere ve durum biçimlerine sahip çıktığını belirlemek. Bu sahiplik açık olduğunda, yeni bir sürümün devraldığı iş ile ekibin üstlendiği bakım işi aynı akışta görülebiliyor.[1]