Mixture of Agents (MoA) Nedir? Çok-LLM İşbirliği

Bir soruyu üç farklı insana sorsanız ve aldığınız yanıtları kritik bir gözle bir araya getirseniz, tek bir kişinin anlık yanıtından genellikle daha sağlam bir sonuç elde edersiniz. Mixture of Agents (MoA) bu fikri LLM dünyasına taşıyor: birden fazla model bağımsız yanıtlar üretiyor, bir aggregator bu yanıtları harmanlayıp tek ve tutarlı bir çıktı oluşturuyor. 2024’te Together AI araştırmacılarının yayımladığı çalışma, bu yaklaşımın AlpacaEval 2.0 ve MT-Bench gibi standart kıyaslamalarda GPT-4 Turbo’yu geride bıraktığını gösterdi; ve üstelik bunu yalnızca açık kaynak modellerle başardı.

Önce bir karışıklığı çözelim: MoA, MoE değil

“Mixture of” ifadesini paylaştığı için Mixture of Experts (MoE) ile aynı şey sanılabiliyor. Bu iki kavram farklı düzlemlerde çalışıyor.

MoE bir model mimarisi. Tek bir modelin içinde, bir router hangi FFN uzmanlarının aktive edileceğine karar veriyor. Tüm sistem tek bir eğitilmiş ağırlık kümesine dayanıyor. Mixtral 8x7B veya Llama 4 Scout’u açıp çalıştırdığınızda zaten MoE kullanıyorsunuz; bu mimariyi dışarıdan göremezsiniz.

MoA bir sistem tasarımı. Birden fazla ayrı ve bağımsız LLM aynı göreve yanıt veriyor, ardından bu yanıtlar harici bir orkestrasyon katmanında birleştiriliyor. Her model ayrı bir API çağrısı; aralarında ortak ağırlık yok. MoE’ye kendi içinde olan bir şey iken, MoA dışarıdan uygulanan bir süreç.

MoA’nın her bir proposer modeli MoE mimarisini kullanabilir. GPT-4o, Mixtral ve Claude’u bir MoA pipeline’ında birleştirdiğinizde, GPT-4o ve Mixtral zaten içlerinde MoE çalıştırıyor olabilir. MoA, bu modellerin üzerinde çalışan bir katman.

MoA mimarisi: Proposer ve Aggregator

MoA iki temel rol tanımlıyor.

Proposer (Öneren)

Proposer, görevi bağımsız olarak işleyen herhangi bir LLM. Proposer’lar paralel çalışır; birbirinin yanıtını görmez. Aynı modeli birden fazla proposer olarak kullanmak mümkün (farklı temperature ayarlarıyla çeşitlilik elde edilebilir), ama asıl güç farklı modelleri bir arada kullanmaktan geliyor. GPT-4o, Claude Sonnet, Gemini Pro ve Qwen gibi modeller farklı eğitim verisi, farklı hizalama yöntemi ve farklı güçlü yanlarla geliyor; bu çeşitlilik aggregator için zengin bir hammadde oluşturuyor.

AI agent framework’leri aracılığıyla her proposer görev bazlı araçlarla donatılabilir; web arama yapan bir proposer, kod çalıştıran başka bir proposer, vektör veritabanından çeken bir diğeri. MoA bu durumda saf bir LLM-ensemble olmaktan çıkıp gerçek bir çok-ajan sistemi haline geliyor.

Aggregator (Harmanlayıcı)

Aggregator, tüm proposer yanıtlarını bağlam olarak alıp bunları sentezleyen LLM. Görevi yanıtları yeniden üretmek değil; hangi kısımların doğru, hangi kısımların güvenilmez olduğunu değerlendirmek, çelişkileri çözmek, eksikleri tamamlamak ve tutarlı bir nihai yanıt üretmek. Bu rol genellikle daha güçlü bir modele verilir; ama Together AI’nin çalışmasında aggregator olarak açık kaynak Qwen modeli kullanılıp ticari modelleri geride bırakan sonuçlar elde edildi.

MoA birden fazla katmana genişletilebilir: Layer 1’deki proposer yanıtları, Layer 2’deki proposer’lara ek bağlam olarak verilebilir. Bu çok katmanlı yapı zincir düşünme (chain-of-thought) mantığını model ensembline taşıyor; her katmanda yanıtlar rafine oluyor. Son katmanda bir aggregator nihai çıktıyı üretiyor.

Neden çalışıyor: ensemble etkisi ve model çeşitliliği

MoA’nın teorik dayanağı LLM-as-judge araştırmalarına uzanıyor. Bir LLM, başka bir LLM’in yanıtını değerlendirirken, sıfırdan o yanıtı üretmekten daha tutarlı ve dikkatli çalışıyor. Aggregator, yanıt üretmek yerine yanıtları sentezliyor; bu görev ayrımı model kapasitesini daha verimli kullanıyor.

İkinci etken model çeşitliliği. Farklı LLM’lerin farklı alanlarda farklı hata profilleri var. GPT-4o ve Claude aynı yanlış bilgiyi bağımsız olarak üretmesi olası değil; birindeki hata diğerinde çoğunlukla yok. Aggregator, azınlıkta kalan yanlış yanıtı ayıklayabiliyor. Bu mantık klasik makine öğrenmesi ensemble yöntemlerinin (Random Forest, Gradient Boosting) LLM dünyasındaki karşılığı.

Üçüncüsü: akıl yürüten modellerdeki test-time compute etkisine benziyor. Tek bir model için daha fazla hesaplama zamanı yerine, birden fazla model için paralel hesaplama harcıyorsunuz; sonuç benzer bir kalite artışı. Reasoning modellerinin çoklu örnekleme (best-of-N) stratejisini, MoA birden fazla farklı model üzerinde uyguluyor.

Python ile minimal MoA uygulaması

Aşağıdaki örnek iki proposer (GPT-4o-mini ve Claude Haiku) ile bir aggregator (GPT-4o) kullanıyor. Paralel çalışma ThreadPoolExecutor ile gerçekleşiyor:

from openai import OpenAI
import anthropic
from concurrent.futures import ThreadPoolExecutor

client_openai = OpenAI()
client_claude = anthropic.Anthropic()

def propose_openai(question: str) -> str:
    response = client_openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": question}]
    )
    return response.choices[0].message.content

def propose_claude(question: str) -> str:
    message = client_claude.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=1024,
        messages=[{"role": "user", "content": question}]
    )
    return message.content[0].text

def aggregate(question: str, proposals: list[str]) -> str:
    proposals_text = "\n\n".join(
        f"Yanıt {i+1}:\n{p}" for i, p in enumerate(proposals)
    )
    system_prompt = (
        "Sen bir sentezleyicisin. Verilen yanıtları değerlendir, "
        "doğru ve tamamlayıcı bilgileri bir araya getir, "
        "tutarsızlıkları gider ve tek bir kapsamlı yanıt üret."
    )
    response = client_openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": system_prompt},
            {
                "role": "user",
                "content": f"Soru: {question}\n\n{proposals_text}"
            }
        ]
    )
    return response.choices[0].message.content

def moa_query(question: str) -> str:
    with ThreadPoolExecutor(max_workers=2) as executor:
        futures = [
            executor.submit(propose_openai, question),
            executor.submit(propose_claude, question),
        ]
        proposals = [f.result() for f in futures]
    return aggregate(question, proposals)

if __name__ == "__main__":
    soru = "Kuantum bilgisayarlar şifrelemeyi nasıl etkiler?"
    yanit = moa_query(soru)
    print(yanit)

Birkaç pratik not:

• ThreadPoolExecutor proposer’ları gerçek anlamda paralel çalıştırıyor; toplam gecikme, en yavaş proposer’ın süresiyle sınırlı.
• Aggregator’ın sistem promptu kalite açısından belirleyici. “Tüm yanıtları birleştir” yerine “doğru parçaları seç, hatalı parçaları at” yönlendirmesi çok daha iyi sonuç veriyor.
• Üretim ortamında her proposer’ı ayrı try/except bloğuna almak gerekiyor; tek bir API hatası tüm pipeline’ı düşürmemeli.

Üretimde MoA: dikkat edilmesi gerekenler

Yukarıdaki minimal örnek temel çalışma prensibini gösteriyor; üretim ortamında birkaç ek konfigürasyon zorunlu hale geliyor.

Timeout ve fallback yönetimi. Her proposer çağrısını bir timeout ile sınırlandırın. ThreadPoolExecutor ile future.result(timeout=30) kullanabilirsiniz. Bir proposer zaman aşımına uğrarsa, tamamlanan yanıtlarla aggregator’ı yine de besleyin. Sıfır proposer yanıtı gelme ihtimalinde aggregator’ı soruyla doğrudan çalıştırmak kabul edilebilir bir son çare olarak bırakın.

Yanıt önbellekleme. Tekrar eden sorgular içeren destek veya SSS akışlarında proposer yanıtlarını semantik benzerliğe göre önbellekleyebilirsiniz. Redis ve pgvector bu amaçla sık kullanılan seçenekler. Özellikle maliyeti yüksek modellerin proposer olarak kullanıldığı sistemlerde bu adım toplam token giderini kayda değer ölçüde azaltıyor.

Aggregator prompt tasarımı. Proposer yanıtlarını aggregator’a gönderirken “Yanıt 1, 2, 3” gibi anonim etiketler yerine modelin adını belirtin: “GPT-4o yanıtı:”, “Claude yanıtı:”. Deneysel bulgular bu formatın aggregator’ın model güçlü yanlarına göre seçici sentez yapmasını kolaylaştırdığını gösteriyor. Kod bölümlerinde GPT-4o çıktısına, açıklama gerektiren kısımlarda Claude çıktısına daha fazla ağırlık verilebiliyor.

Model rotasyonu. Bir API sağlayıcısı kesinti yaşadığında MoA’nın çok-model yapısı doğal bir yedeklilik sunuyor. Proposer listesini dinamik tutarsanız çalışan modellere otomatik yönlendirme yapabilirsiniz; bu tekil model bağımlılığının getirdiği kırılganlığı azaltıyor.

İzleme ve kalite değerlendirmesi. Her MoA çağrısında proposer yanıtlarını ve aggregator çıktısını kaydedin. Zamanla hangi proposer’ın hangi görev kategorisinde daha yararlı katkı yaptığını görebilirsiniz. Yapılandırılmış çıktılar kullanarak proposer yanıtlarını güven skoru içeren JSON formatında topladığınızda aggregator tutarlılığı artıyor; bu LLM-as-judge pratiğiyle örtüşen bir değerlendirme döngüsü oluşturuyor.

Çok katmanlı MoA. Layer 1 proposer yanıtları, Layer 2 proposer’larına bağlam olarak aktarılabilir. Bu yapıda her katman bir öncekinin çıktısını rafine eder. Araştırma özetleme ya da uzun analiz görevlerinde iki katmanlı MoA, akıl yürüten modellerin ardışık düşünme adımlarına benzer bir kalite artışı getiriyor. Ancak her katman ek gecikme ve maliyet demek; iki katman çoğu üretim senaryosu için yeterli denge noktasını temsil ediyor.

Tek LLM, MoA ve MoE: ne zaman ne?

MoA en çok hangi görevlerde fark yaratıyor? Yanıtın birden fazla bakış açısından yararlandığı, hata marjının maliyetli olduğu veya herhangi bir modelin tek başına emin olamayacağı senaryolar.

Kullanım senaryoları

Hukuki ve tıbbi metin analizi. Bir hasta vakası veya sözleşme maddesi, farklı eğitim dağılımlarına sahip birden fazla modele soruluyor. Her proposer farklı bir risk veya nüansı yakalayabiliyor; aggregator sentezi hem kapsam hem de doğruluk açısından tek modelden daha sağlam çıkıyor.

Kod incelemesi. Güvenlik açığı tarama, performans analizi ve okunabilirlik değerlendirmesi üç farklı proposer’a atanıyor; her biri kendi uzmanlık alanına odaklanıyor. Bu yaklaşım prompt mühendisliği tekniklerinden biri olan role prompting ile birleşince her proposer daha odaklı çalışıyor.

Araştırma özetleme. Uzun akademik dokümanlar paralel proposer’lara bölünüyor; her proposer farklı bir bölümü işleyip anahtar bulguları çıkarıyor. Aggregator bu bulguları tutarlı bir özete dönüştürüyor. Burada MoA uzun bağlam modellerinin tek başına yetersiz kaldığı durumlarda alternatif bir bölüt-ve-birleştir stratejisi sunuyor.

Yüksek güvenilirlik gerektiren soru-cevap. Müşteri desteği, finansal danışmanlık veya teknik destek gibi alanlarda tek model başarısızlığına karşı dayanıklılık önem taşıyor. MoA, bir modelin hatalı yanıt üretme olasılığını düşürüyor.

Sınırlar ve maliyetler

MoA’yı her senaryo için önermek yanlış olur.

Token ve gecikme. Üç proposer ve bir aggregator, tek LLM çağrısına kıyasla 4-6 kat daha fazla token harcıyor. Proposer’lar paralel çalışsa bile toplam gecikme, en yavaş proposer artı aggregator süresi kadar. Gerçek zamanlı kullanıcı etkileşimi gerektiren uygulamalarda bu gecikme kabul edilebilir olmayabilir.

Aggregator kalitesi belirleyici. Proposer yanıtları ne kadar güçlü olursa olsun, aggregator zayıfsa sonuç kötüleşebilir. “MoA kalitesi aggregator kalitesiyle sınırlı” kuralı pratikte doğrulanmış.

Basit sorularda marjinal kazanım. “Türkiye’nin başkenti nedir?” türünden net yanıtlı sorularda ensemble etkisi neredeyse sıfır. MoA’nın kalite artışı görev karmaşıklığı ve belirsizliği arttıkça belirginleşiyor; basit fact retrieval görevlerinde maliyet fayda karşılaştırması genellikle tek LLM lehine.

Tutarsız proposer yanıtları aggregator’ı zorluyor. Özellikle üç proposer birbirinden çok farklı yanıtlar verdiğinde, aggregator hangi bilginin doğru olduğuna karar verirken hata yapabiliyor. Bu durumu hafifletmek için her proposer yanıtına güven skoru eklemek veya aggregator’a kaynak bazlı değerlendirme yapması için yapılandırılmış bir format vermek işe yarıyor.

MoA’yı doğru yerleştirmek

MoA, tek bir modelin sınırlarını aşmanın pratik bir yolu. RLHF veya fine-tuning gerektirmeden, mevcut modelleri yeniden eğitmeden, yalnızca orkestrasyon katmanı değiştirilerek kalite artışı elde ediliyor. Bu esneklik onu araştırma laboratuvarlarında olduğu kadar üretim sistemlerinde de geçerli bir seçenek yapıyor.

Üretimde MoA’yı değerlendirirken iki pratik filtre işe yarıyor: görevin hata maliyeti yüksek olmalı, kullanılan modeller arasında gerçek çeşitlilik bulunmalı. Bu iki koşul sağlandığında MoA denenmeye değer. Latency kısıtı varsa proposer sayısını düşürün veya daha hızlı modeller kullanın; bütçe kısıtı varsa tek güçlü bir model muhtemelen daha iyi bir tercih. MoA’yı başarılı kılan şey mimari karmaşıklık değil; doğru görev seçimi ve modeller arası çeşitlilik. Bu iki değişkeni doğru kurduğunuzda orkestrasyon katmanı kendini amorti ediyor.