Çok Modelli Yapay Zekâ Ajanlarında Deterministik Devir ve Geri Alma

Ajan sistemleri neden çoğu zaman modelde değil, devir noktasında kırılır

Ekipler çok modelli ajan mimarisini anlatırken genellikle uzman rollere odaklanır: planlama için bir model, kod veya işlem yürütme için başka bir model, özetleme için ayrı bir model, koruma katmanı için başka biri. Bu ayrım faydalıdır; ancak üretimdeki arızaların gerçek kaynağını çoğu zaman gizler. Pek çok ajan olayı, tek bir modelin zayıf olmasından değil, bileşenler arasındaki devrin belirsiz olmasından doğar. Bir model serbest biçimli bir talimat üretir, sonraki model bunu başka türlü yorumlar, araç çağrısı eksik varsayımlarla yapılır ve süreç kontrollü bir iş akışından çok doğaçlama bir zincire dönüşür.

Bu durum on-prem ortamlarda daha da kritiktir; çünkü ajanlar çoğu zaman iç API’lere, bilgi tabanlarına, bilet sistemlerine, dağıtım hatlarına ve operasyon araçlarına bağlıdır. Ajan artık sadece soru cevaplamıyorsa, her belirsiz devir güvenilirlik ve yönetişim problemine dönüşür. Planlayıcı “eski kayıtları temizle” dediğinde “eski” ne demektir? Yetkili kaynak sistem hangisidir? Silme serbest mi, yoksa sadece etiketleme mi yapılabilir? Aksiyon geri alınabilir mi? İş akışının yan etkisi varsa bu sorular istem metni yorumu seviyesinde bırakılamaz.

Çözüm, devirleri deterministik hale getirmektir. Bir devir, bir modelin diğerine sohbet eder gibi öneri bırakması olmamalıdır. Açık alanları olan bir sözleşme olmalıdır: tanımlı giriş alanları, tanımlı çıktı şeması, açık araç bütçesi, açık durdurma koşulları ve alıcı bileşen görevi reddederse ne olacağını gösteren toparlanma yolu. Çok modelli ajanlar, modellerin kendisi kadar aralarındaki boşluklar da tasarlandığında yönetilebilir hale gelir.

Her devri istem değil, sözleşme haline getirin

İyi bir devir sözleşmesi yapıdan başlar. Gönderen bileşen; görev kimliğini, onaylı bağlamı, kullanılabilecek araçları, güven seviyesini, beklenen çıktı tipini ve varsa zorunlu atıf ya da kanıt alanlarını iletmelidir. Alan model ya da servis ise paragraf halinde dönen serbest metin yerine şemaya uyan bir sonuç üretmelidir. JSON Schema, tipli iş akışı yükleri ve doğrulama ara katmanları kulağa agent söylemi kadar heyecanlı gelmeyebilir; ama altı ay sonra sistemi sürdürülebilir kılan şey tam olarak bunlardır.

Sözleşme aynı zamanda alıcının neyi yapamayacağını da tarif etmelidir. Örneğin özetleme modeli yalnızca çekilen metni kısa bir özet haline getirecekse, doğrudan yazma yetkili iş araçlarına erişimi olmamalıdır. Bir yürütme modeli bakım bileti açabilecekse, kendisine doğrulanmış ve sınırları belli bir bilet gövdesi verilmeli; spekülasyon dolu uzun sohbet geçmişi verilmemelidir. Her role dar kapsam tanımlamak, hem istenmeyen davranışı azaltır hem de olay sonrası incelemeyi çok daha kolaylaştırır.

Çoğu tasarımda eksik kalan önemli alanlardan biri de niyet belirsizliğidir. Her devir aynı kesinlikte olmamalıdır. Planlayıcı görevin “incele”, “öner” ya da “uygula” kategorisinde olduğundan emin değilse, bu belirsizlik de yükle birlikte taşınmalıdır. Sonraki bileşen böylece görevi reddedebilir, açıklama isteyebilir ya da süreci insan onayı gerektiren güvenli moda indirebilir. Deterministik ajanların çoğu zaman daha güvenli olmasının sebebi de budur: belirsizliği saklamak yerine görünür kılarlar.

Yolu model değil, iş akışı motoru veya durum makinesi yönetsin

Sözleşmeler tanımlandıktan sonra ikinci adım, bunları tek bir modele bırakmadan bir iş akışı mantığıyla zorlamaktır. Pratikte bu genellikle bir durum makinesi ya da on-prem platform içinde çalışan dayanıklı iş akışı motoru anlamına gelir. Temporal, Argo Workflows ve benzeri yapılar bu iş için uygundur. Orkestrasyon katmanı hangi aşamanın sırada çalışabileceğine karar verir, yükü doğrular, geçişi kaydeder ve yetkisiz sıçramaları engeller. Böylece kontrol akışı model çıktısından ayrılır; olgun sistemlerin tam da buna ihtiyacı vardır.

Basit ama etkili desenlerden biri; sınıflandır, retrieve et, planla, doğrula, uygula ve onayla gibi açık durumlar tanımlamaktır. Her durum için izin verilen model ya da servis, zaman aşımı, tekrar deneme kuralı ve olası sonraki durum listesi belirlenir. Modeller kendi alanlarında yetkin olabilir; ancak çalışma zamanında yeni akışlar icat edemezler. Planlama adımı izin verilmeyen bir araç isterse süreç devam etmez. Kapalı şekilde durur ve nedeni kaydedilir.

Bu yaklaşım kapasite yönetimini de iyileştirir. On-prem yapay zekâ ekipleri genellikle farklı gecikme ve donanım gereksinimlerine sahip heterojen model filoları işletir. Yolun sahibi orkestrasyon katmanı olduğunda hafif doğrulama işlerini küçük modellere, pahalı muhakeme adımlarını premium GPU’lara yönlendirmek ve araç çağrısı yapan servisleri serbest muhakeme modellerinden ayırmak kolaylaşır. Deterministik yapı yalnızca yönetişim için değil, kaynak yönetimi için de avantaj sağlar.

İlk yan etkiden önce geri alma senaryosu hazır olmalıdır

Gerçek sistemlerde oluşturma, güncelleme veya tetikleme yapabilen her ajan için geri alma kurgusu gerekir. Pek çok prototip burada tehlikeli biçimde eksik kalır. Bilet açabilir, kayıt değiştirebilir, iş tetikleyebilir veya mesaj gönderebilirler; fakat zincirin ortasında hata olursa ne yapılacağı tanımlanmamıştır. Kurumsal on-prem ortamlarda doğru desen çoğu zaman dağıtık sistemlerden gelir: idempotency key’ler, write-ahead intent log’lar, telafi adımları ve önerilen aksiyon ile kesinleşmiş aksiyon arasında net ayrım.

Örneğin ajan bir olay özetini alıp bilet açıyor, tanı paketi ekliyor ve bakım işi planlıyor olsun. Bilet açıldıktan sonra planlayıcı ekipman kimliği hatalı olduğu için işi reddederse, sistem yarım kalmış operasyon değişikliğini sessizce bırakmamalıdır. Ya bileti uygun biçimde kapatmalı veya inceleme için etiketlemeli, ya da süreci operatör müdahalesi bekleyen geri kazanılabilir durumda durdurmalıdır. Mekanizmanın ayrıntısı iş sürecine göre değişir; ama “elimden geleni yaptım” yaklaşımı kabul edilebilir değildir.

İyi kural şudur: geri döndürülemez aksiyonlardan önce onay noktası koyun ve yan etkileri varsayılan olarak idempotent tasarlayın. Aynı adım zaman aşımı sonrası tekrar çalıştırıldığında ikinci kez bilet açmamalı veya aynı değişikliği çoğaltmamalıdır. Geri alma tasarımına erken yatırım yapmak yavaşlatıyor gibi görünür; ancak üç iç sisteme dokunmuş hatalı bir ajan iş akışını sonradan çözmeye çalışmaktan çok daha ucuzdur.

Ajan platformunu demo zinciri gibi değil, üretim yazılımı gibi işletin

Deterministik devir tasarımı, güçlü gözlemlenebilirlikle birleştiğinde gerçek değer üretir. Her durum geçişi; iz, doğrulanmış yük, politika kararı, model kimliği ve araç çağrısı sonucuyla birlikte izleme sistemine akmalıdır. OpenTelemetry uyumlu tracing ve merkezi loglama burada büyük avantaj sağlar. Platform ekipleri böylece belirli bir çalıştırmayı yeniden canlandırabilir, hangi devrin neden kabul edildiğini görebilir ve gecikme ya da hata oranlarının nerede biriktiğini anlayabilir. Bu görünürlük yoksa, en iyi sözleşme modeli bile bakımı zor hale gelir.

İlk günden yeniden oynatma kabiliyeti kurmak da önemlidir. Üretim olaylarını anlamak, aynı yükleri güvenli ortamda tekrar çalıştırıp model sürümleri veya istem değişiklikleri arasındaki farkı görmekle çok kolaylaşır. Buna yeni yönlendirme kuralları için canary yayınları ve eksik bağlam, yavaş araçlar, bozuk çıktı şemaları veya reddedilen izinleri simüle eden hedefli kaos testleri eklenmelidir. Ajan bu koşullarda zarif biçimde başarısız olamıyorsa, geniş ölçekli kullanıma hazır değildir.

Temel ilke nettir: çok modelli ajanlar, birbirine bağlı akıllı istemler topluluğu gibi değil, kontrollü bir dağıtık sistem gibi davranmalıdır. Devirler sözleşmesel olduğunda, durum geçişleri dış katmanda zorlandığında ve geri alma yolları önceden tasarlandığında, mimari iş birimlerinin güvenebileceği kadar öngörülebilir hale gelir. Etkileyici iç demoyla gerçekten güvenilir bir on-prem ajan platformu arasındaki fark tam da budur.

Kapak görseli, Jordan Harrison tarafından çekilmiş ve Unsplash üzerinde yayımlanmıştır.