Yapay Zekâ Ajanları Nadiren Çöker. Sessizce Hata Verirler; Araştırmalar Bunun Nedenini Gösteriyor

Büyük dil modeli ajanları artık destek taleplerini yanıtlıyor, veritabanlarında sorgulama yapıyor ve seyahat planlıyor. Bir şeyler ters gittiğinde genellikle kendinden emin bir yanıt ve başarı kodu döndürüyorlar. Giderek büyüyen bir araştırma birikimi, bu hataların neden fark edilmesinin zor olduğunu ve mühendislik ekiplerinin bunları nasıl ölçmeyi öğrendiğini açıklıyor.

Başarı Gibi Görünen Bir Hata

Geleneksel yazılımlar genellikle hatalarını açıkça belli eder. Bir işlev istisna fırlatır, sunucu hata kodu döndürür ve izleme panosunda kırmızı uyarılar belirir. Yapay zekâ ajanları ise farklı davranır. Bir döngü içinde çalışırlar: Bir dil modeli istemi okur, arama API’si veya veritabanı gibi bir aracı çağırmaya karar verir, sonucu okur ve ardından ne yapacağına karar verir. Zincirdeki tüm ağ istekleri başarıyla tamamlansa bile her adımda bir şeyler ters gidebilir.

Sık karşılaşılan bir durumu ele alalım. Bir hava durumu aracı hata verir ve normal görünen bir yanıtın içine “hizmet kullanılamıyor” metnini ekler. Model bu metni okur; ya nazikçe özür diler ya da daha kötüsü, eğitim verilerinden yararlanarak makul görünen bir tahmin yazar. Kullanıcı akıcı bir yanıt alır. Sunucu günlüklerinde istek başarılı görünür ve gecikme süresi normaldir. Geleneksel bir izleme sistemi, bir şeylerin ters gittiğini kaydetmez.

Model sağlayıcıları da kendi belgelerinde aynı boşluğa dikkat çekiyor. Google’ın Gemini API kılavuzu, modelin “işlevi kendisinin çalıştırmadığını” belirtiyor. Model yalnızca bir işlev adı ve bağımsız değişkenler öneriyor; çağrıyı ise geliştiricinin uygulaması yürütüyor. Dolayısıyla gerçek sonucu gören, sistemin yalnızca uygulama kısmı. Anthropic’in ajan oluşturma mühendislik kılavuzu da benzer biçimde, ajanların kendi ilerlemelerini değerlendirebilmeleri için araç sonuçları gibi her adıma ilişkin ortamdan gelen “gerçek veriye” ihtiyaç duyduğunu belirtiyor. Bir araç hatayı sıradan bir metin olarak bildirdiğinde bu gerçek veri yanlış olur ve ajanın bunu fark etmesinin hiçbir yolu kalmaz.

Bu yeni bir sorun türü değil; yalnızca eski bir sorunun daha belirgin hâli. Google mühendisleri, D. Sculley liderliğinde 2015’te makine öğrenimi sistemlerindeki “gizli teknik borcu” tanımladı. Üretim ortamındaki bir makine öğrenimi sisteminde riskin büyük bölümünün model kodunun dışında; veri bağımlılıklarında, yapılandırmada ve sistemleri birbirine bağlayan kodda bulunduğunu savundular. Ajanlar bu listeye yeni bir katman ekliyor. İstemler ve araç açıklamaları, kodda hiçbir değişiklik yapılmadan sistemin davranışını değiştirebilen yapılandırma öğeleridir.

Küçük Değişiklikler, Büyük Etkiler

İstemdeki küçük bir değişiklik ne kadar önemli olabilir? ICLR 2024’te sunulan bir makalede, University of Washington’dan Melanie Sclar ve meslektaşları, az örnekli istemlerin yalnızca biçimlendirmesini değiştirdi: ayırıcıları, boşlukları ve büyük-küçük harf kullanımını. Anlam aynı kaldı. Buna rağmen LLaMA-2-13B’de aynı görevdeki performans, doğruluk puanı cinsinden 76 puana kadar değişti. Daha büyük modeller, daha fazla örnek veya talimat ince ayarı da bu hassasiyeti ortadan kaldırmadı.

Yazarlar, tek bir sayı vermek yerine makul istem biçimleri arasındaki performans aralığının raporlanmasını öneriyor. Mühendislik ekipleri için çıkarılacak pratik ders daha basit: İstemde yapılan bir düzenleme, kod değişikliğidir. Sürüm geçmişine alınmalı ve kullanıcılara sunulmadan önce test edilmelidir.

Aynı durum, modelin isteminin bir parçası olarak okuduğu araç açıklamaları için de geçerli. Anthropic’in kılavuzu, araç tanımlarına ana istem kadar dikkatli istem mühendisliği uygulanması gerektiğini belirtiyor. Kılavuzda, göreli dosya yolları yüzünden sürekli hata yapan bir kodlama ajanı anlatılıyor. Araç mutlak dosya yollarını zorunlu kılacak şekilde değiştirildiğinde model, aracı hatasız kullandı. Model değişmedi; yalnızca okuduğu açıklama değişti.

Tek Bir Başarı Pek Bir Şey Kanıtlamaz

Araştırmaların ikinci bir kolu tutarlılığı inceliyor. Shunyu Yao ve Sierra’daki meslektaşlarının yayımladığı ve ICLR 2025’te sunduğu τ-bench kıyaslama testi, bir ajanın araçları kullanması ve iş kurallarına uyması gereken müşteri hizmetleri konuşmalarını simüle ediyor. Yazarlar pass^k adlı bir ölçüt geliştirdi: Bu ölçüt, ajanın aynı görevi k denemenin tümünde doğru biçimde tamamlama olasılığını gösteriyor.

Sonuçlar düşündürücüydü. GPT-4o ajanı, perakende görevlerinin yaklaşık %61’ini tek denemede tamamladı. Aynı görevi art arda sekiz kez başarıyla tamamlaması gerektiğindeyse bu oran yaklaşık %25’e düştü. Bir kez çalışan bir demo, sistemin bininci çalıştırmada nasıl davranacağı hakkında pek az şey söyler.

Çok Ajanlı Sistemler Nerede Aksıyor?

Artık birçok ekip, bir ajanın planlama yaptığı, diğerinin uyguladığı ve üçüncüsünün işi denetlediği sistemlerde birden fazla ajanı art arda kullanıyor. UC Berkeley’den 2025 tarihli bir çalışma olan “Çok Ajanlı LLM Sistemleri Neden Başarısız Oluyor?”, yedi popüler çok ajanlı çerçevede etiketlenmiş 1.600’den fazla yürütme izini analiz etti. Mert Cemri liderliğindeki yazarlar, üç grupta 14 hata türünü kapsayan MAST adlı bir sınıflandırma geliştirdi: sistem tasarımı sorunları, ajanlar arasındaki uyumsuzluk ve görev doğrulaması.

Araştırmanın temel bulgusu, birçok hatanın yalnızca temel modelin sınırlarından değil, sistemin tasarımından kaynaklandığı. Ajanlar kendilerine verilen rolü göz ardı ediyor, konuşmanın akışını kaybediyor veya sonucu denetlemeden görevin tamamlandığını ilan ediyor. Bu hatalar geride bir hata kaydı bırakmıyor. Yalnızca birileri her ajanın gerçekte ne yaptığını okuyabiliyorsa fark edilebiliyor. Unite.AI’ın çok ajanlı paradoks hakkındaki haberinde de mimari açısından benzer bir noktaya dikkat çekiliyor: Ajan eklemek, erken aşamadaki bir hatayı ortadan kaldırmak yerine büyütebilir.

Görünmeyeni Görünür Kılmak

Mühendislik yaklaşımı, isteklerin uzun süredir birçok hizmet boyunca izleme adı verilen bir teknikle takip edildiği dağıtık sistemlerden yararlanıyor. Ajanlara uygulandığında her kullanıcı isteği bir iz hâline geliyor; her model çağrısı veya araç çağrısı da bu izin içinde bir “span” oluşturuyor. Bir span, girdisini, çıktısını, kullanılan belirteçleri ve işlemin ne kadar sürdüğünü kaydediyor. Bu alandaki sektör standartlarını belirleyen kuruluş OpenTelemetry, üretken yapay zekâ span’leri için ortak kurallar taslağı hazırlıyor. 2026 itibarıyla bu kurallar hâlâ geliştirme aşamasında olarak işaretlendiğinden, öznitelik adları değişebilir.

Langfuse, Arize Phoenix ve AcruxCore gibi çeşitli açık kaynaklı projeler bu yaklaşımı şimdiden uyguluyor. Kaynak kodları herkese açık olduğundan ekipler bir izin nasıl saklandığını inceleyebiliyor ve yazılımı kendi sunucularında çalıştırabiliyor. Bu projeler, model çağrılarını ve araç çağrılarını tek bir izin span’leri olarak kaydediyor ve ekiplerin bunlara kalite puanları eklemesine olanak tanıyor. Araç seçiminden çok daha önemli olan bir ayrıntı var: araç span’i, yalnızca ağ isteğinin başarılı olup olmadığını değil, aracın gerçekte ne döndürdüğünü de kaydetmeli. Aksi hâlde yukarıda anlatılan hava durumu aracı hatası görünmez kalır.

Sektör anketleri, izleme yaygınlaşmış olsa da testlerin geride kaldığını gösteriyor. LangChain’in Ajan Mühendisliğinin Durumu raporu, 2025’in sonlarında 1.340 uygulayıcıyla anket yaptı. Katılımcıların %32’sinin belirttiği kalite, ajanları üretime almanın önündeki en sık dile getirilen engeldi. Kurumların %89’u ajanları için bir tür gözlemlenebilirlik uyguladığını, %62’si ise tek tek adımları ve araç çağrılarını ayrıntılı biçimde izlediğini bildirdi. Yalnızca %52,4’ü test kümeleri üzerinde çevrimdışı değerlendirme yaptı; %37,3’ü ise canlı trafiği değerlendirdi. Çoğu ekip, ajanlarının ne yaptığını görebiliyor. Ancak daha azı, yaptıklarının doğru olup olmadığını kontrol ediyor.

Yanıtları Ölçekli Biçimde Puanlama

İzler, ne olduğunu gösterir. Ancak yanıtın iyi olup olmadığını söylemez. Her konuşmayı elle okumak ölçeklenebilir olmadığından ekipler giderek daha sık, hakem olarak ikinci bir model kullanıyor; bu yaklaşım LLM-as-a-judge olarak biliniyor. Lianmin Zheng ve çalışma arkadaşlarının NeurIPS 2023’te yayımlanan bir makalesi, GPT-4 gibi güçlü modellerin insan tercihleriyle vakaların %80’inden fazlasında aynı yönde karar verdiğini ve bu oranın insanların kendi aralarında anlaşma oranıyla yaklaşık aynı olduğunu ortaya koydu.

Aynı makale, yöntemin zayıf yönlerini de belgeledi. Hakem modeller, önce gösterilen yanıtı ve daha uzun yanıtları tercih ediyor; ayrıca kendi yazdıkları metinlerden yana olabiliyor. Bu nedenle hakem puanları tahmindir. Çok sayıda yanıtı değerlendirmekte yararlıdırlar, ancak yanıt sırası rastgele belirlenmiş küçük bir insan etiketli örnek kümesiyle kontrol edilmeleri gerekir.

Uygulamadan Politikaya

Bu ölçüm çalışmaları, yönetişim açısından da giderek bir beklenti hâline geliyor. ABD Ulusal Standartlar ve Teknoloji Enstitüsü, Yapay Zekâ Risk Yönetimi Çerçevesi’ni Ocak 2023’te yayımladı. Çerçevenin dört temel işlevinden biri olan “Ölçüm”, kurumların yapay zekâ risklerini zaman içinde nicelleştirmesini, izlemesini ve belgelemesini istiyor. Bir ajan söz konusu olduğunda, bu işlevin talep ettiği kanıtları izler ve değerlendirme puanları sağlar.

Ekipler Şimdi Ne Yapabilir?

Bu, bu platformda dile getirilen ajan tabanlı yapay zekânın asıl sınavının güvenilirlik olduğu görüşünü yansıtıyor. Yukarıdaki araştırma, bu görüşün temelindeki ölçüm boyutunu da ortaya koyuyor: güvenilirlik, bir kez gözlemleyip saptayabileceğiniz bir özellik değil; sürekli ölçmeniz gereken bir aralık.

Araştırmalar, uygulanabilecek kısa bir alışkanlıklar listesine işaret ediyor; önde gelen model sağlayıcılarının çoğu da benzer önerilerde bulunuyor. OpenAI’nin ajan geliştirmeye yönelik uygulamalı kılavuzu, ekiplerin optimizasyona başlamadan önce “performans için bir başlangıç ölçütü belirlemek üzere değerlendirmeler kurmasını” ve bir ajan belirlenen sayıda başarısız denemeyi aşarsa ya da yüksek riskli bir eylemle karşılaşırsa kontrolü bir insana devretmesini öneriyor. Anthropic ise ajanlar kendi başlarına harekete geçmeden önce “izole edilmiş ortamlarda kapsamlı testler” yapılmasını tavsiye ediyor.

Uygulamada bu, birkaç somut adım anlamına geliyor. İstemleri ve araç açıklamalarını kod gibi sürüm denetimi altında tutun. Her istem değişikliğini sabit bir veri kümesiyle test edin ve tek bir sayı yerine farklı sonuçlar elde etmeyi bekleyin. Her test senaryosunu birkaç kez çalıştırın; çünkü tek bir deneme tutarsızlığı gizler. Başarısız bir aracın başarı kodunun ardına saklanamaması için araç çıktılarının izlere kaydedilmesini sağlayın. Otomatik hakem puanlarını tahmin olarak değerlendirin ve insanlara kontrol ettirin.

Bu alışkanlıkların hiçbiri model yeteneklerinde çığır açan bir ilerleme gerektirmiyor. Gereken, bir yapay zekâ ajanını olduğu gibi ele almak: Kendi başarısızlıklarını nadiren bildireceğinden, ölçülmesi gereken olasılıksal bir sistem olarak.