Bir paketle iki sözleşme değişiyor
Python istemcisini 2.0.0 sürümüne yükselten bir takım, uygulamadaki model çağrısına dokunmasa da yeni bir API sözleşmesine geçiyor. Anthropic’in yeni ana SDK sürümleri, 2023-06-01 yerine 2026-10-21 başlığını gönderiyor. Bakım işinin ağırlığı burada değişiyor: bağımlılığın kurulmasıyla birlikte daha önce kabul edilmiş isteklerin biçimi de yeniden ele alınmalı. Geçiş kılavuzunun kod ile SDK değişikliklerini birlikte dağıtma önerisi, bu iki işin aynı teslimatta buluştuğunu açık ediyor.[1]
Örnekleme ayarları bunun elle tutulur örneği. Yeni sürümde temperature, top_p veya top_k göndermek, değer eski varsayılanla aynı olsa bile 400 hatası üretiyor. Çözüm, temperature alanını istekten çıkarmak; değeri 1 yapmak hatayı gidermiyor. Hiç ayar göndermeyen eski uygulama zaten aynı sıcaklık varsayılanını kullanıyordu. Bu ayrım, model davranışını değiştirmeyi amaçlayan bir denemeyle yalnızca geçersiz bir alanı temizleyen bakım işini birbirinden ayırmaya yarıyor.[1]
Konuşma geçmişi de çağrının parçası. Asistan mesajının doğrudan içindeki belge blokları kullanıcı mesajına taşınmak zorunda; araç sonucunun içindeki belgeler ise aynı yasak kapsamında değil. Bu nedenle yalnız kısa bir selamlaşmanın başarıyla dönmesi, belgeyle çalışan bir eylemcinin geçişini sınamaya yetmez. Bence uygun deneme birimi, geçmişiyle birlikte gerçek bir görev isteği. Bazı entegrasyonlar belgeleri zaten kullanıcı mesajında tuttuğundan etkilenmeyebilir; bu olasılık, her uygulamada aynı onarımın gerektiğini varsaymayı da engelliyor.[1]
Denemeyi ağ geçidinden geçir
İstek hizmete ulaşmadan önce başka bir sınırdan geçiyor: ağ geçidi. Yeni SDK, anahtarı Authorization başlığında Bearer değeri olarak gönderiyor. Claude API eski ve yeni başlığı kabul ediyor; yalnız X-Api-Key okuyan ara sunucu ise uyarlama gerektiriyor. API’nin iki biçimi de tanıması, aradaki yazılımın ikisini de tanıdığı anlamına gelmiyor. Dolayısıyla aynı uygulamanın doğrudan bağlantıda ve kurumun ağ yolu üzerinden ayrı sınanması, değişikliğin hangi katmana ait olduğunu görünür kılan bir karşılaştırma.[1]
Pratik bir geçiş denemesinde önce mevcut dağıtımın kabul ettiği görevler sabitlenebilir: belge geçmişi taşıyan istek, araç sonucu içeren konuşma ve uygulamanın kullandığı örnekleme ayarları. Ardından yeni uygulama ve SDK aynı görevlerle, aynı ağ yolu üzerinden denenebilir. Hangi isteğin reddedildiği ve hangi değişiklikle kabul edildiği ayrı tutulmalı. Aksi halde düzeltilen ileti biçimiyle değiştirilen ağ geçidi aynı başarıya yazılır; sorunun nerede çözüldüğü belirsiz kalır. Önceki dağıtım zaten bu alanları kullanmıyorsa bakım yükü daha küçük olabilir.[1]
Bu yaklaşımın değeri, yeni sürüme bir hız kazancı atfetmeden ilerlemeyi ölçebilmesi. Kabul edilen görevler, hata türleri ve onarım için gereken geliştirici incelemesi karşılaştırılabilir. Eski Bedrock modellerinde önceki SDK ve API sürümünü koruma seçeneği de geçişi zorunlu bir toplu değişiklik olmaktan çıkarıyor. Benim için iyi sonuç, aynı işi hangi katmanın bozduğunu açıklayabilen ve eski dağıtıma dönüş yolunu koruyan bir güncelleme. Yeni sözleşmenin açıklığı, geliştiriciye bakım işinin nedenlerini ve sonuçlarını daha iyi denetleme olanağı veriyor.[1]