# Temmuz 2026'da Kurumsal LLM Seçimi: Hangi Model, Hangi İş İçin?

> Source: https://sukruyusufkaya.com/blog/kurumsal-llm-model-secimi-temmuz-2026
> Updated: 2026-07-15T04:43:11.074Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Claude Opus 4.8, GPT-5, Gemini 3, Grok 4... Temmuz 2026'da 'en iyi model' yok; doğru model var. Göreve, bütçeye ve KVKK'ya göre kurumsal seçim çerçevesi.

**TL;DR —** 2026 Temmuz itibarıyla "en iyi LLM hangisi?" sorusunun tek bir doğru cevabı yok; olması da mümkün değil. Sahada gördüğüm gerçek şu: Claude ailesi (Opus 4.8, Sonnet 5, Fable 5) kodlama ve nüanslı yazımda öne çıkıyor, Google'ın Gemini 3 ailesi çok-kipli (multimodal) girdi ve bilimsel muhakemede güçlü, OpenAI'ın GPT-5 ailesi yapılandırılmış akıl yürütme ve bilgisayar kullanımı (agentic görevler) tarafında parlıyor, xAI'ın Grok 4.x en zor muhakeme sınavlarında liderlik ediyor, GLM ve DeepSeek gibi açık/Çin kaynaklı modeller ise veri egemenliği ve maliyet baskısı olan senaryolarda ciddi bir alternatif haline geldi. Kurumsal tarafta doğru soru "hangi model en iyi" değil, "hangi iş için hangi model, hangi bütçe, hangi gecikme ve hangi veri ikameti kısıtıyla" sorusudur. Bu yazıda, KVKK ve Türkçe performansı da dahil ederek, işe göre model seçiminin pratik bir haritasını çıkarıyorum.

## Neden "tek bir en iyi model" arayışı sizi yanlış yere götürür

Danışmanlık yaptığım kurumlarda toplantıların çoğu aynı cümleyle başlıyor: "Şükrü Bey, biz artık şu modele geçelim, en iyisi oymuş." Bu cümleyi her duyduğumda içimden gülümserim, çünkü ardından gelen soruların hepsi aslında farklı işlere ait. Bir bankanın çağrı merkezi özetlemesi için "en iyi" olan model, aynı bankanın hazine ekibinin karmaşık senaryo analizinde "en iyi" olan modelle neredeyse hiçbir zaman aynı değildir. Üstelik bu iki iş, aynı kurumun içinde, aynı hafta, birbirinden tamamen farklı maliyet ve gizlilik profilleriyle karşımıza gelir.

Yıllardır sahada gözlemlediğim en temel yanılgı, LLM seçimini bir "şampiyona" gibi görmek. Sanki her ay bir lig maçı oynanıyor ve en tepedeki modeli alıp tüm süreçlere kurunca iş bitiyormuş gibi. Oysa gerçek şu: 2026 ortasında frontier dediğimiz üst segment o kadar kalabalıklaştı ki, modeller arasındaki fark artık "hangisi genel olarak daha akıllı" ekseninde değil, "hangisi bu spesifik işte, bu maliyetle, bu gecikmeyle daha iyi" ekseninde ölçülüyor. Bu, aslında olgunlaşan her teknolojinin kaderi. Nasıl ki hiç kimse "en iyi programlama dili hangisi" diye sorup tek bir dille tüm sistemini yazmıyorsa, LLM tarafında da aynı olgunluğa geçiyoruz.

Bu yazıyı, son aylarda onlarca kurumla yaptığım mimari toplantılarının damıtılmış hali olarak düşünün. Amacım size bir "şampiyon listesi" vermek değil; kendi kurumunuzda hangi işe hangi modeli, neden ve hangi kısıtlarla eşleştireceğinize dair sağlam bir karar çerçevesi bırakmak. Rakamlara değil, güçlü yönlere göre konuşacağım, çünkü kesin skorlar bu yazıyı okuduğunuz gün büyük ihtimalle çoktan değişmiş olacak.

## 2026 ortasında manzara: kim, neyde güçlü

Önce sahayı net görelim. Temmuz 2026 itibarıyla üst segmentte istikrarlı biçimde konuştuğumuz oyuncular şunlar: Anthropic tarafında Claude Opus 4.8, Claude Sonnet 5 ve Claude Fable 5; OpenAI tarafında GPT-5 ailesi; Google tarafında Gemini 3 ailesi; xAI tarafında Grok 4.x; ve giderek daha ciddiye alınması gereken açık/Çin kaynaklı modeller, özellikle GLM ve DeepSeek varyantları.

Bu modellerin her biri belirli bir kişiliğe, belirli bir "kas grubuna" sahip. Yıllardır bu modelleri gerçek kurumsal iş yüklerinde çalıştıran biri olarak, genel güç dağılımını şöyle özetliyorum ve bu dağılımın aylar içinde ince ayarlarla değişse de ana hatlarıyla korunduğunu görüyorum:

**Claude ailesi — kodlama ve nüanslı yazım.** Anthropic'in modelleri, yazılım geliştirme ve insan tonuna yakın, nüanslı metin üretiminde tutarlı biçimde öne çıkıyor. Bir mühendislik ekibinin gerçek kod tabanında çalışırken, karmaşık bir refactoring'i sabırla ve az hatayla yürütmesi gerektiğinde ilk uzandığım aile bu. Aynı şekilde, bir marka sesinin korunması gereken, tonun kritik olduğu içerik üretiminde de Claude'un nüans yakalama kabiliyeti fark yaratıyor. Sonnet 5, günlük iş yükünün büyük kısmını taşıyabilecek denge modeli; Opus 4.8, en zorlu ve en değerli işler için ayırdığım ağır topçu; Fable 5 ise daha yaratıcı, daha akıcı üretim gerektiren senaryolarda devreye giriyor.

**Gemini 3 ailesi — çok-kiplilik ve bilimsel muhakeme.** Google'ın modelleri, metnin yanında görüntü, tablo, diyagram, hatta karmaşık görsel belgeleri birlikte işlemeniz gereken senaryolarda güçlü. Bir sigorta şirketinin hasar dosyalarındaki fotoğraflarla metni birlikte değerlendirmesi ya da bir Ar-Ge ekibinin bilimsel makalelerdeki grafiklerle akıl yürütmesi gerektiğinde Gemini tarafına bakarım. GPQA tarzı PhD seviyesi bilim sınavlarında gösterdiği performans, bu ailenin bilimsel/teknik muhakemedeki kasını yansıtıyor.

**GPT-5 ailesi — yapılandırılmış muhakeme ve bilgisayar kullanımı.** OpenAI'ın modelleri, adımları net tanımlanmış, yapılandırılmış akıl yürütme ve özellikle "computer use" dediğimiz, bir ajanın ekranı görüp fare-klavye ile görevleri yürüttüğü agentic senaryolarda öne çıkıyor. OSWorld tarzı ajan görevlerinde gösterdikleri başarı, otomasyonun uçtan uca kurgulandığı projelerde bu aileyi güçlü bir aday yapıyor.

**Grok 4.x — en zor muhakeme sınırında.** xAI'ın modeli, "Humanity's Last Exam" gibi bilerek insanlığın en zor sorularından derlenmiş sınavlarda liderlik edebiliyor. Bu, günlük işlerinizin çoğunda doğrudan hissedeceğiniz bir fark olmayabilir; ama gerçekten sınırda, alışılmadık ve yeni muhakeme gerektiren problemlerde bu kası hesaba katmak gerekir.

**GLM ve DeepSeek — açık ve maliyet-egemenlik dengesi.** Bu modeller, özellikle veriyi kurum dışına çıkaramayacağınız, kendi altyapınızda (self-hosted) çalıştırmanız gereken ve maliyet baskısının yüksek olduğu senaryolarda oyuna giriyor. Frontier ile aralarındaki fark her geçek ay kapanıyor ve Türkiye gibi veri ikameti hassasiyetinin yüksek olduğu pazarlarda stratejik bir seçenek haline geliyorlar.

## Muhakeme sınavları neden çeşitlendi ve bu size ne söyler

Birkaç yıl önce herkes tek bir skora bakıyordu; bugün öyle değil. Muhakeme sınavları bilinçli olarak çeşitlendi, çünkü modeller o kadar iyileşti ki tek bir sınav artık ayırt edici olmaktan çıktı. Bugün ciddiye aldığım dört farklı eksen var ve her biri farklı bir kabiliyeti ölçüyor:

- **Humanity's Last Exam (HLE):** İnsanlığın en zor, en uzman-seviyesi sorularından derlenen, modelleri gerçekten sınıra iten bir sınav. Uç muhakeme kasını gösterir.
- **GPQA Diamond:** PhD seviyesinde bilim soruları. Bilimsel/teknik derinlik gerektiren iş yükleri için anlamlı bir gösterge.
- **ARC-AGI-2:** Ezberle değil, gerçekten yeni ve alışılmadık örüntülerle akıl yürütme kabiliyetini ölçer. "Ezberci zeka" ile "gerçek genelleme" arasındaki farkı yakalar.
- **FrontierMath:** Matematiğin en zor ucu. Kantitatif, ispat-yoğun problemlerde modelin gerçekten ne yapabildiğini gösterir.

Buradan çıkaracağınız pratik ders şu: bir modelin "genel olarak zeki" olması, sizin spesifik işinizde en iyi olacağı anlamına gelmez. Eğer işiniz bilimsel makale analiziyse GPQA ekseni, eğer kantitatif finans modellemesiyse FrontierMath ekseni, eğer yeni tür problem çözümüyse ARC-AGI-2 ekseni sizin için daha belirleyicidir. Bu yüzden ben kurumlara her zaman "kendi işinize en yakın ekseni bulun, o eksende güçlü olan modele bakın" derim. Ve çok önemli bir uyarı: bu skorlar aylık olarak değişiyor. Bu yazıyı okuduğunuz gün, güncel liderlik tablolarını mutlaka yeniden kontrol edin. 2026'nın ortasında doğru olan bir sıralama, sonbaharda pekala değişmiş olabilir.

## Kurumsal karar verirken gerçekten baktığım altı faktör

Bir modeli seçerken, "hangisi daha akıllı" sorusu benim listemde bilerek en üstte değil. Yıllar içinde şu altı faktörün, projelerin başarısını belirleyen asıl unsurlar olduğunu gördüm.

### 1. Görev-model uyumu (task-model fit)

Her şeyin başı bu. Modeli işe göre seçin, işi modele göre değil. Özetleme, sınıflandırma, çıkarım (extraction), yaratıcı yazım, kod üretimi, ajan-tabanlı otomasyon — bunların hepsi farklı kaslar ister. Bir çağrı merkezi transkriptini özetlemek için üst segment bir muhakeme modelini kullanmak, çekiçle sinek öldürmek gibidir: işi yapar ama para ve gecikme israfıdır. Tersine, karmaşık bir hukuki sözleşme analizini ucuz bir modele yıkmak da felakete davetiyedir.

### 2. Maliyet katmanlaması (cost tiering)

Kurumsal ölçekte maliyet, tek bir modelle değil, akıllı yönlendirmeyle (routing) yönetilir. Ben buna "ucuz ile pahalıyı ayrıştırmak" diyorum. İşlerin büyük çoğunluğu — belki yüzde 80'i — aslında ucuz, hızlı bir modelle çözülebilir. Geriye kalan, gerçekten zor yüzde 20 için üst segment modeli devreye alırsınız. Bir yönlendirme (router) katmanı kurup gelen her isteği zorluğuna göre doğru modele göndermek, tek başına aylık faturanızı yarıya, hatta üçte bire indirebilir. Sahada bu kararın tek başına bir projenin sürdürülebilirliğini belirlediğini defalarca gördüm.

### 3. Gecikme (latency)

Bir kullanıcı ekranın karşısında yanıt bekliyorsa, gecikme her şeydir. Gerçek zamanlı bir sohbet asistanında iki saniyelik fark, kullanıcının o aracı bir daha açıp açmamasını belirler. Buna karşılık, gece çalışan bir toplu (batch) işlem için gecikme neredeyse önemsizdir; orada tek derdiniz maliyet ve doğruluktur. Bu yüzden "en akıllı ama yavaş" model, canlı bir müşteri deneyiminde "biraz daha az akıllı ama hızlı" modele yenilir.

### 4. Bağlam penceresi (context window)

İşlediğiniz belgelerin boyutu modeli belirler. Yüzlerce sayfalık bir ihale dosyasını, bir yıllık faaliyet raporunu ya da devasa bir kod tabanını tek seferde işlemeniz gerekiyorsa, geniş bağlam penceresine sahip modeller şart. Ama dikkat: geniş bağlam her zaman ücretsiz değildir — hem maliyet hem de dikkatin dağılması (uzun bağlamda modelin ortadaki bilgiyi kaçırması) açısından bedeli vardır. Ben mümkün olduğunca RAG (getirim-artırımlı üretim) ile bağlamı akıllıca daraltmayı, her şeyi pencereye tıkıştırmaya tercih ederim.

### 5. Veri ikameti (data residency)

İşte Türkiye'deki kurumlar için belki de en kritik başlık. Veriniz nerede işlenecek? Bir API'ye gönderdiğinizde veri sınır dışına çıkıyor mu? Bazı sektörlerde — bankacılık, sağlık, kamu — bu soru pazarlık konusu bile değildir. İşte tam burada, kendi altyapınızda çalıştırabileceğiniz açık modeller (GLM, DeepSeek ve benzerleri) stratejik önem kazanıyor. Veriyi hiç dışarı çıkarmadan, kendi veri merkezinizde ya da özel bulutunuzda çalıştırabilmek, bazı projelerde modelin ham zekasından çok daha belirleyici.

### 6. KVKW uyumu

Türkiye'de faaliyet gösteriyorsanız, Kişisel Verilerin Korunması Kanunu (KVKK) her mimari kararın gölgesinde durur. Kişisel veri içeren metinleri bir yurt dışı API'sine göndermeden önce, aydınlatma yükümlülüğü, açık rıza, yurt dışına veri aktarımı kuralları ve anonimleştirme/maskeleme süreçlerini netleştirmek zorundasınız. Ben projelerde çoğu zaman bir "PII maskeleme" katmanı öneriyorum: kişisel veri modele gitmeden önce maskeleniyor, model işini yapıyor, sonra sonuç geri eşleştiriliyor. Bu yaklaşım, hem üst segment API'lerin gücünden faydalanmanızı hem de KVKK tarafında rahat uyumanızı sağlıyor.

## Hangi iş için hangi model: güçlü yönlere göre bir harita

Aşağıdaki tabloyu bir "değişmez gerçek" olarak değil, bir başlangıç haritası olarak okuyun. Kesin skorlar yerine güçlü yönlere göre kurguladım, çünkü asıl kalıcı olan bu. Güncel liderlik tablolarına göre ince ayar yapmayı unutmayın.

| Kullanım senaryosu | Öne çıkan aile/yaklaşım | Neden (güçlü yön) | Dikkat edilecek kısıt |
|---|---|---|---|
| Üretim düzeyi kod geliştirme, refactoring | Claude Opus 4.8 / Sonnet 5 | Kodlamada tutarlı üstünlük, az hata | Maliyet; en zor işler için Opus'u ayırın |
| Marka sesli, nüanslı içerik ve editöryel | Claude Fable 5 / Sonnet 5 | Ton ve nüans yakalama | Kurumsal ton kılavuzuyla besleyin |
| Görsel + metin birlikte (belge, hasar, grafik) | Gemini 3 | Çok-kipli girdide güç | Görsel kalitesi sonucu etkiler |
| Bilimsel/teknik derin muhakeme (Ar-Ge) | Gemini 3 | GPQA tarzı bilim performansı | Alan doğrulaması şart |
| Uçtan uca ajan / bilgisayar kullanımı | GPT-5 ailesi | Yapılandırılmış muhakeme, computer use | Güvenlik/izin sınırlarını netleştirin |
| En zor, sınırda muhakeme problemleri | Grok 4.x | HLE tarzı uç sınavlarda liderlik | Günlük işlerde aşırıya kaçmayın |
| Yüksek hacimli özetleme/sınıflandırma | Ucuz katman (Sonnet 5 veya açık model) | Maliyet/gecikme dengesi | Router ile yönlendirin |
| Veri kurum dışına çıkamayan senaryolar | GLM / DeepSeek (self-hosted) | Veri egemenliği, maliyet | Operasyon/altyapı yükü |
| Türkçe yoğun, kişisel veri içeren işler | Açık model + PII maskeleme | KVKK uyumu, veri ikameti | Türkçe kalite testini atlamayın |

Bu tabloyu her kuruma özel yeniden çiziyorum, çünkü aynı "özetleme" işi bir e-ticaret şirketinde ucuz katmana, bir hukuk bürosunda ise üst segmente düşebilir. Belirleyen, işin kendisinden çok, işin taşıdığı risk ve değerdir.

## Türkçe performansı: göz ardı edilen ama belirleyici bir eksen

Uluslararası liderlik tablolarına bakıp karar veren kurumların en sık yaptığı hata, Türkçe performansını denklemin dışında bırakmak. Oysa bir model İngilizce'de ne kadar parlak olursa olsun, sizin işiniz Türkçe metinler üzerindeyse asıl soru "bu model Türkçe'de ne kadar iyi" olmalıdır.

Sahada gözlemlediğim şey şu: üst segment modeller Türkçe'de son iki yılda ciddi mesafe kat etti, artık dilbilgisi ve akıcılık tarafında büyük sorun yaşamıyoruz. Ama iş nüansa, deyimlere, resmi yazışma diline, hukuki-teknik terminolojiye ve bölgesel bağlama geldiğinde modeller arasında hâlâ hissedilir farklar var. Bir modelin Türkçe resmi bir dilekçeyi doğru tonda yazması, bir başkasının aynı işi hafif "çeviri kokan" bir Türkçe ile yapmasından çok farklı bir deneyim.

Bu yüzden hiçbir kuruma, kendi gerçek Türkçe verisiyle bir test yapmadan model önermiyorum. Küçük ama temsili bir test seti hazırlayın: kendi sektörünüzün gerçek metinlerinden 30-50 örnek alın, aday modelleri bu set üzerinde çalıştırın, çıktıları kendi ekibinize kör (blind) değerlendirtin. Bu yarım günlük iş, size uluslararası tabloların asla veremeyeceği bir gerçeği gösterir: sizin işinizde, sizin dilinizde hangi model gerçekten iyi. Defalarca, uluslararası tabloda ikinci-üçüncü sıradaki bir modelin, spesifik Türkçe iş yükünde birinciyi geçtiğine tanık oldum.

## API maliyetleri: dolar bazlı fiyatları TL gerçeğiyle okumak

Türkiye'de bir gerçekle yüzleşmek zorundayız: bu modellerin neredeyse tamamı dolar bazlı fiyatlanıyor, biz ise TL ile bütçe yapıyoruz. Bu, iki katmanlı bir risk demek. Birincisi, kur dalgalanması bütçenizi ay içinde beklenmedik şekilde şişirebilir. İkincisi, token başına birkaç dolarlık farklar, yüksek hacimde çalıştığınızda aylık faturada milyonlarca TL'lik farka dönüşebilir.

Bu yüzden maliyet planlamasını hiçbir zaman "token başına şu kadar dolar" seviyesinde bırakmayın. Ben şu yaklaşımı öneriyorum:

- **Hacmi modelleyin.** Aylık kaç istek, ortalama kaç girdi ve çıktı token'ı? Bu üç sayı olmadan bütçe yapılamaz.
- **Katmanlı maliyet kurun.** İşlerin çoğunu ucuz modele, azını pahalıya yönlendirdiğinizde ortalama token maliyeti dramatik biçimde düşer.
- **Kur tamponu ekleyin.** Bütçenize belirgin bir kur dalgalanma payı koyun; doların ay içinde hareket edeceğini varsayın.
- **Self-hosted eşiğini hesaplayın.** Belirli bir hacmin üzerinde, açık bir modeli kendi altyapınızda çalıştırmak, API maliyetinin altına inebilir. Bu eşiği hesaplamak, orta-büyük ölçekli her kurum için stratejik bir egzersizdir.
- **Önbelleğe alma (caching) kullanın.** Tekrar eden bağlamları önbelleğe almak, hem gecikmeyi hem de maliyeti ciddi biçimde düşürür.

Şunu net söyleyeyim: gördüğüm en pahalı hata, tüm iş yükünü tek bir üst segment modele yıkıp faturayı sonradan görmek. Doğru mimariyle aynı işi çoğu zaman üçte bir maliyetle, üstelik daha hızlı yapmak mümkün.

## Bir referans mimari: kurumda bunu nasıl kuruyorum

Somut olmak adına, orta-büyük ölçekli bir kurumda tipik olarak önerdiğim mimarinin ana hatlarını paylaşayım. Bunu bir reçete değil, bir düşünce çerçevesi olarak alın.

**Katman 1 — Yönlendirme (Router).** Her gelen istek önce hafif bir sınıflandırıcıdan geçer. Bu sınıflandırıcı işin türünü ve zorluğunu belirler: basit mi, karmaşık mı; kişisel veri içeriyor mu; gerçek zamanlı mı, batch mı. Bu tek katman, sonraki tüm maliyet ve uyum kararlarının temelini atar.

**Katman 2 — Gizlilik ve maskeleme.** Kişisel veri içeren istekler, dış API'ye gitmeden önce bir PII maskeleme katmanından geçer. İsim, TC kimlik, adres, telefon gibi alanlar tokenize edilir; model maskelenmiş metinle çalışır; sonuç geri eşleştirilir. Veri ikametinin katı olduğu işler ise doğrudan self-hosted açık modele yönlendirilir, hiç dışarı çıkmaz.

**Katman 3 — Model havuzu.** Elimde tek model değil, bir havuz var. Ucuz-hızlı işler için bir denge modeli; en zor işler için üst segment bir muhakeme modeli; çok-kipli işler için Gemini tarafı; ajan-otomasyon işleri için GPT-5 tarafı; veri-egemen işler için self-hosted açık model. Router doğru isteği doğru modele gönderir.

**Katman 4 — Değerlendirme ve gözlemlenebilirlik.** Hiçbir modeli "kur ve unut" mantığıyla bırakmam. Sürekli bir değerlendirme (eval) hattı çalışır: çıktıların kalitesi, gecikme, maliyet ve hata oranları izlenir. Yeni bir model sürümü çıktığında, onu doğrudan üretime almadan bu hatta test ederim. Bu disiplin, aylık değişen manzarada sizi hem sürprizlerden korur hem de yeni fırsatları erken yakalamanızı sağlar.

Bu mimarinin en güzel yanı, modelleri "değiştirilebilir parçalar" haline getirmesi. Yarın Grok bir sürüm atlayıp belirli bir işte lider olursa, siz tüm sistemi değil, sadece o işin yönlendirmesini değiştirirsiniz. Bu esneklik, aylık değişen bir dünyada altın değerinde.

## Sık yaptığım uyarılar ve sahadan gözlemler

Yıllar içinde aynı hataları farklı kurumlarda tekrar tekrar gördüm. Sizi bunlardan korumak isterim.

**"En iyi model" saplantısından kurtulun.** En iyi modeli aramak yerine, en iyi eşleşmeyi arayın. Bir işte üçüncü sıradaki model, sizin kısıtlarınızla birinci olabilir.

**Tek bir sağlayıcıya kilitlenmeyin.** Tüm yumurtaları tek sepete koymak, hem müzakere gücünüzü hem de esnekliğinizi öldürür. Mimarinizi baştan çok-modelli kurun; bir sağlayıcı fiyat artırınca ya da bir model gerilerken hızla dönebilin.

**Değerlendirmeyi ciddiye alın.** "Şöyle bir denedim, iyi gibiydi" bir metodoloji değildir. Kendi verinizle, tekrarlanabilir bir eval hattı kurmadan hiçbir modele üretimde güvenmeyin.

**Gecikmeyi kullanıcı gözünden ölçün.** Ortalama gecikme yanıltıcıdır; asıl önemli olan kötü senaryodaki (p95, p99) gecikmedir. Kullanıcı en yavaş anı hatırlar.

**KVKK'yı sonradan değil baştan tasarlayın.** Uyumu projenin sonuna bırakırsanız, çoğu zaman baştan yapmanız gerekir. Veri akışını ilk günden uyumlu kurgulayın.

**Türkçe testini atlamayın.** Uluslararası tablo ne derse desin, sizin diliniz, sizin işiniz için son kararı kendi Türkçe test setiniz versin.

## Karar verirken izleyebileceğiniz pratik adımlar

Bu yazıyı okuduktan sonra masanıza döndüğünüzde, şu sıralı adımları izlemenizi öneriyorum. Bunu bir kapanış değil, bir başlangıç listesi olarak görün.

Önce işi tanımlayın: hangi görev, hangi hacim, hangi gecikme beklentisi, hangi veri hassasiyeti? Bu dört soruyu net cevaplamadan model konuşmayın. Sonra işi bir eksene oturtun: kodlama mı, nüanslı yazım mı, çok-kiplilik mi, bilimsel muhakeme mi, ajan-otomasyon mu, uç muhakeme mi? Ekseni bulduğunuzda, o eksende güçlü aileyi kısa listeye alın. Ardından kendi Türkçe ve kendi sektör verinizle kör bir test yapın; uluslararası tabloya değil, kendi sonucunuza güvenin. Maliyeti katmanlı kurgulayın ve kur tamponunu unutmayın. Veri ikameti ve KVKK kısıtı varsa, self-hosted açık model ile PII maskeleme seçeneklerini masaya koyun. Son olarak, kurduğunuz sistemi bir eval hattıyla sürekli izleyin ve her yeni model sürümünü üretime almadan önce bu hatta sınayın.

Bu adımları izlerseniz, "hangi model en iyi" sorusunun aslında yanlış soru olduğunu, doğru sorunun "benim bu işim için, bu kısıtlarımla, bu ay hangi model en iyi eşleşme" olduğunu kendiniz göreceksiniz. Ve o soruyu sorabilen kurum, aylık değişen bu manzarada rakiplerinden her zaman bir adım önde olur. Manzara her ay değişecek; değişmeyecek olan, doğru soruyu sorma disiplini. Onu kurun, gerisi mühendislik.

## Sektör sektör: sahadan somut örnekler

Soyut çerçeveler faydalı ama asıl öğreten, somut vakalar. Son dönemde farklı sektörlerde karşılaştığım tipik senaryoları, isim vermeden ama gerçeğe sadık kalarak paylaşayım; kendi kurumunuzu bunlardan birinde tanıyacaksınız.

**Bankacılık ve finans.** Bir bankada iki tamamen farklı dünya bir arada yaşıyor. Bir yanda çağrı merkezi transkriptlerinin özetlenmesi, müşteri taleplerinin sınıflandırılması gibi yüksek hacimli, düşük riskli işler var; bunları ucuz-hızlı katmana yıkıp maliyeti minimumda tutuyorum. Diğer yanda hazine ve risk ekiplerinin karmaşık senaryo analizleri, mevzuat yorumlaması gibi düşük hacimli ama çok yüksek değerli işler var; burada üst segment muhakeme modeli devreye giriyor. Ama bankacılıkta asıl belirleyici veri ikameti: müşteri finansal verisi çoğu zaman yurt dışına çıkamaz. Bu yüzden mimarinin merkezine PII maskeleme ve gerektiğinde self-hosted açık model koyuyorum.

**Sağlık.** Sağlıkta veri hassasiyeti tavan yapıyor. Hasta verisi içeren hiçbir metnin, açık rıza ve KVKK süreçleri netleşmeden dış API'ye gitmesine izin vermem. Burada Gemini tarafının çok-kipli gücü cazip — tıbbi görüntü ile raporu birlikte değerlendirmek büyük değer üretir — ama bunu ancak veri ikameti çözülmüş, maskelenmiş bir hatla kurgularım. Sağlıkta yavaş ve doğru, hızlı ve riskliye her zaman yeğdir.

**Hukuk.** Hukuk büroları ve kurumsal hukuk departmanları için nüans her şeydir. Bir sözleşme maddesinin yanlış yorumlanması milyonlarca liralık sonuç doğurabilir. Burada Claude ailesinin nüans yakalama gücü ve uzun bağlam kapasitesi öne çıkıyor; yüzlerce sayfalık sözleşmeleri işlerken hem doğruluk hem tutarlılık kritik. Ama yine Türkçe hukuk terminolojisi testini atlamıyorum: bir modelin İngilizce hukukta parlak olması, Türk hukuk dilinde aynı performansı göstereceği anlamına gelmiyor.

**E-ticaret ve perakende.** Burada oyun tamamen hacim ve maliyet ekseninde dönüyor. Milyonlarca ürün açıklaması, müşteri yorumu, arama sorgusu — hepsi ucuz katmana ideal aday. E-ticarette benim en sık kurduğum yapı, işlerin neredeyse tamamını dengeli veya açık bir modele yönlendiren, sadece kampanya metinleri gibi yaratıcılık gerektiren kısımlar için üst segmente çıkan bir router. Burada birkaç kuruşluk token farkı, yıllık ölçekte devasa rakamlara dönüşüyor.

**Kamu ve savunma.** Bu tarafta veri egemenliği pazarlık konusu değil, ön koşul. Verinin ülke sınırları içinde, çoğu zaman kurumun kendi altyapısında kalması gerekiyor. İşte GLM ve DeepSeek gibi açık modellerin gerçekten parladığı yer burası. Frontier ile aralarındaki farkı, veriyi hiç dışarı çıkarmama güvencesiyle takas etmeye değer buluyorum. Bu kararların çoğunda "en akıllı model" değil, "sınırlarım içinde çalışabilen en iyi model" kazanıyor.

Bu örneklerin ortak dersi şu: aynı LLM manzarası, sektörün risk ve değer profiline göre tamamen farklı mimarilere dönüşüyor. Sizin işiniz için doğru cevap, komşu sektördeki doğru cevaptan çok farklı olabilir — ve olmalı da.