Yapay Zeka Ajanınız Halüsinasyon Nedeniyle Değil, Hız Limitleri (Rate Limits) Yüzünden Başarısız Oluyor

Yapay zeka (AI) ajanlarımız canlı ortamda hata vermeye başladığında ilk yaptığımız şey halüsinasyon aramaktır: daha iyi istemler yazmak, çıktı şemalarını sıkılaştırmak ve daha fazla koruma bariyeri eklemek. Ancak çoğu zaman sorun akıl yürütme düzeyinde değil, altyapı tesisatındadır; yani hız limitleri (rate limits).

Yatırımcı Sunumlarında Gösterilmeyen Veriler

Datadog'un 2026 yılı yapay zeka gözlemlenebilirlik verilerine göre, üretim ortamındaki LLM çağrı hatalarının yaklaşık üçte birini hız limitleri oluşturuyor. Geliştiriciler olarak öğrenmemiz gereken en önemli ders, modern yapay zeka uygulamalarında başarısızlığın kaynağının modellerin "yetersiz zekası" değil, servis sağlayıcıların kapasite sınırları olduğudur. Bu nedenle, projenin başarısı için istem mühendisliği (prompt engineering) kadar kapasite mühendisliği (capacity engineering) pratiklerine de odaklanmamız gerekir.

Neden Ajanlar Bu Duvara Sohbet Botlarından Daha Sert Çarpar?

Sıradan bir sohbet robotu kullanıcı başına tek bir API çağrısı yaparken, bir yapay zeka ajanı tek bir kullanıcı isteği için şu adımları atabilir:

Bir planlama çağrısı,
Döngü boyunca N sayıda araç seçim çağrısı,
Her araç sonucundan sonra bir sonraki adıma karar vermek için bir çağrı,
Herhangi bir aksaklıkta yapılan yeniden deneme çağrıları,
Çoğu zaman kendi döngüsüne sahip bir veya iki alt ajan (sub-agent) çağrısı.

Bu durum, tek bir kullanıcı işleminin arka planda 10 ila 40 arası API çağrısına dönüşmesi demektir. Sunucusuz (serverless) mimarilerde otomatik ölçekleme çalışsa bile, LLM kotası sabit kaldığı için istek patlaması tüm sistemi çökertebilir. Bu, yazılım mimarisinde sıkça karşılaşılan ve sunucu tarafında yeni kapsayıcılar (containers) açıldıkça kotayı daha da hızlı tüketen "thundering herd" (gürleyen sürü) problemine davetiye çıkarır.

Kapasite Mühendisliği Araç Seti

Ajanlarımızın canlı ortamda kesintisiz çalışabilmesi için uygulamamız gereken 5 temel pratik yöntem şunlardır:

Bütçe ve Karşı Basınç (Backpressure) Yönetimi: Hata aldıkça kontrolsüzce yeniden denemek yerine, uygulamanın çıkış noktasına bir Semaphore veya Token Bucket koyarak eş zamanlı istek sayısını limitleyin. İstekler kotayı aşarsa kuyruğa alınmalıdır.
Üstel Geri Çekilme (Exponential Backoff) ve Jitter: Hata alındığında hemen tekrar istek atmak yerine, bekleme süresini katlayarak artırın ve aralara rastgele gecikmeler (jitter) ekleyin. Bu, sunucu üzerindeki yük yığılmasını engeller.
Yedek Model (Fallback) Stratejisi: Ana model hız limitine takıldığında, sistemi tamamen kilitlemek yerine görevi daha ucuz veya farklı bir API sağlayıcısındaki yedek modele yönlendirin.
Agresif Önbelleğe Alma (Caching): Tekrarlanan sistem yönergelerini ve araç tanımlarını API sağlayıcı tarafında veya yerelde önbelleğe alarak gereksiz çağrı hacmini düşürün.
Kapasiteyi Gözlemlenebilir Kılmak: Hataları genel bir "ajan hatası" olarak değil; HTTP 429, zaman aşımı ve araç hatası olarak ayrıştırıp loglayın. Telemetri verilerinde bu ayrımları yapmak, doğru katmanı optimize etmenizi sağlar.

Zihinsel Model Değişimi

LLM kotalarını bulut işlemcileri (CPU) gibi esnek ölçeklenebilen bir kaynak olarak değil, veritabanı bağlantı havuzu (connection pool) gibi sınırlı bir kaynak olarak görmeliyiz. Yazılım geliştiriciler olarak en akıllı modeli seçmek yetmez; sistemin yük altındaki davranışını doğru tasarlamak gerekir.

Orijinal makaleye buradan ulaşabilirsiniz.