İki Ajan Sistemi Geliştirdim: Her Biri Diğerinin Hatalı Olduğunu Kanıtladı

Biri diğer LLM'in planını denetleyen, diğeri ise iki LLM'in bir Pull Request'i (PR) tartıştığı iki farklı ajan mimarisi geliştirdim. İlginç olan şu ki; her iki sistem de diğerinin engellemek üzere tasarlandığı senaryoda başarısız oldu. Onlara güvenebilmemin yegane sebebi tam olarak bu arızaları anlamaktı. Eğer sistem güvenliğini sadece bir prompt talimatına emanet ediyorsanız, her iki senaryonun da sonu kaçınılmaz bir hüsrandır.

1. Sistem: Güvenilir Kılmayı Başaramadığım — ve Zaten Mecbur Olmadığım — Eleştirmen

PlannerCritic, taslak → eleştiri → revizyon döngüsü işletir: İlk model planı oluşturur, ikincisi eleştirir ve sınırlı bir döngü uzlaşma sağlanana veya insan onayına yönlendirilene kadar revize eder. İlk mühendislik refleksim, eleştirmene prompt ile "hasmane/muhalif ol" (adversarial) talimatı vermek oldu. Ancak bu davranışsal müdahale ters tepti; eleştirmen planları "yeterince kapsamlı değil" gibi işlevsiz gerekçelerle engellemeye başladı. Çözüm olarak, ciddiyet sözleşmesini (severity contract) prompt katmanından çıkarıp koddaki değişmez bir yapıya (frozenset) taşıdım.

170 hedef üzerinde 0.49 dolarlık maliyetle yapılan saha testi şu sonuçları verdi:

Critic label_flip_rate: 1.0 — Özdeş girdilerde model her denemede kararını değiştirdi.
Critic evidence_drift_rate: 1.0 — Kararın arkasındaki gerekçeler ve kanıtlar sürekli kaydı.
underclaim_approvals: 0 — Sisteme yerleştirilen hiçbir kusurlu plan onay almadı.
family_migration_rate: 0.0 — Kusurlar başka sınıflara sızmadı.
Gerçek Başarısızlık (True failures): 0 — Üretim seviyesinde hiçbir güvenlik ihlali yaşanmadı.

Tamamen deterministik olmayan bir eleştirmen, arkasındaki deterministik geçitler (gates) güvenlik sınırını üstlendiği için kusursuz bir güvenlik sağladı. Modelin kendisi asla nihai güvenlik sınırı olmamalıdır.

2. Sistem: Aslında Yalnızca Bir "Yankı" Olan Münazara

AdversarialDebate, iki izole modelin aynı PR'ı bağımsız inceleyip ya bir kararda uzlaşmasını ya da görüş ayrılığını korumasını hedefler. Buradaki arıza daha sinsidir: İkinci modele prompt üzerinden "bağımsız ol" dendiğinde sistem çalışıyor gibi görünüyordu. Ancak ham loglar incelendiğinde münazaranın bir illüzyondan ibaret olduğu anlaşıldı; ikinci model ilk modelin ürettiği metinleri tekrarlıyordu ve görüşlerin %89'u sahte bir tiyatroydu.

Prompt düzeyindeki bağımsızlık kaldırılarak mimari seviyede mekanik izolasyon getirildi: İzole bağlamlar, paylaşımsız sonuç ve iddia başına kanıt zorunluluğu uygulandı. Sonuçlar çarpıcıydı:

Tiyatro oranı 217 münazarada %89'dan %0'a geriledi.
70 açık kaynak PR üzerindeki 411 münazarada insan inceleme iddialarıyla %81 eşleşme yakalandı.

Yakınsama: İki Sistemin Ortak Dersi

İki çözüm karşılaştırıldığında aslında aynı temel kurala dayanmaktadır:

Sistem	Yapısal Problem	Prompt Denemesi	Gerçek Çözüm
PlannerCritic	Güvenilmez ciddiyet sözleşmesi	"Muhalif ol"	Koddaki sözleşme (`frozenset`) + deterministik kapılar
AdversarialDebate	Sahte bağımsızlık	"Bağımsız ol"	Mekanik izolasyon kuralı

Her iki örnekte de yapısal bir sorunu prompt ile çözmeye çalışmak hatalı katmandı. Güvenlik sınırı model değil, yazılım mimarisidir.

Bu Çıkarım Neden Genellenebilir? (İhtiyatla)

Bu iki sistem kesin kanıt olmasa da kritik bir yazılım pratiğini işaret eder: LLM'leri güvenilir kılmaya çalışmayı bırakın; onları güvenlik açısından önemsiz hale getirin. Deterministik olmayan katman istediği kadar esnek çalışsın, ancak nihai ve kritik kararları kod düzeyindeki deterministik kurallara bağlayın.

Dürüst Bir Sınırlılık

Bu mimariler kusursuz değildir:

PlannerCritic yapısal plan kusurlarını yakalar ancak karmaşık mantık hatalarını kaçırabilir.
AdversarialDebate modelinde ise henüz açıklanamayan %11.3'lük bir ıskalama oranı mevcuttur.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.