Skill’ler (beceriler) artık modern AI agent uygulamalarının temel taşlarından biri — geliştiricilerin agent’ları farklı araç ve görevlere uyarlamasını sağlıyor. Agent’lara skill eklemek genel başarıyı artırıyor olsa da, endüstri temel bir soruyu yeterince incelemedi: Skill’ler ne zaman işe yarıyor, neden çalışıyor ve nerede başarısız oluyor?
Çeşitli üniversitelerden araştırmacıların yaptığı yeni bir çalışma, çeşitli benchmark’lar üzerinde 8.135 deneme kaydını analiz ederek bu soruya yanıt arıyor. Bulgular, geliştiricilerin agent skill’i inşa ederken sahip olduğu temel varsayımların çoğunlukla hatalı olduğunu gösteriyor.
Araştırma, skill’lerin eksik bilgi depoları gibi çalışmadığını ortaya koyuyor. Bunun yerine skill’ler, agent’ların karmaşık iş akışları sırasında rayından çıkmasını önleyen “çapa”lar (anchor) olarak işlev görüyor.
Ayrıca bir skill kataloğunu ölçeklendirmek beklenmedik davranışlara yol açıyor. Çok fazla skill, agent’ın doğru olanı seçme yeteneğini düşürüyor. Ama agent’lar, ilgili araçlardan yeterince kısmi rehberlik çıkarıp yine de başarılı olabiliyor. Bu mekanikleri anlamak, kırılgan bir demo ile dayanıklı bir production agent’ı inşa etmek arasındaki farkı oluşturuyor.
Skill kataloğunuzu bilimsel olarak nasıl test edersiniz?
AI mühendisleri genellikle skill geliştirirken ve seçerken sezgiye güveniyor. Agent skill kütüphanelerini çoğunlukla deneme yanılma yoluyla inşa ediyorlar.
Araştırmacılar, skill’lerin etkisini izole etmek için agent’ları Terminal-Bench 2.0 ve SkillsBench gibi çok adımlı ortamlarda değerlendirdi. Bu benchmark’lar karmaşık execution, debugging ve doğrulama gerektiriyor.
Araştırmacılar, aynı önceki deneyimi kullanarak üç farklı execution modunu karşılaştıran kontrollü deneyler yürüttü:
- Ham execution: Agent göreve önceden hiçbir deneyimi olmadan girişiyor.
- Workflow memory: Agent, geçmiş çalıştırmalardan ham ve gürültülü execution log’larını alıyor.
- Distilled (damıtılmış) skill: Agent, bu geçmiş çalıştırmalardan çıkarılmış temiz, standartlaştırılmış bir prosedürel özet alıyor.
Temel bulgu şu: deneyimi standartlaştırılmış bir skill’e damıtmak, ham workflow memory’ye kıyasla görev başarısını 6.06 yüzde puanı artırıyor. Bu da deneyimi nasıl formatladığınızın, deneyime sahip olmak kadar önemli olduğunu kanıtlıyor.
Geliştiriciler, kendi özel soyutlamalarının ham log’ları doğrudan prompt’a enjekte etmeye kıyasla gerçekten değer katıp katmadığını görmek için bu temel testi kendi ortamlarında tekrarlayabilir.
Runbook mu, tutorial mı: asıl içgörü
Çalışmanın temel içgörülerinden biri şu: “Skill’ler, gürültülü trajectory’ler execution’ı stabilize eden prosedürel çapalara dönüştüğünde işe yarar.” Bu, bir skill’in asıl odağının agent’a olgu öğretmek değil, bir görevi çözmenin adımlarını göstermek olması gerektiği anlamına geliyor.
Bulgulara göre, prosedürel çapalama başarılı skill vakalarının %65,7’sini oluştururken, açık bilgi enjeksiyonu sadece %4,5’lik bir pay alıyor.
Skill’ler genellikle üst düzey reasoning’i düzeltmek yerine, agent’lara execution sağlamlığı (robustness) sağlıyor. Örneğin, ortam altyapısı hataları (agent’ın tooling konfigürasyonu, dependency çözümleri veya genel ortam kurulumuyla boğuşması gibi) ham execution’da %5,3 iken, agent’lar damıtılmış skill kullandığında %0,2’ye düşüyor.
Bir örnekte, ham bir agent bir React patch’i nasıl yazacağını biliyordu ama latency doğrulama testinde başarısız oldu. API, agent istekleri seri hale getirdiği için gereken 800 milisaniyenin altı yerine 915 milisaniyede yükleniyordu.
Skill, agent’a bağımsız await’leri Promise.all’a dönüştürmesini, promise’leri erken başlatıp geç await etmesini söyleyen katı bir prosedürel runbook gibi davrandı. Execution sırasını çapalayarak agent, tüm testleri 11,74 saniyede geçti.
Geliştiriciler için çıkarım: Agent’lara olgu veya genel algoritma öğretmek için skill yazmayı bırakın. Skill’lerinizi, AI’yı katı bir operasyonel checklist’i izlemeye zorlayan standartlaştırılmış, adım adım runbook’lar olarak formatlayın.
Etiketlenmemiş deneyimin tehlikesi
Araştırmacılar, skill’lerin “kırılgan varsayımlar, uyumsuz bağlamlar veya yetersiz adaptasyon altında başarısız olduğunu” uyarıyor. Bu başarısızlıkların büyük bir nedeni, skill’lerin nasıl oluşturulduğundan kaynaklanıyor. Hangi çalıştırmaların başarılı hangilerinin başarısız olduğunu agent’a açıkça belirtmeden ham trajectory’lerden skill damıtmak, performansı ciddi şekilde düşürüyor.
Araştırmacılar bunu bir “ipucu yok” (no-hint) ablasyon deneyiyle kanıtladı. Bir Gemini agent’ına üç başarılı ve iki başarısız trajectory’den oluşan karma bir grup verdiler. Damıtma sırasında başarı/başarısızlık etiketleri görünür olduğunda, agent sonraki görevlerde %74,6 başarı oranına ulaştı.
Bu etiketler gizlendiğinde ise başarı %40,0’a düştü. Açık sonuç ipuçları olmadan agent, sinyali gürültüden ayıramadı ve halüsinasyonlar ile verimsizlikler ortaya çıkan skill kütüphanesine kalıcı olarak işlendi.
Geliştiriciler için çıkarım: Ham trajectory’ler değerli olsa da, skill damıtmak için doğru sinyalleri içerdiklerinden emin olmalısınız. Trajectory’lerinizin kalitesini ölçmek için LLM-as-a-judge kullanabilirsiniz.
Skill retrieval’ın acımasız (ve şaşırtıcı) matematiği
Devasa bir skill kataloğu inşa etmek ciddi retrieval darboğazlarına yol açıyor. Çalışma, skill havuzu 5’ten 100 seçeneğe büyüdükçe, çekilen skill’lerin gerçek kullanım kesinliğinin (precision) %29,6’dan %3,3’e sert şekilde düştüğünü buluyor.
Bu devasa kesinlik düşüşünün görev başarısını da çökerteceğini düşünürsünüz, ama veri sezgiye aykırı bir gerçeği ortaya koyuyor. Gemini agent’ında, havuz 100 seçeneğe büyüse bile downstream görev başarısı yaklaşık %36-39 aralığında sabit kaldı.
Araştırmacılar, “tam ground-truth çağrısının başarı için ne yeterli ne de gerekli olduğunu” not ediyor. Agent’lar sık sık yanlış skill’i çekse de, ilgili ancak ground-truth olmayan “dikkat dağıtıcılar” yine de agent’ın görevi geçmesine yardımcı olacak kadar kısmi prosedürel destek sağlıyor.
Örneğin, bir agent tam olarak checkout API debug skill’i yerine genel bir API debug skill’i çekerse, yine de execution’ını yönlendirecek değerli bir checklist elde ediyor.
Ancak büyük kataloglardaki asıl tehlike “semantik karışabilirlik.” Bir havuz, embedding uzayında birbirine neredeyse özdeş görünen skill’lerle dolduğunda, offline retrieval sistemleri doğru skill’i seçmekte zorlanıyor.
Geliştiriciler için çıkarım: Güvenilir sistemler inşa etmek için geliştiriciler önce skill’leri domain bucket’larına göre kapılayabilir, ikinci olarak da katı tetikleme koşulları kullanabilir.
Örneğin, 100 skill üzerinde düz bir vektör araması yerine iki seviyeli bir sistem kurun:
- Seviye 1 (domain bucket): Bir LLM router önce görevi frontend veya backend ortamı gibi belirli bir bucket’a kategorize eder.
- Seviye 2 (katı tetikleyici): O bucket içinde, agent bir skill’i yalnızca katı bir kural karşılandığında — örneğin terminal log’larında tam olarak “Connection refused” hata string’i tespit edildiğinde — çeker.
Sadece hafıza değil, soyutlama inşa edin
Skill’ler, önceki deneyim ham hafıza izleri olarak enjekte edilmek yerine yeniden kullanılabilir prosedürel çapalara damıtıldığında en iyi şekilde çalışıyor. Daha fazla hafıza biriktirmek, agent güvenilirliğinin cevabı değil.
Skill’lerinizi bir production runbook kütüphanesi gibi denetleyin, agent’larınızın onları doğru şekilde uygulayacak muhakemeye sahip olduğundan emin olun ve semantik karışabilirliği aşan mimariler kurun.
Araştırmacıların belirttiği gibi: “Skill kullanımı, tek bir hafıza-enjeksiyon mekanizması değil, bir yaşam döngüsü problemi olarak anlaşılmalı.”
Bir yanıt yazın