Yapay Zekâ İstekleri Ne Zaman Farklı Modellere Yönlendirilmeli?

💡 Özet: Ana Çıkarımlar

• Birden fazla model kullanmak, akıllı bir yönlendirme sistemi kurmayı zorunlu kılmaz. Model seçimi dil, belge türü, risk veya veri politikası gibi açık bir kuralla yapılabiliyorsa önce o kural kullanılmalıdır.
• Model routing, sistemin içine yeni bir tahmin daha ekler. Router yanlış modeli seçtiğinde, seçilen model kendi işini düzgün yapsa bile sonuç yetersiz kalabilir.
• Bir router, en iyi tek modelden ve basit yönlendirme kurallarından daha iyi olduğunu gerçek iş yükünde göstermelidir. Tasarruf hesabına yönlendirme, değerlendirme, gecikme ve hata düzeltme maliyetleri de katılmalıdır.

İki yapay zekâ modeliniz olduğunu düşünün. Küçük model sık gelen ve kolayca sınıflandırılabilen talepleri daha ucuza işliyor. Daha güçlü model ise sözleşme istisnaları, belirsiz müşteri mesajları ve daha fazla muhakeme isteyen sorular için ayrılmış.

Burada ikinci modelin gerçekten gerekli olup olmadığını tartışmıyorum. Tek modelin ne zaman yeterli olduğunu ve ikinci modelin sisteme girmek için hangi farkı kanıtlaması gerektiğini önceki yazıda ele aldım. Bu yazı, iki modelin de ölçülebilir bir iş üstlendiği ve sistemde kalmayı hak ettiği noktadan başlıyor.

Şimdi her isteğin hangi modele gideceğine birinin karar vermesi gerekiyor.

Müşteri formda “teslimat sorunu” seçeneğini işaretlediyse karar kolay olabilir. Yazılım isteği ilgili modele gönderir. Fakat müşteri serbest metinle birkaç konuyu bir arada anlatıyorsa zorluk daha mesaj okunurken ortaya çıkar. Bu kez sistem, cevabı bilmeden hangi modelin daha iyi cevap vereceğini tahmin etmek zorundadır.

İsteği inceleyip hangi modelin kullanılması gerektiğine karar veren katmana genellikle model router, yapılan işe de model routing deniyor.

Ancak aynı terim altında birbirinden farklı kararlar bulunuyor.

Önce hangi tür yönlendirmeye ihtiyaç duyduğunuzu ayırın

Bir isteği başka bir modele göndermek her zaman “akıllı” bir karar değildir. Bazen seçim daha model çalışmadan bellidir. Bazen ilk modelin sonucunu görmek gerekir. Bazen de ikinci model yalnızca teknik hata yaşandığında devreye girer.

Bu ayrım ürünlerde de her zaman aynı biçimde kullanılmıyor. Google Cloud'un API Gateway model routing özelliği, 2026'daki ön izleme sürümünde istekte yazan model adını önceden tanımlanmış bir modele eşliyor. Sistem hangi modelin daha iyi olduğuna karar vermiyor. Belirtilen adı doğru hedefe taşıyor.

Amazon Bedrock'un akıllı yönlendirme özelliği ise isteği inceleyip iki modelden hangisinin daha iyi sonuç vereceğini tahmin ediyor. Aynı “routing” sözcüğü birinde açık bir trafik kuralını, diğerinde yeni bir tahmini anlatıyor.

Bu nedenle önce aracı değil, verilecek kararı tanımlamak gerekiyor.

Karar zaten biliniyorsa tahmin etmeyin

Bir sigorta şirketi taranmış hasar belgelerini görsel modele, çağrı merkezi konuşmalarını ses modeline gönderebilir. Kullanılacak model, gelen verinin türünden anlaşılıyorsa ayrıca bir router eğitmek gerekmez.

Benzer biçimde bazı istekler veri politikası nedeniyle yalnızca şirketin kontrol ettiği ortamda çalışabilir. Bazı işlemler ise hata maliyeti yüksek olduğu için ucuz modele hiç gönderilmemelidir. Bu sınırlar, router'ın kalite tahmininden önce uygulanır.

Sabit kural daha az gelişmiş olduğu için seçilmez. Karar açık olduğu için seçilir. Ekip hangi isteğin neden belirli bir modele gittiğini görebilir. Kural değiştiğinde neyin etkileneceğini de daha kolay sınar.

Burada modelin yeteneği ile sistemin izin verdiği seçenekleri ayırmak gerekir. Bir model hassas veriyi teknik olarak işleyebilir. Fakat verinin o sağlayıcıya veya bölgeye gönderilmesine izin verilmiyorsa router'ın onu adaylar arasına alması baştan engellenmelidir.

AWS de bölgeler arası model kullanımında, isteklerin kaynak bölgenin dışına çıkabileceğini ve bazı durumlarda kötüye kullanım denetimi için hedef bölgede saklanabileceğini açıklıyor. Yönlendirme politikası yalnızca kalite ve fiyat hesabı yapamaz. Verinin gidebileceği yer de seçimi sınırlar.

Akıllı router hangi durumda yerini hak eder?

Kuralların yetmediği yerler vardır. Aynı müşteri destek kanalına hem basit adres değişikliği talepleri hem de birden fazla sözleşme maddesini ilgilendiren anlaşmazlıklar gelebilir. İki mesaj da metindir. İkisi de aynı dilde yazılmış olabilir. Fakat gereken model kapasitesi aynı değildir.

Bu tür bir iş yükünde router, isteğin hangi modele uygun olduğunu tahmin etmeye çalışır. Küçük model kolay talepleri yeterli kalitede çözerse maliyet düşebilir. Daha zor talepler güçlü modele gönderildiğinde kalite korunabilir.

RouteLLM araştırmacıları, insan tercih verisiyle eğittikleri router'ların bazı kıyaslama testlerinde cevap kalitesini korurken maliyeti iki kattan fazla azaltabildiğini bildirmiş. Bu sonuç, routing'in işe yarayabileceğini gösteriyor. Ancak çalışma gerçek bir şirketin müşteri trafiğini, çalışanların hata düzeltme süresini veya iş sonucunu ölçmüyor.

Üstelik router'ın önünde gerçekten birbirini tamamlayan modeller bulunmalıdır. Aynı işlerde benzer biçimde davranan üç modeli bir araya getirmek, seçim yapmanın değerini artırmaz. Trafiğin önemli bir bölümü zaten güçlü modele gitmek zorundaysa router maliyeti düşürmek yerine sisteme yeni bir durak ekleyebilir.

Bu nedenle akıllı routing için en az üç koşul gerekir:

1. Modeller gerçek iş yükünün farklı bölümlerinde ölçülebilir biçimde daha iyi sonuç vermeli.
2. İş hacmi, routing'i kurma ve işletme maliyetini karşılayacak kadar yüksek olmalı.
3. Yanlış yönlendirilen isteği ve bunun iş sonucuna etkisini görebilmelisiniz.

Bu koşullardan biri eksikse tek model veya birkaç açık kural daha iyi bir başlangıç olabilir.

Daha fazla model, router'ı otomatik olarak iyileştirmez

2026'da Findings of ACL'de yayımlanan LLMRouterBench araştırması, 21 veri kümesinden 400 binden fazla örneği, 33 modeli ve 10 routing yöntemini aynı düzen içinde karşılaştırmış.

Araştırmacılar modellerin farklı görevlerde birbirini tamamlayabildiğini doğrulamış. Karşılaştırma için önce basit bir seçenek belirlemişler: Bütün istekleri, genel olarak en iyi sonucu veren tek modele göndermek. Bazı güncel yönlendirme yöntemleri ve OpenRouter adlı ticari hizmet bu seçeneği geçememiş. Maliyeti düşürmeye çalıştıklarında ise aynı kaliteyi koruyamamışlar. Model havuzu büyüdükçe kazanç azalmış. Dikkatle seçilmiş küçük bir model grubu, daha kalabalık bir havuzdan daha anlamlı olabilmiş.

Bu çalışma canlı bir müşteri destek sistemi üzerinde yapılmamış. Kıyaslama veri kümeleri kullanılmış. Yine de önemli bir sınır koyuyor: Router kullanmak, doğru modeli seçtiğiniz anlamına gelmiyor. Router'ın kendisi de kanıtlanması gereken bir model veya karar sistemi.

Hatta yönetilen bir hizmet kullanmak bu yükü tamamen ortadan kaldırmıyor. Amazon, kendi akıllı yönlendirme özelliğinin yalnızca İngilizce istekler için optimize edildiğini ve şirkete özgü performans verisine göre kararlarını uyarlayamadığını belirtiyor. Microsoft da model router değerlendirme rehberinde, router'ı doğrudan model kullanımıyla ve şirketin gerçek isteklerini temsil eden bir örnek grubuyla karşılaştırmayı öneriyor.

Yanlış rota ayrı bir hata türüdür

Router zor bir talebi küçük modele gönderirse model düzgün çalışan bir servis olabilir. Yine de iş için yetersiz bir cevap üretir. Daha kötüsü, cevap makul göründüğü için sistem teknik hata vermeyebilir.

Yedek modele geçmek bu sorunu çözmez. Yedek model genellikle ilk model hiç yanıt vermediğinde, kota sınırına takıldığında veya sağlayıcıda kesinti yaşandığında devreye girer. İlk model hızlı ama yanlış bir cevap verdiyse sistem bunu teknik hata saymaz ve yedek modele geçmez.

Kademeli geçiş bu soruna başka türlü yaklaşır. Sistem önce küçük modeli çalıştırır, ardından cevabın kabul edilip edilmeyeceğine karar verir. Yetersiz sonuç güçlü modele gönderilir. Fakat bu kez bazı istekler iki model çağrısı, iki değerlendirme ve daha uzun bekleme süresi yaratır.

Hangi yöntemi seçerseniz seçin, yalnızca her modelin başarısını ölçmek yetmez. Şunları da bilmeniz gerekir:

• Hangi istek neden o modele gitti?
• Zor bir iş kaç kez küçük modele gönderildi?
• Kolay bir iş gereksiz yere pahalı modele kaç kez çıktı?
• Yönlendirme dahil kullanılabilir sonuç başına toplam maliyet ne oldu?
• Router eklendikten sonra gecikme ve hata düzeltme süresi nasıl değişti?

Yapay zekâ sistemlerinin sonucunu nasıl ölçmek gerektiğini ele aldığım yazıda, model çıktısı ile tamamlanan işi ayırmıştım. Routing bu ölçüme yeni bir soru ekliyor: Sonuç kötüyse model mi yetersizdi, yoksa doğru iş yanlış modele mi gönderildi?

Router'ın da yerini hak etmesi gerekir

Birden fazla modeliniz olabilir ve yine de akıllı routing'e ihtiyaç duymayabilirsiniz. Görsel belgeler bir modele, sabit sınıflandırma işleri başka modele ve yüksek riskli kararlar doğrudan en güvenilir yola gidebilir. Seçim açık kurallarla yapılabiliyorsa sistem daha kolay anlaşılır ve sınanır.

Kurallar hangi isteğin hangi modele gideceğini açıkça belirleyebiliyorsa router kurmaya gerek yoktur. Kurallar yetersiz kaldığında tahmine dayalı bir router denenebilir. Fakat router'ı yalnızca bütün istekleri en pahalı modele gönderen sistemle karşılaştırmak yanıltıcı olur. Aynı istekleri üç yöntemle denemek gerekir: Genel olarak en iyi sonucu veren tek model, açık yönlendirme kuralları ve router.

İkinci modelin sisteme girmesi için bir gerekçe gerekir. O modeller arasında her istek için yeniden karar verecek bir sistem kurmak için ise ikinci bir gerekçe gerekir.

Önceki yazıda tek bir yapay zekâ modelinin ne zaman yeterli olduğunu ele aldım.

Model, bilgi, yetki ve ölçümle ilgili diğer kararları yapay zekâ sistemi tasarlama rehberinde bir arada görebilirsiniz.