Amazon, Sonnet 4.6 Yerine Strands Decider Kullanarak Milyonlarca Dolar Tasarruf Ediyor

Bir süredir Amazon ve AWS ekipleri, dünyanın en büyük dahili destek bileti (ticketing) sistemlerinden birinde biletleri etiketlemek için Claude Sonnet 4.6 modeline güveniyordu. Zeka ve maliyet dengesini kurma noktasında ideal bir tercih olan dokuz aylık bu model oldukça başarılıydı. Ancak iki Amazon mühendisi (Carr ve Mehul), yakın zamanda Sonnet 4.6'yı bir ay önce yayınlanan bir karar modeli olan Strands Decider ile değiştirdi. Sonuç olarak, aynı performansı %98 daha düşük maliyetle elde ettiler ve yılda milyonlarca dolarlık token maliyetinden tasarruf sağlayacak bir mimariye geçtiler.

Bir LLM'in Görevini Karar Modeliyle Değiştirmek#

Sistemde müşteri eskalasyonları, kapasite talepleri, otomatik alarmlar ve güvenlik bulguları gibi biletlerin 20 sabit kategoriye ayrılması gerekiyordu. Önceki yapıda Sonnet 4.6, her bilette uzun bir sistem istemiyle (system prompt) çalışıyor, akıl yürütme yapıyor ve JSON çıktısı üretiyordu.

Oysa bir karar modeli (decision model) metin üretmez; kendisine bir durum (bilet) ve seçenekler (etiket kataloğu) verildiğinde her seçenek için olasılık ve güven skoru döndürür. Mühendisler önce orijinal Strands Decider 2B ile başladı, ancak test setinde E4B Gemma 4 sürümü çok daha iyi sonuçlar verince bu modele geçtiler ve güven eşiğini optimize ederek canlıdaki Sonnet modelini geride bıraktılar.

Model, SageMaker ml.g5.xlarge (24 GB A10G GPU) sunucularında çalıştırıldı. Yaklaşık 19 GiB bellek kullanan modelde tek bir istek ortalama 640 ms sürdü. Dış ağ erişimi izole edilen konteynere model ağırlıkları başlangıçta S3 üzerinden kopyalandı. Bilet olayları SQS kuyruğuna düşüyor, Lambda fonksiyonunu tetikliyor ve SageMaker AI Endpoint çağrılıyor. Konfigürasyon AppConfig ile, izleme ise CloudWatch ile yönetilirken tüm altyapı CDK (Beta, Gamma, Prod) ile tanımlanıyor.

Geliştiriciler İçin Pratik Çıkarım (Modeller: Hangisi, Ne Zaman? & Ölçeklendirme ve Optimizasyon): Sabit kategorili sınıflandırma problemlerinde üretken bir LLM kullanarak JSON çıktısı almak yerine özelleşmiş karar modelleri kullanmak, hem gecikmeyi hem de token maliyetini dramatik biçimde düşürür.

Aynı Biletler Üzerinde Sonnet 4.6 ve Strands Decider Çalıştırmak#

Mühendisler doğrudan geçiş yapmak yerine güvenli bir gölge test (shadow testing) stratejisi izledi. Etiketleme yapan Lambda fonksiyonu, her mesajda AWS AppConfig üzerinden üç yönlü bir ayarı okur:

• BEDROCK: Her bileti Sonnet etiketler, Strands Decider çağrılmaz.
• DUAL: Hem Sonnet hem de Strands Decider modelleri paralel olarak çağrılır. Bilete Sonnet sonuçları uygulanır ve sonuçlar Strands Decider ile karşılaştırılır.
• DECIDER: Her bileti Strands Decider etiketler ve Bedrock çağrılmaz.

Ölçüm Sonuçları ve Kazanımlar#

Yapılan ölçümler, üretim ortamında doğru model seçiminin etkisini net bir şekilde ortaya koyuyor:

Token sayısındaki bu büyük düşüşün iki temel kaynağı vardı: Strands Decider, uzun bir JSON yanıtı üretmek yerine yalnızca tek bir çıktı (seçim) üretti ve çok daha kısa bir istem (prompt) yapısıyla çalıştı. Yazılım mühendisliği açısından bu vaka; feature flag tabanlı kademeli geçişin (DUAL modu ile canlı doğrulama) ve göreve özgü model mimarisinin üretim sistemlerindeki kritik önemini kanıtlıyor.