Meta Engineering, 19 Ekim’de tavsiye sistemleri için veri sütunu onboarding’ini otomatikleştiren AI ajan mimarisinden öğrendiklerini paylaştı. Yazının ana tezi: Merkezî ajana daha az iş vermek güvenilirliği artırıyor. Ekip buna thin orchestrator (ince orchestrator / yönlendirici) kalıbı diyor: yaklaşık 1.300 satırlık bir orchestrator 20’den fazla iş akışını 14 uzmanlaşmış alt ajana yönlendiriyor; kendisi hiçbir alan muhakemesi yapmıyor.
Tek “akıllı” ajan neden yetmedi?
İlk yaklaşım, tüm alan bilgisini, yapılandırma şemalarını, kod üretme kurallarını, doğrulama gereksinimlerini ve 10’dan fazla veri kaynağının doldurma kalıplarını bilen tek bir ajandı. Demo ortamında çalışıyordu; üretimde kavramları birbirine karıştırmaya ve yanlış alt sistemin adlandırma kurallarını uygulamaya başladı. Ekip, Mount Sinai’deki Windreich AI bölümünden bir ön baskıya atıfta bulunarak, düzenlenmiş çok ajanlı sistemlerin 80 görevlik partilerde yüzde 65,3 doğruluk tutarken tek ajanların yüzde 16,6’ya düştüğünü ve token kullanımını 65 kata kadar azalttığını not ediyor. Alternatif tek ajan yaklaşımında, görev başına elle yazılmış özel sistem istemiyle başarı yüzde 70–80 iken, bu destek olmadan yüzde 10–20’ye düşüyordu.
İki katmanlı yapı
- Belirleyici orchestrator: Niyeti sınıflandırır, gerekli alanları toplar, güvenilirlik kapılarını çalıştırır ve doğru uzmana yetkilendirir. Kod üretmez, yapılandırma oluşturmaz, kod tabanına dokunmaz.
- 14 uzman alt ajan: Her biri yalıtılmış bağlamda tam alan uzmanı (şema yönetimi, doldurma/population, doğrulama vb.). Hiçbiri bütün resmi görmez; bu kasıtlı bir özellik.
Her istek için sabit 7 adımlık protokol uygulanıyor: ilgili alt ajanın talimat dosyasını oku → hedefin zaten var olup olmadığını kontrol et → kullanıcıdan gerekli alanları topla → çıkarılabilenleri otomatik keşfet → aktif uyarı veya zorunlu inceleme için güvenilirlik kapısı → alt ajana yetkilendir → sonuçları işle. Yalnızca 6. adım LLM muhakemesi gerektiriyor ve bu, yalnızca kendi alan bilgisi yüklü yalıtılmış alt ajanın içinde oluyor.
İş akışı şablonları
Yeni kullanım alanı için yeni ajan yazmak yerine mevcut ajanları farklı sıralayan iş akışı şablonları kullanılıyor. Örnekler: Sütun Onboarding (Şema → Doğrulama → Doldurma → Test), Olay Onboarding, Pipeline Migration. Bilgi dosyaları (25+) çalışma zamanında yükleniyor; güncelleme orchestrator değişikliği gerektirmiyor.
Sonuçlar
Meta’ya göre yeni bir sütun için yapılandırma hazırlığı elle 3–4 gün, önceki yapılandırma odaklı sistemle yaklaşık bir gün sürerken thin orchestrator sistemi bunu bir saatin altına indiriyor. Sistem değişikliklerinin yaklaşık üçte ikisi önemli insan düzenlemesi olmadan kabul ediliyor. Ekip, ağır orchestrator’ın halüsinasyon ürettiğinde hatanın aşağı akıştaki her şeye yayıldığını; ince orchestrator’ın yönlendirme ve güvenilirlik adımlarının LLM muhakemesine dayanmadığı için hata alanını daralttığını savunuyor.
Henüz yorum yok. İlk yorumu siz yapın!