Yıllardır büyük dil modellerini (LLM) dar bir sohbet penceresinin dışına çıkarmanın yollarını düşünüyorum. Denemeleri ve başarılı/başarısız yaklaşımları gözlemledikçe, doğru yöntem konusunda kendi fikirlerimi oluşturdum. Bu yazıda, bu fikirleri ve üzerinde çalıştığım konsepti paylaşacağım. İyi bir koşum takımı (harness) doğal olarak ajan tarafından sezgisel anlaşılabilmeli, her şey şeffaf olmalı (ajanın kendini geliştirmesi veya onarımı için), mümkün olduğunca yalın ve esnek olmalı, hatalardan ve güncellemelerden etkilenmemeli, zamanla bellek bozulması veya düşüş yaşanmamalıdır. LLM'lerin artan zekasıyla bu koşum takımları nihayet güvenilir hale gelecek. Asıl mesele, botunuza yüklediğiniz bilişsel yükü (token cinsinden) azaltmaktır.
Yıllar içinde öğrendiğimiz en önemli şeylerden biri mümkün olduğunca deterministik olmaktır. LLM hangi hedefe ulaşacağını seçmeli, ancak bu hedefe giden yoldaki değerlendirme adımları iyi tanımlanmış olmalıdır. Çekirdek komut dosyası (core prompt) mümkün olduğunca küçük tutulmalı ve LLM çalışma zamanında hangi becerileri yükleyeceğine kendisi karar vermelidir. LLM'ler bağlam sınırına yaklaştıkça sorun çıkarmaya başlar. İyi bir koşum takımı, LLM'in eğitim verilerinde bolca bulunan kodlama ve sistem yönetimi bilgisinden yararlanmalıdır. LLM'ye zaten aşina olduğu bir ortam sağlayın; onu yeni bir ortamda yönlendirmek token israfına yol açar. Ayrıca değerli bağlam, dosya keşfi veya dolaşımı gibi işlemlerle harcanmamalıdır; iyi koşum takımları delegasyonu kolay ve verimli kılar. LLM'e hafif gelen ama arka planda günlük kaydı, sağlık kontrolleri, güvenlik önlemleri gibi birçok işi yapan bir yapı hedeflenmelidir.
Her şey savunmasızdır ve tüm ajanlar eninde sonunda başarısız olur. İki tür ajan hatası vardır: LLM düzeyi ve koşum düzeyi. LLM düzeyindeki hatalar doğrudan düzeltilemez ancak koşum takımı tarafından riski azaltılabilir. Koşum düzeyindeki hatalardan kurtulmak mümkündür ve LLM'in sıra tabanlı doğası sayesinde çalışma zamanında düzeltilebilir. Bir hatayı düzeltmek için ajanın iyi bir günlüğe ve net bir hata mesajına ihtiyacı vardır. Bu gereksinimlerin çoğu aslında eski sorunlardır; sadece kullanıcı yerine ajan kelimesi kullanılmaktadır. Bu nedenle, gerçekten kod yazılan önceki zamanlardan ne öğrenebiliriz sorusunu sormakta fayda var.
Benim hipotezim: Unix/Linux ortamı doğal bir adaydır ve birkaç değişiklikle ajan koşum takımına dönüştürülebilir. Unix konusunda uzman değilim, ancak son on yılda tarihini, tasarım kararlarını ve kullanımını öğrendim. Birçoğu sorunumuza harika bir şekilde uyuyor; bazıları ise uymuyor. Unix'i doğrudan bir karşılaştırma değil, motive edici bir benzetme olarak düşünün. Ritchie ve Thompson'ın Unix felsefesi: Tek bir işi yapan ve onu iyi yapan programlar yazın. Yeni bir iş için yeni program yazın, eskisine özellik eklemeyin. Programların birlikte çalışmasını sağlayın. Her programın çıktısını başka bir programın girdisi olarak bekleyin. Metin akışlarıyla çalışın çünkü bu evrensel bir arayüzdür. Bu ilkeler, günümüz koşum takımlarının aşırı karmaşık olması, çok fazla iş yapmaya çalışması ve ajanın kendi üzerinde kontrol sahibi olamaması gibi sorunları mükemmel şekilde özetliyor.
Buradan kendi koşum takımı tasarım ilkelerimizi türetebiliriz: Modüler, şeffaf, tek işi iyi yapan ve hatada ses çıkaran araçlar yazın. Birlikte çalışan araçlar, beceriler ve bağlayıcılar yazın. Beceriler iş akışlarını belirler, araçlar bunları yürütme yöntemidir, bağlayıcılar ise ajanın manipüle ettiği verilerdir. Metin akışları evrensel bir arayüzdür ve dil modeli bu konuda avantajlıdır. Her şey düz metin dosyası olmalıdır. Bu ortama 'Ambiyans' adını veriyorum. Ambiyans'ta her şey bir dosyadır. JSON işleme, karmaşık curl komutları veya zor regex'lerle uğraşmak yerine, LLM'in tercih ettiği düz metin kullanılır. Harici veri kaynaklarıyla uğraşırken koşum takımı, veriyi LLM'e ulaşmadan temizlemelidir. Tüm bu verileri depolamak için bir yere ihtiyacınız var. Her şeyi kategorize ederek dizinlere ayırmak, ajana çok sayıda token kazandırır.
Dosya Sistemi Hiyerarşi Standardı (FHS), temiz bir Linux kurulumunun nasıl görünmesi gerektiğini belirler. LLM'ler Linux dosya sisteminde gezinme konusunda uzmandır, bu nedenle harici veri kaynaklarımızı stratejik olarak VFS'ye yerleştirmek ajanın kendini evinde hissetmesini sağlar. Günlükler /var'a, yapılandırma dosyaları /etc'e, ajan çalışma alanı /home'a gibi. Ek bir fayda da sizin ve ajanın grep, find, which gibi araçlarla kolayca denetim yapabilmesidir. Asıl zorluk, dağınık dış dünyayı bu sahte VFS'ye sığdırmaktır. Aşağıdaki eşlemeyi kullanıyorum: Koşum → Unix Eşdeğeri: Ajanlar → /home/... gibi. Bu yapı, LLM'in kodlama bilgisini kullanarak verimli bir ajan ortamı oluşturmayı amaçlıyor.
Kaynak: eardatasci.github.io
