Çok ajanlı yapay zekâ sistemleri canlıda nasıl işletilir?

GOGOGO LLC'de çok ajanlı sistemler kuruyoruz: işi uzman ajanlar arasında yönlendiren bir orkestratör ve her birinin somut araçları. Kendi ürünlerimizi geliştirirken de her gün ajan kullanıyorum, GoTasty oyunu dahil. Ajanlar demodan çıkıp gerçek sistemlere dokunduğunda neyin önemli olduğunu burada topladım. Hiçbiri egzotik değil. Çoğu, herhangi bir servisten zaten beklediğimiz disiplinin, sıradaki adıma kendisi karar veren yazılıma uygulanması.

Çok ajanlı bir sistemi tek büyük bir prompttan ayıran ne?

Uzun bir prompt ve bağlı bütün araçlarla çalışan tek bir model kolay başlar, zor güvenilir. Yanlış bir şey yaptığında promptun hangi kısmının buna yol açtığını bilemezsiniz; birini kısıtlamak için hepsine dokunmanız gerekir. Çok ajanlı bir sistem işi böler: koşunun sahibi olan bir koordinatör her adımı hangi uzmanın yapacağına karar verir ve her uzmanın tek bir rolü vardır. Net roller net sorumluluk getirir: bir adım başarısız olduğunda kimin adımı olduğunu bilirsiniz.

Sistemi işletilebilir kılan da bu bölünme. Bir ajanı diğerlerini yeniden yayına almadan test edebilir, sürümleyebilir ve geri alabilir; her birine kendi modelini, bütçesini ve yetki setini verebilirsiniz.

Neden her adım loglanmalı?

Çünkü geçen salı olmuş bir koşu için "bunu neden yaptı?" sorusunu yanıtlamanız gerekecek ve model hatırlamayacak. Kuralımız şu: her devir, her araç çağrısı, her puan ve her sonuç; ajanın gördüğü girdi ve onu üreten ajan sürümüyle birlikte kaydedilir. Bu size üç şey verir:

• Yeniden oynatma. Başarısız bir vakayı yeni bir prompt ya da modelle tekrar çalıştırıp ikisini karşılaştırabilirsiniz.
• Denetim. Herkes bir kararı ona yol açan bağlama kadar izleyebilir; bir müşteri sorduğu anda bu önemlidir.
• Geri alma. Bir değişiklik işleri kötüleştirdiyse hangi koşulara dokunduğunu tam olarak bilirsiniz.

Yalnızca sonda değil, sınırlarda loglayın. İyi görünen bir son yanıt, hiç olmaması gereken bir araç çağrısını gizleyebilir. Bunu varsayılan olarak gözlemlenebilirlik yazısında daha ayrıntılı anlattık.

Bir ajanın araçları nasıl sınırlanır?

Mevcut olandan değil, işten başlayın. Yanıt taslağı yazan bir ajanın onları göndermesi gerekmez. Bir veritabanını okuyan ajanın yazma yetkisine ihtiyacı yoktur. Eklediğiniz her araç yeni bir başarısızlık yoludur; bu yüzden her ajan, işini bitirmesine yetecek en küçük seti alır ve araçlar tek bir ürün yüzeyiyle sınırlıdır.

Sonra eylemleri sonuçlarına göre ayırın. Okumak, taslak yazmak ve hesaplamak serbestçe çalışabilir. Geri dönüşü olmayan, para harcayan ya da kimlik bilgilerine dokunan her şey önce bir insanın onayını ister. Kendi kodlama ajanlarımızı da aynı kurala bağlıyoruz: GoTasty deposunda çalışma dallarına sormadan commit ve push yapabiliyorlar, ama geri dönüşü olmayan bir adımdan, bir ödemeden ya da bir kimlik bilgisinden önce soruyorlar; bazı bulut konsolu ayarları da doğrudan bir insana ayrılmış. Android emülatöründe QA ajanlarımız bir cihaza seri numarasıyla seslenmek, asla geniş bir kill komutu çalıştırmamak ve sabit portlar kullanmak zorunda. Ajanları çalışır hâlde bırakmayı güvenli kılan bu tür küçük kurallar.

Ajanlar işi birbirine nasıl devretmeli?

Bir paragrafla değil, tipli bir yükle. Bir uzman işi bir sonrakine verirken devir; görevin ne olduğunu, neye karar verildiğini, hangi kanıta dayandığını ve neyin hâlâ açık olduğunu söyler. Bir sonraki ajanın göremediği bir sohbette gizli durum yaşamaz. Yük doğrulanmazsa, bir sonraki ajan tahmin yürütmek yerine devir yüksek sesle başarısız olur.

Hafıza için de aynısı geçerli. Bağlam müşteri bazında ve sohbet bazında, sürümlü ve sorgulanabilir saklanmalı; böylece ajan geçmişi başka bir modelin yazdığı ve kimsenin kontrol etmediği bir özetten değil, bir kayıttan okur.

Çok ajanlı bir sistemin iyileşip iyileşmediği nasıl anlaşılır?

Puanlarsınız. Her ajanın, mümkünse kodla kontrol edilebilen bir iyi sonuç tanımı olmalı: yanıt soruyu karşıladı mı, build geçti mi, eylem politikaya uydu mu. Kodun kontrol edemediği yerde bir insan belli aralıklarla bir örneklem kontrol eder. GoTasty için QA ajanlarımız böyle çalışıyor: bir build, bir ajan iyi göründüğünü söylediğinde değil, logda sıfır Unity hatası olduğunda ve bot her bölgeyi kendi zaman aralığında açtığında geçer. Bot temposunu 15 saniyede bir kaydediyor; tempo koşuları sabit 1/30 sn adım ve tohumlanmış rastgelelik kullanıyor, bu yüzden aynı build'in iki koşusu aynı sayıları veriyor.

Zaman içindeki puanlar, bir model güncellemesinden sonraki kaymayı fark etmenin ve yeni bir ajanın yerini hak edip etmediğine karar vermenin yolu. Daha fazlası çok ajanlı sistemleri puanlamak yazısında.

Nereden başlamalı?

1. İş akışını adımlar hâlinde yazın ve sistemin dışındaki bir şeyi değiştiren adımları işaretleyin.
2. Her adıma bir ajan, bir rol ve en az araç verin.
3. Promptları yazmadan önce adımlar arasındaki devir yükünü tanımlayın.
4. İlk günden her sınırı, ajan sürümüyle birlikte loglayın.
5. Loglar kaldırabileceğinizi gösterene kadar geri dönüşü olmayan her eylemin önüne bir insan koyun.

Bunu kendi ürünlerimize nasıl uyguladığımızı görmek için ajan sistemleri sayfasıyla ya da bu sitedeki, her rakamı tarihi ve kaynağıyla listeleyen mühendislik kaydıyla başlayabilirsiniz.