Üretimdeki AI ajanları, geleneksel uygulamalardan farklı şekilde başarısız olur. Hatanın kaynağı genellikle kodun kendisinde değil, sistemin birbirine bağlandığı noktalarda gizlidir: teslim adımı, araç çağrısı, yönlendirme kararı ya da bütçeyi tüketen başlangıç süreci. Bu durumlar istisna olarak görülmediğinden, uygulama performans izleme araçları her şeyin yolunda olduğunu gösterirken, kullanıcı aksini deneyimler. Peki, üretimdeki AI ajanlarında fark edilmeyen başarısızlık modları neler ve bunları nasıl tespit edip önleyebiliriz?
Zamanlanmış görevler başarılı bildirirken aslında çalışmıyor olabilir
Zamanlanmış görev (cron) çerçevesi, kullanıcının ne aldığını değil, ajan tarafından her çalıştırma adımında bildirilen durumu bilir. Çalışma zamanı, lastDeliveryStatus adlı üçlü bir durum alanını ("teslim edildi" | "teslim edilmedi" | "talep edilmedi") kalıcı olarak saklar. Ancak bu durumlar, ajan tarafından rapor edilen öznel bir değerlendirmeden ibarettir. Örneğin, 300 saniyelik bir zaman aşımı süresi olan bir hata ayıklama cron görevi, yaklaşık 75 saniyesini başlangıç süreciyle harcadıktan sonra bile GitHub’a bir issue oluşturabilir, Jira’ya bir bilet açabilir ve bir elektronik tabloyu güncelleyebilir. Ardından, waitedMs=298401 ile kapanmadan önce Slack’e bir duyuru yapılması gereken adımda bütçe tükendi. Çerçeve bu çalıştırmayı başarılı olarak kaydederken, kullanıcı hiçbir Slack mesajı alamaz.
Bu sorunu çözmek için sistem, cron hizmetinden gelen cron: ... hata satırlarını Sentry’ye yönlendirerek bileşen, görev kimliği, cron adı, çalıştırma kimliği ve hata sayısıyla etiketlenmiş olaylara dönüştürür. Böylece, geçmişte gömülü bir log satırından ibaret olan zaman aşımı olayları artık aranabilir duruma gelir. Ancak bu olayın derin kökü, gözlemlemeyle değil, çalıştırma sıralamasıyla ilgilidir: Kullanıcıya yönelik duyuruların temizleme adımlarından önce yapılması gerekir. Bu konuya beşinci başarısızlık modunda yeniden değineceğiz.
Araç çağrıları sessizce 4xx yanıtı döndürdüğünde
Bir araç sarıcıları (tool wrapper) 2xx dışı bir yanıtla boş bir dize veya "işlem tamamlanamadı" gibi yumuşak bir hata mesajı döndürdüğünde, model bu sinyali algılayamaz. Yanıtın başarısız olduğunu fark etmeyen model, bir sonraki adıma geçer. Çalıştırma özeti her şeyin başarılı olduğunu gösterirken, denetim izi aracın çağrıldığını kaydeder; ancak hiçbir izde çağrının aslında başarısız olduğu görülmez.
Bu sorunu çözmek için çalışma zamanı katmanında bu başarısızlıkları sesli hale getirdik. Artık çalışma zamanı, [tools] NAME başarısız oldu: neden ... şeklindeki hata kalıplarını algılayarak aracın adını etiketleyen Sentry olaylarına dönüştürüyor. Bu sayede, bir aracın başarısızlık oranı basit bir metrik olarak izlenebilir hale geliyor. Ayrıca, Slack’e yapılan gönderilerin sessizce düşürülmesiyle ilgili logları verbose seviyesinden info seviyesine yükselterek, oran sınırı ya da yetki hataları gibi gönderi sınırındaki sorunların görünürlüğünü artırdık.
Gelen mesajları engelleyen kanallar uyarı vermiyor
Bir AI ajanının doğrudan mesajlara yanıt vermemeye başlamasının nedeni genellikle ajan değildir. Gelen mesajları değerlendiren ve hangi olayların yönlendirileceğine karar veren giriş katmanı, çoğu zaman doğru kararı verir: Bir botun kendi adına yapılan bir bahsetmeyi döngüye sokmaması, bir mesajın düzenlenmesinin yeni bir çalıştırma tetiklememesi ya da ajan tarafından yapılandırılmamış bir sohbetin yanıt almaması gerekir. Ancak sorun, bu katmanın bir mesajı engellediğinde bunu bildirmemesindedir. Kullanıcı beklerken çalışma zamanı yeşil görünür ve izde mesajın bile görüldüğüne dair bir kayıt bulunmaz.
Bu sorunu çözmek için giriş katmanında iki yapılandırılmış görünürlük mekanizması uyguladık. Daha önce verbose seviyesindeki on beş sessiz engelleme log satırı artık info seviyesinde görünür. Böylece normal çalışma zamanı loglarında herhangi bir hata düzeyini değiştirmeye gerek kalmadan engellemeler takip edilebilir. Bunun yanı sıra, her engelleme yapılandırılmış bir olay taşımacılığıyla on dört standart neden kodu (bahsetme yok, kanal izinli değil, doğrudan mesaj yetkili değil vb.) ve orijinal log satırıyla birlikte etiketlenir. Bir kullanıcı "ajanım DM’ime yanıt vermedi" dediğinde, cevap bu olaylarda saklıdır: Mesaj kimliğiyle arama yapıldığında yönlendirme nedeni net bir şekilde görülebilir.
Slack sohbetlerinde sebep açıklaması araç çağrısını gölgede bırakıyor
Fark edilmeyen başka bir başarısızlık türü de şu şekilde ortaya çıkar: AI ajanları bir Slack sohbetine Şimdi action=send, channel=#alerts mesajını gönder şeklinde bir açıklama mesajı bırakır, ancak araç çağrısı düz metin olarak yazıldığı için aslında hiçbir uyarı gönderilmez. Kullanıcı açısından bakıldığında ajan işini yaptı gibi görünürken, çalışma zamanı katmanında da yan etkili bir araç çağrısı gerçekleşmediğinden model, açıklamayı yaptığı iş olarak algılar ve devam eder.
Bu durum istisna olarak yakalanamaz. Bu nedenle, iki farklı katmanda savunma mekanizması uygulanır. İlk olarak, komut katmanında çalışma prensibi, rutin ve düşük riskli araç çağrılarının anlatılmaması kuralını içerir. Araç çağrıları ya doğrudan yapılmalı ya da kullanıcıya yönelik düzgün bir mesaj bırakılmalıdır. İkinci olarak, araç çağrıları arasındaki mesajlarda yer alan sebep açıklamaları, Slack, Discord ya da Telegram’a gönderilmeden önce çıkartılır. Böylece model dahili olarak açıklama yapsa bile kullanıcıya ulaşan mesaj temiz kalır. Bununla birlikte, henüz çalışma zamanı katmanında araç çağrısı kalıplarını tarayan ve hata olayları tetikleyen bir izleme mekanizması bulunmuyor. Bu da gelecekte üzerinde çalışılması gereken bir iyileştirme alanıdır.
Başlangıç sürecinin gecikmesi zaman aşımını tüketiyor
Başlangıç süreci, AI ajanının asıl göreviyle aynı bütçeyi paylaşan gerçek duvar saati zamanıdır. Bu süreci ücretsiz bir aşama olarak görmek, 300 saniyelik bir zaman aşımı süresinin sessizce 225 saniyeye düşmesine neden olur. İlk başarısızlık modunda bahsedilen hata ayıklama cron görevi örneğinde bellek yükü, kimlik bilgisi çözümlemesi ve yetenek tarama birlikte yaklaşık 75 saniye aldı. Geriye kalan süre içerisinde ajan herhangi bir verimli iş yapamadı ve kullanıcıya yönelik duyuru her zaman en son adımdı. Çalışma zamanı, 298 saniyede kapanmadan önce hiçbir hata üretmediği için sistem yeşil olarak görünürken, kullanıcı hiçbir uyarı almadı.
Bu sorunu çözmek için başlangıç sürecinin bütçeden düşülmesi gerektiğini net bir şekilde tanımladık. Ayrıca, çalıştırma öncesi ve sonrası adımlarına ait logları ve performans metriklerini ayrıntılı olarak izleyerek, hangi bileşenlerin zaman aldığını ve sistemin nerede optimize edilmesi gerektiğini belirledik. Gelecekte, üretimdeki AI sistemlerinin güvenilirliğini artırmak için bu tür görünürlük ve sıralama iyileştirmelerini standart uygulamalar haline getirmeyi hedefliyoruz. Bu sayede, kullanıcılar AI ajanlarının beklenen davranışı sergilediğinden emin olabilirler.
Yapay zeka özeti
AI ajanlarının üretimdeki sessiz başarısızlıklarını keşfedin. Zaman aşımı, araç çağrıları, yönlendirme hataları ve daha fazlası için uygulama ipuçları ve izleme stratejileri.
