AI ajanının ikinci işlemi başarısızsa ilk işlem ne olacak?

Son hata önceki başarıyı silmez

Bir AI ajanı demo hazırlığı için iki araç kullanıyor: önce bir kit ayırıyor, sonra hazırlık panosunda kayıt açıyor. İlk araç başarılı, ikinci araç kesin bir ret veriyor. Ajan kullanıcıya “işlem başarısız” diyor. Peki ayrılan kit hâlâ ayrılmış durumda mı? Tek bir başarısızlık cümlesi, iki sistemde kalan etkiyi anlatmaya yetmez.

Birden fazla sistemde tamamlanan adımları geri dengelemek, her zaman bütün veriyi eski haline döndürmek değildir. Microsoft’un telafi işlemi örüntüsü, bu adımların işe özel kurallara ve ilerleme kaydına ihtiyaç duyduğunu; telafinin de başarısız olabileceğini açıklar. Aşağıdaki çalışma bu ilkeyi iki zararsız sentetik araçla somutlaştırır. Gerçek kit ayırma, kayıt açma veya iptal işlemi yapılmaz.Kaynak: Microsoft — Compensating Transaction pattern

Bu yazıdaki araçların durum sorgusu ve tekrar güvenliği özellikleri açık varsayımdır. Gerçek sistemde böyle özellikler yoksa varmış gibi komut üretilemez. Önce araç sahibiyle sözleşme netleşmelidir. Eğitim örneğinde asıl amaç, “başarısız oldu”, “telafi istendi” ve “kalan etki doğrulandı” durumlarını tek bir etiket altında birleştirmemektir.

İki aracın etkisini ayrı kaydedin

Ana iş: W7 demo hazırlığı.
Araç A: Bir kiti ayır; başarılı sonuç R51 ayırma kaydıdır.
Araç B: W7 için hazırlık pano kaydı aç.
Kural: B kesin reddederse ve kit henüz kullanılmamışsa R51 serbest bırakılır.
Telafi kimliği: C51; aynı R51 için tekrar aynı sonucu döndürür.
Durum sorgusu R51’in güncel ayırma durumunu okuyabilir.
Bu görevde gerekli yetkiler ve telafi sınırı önceden tanımlı kabul edilir.

Telafi, rastgele bir ters işlem değildir. Yalnızca W7’nin oluşturduğu R51 kaydını hedefler. Başka bir işin ayırdığı kiti serbest bırakmak veya ortak toplamı başlangıçtaki sayıya yazmak farklı işlerin durumunu bozabilir. Bu nedenle günlüğe ana iş kimliğini, alt işlem kimliğini ve hedef kaydı birlikte koyuyoruz. Kimliklerin rolü birbirinden farklıdır.

İkinci adımda B’nin yalnızca yanıt vermemesi değil, kayıt oluşturmadığının doğrulanması verilmiştir. Zaman aşımı yaşansaydı B’nin etkisi belirsiz kalabilirdi ve aynı karar otomatik uygulanamazdı. Bu ayrıntı telafi koşulunun bir parçasıdır. Hata türünü bilmeden her araç hatasından sonra önceki işlemi geri almak doğru bir genel kural değildir.

Gönderilen telafi isteğini tamamlanmış telafi saymayın

Üçüncü adımda C51 isteği gönderilmiştir, fakat yanıt kaybolmuştur. Uygulamanın o anda bildiği şey yalnızca isteğin denendiğidir. Kitin serbest bırakıldığı henüz doğrulanmaz. Olası iki durumu ayrı tutun: telafi uygulanmış olabilir veya henüz uygulanmamış olabilir. Bu iki olasılığın hangisinin gerçek olduğunu dördüncü adımdaki durum sorgusu çözmektedir.

Son durum “W7 başarılı” değildir. Asıl amaç pano kaydıyla birlikte demo hazırlığıydı ve bu gerçekleşmedi. Doğrulanan sonuç, başarısız işin bıraktığı ayırma etkisinin temizlendiğidir. Ana işin başarısı ile telafinin başarısını ayrı alanlarda tutmak, operasyon raporunda yapılmayan işin tamamlanmış gibi görünmesini önler.

W7 sözleşmesini ve dört adımlı sentetik günlüğü incele. A ve B etkilerini ayrı yaz. B’nin kesin reddini zaman aşımıyla karıştırma. C51 yanıtı kaybolduğunda telafiyi tamamlandı sayma; verilen R51 durum sorgusunu kullan. Yeni kimlikle yeni ayırma veya bütün envanteri sıfırlama önerme. Çıktı: durum tablosu, kalan etki ve kapanış kanıtı. Araç çalıştırdığını iddia etme; desteklenmeyen yetenek ekleme.

Ana iş W7: tamamlanmadı; pano kaydı açılmadı.
Ayırma R51: önce 1 aktif kit, son sorguda serbest.
Telafi C51: yanıt kaybından sonra durum sorgusuyla sonucu doğrulandı.
Kalan etki: W7’ye bağlı aktif ayırma 0.
Başka işlerin ayırmaları incelenmedi veya değiştirilmedi.
Yeni hazırlık girişimi, yeni karar ve uygun iş kaydı gerektirir.

Kapanış kaydında sorgunun hangi anda yapıldığını da tutmak yararlıdır. Eski bir serbest durum yanıtı yeni bir ayırmanın durumunu anlatmayabilir. Bu örnekte R51 tek ayırma kaydıdır ve son sorgu telafi denemesinden sonra gelir. Gerçek araç sözleşmesinde durumun güncellik koşulu ayrıca bilinmelidir; bu koşul verilmiyorsa kapanış kanıtının sınırı açık kalır.

Telafi yolu da kendi sınamalarını ister

Microsoft’un örüntüsü telafinin ilerleme bilgisini korumayı ve tekrarlanabilecek adımları güvenli tasarlamayı vurgular. Burada C51 kimliği bu ihtiyacı örnekler. Bir yanıt kaybolduğunda aynı hedef için farklı telafi kimlikleri üretmek yerine aracın sözleşmesindeki tekrar davranışını kullanmak gerekir. Bu davranışın uygulamada gerçekten sağlandığı ayrıca sınanır; istemde yazılması tek başına yeterli değildir.Kaynak: Microsoft — Compensating Transaction pattern

Küçük alıştırma: R51 için kitin kullanıma alındığı bilgisi gelsin. Örneğin telafi kuralı yalnızca kullanılmamış kiti serbest bırakmaya izin veriyordu. Artık otomatik serbest bırakma uygulanamaz. Ana iş kısmi durumda kalır; süreç sorumlusuna W7, R51, B’nin ret gerekçesi ve kullanım bilgisi aktarılır. Kalan etkiyi sıfır göstermek için geçmiş durumu değiştirmeyin.

İkinci bir sınır da telafinin geçici olarak başarısız olmasıdır. Deneme sınırı ve sorumlu devri önceden tanımlı olmalıdır. Sonsuz tekrar, başarısız işi tamamlamaz; yeni belirsizlikler ekleyebilir. Hangi adımların yeniden denenebileceği, hangilerinde insan kararı gerektiği ve hangi gözlemin kapanış sayıldığı aynı olay kartında görünmelidir.

Bu çalışmanın teslimi bir hata mesajından daha kapsamlıdır: iki araç etkisi, telafi koşulu, ilerleme izi ve son durum kanıtı vardır. Böyle bir kayıt, sonraki kişinin bütün işi baştan çalıştırmadan nerede kalındığını anlamasını sağlar. Akışın sonunda başarı veya başarısızlık yazmak kadar, sistemlerde hangi etkinin kaldığını doğru göstermek de gerekir.