Yapay Zekâ Ajanlarında Checkpoint ve Rollback: Hata Yapan Sisteme Güvenli Bir Geri Dönüş Yolu Tasarlamak

Bir yapay zekâ ajanı elli müşteri kaydını güncelledi, üç dosyayı yeniden adlandırdı ve iki sipariş için iade sürecini başlattı. Sonra bir sorun fark edildi: Ajan, “teslim edilmedi” durumundaki siparişlerle “teslimatı gecikti” durumundaki siparişleri aynı gruba koymuştu.

Burada yalnızca yanlış karar veren bir modelle karşı karşıya değiliz. Yanlış karar, gerçek sistemlerde bir dizi değişikliğe dönüşmüştür. Bazı değişiklikler kolayca geri alınabilir; bazıları başka sistemlere yayılmış, insanlara bildirim göndermiş veya finansal sonuç üretmiş olabilir. “Ajan yeniden denesin” demek bu noktada yeterli değildir. Önce dünyayı güvenli ve tutarlı bir duruma getirmemiz gerekir.

Checkpoint ve rollback mekanizmaları tam olarak bu sorunu çözer. Checkpoint, ajanın belirli bir andaki çalışma durumunu yeniden kullanılabilecek biçimde kaydeder. Rollback ise hata sonrasında sistemi daha önce bilinen güvenli bir duruma döndürmeye çalışır. Fakat gerçek hayatta bu, bilgisayar oyunundaki “son kayda dön” düğmesi kadar basit değildir. Gönderilmiş bir e-posta geri gönderilmemiş hâle, müşterinin gördüğü fiyat hiç görülmemiş hâle kolayca çevrilemez.

Bu yazıda önce checkpoint ve rollback’in neyi koruduğunu açıklayacağız. Ardından hangi işlemlerin gerçekten geri alınabildiğini, hangilerinin ancak telafi edilebildiğini ve insan onayının nerede devreye girmesi gerektiğini kuracağız. Son bölümde ise bütün yapıyı gerçekçi bir e-ticaret senaryosuna uygulayacağız.

Checkpoint yalnızca konuşma geçmişini kaydetmek değildir

Bir ajanın durumu, modelle yapılan son birkaç mesajdan daha geniştir. Ajan bir görevi yürütürken en az dört farklı durum katmanı oluşur:

• Mantıksal durum: Hedef, tamamlanan adımlar, sıradaki eylem, verilen kararlar ve açık varsayımlar.
• Çalışma durumu: Kullanılan model, talimat sürümü, araç çıktıları, ara dosyalar ve hata sayacı.
• Dış dünya durumu: Veritabanındaki kayıtlar, dosyalar, siparişler, takvim etkinlikleri ve başka sistemlerde oluşan değişiklikler.
• Yetki ve bütçe durumu: Kalan süre, harcama sınırı, kullanılabilecek araçlar ve bekleyen insan onayları.

İyi bir checkpoint, görevi aynı güvenlik koşullarıyla sürdürebilmek için gerekli olan bu bilgileri birlikte ele alır. Yalnızca konuşma metnini saklarsak ajan neden belirli bir kararı verdiğini görebilir; fakat kararın veritabanına uygulanıp uygulanmadığını bilemeyebilir. Yalnızca veritabanının kopyasını saklarsak da ajanın hangi adımı tamamlanmış saydığını kaybedebiliriz.

Örneğin bir ajan yüz faturayı incelerken 37. faturadan sonra checkpoint oluşturmuş olsun. Yararlı bir kayıt şunları içermelidir: Görev kimliği, işlenen fatura kimlikleri, her fatura için karar ve kanıt, henüz işlenmeyen liste, kullanılan kural sürümü, oluşturulan taslaklar, dış sistemlerde yapılan değişikliklerin kimlikleri ve checkpoint’in alındığı zaman. “37 faturayı işledim” cümlesi tek başına yeterli kanıt değildir.

Karar kuralı: Bir checkpoint, sistem yeniden başladığında “Nereden devam edeceğiz?” kadar “Şimdiye kadar dünyada neyi değiştirdik?” sorusunu da cevaplamalıdır.

Checkpoint ne zaman alınmalı?

Her model cevabından sonra tam bir kopya almak güvenli görünebilir; ancak depolama, gecikme ve yönetim maliyeti yaratır. Çok seyrek checkpoint almak ise uzun bir işi baştan çalıştırmaya ve aynı yan etkileri tekrar üretme riskine yol açar. Bu yüzden aralığı yalnız zamana göre değil, risk ve geri kazanma maliyetine göre seçmek gerekir.

Dört tetikleyici özellikle kullanışlıdır:

1. Kritik eylemden önce: Para iadesi, toplu kayıt değişikliği veya harici bildirim gibi etkili bir adımdan hemen önce.
2. Tutarlı bir iş birimi tamamlandığında: Bir müşterinin bütün kayıtları veya bir siparişin tüm kontrolleri bittiğinde.
3. Yetki sınırı değiştiğinde: Ajan salt okunur incelemeden yazma yetkisine geçmeden önce.
4. Maliyetli ara sonuç üretildiğinde: Uzun bir araştırma, büyük dosya analizi veya insan tarafından onaylanan plan tamamlandığında.

Basit bir karar hesabı kurulabilir: Bir checkpoint’in maliyeti, kaybedilmesi muhtemel işin yeniden yapılma maliyetinden ve yanlış tekrarın doğuracağı riskten düşükse checkpoint mantıklıdır. Buradaki değerler kesin olmak zorunda değildir. “Düşük, orta, yüksek” sınıfları bile başlangıç için yeterlidir.

Checkpoint’in varlığı da doğrulanmalıdır. Kayıt yazılmış görünüp eksik kalabilir, dış durumla uyuşmayabilir veya daha sonra okunamayabilir. Bu nedenle her kayıt; benzersiz kimlik, zaman damgası, görev ve kural sürümü, tamamlanmış eylem listesi ve bütünlük kontrolü taşımalıdır. Kritik sistemlerde zaman zaman deneme amaçlı geri yükleme yapmak, yalnızca yedek alındığına inanmanın önüne geçer.

Rollback tek bir işlem değil, üç farklı geri dönüş biçimidir

“Geri al” dediğimizde aslında birbirinden farklı üç mekanizmayı aynı kelime altında toplarız.

1. Durumu doğrudan geri yüklemek

Bir taslak dosya yanlış değiştirildiyse önceki sürüm yeniden yazılabilir. Bir veritabanı işlemi henüz tamamlanmadıysa transaction iptal edilebilir. Bu, rollback’in en temiz biçimidir: Eski durum elimizdedir ve değişiklik dışarıya kalıcı biçimde yayılmamıştır.

Fakat eski değeri körlemesine yazmak da tehlikelidir. Ajanın değişikliğinden sonra bir insan aynı kaydı düzeltmiş olabilir. Rollback, insanın yeni değişikliğini de silerse ilk hatayı düzeltirken ikinci bir hata üretir. Bu nedenle geri alma işlemi mevcut sürümü kontrol etmeli; kayıt beklenmedik biçimde değişmişse otomatik geri dönüşü durdurmalıdır.

2. İleriye doğru düzeltmek

Bazen güvenli çözüm geçmişe dönmek değil, mevcut durumdan yeni ve doğru bir duruma ilerlemektir. Ajan bir rapora yanlış sınıflandırma yazdıysa raporun eski sürümünü geri yüklemek yerine düzeltilmiş yeni bir sürüm oluşturmak daha anlamlı olabilir. Böylece değişiklik geçmişi korunur ve başka kullanıcıların aradaki çalışmalarına dokunulmaz.

3. Telafi edici eylem uygulamak

Gerçek anlamda geri alınamayan işlemlerde “compensating action”, yani telafi edici eylem gerekir. Para iadesi yanlış başlatıldıysa aynı işlemi silmek yerine muhasebe kurallarına uygun yeni bir tahsilat veya inceleme kaydı gerekebilir. Yanlış e-posta gönderildiyse mesaj alıcının zihninden silinemez; düzeltme mesajı gönderilir ve destek ekibi bilgilendirilir.

Telafi, geçmişi yok etmez. Oluşan zararı veya tutarsızlığı yeni bir işlemle yönetir. Bu ayrım önemlidir; çünkü sistem “rollback başarılı” derken müşteri yanlış mesajı hâlâ görüyorsa teknik rapor ile gerçek dünya birbirinden kopmuş demektir.

Her eylem için geri dönüş sözleşmesi yazmak

Güvenli geri dönüş sonradan eklenecek tek bir düğme değildir. Ajanın kullanabildiği her yazma aracı için önceden bir geri dönüş sözleşmesi tanımlanmalıdır. Bu sözleşme eylemin girdisini, etkisini, tekrar davranışını ve hata sonrasındaki yolu açıklar.

Aşağıdaki doldurulmuş örnek, müşteri statüsü değiştiren bir araç içindir:

Eylem: müşteri_statüsü_güncelle
Hedef kayıt: müşteri_4821
Beklenen mevcut sürüm: 17
Eski değer: normal
Yeni değer: inceleme_gerekli
Başarı kanıtı: kayıt sürümü 18 ve statü inceleme_gerekli
Tekrar anahtarı: görev_2026_071_4821_statü
Doğrudan geri alma: sürüm hâlâ 18 ise eski değeri yeni sürüm olarak yaz
Çakışma kuralı: sürüm 18 değilse otomatik rollback yapma
Telafi yolu: risk ekibine manuel inceleme görevi aç
İnsan onayı: müşteri hesabı askıya alınacaksa zorunlu

Buradaki beklenen mevcut sürüm, yanlış veya sonradan değişmiş bir kaydın ezilmesini engeller. Tekrar anahtarı ise ağ kesintisi yüzünden aynı aracın yeniden çağrılması hâlinde aynı eylemin iki kez uygulanmasını önlemeye yardımcı olur. Buna idempotency denir: Aynı talep tekrarlandığında sistemin ikinci bir bağımsız etki üretmemesi.

Her araç doğal olarak idempotent değildir. “Dosyada bu alanı X yap” komutu genellikle tekrar edilebilir; “bakiyeye 100 lira ekle” komutu iki kez çağrılırsa 200 liralık etki doğurur. Bu nedenle finansal ve mesajlaşma işlemlerinde benzersiz işlem anahtarı ile sonuç sorgulama yeteneği özellikle değerlidir.

Güvenli geri dönüş bir durum makinesi olarak tasarlanmalı

Ajanın hangi aşamada olduğunu yalnız serbest metinden çıkarmaya çalışmak kırılgandır. Bunun yerine görev açık durumlar arasında ilerletilebilir:

HAZIR
  → PLANLANDI
  → ONAY_BEKLİYOR
  → UYGULANIYOR
  → DOĞRULANIYOR
  → TAMAMLANDI

Hata yolu:
UYGULANIYOR veya DOĞRULANIYOR
  → HATA_SINIFLANDIRILIYOR
  → GERİ_ALINIYOR ya da TELAFİ_BEKLİYOR
  → GERİ_DÖNÜŞ_DOĞRULANIYOR
  → GÜVENLİ_DURUM veya İNSAN_MÜDAHALESİ

Bu yapı iki yaygın yanılgıyı önler. Birincisi, aracın başarılı cevap vermesini görevin tamamlanması sanmaktır. İkincisi, rollback komutunun çalışmasını dünyanın düzeldiğine kanıt saymaktır. Hem ileri eylem hem geri dönüş ayrı ayrı doğrulanır.

Örneğin ajan “müşteri statüsünü eski değerine döndür” aracını çağırdıktan sonra kaydı yeniden okumalı, sürümün beklenen biçimde arttığını ve değerin gerçekten düzeldiğini kontrol etmelidir. Buna ek olarak, önceki yanlış statünün tetiklediği bildirim veya alt görev varsa onların da ele alındığını doğrulamalıdır.

Gerçek hayat senaryosu: Geciken siparişleri yöneten ajan

Şimdi yapıyı baştan sona kuralım. Bir e-ticaret şirketi, geciken siparişleri inceleyen bir ajan kullanıyor. Ajan kargo durumunu kontrol ediyor, uygun siparişe kupon tanımlıyor, müşteri mesajı hazırlıyor ve yüksek riskli vakaları destek ekibine aktarıyor.

Görev kuralları şöyle olsun:

• Kargo hareketi 48 saattir değişmeyen siparişler incelenecek.
• Teslim edildi görünen siparişlere otomatik kupon tanımlanmayacak.
• Kupon yalnızca destek politikasındaki koşullar karşılandığında oluşturulacak.
• Müşteri mesajları otomatik gönderilmeyecek; taslak olarak bırakılacak.
• Para iadesi ajan tarafından başlatılmayacak, yalnızca insan onayına sunulacak.

Ajan ilk olarak sipariş listesinin kimliğini, sorgu zamanını ve kullanılan politika sürümünü kaydeder. Her siparişi tek bir iş birimi olarak ele alır. Siparişe başlamadan önce mevcut sipariş durumu, kargo kaydı, tanımlı kuponlar ve açık destek talepleri checkpoint’e eklenir.

Sipariş 1048 için ajan kargo hareketinin 60 saattir değişmediğini görür. Politika koşullarını kontrol eder, tek kullanımlık bir kupon oluşturur ve müşteri mesajını taslak olarak kaydeder. Ardından iki doğrulama yapar: Kupon gerçekten sipariş hesabına bağlı mı ve mesaj gönderilmek yerine taslakta mı? Her iki koşul da doğruysa sipariş birimi tamamlandı durumuna geçer.

Sipariş 1049 sırasında kupon aracı zaman aşımına uğrar. Ajanın burada doğrudan yeniden kupon oluşturması tehlikelidir; ilk istek sunucuda işlenmiş, yalnızca cevap kaybolmuş olabilir. Ajan tekrar anahtarıyla sonucu sorgular. Kuponun zaten oluştuğunu görürse yeni kupon üretmez ve doğrulamaya geçer. Sonuç bulunamazsa aynı anahtarla kontrollü tekrar yapar.

Sipariş 1050 için ajan yanlışlıkla teslim edilmiş kayda kupon tanımlar. Doğrulama aşaması, sipariş durumunun politika koşuluyla çeliştiğini yakalar. Sistem hemen yeni işlem başlatmayı durdurur ve hatayı kapsam açısından değerlendirir: Yanlış yorum yalnız bu siparişte mi oluşmuştur, yoksa aynı kural önceki siparişleri de etkilemiş olabilir mi?

İnceleme, sorunun bu tek siparişle sınırlı olduğunu gösterirse kupon henüz kullanılmadığı için iptal edilebilir. Bu, telafi edici bir eylemdir; kuponun oluşturulmuş olduğu gerçeğini geçmişten silmez. İptal sonrasında sistem kuponun geçersiz olduğunu ve mesaj taslağının kaldırıldığını doğrular. Kupon kullanılmışsa otomatik telafi durur, vaka insana aktarılır. Müşterinin hesabından tek taraflı değer düşmek yeni bir zarara yol açabilir.

Eğer yanlış kural önceki yirmi siparişi de etkilemiş olabilirse tek kayda dönmek yetmez. Ajan yazma yetkisini askıya alır, son güvenilir checkpoint’ten sonraki tüm eylemleri listeler ve her biri için etki analizi üretir. Böylece toplu, kör bir rollback yerine seçici bir kurtarma planı hazırlanır.

Rollback’in bozulduğu sınırlar

Checkpoint ve rollback güçlüdür; fakat geçmişi kusursuz biçimde geri getiren bir zaman makinesi değildir. Tasarım sırasında şu sınırlar açıkça kabul edilmelidir:

• Dış sistemler bağımsızdır: Bir API değişikliği kabul etmiş, fakat ajan cevap alamamış olabilir. Önce sonucu sorgulamadan tekrar etmek çift etki yaratabilir.
• İnsanlar durumu görmüş olabilir: Yanlış bildirim silinse bile alıcı içeriği okumuş veya ona göre karar vermiş olabilir.
• Durum eşzamanlı değişebilir: Ajan checkpoint aldıktan sonra çalışanlar veya başka ajanlar aynı kayıtları güncelleyebilir.
• Checkpoint de hatalı olabilir: Yanlış politika altında oluşturulmuş bir kayıt teknik olarak tutarlı, iş açısından güvensiz olabilir.
• Geri dönüşün kendisi hata verebilir: Yetki süresi dolabilir, telafi aracı erişilemez olabilir veya eski değer yeni veri modeliyle uyumsuz kalabilir.
• Gizlilik yükü oluşur: Checkpoint’ler müşteri verisi, araç çıktısı veya hassas ara bilgi taşıyabilir. Saklama süresi ve erişim sınırı gerekir.

Bu sınırlar nedeniyle güvenli sistem “Her şeyi geri alabilirim” iddiasıyla kurulmaz. Daha gerçekçi hedef şudur: Hatayı erken yakalamak, yayılmasını durdurmak, değişiklik geçmişini kanıtlarla görmek ve mümkün olan en düşük riskli düzeltme yolunu seçmek.

İnsan onayı nerede zorunlu olmalı?

Her hatayı insana bırakmak otomasyonun değerini azaltır; her hatayı ajana bırakmak ise yetkiyi ölçüsüz genişletir. İyi ayrım, eylemin geri alınabilirliği ve etkisi üzerinden yapılabilir.

Aşağıdaki durumlarda otomatik rollback genellikle makuldür: Değişiklik tek bir iç sistemdeyse, eski değer kesin olarak biliniyorsa, arada başka değişiklik yapılmadıysa, geri dönüş yeni bir kişiye zarar vermiyorsa ve sonuç deterministik biçimde doğrulanabiliyorsa.

Şu durumlarda insan onayı gerekir: Finansal hareket oluşmuşsa, müşteri iletişimi gönderilmişse, kişisel veri etkilenmişse, birden fazla sistem tutarsız duruma gelmişse, checkpoint’in güvenilirliği şüpheliyse veya iki güvenli seçenek arasında iş kararı gerekiyorsa.

Pratik eşik: Sistem geri dönüşün doğru hedefe, doğru kapsamda ve yeni zarar üretmeden uygulanacağını kanıtlayamıyorsa eylemi durdurmalı; insana yalnız “bir şeyler ters gitti” değil, etkilenen kayıtları ve olası yolları sunmalıdır.

Kendi ajanınız için uygulanabilir kontrol listesi

İlk sürümde karmaşık bir altyapı kurmak zorunda değilsiniz. Tek bir gerçek iş akışını seçip şu sırayla ilerleyebilirsiniz:

1. Ajana açık bütün yazma eylemlerini listeleyin: örneğin kayıt güncelleme, dosya yazma, kupon oluşturma ve mesaj gönderme.
2. Her eylemi “doğrudan geri alınabilir”, “telafi edilebilir” veya “geri alınamaz” olarak sınıflandırın.
3. Her iş birimi için kaydedilecek mantıksal ve dış durum alanlarını belirleyin.
4. Kritik eylemlerden önce checkpoint, sonrasında ise bağımsız durum okuması ekleyin.
5. Tekrar çalıştırıldığında çift etki üretebilecek araçlara benzersiz işlem anahtarı verin.
6. Rollback öncesinde kayıt sürümünü ve eşzamanlı değişiklikleri kontrol edin.
7. Geri dönüşü de normal eylem gibi doğrulayın; yalnız araç cevabına güvenmeyin.
8. Finansal, hukuki, gizlilikle ilgili veya müşterinin gördüğü sonuçlar için insan onay eşiği koyun.
9. Bir deneme senaryosunda ağ kesintisi, yarım kalan işlem ve çakışan kullanıcı güncellemesi oluşturun.
10. Raporu yalnız son durumla değil; eylem, kanıt, geri dönüş ve açık risk zinciriyle saklayın.

Sonuç: Güven, hiç hata yapmamak değil güvenli toparlanabilmektir

Yapay zekâ ajanları belirsiz girdilerle karar verir, araç çağırır ve değişen sistemlerde çalışır. Bu ortamda bütün hataları önceden engellemek gerçekçi değildir. Güvenilirliği belirleyen şey, ajanın yalnız başarılı yolda ne kadar becerikli olduğu değil; bir hata ortaya çıktığında nerede durduğu, neyi değiştirdiğini gösterebildiği ve güvenli biçimde toparlanıp toparlanamadığıdır.

Checkpoint bize geçmişte bilinen bir durumu verir. Rollback geri alınabilir değişiklikleri düzeltir. Telafi mekanizmaları geri alınamayan etkileri yönetir. Sürüm kontrolleri başkalarının çalışmasını ezmeyi önler. İdempotency anahtarları tekrar denemeyi güvenli kılar. Doğrulama ise bütün bu mekanizmaların yalnızca çalıştığını söylemekle kalmayıp gerçekten beklenen sonucu ürettiğini kanıtlar.

Başlamak için bugün tek bir ajan iş akışını seçin ve en riskli yazma eylemini bulun. O eylemden önce neyi kaydetmeniz gerektiğini, başarısını nasıl doğrulayacağınızı ve hata hâlinde doğrudan geri alma mı, ileriye doğru düzeltme mi, yoksa telafi mi kullanacağınızı yazın. Güvenli geri dönüş tasarımı, “geri al” düğmesi eklemekle değil, bu üç soruya somut cevap vermekle başlar.