Yapay zekâ ajanları yeniden denemeden önce neden kanıta ihtiyaç duyar?

Kaybolan bir yanıtın yinelenen bir işleme dönüşmesi nasıl önlenir?

Tek bir geri ödeme yapma yetkisi olan bir destek ajanı isteği gönderir, ancak bağlantısı kesilir. Ajan, işlemin başarıyla tamamlandığına dair onay alamaz ve geri ödeme isteğini yeniden göndermeye çalışır. İlk istek başarıyla işleme alındıysa ajanın bu tekrarı ikinci bir geri ödemeye yol açabilir.

Bu tamamen varsayımsal bir örnektir. Model doğruluğunun tek başına çözemeyeceği bir sorunu ortaya koyar. Ajan, önceki eyleminin ortamın durumunu değiştirip değiştirmediğini belirleyemiyorsa ne yapmalıdır?

Unite.AI, modellerin ötesinde ajan güvenilirliğini de ele aldı. Bu tartışmalarda kurtarma sorunları için ayrı kurallar belirlenmesi gerekir. Ajan, sonuç doğurabilecek bir eylemi ikinci kez gerçekleştirmeye çalışmadan önce ne olduğunu doğrulamalı ya da yinelenen etkilerin oluşmasını önleyecek geçerli bir güvenceye sahip olmalıdır.

Yanıt Alınamaması Başarısızlık Anlamına Gelmez

Yanıt alınamaması, bir eylemin başarısız olduğunu göstermez. Hatanın yürütme başlamadan önce mi oluştuğunu, eylemin onay alınmadan mı tamamlandığını, yoksa sürecin hâlâ devam mı ettiğini de belirtmez.

Bu, dağıtık sistemlerde sık karşılaşılan bir sorundur; Amazon’un da açıkladığı gibi. Amazon, yeniden deneme mekanizmalarının yinelenen yan etkileri önlemek için neden belirli güvenlik önlemlerine ihtiyaç duyduğunu açıklıyor. Ajanlar, sisteminizin kurtarma sürecine karar veren yeni bir aktör ekler. Hatalardan nasıl kurtulacaklarına ilişkin ek kararlar alabilirler.

Bu kararlar, işlerin yürütülme biçiminde değişikliklere yol açabilir. Örneğin, farklı bir dolar tutarıyla geri ödeme isteğini yeniden göndermek, aynı isteği bir kez daha yinelemekten ibaret değildir. Benzer şekilde, ilk ödeme hizmeti yanıt vermeyi kestiğinde ikinci bir ödeme hizmetini seçmek de aynı isteği basitçe yinelemek değildir.

Ekipler, bir eylemi gerçekleştirme izni vermekle sonucu belirsiz bir eylemden kurtulma izni vermeyi birbirinden ayırmalıdır. İlk onay, eylemi yeniden gerçekleştirmenin güvenli olduğu anlamına gelmez.

Yeni Araştırmalar Riski Ölçüyor

Eylül 2026 tarihli bir ön baskı olan “Where Does Exactly-Once Live?”, LIMBO kıyaslama testini tanıttı ve dokuz model üzerinde 25.930 epizodu sınadı. Simüle edilen hizmetler; onayların kaybolması, işlemlerin gecikmeli yürütülmesi ve iletilerin yinelenmesi koşullarında test edildi.

Yazarların ana testinde yinelenen bir etkinin oluştuğu 1.279 epizodun yüzde 90’ında ajanlar işlemi başarıyla tamamladıklarını bildirdi. Dolayısıyla bir ajan, işlem hatalı biçimde yürütülmüş olsa bile başarılı olduğunu bildirebilir.

Bu sonuçlar kontrollü kıyaslama testlerine dayanıyor ve üretimdeki hata oranlarını tahmin etmiyor. Hizmetler simüle edildi ve analizlerin birkaçı keşif amaçlıydı. Ekipler, ajanların eylemlerinin sonuçlarını, işlemleri başarıyla yürüttüklerine dair bildirimlerinden ayrı olarak değerlendirmelidir.

Makale, mevcut durumu kontrol etmenin neden yetersiz kalabileceğini de ele alıyor. Hâlâ işlenmekte olan bir istek, kontrolün ardından etkisini gösterebilir. Durum yanıtının boş olması bile isteğin eninde sonunda etkili olmayacağı anlamına gelmez.

Yinelemeler Aynı Amaca Yöneliktir

İsteği alan hizmet, idempotency anahtarı kullanarak tek bir işlem için yinelenen denemeleri tanıyabilir. Gerektiği gibi desteklendiğinde bu yöntem, yinelenen denemelerin ek etkilere yol açmamasını sağlar. Tüm yeniden denemelerde idempotency anahtarı aynı kalmalıdır.

Stripe’ın API belgeleri, idempotency anahtarlarının işleyişine ve sınırlamalarına ilişkin örnekler sunuyor. API v1’de anahtarlar en az 24 saat geçtikten sonra silinebilir. Temizlenmiş bir anahtarın yeniden kullanılması yeni bir istek oluşturur. Stripe ayrıca istekte bulunanın sağladığı parametrelerin ilk istektekilerle eşleşip eşleşmediğini doğrular.

İdempotentliğin pratikteki temel uygulama alanı yalnızca bir istem değil, entegrasyon katmanınızdır. Bir işlemi göndermeden önce onaylanmış işlemi kayda geçirin. İşlemin kimliğini, parametrelerini eksiksiz biçimde, varsa sağlayıcı referansını ve işlem durumunu saklayın.

Geri ödeme için onayın ilk işlemle bağlantısını ve sağlayıcının döndürdüğü geri ödeme tanımlayıcılarını saklayın. Aynı tutarda herhangi bir geri ödeme aramak daha zayıf bir kanıttır; çünkü iki geçerli isteğin tutarı aynı olabilir. Ayrıca geri ödeme isteğinin gönderilmesiyle arama sonuçlarında görünmesi arasında gecikme yaşanabilir. İlk istek hâlâ işleniyor olabilir.

Bir ajan ya da çalışan yeniden başlatıldığında yürütme katmanı bu kimliği korumalıdır. Aynı işlem olarak gönderilen değiştirilmiş bir isteği reddetmelidir. Böyle bir değişiklik, iş akışı kuralları uyarınca yeni bir onay kararı gerektiren yeni bir eylemdir.

Araç Açıklamaları Tek Başına Yeterli Değil

Araç açıklamalarına ek olarak, isteği alan hizmetin idempotency desteğine ilişkin sözleşmesini doğrulayın. Gerçekte hangi güvencelerin sağlandığını teyit etmek için uygulamasını test edin.

Belirsizliği İşleyişin Bir Parçası Olarak Ele Alın

Şekil 1. Önemli sonuçlar doğurabilecek eylemler için önerilen kurtarma akışı. Her yeniden deneme için ayrıca güncel yetkilendirme gerekir.

Tamamlandığı doğrulandığında iş akışı sonucu kayda geçirir ve işlemi tekrarlamadan devam eder. İşlemin gerçekleştirilmediği doğrulandığında ise yalnızca beklemede olan ilk istek kalmamışsa ve yetki hâlâ geçerliyse yeniden denemeye izin verilir.

Sonucun belirsiz kaldığı durumlarda dikkate alınması gereken başka birçok nokta vardır. Sağlayıcının desteklediği, işlemin yinelenen etkilere yol açmayacağına dair geçerli bir garanti varsa ilk isteğin aynı anahtarla yeniden denenmesine izin verebilirsiniz. Aksi hâlde yazma işlemlerini durdurun ve durum sorgulaması, sağlayıcı desteği veya yetkili bir operatör aracılığıyla durumu netleştirin. Sonuç vermeyen bir kontrol, yeniden denemeye izin vermek için yeterli gerekçe değildir.

Sağlayıcı, işlemenin ve görünürlüğün sınırlarını belgeliyorsa işlemi duraklatmak da haklı bir tercih olabilir. Bu sınırlar belirlenmemişse yalnızca geçen süre, işlemin gerçekleştirilmediğini doğrulamaz. Çözüme kavuşturulamayan durumlardan kimin sorumlu olacağını ve bu kişilerin bunları ne zaman incelemesi gerektiğini tanımlamanız gerekir.

Başarısızlık Sonrası Kurtarma Farklı Bir İş Süreci Gerektirebilir

Para iadesi başarıyla gerçekleştirildiği hâlde müşteriye daha sonra gönderilecek bildirim başarısız olursa iş akışının tamamını yinelemek, para iadesinin de yinelenmesine yol açabilir. Kurtarma süreci, tamamlanan işlere ilişkin kanıtları korurken yalnızca tamamlanmamış adımı bitirmeye odaklanmalıdır.

Daha önce tamamlanmış işlemler için düzeltici adımlar gerekiyorsa Microsoft, telafi işlemlerine ilişkin yönergeler sunar. Hataların nasıl telafi edileceğine her uygulama kendi karar verir. Telafi, işleri başlangıçtaki hâline döndürmeyebilir ve telafi işleminin kendisi de başarısız olabilir.

Ayrıca, bir işlemi iptal etmek ücrete yol açabilir. Bir mesajı düzeltmek, birinin önceki sürümü görmediğini garanti etmez. Bu nedenle, kurtarma faaliyetlerinde aracının neleri geri alabileceği, değiştirebileceği veya taahhüt edebileceği açıkça sınırlandırılmalıdır. Bu sınırların dışındaki kararlar, gerekli yetkiye sahip bir kişiye yönlendirilmelidir.

Dağıtıma Almadan Önce İkinci Denemeyi Test Edin

Önemli sonuçlar doğuran araçlardan birini seçin ve test ortamında bilinçli kurtarma testleri gerçekleştirin. İşlem başarıyla tamamlandıktan sonra ilk isteğe verilen yanıtı yok sayın. İlk isteğin yürütülmesini, durum kontrolünden sonrasına erteleyin. Kurtarma sırasında çalışan süreci yeniden başlatın. Yeniden denemeden önce anahtarın saklama süresinin dolmasını bekleyin. Tekrarlanan denemeler sırasında bir parametreyi değiştirin.

Yalnızca araç yanıtlarına güvenmek yerine, ortaya çıkan iş kayıtlarını değerlendirin. Yinelenen etkileri, çözüme kavuşmamış işlemleri, aksayan işleri, kurtarma süresini ve ek manuel müdahaleleri kaydedin. İşlem geri almaları ve müşteriye yönelik telafi adımları da dâhil olmak üzere toplam iş akışı maliyetlerini kullanarak doğru biçimde tamamlanan görev başına maliyeti hesaplayın.

Ayrıca, asıl isteğe benzeyen gerçek bir ikinci isteği de test edin. Sisteminizin yeni işlerin yapılmasını engellemeden yinelenen işlemler oluşturulmasını önlediğinden emin olun. Yinelenen işlemleri önlemeyi ve görevlerin sonunda tamamlanmasını ayrı ayrı değerlendirin. Aksi hâlde her görevi sonlandıran bir aracı, çok az değer sağladığı ya da hiç değer sağlamadığı hâlde güvenli görünebilir.

Değerlendirme sorunuz açıkça ifade edilmelidir. Sistem şunları açıklayabildi mi:

• Hangi işleme izin verilmişti?
• İşlemin sonucunu göstermek için hangi kanıtlar vardı?
• Yeniden denemeye neden izin verilebilirdi?

Çözüme kavuşmamış belirsizlik nedeniyle duraklayan bir aracı, gösterimler sırasında daha az etkili görünebilir. Ancak üretim ortamlarında duraklamak, müşterinin başlangıçtaki niyetini koruyabilir. Yararlı bir süreklilik, sistemin yetki verilmiş görevleri tamamlaması ve bunları fark ettirmeden yinelememesi demektir.