Etkili AI Ajanları Oluşturmak

 (anthropic.com)
8 puan yazan GN⁺ 2025-06-18 | 1 yorum | WhatsApp'ta paylaş
  • Anthropic’in sahadaki deneyimine göre başarılı LLM ajanları çoğu zaman karmaşık framework’lerden değil, basit ve birleştirilebilir kalıplardan yola çıkıyor
  • Ajanik sistemler, sabit bir kod yolunu izleyen iş akışları ile LLM’in prosedürü ve araç kullanımını dinamik olarak belirlediği ajanlar olarak ikiye ayrılıyor
  • Birçok LLM uygulaması için, tek bir LLM çağrısına arama ve in-context örnekler eklemek yeterli oluyor; karmaşıklık ise yalnızca değerlendirmelerle etkisi doğrulandığında artırılmalı
  • Framework’ler başlangıcı hızlandırsa da, istemleri ve yanıtları gizleyen soyutlama katmanı nedeniyle hata ayıklamayı zorlaştırabiliyor
  • Otonom ajanlar açık uçlu problemlerde güçlü olsa da artan maliyet ve hata birikimi riski taşıyor; bu yüzden sandbox testleri, guardrail’ler ve net araç tasarımı gerekiyor

Ajanik sistemlerin temel ayrımı

  • Ajanik sistemler, uzun süre bağımsız çalışan tam otonom sistemlerden, önceden tanımlanmış iş akışlarını izleyen uygulamalara kadar geniş bir aralığı kapsayan bir terimdir
  • Anthropic bu varyasyonların tümünü ajanik sistem olarak görür, ancak mimari açıdan ikiye ayırır
    • İş akışları: LLM ve araçlar önceden tanımlanmış bir kod yolunu izleyerek orkestre edilir
    • Ajanlar: LLM, görevin nasıl yürütüleceğini, prosedürü ve araç kullanımını dinamik olarak yönlendirir ve kontrol eder

Ajan ne zaman kullanılmalı?

  • LLM uygulamalarında mümkün olan en basit çözümle başlanması ve yalnızca gerektiğinde karmaşıklığın artırılması önerilir
  • Ajanik sistemler daha iyi görev performansı karşılığında gecikme ve maliyet yükü getirir; bu ödünün gerçekten gerekli olup olmadığı önce doğrulanmalıdır
  • Karmaşıklık gerektiğinde bile seçim ölçütü farklıdır
    • İyi tanımlanmış görevlerde iş akışları öngörülebilirlik ve tutarlılık sağlar
    • Büyük ölçekli esneklik ve model güdümlü karar verme gerektiren görevlerde ajanlar daha uygundur
  • Birçok uygulama için, arama ve in-context örneklerle tek bir LLM çağrısını optimize etmek yeterlidir

Framework kullanım ölçütleri

  • Ajanik sistemleri uygulamak için Claude Agent SDK, Strands Agents SDK by AWS, Rivet, Vellum tanıtılıyor
  • Bu tür framework’ler LLM çağrıları, araç tanımı ve parse etme, çağrı bağlantılama gibi düşük seviyeli standart işleri basitleştirerek başlangıcı hızlandırır
  • Ancak ek soyutlama katmanı, gerçek istemleri ve yanıtları gizleyerek hata ayıklamayı zorlaştırabilir
    • Basit bir yapılandırmanın yeterli olduğu durumlarda bile gereksiz karmaşıklık eklemeye yönlendirebilir
  • Geliştiricilerin önce LLM API’lerini doğrudan kullanarak başlaması daha iyidir
    • Birçok kalıp birkaç satır kodla uygulanabilir
    • Framework kullanılsa bile iç kodun nasıl çalıştığı anlaşılmalıdır
    • İç işleyiş hakkında yanlış varsayımlar müşteri hatalarının yaygın nedenlerinden biridir
  • Örnek uygulamalar cookbook içinde görülebilir

Temel yapı taşı: güçlendirilmiş LLM

  • Ajanik sistemlerin temel yapı taşı, arama, araçlar ve bellek gibi yeteneklerle güçlendirilmiş geliştirilmiş LLM’dir
  • Güncel modeller bu yetenekleri, arama sorgularını doğrudan oluşturarak, uygun araçları seçerek ve hangi bilgiyi tutacağına karar vererek etkin biçimde kullanabilir
  • Uygulama sırasında iki şeye odaklanılmalıdır
    • Yeteneği kullanım senaryosuna göre ayarlamak
    • LLM’in kolay kullanabileceği, iyi dokümante edilmiş arayüzler sunmak
  • Bir uygulama yöntemi olarak Model Context Protocol tanıtılıyor
    • Geliştiriciler basit bir client implementation ile üçüncü taraf araç ekosistemleriyle entegre olabilir

İş akışı kalıpları

  • Prompt chaining

    • Prompt chaining, görevi sıralı aşamalara ayırır ve her LLM çağrısı bir önceki çağrının çıktısını işler
    • Sürecin doğru yolda olup olmadığını doğrulamak için ara adımlara programatik kontroller eklenebilir
    • Görev sabit alt görevlere temiz biçimde ayrıştığında uygundur
    • Temel ödün, gecikme karşılığında her LLM çağrısının zorluk seviyesini düşürüp doğruluğu artırmaktır
    • Örnekler
      • Pazarlama metni üretip sonra başka bir dile çevirmek
      • Belge taslağı oluşturmak, kriterleri karşılayıp karşılamadığını denetlemek ve taslağa dayanarak belgeyi yazmak

  • Yönlendirme

    • Yönlendirme, girdiyi sınıflandırdıktan sonra onu uzmanlaşmış sonraki işleme yollarına göndermektir
    • İlgi alanlarını ayırmayı ve daha uzmanlaşmış istemler oluşturmayı mümkün kılar
    • Bu yapı olmadan, bir tür girdiye yönelik optimizasyon başka girdilerin performansını bozabilir
    • Farklı kategoriler ayrı işlemeye uygunsa ve LLM ya da geleneksel sınıflandırma modeli/algoritması bunları doğru sınıflandırabiliyorsa iyi çalışır
    • Örnekler
      • Genel sorular, iade talepleri ve teknik destek gibi müşteri hizmetleri sorgularını farklı süreçlere, istemlere ve araçlara yönlendirmek
      • Kolay ve genel soruları Claude Haiku 4.5 gibi daha küçük ve maliyet verimli modellere, zor ya da sıra dışı soruları Claude Sonnet 4.5 gibi daha güçlü modellere yönlendirmek

  • Paralelleştirme

    • Paralelleştirme, LLM’in bir görevi eşzamanlı işlemesi ve çıktıların programatik olarak bir araya getirilmesidir
    • İki temel varyant vardır
      • Bölümlendirme: Görevi bağımsız alt görevlere ayırıp paralel yürütmek
      • Oylama: Aynı görevi birden fazla kez çalıştırarak çeşitli çıktılar elde etmek
    • Alt görevleri ayırarak hızı artırmak mümkün olduğunda veya daha yüksek güvenilirlik için birden çok bakış açısı ya da deneme gerektiğinde etkilidir
    • Karmaşık görevlerde her değerlendirme unsurunun ayrı bir LLM çağrısı tarafından ele alınması, belirli yönlere daha fazla odaklanmayı sağlar
    • Örnekler
      • Bir model örneğinin kullanıcı sorgusunu işlerken başka bir örneğin uygunsuz içerik ya da talepleri denetlediği guardrail’ler
      • LLM performans değerlendirmelerinde her çağrının model performansının farklı bir yönünü ölçmesi
      • Birden fazla istemin kod zafiyetlerini incelemesi ve sorun bulunursa işaretlemesi
      • İçerik uygunsuzluğu değerlendirmesinde birden fazla istem ve oylama eşiği kullanarak yanlış pozitifler ile yanlış negatifleri dengelemek

  • Orkestratör-çalışan

    • Orkestratör-çalışan, merkezi bir LLM’in görevi dinamik olarak parçalara ayırdığı, bunları çalışan LLM’lere devrettiği ve sonuçları sentezlediği yapıdır
    • Gerekli alt görevlerin önceden tahmin edilemediği karmaşık görevler için uygundur
    • Paralelleştirmeye benzese de temel fark esnekliktir
      • Paralelleştirmede alt görevler önceden tanımlıdır
      • Orkestratör-çalışan yapısında orkestratör alt görevleri girdiye göre belirler
    • Örnekler
      • Her seferinde birden çok dosyada karmaşık değişiklikler yapan kodlama ürünleri
      • Birden çok kaynaktan ilgili olabilecek bilgileri toplayıp analiz eden arama görevleri

  • Değerlendirici-optimizatör

    • Değerlendirici-optimizatör, bir LLM çağrısının yanıt ürettiği, başka bir LLM çağrısının ise değerlendirme ve geri bildirim sunduğu döngüsel bir yapıdır
    • Açık değerlendirme ölçütleri olduğunda ve yinelemeli iyileştirme ölçülebilir değer sağladığında özellikle etkilidir
    • İyi uyum sinyalleri iki tanedir
      • İnsanlar geri bildirimi net biçimde ifade ettiğinde LLM yanıtı gerçekten iyileşir
      • LLM bu tür geri bildirimi sağlayabilir
    • Bu, insan yazarların cilalı bir metin üretirken geçtiği yinelemeli yazma sürecine benzer
    • Örnekler
      • Değerlendirici LLM’in, çeviri LLM’inin ilk aşamada kaçırabileceği nüansları eleştirdiği edebi çeviri
      • Değerlendiricinin ek arama gerekip gerekmediğine karar verdiği karmaşık arama görevleri

Otonom ajanlar

  • Ajanlar, LLM’lerin karmaşık girdileri anlama, akıl yürütme ve planlama, araçları güvenilir kullanma ve hatalardan toparlanma yetenekleri geliştikçe üretimde kullanılmaya başlandı
  • Görev, insan komutuyla veya bir diyalogla başlar
    • Görev netleştiğinde ajan plan yapar ve bağımsız çalışır
    • Ek bilgi ya da yargı gerektiğinde tekrar insana dönebilir
  • Çalışma sırasında her adımda ortamdan gerçek doğrulama sinyalleri almak önemlidir
    • Örneğin araç çağrısı sonuçları, kod yürütme sonuçları
    • Bunlar ilerlemenin değerlendirilmesini sağlar
  • Ajanlar kontrol noktalarında veya tıkandıklarında insan geri bildirimi için durabilir
  • Görev çoğunlukla tamamlandığında sona erer, ancak kontrolü korumak için azami yineleme sayısı gibi durdurma koşulları koymak da yaygındır
  • Uygulamanın kendisi çoğu zaman basittir
    • Ajan genellikle, ortam geri bildirimine dayanarak bir döngü içinde araç kullanan bir LLM’dir
    • Bu nedenle araç seti ve dokümantasyon dikkatli ve açık biçimde tasarlanmalıdır
  • Kullanım koşulları
    • Gerekli adım sayısının öngörülmesinin zor ya da imkânsız olduğu açık uçlu problemler
    • Sabit bir yolun hard-code edilemediği görevler
    • LLM’in birden fazla tur boyunca çalışabildiği ve karar verme konusunda belirli bir güven düzeyinin gerektiği durumlar
  • Kısıtlar
    • Otonomi, daha yüksek maliyet ve hata birikimi olasılığıyla birlikte gelir
    • Sandbox ortamlarında kapsamlı testler ve uygun guardrail’ler önerilir
  • Örnekler

Kalıpları birleştirme ve özelleştirme

  • Sunulan yapı taşları sabit reçeteler değil, geliştiricilerin kullanım senaryolarına göre uyarlayıp birleştirebileceği ortak kalıplardır
  • Başarının anahtarı, LLM yeteneklerinin genelinde olduğu gibi performansı ölçmek ve uygulamayı yinelemeli olarak iyileştirmektir
  • Karmaşıklık yalnızca sonuçlar gerçekten iyileştiğinde eklenmelidir

Uygulama ilkeleri

  • LLM alanındaki başarı, en karmaşık sistemi kurmak değil, ihtiyaca uygun doğru sistemi kurmaktır
  • Önerilen sıra şöyledir
    • Basit istemlerle başlamak
    • İstemleri kapsamlı değerlendirmelerle optimize etmek
    • Basit çözüm yetersiz kaldığında ancak o zaman çok aşamalı ajanik sistemler eklemek
  • Ajan uygularken üç ilke önemlidir
    • Tasarımda sadeliği korumak
    • Ajanın planlama aşamasını açıkça göstererek şeffaflığa öncelik vermek
    • Araç dokümantasyonu ve testlerini titizlikle yaparak agent-computer interface, yani ACI’yi dikkatle tasarlamak
  • Framework’ler hızlı başlamak için yararlı olsa da, üretime geçerken soyutlama katmanlarını azaltıp temel bileşenlerle inşa etmeye dönmek gerekebilir

Gerçek kullanım alanları

  • Müşteri desteği

    • Müşteri desteği, tanıdık chatbot arayüzünü araç entegrasyonuyla genişletilmiş yeteneklerle birleştirir
    • Bunun daha açık uçlu ajanlara doğal biçimde uymasının nedenleri vardır
      • Destek etkileşimleri konuşma akışını izlerken dış bilgiye ve görev erişimine ihtiyaç duyar
      • Araçlar müşteri verilerini, sipariş geçmişini ve bilgi tabanı belgelerini getirecek şekilde entegre edilebilir
      • İade işleme veya ticket güncelleme gibi görevler programatik olarak yürütülebilir
      • Başarı, kullanıcının tanımladığı çözümle açık biçimde ölçülebilir
    • Birden çok şirket, yalnızca başarılı çözümler için ücret alan kullanıma dayalı fiyatlandırma modeliyle bu yaklaşımın uygulanabilir olduğunu gösterdi

  • Kodlama ajanları

    • Yazılım geliştirme alanı, LLM yeteneklerinin kod tamamlama düzeyinden otonom problem çözmeye evrilmesiyle büyük potansiyel gösterdi
    • Ajanların etkili olmasının nedenleri vardır
      • Kod çözümleri otomatik testlerle doğrulanabilir
      • Ajanlar test sonuçlarını geri bildirim olarak kullanıp çözümleri yinelemeli biçimde iyileştirebilir
      • Problem alanı iyi tanımlanmış ve yapılandırılmıştır
      • Çıktı kalitesi nesnel olarak ölçülebilir
    • Anthropic’in uygulamasında ajanlar, yalnızca pull request açıklamasından yola çıkarak SWE-bench Verified benchmark’ındaki gerçek GitHub issue’larını çözebiliyor
    • Otomatik testler işlevselliği doğrulamaya yardımcı olsa da, çözümün daha geniş sistem gereksinimlerine uyup uymadığını görmek için insan incelemesi hâlâ önemlidir

Araç istem mühendisliği

  • Herhangi bir ajanik sistemde araçlar büyük olasılıkla kritik bir bileşen olacaktır
  • Tools, Claude’un harici servisler ve API’lerle etkileşim kurmasını sağlar
    • API içinde doğru yapı ve tanımlar belirtilir
    • Claude araç çağrısını planladığında API yanıtında bir tool use block yer alır
  • Araç tanımları ve spesifikasyonları, bütün istem kadar dikkatli bir prompt engineering yaklaşımını hak eder

  • Araç formatı seçimi

    • Aynı görev birden fazla şekilde tanımlanabilir
      • Dosya düzenleme diff olarak da yazılabilir, dosyanın tamamını yeniden yazarak da belirtilebilir
      • Yapılandırılmış çıktı, Markdown içindeki kod veya JSON içindeki kod olarak döndürülebilir
    • Yazılım mühendisliği açısından bunlar kayıpsız dönüştürülebilir biçim farkları gibi görünebilir, ancak LLM için bazı formatları yazmak çok daha zordur
      • diff yazmak, yeni kod yazmadan önce chunk header içindeki kaç satırın değiştiğini bilmeyi gerektirir
      • JSON içinde kod yazmak ek satır sonu ve tırnak kaçışları gerektirir
    • Araç formatı seçilirken model gereksiz biçim yüklerine hapsedilmemelidir
      • Çıkışı zorlayıcı bir formata sokmadan önce yeterli düşünme token’ı sağlamak
      • Modelin internette doğal olarak gördüğü metin formatlarına yakın kalmak
      • Binlerce satır kodun tam satır sayısını saymak veya kod dizelerini escape etmek gibi biçimsel yükleri ortadan kaldırmak

  • ACI tasarımı

    • İnsan-bilgisayar arayüzüne (HCI) gösterilen özen kadar agent-computer interface(ACI) tasarımına da yatırım yapılmalıdır
    • İyi araç tanımları çoğu zaman örnek kullanım, edge case’ler, giriş biçimi gereksinimleri ve diğer araçlarla net sınırlar içerir
    • Parametre adları ve açıklamalar, modelin daha kolay anlaması için ayarlanmalıdır
      • Bu, ekibinizdeki junior geliştirici için mükemmel bir docstring yazmaya benzer
      • Özellikle benzer araç çoksa daha da önemlidir
    • Modelin araç kullanımının test edilmesi gerekir
      • workbench üzerinde çok sayıda örnek girdi çalıştırılarak model hataları gözlenir ve yinelemeli iyileştirme yapılır
      • Araçların Poka-yoke yaklaşımıyla, hata yapmayı zorlaştıracak şekilde argümanları değiştirilerek tasarlanması önerilir
    • SWE-bench için ajan oluşturulurken, tüm istemden daha fazla zaman araç optimizasyonuna harcandı
      • Ajan, kök dizinin dışına çıktıktan sonra göreli dosya yolları kullanan bir araçta hata yapıyordu
      • Araç her zaman mutlak dosya yolu istemeye başlayınca model bu yöntemi hatasız kullandı

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-18
Hacker News yorumları

  • Bu yazının bu konuda hâlâ iyi yazılardan biri olduğunu düşünüyorum. Özellikle başta AI agent ifadesini hangi anlamda kullandığını net biçimde tanımlaması hoşuma gitti.
    Burada bunu “LLM'in kendi işlem sürecini ve araç kullanımını dinamik olarak yönlendirdiği, görevin nasıl gerçekleştirileceğine dair kontrolü elinde tuttuğu sistem” olarak tanımlıyor.
    Ayrıca “agent” ile “workflow”u ayırması ve faydalı workflow kalıplarını birkaç örnekle açıklama biçimi de iyiydi.
    İlk yayımlandığında bu yazı hakkında notlar almıştım: https://simonwillison.net/2024/Dec/20/building-effective-age...
    Anthropic'in daha güncel yazılarından https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system” var; bu da çok ilginçti, onun için de notlarımı derledim: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

    • Building Effective Agents yazarlarından biri AIE'ye gelip bu yazıya dayalı bir sunum da yaptı ve iyi tepki aldı: https://www.youtube.com/watch?v=D7_ipDqhtwk
    • Çok agent'lı araştırma sistemi yazısı harika. Ancak Building Effective AI Agents yazısında ilk sistemleri framework kullanmadan kurma önerisine katılmıyorum.
      Öğrenme amacıyla iyi görünüyor, ama iyi bir framework'ün ilk avantajı farklı sağlayıcıların LLM'lerini kolayca deneyebilmenizi sağlamasıdır.
    • Bu yazıdaki workflow tanımının isabetsiz olduğunu düşünüyorum. Modern workflow motorları yalnızca önceden belirlenmiş kod yollarını izlemez; böyle durumlarda agent'larla fiilen aynıdır.
      Workflow'u yeniden tanımlayıp ayrıştırma girişimi gibi görünüyor, ancak çoğu agent, LLM yanıtına göre dinamik olarak bir şeyler çağıran yinelemeli workflow'lardan ibaret. Modern workflow motorları çok dinamiktir.
    • Anthropic'in hangi AI agent framework'ünü kullandığını bilen var mı? Kendi framework'lerini yayımlamış gibi görünmüyor.

  • “LLM çağrıları, araç tanımlama ve ayrıştırma, çağrıları birbirine bağlama gibi standart düşük seviyeli işleri basitleştirerek başlamayı kolaylaştırırlar; ancak çoğu zaman ek soyutlama katmanları yaratarak temel prompt'ları ve yanıtları gizler, debug etmeyi zorlaştırırlar. Daha basit bir kurgu yeterliyken bile karmaşıklık eklemeyi cazip kılarlar. Geliştiricilerin LLM API'lerini doğrudan kullanarak başlamasını öneriyoruz” tavsiyesinin yazının tamamındaki açık ara en iyi tavsiye olduğunu düşünüyorum.
    Özünde bir string dizisini bir web servisine göndermek için devasa bir framework kullanmak mantıklı değil.
    Şirket projesinde de LangChain ve LangGraph'ı kaldırdık; pratikte değer katmıyor, sadece karmaşıklığı artırıyordu. Framework'ün boilerplate'leriyle uğraşmak gerektiği için, kullanmadığımız duruma kıyasla daha fazla kod yazmak zorunda kalıyorduk.

    • langflow da bu kategoriye giriyor gibi. Yine de birden fazla akışı ortak bir biçimde düzenleme açısından kesinlikle bir kullanım alanı olduğunu düşünüyorum.
      Stable Diffusion ile görüntü üretiminin tüm adımlarını tek tek çalıştırabilir ya da shader kodunu doğrudan yazabilirsiniz; ama birden fazla akışınız ya da işiniz varsa ve deneme yapıyorsanız comfy-UI veya shader graph kullanmak çok daha düzenli olur.

  • Yarım yıl geçti ve yapay zeka alanında bu epey uzun bir süre gibi geliyor. Birkaç ay önce bu yazıyı tekrar tekrar okumuştum, ama şu anda agent geliştirmenin açıkça bir darboğaza ulaştığını düşünüyorum.
    En yeni Gemini bile gerilemiş gibi görünüyor.

    • Birden fazla agent çalıştırınca maliyet yükseliyor ve yatırım getirisi düşüyor. Hisse senetleri için DeepSearch agent'ı 6 agent kullanıyor ve sorgu başına yaklaşık 2 dolar tutuyor.
      Çok agent'lı orkestrasyonu kontrol etmek zor; model performansı iyileştikçe çok agent'a duyulan ihtiyaç azalıyor. Tersine, model performansı ne kadar düşükse dar kapsamlı yapay zeka iş açısından o kadar daha mantıklı hale geliyor.
    • Tam olarak ne yüzünden geriliyor? Kendisini bir sürü kopyaya fork'layıp 24 saat paralel çalışmasını, sonuçları doğrulayıp sürekli gelişmesini engelleyen şeyin ne olduğunu merak ediyorum.
    • Prompt injection sorununu çözmekte zorlanıyorlar ve bu da darboğazlardan biri.

  • Gerçek üretim ortamında şirketlere maliyet tasarrufu sağlayan ve gerçekten değerli işler yapan ajan örnekleri var mı? Patates cipsi paketindeki boşluğu doldurmak için metin yazmak gibi olmayanları kastediyorum

    • ChatIPT iyiydi. Biyoçeşitlilik verilerinde gerçek bir sorunu çözüyor. “Ajansal” ifadesini kullanmıyor ama açıkça Python kodu yazıp çalıştırıyor
      https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
      Hâlâ beta aşamasında
      Basın bültenine göre Rukaya Johaadien’in chatbot’u, biyoçeşitlilik verilerine sahip olan ancak veri yayımlamaya yeni başlayan ya da bunu nadiren yapan öğrenci ve araştırmacılara sohbet tabanlı destek sağlıyor. Elektronik tabloları temizleyip standartlaştırıyor, temel metadata oluşturuyor ve iyi yapılandırılmış veri kümelerini Darwin Core Archive olarak GBIF.org’da yayımlamaları için rehberlik ediyor
      Şimdiye kadar doktora ve yüksek lisans araştırmalarından ya da küçük ölçekli biyoçeşitlilik çalışmalarından çıkan yüksek kaliteli verileri büyük ölçekte yayımlamak zordu. Çünkü veri standardizasyonu genellikle programlama dilleri, veri yönetimi teknikleri ve özel yazılımlar hakkında bilgi gerektiriyordu
      GBIF ağının veri paylaşımı için temel uygulaması olan Integrated Publishing Toolkit’e (IPT) erişme süreci de yeni başlayanlar için zor. Düğüm sorumlularının zamanı ve kaynakları sınırlı; ara sıra kullanan kullanıcılar da her yıl doğru prosedürleri ve ayrıntıları kolayca unutabiliyor. Bu yüzden yalnızca eğitimle lojistik ve dil engellerini aşmanın zor olduğu söyleniyor
      “Veri standardizasyonu zordur; biyologlar da kodlamayı ya da Excel’i sevdikleri için biyolog olmadıklarından, potansiyel olarak değerli pek çok veri çöpe gider. Büyük dil modellerinin kod üretimi ve veri işleri konusunda çok iyi hâle geldiğini görünce, teknik olmayan kullanıcıları gündelik sorularla yönlendiren, dağınık verileri mümkün olduğunca işleyen ve ardından GBIF’e hızlı ve otomatik biçimde yayımlayan bir araç yaptım” diye açıklıyor
    • louie.ai’de kullanıcıların her gün yaptığı araştırma işlerini otomatikleştirmek için ajanlar ve ajansal akıl yürütme kullanılıyor
      Gelen her uyarı ya da ticket için ajan, ilgili API’ler, veritabanları vb. üzerinde ön araştırma yaparak false positive’leri belirliyor ve gerçek sorunlara daha fazla bağlam sağlıyor. İnsanların harcadığı zamanı azaltıyor ve işlem hızını artırıyor
      Aynı ajansal akıl yürütme keşif işlerinde de kullanılıyor; basit text-to-SQL’in ötesine geçerek LLM, 2–10 dakika boyunca Splunk, Databricks vb. araçlarda kullanıcı yerine araştırma yapıyor
      İçeride veritabanlarının üstünde bir semantik katman, büyük ölçekli log/metin/dataframe analiz araçları gibi bileşenler var

  • Yazıdakine neredeyse aynı yapıda, kendi yaptığım bir n8n workflow kullandım. Basit bir soruya yanıt almak 3 dolara ve en az 3 dakikaya mal oldu
    Bir süre daha normal aramayı kullanmaya devam edeceğim

  • Bu yazı, çalışan en basit şeyle başlayıp karmaşıklığı yalnızca gerçekten gerektiğinde eklemek gerektiğini iyi hatırlatıyor
    Net tanımlanmış birkaç LLM çağrısı ve hafif bir yapıştırıcı mantık bile genellikle daha kararlı, debug etmesi daha kolay ve çalıştırması çok daha ucuz bir sistem ortaya çıkarıyor. Gösterişli ve çok özellikli ajanlar çoğu zaman çözdüklerinden daha fazla sorun yaratıyor

  • Üretim ortamında workflow değil, gerçek ajanları olan bir şirkette çalışan biri olarak, buradaki “LangGraph gibi ajan framework’leri kullanın” şeklindeki ilk cümleye hiç katılamıyorum
    Biz de tam olarak bunu yaptık ve bir ay içinde hepsini atmak zorunda kaldık; sonra baştan tekrar yaptık ve şimdi oldukça iyi ölçeklenen bir sistemimiz var
    Adil olmak gerekirse ajan framework’leri için bir kullanım alanı olabilir. Ama ajan alanı, yeterince iyi bir framework’ün ortaya çıkması için hâlâ fazla erken aşamada
    Bir ölçüde bunun tersini de düşünüyorum: ajan alanı o kadar hızlı ilerliyor ki yeterince iyi bir framework hiç çıkmayabilir

    • Aksine, yazıyla aynı fikirdeymişsin gibi geliyor. Orijinal metinde de son bir yılda çeşitli sektörlerdeki LLM ajan ekipleriyle çalışınca, en başarılı uygulamaların karmaşık framework’ler ya da özelleşmiş kütüphanelerle değil, basit ve birleştirilebilir pattern’lerle yapıldığını söylüyor
      Framework’ler başlamayı kolaylaştırır ama ek soyutlama katmanları prompt’ları ve yanıtları gizleyerek debug etmeyi zorlaştırabilir; daha basit bir yapı yeterliyken karmaşıklık eklemeye de yol açabilir. Bu yüzden pek çok pattern birkaç satır kodla uygulanabildiğinden, doğrudan LLM API’sini kullanarak başlamayı öneriyor
    • Şu anda N8N’in ajan araçlarıyla yaptığım prototipten, self-host edilebilir gerçek bir sisteme geçiyorum
      Pratik ekiplerin çoğunun LangChain, LangGraph, Haystack, Crew gibi şeyleri bırakıp daha basit iç koda geçtiğine dair çok yorum gördüm ama gerçek hayatta tool calling gibi kısımların fiilen nasıl uygulandığını hâlâ tam kavrayabilmiş değilim
      Çalışmana temel aldığın linkler ya da dokümanlar varsa paylaşabilir misin
    • O ajan hangi işleri yapıyor?

  • Aralık 2024 tarihli bir yazı ama tuhaf biçimde çok eskiymiş gibi hissettiriyor

    • Yine de kişisel olarak hâlâ gayet iyi dayandığını düşünüyorum. Bu yazıyı sürekli referans olarak kullanıyorum ve eskimiş hissettirmiyor
      Yapay zeka araçları geliştirmede Anthropic’i “pratik bir ortak” olarak yeniden görmemi sağlayan yazıydı
    • “Hayır, yine beynimizi kullanmak ve Aralık 2024 mağara insanları gibi kodun %100’ünü kendimiz yazmak zorundayız”
      https://news.ycombinator.com/item?id=44260988

  • Görünüşe göre ajan hype’ı artık biraz yatıştı

  • “Basit ve birleştirilebilir pattern’ler kullanın” sözü garip derecede iç rahatlatıcı
    “Tek bir işi iyi yap” deyişinin onlarca yıl sonra hâlâ geçerli olması hoşuma gidiyor. Birleştirilebilirlik en iyisi