Ajan tabanlı sisteminizde kararların nasıl ve nerede alındığını dikkatle değerlendirmek önemlidir.
Daha fazla kararı LLM’ye bırakmak, sistemin daha çok göreve genellenebilmesini sağlayabilir; ancak bunun bedeli hız, güvenilirlik ve dayanıklılık olabilir.
Mümkün olduğunda karar verme sürecinin olabildiğince büyük bir bölümünü LLM’den çıkarıp açık yazılım koduna aktarın. Bu, özellikle yüksek riskli ve/veya üretim ortamındaki iş akışları için geçerlidir.
LLM tabanlı bir ajan sistemi tasarlarken vermeniz gereken en önemli kararlardan biri, karar verme sürecinin ne kadarının bir LLM modelinde, ne kadarının açık yazılımda yer alacağıdır.
Bu tercihi daha iyi anlamak için aşağıdaki yaklaşımlar arasında uzanan bir yelpaze olarak düşünebiliriz:
Yönlendirici tabanlı mimariler, sıralamayı ve mantığı kod içinde açıkça tanımlayarak dar kapsamlı görevlerde test edilebilirlik, öngörülebilirlik ve dayanıklılık sağlar (bunlara “iş akışı ajanları” da denir).
Orkestratör ajanlar, görev akışlarına doğal dil istemleriyle dinamik olarak karar vermek için büyük dil modellerinden (LLM’lerden) yararlanır; bu yaklaşım, önceden tanımlanmış mantığın yetersiz veya olanaksız olduğu açık uçlu etkileşimler için idealdir.
Yüksek riskli üretim iş akışlarında genellikle yönlendirici tabanlı özelliklerin daha fazla kullanılmasını, orkestratörlerin ise esnek ve genel amaçlı konuşmalar gerektiren uygulamalara ayrılmasını öneriyoruz.
Yönlendirici Tabanlı Mimariler
Yönlendirici ajan sistemleri:
Karar verme akışını kod/yazılım aracılığıyla açıkça tanımlar ve yazılımın hangi yolu izleyeceğini belirlemek için bir LLM kullanır.
Daha tutarlı sonuçlar sağlayan açık ve öngörülebilir yollara sahip olmaları bakımından geleneksel yazılım sistemlerine daha yakındır.
Kesin biçimde tanımlanabilen görevler için idealdir.
Aşağıda, “Yönlendirici yaklaşımını” kullanan bir Havayolu Sohbet Botu Rezervasyon ajanına ait basit bir örnek yer alıyor. LLM, sorunun amacını üç olası seçenekten biri olarak sınıflandırmamıza yardımcı olsa da bu amacı şablon bir metin yanıtıyla eşleştiren sonuçta yazılımımızdır. LLM büyük ölçüde kısıtlandığı için kullanıcı daha tutarlı bir davranışla karşılaşır.
Orkestratör Mimarileri
Yönlendirici sistemlerin aksine orkestratör ajan sistemleri:
Mantık akışlarını yazılım yerine doğal dil istemleriyle tanımlar. Not: Bir programlama diliyle karşılaştırıldığında doğal dil doğası gereği belirsiz ve esnektir (ileride ele alacağımız üzere bu, hem olumlu hem de olumsuz bir özelliktir). Bunu “talimat yerine niyet” olarak düşünüyoruz.
Birden fazla işleme seçeneği sunabilir; yürütme sırasını ve yöntemini LLM belirler.
Yazılımda açıkça tanımlanması zor olan yeni mantık yollarını dinamik biçimde oluşturabilir.
Bu belirsizlik tutarsız çıktılara yol açabilir; ancak sistem işe yaradığında “sihirli” bir deneyim sunabilir.
Aşağıdaki örnekte aynı basit havayolu problemine orkestratör yaklaşımı uygulanıyor. Hangi yanıtın uygun olduğuna yazılımın karar vermesi yerine karar verme süreci LLM katmanına devredilir. Burada, “yönetici” bir orkestratör ajanın kullanıcı sorgusunu önceliklendirip uçuş değişiklikleri için özel olarak tasarlanmış bir ajana devrettiği ve bu ajanın sonuçta kullanıcıya yanıt verdiği çok ajanlı bir sistem bulunuyor.
Bu örnekte LLM katmanı sınıflandırıcı, yönlendirici ve yanıt yazarı rollerini üstlenir. Yönlendirici örneğinde ise yalnızca sınıflandırıcı rolündeydi; geri kalan işleri yazılım yürütüyordu.
Mümkün olduğunda, aşağıdaki avantajları sundukları için yönlendirici tabanlı yaklaşımları kullanmanızı öneriyoruz:
Hız ve verimlilik: Yerel hesaplamalar, harici API’lere bağımlı orkestratörlere kıyasla daha yüksek hız sunar. Ayrıca “IF/ELSE” mantığınızı Python’da işlemek, bunu 400 milyar parametreli modelinden geçirmek için bir LLM sağlayıcısına ödeme yapmaktan çok daha ucuzdur.
Test edilebilirlik ve öngörülebilirlik: Yerleşik yazılım uygulamaları sayesinde hata ayıklama, test ve bakım önemli ölçüde kolaylaşır.
Şeffaflık ve güvenilirlik: Davranıştaki değişkenliğin azalması, sorun gidermeyi kolaylaştırır. Ayrıca uygulama akışının daha büyük bir bölümü, bir LLM’nin opak ve yorumlanamaz ağırlıkları yerine şeffaf ve sürüm denetimli yazılımla ifade edilir.
Yönlendirici yaklaşımların dezavantajı ise katı ve esneklikten uzak olabilmeleri, daha açık uçlu problemlerde zorlanabilmeleridir. Her zaman tamamen aynı yanıtları veren bir sohbet botu, kullanıcılar tarafından sıkıcı veya durağan bulunabilir.
Orkestratör tasarımları güçlü yeteneklere sahiptir:
Planlama: Yanıtları dinamik olarak planlayabilirler.
Araç Seçimi/Ajana Devir: Uygun araçları seçebilir veya görevleri ajanlara devredebilirler.
Çıktıların Yinelemeli Birleşimi: Çıktıları yinelemeli ve yaratıcı biçimde yeniden birleştirebilirler.
Tamamlanmanın Belirlenmesi: Bir yanıtı tamamlamak için yeterli bilgi toplanıp toplanmadığını belirleyebilirler.
Pydantic-AI veya OpenAI Agents SDK gibi çerçeveler, orkestrasyonun kolay ve hızlı biçimde uygulanmasını sağlar. Bu nedenle demolar ve kavram kanıtları için çok uygundur.
Bu yaklaşımın dezavantajları şunlardır:
LLM’nin planlama adımlarının ve sonraki eylemlerinin doğru ya da uygun olacağı garanti edilemez. Yönlendirici sistemde de aynı sorun vardır; ancak sistem daha kısıtlı olduğu için davranışı daha öngörülebilirdir.
Basit ve iyi tanımlanmış görevlerde çok ajanlı bir sistemin tüm yeteneklerine ihtiyaç duymamız pek olası değildir. Örneğin Havayolu Ajanı örneğimizde, bir havayolu destek sistemiyle etkileşime giren kişinin gerçekleştirmek isteyeceği sorgu türlerinin sayısı muhtemelen sınırlıdır.
Mantığın daha büyük bir bölümü LLM’de bulunduğundan sistem, kötü niyetli kişilerin jailbreak veya istismar girişimlerine çok daha açıktır.
Karar verme sürecini soyutlayarak LLM’ye taşır ve bu nedenle sisteminizi anlamayı zorlaştırır (ancak Langfuse veya Braintrust gibi izleme araçları buna kısmen yardımcı olabilir).
Okura not: Model yetenekleri hızla değişse de aşağıdakilerin yakın gelecekte değişmesi pek olası değildir.
Probleminizin kapsamını belirleyin.
İstediğiniz karar mantığını bir diyagramda kolayca tanımlayabiliyor musunuz?
Uygulamanızda hataya veya beklenmedik davranışlara tahammülünüz yok mu?
Yukarıdakilerden birine “evet” yanıtı vermeniz, yönlendirici özelliklerin daha uygun olacağını gösterir.
Mümkün olduğunda ve yeterli kaldığı sürece yönlendirici yaklaşımları kullanmanızı öneriyoruz. Genel bir ilke olarak, sisteminizin bir bölümü kodla ifade edilebiliyorsa onu kodla ifade edin (yani gerekmediğinde LLM’leri aşırı kullanmayın).
Bu yaklaşımların sınırlarına ulaşıldığında, orkestratörlerin açık uçlu avantajlarından bazıları kısıtlı biçimde yeniden oluşturulabilir. Örneğin:
Araç Seçimi/Ajana Devir: Koşullu dallanma veya LLM sınıflandırıcılarıyla kolayca uygulanabilir.
Tamamlanmanın Belirlenmesi: Basit LLM sınıflandırıcıları, yanıt kullanıcıya gönderilmeden önce tamamlanıp tamamlanmadığını denetleyebilir.
Ancak “Planlama” ve “Çıktıların Yinelemeli Birleşimi” özelliklerini katı bir yönlendirici sistemde gerçekleştirmek kuşkusuz çok daha zordur. Bu nedenle bir görev bu özellikleri gerektirdiğinde (bir LLM sınıflandırıcısı veya başka bir mantık tarafından belirlendiği üzere) sisteminizde daha az kısıtlı bir orkestratör dalı oluşturmanızı öneriyoruz.
Yönlendirici ve orkestratör mimarileri arasındaki tercihiniz, uygulamanızın netliğini, karmaşıklığını ve etkileşim biçimini yansıtmalıdır. Yönlendirici tabanlı yaklaşımlar günümüzde açıkça tanımlanmış görevler için güvenilirlik, verimlilik ve test kolaylığı sağlar. Orkestratörler, daha geniş kapsamlı ve konuşmaya dayalı etkileşimlerde daha fazla esneklik sunar.
LLM’ler gelişmeye devam ettikçe bu yaklaşımlar arasındaki denge değişebilir. Üretim iş yüklerinde yönlendirici tabanlı veya hibrit mimarileri tercih ediyor; orkestratörleri ise dinamik ve insan benzeri etkileşim gerektiren açık uçlu problemlere ayırıyoruz.