Mixture of Agents (MoA) Nedir? Çok-LLM Rehberi 2026

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ığı “Mixture-of-Agents Enhances Large Language Model Capabilities” çalışması, 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 Mixtral 8x22B, Qwen 1.5 110B ve Llama 3 70B’den oluşan, yalnızca açık kaynak modellerden kurulu bir yığınla 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. Katman sayısı arttıkça kalite yükseliyor ama azalan getiri çabuk başlıyor; Together AI’nin bulgularına göre 2-3 katman genellikle yeterli, fazlası gecikme ve maliyeti artırırken kaliteye katkısı belirgin biçimde azalıyor.

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. Together AI araştırmacıları bu davranışa “collaborativeness” adını veriyor: LLM’ler başka modellerin yanıtlarını bağlam olarak aldıklarında, kendi başlarına ürettiklerinden daha bütünlüklü çıktılar oluşturuyor. Makaledeki 3 proposer + 1 aggregator kurulumu, yığındaki en güçlü tekil modeli AlpacaEval 2.0’da ortalama 5-8 puan geride bıraktı. Proposer sayısı 3’ten 5’e çıktığında kazanım sürdü ama her ek modelin katkısı azaldı; dördüncü proposer üçüncü kadar değer katmı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ığı. Madalyonun öbür yüzünde “anchoring” etkisi var: güçlü görünen bir proposer yanıtı geldiğinde aggregator onu sıfırdan reddetmek yerine temel alarak ilerliyor. Bu güvenilir bir referans noktası oluşturuyor; ama yanlış ve özgüvenli bir proposer yanıtının tüm yığını yanıltabileceği anlamına da geliyor. Riski azaltmanın en sağlam yolu mimari çeşitlilik: tüm proposer’ların aynı model olduğu kurulumda sayıyı artırmak neredeyse hiç fayda getirmiyor; çeşitlilik olmadan ensemble çalışmıyor. Proposer sistem promptlarını farklılaştırmak da (biri daha eleştirel, biri daha yaratıcı) aynı model havuzundan bile ek çeşitlilik çıkarıyor.

Üçü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. Etki matematik ağırlıklı testlerde net görünüyor: GSM8K ve MMLU gibi kıyaslamalarda MoA tabanlı sistemler, yığındaki modellerin bireysel performansını tutarlı biçimde geçiyor.

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.
• Paralel çağrılar API sağlayıcısının rate limitine takılabilir. asyncio tabanlı bir kurulumda asyncio.Semaphore ile eş zamanlı çağrı sayısını sınırlamak bu sorunu çözüyor; aynı mantık OpenAI, Anthropic veya Together API’lerinin hepsinde geçerli.

Together AI, makaleyle birlikte MoA’yı uygulayan açık kaynak bir referans kütüphane de yayımladı; hem API tabanlı hem yerel model kurulumlarını destekliyor. Sıfırdan yazmak yerine bu implementasyondan başlamak çoğu proje için daha hızlı bir yol.

Ü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.

Açık kaynak yığın ve kendi altyapınızda barındırma. Kapalı model maliyetinden kaçınmak istiyorsanız ucuz proposer’lar artı güçlü tek bir aggregator kombinasyonu üretimde yaygın bir denge noktası: proposer olarak 7B-13B arası quantized modeller, aggregator olarak 70B sınıfı bir model hem maliyet hem kalite açısından iyi bir başlangıç. Birden fazla model eş zamanlı çalışacağından verimli bir çıkarım motoru kritik; vLLM’in continuous batching özelliği bu senaryoda öne çıkıyor. Proposer başına ayrı sunucu açmak yerine tek bir çok modelli vLLM sunucusu kurmak gecikmeyi daha da düşürü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.

MoA ve LLM Router: aynı problem mi?

LLM Router ve MoA zaman zaman birbirinin alternatifi gibi gösterilse de çözdükleri problem farklı. Router, bir göreve hangi modelin en uygun olduğuna karar verip yalnızca o modele yönlendiriyor; RouteLLM ve LiteLLM bu yaklaşımın araçları. Amaç maliyet optimizasyonu: basit sorular ucuz modele, karmaşık olanlar güçlü modele gidiyor. MoA ise tek model seçmek yerine birden fazla modeli çalıştırıp sentezliyor; maliyet daha yüksek ama kalite tavanı da daha yüksek. Router “en iyi modeli bul” derken MoA “birden fazla modelin çıktısını birleştir” diyor.

İkisini birleştirmek de mümkün: rutin görevler için router ve tek model, karmaşık görevler için MoA yığını. Bu hibrit yaklaşım özellikle çok adımlı agentic sistemlerde işe yarıyor; her adımın gerektirdiği kalite seviyesine göre farklı bir strateji devreye giriyor. Ayrıntılar için LLM Router nedir? yazısına bakabilirsiniz.

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.

Context baskısı. Aggregator tüm proposer yanıtlarını bağlam olarak alıyor; her yanıt 500 token ise aggregator promptu daha başlamadan 1500+ token oluyor ve çok katmanlı bir yığında bu hızla büyüyor. İki çıkış yolu var: proposer’lara max_tokens=300 gibi kısa yanıt ürettirmek ya da aggregator için 128k+ context destekli bir model seçmek. Birincisi maliyeti de düşürüyor; ikincisi kaliteyi koruyor ama aggregator giderini artırıyor. Karmaşık teknik sorularda kısa token limiti proposer kalitesini bozabildiğinden ikisini karıştırmak mantıklı: basit görevlerde kısa limit, karmaşık görevlerde geniş context’li aggregator.

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.