Bir Yapay Zeka Agent'ı Sessizce Nasıl Başarısız Olur: 5 Biçim

Ekranda "İş başarıyla tamamlandı" yazıyordu. Durum göstergesi yemyeşil, hata yok, uyarı yok... Ta ki operasyondan biri telaşla raporun nerede kaldığını sorana kadar kimse dönüp bir daha bakmadı. Sistem çökmemişti; işlem kaydı (log), aslında hiç gerçekleşmemiş bir iş için "başarılı" damgası basmıştı ve buradaki tek arıza, herkesin o yeşil göstergeye körü körüne inanmasıydı.

Bir yapay zeka (AI/SI) ajanı (agent) işi sahiden yaptı mı? Bunu teyit etmek için arayüzdeki durum göstergesine değil, nihai sonuca bakın. Bir işlem döngüsü (tur) ancak çağırdığı her araç teyit edilmiş bir başarı döndürdüyse, beklenen veri hedef sistemde fiilen duruyorsa ve eylem kaydı neyin değiştiğini açıkça belgeliyorsa tamamlanmış sayılır. Ekranda hata görmemek, işin bittiğinin kanıtı değildir.

Agent neden hiçbir şey yapmadığı hâlde "tamamlandı" der?

Bu yanıltıcı tabloyu üreten birbirinden farklı üç temel arıza mekanizması vardır ve her birinin reçetesi ayrıdır:

1. Ağ ve bağlantı katmanı (transport) ayakta kaldı, ancak son adım hiç çalışmadı. HTTP akışı temiz kapandı, bu yüzden süreci saran altyapı temiz bir bitiş kaydetti. Ancak agent zincirin ortasında bir yerde zaman aşımına uğradı, adım limitini veya token bütçesini tüketti; dolayısıyla zincirin en sonundaki teslim adımına hiçbir zaman sıra gelmedi.
2. Araç, arka plandaki etkiyi teyit etmeden biçimsel olarak geçerli bir yanıt döndürdü. API çağrısı kabul edildi (HTTP 200/202), yanıt başarıyla ayrıştırıldı; ancak hedef sistem o çağrıyı sonradan reddetti, kuyruğa hapsetti, rate-limit'e taktı veya değeri sessizce değiştirdi. Tur kaydında görünen şey sadece "talebin ulaştığı"dır; işin bittiği değil.
3. Agent, bir niyeti tamamlanmış bir eylem gibi hikâyeleştirdi. Üretilen özet metin e-postanın gönderildiğini yazıyor; ancak gerçekte gönderme aracı (tool) hiçbir zaman tetiklenmedi. Metin akıcı, kulağa inandırıcı ve kendi içinde tutarlı; fakat hiç yaşanmamış bir kurguyu anlatıyor.

Bu üç senaryo da arayüzde birbirinin tıpatıp aynısı olan "yeşil" bir işlem kaydı üretir. Sadece arayüzdeki durum alanına bakarak bunları birbirinden ayıramazsınız; zaten durum göstergelerinin güvenilmez olmasının asıl sebebi de budur.

Bu üç arızanın da çözümü vardır: Birincisi araç sonuçlarından matematiksel olarak hesaplanan bir tamamlanma sinyaliyle, ikincisi hedef sistemden alınan somut geri okuma teyidiyle, üçüncüsü ise özette iddia edilen her eylemi araç çağrısı listesiyle çapraz eşleştirmeye tabi tutarak önlenir.

Bir agent turunda sessiz hata (silent failure) nedir?

“

Sessiz hata; sistemde hiçbir hata sinyali üretmediği hâlde, amaçlanan iş sonucunu da fiilen üretmeyen agent işlemidir. Hiçbir servis çökmez, hiçbir alarm çalmaz ve tur kaydı sanki her şey yolundaymış gibi başarıyla kapanır.

Gürültülü hatalar ucuzdur: bir alarm patlatır, nöbetçi mühendisi uyarır, loglara düşer ve genellikle aynı gün içinde çözülür. Sessiz hatanın faturası ise çok daha ağırdır. O an için hiçbir maliyeti yokmuş gibi durur ama her gün birikerek büyür; üstelik kimse dönüp bakmaz, çünkü insanları kontrol etmeye yöneltecek olan uyarı mekanizmasının kendisi arızalanmıştır.

Bu yüzden sessiz hatanın maliyeti parayla değil zamanla ölçülür: Arıza ne kadar geç fark edilirse, geriye dönük ayıklanması ve telafi edilmesi gereken işlem hacmi o denli devasa olur. Gürültülü hatada müdahale süresi dakikalarla ölçülürken, sessiz hatada bu süre maalesef haftaları bulabilir.

Gözetimsiz (otonom) iş akışlarında bu tehlike çok daha belirgindir. İki insanın yazıştığı bir sohbet oturumunda çıktıyı okuyan bir göz vardır ve o insan doğal bir güvenlik filtresidir: sipariş tutarının saçma olduğunu hemen fark eder. Ancak gece 03:00'te sessizce çalışan bir zamanlanmış arka plan agent'ının başında kimse yoktur; sistemin kendi hakkında söylediği sahte "başarılı" beyanı, bir müşteri veya muhasebe isyan edene kadar ortalıktaki tek bilgi olarak kalır.

İzleme (monitoring) ile doğrulama (verification) arasındaki fark nedir?

İzleme sistemi gözetler: Sunucu ayakta mı, API yanıt verdi mi, yanıt kaç milisaniyede döndü? Doğrulama ise gerçek dünyayı gözetler: Fatura gerçekten kesildi mi, kargo takip numarası sisteme işlendi mi, veritabanındaki bakiye doğru mu? Yalnızca izlenen ama bağımsız olarak doğrulanmayan bir agent filosu, kendinden son derece emin ama içi boş yeşil panolar üretir.

İzleme yazılımlarını satın almak kolaydır; satılan tüm gösterge panoları bu arızaların hepsinde yeşil yanar, çünkü teknik altyapı sorunsuz çalışırken işin kendisi ortada yoktur. Kimsenin iş neticesini denetlemediği için buharlaşan pilot yatırımları tam olarak bu yanılsamadan beslenir.

İki sorunun cevabı farklı yerlerde aranır: İzlemenin cevabı kendi iç panelinizde, doğrulamanın cevabı ise harici hedef sistemin veritabanında durur. Bu yüzden sadece kendi paneline bakarak geçirilen bir hafta, işin kalitesi açısından gözü kapalı geçirilmiş bir haftadır.

İzleme size agent'ın çalıştığını söyler. İşin gerçekten olup bittiğini ise yalnız ve yalnız hedef sistem söyler.

Beş sessiz hata türü ve bunların sahadaki yansıması

Aşağıdaki tabloyu, yönetim panelinizde görünen yanıltıcı durum ile çıplak gözle hedef sistemde kontrol etmeniz gereken gerçek durum arasındaki fark olarak okuyun.

Bu beş arızanın dördü kendi loglarınızda asla görünmez; yalnızca hedef sistemin içine girdiğinizde fark edilir.

Yarım kalma vakalarının bir diğer yaygın örneği de işin bir agent'tan diğerine devredildiği çoklu agent mimarilerinde görülür: Görev devri ilk agent'ta başarılı sayılırken, işi devralan agent süreci hiçbir zaman tamamlayamamış olabilir.

Bir işlem turunu güvenilir bir tamamlanma sinyaline nasıl dönüştürürsünüz?

Hesaplama yaparak. Bir tamamlanma sinyali, yalnızca araç çağrılarının fiilen ne döndürdüğü matematiksel olarak analiz edildiğinde güvenilirdir; oturumun kapanmış olmasından başarı çıkarımı yapmak tamamen temelsizdir.

Dört altın kural:

1. Sonucu ağ bağlantısının kopup kopmamasına göre değil, araç çağrılarının döndürdüğü somut verilere göre tartın. Neyin denendiğini, kaçının başarılı olduğunu ve kaçının reddedildiğini sayın.
2. Dış dünyada etki yaratan (yan etkili) çağrılarının tamamı başarısız olmuş bir turu, agent ne kadar edebi ve akıcı bir özet yazmış olursa olsun doğrudan başarısız kabul edin.
3. Yeteneklerin (tools), modelin etrafından lafla dolaşamayacağı katı hata kodları içeren yapılandırılmış JSON nesneleri döndürmesini zorunlu kılın.
4. Nihai başarı veya başarısızlık sonucunu sadece derin log dosyalarına gömmeyin; görev kartının en tepesine işleyin ki bir insan tek bakışta akıbeti görsün.

Tamamlanma bayrağı sonuçlardan otomatik hesaplanır; sonuçları üreten yapay zekanın kendi beyanına asla bırakılamaz.

Bunu kendi sistemlerimizi geliştirirken bizzat tecrübe ettik: Zamanlanmış bir sosyal medya paylaşımı, hedef hesabın kısıtlanması sebebiyle reddedilmişti. Ancak HTTP bağlantısı temiz sonlandığı için sistem işi "tamamlandı" olarak kaydetti. Çalışma zamanı mimarimizi baştan aşağı yeniledik: Artık son olay kaydı, araç çağrılarının gerçek neticelerinden türetilen katı bir sonuç nesnesi taşır. Yan etkili işlemleri patlayan hiçbir tur artık sisteme "başarılı" olarak yazılamaz.

Zamanlanmış bir iş, ihtiyaç duyduğu yetenekleri neden baştan beyan etmelidir?

Çünkü önceden bildirilmiş bağımlılıklar, düşmüş bir oturumu kendinden emin sahte bir sessizlik yerine gürültülü ve görünür bir hataya çevirir. Bir arka plan görevi hangi araçlara ve API'lere muhtaç olduğunu baştan ilan ederse, model eksik bir servisin etrafından doğaçlama yapmaya başlamadan önce süreç güvenle durdurulur.

En büyük risk modelin doğaçlama yapmasıdır. Veri tabanına erişemeyen bir dil modeli, veri tabanı hakkında son derece akıcı ve inandırıcı bir masal uydurabilir; çünkü diğer yetenekleri elinden alındığında yapabildiği tek şey metin üretmektir. Bu nedenle tekrarlayan her iş için dokunduğu sistemleri listeleyin ve şu soruyu sorun: "Bu servis çökerse tura ne olur?" Cevabınız "Yine de çalışır ve bir şeyler yazar" ise, o işin bağımlılık deklarasyonuna acil ihtiyacı var demektir.

Botonom altyapısında çalışan tekrarlayan işler bağımlılıklarını önceden deklare eder; örneğin analitik kaynağından veri çekip tablo güncelleyen bir raporlama görevi, kaynaklardan biri yanıt vermediğinde boş rapor üretmek yerine süreci anında gürültülü bir alarm ile durdurur.

Bir iş üst üste arızalandığında sistem ne yapmalıdır?

Kendini otomatik olarak duraklatmalı, sorumlu yöneticisine bildirim göndermeli ve gereksiz yere bütçe yakmayı derhal kesmelidir. Arka arkaya körü körüne çalışmaya ve kimsenin bakmadığı uyarılar üretmeye devam etmemelidir. Arka arkaya gelen üçüncü alarm genellikle göz ardı edilir; bu sırada her dakika yeniden tetiklenen başıboş bir agent, havaya para savurmaktan başka hiçbir işe yaramaz.

Bu mekanizmanın adı devre kesicidir (circuit breaker): Sabit bir ardışık hata eşiğinde süreci askıya alan ve ilk başarılı işlemde sayacı sıfırlayan akıllı bir kontrol mekanizması.

Buradaki eşik tam bir iki ucu keskin bıçaktır (trade-off): Eşiği çok dar tutarsanız geçici tek bir ağ dalgalanmasında sağlıklı bir iş duraklatılır; çok yüksek tutarsanız bozuk bir süreç günlerce havaya para harcar. Kendi platformumuzda 3 ardışık hata eşiğini uyguluyoruz: Üst üste üç kez başarısız olan görev otomatik olarak dondurulur ve süreç sahibine acil bildirim iletilir.

Tekrarlayan işler altyapı yeniden başlasa veya sunucu resetlense bile kaldığı yerden devam eder; ancak bakım pencerelerine denk gelen tekil görevlerin kaçırılmaması için idempotent kontrol mekanizmaları şarttır.

Mühendis olmayan bir yöneticinin okuyabileceği bir eylem kaydında neler olmalı?

İş dünyasının diliyle 5 temel alan: Kim istedi, ne çalıştı, ne değişti, ne harcadı, ne reddedildi?

1. Kim istedi: Görevi tetikleyen kullanıcı veya zamanlama kuralı ve turun hangi yetki profiliyle çalıştığı. (Şirketten ayrılmış bir personelin yetkileriyle işlem yapılması kabul edilemez bir güvenlik açığıdır.)
2. Ne çalıştı: Sırasıyla hangi araçların çağrıldığı ve ne yanıt döndüğü; yapay zekanın yazdığı süslü özet değil, somut araç çağrıları.
3. Ne değişti: Değiştirilen satır, oluşturulan dosya veya gönderilen e-posta; hedef sistemde aranıp teyit edilebilecek tekil bir kimlik (ID) bilgisiyle birlikte.
4. Ne harcadı: Turun tükettiği token ve API maliyeti. Böylece hatalı bir döngünün faturası anında yakalanır.
5. Ne reddedildi: Güvenlik kapısına takılan, yetki yetersizliğinden dönen veya engellenen çağrılar.

Avrupa Birliği'nin Yapay Zeka Yasası (EU AI Act) Madde 12 de yüksek riskli sistemler için tam olarak bu otomatik ve silinemez log mekanizmasını zorunlu tutmaktadır. Arka ofis işleri bu yasanın doğrudan kapsamına girmese bile, mühendislik prensibi aynıdır: Kayda geçmemiş, kanıtı olmayan bir süreci kimse denetleyemez.

Bir haftalık agent operasyonu 15 dakikada nasıl denetlenir?

Önce başarısız olanlara bakın, ardından çalışan her iş için hedef sistemde tek bir gerçek çıktıyı gözünüzle teyit edin. 15 dakikalık pratik haftalık denetim rutini:

1. Başarısız turları açın (2 dakika): Hata alan işlemler zaten alarm vermiştir, hızlıca sebebe bakın.
2. Hedef sistemden tek bir çıktıyı teyit edin (5 dakika): Agent'ın raporuna değil, ERP veya CRM'e girip kaydın gerçekten orada olduğunu doğrulayın.
3. Reddedilen ve takılan aksiyonları tarayın (2 dakika): Sürekli aynı kapıya takılan bir yetki talebi var mı?
4. Maliyet dalgalanmalarını karşılaştırın (3 dakika): Geçen haftaya göre ani bir maliyet artışı var mı?
5. Karar verin: Devam, revize et veya durdur (3 dakika): Sorunlu görevleri askıya alın, stabil olanları onaylayın.

Hiçbir şeyi duraklatma veya düzeltmeyle sonuçlanmayan bir denetim, gerçek bir denetim değildir; sadece vakit kaybıdır.

Hangi kontroller otomatik çalışmalı, hangileri insana bırakılmalıdır?

Verinin varlığı ve sayısal mutabakat makinenin işidir; karmaşık ticari muhakeme ise insanın.

Tekrarlayan, baş ağrıtmayan rutin işler gözetimsiz otomasyonun en başarılı olduğu sahadır ve doğrulaması da en ucuz olanıdır. Metinleri tek tek baştan okumak yerine sayısal mutabakat sağlayın; hedef sistemde tekil bir kayıt kimliği arayın. Kendi işini yine aynı agent'a kontrol ettirmeyin; çünkü bu size ikinci bir nesnel kanıt değil, sadece ikinci bir inandırıcı masal sunar.

Sessiz bir hata fark edildiğinde ilk bir saatte ne yapılmalıdır?

İncelemeye dalmadan önce görevi derhal duraklatın. İşlem çalıştığı her saniye hasar penceresi genişler ve mükerrer hatalar katlanır.

1. Hasarı durdurmak için görevi hemen askıya alın.
2. Hasar penceresini netleştirin: "Tamamlandı" yazan son işlem değil, çıktısını hedef sistemde gözünüzle teyit edebildiğiniz son sağlıklı tarih başlangıç noktanızdır.
3. Etkilenen kayıtları agent loglarından değil, hedef sistemin kendi veritabanından listeleyin.
4. Düzeltmeyi ileriye dönük yapın; yarım kalan bir akışı körü körüne baştan çalıştırmak zaten başarılı olmuş ilk adımları mükerrer işleterek iki kez fatura kesebilir.
5. Bu hatayı yakalayacak güvenlik kuralını devreye alın.
6. Olayı, tarihi ve şirkete getirdiği operasyonel maliyetiyle birlikte yazılı bir rapora dökün; kayda geçmeyen arızalar mutlaka tekrarlanır.

Gözetimsiz agent operasyonları için doğrulama kontrol listesi

• İş akışı, ihtiyaç duyduğu servisleri baştan ilan ediyor mu ve servis çöktüğünde gürültülü bir alarm üretiyor mu?
• Tamamlanma durumu sadece ağ bağlantısından değil, araçların gerçek çıktılarından mı hesaplanıyor?
• Dış dünyada etki yaratan her eylem, hedef sistemde doğrulanabilir tekil bir kimlik (ID) bırakıyor mu?
• Üst üste tekrarlanan arızalarda devre kesici (circuit breaker) çalışıp görevi donduruyor mu?
• Eylem kayıtları 5 temel soruyu yanıtlıyor mu: Kim istedi, ne çalıştı, ne değişti, ne harcadı, ne engellendi?
• Her iş için haftada en az bir kez hedef sistemden çıplak gözle teyit alınıyor mu?
• Her görevin adı, unvanı belli yetkili bir süreç sahibi var mı?

Bir aydır dokunmadığınız bir arka plan agent görevi seçin. Son 5 işlemini açın ve ürettiğini iddia ettiği kayıtları hedef sistemin içinde bizzat arayın. Eğer bu kayıtları bir dakikadan kısa sürede bulamıyorsanız elinizde sağlıklı bir doğrulama yoktur; sizi sahte bir yeşille oyalayan, her şeye onay veren bir durum göstergesi var demektir.

Şirketinizin yapay zeka süreçlerindeki operasyonel güvenilirliği ölçmek isterseniz, AIQ değerlendirmemiz ile hazırlık seviyenizi hemen analiz edebilirsiniz.

Sık sorulan sorular

Sessiz hata ile yapay zeka halüsinasyonu arasındaki fark nedir?

Halüsinasyon, üretilen metnin içindeki yanlış bilgidir. Sessiz hata ise metnin dışındaki eksik eylemdir: Agent harika bir fatura özeti yazabilir ama faturayı muhasebe sistemine hiç işlememiş olabilir. Biri okuyarak fark edilen bir içerik kusuru, diğeri yalnızca hedef sisteme girilerek anlaşılan operasyonel bir zafiyettir.

Agent'ın kendi hazırladığı başarı özetine güvenilebilir mi?

Hukuki ve operasyonel bir kanıt olarak kesinlikle hayır. İşi yapan sürecin kendi yazdığı özet, o işin bağımsız doğrulaması sayılamaz. Özeti sadece neleri denetleyeceğinizin bir fihristi olarak kullanın; ardından iddia edilen her değişikliği hedef sistemde tek tek teyit edin.

Mühendislik ekibi olmayan bir şirkette doğrulama kime ait olmalıdır?

Yazılımı kuran kişiye değil, o iş sürecinin ticari sorumlusuna. Doğrulama teknik bir kod testi değil, operasyonel bir iş denetimidir: Sunucunun ayakta olup olmadığını değil, faturanın müşteriye ulaşıp ulaşmadığını sorar.

Doğrulama süreci agent'ın kazandırdığı tüm zamanı alıp götürür mü?

Eğer her metni baştan sona tek tek okumaya kalkarsanız evet. Ancak hedef sistemden tekil kimlik doğrulaması yapmak, rastgele küçük bir örneklem almak ve sayısal mutabakat sağlamak haftada sadece birkaç dakikanızı alır.

Bir agent işi bir başka agent'a devrettiğinde durum değişir mi?

Aksine, denetim ihtiyacı katlanır. İki agent arasındaki devir teslimin başarılı görünmesi, sürecin son durağa ulaştığı anlamına gelmez. Zincirin nihai çıktısını hedef sistemde bizzat teyit etmeli; aradaki devirleri kesin sonuç değil sadece birer "alındı makbuzu" kabul etmelisiniz.

Bir kişi gerçekçi olarak kaç gözetimsiz agent işini doğrulayabilir?

Çoğu ekibin tahmin ettiğinden çok daha azını. Buradaki darboğaz görev sayısı değil; bir personelin tek bir oturuşta açıp kontrol edebileceği harici hedef sistem sayısıdır. Liste bu kapasiteyi aştığında kontrolleri baştan savma yapmak yerine, ya görev sayısını sadeleştirin ya da işleri unvanı belli farklı süreç sahipleri arasında paylaştırın.

Kayıt tutmaya başlamadan önce yaşanan sessiz hatalar ne olacak?

O dönemi "sorunsuz" değil, "karanlık nokta" olarak kabul edin. Şirkete en çok zarar vermiş olabilecek kritik çıktıları belirleyip hedef sistemde geriye dönük elle teyit edin ve şeffaf denetim kaydı tutmaya başladığınız milat tarihini kayda geçirin. O tarihten öncesinin henüz doğrulanmadığını açıkça kabul etmek, her şeyin yolunda gittiğini varsaymaktan çok daha dürüst ve güvenlidir.