Hangi Yapay Zeka Modelini Seçmelisin? Küçük-Hızlı mı Büyük-Akıllı mı, Hangi İş İçin Hangisi

Bir özelliğe yapay zeka eklemeye karar verdin, API dokümanını açtın ve karşına bir liste çıktı: GPT-5, GPT-5-mini, Claude Sonnet, Claude Haiku, Gemini Pro, Gemini Flash... Hangi yapay zeka modelini seçmelisin? Çoğu geliştirici bu soruyu yanlış soruyor. 'En iyi model hangisi' diye sormak yerine 'bu iş için hangisi yeterli' diye sormak lazım, çünkü doğru cevap neredeyse hiçbir zaman tek bir model değil — işe göre değişen bir seçim.

##Hangi Yapay Zeka Modelini Seçmelisin? Küçük-Hızlı ile Büyük-Akıllı Arasındaki Fark Aslında Ne?

Model ailelerinin çoğu artık aynı 'akıl' seviyesinden birkaç boy satıyor: bir 'mini' veya 'flash' sürüm, bir orta seviye, bir de en üst düzey 'akıllı' sürüm. Aradaki fark ham parametre sayısından çok, modelin ne kadar 'düşünmeye' zorlandığı ve ne kadar geniş bir örnekle eğitildiği. Küçük modeller, dar ve tekrarlayan görevlerde büyük modellere şaşırtıcı derecede yakın sonuç verecek şekilde damıtılmış (distilled) modellerdir; hız ve maliyet için tasarlanmışlardır. Büyük modeller ise çok adımlı akıl yürütme, belirsizliği tolere etme ve az örnekle genelleme yapma konusunda daha güçlüdür — ama bu gücün bir bedeli var.

Üç eksende fark ediyorlar: maliyet, hız ve yetenek. Deneyimlerime göre küçük-hızlı modeller genelde 1 milyon girdi tokenı için 0,15–0,40 dolar aralığında fiyatlanıyor ve 200-600 milisaniyede yanıt dönüyor; büyük-akıllı modeller ise aynı token miktarı için 2–15 dolar arasına çıkabiliyor ve karmaşık görevlerde yanıt süresi 1-4 saniyeye kadar uzayabiliyor. Bu, on kat maliyet farkı ve genelde üç-beş kat gecikme farkı demek — küçük ölçekte önemsiz görünse de, ayda milyonlarca istek işleyen bir sistemde bu fark aylık faturayı doğrudan belirliyor.

'Madem büyük model daha akıllı, neden her zaman onu kullanmıyoruz?' sorusu haklı bir itiraz. Cevap sadece maliyet değil. Büyük modellerin rate limit'leri (dakikada işlenebilecek istek sayısı) genelde küçük modellerden daha kısıtlı olduğu için, yüksek trafikli bir uygulamada darboğaz yaratabiliyorlar. Ayrıca bazı küçük modeller açık kaynak olarak sunuluyor ve kendi sunucunda çalıştırabiliyorsun — bu da hassas veriyi hiç dışarı çıkarmadan işlemek isteyen sağlık, hukuk veya finans uygulamaları için önemli bir avantaj. Kısacası büyük model her zaman 'daha iyi' değil, sadece belli eksenlerde daha güçlü; küçük model de bir 'ucuz alternatif' değil, kendi başına doğru araç olabiliyor.

##Küçük-Hızlı Model Ne Zaman Yeterli?

Görev ne kadar dar tanımlı ve tekrarlıysa, küçük model o kadar iyi çalışıyor. Pratikte şu işlerde küçük-hızlı modeller büyük modelle neredeyse aynı kaliteyi, çok daha ucuza ve hızlı veriyor:

• ▸Sınıflandırma / etiketleme — bir metnin hangi kategoriye, hangi duyguya, hangi önceliğe ait olduğunu belirlemek
• ▸Basit veri çıkarma (extraction) — bir e-postadan tarih, tutar, sipariş numarası gibi sabit alanları çekmek
• ▸Kısa özetleme — bir yorumu veya kısa bir metni 1-2 cümleye indirmek
• ▸Yönlendirme (routing) katmanı — kullanıcı mesajını hangi akışa, hangi ekibe, hangi büyük modele gönderileceğine karar vermek
• ▸İçerik moderasyonu ve filtreleme — spam, uygunsuz içerik veya basit kural ihlallerini yakalamak
• ▸Sabit bir bilgi tabanından basit soru-cevap — SSS tarzı, tek adımlı sorular

Bu görevlerin ortak noktası: girdi ve beklenen çıktı formatı belli, karar tek adımda veriliyor, 'yaratıcılık' veya çok adımlı planlama gerekmiyor. Böyle bir işte büyük modeli kullanmak, bir zarfı taşımak için kamyon kiralamak gibi — çalışır ama gereksiz yere pahalı ve yavaştır.

##Büyük-Akıllı Model Ne Zaman Şart?

Bazı işler küçük modelde sessizce bozuluyor — hata vermiyor, sadece yanlış veya sığ cevap veriyor, ve bunu fark etmek zor oluyor. Büyük modelin gerçekten fark yarattığı durumlar şunlar:

• ▸Çok adımlı planlama ve 'agent' akışları — bir hedefe ulaşmak için ara adımları kendi kurgulaması gereken görevler
• ▸Belirsiz veya eksik tanımlı talimatlar — kullanıcının tam ne istediğini metinden çıkarmak gereken durumlar
• ▸Kod üretme ve hata ayıklama — özellikle birden fazla dosya/bağlamı aynı anda tutması gereken işler
• ▸Hukuki, finansal veya tıbbi metin analizi — nüansın ve bağlamın önemli olduğu, hata payının düşük olduğu alanlar
• ▸Uzun ve dağınık bağlamı sentezleme — RAG ile gelen birden fazla kaynağı tutarlı, çelişkisiz bir cevaba dönüştürmek
• ▸Yaratıcı yazım ve marka sesini koruyan içerik — kalıp cümlelerin hemen fark edildiği işler

Buradaki ortak nokta, görevin doğru cevabının önceden net olmaması ve modelin kendi başına akıl yürütmesi gerekmesi. Bu tür işlerde küçük modeli kullanmak kısa vadede ucuz görünür ama üretilen hatalı çıktıları düzeltmek için harcanan insan zamanı, kazanılan model maliyetinden fazlasını götürür.

##Gerçek Bir Senaryo: Bir Destek Bileti Sistemini Model Karışımıyla Kurmak

Orta ölçekli bir SaaS şirketi düşünelim: ayda yaklaşık 10.000 destek bileti alıyorlar. Eskiden her bilet doğrudan büyük bir modele gidiyordu — çalışıyordu ama fatura hızla büyüyordu. Kurdukları sistem şöyle işliyor: bilet geldiği anda küçük-hızlı bir model, konuyu (faturalama, teknik sorun, iptal talebi, genel soru) ve aciliyeti sınıflandırıyor; bu adım 300 milisaniyeden kısa sürüyor ve pratikte tokene göre neredeyse bedava sayılabilecek bir maliyette.

Sınıflandırılan biletlerin yaklaşık yüzde 70-80'i, doğrudan sabit bir bilgi tabanından cevaplanabilecek tekrarlayan sorular (şifre sıfırlama, fatura nerede, plan nasıl değiştirilir). Bunlar da yine küçük modelle, bilgi tabanından çekilen pasajlarla yanıtlanıyor ve müşteri temsilcisine hiç düşmüyor. Geriye kalan yüzde 20-30'luk dilim — öfkeli müşteri, birden fazla sistemi ilgilendiren teknik arıza, iade/iptal gibi karar gerektiren durumlar — otomatik olarak büyük-akıllı modele veya doğrudan insana yönlendiriliyor. Büyük model burada hem bağlamı (müşterinin geçmiş biletleri, plan bilgisi) hem de duygusal tonu dikkate alarak taslak bir cevap hazırlıyor, temsilci onaylayıp gönderiyor.

Sonuç: toplam model maliyetinin büyük kısmı ucuz küçük model tarafında kalıyor, pahalı büyük model sadece gerçekten ona ihtiyaç duyan yüzde 20-30'luk dilimde çalışıyor. Şirket, tüm biletleri tek bir büyük modelden geçirmeye kıyasla model faturasını kabaca yarıya indirdiğini, üstelik ortalama yanıt süresinin de kısaldığını gördü — çünkü basit biletler artık kuyrukta büyük modelin yavaş yanıtını beklemiyor.

##Model Karışımı (Routing) Nasıl Kurulur, Kısaca

Tek model ile başlamak her zaman yanlış değil — küçük bir ürün için gayet mantıklı. Ama trafik büyüdükçe tek modelli yaklaşım iki şekilde çatlıyor: ya fatura orantısız büyüyor (her basit istek de en pahalı modelden geçiyor), ya da kullanıcı deneyimi bozuluyor (basit bir soru bile büyük modelin yavaş yanıt süresini bekliyor). Routing kurmak, bu ikisini aynı anda çözmenin yolu.

• ▸İşini alt görevlere ayır — 'destek bileti cevaplama' tek bir iş değil; sınıflandırma, bilgi çekme ve cevap üretme ayrı adımlardır
• ▸Her adım için en ucuz modelle başla ve kaliteyi ölç — gerçekten büyük modele mi ihtiyacın var, yoksa varsayım mı bu
• ▸Küçük modelin çıktısına bir güven eşiği (confidence threshold) koy — model 'emin değilim' sinyali veriyorsa büyük modele veya insana devret
• ▸Devretme (escalation) mantığını net kurallara bağla — belirsizlik, düşük güven skoru, belirli anahtar kelimeler (iptal, iade, hukuki) otomatik yükseltme tetiklesin
• ▸Her iki katmanı da logla — hangi bilet hangi modele gitti, sonuç doğru muydu, bu veriyi haftalık gözden geçir
• ▸Maliyet/performans dengesini periyodik kontrol et — model fiyatları ve yetenekleri sık değişiyor, altı ayda bir yeniden değerlendir

##Sık Sorulan Sorular

>En ucuz ve en hızlı model her zaman yeterli mi?

Hayır. Dar tanımlı, tekrarlayan işlerde evet, ama belirsizlik veya çok adımlı akıl yürütme içeren işlerde küçük model sessizce yanlış cevap üretir — hata fırlatmaz, sadece yüzeysel veya hatalı bir sonuç döner. Bu yüzden 'yeterli mi' sorusunu görev bazında, gerçek örneklerle test ederek cevaplamak gerekir, varsayımla değil.

>Küçük model yanlış cevap verirse ne olur, bunu nasıl yakalarsın?

Üretimde bunu yakalamanın iki yolu var: modelin kendi güven sinyalini (ya da yapılandırılmış çıktıdaki tutarsızlığı) izlemek, ve örneklem bazlı insan denetimi yapmak — biletlerin küçük bir yüzdesini rastgele seçip gerçekten doğru mu cevaplanmış diye kontrol etmek. İyi kurulmuş bir sistemde düşük güvenli veya riskli görülen vakalar zaten otomatik olarak büyük modele veya insana yönlendirilir; buradaki amaç modelin 'bilmiyorum' demesini sağlamak, tahmin yürütmesini değil.

>Fine-tuning, küçük modeli büyük model kadar iyi yapar mı?

Dar bir alanda evet, genel akıl yürütmede hayır. Fine-tuning, küçük bir modeli senin spesifik veri formatına, jargonuna ve karar mantığına alıştırarak o dar görevde büyük modele çok yaklaştırabilir — hatta bazı durumlarda geçebilir. Ama modelin karşılaşmadığı, eğitim verisinde olmayan bir senaryoyla karşılaştığında büyük modelin genel akıl yürütme avantajı geri döner. Fine-tuning, 'bu işi daha iyi yap' demektir; modele yeni bir zeka eklemez.

>Küçük bir ürün için model karışımı kurmaya değer mi, yoksa gereksiz karmaşıklık mı?

Ayda birkaç bin istekten az bir hacimde, tek model ile başlamak (genelde orta seviye bir model) daha az mühendislik yükü getirir ve maliyet farkı önemsizdir — önce basit başla. Hacim büyüdükçe veya aynı işin belirgin şekilde 'kolay' ve 'zor' alt kümelere ayrıldığını fark ettiğinde (destek biletleri örneğindeki gibi), routing kurmanın getirisi mühendislik maliyetini hızla aşar. Kural olarak: aylık model faturan dört haneli rakamlara yaklaşıyorsa, routing'i ciddi ciddi değerlendirmenin vakti gelmiştir.

>Açık kaynak küçük modeller (Llama, Mistral gibi) bu işi görür mü?

Dar tanımlı görevlerde çoğu zaman evet, hatta bazı senaryolarda tercih edilir. Açık kaynak küçük modelleri kendi sunucunda çalıştırmak, veriyi hiç dışarı göndermeden işlemek isteyen (KVKK'ya tabi, hassas müşteri verisi işleyen) uygulamalar için ciddi bir avantaj. Dezavantajı, model kalitesini ve altyapıyı kendi başına yönetmen gerekmesi — API sağlayıcının otomatik güncellediği bir modeli değil, kendi barındırdığın bir sistemi bakımlı tutuyorsun. Çok yüksek hacimli, dar tanımlı bir görev ve veri gizliliği önceliğiyse, açık kaynak küçük model gerçek bir seçenek; genel amaçlı, düşük hacimli bir kullanım içinse yönetilen bir API genelde daha az baş ağrısı.

Model maliyetlerinin token bazında nasıl hesaplandığını ve bir API faturasının aslında neye göre şekillendiğini merak ediyorsan, token ekonomisini anlattığım yazıya göz atabilirsin.