Multi-Agent: Paralel Hız Değil, Bölünebilir İş

Neyi paralelleştiriyoruz?

Önceki yazıda akışı kodda yazmıştık: zincir, yönlendirici, planlayıcı–işçi. Üçüncü desende plan uzadıkça süre uzuyor. “Geçen ayın reddedilen çekimleri” 34 kayıt demekti ve her kayıt için aynı iş yapılıyordu: kaydı çek, red sebebini oku, müşterinin önceki çekimlerine bak, bir etiket ver.

Bu iş paralelleştirmeye uygun görünüyor. Uygun olup olmadığını ölçen üç soru var:

Üçüncü soruya “kısmen” demem gerekiyordu ve ilk koşuda demedim. Bedelini birleştirme adımında ödedim.

Sahadan: 34 çekim, 4 agent, iki hata

İlk kurgu basitti: orchestrator 34 kaydı dörde böldü, dört alt agent aynı prompt ile çalıştı, her biri kendi payını inceledi ve sonucu ozet.md dosyasına ekledi.

Token’ın 3,4 katına çıkması sürpriz değil: her alt agent kendi system prompt’unu, tool tanımlarını ve talimatını baştan taşıyor. 4 agent = 4 kez sabit giriş maliyeti. Buna razıydım. Razı olmadığım iki şey vardı.

Birinci hata: ortak dosyaya yazmak

ozet.md’ye dört agent aynı anda satır ekledi. İkisi aynı saniyede okudu, ikisi de kendi satırını ekleyip yazdı; ikincisi birincisinin satırını sildi. Bu tam olarak stok neden eksiye düşer yazısındaki olay — oku–değiştir–yaz. Tek fark: orada iki thread vardı, burada iki model. Modelin akıllı olması bu yarışı çözmüyor; çözen şey her agent’ın kendi çıktısını ayrı yere yazması ve birleştirmeyi kodun yapması.

# YANLIS: dort agent ayni dosyaya
for parca in parcalar:
    spawn(agent, prompt=parca, cikti="ozet.md")   # yaris

# DOGRU: her agent kendi kaydini dondurur, birlestirme kodda
sonuclar = paralel_calistir(
    [lambda p=p: alt_agent(p) for p in parcalar], es_zamanli=3
)
rapor = birlestir(sonuclar)      # kod: sirala, tekille, sayi kontrol et

İkinci hata: mükerrer okuma

13 tool çağrısı mükerrerdi. Sebebi bölme kuralıydı: kayıtları sırayla dörde bölmüştüm, ama aynı müşterinin iki çekimi iki farklı agent’a düşmüştü. İkisi de o müşterinin geçmişini çekti. Çözüm bölme kuralını değiştirmekti: kayda göre değil, müşteriye göre böl. Aynı müşterinin bütün kayıtları tek agent’a gider. Bu worker sharding yazısındaki kuralın aynısı: parçalama anahtarı, işin doğal anahtarıdır.

Alt agent’ın context’i: kazancın yarısı

Multi-agent’ın konuşulmayan faydası hız değil, izolasyon. Tek agent 34 kaydı incelerken hepsi aynı pencerede birikir: 34 kaydın ayrıntısı, 71 tool cevabı, ara notlar. 20. kayda geldiğinde ilk kayıtların ayrıntısı ya kaymıştır ya da kararını bulandırıyordur. (Ayrı yazının konusu.)

Alt agent’ta pencere temiz: 8–9 kayıt, kendi tool cevapları, başka hiçbir şey. Kalite farkını ölçtük: elle etiketlediğim 34 kaydın karşılığında tek agent 27’sini doğru etiketledi, dörde bölünmüş hâli 31. Aynı model, aynı prompt; fark sadece önüne konan yığın.

Bedeli de burada: alt agent’ın gördüğü ayrıntı yukarı çıkmaz. Yalnızca özeti çıkar. Bu yüzden alt agent’ın çıktısı serbest metin değil, sabit alanlı bir kayıt olmalı:

{
  "kayit_no": "WD-24817",
  "etiket": "kyc_eksik",          # kapali kume: 6 etiket + diger
  "gerekce": "Adres belgesi 6 aydan eski.",   # tek cumle, 200 karakter
  "guven": "yuksek",              # yuksek | dusuk
  "bakilan_kayit": 3              # kac tool cagrisi yapildi
}

“Güven” alanı sonradan eklendi ve en çok işe yarayan alan oldu: düşük güvenli 5 kaydı birleştirme adımı ayırıp insana bıraktı. Modelden emin olmasını istemek yerine, emin olmadığını söyleyebileceği bir alan açmak daha ucuz.

Birleştirme: asıl iş burada

Dört özet geldi, rapor kendiliğinden oluşmuyor. Birleştirmede çıkan sorunlar:

• Sayı tutmuyor. 34 gönderildi, 33 geldi. Birleştirme adımının ilk işi sayım: gönderilen parça sayısı ile dönen kayıt sayısı eşit mi? Değilse rapor üretilmez, hata verilir.
• Aynı şeye iki ad. Bir agent kyc_eksik, diğeri belge_eksik yazmıştı. Kapalı etiket kümesi bunu çözdü; küme açık olduğu sürece her agent kendi sözlüğünü uydurur.
• Mükerrer kayıt. Aynı müşterinin iki çekimi iki agent’a düştüğünde iki kez raporlandı. Bölme kuralı düzelince bitti.
• Sıra. Paralel koşuda dönüş sırası rastgeledir. Rapor her koşuda farklı sıralanıyorsa iki raporu diff ile karşılaştıramazsın. Birleştirme adımı deterministik sıralar: kayıt numarasına göre.

Bunların hiçbiri model işi değil: sayım, eşleme, tekilleştirme, sıralama. Birleştirmeyi bir modele verdiğim ilk denemede 34 kaydın 2’si rapora hiç girmedi ve fark etmem iki gün sürdü. Kodun yaptığı birleştirmede aynı hata olursa program duruyor.

Topoloji: yıldız, zincir değil

İnternetteki çoğu multi-agent örneğinde agent’lar birbiriyle konuşuyor: “eleştirmen agent”, “yazar agent”, “yönetici agent”. Bir kez denedim. İki agent — biri kaydı etiketliyor, diğeri etiketi denetliyor — 9 tur boyunca birbirlerine yazdılar ve sonunda aynı yanlış etikette anlaştılar. Denetleyici, denetlediği şeyin gerekçesini okuyunca ikna oldu.

Önce tek agent’ı düzelt

En önemli madde en sonda çıktı: 11 dakikalık tek agent koşusunu inceledim. 6 dakikası aynı raporu üç kez çekmeye gidiyordu. Tekrar koruması ve doğru bir tool sözleşmesiyle tek agent 11 dakikadan 5 dakika 40 saniyeye indi — hiçbir paralellik olmadan, token artışı olmadan.

Sonra dörde böldüm: 3 dakika 12 saniye değil, 1 dakika 50 saniye. Yani paralelleştirmeden önceki düzeltme, paralelleştirmenin kendisinden daha çok kazandırdı ve bedavaydı. Sıra önemli: bozuk işi paralelleştirirsen bozukluğu dört kopyalarsın, faturası da dört katına çıkar.

Son satırda token hâlâ tek agent’ın 2,8 katı. Buna değdi mi? Bu iş ayda bir çalışıyor ve raporu sabah toplantısına yetiştirmesi gerekiyor: değdi. Günde 400 kez çalışan bir iş olsaydı cevap “hayır” olurdu. Görev başı maliyet hesabı tam olarak bu soruyu cevaplamak için var.

Ne izlemeli?

• Paralellik verimi. Tek agent süresi ÷ (alt agent sayısı × paralel süre). 1’e yakınsa bölme iyi; 0,5’in altındaysa parçalar bağımsız değil.
• Mükerrer tool çağrısı oranı. Bölme anahtarının yanlış olduğunu söyleyen tek sayı. Bizde %18 → %0.
• Alt agent başına token. Biri diğerlerinin iki katıysa parça dengesizdir.
• Birleştirmede reddedilen kayıt sayısı. Sayım tutmazsa rapor üretilmez; bu sayı sıfırdan büyükse kök sebep alt agent sözleşmesindedir.
• Düşük güvenli kayıt oranı. İnsana düşen iş. Artıyorsa girdi zorlaşmıştır, model değil.
• Aynı girdiye aynı rapor. Deterministik sıralama sonrası diff temiz olmalı.

Kontrol listesi

Sonuç

Dört agent 11 dakikayı 3 dakikaya indirdi ve ben sevindim. Sevinmem gereken yer orası değildi: asıl kazanç, tek agent’ın boşa geçen 6 dakikasını bulduğumuzda geldi. Paralellik onun üstüne bindi ve iyi bir iş çıktı — ama sırayı ters kurmuş olsaydık, bozuk işi dört kopyalamış ve faturayı üçe katlamış olacaktık.

İki agent aynı dosyaya yazdığında öğrendiğim şey de yeni değildi: bu bir race condition ve modelin zekâsıyla çözülmüyor. Alt agent’lar kendi kayıtlarını döndürür, birleştirmeyi kod yapar, sayım tutmazsa program durur. Model burada yok; olmaması iyi.

Akılda kalacak cümle: multi-agent bir hız tekniği değil, bir bölme tekniğidir. İşi bölebiliyorsan agent sayısı bir mühendislik kararıdır. Bölemiyorsan, kaç agent eklersen ekle aynı işi birkaç kez yapıyorsundur.