.avif)
.avif)
.avif)
Sektörün, her şeyi bilen tek bir asistan yerine uzmanlaşmış asistanlara yönelmesi doğru bir adımdı. Tüm talimatları, araçları ve kuralları tek bir prompt'ta toplamak, yapı büyüdükçe odağın kaybolmasına ve halüsinasyon riskinin artmasına neden oluyor. Yeni bir senaryo eklemek de tüm sistemin yeniden test edilmesini gerektiriyor. Bu yükü, her biri kendi talimatlarına, bilgi kaynaklarına ve araçlarına sahip uzmanlaşmış asistanlara dağıtmak ve bunları bir üst asistanın yönetmesi, değişikliklerin etkisini ilgili alanla sınırlı tutarken talimatları da kısa tutuyor. Biz de bu mimariyi temel alıyoruz ve hâlâ doğru yaklaşım olduğuna inanıyoruz.
Ancak bu mimarinin gerçek kullanımda ne kadara mal olduğu daha az konuşuluyor. Her devirde konuşma geçmişi bir sonraki asistana aktarılıyor. Üst asistana yapılan her dönüş, o ana kadar biriken konuşma geçmişinin yeniden işlendiği yeni bir model çağrısı anlamına geliyor. Bir aracın ürettiği sonuç, asistan işini bitirdikten çok sonra bile bağlam penceresinde kalıyor ve sonraki her turda yeniden işlenmesinin maliyeti ödeniyor.
Bu maliyeti fark etmek kolay değil; çünkü her turda ortaya çıkmıyor. Konuşmayı devralan bir alt asistan, konu kendi uzmanlık alanında kaldığı sürece müşteriye doğrudan yanıt veriyor ve üst asistan devreye girmiyor. Üst asistan ancak konuşmanın başka bir uzmana aktarılması gerektiğinde yeniden devreye giriyor. Bu nedenle maliyet, görüşme boyunca eşit dağılmıyor; belirli anlarda sıçrama yapıyor. Üstelik bu sıçramalar tam da en elverişsiz anda yaşanıyor: konuşma geçmişi en uzun hâline ulaştığında, müşteri hâlâ sorununu çözmeye çalışırken ve yanıt beklerken.
Servis randevusu oluşturmak isteyen bir müşteriyi düşünelim. Bir uzman hangi ürünün söz konusu olduğunu belirliyor. Bir diğeri müşterinin adını ve telefon numarasını alıyor. Başka bir uzman adresi doğruluyor. Sonuncusu da uygun bir randevu saati buluyor. Müşteri açısından bunların hepsi, bir kez iletilen tek bir talebin parçaları. Bu iyileştirmeler yapılmadan önce her adımın sonunda görüşme yeniden üst asistana aktarılıyordu. Üst asistan da sıradaki adımı ve kimin konuşacağını belirlemeden önce o ana kadar söylenen her şeyi yeniden işliyordu.
Anthropic, Haziran 2025'te kendi geliştirdiği çoklu asistan araştırma sistemine ilişkin mühendislik ölçümlerini yayımladı. Çalışmada şu bulguya yer verildi: “Verilerimizde asistanlar, sohbet etkileşimlerine kıyasla genellikle yaklaşık 4 kat daha fazla token kullanıyor; çoklu asistan sistemlerinde ise bu oran yaklaşık 15 kata çıkıyor.” Bunun bağımsız bir analist araştırması değil, bir model sağlayıcısının kendi sistemine ilişkin ölçümü olduğunu göz önünde bulundurmak gerekiyor. Aynı çalışmada şu sonuç da paylaşılıyor:
“Token kullanımı, gözlemlenen değişkenliğin %80'ini tek başına açıklıyor. Araç çağrılarının sayısı ve model seçimi ise diğer iki açıklayıcı faktör.”
Kaynak: Anthropic Engineering, “How we built our multi-agent research system” (13 Haziran 2025) https://www.anthropic.com/engineering/multi-agent-research-system
Dolayısıyla sistemi yönetilebilir kılan yaklaşım, aynı zamanda onu yavaşlatan ve maliyetli hâle getiren unsurlardan biri. Üstelik maliyet, mimari diyagramına bakıldığında ilk akla gelen yerde ortaya çıkmıyor. Üretim ortamında çalışan çoklu asistan sistemlerinin maliyetini, asistanların kendi iç işleyişinden çok aralarındaki geçişler belirliyor.
Bağlamı korumayı ücretsiz bir güvence gibi gören bir yaklaşım var: Asistanın ihtiyaç duyabileceği ihtimaline karşı her şeyi saklamak. Ancak ölçümlere dayalı bulgular bu yaklaşımı desteklemiyor.
Chroma Research, Temmuz 2025'te GPT-4.1, Claude 4, Gemini 2.5 ve Qwen3 ailelerinden 18 modeli kapsayan bir değerlendirme yayımladı. Görev sabit tutulurken girdi uzunluğu değiştirildi. Araştırma, “Girdi uzunluğu değiştikçe model performansı, basit görevlerde bile önemli ölçüde farklılık gösteriyor” ve performans “girdi uzadıkça giderek daha az güvenilir hâle geliyor” sonuçlarına ulaştı. Farklı model ailelerini kapsayan bu araştırmanın ortaya koyduğu eğilim, uzun görüşme geçmişlerinde hata ayıklayanların gözlemlediği durumla da örtüşüyor.
Kaynak: Chroma Research, “Context Rot: How Increasing Input Tokens Impacts LLM Performance” (July 2025).
Bu bulgu, konuyu yalnızca bir verimlilik artışı olarak değerlendirmemek gerektiğini gösteriyor. Bir arıza tespit aracı, kapsamlı ve yapılandırılmış bir veri çıktısı döndürüyor. Asistan bu çıktının yalnızca bir alanını kullanarak müşteriye yanıt veriyor. Ancak 15 tur sonra bile çıktının tamamı her yeni istekte bağlamda tutuluyor. Böylece müşterinin az önce yazdığı cümleyle birlikte modelin dikkatini çekmek için yarışıyor. Bu gereksiz veriyi kaldırmak yalnızca bir temizlik işlemi değil. Burada maliyet ve yanıt kalitesi aynı yönde iyileşebiliyor; dolayısıyla ikisi arasında bir ödünleşim yapmak gerekmiyor.
Bu maliyetlerin her biri, ortadan kaldırılabileceği belirli bir noktaya sahip. Canlı ortamda çalışan bir sistemde, asistanlar arasında aktarılan bağlamı ve kontrolü değiştiren üç iyileştirme aynı anda devreye alındı.
Birbirine ihtiyaç duyan iki uzman, üçüncü bir asistan üzerinden iletişim kurmak zorunda kalmamalı.
Yaygın tasarımda, yönlendirme kararlarının tek bir noktadan yönetilmesi için üst asistan tüm yönlendirmeleri üstlenir. Konu aynı uzmanın alanında kaldığı sürece bu ek maliyet yaratmaz. Ancak konu başka bir uzmana geçtiğinde maliyet artar. Çünkü o ana kadarki konuşma geçmişinin yeniden işlendiği yeni bir model çağrısı yapılır ve müşteri bu sırada bekler.
Sub-Agent Collaborations, bir alt asistanın görüşmeyi doğrudan başka bir alt asistana aktarmasını sağlar. Bu aktarım tek yönlü veya iki yönlü olabilir. Böylece hangi ürünün söz konusu olduğunu belirleyen asistan, iletişim bilgilerini alan asistana doğrudan geçiş yapar; o asistan da görüşmeyi adresi doğrulayan uzmana aktarır. Üst asistana yeniden danışmaya gerek kalmaz. Birikmiş konuşma geçmişi üzerinden yapılan model çağrısı kısaltılmaz; tamamen ortadan kaldırılır. Konuşma geçmişi paylaşıldığı için görüşmeyi devralan asistan kaldığı yerden devam eder ve müşteri aynı bilgileri tekrar vermek zorunda kalmaz.
Yönlendirme kararı zaten belliyse bunu vermesi için bir model çağrısı yapmayın.
Yaygın tasarımda, sıradaki adımı belirlemek asistanların görevi olduğu için bir sonraki konuşmacıya da asistan karar verir. Ancak her geçiş bir karar gerektirmez. Bir araç müşterinin hangi ürüne sahip olduğunu kaydettiğinde sıradaki asistan zaten bellidir: Belirli bir ürün kategorisi her zaman bir uzmana, başka bir kategori ise diğerine yönlendirilir. Bu noktada ayrıca bir değerlendirme yapılmasına gerek yoktur.
Bu nedenle araç, işlemini tamamladığı anda kendi yanıtında sıradaki asistanı belirtir. Benzer şekilde araç, talebin türünü kaydettiğinde görüşmeyi doğrudan ürün değişimi veya yedek parça konusunda uzmanlaşmış asistana aktarabilir. Bu geçiş için hiçbir model çağrısı yapılmaz; çünkü modele sorulması gereken bir karar yoktur.
Bu yaklaşımın bir sınırı da vardır. Sıradaki adımın önceden belirlenemediği durumlarda kararı yine model vermelidir. Böyle durumlarda karar için model çağrısı yapmanın maliyeti, yanlış yönlendirme yapmanın maliyetinden daha düşüktür.
İşlevini tamamlamış bir araç çıktısının maliyetini her turda yeniden ödemeyin.
Buradaki risk gerçek: Asistanın hâlâ ihtiyaç duyduğu bir bilgiyi kaldırmak, maliyeti düşürürken sistemin başarısını da olumsuz etkileyebilir. Bu nedenle Context Pruning ayarı tüm sistem için genel bir kural olarak değil, her araç için ayrı ayrı tanımlanır. Bir aracın çıktısı, belirli sayıda müşteri turu geçtikten sonra veya görüşme başka bir asistana aktarıldığında bağlamdan çıkarılabilir. Geriye yalnızca ilgili araç çağrısının gerçekleştiğini belirten bir not kalır.
Adres doğrulama ve garanti sorgulama çıktıları, görüşme başka bir asistana aktarıldığında kaldırılır. Adres doğrulandıktan sonra doğrulama sonucu geçerliliğini korur; ayrıntılı veri çıktısını bağlamda tutmaya devam etmek gereksizdir. Uygun randevu saatlerinin listesi ise farklıdır. Müşterinin seçenekler arasından seçim yapabilmesi için bu bilginin bir veya iki tur boyunca korunması gerekir. Bu nedenle liste yalnızca gerektiği süre boyunca tutulur, ardından sonraki her istekte yeniden işlenerek maliyet yaratmadan önce bağlamdan çıkarılır.
Bir ayarı yapılandırmakla doğru kararı vermek arasındaki fark budur.
Bir hafta arayla, haftanın aynı günlerini kapsayan iki dönemin üretim verilerini karşılaştırdık. Her iki dönemde de on binlerce çağrı yer aldı. Aşağıdaki sonuçlar bir örneklemden değil, gerçek müşteri görüşmelerinden elde edilen ortalama değerleri yansıtıyor.
Bir hafta arayla, haftanın aynı günlerini kapsayan iki döneme ait üretim verileri. Her dönemde on binlerce çağrı yer alıyor.
Müşterinin doğrudan hissedebileceği en belirgin değişim, aynı zamanda en büyük kazanım oldu. İlk token'ın üretilmesine kadar geçen ortalama süre %31 azaldı. Bu süre, müşterinin konuşmasını bitirmesiyle sistemin yanıt vermeye başlaması arasındaki zamanı ifade ediyor. Bir müşteri sistemin neden yavaş olduğunu açıklayamayabilir ama yanıt beklediğini fark eder.
Sistemin işlediği veri miktarı da azaldı. Oturum başına ortalama token sayısı 76,5 binden 68,2 bine gerileyerek %11 düştü. Ortalama görüşme süresi ise 135 saniyeden 126 saniyeye inerek %7 azaldı.
Daha kısa süren bir görüşme, müşterinin sonuç alamadan vazgeçtiği anlamına da gelebilir. Bu nedenle görüşme süresindeki düşüş tek başına bir başarı göstergesi değildir. Self-servis oranı yaklaşık %70 seviyesinde sabit kaldı. Yani arayan müşterilerin aynı oranı, ihtiyaçlarını bir çalışanla görüşmeye gerek kalmadan karşılamayı sürdürdü. Diğer göstergeleri anlamlı kılan da bu sonuç. Aksi durumda rakamlar, aynı işi daha az kaynakla yapan bir sistemi değil, daha az iş yapan bir sistemi gösteriyor olabilirdi.
Bu karşılaştırmanın sınırlarını da açıkça belirtmek gerekir. Canlı ortamda elde edilen iki dönemin verilerini yan yana koymak kontrollü bir deney değildir. Ayrıca üç değişiklik aynı anda devreye alındığından, sonuçlardaki iyileşmeyi tek başına herhangi bir değişikliğe bağlamak mümkün değildir.
Bu sonuçların maliyetin ötesinde bir etkisi de var. Kapasite önceden satın alındığı için sistemin kullanabileceği kaynak miktarı, bu iyileştirmeler devreye alınmadan çok önce belirlenmiş bir üst sınırla kısıtlı. Bu kapasitenin ne kadarını tükettiğini iki unsur belirliyor: yoğun saatlerde gelen istek sayısı ve her bir isteğin işlenmesi için gereken kaynak miktarı. İlk unsur müşterilere bağlı. İkinci unsur ise asistanlar arasındaki iletişimin nasıl tasarlandığına bağlı.
Bu iyileştirmeler için yeni bir model satın alınmadı. Model aynı, sağlayıcı aynı, sözleşme aynı. Değişen, kontrolün ve bağlamın asistanlar arasında nasıl aktarıldığı oldu. Artık aynı iş daha düşük maliyetle yapılıyor ve sistem daha hızlı yanıt veriyor.
Bu tür sistemleri geliştiren herkes benzer bir mimari diyagramı çiziyor: Asistanları temsil eden kutular ve aralarındaki bağlantılar. Kutuların tasarımına büyük emek ve dikkat harcanıyor; istemler, araçlar, test senaryoları ve tasarım değerlendirmeleri ayrıntılı biçimde ele alınıyor. Bağlantılar ise genellikle en son çiziliyor ve maliyetleri hesaplanmıyor. Oysa sistemin maliyetini belirleyen unsurlardan biri tam da bu bağlantılar.
Pilot projelerin neden üretime geçemediğine ilişkin yaygın açıklamalar; net tanımlanmamış hedefleri, eksik entegrasyonları ve toplanmamış verileri sıralıyor. Ancak bu açıklamalarda bir unsur eksik kalıyor. Bu unsur, ancak yüksek kullanım hacmine ulaşıldığında görünür hâle geliyor: mimarinin çalıştırılma maliyeti.
Dolayısıyla bu teknolojinin fiyatı yalnızca size sunulan bir tekliften ibaret değil; tasarım aşamasında verdiğiniz kararlarla da belirleniyor.
Kimse çizdiği mimari diyagram üzerinden değerlendirilmez. Asıl sınav, sistemin sıradan bir sabah gerçek çağrılarla çalıştığı sırada verilir.
.avif)
