Fiyat/performans: aynı iş yükünde model karşılaştırmasını yönetmek

Yöneticilerin en sık düştüğü tuzak, genel benchmark skorunu iş kararı sanmaktır. Liderboard’da öne çıkan bir model, sizin destek özetinizde, sözleşme taslağınızda veya iç bilgi tabanı sorularınızda aynı kaliteyi ve maliyeti üretmeyebilir. Bu yazı; aynı iş yükünde maliyet × kalite × gecikme üçlüsünü nasıl ölçeceğinizi, karar kaydını nasıl bırakacağınızı ve vendor görüşmesini nasıl çerçeveleyeceğinizi anlatır.

Tez: Benchmark skoru iş KPI’sı değildir. Karar, sizin tanımladığınız iş yükünde ölçülmüş toplam maliyet ve kabul edilebilir kalite eşiğiyle verilir.

Test tasarımı: önce soruyu kilitleyin

Karşılaştırmaya model listesiyle başlamak yerine şu soruları kilitleyin:

1. İş nedir? (ör. gelen müşteri mailini 5 maddelik iç özet + sonraki adım) 2. Başarı nedir? (insan editörün kabul ettiği çıktı oranı; kritik hata tanımı) 3. Kısıtlar nedir? (maksimum gecikme, veri sınıflandırması, dil, format) 4. Kim karar verir? (ürün + risk + finans ortak imzası)

Bu dört madde yoksa “hangi model daha iyi?” sorusu politik bir tartışmaya dönüşür. Test tasarımı, teknik ekibin değil iş sahibinin de imzaladığı bir protokoldür.

Önerilen minimum protokol:

- Sabit prompt iskeleti (sistem talimatı + çıktı şablonu) - Sabit değerlendirme seti (en az onlarca gerçek örnek; sentetik veri tek başına yetmez) - Kör değerlendirme (değerlendirici hangi modeli gördüğünü bilmesin) - Tekrarlanabilirlik (aynı girdide sıcaklık/seed politikası yazılı)

İş yükü tanımı: “genel sohbet” iş değildir

İş yükünü üç katmanda yazın:

Girdi profili. Ortalama uzunluk, dil karışımı, ek dosya varlığı, hassas veri oranı. Çıktı sözleşmesi. JSON mu, yönetici özeti mi, customer-facing metin mi? Operasyon bağlamı. Eşzamanlı istek, gün içi pik, insan onay kapısı var mı?

Aynı “LLM” kategorisinde bile RAG’li kurumsal asistan ile tek atımlık metin üretimi farklı iş yüküdür. Karşılaştırmayı bu ayrımı silerek yapmak, yanlış kazanan ilan etmektir.

Pratik: her aday modeli aynı 30–100 örnek üzerinde çalıştırın. Örnekler üretim dağılımını yansıtmalı; sadece “kolay” demolar seçmek Soft PASS tuzağıdır.

Kalite rubriği: sayı uydurmadan net eşikler

Uydurma yüzde veya pazar payı kullanmayın. Bunun yerine rubrik kurun:

| Boyut | 0–2 ölçek (örnek) | Fail koşulu |
|-------|-------------------|-------------|
| Doğruluk / uydurma | Kaynakla çelişki var mı | Kritik uydurma = otomatik fail |
| Talimat uyumu | İstenen format/alanlar | Eksik zorunlu alan |
| Ton / risk | Yönetici dili, abartı yok | Hukuki/vaat dili |
| Kullanılabilirlik | Editör kaç dakika harcar | Aşırı yeniden yazım |

Kalite skoru, ağırlıklı ortalama olabilir; ama fail koşulu ortalamayı ezer. Bir model ortalama “iyi” görünüp kritik uydurmada sık düşüyorsa üretim için aday değildir.

İnsan değerlendirici maliyeti yüksektir; bu yüzden önce otomatik kontroller (şema, yasaklı ifade, boş alan), sonra örneklemeli insan review.

Toplam maliyet: token fiyatı tek satırdır

Fiyat/performans hesabında şunları toplayın:

- Girdi + çıktı token (veya karakter) maliyeti × beklenen hacim - Araç çağrıları / retrieval / yeniden deneme - İnsan editör süresi (dakika × maliyet) - Gecikmenin iş maliyeti (SLA ihlali, kuyruk) - Vendor minimum taahhüt, rezervasyon, egress

Ucuz model, yüksek yeniden yazım ve yüksek fail ile daha pahalı olabilir. Bu cümleyi finans diline çevirin: “iş başına maliyet” ve “kabul edilmiş çıktı başına maliyet”.

Latency’yi de aynı tabloya koyun. p50 ile p95 ayrımı yapın; yönetim sunumunda yalnız ortalama gecikme göstermek yanıltıcıdır.

Karar kaydı: sonra tartışmayı bitiren artefakt

Her karşılaştırma sonunda tek sayfalık karar kaydı bırakın:

- İş yükü tanımı ve tarih - Aday modeller + tarih/versiyon - Rubrik ve fail kuralları - Özet tablo (kalite / maliyet / latency) — ölçülen, tahmin edilmeyen - Seçim ve gerekçe - Gözden geçirme tarihi (model/versiyon değişince yeniden test)

Bu kayıt olmadan üç ay sonra “neden bu vendor?” sorusu tekrar açılır. Karar kaydı, AI governance ile de bağlanır: kim onayladı, hangi risk kabul edildi.

Vendor ve iç platform görüşmesi

Tedarikçiye sorulacaklar:

- Sizin iş yükünüze yakın referans var mı, yoksa genel demo mu? - Fiyat değişim politikası ve deprecation süresi - Verinin eğitinde kullanılıp kullanılmadığı - Bölge / residency / log saklama - Rate limit ve burst davranışı

İç platform için: tek model kilidi yerine iş yükü bazlı routing (ucuz model + zor işlerde güçlü model) çoğu kurumda daha rasyoneldir — ama routing de aynı rubrik ve maliyet hesabıyla yönetilmeli.

Yönetici özeti

1. Benchmark ≠ iş kararı. 2. Önce iş yükü ve fail koşulları. 3. Kalite + maliyet + latency aynı tabloda. 4. Token fiyatı yetmez; insan ve yeniden deneme dahil. 5. Karar kaydı olmadan seçim tamamlanmış sayılmaz.

Örnek değerlendirme akışı (iki haftalık sprint)

Birinci hafta protokol kilidi: iş sahibi, risk ve platform aynı odada (veya yazılı thread’de) iş yükünü, fail koşullarını ve örneklem kaynağını imzalar. Bu hafta model yarışı yoktur; yarış protokolü vardır.

İkinci hafta koşum: her aday için aynı pipeline (retrieval varsa aynı indeks, aynı chunk politikası). Sonuçlar kör rubrik ile işaretlenir. Hafta sonunda karar kaydı taslağı çıkar; itiraz varsa yalnızca protokol ihlali veya ölçüm hatası üzerinden yapılır — “ben bu modeli daha çok beğendim” geçerli argüman değildir.

Bu disiplin sert görünür; aslında siyasi maliyeti düşürür. Herkes kuralları önceden bildiği için kaybeden vendor tartışması kişiselleşmez.

Sık görülen metodoloji hataları

Demo seti yanlılığı. Satış toplantısında parlayan 10 örnek, üretim kuyruğundaki uzun, kirli, eksik girdileri temsil etmez. Değerlendirme setinin en az bir kısmı “zor ve çirkin” olmalıdır.

Tek atımlık iyimserlik. Bazı işler çok adımlı ajan veya tool zinciri ister. Tek prompt benchmark’ı, zincir kırılmalarını görmez. İş yükünüz ajanlıysa testi de ajanlı kurun; aksi halde elma-armut karışır.

Gizli prompt mühendisliği yarışı. Her modele farklı, aşırı optimize prompt yazmak karşılaştırmayı bozar. İzin verilen uyarlama sınırını protokole yazın (ör. yalnızca sistem mesajında marka adı değişir).

Maliyet hesabını “liste fiyatı”nda bırakmak. İndirimli rezervasyon, batch API, cache’lenen prefix’ler toplam maliyeti değiştirir. Hesabı sizin sözleşme taslağınıza göre yapın; blog yazısındaki fiyat tablosuna göre değil.

Latency’yi yok saymak. Kullanıcı bekleyen bir asistan ile gece batch özeti aynı SLA’ya sahip değildir. p95’i tabloya koymayan karşılaştırma eksiktir.

Kalite–maliyet sınır eğrisi (kavramsal)

Modelleri bir saçılımda düşünün: yatay eksen iş başına maliyet, dikey eksen kabul oranı (fail olmayan çıktı). Hedefiniz “en ucuz” veya “en yüksek skor” değil; kabul eşiğinin üstünde kalan en düşük toplam maliyet (veya stratejik olarak biraz daha pahalı ama daha düşük operasyon riski) bölgesidir.

Bu eğriyi rakam uydurmadan da konuşabilirsiniz: ölçümlerinizi kendi tablonuza dökün, eşiği iş sahibi belirlesin. Eşik yoksa herkes kendi favori modelini “performans” diye satar.

Güvenlik ve uyum boyutu fiyat/performansa dahil mi?

Evet — çünkü bir model ucuz ve hızlı olsa bile veri işleme koşulları sizi bloke ediyorsa aday değildir. Karşılaştırma matrisine ayrı bir sütun açın: uyum geçti/kaldi. Bu sütun sayısal skor değil; kapı kontrolüdür. Kapıdan geçemeyen aday kalite yarışına girmez.

Aynı şekilde log saklama, alt işlemci zinciri ve eğitimde veri kullanımı da kapıdır. Bunları “sonra bakarız” diye ertelemek, go-live sonrası pahalı geri dönüş demektir.

Yeniden test tetikleri

Karar kaydındaki gözden geçirme tarihi boş kalmamalı. Yeniden test tetikleri örnekleri:

- Model major versiyon veya deprecation duyurusu - İş yükü tanımında maddi değişiklik (yeni dil, yeni doküman tipi) - Fail oranında operasyonel bozulma sinyali - Fiyat listesi veya rezervasyon koşullarında kırılım - Regülasyon veya iç politika değişikliği

Yeniden test, ilk test kadar kapsamlı olmak zorunda değildir; ama aynı rubrik ve aynı fail kuralları korunmalıdır. Aksi halde zaman içinde Soft PASS birikir.

Platform ekibine net talep listesi

Yöneticinin platform ekibinden isteyebileceği somut çıktılar:

1. İş yükü kartı şablonu (tek sayfa) 2. Kör değerlendirme formu 3. Maliyet hesap sayfası (token + insan + retry) 4. Karar kaydı şablonu 5. Aylık “model sağlığı” özeti (fail, latency, maliyet sapması)

Bu beş artefakt yoksa kurum “model seçiyor” değil, “model tartışıyor” demektir.

Finans ile ortak dil

Finansa “LLM daha ucuz” demek yetmez. Şunu deyin:

- Beklenen aylık iş hacmi (iş birimi tahmini) - Kabul edilmiş çıktı başına maliyet aralığı (ölçümden) - İnsan editör FTE etkisi (azalma veya artma senaryoları) - Vendor kilit riski ve çıkış maliyeti (nitel)

Finans, belirsizliği severek yönetir; uydurma kesin rakamı değil. Aralığı ve varsayımları yazın. Varsayım değişince tabloyu güncelleyin.

Sonuç: yönetilebilir bir yarış

Fiyat/performans karşılaştırması bir kez yapılan gizli bir POC değildir; tekrarlanan bir yönetim pratiğidir. Protokol, rubrik, maliyet, latency, uyum kapısı ve karar kaydı bir araya geldiğinde model seçimi kişilik yarışından çıkar, işletme kararına dönüşür.

AI Ekonomisi bu çerçeveyi bilerek yayınlar: amaç “hangi model birinci” listesi değil, yöneticinin kendi ölçümünü kurmasıdır.

İç link önerileri

- Model maliyeti ve birim ekonomi - Kurumsal AI ürün seçimi: build vs buy - MLOps ve üretimde görünmeyen maliyet

Newsletter CTA

Kurumsal AI maliyet ve model seçimi notları için Şirketlerde AI listesine kaydolun (üyelik sistemi açıldığında).

---

Operasyonel izleme (seçimden sonra)

Seçim bittiğinde iş bitmez. Üretimde fail oranı, p95 gecikme ve iş başına maliyet için hafif bir izleme panosu (veya haftalık tablo) şarttır. Sapma eşiği aşılınca yeniden test tetiklenir; “model bir kez seçildi sonsuza kadar” yaklaşımı Soft PASS üretir.

Ayrıca aynı iş yükünde ikinci bir yedek model (failover) tanımlamak çoğu kurumda rasyoneldir. Yedek, birincinin kopyası olmak zorunda değildir; maliyet/kalite trade-off’u yazılı olmalıdır.

*AI Ekonomisi, ManegAI ekibinin yayın girişimidir. Bu metin draft olup kurucu onayına tabidir; yayınlanmamıştır. Uydurma pazar istatistiği içermez; kurum kendi ölçümünü yapmalıdır.*