LLM fonksiyon çağrıları ölçeklenmiyor; kod orkestrasyonu daha basit ve daha etkili

• LLM'in araç çağrısı sonuçlarının tamamını işlemesi yavaş, maliyetli ve ölçeklenmeye elverişsizdir
• Bunun yerine, çıktı şeması tabanlı yapılandırılmış verileri kodla işlemek üzere LLM'in orkestrasyon yapması öneriliyor
• Bu yaklaşım, kod üzerinden fonksiyon zincirleme ve değişken tabanlı bellek yönetimiyle büyük ölçekli veri işlemeye uygundur
• Kod yürütme tabanlı veri işleme yaklaşımı, LLM veriyi doğrudan yeniden üretmediği için doğruluk ve ölçeklenebilirlik açısından güçlüdür
• Güvenli bir AI runtime ortamı kurmak yeni bir zorluk olarak öne çıkıyor; sürdürülebilir ve durum koruyabilen bir yürütme ortamına ihtiyaç var

---

LLM function calls don't scale; code orchestration is simpler, more effective.

Araç çağrısı sonuçlarını LLM'e geri vermeye dayanan mevcut yaklaşımın sınırları

• MCP(Machine Context Protocol) araçları kullanılırken genellikle araç çıktıları mesaj olarak LLM'e iletilir ve bir sonraki adımın buna göre belirlenmesi istenir
• Gerçek kullanım senaryolarında Linear ve Intercom'un MCP sunucuları JSON biçiminde büyük yanıtlar döndürür
• JSON API'lere benzese de tanımlı bir çıktı şeması olmadığından, LLM'in tüm metni parse etme yükü ortaya çıkar
• Örneğin Linear'dan issue listesi sorgusunun sonucu 50 öğede 70.000 karakter, yaklaşık 25.000 token ile oldukça büyüktür
• Birçok id alanı anlam taşımamasına rağmen token tüketir; LLM'in bunları olduğu gibi yeniden üretmesi maliyeti artırır ve hata riskini büyütür

Veri işleme ile orkestrasyonun ayrılması gerekiyor

• Mevcut yaklaşım, veri işleme ile orkestrasyonu aynı sohbet oturumu içinde karıştırıyor
• Bazıları bunun için "ajan" adıyla başka thread'ler oluştursa da, JSON zaten yapılandırılmış olduğunda bu verimsiz kalır
• Daha iyi yöntem, yapılandırılmış veriyi doğrudan kodla işlemektir
  • Örneğin issue sıralamada LLM'in çıktı üretmesi yerine kodla sort çalıştırılıp yalnızca sonuç dizisi döndürülebilir

Kod yürütme tabanlı veri işleme

• Kod çalıştırma yoluyla AI hesaplama, çeşitli AI yorumlayıcılarında zaten kullanılıyor
• Bu yaklaşım, LLM'in veriyi doğrudan üretmek yerine yalnızca araçların nasıl kullanılacağına karar vermesini sağlayan daha yalın bir yapı sunar

Temel kavramlar

• Değişkenleri bellek olarak kullanma: değer atama = depolama, çıktı = okuma, fonksiyon çağrılarında argüman olarak aktarma
• Fonksiyon zincirleme desteği: birden çok fonksiyon çağrısını paralel/sıralı olarak birleştirme, bağımlılıkları ise kod içindeki doğal akışla ifade etme
• Ölçeklenebilir büyük veri işleme: NumPy, pandas gibi araçlarla birleştiğinde binlerce~on binlerce kaydı kolayca işleyebilme
• Başka LLM çağrıları da mümkün: LLM'in yazdığı kod içinde başka bir LLM çağrılarak yapılandırılmamış veri işleme de yapılabilir

MCP hazır mı?

• MCP spesifikasyonu zaten girdi şemasını tanımlıyor; yakın zamanda çıktı şeması PR'ı da sunuldu
• Çıktı şeması yaygınlaşırsa aşağıdaki kullanım senaryoları mümkün hale gelebilir:
  • issue durum panosu
  • haftalık tamamlanan ticket raporu
  • takılı kalan ticket'ları yapay zekanın izleyip push etmesi

Kod yürütme ortamının zorlukları

• Güvenlik temel mesele: AI/kullanıcı tarafından üretilen kod çalıştırıldığı için API anahtarları ve veri sızıntısını önleyecek tasarım gerekiyor
• Lutra örneğinde yürütme ortamı sandbox yaklaşımıyla kuruluyor ve modele yalnızca API çağrı dokümantasyonu veriliyor
• Durum koruyan yürütme ortamları (Jupyter vb.) maliyetlidir; uzun oturumlar için durumsuz (stateless) + kalıcı (persistent) özelliklerine ihtiyaç vardır
• Bu, yeni bir AI runtime kategorisi oluşturuyor ve tasarımı hâlâ aktif biçimde şekilleniyor

Sonuç

• Araç çağrısı sonuçlarını LLM'e verip orada işlettiren mevcut yaklaşımın maliyet ve doğruluk açısından sınırları var
• Kod tabanlı orkestrasyon, daha yalın ama aynı zamanda ölçeklenebilir ve doğru işleme imkânı sunuyor
• AI kod yürütme ortamları, güvenlik, kalıcılık ve ölçeklenebilirlik sunan yeni nesil runtime'lar olarak öne çıkıyor

[GN⁺]

Hacker News görüşleri

• Son 2 yıldır, "yeterince gelişmiş bir ajan DSL'den ayırt edilemez" görüşünü savunan bir deneyim paylaşımı. Ajandanın algoritmaları içselleştirmesini istemek yerine ona API öğretmenin ve bu API'yi kullanan algoritmalar tasarlatıp bunları kullanıcı alanında çalıştırmanın çok daha uygun olduğu görüşü. Algoritmaları LLM'in içine gömmek, çok sınırlı birkaç durum dışında (maliyet veya doğruluk açısından) verimsiz görülüyor. Bu durum, geliştiriciden fonksiyonları kafasında çalıştırmasını istemekle kıyaslanıyor
  • ASI'ye (yapay genel zekaya) giden yolun LLM'in yeteneklerini genişletmekten değil, dışarıdan kendi kendini iyileştiren algoritmaları sembolik uygulamalar olarak çıkarıp derlemekten geçtiğine dair bir kanıt olarak yorumlanıyor
  • 2 yıl önceden beri bu bağlamda "agent" terimini yaygın biçimde kullandığına dair dayanak veya örnek paylaşımı isteniyor
• Kendi e-ticaret işinde agentic sistemleri doğrudan kurma deneyimi. smolagents değerlendirilmiş; zarif ve çekici olsa da sistem karmaşıklığını ciddi ölçüde artırma dezavantajına sahip. Dinamik raporlama gibi verilerin şema olmadan sıralanıp toplandığı ortamlarda mükemmel, ancak çoğu iş için gereğinden fazla. Gemini ve OpenAI, Python yorumlayıcısı sunduğu için kod ajanlarının işlerinin önemli bir kısmını kapsayabiliyor. Araç çağrısı mesajlarını yığına sonsuza kadar ekleme yaklaşımı ölçeklenebilir olmadığı için önerilmiyor. Gerçek agentic iş akışlarının ömrü kısa ve karmaşıklık yapı ile disiplin üzerinden yönetiliyor. Mevcut yazılım geliştirmeden gelen dersler, yani fonksiyon çağrılarının ölçeğini yönetmek ve kaosu önlemek, bugün de aynı şekilde geçerli. İyi bir sistem kurmanın özü geliştiricinin bilişsel yükünü yönetmekte yatıyor; basit ama yeterince iyi çalışan çözümler, performanslı fakat gösterişli yöntemlerden üstün. Fonksiyon çağrısı kombinasyonları bu tür basit çözümlere örnek, yapılandırılmış veri işleme için de geleneksel ayrıştırma ve dönüştürme yöntemleri yeterli. Yapı bilinmediğinde ise ucuz modeller bile çok iyi ayrıştırma performansı gösterebiliyor. Sonuçta agentic sistemlerde karmaşıklığı yönetmek, uygulama durumunu titizlikle yönetme problemine indirgeniyor. Mesaj yığınını manipüle ederek modele verilecek aktif bağlam esnek biçimde oluşturulabiliyor; bu da kısıtlı ortamlardaki bellek yönetimine benziyor
  • Agentic sistemlerin trade-off'larını çok isabetli özetleyen bir değerlendirme. Biz de e-ticaret konuşmalı ürün arama çözümü (IsarTech) kurarken aynı sorunları yaşadık. Fonksiyon bileşimi ve yapılandırılmış veri, karmaşıklık kontrolünün anahtarı. Deneyime göre açık tip şemalarına dayalı çıktı, araç çağrılarının ölçeklenebilirliğini gerçekten artırıyor. Tip şemaları sayesinde hem bilişsel yük hem de sistem karmaşıklığı yönetilebiliyor. Mümkün olduğunda deterministik davranışa dayanıp, yalnızca şemasız veri veya belirsizlik olduğunda LLM kullanılıyor. Belirsiz istekleri deterministik sistemlere eşlemede LLM çok etkili. Ancak yüksek entropili (yapılandırılmamış) girdilerde karmaşıklığı azaltmak ile araç çağrısı zincirleri üzerinden karmaşıklığı artırmak arasında denge kurulması gerekiyor. Gerçek ticaret ortamında tek bir yaklaşımı kullanmak zor; yapılandırılmış çıktı da belirsiz niyetlerde sınırlı kalabildiği için ek stratejiler gerekiyor
• Sorunun fonksiyon çağrısının kendisi değil, MCP'nin tasarımı ve kullanım biçimi olduğu eleştirisi. MCP'lerin çoğu API kopyası ve anlamsız veri saçılımı sorunu var. JSON formatı tekrar tekrar iç içe geçirilerek gereksiz yere çok fazla girdi bağlamı tüketiliyor, çok sayıda alakasız bilgi de ekleniyor. Veri düzleştirme ve gereksiz alanları silme gibi optimizasyonlar gerekli. MCP SaaS sonuçta yalnızca bir API gateway işlevi görüyor. Mevcut MCP, gürültü üretiminin başlıca nedeni ve yeterince optimize edilmiş değil
  • GraphQL tam olarak bu amaç için optimize edilmiş bir teknoloji. Yalnızca gerekli alanların seçilebilmesi için tasarlanmış. Birden fazla GraphQL sorgusunu tek bir MCP sunucusuna dönüştüren açık kaynak bir Gateway geliştirildi
  • Sorunun, modelin karmaşık JSON şemalarına düzgün şekilde uymaması olup olmadığı sorgulanıyor
  • MCP faydalı değil ama her şeyi filtrelemek de en iyi çözüm olmayabilir. Bazen ajanın büyük miktarda veri işlemesi gerekiyor. Böyle durumlarda basit veri değerlendirmesi ve şema açıklaması içeren kod çalıştırma daha ölçeklenebilir bir yaklaşım olabilir. Elbette sistem çok büyürse benzer sorunlar ortaya çıkıyor. Nihai çözüm, insanın deterministik düşünme düzeyindeki kesinliğini kodla yeniden üretmek ve LLM'in bu karar sistemini çağırdığı bir yapı kurmak. Teoride kolay görünse de pratikte uygulaması çok zor olduğu vurgulanıyor
  • ChatGPT ile bir string ters çevirme testinde LLM'in sadece basit sonucu vermesini sağlamak bile çok zor bulunmuş ve güvenilirliği düşük hissedilmiş. Bu deneyimden sonra her zaman birden fazla LLM ile doğrulama yapma alışkanlığı edinilmiş. Bu gidişle basit bir string içindeki karakter sayısını saymak için bile kendi GPU veri merkezini hazırlamak gerekebileceğine dair bir şaka da yapılıyor
• Shopify ekibi yakın zamanda Roast'u açık kaynak yaptı. Büyük kod tabanlarında otomasyon için, deterministik olmayan LLM görevlerini iş akışı içine yerleştirmeye yarayan bir araç. Karmaşık işlerin otomasyonu için gerekli görülüyor
  • Roast oldukça etkileyici bulunmuş. Determinizm ile determinizm dışılığın uyumu özellikle öne çıkıyor. LLM'in birden fazla araç çağrısını nasıl orkestre ettiği ve çağrı sırasını nasıl belirlediği biraz kafa karıştırıcı. Refactoring talimatlarında çalışıyor gibi görünse de, "iyileştir → test et → tekrarla" gibi bileşik işler için uygun olup olmadığı merak ediliyor
  • Ruby'nin AI çağında da istikrarlı biçimde anlamlı kalması ferahlatıcı bulunuyor
  • Sadece dokümantasyonu okumak bile zihinsel olarak uyarıcı; LLM yeteneklerinin bildirimsel (declarative) biçimde paketlenmesi etkileyici
  • Shopify içinde bu iş akışlarının gerçekte nasıl kullanıldığına dair somut örnekler isteniyor
  • Claude Code Research Preview ile ChatGPT 4.5 Pro Deep Research'ün ikisini de çökertme deneyimi yaşanmış (kanıt da olduğu söyleniyor) ve gerçekten çalışan bir araç aranıyor
• En iyi yanıtın tek bir uçta değil, hibritte olduğu düşünülüyor. Mümkün olduğunca çok şeyi deterministik yaklaşımla çözmek ve LLM'i yalnızca spesifikasyona dökülmesi veya deterministik tekniklerle ele alınması zor olan karmaşık bölümlerde kullanmak en iyi yol olarak görülüyor
  • LLM'i deterministik çözüm (kod) üretmeye odaklayıp, bu kod doğrulandıktan sonra ileride deterministik kod olarak yeniden kullanma stratejisi ilginç bir yaklaşım
  • Amaç, iş akışı içindeki LLM kullanımını en aza indirmek olmalı görüşü dile getiriliyor
• Bir yıldan uzun süredir sektörden uzak kaldıktan sonra bu kadar karmaşık deneylerin yaygınlaşmış olmasına şaşırılıyor
  • Gerçekte hâlâ az sayıda kişinin deneme yaptığı, devrimsel örnekler olmasa da bazı faydalı kullanım örnekleri bulunduğu belirtiliyor
  • Şimdi bu işleri yapmayanların yakında sektörü yeniden terk etmek zorunda kalabileceği görüşü de dile getiriliyor
  • Kendi günlük işinin zaten LLM tabanlı AI ajan tasarım otomasyonuna yoğunlaştığı söyleniyor; isteyerek değil, farkında olmadan bu noktaya gelinmiş
• LLM'in yapılandırılmış veri sıralama için neden kullanıldığı soruluyor
  • Asıl amaç dashboard kurmak, issue ticket'ları otomatik tespit etmek, çeyreklik review'lar gibi daha karmaşık veri işlemleri. Sıralama yalnızca basit bir örnek; problemin ölçeğini anlamayı kolaylaştıran küçük bir gösterim
• huggingface smolagent bu yaklaşımın temsilî örneklerinden biri, ancak gerçek çalıştırma başarısız olduğunda rollback veya recovery çok zor hale geliyor. Yürütme bloğunun tamamını dağıtık transaction ile sarmak gibi teorik çözümler mümkün, fakat pratikte LLM sağlam kod üretmeye çalışırken bu desenle iyi uyuşmuyor ve hata takibiyle başarısızlık nedenini bulmak zorlaşıyor
  • smolagent'in temel fikri iyi, ancak asıl sorun yürütme ve hata işleme tarafında olduğu konusunda fikir birliği var. Örneğin kod çalıştırması kesildiğinde, tam o durumdan devam edebilmek isteniyor. LLM'in durum kurtarma kodunu iyi yazabildiği görülmüş ve şu anda bu yeteneğin gerçek ürünlerde (Lutra) oldukça iyi çalıştığı söyleniyor
• Başka bir yaklaşım olarak, LLM'in MCP'yi fonksiyon gibi çağıran kodu (Python script biçiminde) yazması teşvik ediliyor. Örnek kod paylaşılıyor
  • Bu yöntemi gerçek kullanımda uygulayan bir örnek olarak Lutra.ai tanıtılıyor. Temel nokta, kod runtime'ını ne kadar iyi tasarlayabildiğinize dayanıyor
• LLM'lerin özellikle JSON'a, özellikle de büyük JSON'lara karşı zayıf olduğu belirtiliyor. Endpoint'lerin veriyi illa JSON dışında başka bir formatta döndürmesi de mümkün. LLM'ler bazen XML'de çok daha güçlü performans gösterebiliyor; hatta şablonlarla anlatı biçiminde metin üretmek de mümkün
  • XML, içsel anlam bilgisi taşıyan bir format olduğu için LLM'lerde varsayılan olarak daha yaygın kullanılmaması şaşırtıcı bulunuyor. Gerekirse XML'i deterministik olarak JSON'a çevirip pipeline'a vermek etkili olabilir
  • LLM'e veri döndürürken Markdown tabloları kullanmanın oldukça iyi sonuç verdiği deneyimlenmiş
  • XML'in daha iyi performans göstermesinin, LLM eğitim verisinde daha sık yer alması mı yoksa metin token sayısının daha yüksek olması mı nedeniyle olduğu merak ediliyor. Daha büyük metin bloklarının LLM'e daha fazla bağlam sağlayabileceği de belirtiliyor