Temmuz 2026 Frontier Model Manzarası: Hangi İş İçin Hangi Model

TL;DR — Temmuz 2026'da elimizde artık tek bir "en iyi model" yok; her biri belirli işlerde parlayan bir model kadrosu var. Anthropic'in Claude Sonnet 5'i (30 Haziran'da çıktı, 1 Temmuz'dan itibaren ücretsiz ve Pro kullanıcılarda varsayılan) günlük ajan işlerinin belkemiği; Google'ın Gemini 3.5 Flash'ı hız ve 1 milyon token bağlamda öne çıkıyor; OpenAI'ın GPT-5.6 ailesi (Sol, Terra, Luna) en üst uçta ama erişimi devlet yönetimli bir listeyle sınırlı; açık ağırlıklı tarafta MiniMax M3 ve Apache 2.0'a geçen Mistral modelleri, KVKK ve BDDK veri yerleşimi gerektiren sektörler için gerçek bir kurumsal seçenek oldu. Bu yazıda sahadan gözlemlerimle, "hangi iş için hangi model" sorusuna pratik bir seçim çerçevesiyle yanıt veriyorum: sohbet, kodlama, ajan iş akışları, uzun bağlam RAG ve şirket içi/açık ağırlıklı kurulum. Türkçe performans, maliyet ve gecikme boyutunu da tabloyla veriyorum.

Bir yıl önce müşterilerime "şu modeli kullanın" derken kendimi rahat hissediyordum. Bugün bu cümleyi kuramıyorum. Çünkü doğru cevap artık "ne yapmak istediğinize bağlı" ile başlıyor. Bir kurumsal AI danışmanı olarak son altı ayda sahada gördüğüm en büyük değişim bu: model seçimi tek bir karar olmaktan çıktı, bir portföy yönetimi meselesine dönüştü. Elinizde birden fazla model var, her birinin bir maliyet-hız-doğruluk üçgeninde farklı bir konumu var ve işin ustalığı, doğru işi doğru modele yönlendirmekte yatıyor.

Bu yazıyı, size Temmuz 2026 itibarıyla bu manzarayı olabildiğince sade anlatmak için yazıyorum. Amacım pazarlama slaytı değil; masaya oturduğunuzda "bu iş için hangisini seçeyim" dediğinizde işinize yarayacak bir pusula bırakmak. Rakamları yön gösterici tutuyorum, çünkü bu alanda sayılar haftadan haftaya değişiyor; ama kararların arkasındaki mantık değişmiyor.

Model manzarasına dalmadan önce, altımızdan kayan zeminin ne olduğunu görmek gerekiyor. Çünkü modellerin isimleri değişiyor ama asıl önemli olan, bu modellerin çalışma biçiminde olan üç yapısal değişim.

Birincisi, muhakeme (reasoning) modellerinin standartlaşması. Artık neredeyse her ciddi model, cevabı vermeden önce "düşünme" adımı harcayabiliyor. Bu, hızdan doğruluk lehine bilinçli bir takas. Yani bir modele karmaşık bir problem verdiğinizde, saniyeler yerine belki yarım dakika bekliyorsunuz ama karşılığında çok daha güvenilir bir sonuç alıyorsunuz. Sahada bunun anlamı şu: artık "hızlı ve ucuz" ile "yavaş ve doğru" arasında model bazında değil, aynı model içinde bir düğmeyle geçiş yapabiliyorsunuz. Bu, mimari kararlarınızı kökten değiştiriyor.

İkincisi, çok-kipliliğin (multimodality) varsayılan hâle gelmesi. Bir yıl önce "bu model görsel de anlıyor mu?" diye sormak anlamlıydı. Bugün anlamsız; ciddi her frontier model metni, görseli, ses ve çoğu zaman videoyu doğal biçimde işliyor. Bunun kurumsal karşılığı çok somut: bir sigorta hasar dosyasındaki fotoğrafları, bir üretim hattındaki kalite görüntülerini, bir çağrı merkezi ses kaydını artık ayrı ayrı sistemlere yönlendirmeden tek bir modele verebiliyorsunuz.

Üçüncüsü ve belki de en az konuşulanı, verimlilik kazanımları. Bundan bir buçuk yıl önce "GPT-4 seviyesi" performans bir lüks ve pahalıydı. Bugün aynı performansı, o günkü maliyetin çok küçük bir kesrine alıyorsunuz. Bu, sadece bütçe meselesi değil; ölçek meselesi. Eskiden pilot projede kalan fikirler, bugün maliyet düştüğü için tüm organizasyona yayılabiliyor. Ben buna "sessiz devrim" diyorum çünkü manşet olmuyor ama en çok işi bu değiştiriyor.

Bu üç değişimi akılda tutarak modellere tek tek bakalım.

Claude Sonnet 5 — Günlük İşin Yeni Belkemiği

Anthropic, Claude Sonnet 5'i 30 Haziran 2026'da duyurdu ve 1 Temmuz'dan itibaren hem ücretsiz hem Pro kullanıcılar için varsayılan model yaptı. Bu "varsayılan" kelimesinin altını çiziyorum çünkü çok şey anlatıyor: Anthropic, günlük iş yükünün büyük kısmını bu modelin taşıyabileceğine güveniyor.

Sonnet 5, "şimdiye kadarki en ajan-yetenekli Sonnet" olarak tanımlanıyor ve birçok görevde amiral gemisi Opus 4.8'e yakın performans gösteriyor. Sahadaki karşılığı şu: eskiden en ağır işleri Opus'a, gündelik işleri Sonnet'e yönlendiren bir mimariniz varsa, artık bu ayrımın çizgisi yukarı kaydı. Sonnet 5, çok adımlı ajan iş akışlarında (araç çağırma, plan yapma, hata sonrası toparlanma) belirgin biçimde olgunlaştı. Benim müşterilerimde gördüğüm pratik sonuç: Opus'a giden trafiğin bir kısmını Sonnet 5'e kaydırarak, kalitede hissedilir bir düşüş olmadan maliyeti aşağı çekebiliyorlar.

Benim önerim: eğer bir ajan sistemi kuruyorsanız, varsayılan "beyin" olarak Sonnet 5 ile başlayın ve yalnızca gerçekten zorlandığı, en karmaşık muhakeme adımlarında Opus 4.8'e yükselin.

Gemini 3.5 Flash — Hız ve Bağlamın Buluştuğu Yer

Google, Gemini 3.5 Flash'ı 19 Mayıs 2026'daki Google I/O'da tanıttı. Bu modelin iki belirgin silahı var. Birincisi, kodlama ve ajan kıyaslamalarında (benchmark) güçlü olması; "Flash" ismine rağmen artık ciddi işler yapabilen bir model. İkincisi ve daha çarpıcısı: 1 milyon token bağlam penceresi ve karşılaştırılabilir frontier modellere göre yaklaşık 4 kat daha hızlı çıkarım (inference).

Bu hız avantajını hafife almayın. Kullanıcının gerçek zamanlı beklediği senaryolarda — canlı bir chatbot, bir çağrı merkezi asistanı, kod editöründe satır satır tamamlama — gecikme (latency) doğrudan kullanıcı deneyimidir. Bir modelin cevabı 4 saniye yerine 1 saniyede vermesi, aynı işlevi teslim etse bile deneyim olarak bambaşka bir üründür. Gemini 3.5 Flash'ı ben "yüksek hacimli, hız-hassas, geniş bağlam" işlerin favorisi olarak konumluyorum.

GPT-5.6 (Sol, Terra, Luna) — Zirvede, Ama Kapıda Bir Bekçi Var

OpenAI, GPT-5.6'yı üç varyantla çıkardı: Sol, Terra ve Luna. Bu üçlü, farklı hız-yetenek noktalarını hedefliyor. Ama bu lansmanın asıl dikkat çeken yanı teknik değil, yönetişimsel: GPT-5.6, erişimi devlet yönetimli bir onay listesiyle sınırlanan ilk frontier lansmanı oldu.

Bunun ne anlama geldiğini kurumsal planlamacılar için açıkça söyleyeyim: en üst uçtaki bir modelin varlığı artık, ona erişebilme garantinizden ayrı bir mesele. Bir Türkiye merkezli kurum olarak, bir tedarik zinciri kararını, erişimin idari bir listeye bağlı olduğu bir modele dayandırmak stratejik bir risktir. Model harika olabilir; ama mimarinizi tek bir tedarikçinin — üstelik erişimi dışsal onaya bağlı bir tedarikçinin — üzerine kurmak, size sonradan pahalıya patlayabilecek bir bağımlılık yaratır. Ben müşterilerime bu tür modelleri "en zorlu, en yüksek değerli, düşük hacimli işler için ihtiyat aracı" olarak konumlamalarını, ama omurgayı bunun üzerine kurmamalarını öneriyorum.

MiniMax M3 ve Mistral — Açık Ağırlıklı Cephe Ciddiye Alınmalı

Şimdi en çok heyecanlandığım kısma geliyorum, çünkü Türkiye ve düzenlenmiş sektörler için asıl fırsat burada.

MiniMax M3, açık ağırlıklı (open-weight) tarafta frontier seviyesinde kodlama yeteneği, 1 milyon token bağlam ve doğal çok-kiplilik sunuyor. Bu üç özelliğin bir arada, üstelik ağırlıkları indirilebilir bir modelde olması, bir yıl önce hayal edilemezdi. Anlamı şu: artık en hassas verilerinizi tek bir baytını bile dışarı çıkarmadan, kendi altyapınızda frontier'a yakın bir modelle işleyebilirsiniz.

Mistral ise Large ve Small modellerini Apache 2.0 lisansına taşıdı. Apache 2.0'ın önemi hukuki: bu, ticari kullanımda son derece serbest, kurumsal hukuk departmanlarının rahatça onaylayabildiği bir lisans. Yani artık "açık model kullanalım ama lisans belirsizliği risk yaratır mı" endişesi büyük ölçüde ortadan kalktı.

Bu iki gelişmenin birleşimi, benim gözümde 2026'nın en stratejik hamlesi. Çünkü KVKK ve BDDK gibi veri yerleşimi zorunlulukları olan bir bankada, sigortada ya da kamu kurumunda, verinizi yurt dışındaki bir API'ye göndermeden, frontier'a yakın yetenek almak artık gerçekçi bir seçenek.

Burada, çoğu uluslararası karşılaştırmanın atladığı ama benim müşterilerim için birinci öncelik olan konuya geleyim: Türkçe.

Frontier modeller son bir yılda Türkçede belirgin biçimde iyileşti. Ama "iyileşti" demek "hepsi eşit" demek değil. Sahada gözlemlediğim birkaç nüans var. Büyük, muhakeme ağırlıklı modeller (Opus 4.8, GPT-5.6'nın üst varyantları, Claude Sonnet 5) Türkçe dilbilgisi, deyim ve resmî üslupta çok daha tutarlı. Hukuki metin, resmî yazışma, sözleşme özeti gibi işlerde bu fark hissediliyor.

Küçük ve hızlı modeller Türkçede genellikle "anlıyor ama üretirken zaman zaman tökezliyor" durumunda. Kullanıcıya doğrudan giden, üslubun önemli olduğu metinlerde küçük modellere körlemesine güvenmeyin; mutlaka Türkçe örnekler üzerinde test edin.

Açık ağırlıklı modellerde Türkçe performansı, modelin eğitim verisine ciddi biçimde bağlı ve varyansı yüksek. MiniMax M3 gibi güçlü açık modeller bile, Türkçe özelinde mutlaka sizin kendi kullanım senaryolarınızla test edilmeli. Benim tavsiyem hep aynı: bir modeli Türkçe için "onaylamadan" önce, kendi alan terminolojinizden 30-50 gerçek örnekle bir mini değerlendirme seti kurun. Genel benchmark'lar size Türkçe hukuk ya da Türkçe bankacılık jargonundaki performansı söylemez.

Şimdi asıl vaadime geliyorum. Aşağıda, kullanım senaryosuna göre pratik bir seçim çerçevesi bırakıyorum. Bunu bir reçete gibi değil, bir düşünme aracı gibi kullanın.

1. Sohbet ve Genel Asistan İşleri

Burada öncelik hız ve maliyet dengesidir; en zorlu muhakemeye çoğu zaman gerek yoktur. Kullanıcı gerçek zamanlı bekliyorsa Gemini 3.5 Flash'ın hız avantajı belirleyici. Türkçe üslubun ve tutarlılığın kritik olduğu, markanızın sesini taşıyan asistanlarda Claude Sonnet 5 güçlü bir varsayılan. Genel kural: yüksek hacimli, düşük riskli sohbet için hızlı-ucuz modelle başlayın, yalnızca kalite şikâyeti geldiğinde yükseltin.

2. Kodlama

Kodlama artık tüm frontier modellerin ciddi yarıştığı bir alan. Editör içi tamamlama, hızlı düzeltmeler gibi düşük gecikme isteyen işlerde Gemini 3.5 Flash ve MiniMax M3 öne çıkıyor. Karmaşık, çok dosyalı refactoring, mimari kararlar ve "bu bug'ı bul" tarzı derin muhakeme gerektiren işlerde Claude Sonnet 5 (ve zorlandığında Opus 4.8) benim ilk tercihim. Şirket içinde tutulması gereken kaynak kodu için MiniMax M3'ün açık ağırlıklı olması ayrı bir avantaj.

3. Ajan İş Akışları

Ajan işleri, yani modelin araç çağırdığı, plan yaptığı, adım adım ilerlediği senaryolar, bugünün asıl savaş alanı. Burada modelin tek bir cevaptaki parlaklığı değil, çok adımlı bir görevde tutarlılığı, hata sonrası toparlanması ve araç çağırma disiplini önemli. Claude Sonnet 5 bu boyutta özellikle olgunlaştı ve benim varsayılan önerim. En karmaşık muhakeme düğümlerinde Opus 4.8'e, hız-hassas ve yüksek hacimli ajan adımlarında Gemini 3.5 Flash'a yükseltebilir/indirebilirsiniz. Mimari sırrı şu: tek bir ajanda tek bir model kullanmak zorunda değilsiniz — farklı adımlara farklı model atayın.

4. Uzun Bağlam ve RAG

Bir sözleşme yığınını, bir yıllık destek kaydını ya da devasa bir teknik dokümantasyonu tek seferde işlemek gerektiğinde 1 milyon token bağlam belirleyici. Hem Gemini 3.5 Flash hem MiniMax M3 bu ligde. Gemini 3.5 Flash'ı, hızın da önemli olduğu geniş bağlam işlerinde; MiniMax M3'ü ise verinin şirket içinde kalması gereken uzun bağlam işlerinde konumluyorum. Şunu da ekleyeyim: geniş bağlam pencere, iyi bir RAG mimarisinin yerini tutmaz. Modele "her şeyi at gitsin" demek pahalı ve çoğu zaman daha az doğru; bağlamı akıllıca seçmek hâlâ önemli.

5. Şirket İçi / Açık Ağırlıklı (KVKK, BDDK Veri Yerleşimi)

Verinin yurt içinde, hatta kendi veri merkezinizde kalması zorunluysa denklem netleşir: açık ağırlıklı modeller. MiniMax M3, frontier'a yakın yetenekle bu ihtiyacı karşılıyor; Mistral'in Apache 2.0 modelleri ise lisans netliğiyle kurumsal hukukun içini rahatlatıyor. Bu senaryoda maliyet hesabı da farklıdır: API başına ödeme yoktur ama GPU altyapısı, MLOps ekibi ve bakım maliyeti vardır. Yüksek hacimde bu genellikle karlıdır; düşük hacimde API daha ekonomik olabilir.

Aşağıdaki tabloyu yön gösterici olarak okuyun; kesin sayılar sürekli değişiyor, ama modellerin birbirine göre konumu ve hangi işe uygun oldukları görece istikrarlı.

Model	Konum	Bağlam	Gecikme/Hız	Maliyet	Erişim	En İyi Olduğu İş
Claude Sonnet 5	Dengeli, ajan-güçlü varsayılan	Geniş	Orta	Orta	Açık (varsayılan)	Ajan iş akışları, Türkçe üslup, kodlama
Claude Opus 4.8	Amiral gemisi	Geniş	Yavaş	Yüksek	Açık	En zor muhakeme, kritik kararlar
Gemini 3.5 Flash	Hız + geniş bağlam	1M token	Çok hızlı (~4x)	Düşük-orta	Açık	Gerçek zamanlı sohbet, uzun bağlam, hız-hassas ajan
GPT-5.6 (Sol/Terra/Luna)	Zirve, çok varyantlı	Geniş	Değişken	Yüksek	Sınırlı (devlet yönetimli liste)	En yüksek değerli, düşük hacimli işler
MiniMax M3	Açık ağırlıklı frontier	1M token	Kuruluma bağlı	Altyapı maliyeti	Açık ağırlıklı	Şirket içi kodlama, veri yerleşimli uzun bağlam
Mistral Large/Small	Açık ağırlıklı, Apache 2.0	Orta-geniş	Kuruluma bağlı	Altyapı maliyeti	Açık (Apache 2.0)	Lisans netliği gereken şirket içi kurulum

Bu tablonun bana göre en önemli sütunu "Erişim" sütunu. Çünkü teknik yetenek kadar, o modele istikrarlı ve öngörülebilir biçimde erişebilmek de bir mimari karardır. GPT-5.6 örneğinde gördüğümüz gibi, en yetenekli model her zaman en dayanaklı temel değildir.

Sahada en sık yaptığım düzeltmelerden biri şu: müşteriler modelleri "token başı fiyat" ile karşılaştırıyor ve orada duruyor. Oysa toplam maliyet çok daha katmanlı.

Birincisi, muhakeme modellerinde gizli maliyet. Bir muhakeme modeli cevap vermeden önce "düşünme" tokenları harcar. Etiket fiyatı ucuz görünen bir model, ağır düşünme yaptığında görev başına beklediğinizden çok daha pahalı olabilir. Karşılaştırmayı token başı değil, görev başı yapın.

İkincisi, gecikmenin dolaylı maliyeti. Bir ajan iş akışında modeli 10 kez çağırıyorsanız, her çağrıdaki gecikme birikir. Kullanıcı bekliyorsa bu deneyimi öldürür; arka planda çalışan bir toplu işse önemli olmayabilir. Bu yüzden Gemini 3.5 Flash'ın hızı, çok adımlı ajanlarda etikette görünmeyen bir değer yaratır.

Üçüncüsü, açık ağırlıklı modellerin gerçek maliyeti. "Ücretsiz indirilebilir" demek "bedava çalışır" demek değil. GPU, elektrik, MLOps mühendisi, güvenlik yaması, izleme — hepsi maliyet. Hesabı, aylık çağrı hacminizle yapın: belli bir eşiğin üstünde şirket içi kurulum ucuzlar, altında API daha mantıklıdır.

Benim müşterilerime kurdurduğum pratik disiplin şu: her kullanım senaryosu için "görev başı maliyet" ve "kabul edilebilir gecikme" hedefi belirleyin, sonra modeli buna göre seçin. Model seçimini duygusal marka tercihiyle değil, bu iki sayıyla yapın.

Türkiye'de çalışan bir kurum için model seçimi hiçbir zaman salt teknik bir karar değildir. KVKK, kişisel verilerin işlenmesi ve yurt dışına aktarımı konusunda net sınırlar çizer. BDDK, finansal sektörde veri yerleşimi ve dışarıya bağımlılık konusunda ek yükümlülükler getirir. EU AI Act ise, Avrupa pazarına dokunan her Türk kurumunu dolaylı olarak etkiler; yüksek riskli AI sistemleri için şeffaflık, dokümantasyon ve insan gözetimi zorunlulukları getirir.

Bu tabloda açık ağırlıklı modellerin yükselişi tesadüf değil. Verisini yurt içinde tutmak zorunda olan bir banka için, frontier'a yakın bir açık modeli kendi veri merkezinde çalıştırabilmek, bir yıl önce olmayan bir kapıyı açıyor. Ben buna "veri egemenliği ile yetenek arasındaki tarihsel takasın sonu" diyorum. Eskiden ya verinizi dışarı verip en iyi modeli alırdınız ya da veriyi tutup daha zayıf bir modele razı olurdunuz. Bugün bu ikilem büyük ölçüde yumuşadı.

Pratik önerim şu: düzenlenmiş bir sektördeyseniz, mimarinizi baştan "hibrit" tasarlayın. Hassas, kişisel veri içeren iş akışlarını şirket içi açık ağırlıklı modele; hassas olmayan, kamuya açık bilgiyle çalışan iş akışlarını en yetenekli bulut modeline yönlendirin. Bu ayrımı en baştan mimariye gömün ki, bir denetimde "hangi veri nereye gitti" sorusuna net cevap verebilesiniz. KVKK ve BDDK uyumu sonradan yamanan bir katman değil, mimarinin temel taşı olmalı.

Bir uyarı da tedarikçi bağımlılığı üzerine: GPT-5.6'nın erişim listesi örneği, tek bir tedarikçiye kilitlenmenin risklerini çıplak biçimde gösterdi. Mimarinizi, modeli değiştirmenin kolay olduğu bir soyutlama katmanı üzerine kurun. Bugün Sonnet 5 kullanıyor olabilirsiniz; yarın koşullar değişip başka bir modele geçmeniz gerektiğinde, bunun bir "yeniden yazma projesi" değil, bir "konfigürasyon değişikliği" olması gerekir. Model çağrılarınızı doğrudan uygulama koduna gömmek yerine, arkasında istediğiniz modeli takıp çıkarabileceğiniz bir ara katmanla soyutlayın.

Teoriyi bir yana bırakıp, yarın masaya oturduğunuzda ne yapacağınıza gelelim. Müşterilerime önerdiğim adımları sizinle de paylaşayım.

Önce envanterinizi çıkarın. AI kullandığınız ya da kullanmayı planladığınız her iş akışını listeleyin ve her birini beş eksende etiketleyin: hacim, gecikme hassasiyeti, muhakeme derinliği, veri hassasiyeti ve Türkçe üslup önemi. Bu tek başına bile size hangi işin hangi model kategorisine düştüğünü büyük ölçüde gösterir.

Sonra bir varsayılan seçin. Çoğu kurum için bugün mantıklı varsayılan, dengeli ve ajan-güçlü olması nedeniyle Claude Sonnet 5. Her şeyi buradan başlatın, sonra sadece gerekçesi olan yerlerde sapın: hız için Gemini 3.5 Flash'a inin, en zor muhakeme için Opus 4.8'e çıkın, veri yerleşimi için MiniMax M3 ya da Mistral'e geçin.

Ardından kendi değerlendirme setinizi kurun. Genel benchmark'lar sizin işinizi ölçmez. Kendi alanınızdan, kendi Türkçenizden 30-50 gerçek örnek toplayın ve aday modelleri bu set üzerinde yan yana koşturun. Bir modeli üretime almadan önce, o setteki performansını ölçün. Bu disiplin, size pazarlama iddialarının söyleyemeyeceği tek gerçeği verir: sizin işinizde ne kadar iyi.

En son, soyutlama katmanınızı kurun ve izleyin. Model çağrılarını değiştirilebilir kılın, her çağrının maliyetini ve gecikmesini ölçün, kaliteyi düzenli örnekleme ile denetleyin. Bu manzara önümüzdeki altı ayda yine değişecek — yeni modeller çıkacak, fiyatlar düşecek, erişim koşulları oynayacak. Kazanan, en yeni modeli kovalayan değil; işini doğru modele hızla yeniden yönlendirebilen kurum olacak. Model seçimini bir kerelik bir satın alma değil, sürekli optimize ettiğiniz canlı bir portföy olarak görürseniz, bu hızlı akan sularda ayakta kalmakla kalmaz, rakiplerinizin bir adım önünde durursunuz.

Sahada gördüğüm en olgun kurumların ortak bir alışkanlığı var: tek model peşinde koşmuyorlar, bir model kademesi kuruyorlar. Bunun mantığı şu. Gelen her isteği önce en ucuz ve en hızlı modele gönderirsiniz. Model işi güvenle yaptığında orada durursunuz. Eğer sonuç belirli bir güven eşiğinin altındaysa ya da görev önceden "zor" olarak işaretlenmişse, isteği bir üst kademeye, daha yetenekli ama daha pahalı modele yükseltirsiniz. Bu basit mimari, kaliteyi neredeyse hiç düşürmeden toplam maliyeti çarpıcı biçimde aşağı çeker; çünkü işlerin büyük çoğunluğu aslında zor değildir ve ucuz modelle rahatça hallolur.

Bu kademelemenin bir de "yönlendirme" (routing) katmanı var. İsteği içeriğine bakarak doğru modele dağıtan küçük bir sınıflandırıcı kurabilirsiniz: kod içeren bir istek kodlamada güçlü modele, uzun bir sözleşme geniş bağlamlı modele, hassas kişisel veri içeren bir istek şirket içi açık ağırlıklı modele gider. Bu yönlendiriciyi ne kadar akıllı kurarsanız, portföyünüzün her modelinden o kadar iyi verim alırsınız. Ben buna "orkestra şefi katmanı" diyorum: modeller çalgılar, siz orkestra şefisiniz ve doğru anda doğru çalgıyı devreye sokmak sizin işiniz.

Bir uyarı: bu kademeleme ve yönlendirme mantığını da bir gecikme ve maliyet olarak hesaba katın. Yönlendirici çok ağırsa, kazandığınızı harcarsınız. Genellikle küçük ve hızlı bir sınıflandırıcı ya da basit kural tabanlı bir yönlendirici, en karmaşık öğrenmeli çözümden daha iyi bir başlangıçtır. Sadeyken çalışan bir sistem, karmaşıkken çalışmayan bir sistemden her zaman iyidir.

Bu yazıda bir tema sürekli tekrar ediyor: kendi değerlendirme setinizi kurun. Bunu bir kez daha, biraz derinleştirerek vurgulamak istiyorum, çünkü model seçiminde başarı ile başarısızlığı ayıran çizgi çoğu zaman burada.

Genel benchmark'lar bir modelin "genel zekâsı" hakkında fikir verir ama sizin özel işinizde nasıl performans göstereceğini söylemez. Sizin işiniz Türkçe bir sigorta poliçesini özetlemekse, dünya genelinde en yüksek matematik skorunu alan model sizin için en iyisi olmayabilir. Bunu ancak kendi örneklerinizle ölçerek bilebilirsiniz.

İyi bir değerlendirme seti kurmanın birkaç ilkesi var. Örnekler gerçek olmalı; hayali, temiz, ideal örnekler size yanıltıcı bir güven verir. Gerçek kullanıcılarınızın yazdığı dağınık, eksik, bazen hatalı girdileri kullanın. Örnekler yeterince çeşitli olmalı; kolay, orta ve zor vakaları dengeli biçimde içermeli. Ve en önemlisi, her örnek için "iyi cevap neye benzer" sorusuna bir yanıtınız olmalı; bu bazen kesin bir doğru cevap, bazen bir kontrol listesi, bazen bir insan hakemin puanıdır.

Bu seti bir kez kurduğunuzda, yeni bir model çıktığında yapacağınız iş dakikalar sürer: modeli sete koşturur, skorları eskisiyle karşılaştırır, kararınızı veriye dayanarak verirsiniz. Bu disiplini kurmuş bir ekip, model manzarasındaki her değişikliği bir fırsata çevirir; kurmamış bir ekip ise her yeni lansmanda paniğe kapılır ve pazarlama iddialarının peşinde koşar. Ben, danışmanlık verdiğim her kurumda ilk kurdurduğum şeyin bu değerlendirme kültürü olduğunu söyleyebilirim; çünkü diğer her şey bunun üzerine inşa ediliyor.

Model seçimi teknik bir karar gibi görünür ama sorumlu kullanım boyutu olmadan eksiktir. Hangi modeli seçerseniz seçin, birkaç konuyu mimarinize baştan gömmeniz gerekir.

Birincisi, istem enjeksiyonu (prompt injection) riski. Modelinize dışarıdan gelen metin — bir e-posta, bir web sayfası, bir kullanıcı girdisi — beslerken, o metnin modele gizli talimatlar vermeye çalışabileceğini varsayın. Özellikle araç kullanan, dış dünyaya erişen ajan sistemlerinde bu risk somut. Modelin yapabileceği eylemleri sınırlayın, kritik eylemleri insan onayına bağlayın.

İkincisi, veri sızıntısı. Bulut tabanlı bir API kullanıyorsanız, oraya ne gönderdiğinizi ve tedarikçinin bu veriyle ne yaptığını net bilmelisiniz. Kurumsal anlaşmalarda genellikle verinizin eğitimde kullanılmayacağına dair taahhütler olur; bunları okuyun ve sözleşmeye bağlayın. Hassas veri söz konusuysa, en baştan açık ağırlıklı ve şirket içi seçeneği değerlendirin.

Üçüncüsü, halüsinasyon ve doğruluk. En iyi modeller bile emin bir tonla yanlış bilgi üretebilir. Kullanıcıya doğrudan giden, karar destekleyen çıktılarda mutlaka bir doğrulama katmanı olsun: kaynak gösterimi, insan gözden geçirmesi ya da başka bir sistemle çapraz kontrol. Model ne kadar iyi olursa olsun, "modele güvenip bırakmak" düzenlenmiş bir sektörde kabul edilebilir bir mimari değildir.

Bu üç konuyu model seçiminden ayrı düşünmeyin. Bazen "daha zayıf ama daha kontrol edilebilir" bir kurulum, "daha güçlü ama denetlenemeyen" bir kurulumdan kurumsal olarak daha doğrudur. EU AI Act'in yüksek riskli sistemler için getirdiği insan gözetimi ve şeffaflık zorunlulukları da tam olarak bu noktaya işaret ediyor: yeteneğin tek başına yeterli olmadığı, hesap verebilirliğin de mimariye gömülmesi gereken bir dünyadayız.

Bu yazının başında söylediğimi tekrar edeyim: bu manzara değişecek. Ama nasıl değişeceğine dair birkaç öngörüm var ve bunlara göre hazırlanmanızı öneririm.

Açık ağırlıklı modellerle kapalı frontier modeller arasındaki mesafe daralmaya devam edecek. Bu, düzenlenmiş sektörler için giderek daha çok kapı açacak; şirket içi kurulumun "yeterince iyi" olduğu senaryolar genişleyecek. Bu yüzden, bugün açık ağırlıklı modelleri değerlendirme yeteneğinizi ve MLOps kaslarınızı geliştirmeye başlamak akıllıca.

Maliyetler düşmeye devam edecek. Bugün pahalı olduğu için pilotta kalan fikirlerinizin bir kısmı, altı ay sonra ölçeklenebilir hâle gelecek. Bu yüzden "bugün pahalı" diye rafa kaldırdığınız fikirlerin bir listesini tutun; fiyatlar düştükçe onları geri çağırın.

Erişim ve düzenleme, teknik yetenek kadar önemli bir boyut olmaya devam edecek. GPT-5.6'nın erişim listesi, bir istisna değil, bir yönelimin habercisi olabilir. Mimarinizi model-bağımsız tutan disiplin, önümüzdeki dönemde en değerli sigortanız olacak.

Ve son olarak, ajan iş akışları olgunlaşmaya devam edecek. Bugün tek bir modele "sohbet" ettiğiniz senaryolardan, birden çok modelin bir orkestra gibi çalıştığı, adım adım ilerleyen, hata sonrası toparlanan sistemlere geçiş hızlanacak. Bu geçişe mimari olarak hazır olan kurumlar, sadece tek tek görevleri değil, uçtan uca iş akışlarını dönüştürecek.

Bütün bunların ışığında size bırakacağım son düşünce şu: Temmuz 2026'da doğru soru "en iyi model hangisi" değil. Doğru soru, "işlerimi doğru modellere yönlendiren, değişime hızla uyum sağlayan, veri egemenliğimi ve maliyetimi kontrol altında tutan bir mimariyi nasıl kurarım" sorusu. Bu soruyu bugün ciddiyetle sorup cevaplamaya başlayan kurum, model isimleri kaç kez değişirse değişsin, her seferinde kazanan tarafta olacak. Ben masanın karşısına oturduğumda müşterilerime bu çerçeveyi kurmalarında yardımcı oluyorum; sizin de bu yazıyı bir başlangıç noktası olarak kullanıp kendi portföyünüzü inşa etmeye bugün başlamanızı öneririm.