Model Routing: Hangi Soruyu Hangi Modele Gönderiyorsun? E-Ticarette Maliyet ve Hız Denklemi
Basit Görünen Ama Gerçekte Zor Olan Karar
Hugging Face blogunda 15 Temmuz 2026'da yayımlanan "Model Routing Is Simple. Until It Isn't." başlıklı yazı, sahada AI kullanan firmaların en çok altını çizdiği soruya dokunuyor: Her görevi aynı modele mi yönlendirelim?
Yüzeysel cevap "hayır" ama pratikte neredeyse herkes hâlâ böyle yapıyor. Shopify mağazası işleten, Meta/Google Ads yöneten ya da müşteri desteğini kısmen otomatize etmiş bir e-ticaret firması için bu ayrım ciddi maliyet ve performans farkı yaratıyor.
Model Routing Nedir, Neden Önemlidir?
Model routing, gelen bir görevi —metin yazma, sınıflandırma, müşteri sorusu yanıtlama, ürün açıklaması oluşturma, reklam kopyası üretme— otomatik olarak en uygun (yani en hızlı + en ucuz + kalite eşiğini geçen) modele yönlendirme kararıdır.
Sorun şu: "En uygun model" statik değil. Görevin zorluğuna, bağlam uzunluğuna, gereken doğruluk eşiğine ve tolere edilebilir gecikmeye göre değişiyor.
Hugging Face yazısının özetlediği çekirdek gerilim şu: Basit bir yönlendirici kurmak kolay. Ama gerçek dünyada görev dağılımı düzgün değil — yüklerin %20'si toplam karmaşıklığın %80'ini oluşturuyor ve statik kurallar burada çöküyor.
E-Ticaret Firması İçin Somut Tablo
Bir e-ticaret operasyonunda şu görev türleri vardır:
- Düşük karmaşıklık / yüksek hacim: Ürün başlığı formatlaması, etiket normalizasyonu, SSS kısa yanıtları, sipariş durumu bildirimleri
- Orta karmaşıklık: Ürün açıklaması yazma, e-posta kişiselleştirme, basit reklam kopyası
- Yüksek karmaşıklık / düşük hacim: Strateji önerileri, çok adımlı müşteri şikayeti çözümü, ROAS analiz yorumu, dinamik teklif mantığı açıklaması
Birinci gruptaki her görevi Claude Opus ya da Gemini 1.5 Pro gibi büyük, pahalı modele göndermek hem gereksiz hem zararlı. Token başına maliyet farkı büyük modeller ile küçük/hızlı modeller (Haiku, Flash, küçük açık ağırlıklı modeller) arasında 10-40 kat arasında değişebiliyor.
Firmalar Nerede Hata Yapıyor?
1. Tek model, tüm görevler: API entegrasyonunu tek seferde kurup en yüksek kapasiteli modeli her şeye bağlamak. Başlangıçta çalışıyor, maliyet faturası gelince şaşırıyorlar.
2. Kural tabanlı routing ve sabit eşikler: "100 token altıysa küçük model gönder" gibi basit kurallar, görevin gerçek zorluğunu ölçmüyor. Kısa ama kritik bir soru yanlış yönlendirilebiliyor.
3. Routing kararını log'lamama: Hangi görev hangi modele gitti, kalite nasıldı, latency ne oldu — bu veri olmadan sistemi optimize etmek mümkün değil.
Firma Ne Yapmalı?
Adım 1 — Görev envanteri çıkar: Mevcut AI kullanım senaryolarını karmaşıklık × hacim matrisine yerleştir. Hangi görev tipi ne kadar sıklıkla geliyor?
Adım 2 — Kalite eşiği belirle: Her görev tipi için "yeterince iyi" ne demek? Ürün başlığı formatlamasında %98 doğruluk yeterliyken müşteri şikayeti çözümünde insan incelemesi gerekebilir.
Adım 3 — Küçük modeli test et önce: Varsayılan olarak küçük/hızlı modeli kullan, kalite eşiğini geçemediğinde büyük modele eskalasyon yap (cascade routing). Bu yaklaşım hem maliyet hem gecikme açısından avantajlı.
Adım 4 — Routing kararlarını izle: Her API çağrısında model adı, token sayısı, görev tipi ve (mümkünse) çıktı kalite skoru loglan. Aylık bazda routing dağılımını gözden geçir.
Neden Şimdi?
Claude Sonnet 5, Gemini 2.5 Flash, açık ağırlıklı modellerin yeni nesli — tüm bu gelişmeler kapasiteyi artırırken fiyat farklarını da koruyarak büyütüyor. 2026'da "büyük model = güvenli tercih" mantığı hem yanlış hem pahalı. Model routing, AI maliyetini kontrol altına almanın altyapısal temelidir ve e-ticaret operasyonlarında bu tartışma artık ertelenemiyor.