Yapay Zeka Faturanız 4 Katına Çıktı ve Kimse Hangi Adımın Buna Sebep Olduğunu Söyleyemiyor

Geçen ay görüştüğüm bir ekibin çıkarım (inference) harcamaları tek bir çeyrekte 4 katına çıktı. Bu bir kriz değildi; yeni bir ajan (agent) canlıya almışlardı, kullanım ve gelir artmıştı. Asıl sorun çok daha can sıkıcıydı: Finans departmanı ürünün hangi kısmının pahalılaştığını sorduğunda kimse cevap veremedi. Üç mühendis, üç farklı tahminde bulundu. Tüm gösterge panelleri yeşildi ve faturalar doğruydu, ancak kimse maliyeti artıran adımı adlandıramıyordu.

Karşılaştığım temel hata modu "faturanın çok yüksek olması" değil; faturanın doğru ama okunamaz olmasıdır. Bu bir finans veya fiyatlandırma sorunu değil, doğrudan bir enstrümantasyon (izleme ve ölçümleme) sorunudur. Sebebi ise nettir: İş birimi değişti, ancak maliyet ilişkilendirme (attribution) birimi değişmedi.

Token Başına Fiyatlar Düştü, Fatura Yine de Arttı#

Son iki yılda kullandığınız her modelin token başına maliyeti ucuzladı. Buna rağmen faturalar arttı. Değişen şey fiyat değil, kullanıcının tek bir işlem olarak gördüğü işin arkasındaki çağrı sayısıdır.

Sohbet (chat) döneminde "bu müşterinin son çeyreğini özetle" komutu tek bir istekti: bir istem (prompt), bir tamamlama (completion) ve işlem tamam. Ajan (agent) döneminde ise aynı cümle; bir planlama çağrısı, birkaç veri getirme (retrieval) veya embedding çağrısı, iç sistemlere yapılan iki-üç araç (tool) çağrısı, araç çıktısını sığdırmak için bir sıkıştırma adımı, bağlamın (context) yeniden inşası, üretim, doğrulama adımı ve doğrulama başarısız olursa ikinci bir üretim çağrısı demektir. Kullanıcının tek bir eylem olarak algıladığı işlem, arka planda 20 ila 40 çağrıya dönüşür.

Üstelik aritmetiği doğrusal olmaktan çıkaran kritik bir detay vardır: Bağlam (context) bir toplanan değil, bir çarpandır. 30. çağrı sadece kendi maliyetini taşımaz; 1'den 29'a kadar olan çağrıların birikmiş sonuçlarını da taşır. Döngü derinleştikçe, girdi token'ları adım sayısının karesiyle orantılı olarak büyürken faydalı çıktı sabit kalır. Eskiden faturalar az sayıda pahalı işlemden oluşurdu; şimdi ise tek başına ucuz görünen çok sayıda işlemin, ara katmanlarda (plumbing) birikmesiyle oluşuyor.

İlişkilendirme (Attribution) Sorunu#

Çoğu ekip maliyeti hala bir sohbet ürününe uygun eksenlerde izliyor:

• API anahtarına göre
• Uç noktaya (endpoint) göre
• Ekibe veya ortama göre

Bu metrikler maliyeti kimin oluşturduğunu yanıtlar, neden oluştuğunu değil. Örneğin, API anahtarına göre harcamalara bakıp platform ekibinin faturanın %60'ını oluşturduğunu görebilirsiniz. Ancak o ekip 11 farklı özellik çalıştırıyorsa hangisi buna sebep oldu? Bu özelliğin içindeki veri getirme adımı mı, araç çağrıları mı yoksa yeniden denemeler (retries) mi bütçeyi eritti?

İş birimi bir görev zincirine (task chain) dönüştüğünde, maliyet takibi de bu zincire uyum sağlamalıdır. Pratikte, yazılım geliştiricilerin üç farklı irtifada üç farklı soruyu yanıtlayacak bir LLM Observability (Gözlemlenebilirlik) yapısına ihtiyacı vardır:

• Toplam (Total): Bu ay modele ve sonuca göre (200, 429 veya zaman aşımı — durum kodları sadece sistem sağlığı değil, aynı zamanda birer maliyet sinyalidir) ne kadar harcandı?
• İlişkilendirme (Attribution): Hangi özellik, hangi müşteri (tenant), hangi görev tipi ne kadar tüketti?
• Tekil Adım (Single step): Tek bir izleme (trace) kaydı içindeki 34 çağrıdan hangisi maliyetin %60'ını yuttu?

Ekiplerin neredeyse tamamında 1. seviye, bazılarında ise 2. seviye bulunur. Ancak çok az ekipte 3. seviye vardır. Oysa mühendislik davranışını değiştiren ve size neyi düzeltmeniz gerektiğini söyleyen tek seviye 3. seviyedir. Çok adımlı ajanlar geliştirirken her adımı izlenebilir kılmak, sadece hata ayıklama (debugging) için değil, sürdürülebilir maliyet yönetimi için de zorunludur.