Çok ajanlı sistemleri ayakta tutan sıkıcı kalıplar

Çok ajanlı sistemler sıkıcı nedenlerle bozulur. İlginç nedenler hakkında çok yazıldı: koordinasyon hataları, kilitlenmeler (deadlock), birbirinden açıklama isteyen ajanlar arasında dönen sonsuz döngüler. Bunlar gerçek sorunlardır ve literatür onları ele alır. Canlıya geçişi batıran ise sıkıcı nedenlerdir ve sayıları beştir.

Birinci kalıp: kapsamı sınırlı bağlam

Her şeyi görebilen bir ajan her şeyi kullanır. Yalnızca ihtiyacı olanı görebilen bir ajan ise daha iyi iş çıkarır; daha hızlı çalışır ve hataları daha küçük kalır.

Her ajana, sistemin verisinden kapsamı sınırlı bir görünüm verilmelidir. Örnek olarak kredi başvurularını karşılayan bir tasarımı ele alalım. Başvuru ajanı başvuru formunu görür, başka hiçbir şeyi görmez. Kredi bürosu ajanı büro arayüzünü ve ihtiyaç duyduğu kimlik alanlarını görür, başka hiçbir şeyi görmez. Sentez ajanı kendinden önceki ajanların çıktılarını görür, başka hiçbir şeyi görmez. Hiçbiri müşteri kaydının tamamını görmez.

Bu disiplin başta rahatsız eder. Her yeni ajan, daha fazla bağlamla daha yararlı olacakmış gibi gelir. Bu isteğe direnin. Bağlam sızması yüzünden yanlış iş yapan bir ajanın hatasını ayıklamanın bedeli, biraz daha küçük bir ajan kurmanın bedelinden yüksektir.

İkinci kalıp: açık iş aktarımları

Bir uzman ajanın işi diğerini besliyorsa iç iş aktarımı ortak bir değişken değil, tipi tanımlı bir olaydır. Tipi tanımlı bir iş aktarımının sözleşmesi vardır. Ortak değişkenin yoktur. A2A ise yalnızca kurulumun sınırında, bağımsız işletilen bir ajan sistemiyle birlikte çalışmak için kullanılır.

Tipi tanımlı sözleşme sayesinde hata “mesaj gelmedi” ya da “mesaj doğrulamadan geçmedi” biçiminde ortaya çıkar; ikisi de gözlemlenebilir. Ortak değişkendeki karşılığı ise “değişkenin tipi yanlıştı” ya da “değişken okunduktan sonra, kullanılmadan önce üzerine yazıldı” olur; ikisi de sessizdir.

Ortak değişkenler, bir prototipin ikinci ya da üçüncü ajanında, bir şey çalışsın diye aceleyle yazılmış kod olarak ortaya çıkma eğilimindedir. Birini tipi tanımlı bir iş aktarımına çevirmek, daha önce görünmeyen bir hata sınıfını yüzeye çıkarmanın güvenilir bir yoludur. Tip sınırı, mesajın gerçekte ne içerdiği sorusunu sormaya zorlar.

Üçüncü kalıp: hata bütçeleri

Her ajanın bir hata bütçesi vardır. Bütçe tükendiğinde ajan durur ve orkestrasyon katmanı işi onun etrafından dolaştırır. Bütçe kurulum başına, ajan başına ve zaman penceresi başına tanımlanır.

Bütçeler küçüktür: kısa bir zaman penceresindeki çağrıların yüzde birinden de az bir kısmı. Bütçe, gerçek arka plan hatalarıyla nadiren tükenecek, bir şeyler ters gittiğinde ise hızla tükenecek biçimde belirlenir. Kesin rakam genel bir kurala değil, kuruluma ve onun hata toleransına aittir. Bir ajan bütçesini tükettiğinde orkestrasyon katmanı onu duraklatır ve nöbetçi mühendisi uyarır. Ardından ya daha az yetenekli bir yedeğe geçer ya da işi insan incelemesine yönlendirir. Otomatik yeniden başlatma yapmayız.

Bütçe şu yüzden var: ajanlar deterministik olmayan davranışı olan sistemlerdir ve “bu ajan şu anda bozuk mu” sorusunun her zaman bir cevabı yoktur. Bütçe soruyu somutlaştırır: bütçe aşılmışsa cevap evettir.

Dördüncü kalıp: gözlemlenebilirlik

Her ajan, her çağrı için yapılandırılmış bir olay üretir: girdi, çıktı, gecikme, kullanılan model, token sayısı ve ajanın çıktıya duyduğu kendi güveni. Olaylar ayrı bir yapıya değil, müşterinin diğer sistemlerinin kullandığı gözlemlenebilirlik altyapısına gider.

Buradaki disiplin, ajanları yapay zekâ büyüsü gibi değil, birer servis gibi göstermektir. Bir servisin logları, izleri (trace) ve metrikleri vardır. Bir ajanın da vardır. Bir ajan tuhaf davrandığında teşhis yolu, nöbetçi mühendisin herhangi bir serviste izleyeceği yolla aynıdır: izi okumak, girdilere bakmak, metriği kontrol etmek.

Direnilmesi gereken bir eğilim var: modelin ara akıl yürütmesini loglamak. Bu kayıt uzundur, saklaması pahalıdır ve nadiren bir şey anlatır. Son girdi ve çıktı, gecikme ve güven düzeyi yeter.

Beşinci kalıp: kapatma anahtarı

Bir sistemin, ajanları kapatıp trafiği mevcut bir yedek yola (fallback) yönlendiren tek bir anahtara ihtiyacı vardır. Yedek yol bazen sistem gelmeden önce çalışan iş akışıdır, bazen insan incelemesidir. Yedek yolun isteğe bağlı olduğu bir senaryo yoktur.

Anahtar, ajanlardan herhangi biri devreye alınmadan önce kurulur. Kapatma anahtarı test edilmemiş bir sistem canlıya geçişe hazır değildir. Bu test, işletme kılavuzu (runbook) üzerinden yapılan masa başı tatbikatının parçasıdır.

“Bu anahtar hiç kullanılacak mı?” sorusunun dürüst cevabı şudur: en olası nedenler ajanların yanlış davranması değil, sistemin beslendiği kaynaklardaki sorunlardır; bir bağlayıcı (connector) kesintisi ya da bir veri ambarı taşıması gibi. Tasarım da buna göre kurulmalıdır: kaynaklarda bir şey bozulduğunda, sorun çözülene kadar operasyon yedek yol üzerinden sürer.

Bu kalıplar ne değildir

Beş kalıp, çok ajanlı bir sistemin kendi içine çökmesini önlemenin yoludur. Ajanları daha akıllı, daha hızlı ya da daha yetenekli yapmanın yolu değildir. Onlar ayrı sorunlardır ve literatürleri de ayrıdır. Yukarıdaki kalıplar işin sıkıcı yarısıdır. İlginç yarının canlıya çıkmasını sağlayan da bu sıkıcı yarıdır.

Bir sonraki not, bilgi erişimi (retrieval) ile ince ayar (fine-tuning) arasındaki seçimi ele alıyor; modeliniz hakkında değil, veriniz hakkında dört soru olarak.