Çoğu yapay zeka ajanı her şey için tek bir model kullanır. Planlama adımı, araç çağrıları, özetleme, hata kurtarma. Bu, demolar için işe yarar. Üretim aşamasında ise israftır.
Derin muhakeme gerektiren bir planlama adımı, bir JSON çıkarma adımı ile aynı modele ihtiyaç duymaz. Bir kod oluşturma görevinin gereksinimleri, bir sınıflandırma görevinden farklıdır. Bir tarih dizisini formatlamak için Claude Opus 4.6 ($25/1M output tokens) kullanmak, bir duvarı boyamak için kıdemli bir mimar tutmaya benzer.
İşte her adımı en uygun modele yönlendiren ajanların nasıl inşa edileceğine dair bir rehber.
Ajan katmanından ziyade API katmanı üzerinde çalışıyorsanız, bu sayfayla birlikte Ajan Öncelikli API Tasarımı ve Ekipler Neden Doğrudan Model API'lerinden Birleşik bir Yapay Zeka API'sine Geçiyor yazılarını okuyun. Çoklu modelli ajanlar, alttaki API yüzeyi orkestrasyon kodunu yeniden yazmadan modelleri değiştirecek kadar kararlı olduğunda en iyi şekilde çalışır.
Çoklu Modelli Ajan Mimarisi
Kullanıcı İsteği
│
▼
┌─────────────┐
│ Yönlendirici │ ← Görev karmaşıklığını sınıflandırır
│ (hızlı model)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│Basit │ │Karmaşık│
│Model │ │Model │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ Birleştirici │ ← Sonuçları birleştirir
│ (hızlı model)│
└─────────────┘
Üç bileşen:
- Gelen görevleri karmaşıklığa göre sınıflandıran bir yönlendirici (router)
- Farklı görev türleriyle eşleştirilmiş bir model havuzu
- Gerektiğinde sonuçları birleştiren bir birleştirici (aggregator)
Pratikte, üretimdeki ajanlar genellikle iki parçaya daha ihtiyaç duyar:
- Tercih edilen model başarısız olduğunda veya yavaşladığında bir yedekleme (fallback) politikası
- Adım başına model seçimini, gecikmeyi ve maliyeti kaydeden bir telemetri katmanı
Bu ikisi olmadan, çoklu modelli bir ajan hızla öngörülemeyen davranışlara sahip bir kara kutuya dönüşür.
OpenAI SDK ile Uygulama
Bir birleştirici aracılığıyla tek bir API anahtarı kullanarak, birden fazla SDK'yı yönetmeden tüm modellere erişebilirsiniz:
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Model pool with cost/capability tiers
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - fast classification
"simple": "gpt-4.1-mini", # $0.40/1M in - extraction, formatting
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - planning, analysis
"complex": "gpt-4.1", # $2.00/1M in - code gen, multi-step
"budget": "deepseek-chat", # $0.28/1M in - bulk processing
}
def route_task(task: str) -> str:
"""Use a cheap model to classify task complexity."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Classify this task into one category:
- simple: data extraction, formatting, translation
- reasoning: analysis, planning, comparison
- complex: code generation, multi-step problem solving
- budget: bulk processing, non-critical tasks
Reply with just the category name."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""Route task to appropriate model and execute."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
Gerçek Dünya Ajanı: Kod İnceleme İş Akışı
İşte pull request'leri inceleyen pratik bir çoklu modelli ajan örneği:
def review_pr(diff: str) -> dict:
"""Multi-model PR review pipeline."""
# Step 1: Classify changes (cheap model)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Classify these code changes: {diff[:2000]}\n"
"Categories: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# Step 2: Security scan (reasoning model)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "You are a security reviewer. Check for: "
"SQL injection, XSS, auth bypass, secrets in code, "
"unsafe deserialization. Be specific about line numbers."
}, {
"role": "user",
"content": f"Review this diff for security issues:\n{diff}"
}]
).choices[0].message.content
# Step 3: Code quality (general model)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Review code quality: naming, structure, "
f"error handling, test coverage.\n{diff}"
}]
).choices[0].message.content
# Step 4: Summary (cheap model)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Summarize this PR review in 3 bullet points:\n"
f"Type: {classification}\n"
f"Security: {security[:500]}\n"
f"Quality: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
Tipik bir PR incelemesi için maliyet dökümü (2K token diff):
| Adım | Model | Giriş Token'ları | Maliyet |
|---|---|---|---|
| Sınıflandırma | GPT-4.1-mini | ~2,100 | $0.0008 |
| Güvenlik | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| Kalite | GPT-4.1 | ~2,500 | $0.0050 |
| Özet | GPT-4.1-mini | ~1,200 | $0.0005 |
| Toplam | ~$0.014 |
Dört adımın tamamı için Claude Sonnet 4.6 kullanmak ~$0.028 tutacaktır. Çoklu modelli yaklaşım, en güçlü modeli en önemli yerde (güvenlik incelemesi) kullanarak maliyetleri %50 oranında azaltır.
Sadece Fiyata Göre Değil, Yeteneğe Göre Yönlendirme
Birçok ekip çoklu modelli yönlendirmeye basit bir kuralla başlar: pahalı görevler pahalı modellere, ucuz görevler ucuz modellere gider.
Bu iyi bir ilk adımdır ancak yeterli değildir.
Daha güçlü bir yönlendirme politikası dört boyuta bakar:
- muhakeme derinliği
- bağlam uzunluğu
- araç kullanım güvenilirliği
- gecikme hassasiyeti
Bu da daha iyi kurallara yol açar:
- planlama ve ayrıştırma işlemleri muhakeme yeteneği yüksek bir modele gider
- veri çıkarma ve formatlama işlemleri ucuz ve hızlı bir modele gider
- kod incelemesi, en iyi hata bulma davranışına sahip modele gider
- depo genelindeki analizler, en büyük bağlam penceresine sahip modele gider
Bu, kodlama modeli karşılaştırması ve fiyat karşılaştırması gibi kaynakların ayrı bir araştırma klasöründe durmak yerine yönlendiricinizi bilgilendirmesi gerektiğinin nedenidir.
LangChain Entegrasyonu
from langchain_openai import ChatOpenAI
# Create model instances with different configs
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Use in LangChain chains
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
Ne Zaman Çoklu Modelli Ajan Kullanılmalı?
Çoklu modelli yönlendirme karmaşıklık katar. Şu durumlarda buna değer:
- Ajanınız çeşitli görev türlerini yönetiyorsa (sadece sohbet değil)
- Aylık API maliyetleri 100 doları aşıyorsa (tasarruf anlamlı hale gelir)
- Belirli model güçlerine ihtiyacınız varsa (kod için Claude, uzun bağlam için Gemini, hız için GPT)
- Gecikme bazı adımlar için önemliyken diğerleri için değilse
Basit sohbet robotları veya tek amaçlı ajanlar için tek bir model yeterlidir. Her isteğin aynı yeteneğe ihtiyaç duyduğu durumlarda yönlendirme maliyeti haklı çıkarılamaz.
Kırılma noktası genellikle şunlardan biridir:
- Düşük değerli görevler için üst düzey muhakeme ücreti ödüyorsanız
- Bir sağlayıcının kesintileri artık gerçek bir iş riski haline geldiyse
- Bağlam ihtiyaçları iş akışı boyunca büyük ölçüde değişiyorsa
- Pahalı bir çekirdek aşamanın etrafında daha ucuz inceleme / çıkarma / özetleme aşamalarına ihtiyacınız varsa
Bunların hiçbiri geçerli değilse, tek bir model hala doğru cevaptır.
Yaygın Hata Türleri
Çoklu modelli sistemler öngörülebilir şekillerde başarısız olur:
1. Yönlendiricinin çok "akıllı" olması
Yönlendirici istemi devasa bir taksonomi egzersizine dönüşürse, ne yapacağınıza karar vermek için çok fazla harcama yaparsınız. Yönlendiriciyi ucuz ve kaba tutun.
2. Çıktı sözleşmelerinin sapması
Bir model temiz JSON döndürürken, diğeri JSON bloğu içeren bir metin döndürür ve alt akıştaki ayrıştırıcınız bozulur. Her aktarımda açık şemalar ve doğrulama kullanın.
3. Yedeklemenin kaliteyi sessizce değiştirmesi
Sağlayıcı baskısı sırasında daha ucuz bir modele yönlendirme yapmak, kullanıcı tamamen farklı bir kalite profili görürse ajanın tutarsız görünmesine neden olabilir. Bu nedenle hız sınırlama stratejisi sonradan akla gelen bir düşünce değil, tasarımın bir parçası olmalıdır.
4. Maliyet raporlamasının eksikliği
Adım başına model seçimini, maliyeti ve gecikmeyi kaydetmezseniz, çoklu modelli tasarımın gerçekten para kazandırıp kazandırmadığını anlayamazsınız.
Minimal Bir Değerlendirme Döngüsü
Çoklu modelli bir ajanı sorumlu bir şekilde çalıştırmak için devasa bir değerlendirme platformuna ihtiyacınız yoktur.
Çalıştırma başına bir tablo veya veritabanı kaydıyla başlayın:
- kullanıcı görev kategorisi
- yönlendirici kararı
- adım başına kullanılan nihai model
- adım başına gecikme
- toplam token maliyeti
- yedeklemenin tetiklenip tetiklenmediği
- kullanıcının cevabı kabul edip etmediği
Bu, önemli soruları yanıtlamak için yeterli sinyali sağlar:
- Yönlendirici doğru pahalı modeli yeterince sık seçiyor mu?
- Hangi adım bütçenin çoğunu tüketiyor?
- Yedeklemeler süreci kurtarıyor mu yoksa sadece istikrarsızlığı mı gizliyor?
- Ucuz yol, tekrarlayan görevler için yeterince iyi mi?
Birleşik bir ağ geçidinin (gateway) yardımcı olmasının nedeni de budur. Model kullanımı birçok sağlayıcıya yayıldığında, karşılaştırılabilir bir çalışma günlüğü oluşturmak zorlaşır. Her şey tek bir API katmanından geçtiğinde, izleme yükü azalır.
Mimariyi Sade Tutun
En iyi çoklu modelli ajanlar egzotik hissettirmez. Operasyonel olarak sade hissettirirler.
Bu şu anlama gelir:
- orkestrasyon katmanınıza giren tek bir kararlı istek yapısı
- yönlendirme kurallarını tanımlamak için tek bir yer
- maliyet ve gecikmeyi incelemek için tek bir yer
- görev ailesi başına tek bir yedekleme politikası
- model izin listeleri için tek bir doğruluk kaynağı
Ajan grafiğiniz zekice görünüyor ancak operatörleriniz bir isteğin neden bir model yerine diğerine gittiğini açıklayamıyorsa, tasarım henüz bitmemiş demektir.
Çoklu Modelli Ajan Ne Zaman Kullanılmamalı?
Daha basit tasarımın kazandığı açık durumlar da vardır.
Sırf model kataloğu geniş diye yönlendirme eklemeyin.
Şu durumlarda tek bir modele sadık kalın:
- ürün tekrarlı olarak tek bir dar görevi yapıyorsa
- modeller arasındaki kalite farkları kullanıcı için önemsizse
- trafiğiniz maliyet optimizasyonunun önemli olmayacağı kadar düşükse
- operasyonel izleme altyapınız henüz yetersizse
- yönlendirmenin yardımcı olup olmadığını anlayacak kadar güçlü değerlendirmeleriniz (evals) yoksa
İyi seçilmiş, iyi yeniden deneme mekanizmalarına, istem hijyenine ve gözlemlenebilirliğe sahip tek bir model; kimsenin güvenmediği gösterişli bir çoklu modelli grafiği genellikle geride bırakır.
Doğru soru "yönlendirme yapabilir miyiz?" değil, "yönlendirme bu iş akışı için daha iyi kalite, daha düşük maliyet veya daha güvenli hata davranışı sağlıyor mu?" sorusudur.
Cevap belirsizse, iş akışının kendisi daha çeşitli hale gelene kadar mimariyi basit tutun.
Önemli Çıkarımlar
- Her adımı iyi yöneten en ucuz modeli kullanın
- Pahalı modelleri gerçekten ihtiyaç duyan görevler için saklayın
- Sınıflandırma/yönlendirme adımları her zaman mevcut en ucuz modeli kullanmalıdır
- Sadece token başına fiyatlandırmayı değil, ajan çalışması başına gerçek maliyeti ölçün
- Tek anahtarlı bir API birleştirici, çoklu modele erişimi önemli ölçüde basitleştirir
Çoklu modelli ajanlar doğası gereği daha iyi değildir. İş akışı gerçekten farklı türde işler içerdiğinde daha iyidirler.
Her modele tek bir API üzerinden erişin: LemonData, tek bir API anahtarı ile 300'den fazla model sunar. Birden fazla sağlayıcı hesabını yönetmeden veya her sağlayıcı çifti için yönlendirmeyi yeniden icat etmeden çoklu modelli ajanlar inşa edin.