Belirsiz Makineyi Dizginlemek: Ajan Tabanlı Yapay Zeka Dayanıklılığında Pratik Dersler

Ajan tabanlı (agentic) yapay zeka sistemlerinde karşılaşılan kendine has bir güven hatası türü vardır. Bu hata, hiç var olmamış bir kişinin özgüvenle uydurulması gibi dramatik bir halüsinasyon değildir; çok daha sessizdir. Model görevi ve veriyi anlar, ancak sonrasında "daha iyi bir fikri olduğuna" karar verir. Açık kaynaklı, yapay zeka tabanlı bir wiki motoru olan Synthadoc için içerik sağlığı bakım iş akışını geliştirirken bu durumla defalarca karşılaştık. İş akışının görevi mütevazı görünüyordu: Wiki sayfalarını yinelenen başlıklar veya zayıf bölümler gibi yapısal sorunlar açısından taramak, hedefli düzeltmeler önermek ve herhangi bir değişiklik uygulamadan önce kullanıcının onayına sunmak. Ancak süreçte keşfettiğimiz şey, model yetenekli ve niyet açık olsa bile bir ajanın nasıl yoldan çıkabileceğinin kataloğu ve çözümün neden hiçbir zaman sadece "daha iyi bir komut (prompt)" olmadığıydı.

Çözdüğümüz Sorun#

Synthadoc, PDF'ler, web sayfaları, transkriptler ve电子 tablolar gibi ham belgeleri alır ve bunları yapılandırılmış bir Markdown wiki'sine sentezlemek için bir LLM kullanır. Zamanla aynı konu birden fazla kaynaktan beslenir. Müdahale edilmezse, Alan Turing hakkındaki tek bir wiki sayfasında ## Bletchley Park and Cryptanalysis başlığının on kopyası ve ## Early Life and Education başlığının sekiz kopyası birikebilir. Sayfa kendi içinde tutarlı görünse de yapısal olarak bozuktur: yinelenen içerikler, çelişkili vurgular ve gövde metni yazılmadan önce başlık oluşturulduğu için ortaya çıkan zayıf bölümler barındırır.

İçerik sağlığı tarayıcısı tam olarak bu sorunu hedefler. Bilinçli bir tercihle, hiçbir LLM bağımlılığı olmayan saf Python tabanlı bir sezgisel (heuristic) algoritma olarak tasarlanmıştır. Deterministik düzenli ifadeler (regex) aracılığıyla şu altı sorunu tespit eder: duplicate_section, empty_section, thin_section, unclosed_code_block, orphaned_heading ve broken_list_nesting. Sürecin bu kısmı son derece güvenilirdir. Hikayenin ilginçleştiği yer ise tespit edilen bu sorunları çözmek için bir LLM kullanmaya başladığımız aşamadır.

İş Akışının Yapmasını Hedeflediğimiz Şey#

Tasarımımız oldukça netti. İşaretlenen her sayfa için şu beş adım izlenecekti:

Sayfa içeriğini ve tespit edilen sorunların listesini yükle
Her ikisini de özenle oluşturulmuş bir istemle (prompt) LLM'e gönder
Kullanıcıya yan yana ÖNCE/SONRA (BEFORE/AFTER) fark görünümü (diff) göster
Herhangi bir değişiklik yazmadan önce kullanıcı onayını bekle
Geri dönüşün (rollback) mümkün olması için önceki sürümün anlık görüntüsünü (snapshot) al

Bu tasarımdaki her adımın kritik bir amacı vardır. ÖNCE/SONRA incelemesi bir formalite değil, insan kontrol kapısıdır (human gate). Anlık görüntü, geri döndürülebilirlik garantisidir. Sezgisel tarayıcı LLM'den önce çalışır, böylece sorun listesi spekülatif değil, kesindir. İlk çalıştırmada gerçekte yaşananlar, sistem dayanıklılığında (hardening) hangi parçaların eksik olduğunu bize net bir şekilde gösterdi.

Neler Yanlış Gitti?#

Hata 1: Model Sayfayı Baştan Yazdı#

İlk sorun hemen ortaya çıktı. LLM, "Açık Kaynak Hareketi" hakkındaki sayfa içeriğini ve on iki yapısal sorundan (üç yinelenen bölüm ve dokuz zayıf bölüm) oluşan listeyi aldı. Bize geri dönen SONRA (AFTER) içeriğinin, orijinal sayfayla hiçbir yapısal benzerliği kalmamıştı.

Orijinal ## Richard Stallman and GNU (1983) ve ## The Cathedral and the Bazaar (1999) başlıkları tamamen kaybolmuştu. Bunların yerini ## Historical Framing and Origins, ### Research Computing Culture and Principled Advocacy ve ### GNU Toolchain and the Missing Kernel gibi başlıklar almıştı. İçerik olgusal olarak mantıklıydı ancak kullanıcının asla talep etmediği ve güvenle onaylayamayacağı bir çıktıydı. Çünkü orijinal metin ile önerilen sürüm arasındaki tüm izlenebilirliği (traceability) kaybetmiştik. Model, esasen kendi ön eğitim (pre-training) bilgisine dayanarak sıfırdan yeni bir wiki sayfası yazmıştı.

Yazılım Geliştirme İçin Pratik Çıkarımlar#

Deterministik ve Olasılıksal Katmanları Ayırın: Sorun tespiti gibi kesinlik gerektiren işlerde LLM yerine regex veya kurallı Python kodları kullanmak, hata payını sıfırlar ve maliyeti düşürür.
Sadece Prompt'a Güvenmeyin: Production'da ajan güvenilirliği (Agent Reliability) sağlamak için iyi bir prompt yeterli değildir; mimari sınırlar, diff kontrolleri ve versiyonlama (snapshot) şarttır.
İzlenebilirliği Koruyun: LLM'e tüm belgeyi yeniden yazdırmak yerine, yalnızca hedeflenen bölümlerde lokalize değişiklikler yapmasını zorunlu kılan yapısal kısıtlamalar uygulayın.