Daha iyi ajan performansının peşindeki çoğu yapay zekâ ekibi aynı araçlara yöneliyor: daha büyük bağlam kapasiteleri, daha fazla belge ve daha akıllı promptlar. Bu makale, bunun baştan sona yanlış bir yaklaşım olduğunu savunuyor. Eksik olan daha fazla bilgi değil. Kontrol. Demoda çalışan bir ajanla üretimde çalışan bir ajanı birbirinden ayıran, iyi tasarlanmış bir kontrol katmanıdır.
Bir yapay zekâ ajanına daha büyük bir bellek, daha fazla belge veya daha uzun bir bağlam kapasitesi vermek onu daha akıllı yapmaz; yalnızca yavaşlatır ve maliyetini artırır. Asıl kazanım, ajanın her şeyi bir kerede tüketmesi yerine neye, ne zaman ihtiyaç duyduğunu seçmeyi öğrenmesinden gelir.
Güvenilirlik modelden değil, döngüden gelir. Demoda etkileyici görünen bir ajanla üretimde ayakta kalan bir ajan arasındaki fark yapay zekânın kalitesi değil, sistemin kendi çalışmasını kontrol edip etmemesidir. Her adımda planlayan, harekete geçen, gözlemleyen ve doğrulayan ajanlar, kendinden emin biçimde hata yapmak yerine kendi hatalarını yakalar.
Günümüzde çoğu yapay zekâ ajanı, özünde ek adımları olan sohbet botlarıdır; doğru yolda olup olmadıklarını, ne zaman duracaklarını veya ne zaman farklı bir yaklaşım deneyeceklerini bilmelerini sağlayacak mekanizmalardan yoksundurlar. Net başarı ölçütleri, yapılandırılmış durum ve doğrulama kontrollerinden oluşan uygun bir kontrol katmanı eklemek, ajan biçimli bir nesneyi gerçekten güvenebileceğiniz bir şeye dönüştürür.
Dün öğle yemeğinde ne yediniz?
Muhtemelen “dün + öğle yemeği” eşleşmesini bulana kadar tüm anılarınızı baştan oynatmadınız. Doğrudan deneyimlerinizin bu kavramlarla ilgili bölümüne gittiniz. Bu, ajan geliştirirken yararlanabileceğiniz bir zihinsel modeldir:
Dev bir bağlam kapasitesi bellek değildir.
Getirilmiş bir belge yığını anlayış değildir.
Uzun bir düşünce zinciri güvenilirlik değildir.
Bunlar yalnızca bileşenlerdir. Ancak bir ajanı gerçekten ajan gibi hissettiren şey, beyninizin tüm yaşam öykünüzü kaba kuvvetle taramasını önleyen şeyle aynıdır: kontrol.
Yakın tarihli Büyük Dil Modelleri için Ajansal Akıl Yürütme araştırması, çoğumuzun geliştirme sırasında hissettiği değişimi başarıyla özetleyip adlandırdı: modelin içinde akıl yürütmeden etkileşim yoluyla akıl yürütmeye geçiş. Bu yazı, söz konusu makalenin özeti değildir. Bu değişimi pratik sistem tasarımına aktarma girişimidir:
Ajanları araçlarla donatılmış sohbet botları gibi geliştirirseniz sohbet botlarına özgü hataları almaya devam edersiniz; yalnızca hatalarınız daha pahalı olur.
Bir süre boyunca “modeli daha akıllı yapmaya” yönelik standart reçetemiz temelde şuydu: daha iyi promptlar, düşünce zinciri, öz tutarlılık/örneklemeye dayalı iyileştirmeler ve belki biraz arama.
ReAct, “düşünce → eylem → gözlem” akışını doğal hâle getirdiği için bir dönüm noktasıydı. Ancak örtük kısıta dikkat edin: Bunların çoğu hâlâ “daha çok token kullanan tek örnekli çıkarım”a dönüşüyor. Araştırmanın yaklaşımı daha net: Ajansal akıl yürütme, test zamanındaki etkileşimi ölçeklendirmeyi vurgular; çıkarımı modelin, belleğin ve ortamın döngüde kaldığı yinelemeli bir sürece dönüştürür.
Demolarda etkileyici görünen ancak gerçek iş akışlarında kırılgan olan ajanlar geliştirdiyseniz veya kullandıysanız bu yazı sizin için.
Sıkça karşılaştığım ve kesinlikle kendi sürümlerimi de geliştirdiğim bir kalıbı anlatayım:
İyi bir sohbet modeli alın
Birkaç araç ekleyin (arama, veritabanı sorgusu, belki kod yürütme)
RAG ekleyin
“Sen özerk bir ajansın” sistem promptu ekleyin
Her şeyi, durana veya zaman aşımına uğrayana kadar çalışan bir while döngüsüne sarın
Tebrikler, artık ajan biçimli bir nesneniz var. Ancak bu nesne öngörülebilir şekillerde başarısız olur:
Bağlam şişmesi: Her gözlem sona eklenir; promptlar arkeolojik katmanlara dönüşür.
Araç bocalaması: “Yanlış aracı kendinden emin biçimde kullanmak” varsayılan hata biçimi olur.
Durma koşullarının olmaması: Devam etmesi gerektiği için değil, edebildiği için devam eder.
Dayanaklandırma disiplininin olmaması: Zorlamadığınız sürece yanıldığını fark etmez.
Bellek = sohbet geçmişi: Bu, temelde günlük tutup buna öğrenme demektir.
“Ajanların” demolarda çoğu zaman sihirli, üretimde ise karmaşık görünmesinin nedeni budur. Ajansal sistemleri üretime alma deneyimimiz de bunu gösteriyor: Artık bir modeli değil sistemi değerlendiriyorsanız hata biçimleri yalnızca “model doğru yanıt verdi mi?” sorusuyla sınırlı kalmaz; yön bulma, araç disiplini, bağlamı budama ve değerlendirme tasarımını da kapsar.
O hâlde soru şu: Amaca uygun ajan nedir?
Konuyu biraz daha somutlaştırmak için çoğu kişinin gözünde canlandırabileceği basit bir iş akışı düşünelim: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Yaygın bir “ajan biçimli” uygulama şöyle görünür:
Henüz gerekmese bile hemen bir yığın hava yolu/seyahat politikası belgesi getirir.
Bir arama aracını çağırır, uzun bir sonuç listesini prompta yapıştırır ve “birini seçer”.
Kısıtları (varış saati/bagaj/koltuk/politika) doğrulamadan erkenden rezervasyon yapar.
Başarısız olursa biraz farklı bir şekilde yeniden dener ancak neyin değiştiğini veya ne öğrendiğini açıkça bilmez.
Sorun modelin akıl yürütememesi değil, sistemin iş akışını kontrol etmemesidir.
Daha ajansal bir sürüm, görevi açıkça belirtilen durum ve kontroller içeren etkileşimli bir süreç olarak ele alır:
PLANLA: Kısıtları yeniden belirt ve eksik bilgileri listele (ör. “hangi havalimanını tercih edersiniz?” / “1 aktarma uygun mu?”).
HAREKETE GEÇ: Yapılandırılmış bir sorguyla (tarih aralığı, varış kısıtı, bütçe) uçuş aramasını çağır.
GÖZLEMLE: Sonuçları dev bir metin yığını olarak yapıştırmak yerine kompakt bir durum nesnesinde sakla (fiyat/varış/aktarma bilgileriyle en iyi 5 seçenek).
GÜNCELLE: Kısıtlar karşılanmıyorsa sorguyu iyileştir (ör. “18.00'den önce varış fazla kısıtlayıcı; saat aralığını genişletelim mi, bütçeyi artıralım mı?”).
DOĞRULA: Doğrulayıcıları çalıştır (“varış < 18.00”, “fiyat ≤ £900”, “politikalara uygun”, “koltuk seçimi mevcut”).
DUR: Yalnızca rezervasyon API'si onay döndürdüğünde ve tüm doğrulayıcılar başarılı olduğunda.
Değişiklik küçük görünse de belirleyicidir. Veri getirme koşulludur (refleks değildir), bağlam yönetilir (durum biriktirilmez, yapılandırılır) ve doğrulama döngünün içindedir (kullanıcıya bırakılmaz). “Uçak bileti rezervasyonu” yerine “satın alma siparişi oluşturma”, “para iadesi yapma”, “üretim yapılandırmasını değiştirme” veya “PR yayımlama” ifadelerinden birini koyun; durum aynıdır: Ajan harekete geçebildiğinde döngü prompttan daha önemli olur.
Yukarıda anılan araştırma, ajansal akıl yürütmeyi üç katmana ayırıyor: temel (planlama/araç kullanımı/arama), kendini geliştiren (geri bildirim + bellek) ve kolektif (çok ajanlı koordinasyon).
Ancak daha derindeki fikir şu: Akıl yürütme, yalnızca makul görünen bir düşünce zinciri üretmekten ibaret değildir; planlama, karar verme ve doğrulamanın düzenleyici ilkesi hâline gelir. Mimarinizi nasıl değiştirdiğine bakana kadar bu fikir soyut gelebilir. Hatırlanması gereken üç temel nokta var:
İyi bir ajan, veri getirmeyi “her zaman yapılacak bir şey” olarak görmemelidir. Veri getirme bir karardır, refleks değil.
Pratik bir kural:
Sisteminiz her turda veri getiriyorsa bir veri getirme mekanizması değil, bağlam vergisi oluşturmuşsunuzdur.
Gerçek işlerde bununla sürekli karşılaşılır. Üretimdeki bir olayı incelerken tüm günlükleri bağlama yığmazsınız; mevcut hipotezinize göre hangi metrikleri/günlükleri sırada getireceğinize karar verirsiniz. “Ajansal veri getirme” budur. Daha somut bir kalıp şöyle:
Veri getirmenin gerekip gerekmediğine karar ver
Gerekiyorsa: sorgu hazırla, verileri getir, gözden geçir ve ayıkla
Kanıtlar çelişiyorsa yeniden veri getir
Ancak bundan sonra sentezle
“Ajansal RAG” de geleneksel RAG'den burada ayrılmaya başlar: Veri getirme, varsayılan bir işlem hattı aşaması değil, bilinçli bir akıl yürütme adımı olur.
“Bir modeli” değerlendirmeyi bırakıp “bir sistemi” değerlendirmeye başladığınız anda durum takibi ve izleme önem kazanır.
Sektörün artık daha açık biçimde ele aldığı konulardan biri, ajan iş akışlarının gözlemlenebilirliğidir. Örneğin OpenAI Agents SDK, yerleşik izleme özelliği ve ajan çalıştırmalarını (üretimler, araç çağrıları, devirler, güvenlik bariyerleri ve özel olaylar) kaydeden bir Traces panosuyla gelir; böylece ne olduğunu adım adım hata ayıklayabilir ve denetleyebilirsiniz.
Bu, “olsa iyi olur” denecek bir özellik değildir. Hata ayıklayabildiğiniz bir sistemle yalnızca sezgisel olarak kontrol edebildiğiniz bir sistem arasındaki farktır.
Bence araştırmanın uygulamaya en kolay dönüştürülebilecek yanı, geri bildirim konusunda son derece net olmasıdır. Geri bildirimi üç düzene ayırır: yansıtıcı geri bildirim (üret → eleştir → düzelt), parametrik uyarlama (ince ayar/RL yoluyla öğren) ve doğrulayıcı odaklı geri bildirim (doğrulayıcı onaylayana kadar yeniden dene).
Çoğu ekip, sıkıcı ama etkili olduğu için doğrulayıcı odaklı geri bildirimle başlamalıdır. Birim testleri yapan, şemayı kontrol eden, iş kuralları/kısıtları belirleyen (“üst mercie iletmeden X üzerindeki tutarlar iade edilemez”) veya olgusal doğruluğu güvenceye alan (“kaynak göstermek zorunludur”) herhangi bir doğrulayıcı yazabiliyorsanız deterministik olmayan model çıktısını gerçekten güvenebileceğiniz bir şeye dönüştürebilirsiniz.
Buradaki “bilmediğimizi bilmediğimiz” değişimlerden biri basit: Ajan dünyasında güvenilirlik çoğu zaman modelden çok döngüden gelir.
Eğitim gerektirmeden davranışı güvenilir biçimde iyileştirdiğini gördüğüm en basit döngü disiplini şöyle:
Adımlar hâlinde ilerleyin: Planla → Harekete Geç → Gözlemle → Güncelle,
Her Harekete Geç adımından sonra Gözlemi 1-3 maddeyle özetleyin,
Başarı ölçütleri karşılandığında veya bütçe sınırına ulaşıldığında durun; bilinen en iyi sonucu ve kalan belirsizlikleri sunun.
Amaç modeli gereksiz yere uzun konuşturmak değil. Amaç sistemi anlaşılır kılmak ve her adımda “gerçeklikle temas” etmeye zorlamaktır. Mühendislerin kolayca bağ kurabileceği bir örnek, CI tarzı kapalı döngü dayanaklandırmadır:
Planla: değişiklik listesini öner
Harekete geç: testleri/lint denetimini çalıştır
Gözlemle: hataları ayrıştır
Güncelle: yama uygula ve yeniden dene
Tesadüfen ajan benzeri hâle gelmiş tasarımları ortaya çıkaran birkaç soru:
“Ajanım neyi getireceğini seçiyor mu, yoksa ben her zaman veri mi getiriyorum?”
Veri getirme koşulsuzsa gecikme, maliyet, bağlamın sulanması ve hatalı girdiden hatalı çıktı alma riskinin artmasıyla bedel ödersiniz.
“Ajanım yanıldığını fark edebiliyor mu?”
Ajanınızın tek geri bildirim sinyali “kullanıcının sinirlenmesi” ise insanların çektiği sıkıntıyla RL yapıyorsunuz demektir. Doğrulayıcı odaklı bir yeniden deneme döngüsü, ajanı gerçekle yüzleştirmenin en temiz yoludur.
“Belleğe yazılabiliyor mu ve bellek zamanla gelişiyor mu?”
“Belleğiniz” yalnızca sohbet geçmişini sonuna ekliyorsa aslında günlük tutuyorsunuz demektir. Araştırmanın belleği ele alış biçimi önemli: Bellek yalnızca bir döküm değil, ajanların zaman içinde iyileştirdiği ve dinamik olarak büyüyen bir bağlamdır.
Günlükler ne olduğunu, bellek ise bir dahaki sefere ne yapılacağını söyler. Sohbet geçmişi bir dökümdür. Bellek, nelerin geleceğe taşınmaya değer olduğuna ilişkin gelişen bir politikadır.
Başlangıç için pratik bir çözüm; görev türü, araç ve hata biçimini anahtar, işe yarayanlar ile kaçınılması gerekenleri de değer olarak kullanan küçük bir “çıkarılan dersler” tablosudur. Amaç kusursuz bir bilgi grafiği oluşturmak değildir. Amaç, etkisi katlanarak artan bir davranış oluşturmaktır: Bellek ve geri bildirim, ajanları “durumsuz yardımcılardan” zamanla gelişen sistemlere dönüştürür.
Soruna daha fazla ajan yöneltmek cazip gelse de bu yaklaşım çoğu zaman koordinasyon yükünü katlar. İyi bir “asgari uygulanabilir ekip” kalıbı:
Koordinatör: görevi parçalara ayırır ve atar
Yürütücü: araç çağrılarını/değişiklikleri gerçekleştirir
Eleştirmen/değerlendirici: doğruluğu/riski kontrol eder
Bellek sorumlusu: dersleri kaydeder/düzenler
Her ajanın sorumluluğunu açıklayamıyorsanız muhtemelen henüz birden fazla ajana ihtiyacınız yoktur.
Bu paradigma değişimini gerçekten benimsiyorsak muhtemelen her şeyi promptlara doldurmayı, hataları nihai çıktı olarak görmeyi ve ajanları sohbet botları gibi değerlendirmeyi bırakırız. Ajanları gerçekte oldukları gibi ele almaya başlarız: Dilin kontrol düzlemi olduğu ve güvenilirliğin döngüden geldiği yazılım sistemleri.
Yeni bir model eklemeden önce yeni bir değerlendirme döngüsü ekleyin. Her şeyi getirmeden önce veri getirmeyi koşula bağlayın. On tane yayımlamadan önce tek bir doğrulayıcıyı kullanıma sunun. Belleği veritabanı gibi değil, politika kararları olarak ele alın. Çok ajanlı sisteme geçerken yirmi ajanla değil, iki ajanla başlayın. Bunlar kural değil; üretim ortamında ayakta kalan kalıplardır.