GOGOGOLLC
Blog'a dönAjansal AI kılavuzunun parçası
ComparisonMay 18, 202610 min read

Çoklu-ajan ve RAG: hangisi ne zaman kazanır.

RAG bir retrieval kalıbı. Çoklu-ajan bir orchestration kalıbı. Farklı problemleri çözerler ve yanlış olanı seçen ekiplerin çoğu bir yıl içinde sistemi yeniden yazıyor. İşte kullandığımız karar ağacı — ve geriye dönüp baktığınızda yanlış seçtiğinizi gösteren hata modları.

Atakan Özalan

Atakan Özalan

Kurucu ortak & mühendislik lideri, GOGOGO LLC

Çoklu-ajan ve RAG: hangisi ne zaman kazanır.

2026'da konuştuğum mühendislik ekiplerinin yarısı aynı soruyu soruyor: 'RAG mı yapalım çoklu-ajan mı?' Yanlış soru. RAG bir retrieval kalıbı — modele taze bağlam vermenin yolu. Çoklu-ajan bir orchestration kalıbı — birden çok uzmanlaşmış modelin nasıl iş birliği yapacağı. Ortogonaller. Tek ajan içinde RAG kurabilirsiniz. Sıfır retrieval ile çoklu-ajan koşturabilirsiniz. Üretimdeki yapay zekânın çoğu ikisini birden yapıyor.

Ama soru ısrarla geliyor çünkü ekipler birini birincil mimari olarak seçiyor ve o seçim gerçekten önemli. Yanlış seçerseniz, sonraki yılı yeniden yazarak geçirirsiniz. Bu yazı, GOGOGO LLC'de Goddo, GoPeople, GoVista ve GoTrack genelinde kullandığımız karar ağacı — ve geriye dönüp baktığınızda yanlış seçtiğinizi gösteren hata modları.

Her biri gerçekte ne

RAG (retrieval-augmented generation): model bir soru alır, soruyu embed edersiniz, vector store'unuzda en benzer K parçayı bulursunuz, o parçaları prompt'a tıkıştırırsınız, model cevap verir. Tek model, tek tur. Daha büyük context window veya daha iyi embedding = daha iyi RAG. İşi model yapar; retrieval yakıt.

Çoklu-ajan: görevi uzman rollere (planner, executor, critic, retriever, validator) ayrıştırırsınız ve birbirlerine tipli payload'lar devretmelerine izin verirsiniz. Bir ajanın çıktısı başka bir ajanın girdisi. Orchestrator küçük ve kural şeklinde; uzmanlar üretici. Birkaç model, birkaç tur. İşi yapı yapar; üretim son adımdır.

RAG ne zaman kazanır

  1. Tanımlı bir corpus üzerinde tek-turlu Soru&Cevap. Ürün dokümanlarınız için bir yardım botu. Sözleşmeleriniz üzerinde bir hukuki asistan. Kullanıcı bir soru sorar, model bir cevap verir, retrieve ettiğiniz corpus sınırlıdır.
  2. 1 saniyenin altında latency bütçesi. RAG tek bir model çağrısı (artı vector arama). Çoklu-ajan minimum üç (plan + execute + critic). Kullanıcıların önündeki chat hissi tepkiselliği için round-trip matematiği RAG'i zorunlu kılar.
  3. Çıktı bir paragraf, bir akış değil. Doğru cevap metin ise — bir e-posta gönderme, bir iş zamanlama, veritabanına yazma gibi yan etkili eylem dizisi değilse — RAG bunu temiz şekilde kapsar.
  4. Sorgu başına maliyet sub-cent olmalı. RAG ≈ bir model çağrısı. Çoklu-ajan ≈ N model çağrısı. Ölçekte bu faturayı domine eder.

Bu dördünün hepsine cevap evet ise, RAG kurun. Çoklu-ajan aşırılıktır ve kullanıcılar için fark edemedikleri hiçbir şey vermeden daha yavaş hissedilir.

Çoklu-ajan ne zaman kazanır

  1. Görev bir süreç, bir soru değil. "Bu gelen müşteri mesajını oluştur, sınıflandır ve İK, payroll ve IT arasında yönlendir" tek bir modelin işi değil. GoPeople'ın işi ve ayrıştırma ürünün kendisi.
  2. Görevin farklı parçaları farklı modeller gerektiriyor. Görüntü için vision, kataloğa retrieval, niyet için sınıflandırma, yanıt için üretim. RAG bunu tek prompt'a sıkıştırır; çoklu-ajan her modelin kendi işinde en iyisi olmasına izin verir.
  3. State tek bir çağrıdan uzun yaşıyor. Adım 3'te olanın adım 7'de önem taşıdığı çok-turlu akışlar. RAG, bağlam yeniden inşa edilmedikçe çağrılar arasında unutur; çoklu-ajan konuşma graph'ını birinci sınıf vatandaş olarak ele alır.
  4. Replay'e ihtiyacınız var. Üretim debug'ı başarısız bir görevi aynı girdilerle yeniden çalıştırabilmeyi gerektirir. Çoklu-ajan trace'leri bunu doğal olarak verir; RAG trace'leri sadece retrieve-edilen-parçalar-artı-cevap çiftini verir, modelin neden öyle cevapladığını yakalamaz.

Bunlardan herhangi ikisi doğruysa, çoklu-ajan kurun. Ekstra orchestration'ın maliyeti, bir şeyi debug etmek zorunda kaldığınız anda kendini öder.

Dürüst karşılaştırma tablosu

ts
// Aynı görev — perakendede pickup tespiti — her iki yolla.

// RAG yaklaşımı (tek model, bağlamsal retrieval)
const candidates = await vectorStore.search(frame.embedding, k=20);
const answer = await llm.complete({
  system: "Görüntülerden ve katalogtan ürün tanımlıyorsun.",
  context: candidates.map(c => c.metadata),
  question: `Müşteri rack ${rack.id}'ten ne aldı?`,
});
// → string cevap. Hızlı. Stateless. Replay yok.

// Çoklu-ajan yaklaşımı (uzmanlar devrediyor)
const ranked = await retrievalAgent.rank(frame);
const scored = await rerankAgent.score(ranked, ctx);
const decision = await validationAgent.confirm(scored, history);
const action = await signageAgent.swap(decision);
// → tipli eylem, her adımın input/output/karar trace'i,
//    replayable, debuggable, observable.

İkisi de işliyor. RAG versiyonu bir hafta sonunda yayına çıkar. Çoklu-ajan versiyonu bir ay alır. RAG versiyonu, yeniden üretemeyeceğiniz ilk üretim hatasında ölçeklenmeyi keser. Çoklu-ajan versiyonu, yeniden üretebilmek üzerine inşa edildi. Karar, yeniden üretilebilirliğin ilk-demoya-süreden daha önemli olup olmadığıdır.

Geriye dönüp baktığınızda yanlış seçtiğinizi gösteren üç hata modu

Hata 1: RAG kurdunuz ve destek ekibiniz sürekli 'neden öyle cevap verdi?' diye soruyor

Bir destek mühendisine hangi retrieve edilen parçaların cevaptaki hangi cümleye yol açtığını gösteremiyorsanız, RAG'iniz debug edilemez ve aylar içinde üstüne ajan-şeklinde iskele cıvatalarken bulursunuz kendinizi. O noktada, doğrudan çoklu-ajan olarak yeniden yazın. GoPeople'ın ilk versiyonunda bunu yaptık.

Hata 2: Çoklu-ajan kurdunuz ve demoyu RAG rakibinizden 4× daha yavaş

Çoklu-ajanın gücü debug edilebilirlik; zayıflığı round-trip'ler. Göreviniz gerçekten tek-turluysa ve 'daha doğru hissettirdiği' için 3 ajan çağrısına sardıysanız, latency bütçenizi ihtiyacınız olmayan orchestration'a harcadınız. Güçlü retrieval'lı tek bir ajana geri çökertin.

Hata 3: RAG'i seçtiniz ve şimdi bir kararın 'neden'ini temsil edemiyorsunuz

Bankacılık, sağlık, uyum — bir sistemin yaptığını neden yaptığını savunmanız gereken her alan. RAG cevabı verir; çoklu-ajan cevaba giden yolu verir. Bir düzenleyici soracaksa, çoklu-ajan'a ihtiyacınız var.

GOGOGO'da ikisini de nasıl kullanıyoruz

Her çoklu-ajan sisteminin içinde retrieval ajanı RAG yapıyor. Retrieval ajanı birçok uzmandan biri; işi taze bağlam getirip sonraki ajana iletmek. Yani GoTrack reranker'ımız RAG (vector arama + cross-encoder), ama görsel, scoring, validation ve signage ajanları da olan bir çoklu-ajan runtime'ının içinde duruyor.

Çoklu-ajan RAG'in zıttı değil. Çoklu-ajan, retrieval sisteminizin yapması gereken birkaç şeyden biri olduğunda RAG'in içinde koştuğu konteyner. Retrieval tek şey ise — yalnız RAG. Retrieval birçokundan biriyse — çoklu-ajan, içindeki bir uzman olarak RAG.

Karar ağacı, özet

  • Tek-turlu, latency-bağımlı, metin-çıktı, sub-cent maliyet → RAG.
  • Çok-adımlı süreç, birden çok model türü, stateful, replay gerektiriyor → Çoklu-ajan.
  • Emin değil → çoklu-ajan kabuğunun içinde RAG ile başlayın. Kabuk ucuzdur; sonra yeniden yazmak değil.

RAG yakıt. Çoklu-ajan motor. Soru 'hangisi' değil — 'yakıt-tek-başına ne zaman cevap, ne zaman içinde yakacak bir motora ihtiyacınız var.'

GOGOGO LLC'de ikisini de kurduk ve ikisini de alet çantasında tutuyoruz. Stack'inizdeki belirli bir karar üzerine not değiş tokuş etmek istiyorsanız — Atakan, ya da dev handle isterseniz ezagor.

Bunu işin için ister misin?

Önce hangi iş akışını kuracağını anlat. Sana 4 fazlı bir plan ve uygun ajanlarla geri döneriz.