Tipli Karar Modeli mi, Sohbet Modeli mi? 446 Modellik Gerçek Katalogda Ölçtük

İki gün önce tipli karar modellerinin ne olduğunu yazmıştık: metin üretmeyen, sorduğunuz soruya olasılıklı ve tipli cevap dönen modeller. Yazıdan sonra gelen ilk soru haklı bir soruydu: "Bunu ucuz bir sohbet modeline JSON şema dayatarak zaten yapmıyor muyuz?"

Cevabı tahmin etmek yerine ölçtük. İkisine de aynı gerçek işi verdik: kendi model kataloğumuzu denetlemek. Toplam 446 model, üç soru, iki yöntem. Sonuçta beklediğimiz iki fark (maliyet ve gecikme) çıktı, beklemediğimiz üçüncü bir fark da çıktı — ve asıl önemlisi o. Üstelik denetim, kataloğumuzda olmaması gereken gerçek bir modeli buldu; yazının sonunda onu ne yaptığımızı da anlatıyoruz.

İş: Katalogda Olmaması Gereken Modeli Bulmak

Onysoft kataloğunda yetişkin ve eşlik/roleplay sınıfı modeller yer almaz. Sebep ahlaki bir duruş değil, ticari bir zorunluluk: kurumsal müşteri, ödeme altyapısı ve partner kanalı bu sınıfı taşımıyor.

Bugüne kadarki eleme kuralımız iki satırdı: yayıncı adı listesi ve model kimliğinde geçen kalıplar (uncensored, nsfw gibi). Senkronizasyon kodumuzdaki yorum, neden açıklama metnine göre elemediğimizi de söylüyor:

"Yayıncı bazlı eleme tercih edildi; açıklama metnine göre eleme yanlış pozitif üretir (Hermes gibi genel amaçlı modeller de roleplay kelimesi taşıyor)."

Bu kuralın bilinen zayıflığı şu: listede olmayan yeni bir yayıncı sessizce içeri girer. Tam olarak bunu aramak için iyi bir test: sonucu elle doğrulanabilir, etiketleri zaten elimizde ve yanılmanın bedeli gerçek.

Kurulum: Aynı Üç Soru, İki Yöntem

Veri kümesi: katalog kaynağımızdaki 446 metin modeli, her biri için model kimliği, adı ve açıklaması (ortalama 208 karakter). Etiket: elle hazırlanmış eleme listemizin yakaladığı 15 model.

Her modele üç soru sorduk ve aynı üç soruyu iki farklı yolla çalıştırdık:

• Tipli karar modeli (Jev): choice ile ana amaç, score ile 0-3 arası "kurumsal katalog riski", noul ile "bu model esas olarak yetişkin içeriği için mi pazarlanıyor" olasılığı.
• Sohbet modeli (google/gemini-3.8-flash, Onysoft üzerinden): birebir aynı tanımlar response_format: json_schema ile katı şemaya çevrildi, temperature: 0, puanlar ve güven değerleri şemada sayı alanı olarak istendi.

Karşılaştırma 446 modelin tamamında tipli modelle, ardından 60 modellik denetimli bir örneklemde (15 eleme adayının hepsi + rastgele seçilmiş 45 normal model) iki yöntemle birlikte yapıldı.

İlk Sonuç: Yanlış Soru Sorarsanız Doğru Model de Yanlış Cevap Verir

İlk denememizde "bu model yetişkin içeriği için mi pazarlanıyor" sorusu (noul) 15 modelin yalnızca 3'ünü 0,50 eşiğinin üstüne çıkardı. İlk bakışta başarısızlık görünüyor. Değil.

Açıklama metinlerine bakınca sebep ortaya çıkıyor: bu modellerin hiçbiri kendini "yetişkin" diye tanıtmıyor. "Zengin betimlemeler", "karakter tutarlılığı", "yaratıcı yazım" diyorlar. Yani sorduğumuz sorunun dürüst cevabı gerçekten düşük olasılıktı. Model doğru cevap verdi; biz yanlış soruyu sorduk.

Aynı istekteki score sorusu — "bu modeli kurumsal bir katalogda listelemenin riski" — ise ayrımı net yaptı:

Grup	Ortalama risk puanı	Aralık
Elle elenmiş 15 model	1,99 / 3	0,44 – 2,95
Diğer 431 model	0,10 / 3	0,00 – 1,79

Ders şu: tipli model, soru tasarımını sizin yerinize yapmaz. "Doğru cevabı ver" diye değil, "hangi soruyu sorduğumu biliyorum" diye çalışan bir araç. Aynı bağlam, aynı model, iki soru — biri işe yaramaz, diğeri işi bitirir.

Beklemediğimiz Fark: Güven Gerçekten Bir Eksen mi?

İki yöntemin asıl ayrıldığı yer burası oldu. Her iki yöntemden de puanın yanında bir güven değeri istedik. Tipli modelde güven, API'nin döndürdüğü bir alan; sohbet modelinde ise şemaya koyduğumuz bir sayı alanı. İsimleri aynı, davranışları aynı değil:

60 modelde	Tipli karar modeli	Sohbet modeli (JSON şema)
Farklı güven değeri sayısı	25	6
Güven standart sapması	0,171	0,059
Güven aralığı	0,22 – 0,98	0,80 – 0,99
Farklı risk puanı sayısı	33	4
Tam sayıya yuvarlanmış puan oranı	%0	%100

Sohbet modeli, şema onu zorladığı için her seferinde bir güven sayısı yazdı — ama yazdığı sayı neredeyse sabitti: 60 kararın hepsinde 0,80 ile 0,99 arasında. Yani "emin değilim" diyebileceği bir aralığı fiilen kullanmadı. Risk puanında ise daha da nettir: dört farklı değer üretti ve hepsi tam sayıydı (0, 1, 2, 3). 1,79 ile 1,63'ü ayırt edemezsiniz, çünkü model o ara değerleri hiç yazmıyor.

Somut örnek — senkronizasyon kodumuzun yıllardır "bu yanlış pozitif üretir" diye uyardığı model:

Model	Tipli model	Sohbet modeli
nousresearch/hermes-3-llama-3.1-70b	risk 1,48 — güven 0,46	risk 1,00 — güven 0,90
nousresearch/hermes-3-llama-3.1-405b	risk 1,26 — güven 0,22	risk 1,00 — güven 0,90

Tipli model, "bu metinde beni kararsız bırakan bir şey var" bilgisini ölçülebilir biçimde verdi. Sohbet modeli aynı belirsizlikte de 0,90 yazdı. Kodunuzda if ($guven < 0.5) insanaSor(); satırı varsa, bu fark doğrudan davranış farkıdır.

Maliyet ve Gecikme: Beklenen Fark, Beklenenden Büyük

Aynı 60 karar için ölçülen değerler:

Ölçüm	Tipli karar modeli	Sohbet modeli
İstek başına girdi tokeni	654	442
İstek başına çıktı tokeni	94 (ücretsiz)	265
Gecikme (medyan)	1,11 sn	4,02 sn
Gecikme (p95)	1,21 sn	12,28 sn
1.000 karar maliyeti	$0,0275	$1,99

Aradaki fark 72 kat. Dikkat çeken ayrıntı: tipli model aslında daha fazla girdi tokeni harcıyor (654'e karşı 442), çünkü soru tanımları her istekte yeniden gönderiliyor. Buna rağmen kazanıyor, çünkü sohbet modelinin parası çıktıda gidiyor — karar başına 265 çıktı tokeni, üstelik çıktı tokeni girdinin beş katı fiyatlı.

Gecikmedeki p95 farkı da önemli: tipli modelde en yavaş istek 1,21 saniyedeydi, sohbet modelinde 12,28. Kullanıcıyı bekleten bir akışa karar kapısı koyacaksanız, ortalama değil bu kuyruk değeri belirleyicidir.

Not: iki ölçüm farklı eşzamanlılıkla alındı (tipli modelde 6, sohbet modelinde 3 paralel istek), o yüzden toplam süreler değil istek başına gecikmeler karşılaştırılmalıdır.

Sohbet Modelinin Sessiz Tuzağı: Görünmeyen Düşünme Bütçesi

Karşılaştırmanın ilk turunda sohbet modeline max_tokens: 300 verdik — beş alanlı, 105 karakterlik bir JSON için fazlasıyla yeterli görünüyordu. Sonuç: 60 isteğin 14'ü ayrıştırılamadı.

Dönen gövdeye baktığımızda asıl sorun ortaya çıktı:

finish_reason : "stop"
usage.completion_tokens : 285
içerik : {"adult_rp":0.9,"purpose":"roleplay","purpose

Model 285 çıktı tokeni harcamış ve faturalanmış, ama bize ulaşan metin 45 karakterde kesilmiş. Daha kötüsü, finish_reason bunu "length" diye değil "stop" diye bildiriyor — yani standart kontrolünüz bu hatayı yakalamaz.

Sebep, düşünen modellerde görünmeyen akıl yürütme tokenlerinin bütçeyi yemesi. Bütçeyi 1.200'e çıkardığımızda 60/60 istek temiz JSON döndü. Bunun bir ağ geçidi sorunu olmadığını doğrulamak için aynı isteği modele doğrudan da gönderdik; davranış birebir aynıydı.

Pratik sonuç, JSON şema kullanan herkes için geçerli üç kural:

• Görünür çıktının uzunluğuna göre değil, düşünme payı bırakarak bütçe verin.
• finish_reason tek başına yeterli kanıt değil; gövdeyi her zaman ayrıştırın ve ayrıştırma hatasını yeniden deneyin.
• Faturanızı çıktı tokeni belirler: 285 token harcanıp 45 karakter dönmesi, hem para hem karar kaybıdır.

Tipli modelde bu sınıf hata yapısal olarak yok: dönen şey zaten metin değil, sayı. 446 isteğin hiçbirinde ayrıştırma hatası almadık.

İsabet: İki Yöntem de 14/15, Ama Kaçırdıkları Farklı

60 modellik denetimli örneklemde, "puan ≥ 1,8 ve güven ≥ 0,75" eşiğiyle:

	Tipli karar modeli	Sohbet modeli
Yakalanan (15 etiketli)	14	14
Yanlış alarm (45 normal)	0	1
Ayrıştırma hatası	0	0 (bütçe düzeltildikten sonra)

İki yöntem de aynı orana ulaştı; ilginç olan neyi kaçırdıkları.

Tipli modelin kaçırdığı model anthracite-org/magnum-v4-72b (risk 0,44). Açıklamasına bakınca kaçırması doğru: "Claude 3 modellerinin düzyazı kalitesini taklit etmek için tasarlanmış, Qwen2.5 72B üzerine ince ayarlanmış." Bu metinde eleme gerekçesi yok; gerekçe yayıncının konumlanmasında. Model yalnızca kendisine verilen duruma bakar — bilmediği şeyi uyduracağına düşük puan verdi.

Sohbet modelinin "yanlış alarm" hanesine yazdığı model ise aslında haklı çıktığı yerdi. O modele birazdan geliyoruz.

Denetimin Bulduğu Gerçek Sorun

Sıralamanın tepesinde, eleme listemizde olmayan bir model duruyordu:

undi95/remm-slerp-l2-13b
"A recreation trial of the original MythoMax-L2-B13 but with updated models."

tipli model : risk 1,79  güven 0,67
sohbet      : risk 2,00  güven 0,85

Bu model, kataloğumuzda aktif durumdaydı. MythoMax'in birebir yeniden üretimi — yani eleme listemizin zaten dışarıda tuttuğu ailenin aynısı. Kural onu kaçırmıştı çünkü yayıncı adı listede yoktu ve kimliğinde hiçbir kalıp geçmiyordu.

Aynı gün kapattık: model pasife alındı, yayıncı EXCLUDED_PUBLISHERS listesine eklendi. Kural artık aynı yayıncının bir sonraki modelini de tutuyor.

Burada dürüst olmak gerekiyor, çünkü asıl ders bu: sert eşik bu modeli yakalamıyordu. 1,79 puan, 1,80 eşiğinin altında kalıyor. Onu bulan şey eşik değil, sıralanmış listeye bakan insandı. Kalibre bir puanın asıl değeri tek bir kesme noktası vermesi değil, size bir inceleme sırası vermesidir — 446 modelin hangi 15'ine bakacağınızı söylemesi.

Üretime Aldığımız Hâli

Ölçüm bir kereye mahsus kalmasın diye denetimi haftalık bir işe çevirdik. Tasarım kararları, yukarıdaki ölçümlerin doğrudan sonucu:

• İki bant. Sert işaret (puan ≥ 1,8 ve güven ≥ 0,75) ve gri bant (puan ≥ 1,4). Gri bant karar istemez, göz gezdirmek yeter — bulduğumuz tek gerçek sorun tam o banttaydı.
• Hiçbir satırı kendiliğinden kapatmaz. Betik rapor üretir, kesme kararını insan verir. Üçüncü taraf bir model, kataloğumuzu sessizce değiştirmemeli.
• Açıklaması 90 karakterden kısa modeller taranmaz. Sebebi ölçümde çıktı: açıklaması 75 karakter olan bir yönlendirme kaydına model 1,63 risk verdi — elinde bilgi olmayınca isimden çıkarım yapıyor. Bilgi yoksa soru sorulmaz.
• Yalnızca değişen modeller sorgulanır. Açıklama özeti saklanır; haftalık koşuda genelde birkaç model kalır.

İlk canlı koşunun sonucu:

katalog=413  denetlenecek=413  (açıklaması kısa/boş 23 model taranmadı)
bitti: sorgu=413  işaret=0  başarısız=0  token=223.498
       maliyet=$0,0094  süre=249 sn

Sıfır işaret, çünkü tek gerçek sorun koşudan önce kapatılmıştı. Kalan en yüksek puan, tanıdığımız yanlış pozitif: hermes-3-llama-3.1-70b, risk 1,50 — güven 0,45. 413 modelin 405'i 0,50 puanın altında, hiçbiri "roleplay" amacıyla işaretlenmedi. Tüm kataloğu denetlemenin haftalık maliyeti bir sentin altında.

Hangi İş Hangi Yönteme

Ölçümün sonunda kendi kullandığımız ayrım şu:

Durum	Yöntem	Neden
Dar soru, yüksek hacim, eşik/sıralama gerekiyor	Tipli karar modeli	Kalibre olasılık, ara değerler, karar başına maliyet iki basamak düşük
Karar + kullanıcıya gidecek metin birlikte	Sohbet modeli	Tipli model metin üretmez; iki çağrıya bölmek yerine tek çağrı
Az sayıda karar, mevcut akışa ek	Sohbet modeli + JSON şema	Yeni bir bağımlılık kurmaya değmez
Belirsizliği ölçüp insana devretmek	Tipli karar modeli	Güven gerçekten hareket eden bir eksen
Açık uçlu üretim, özet, kod	Sohbet modeli	Tipin olmadığı yerde tipli modelin işi yok

Aynı Deseni Onysoft Üzerinde Kurmak

Tipli karar bir ürün değil, bir desen. Onysoft kataloğundaki modellerle bugün kurabilirsiniz; response_format ve tools parametreleri geçiyor:

curl https://api.onysoft.com/v1/chat/completions \
  -H "Authorization: Bearer sk-ony-ANAHTARINIZ" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemini-3.8-flash",
    "temperature": 0,
    "max_tokens": 1200,
    "messages": [
      {"role": "system", "content": "Sadece JSON nesnesi dondur."},
      {"role": "user", "content": "Model: ... Aciklama: ..."}
    ],
    "response_format": {
      "type": "json_schema",
      "json_schema": {
        "name": "siniflandirma",
        "strict": true,
        "schema": {
          "type": "object",
          "properties": {
            "risk": {"type": "number"},
            "amac": {"type": "string", "enum": ["genel","kod","akil","coklu","roleplay"]}
          },
          "required": ["risk","amac"],
          "additionalProperties": false
        }
      }
    }
  }'

Bu ölçümden çıkan üç pratik uyarıyı kurarken hatırlayın: bütçeyi cömert verin (düşünme tokeni görünmez), gövdeyi her zaman ayrıştırın (finish_reason yanıltır) ve şemadan gelen "güven" alanına eşik koymayın — ölçümde o alan 60 kararın hepsinde 0,80-0,99 arasında kaldı.

Kalibre olasılığa gerçekten ihtiyacınız varsa ve tipli bir modeli kendi uygulamanızda değerlendirmek istiyorsanız, kendi sağlayıcı anahtarınızı Onysoft'a tanımlayıp aynı arayüzden kullanabilirsiniz; sözleşme sizinle sağlayıcı arasında kalır. Ayrıntı: tipli karar modelleri yazısı.

Özet

446 model, iki yöntem, aynı üç soru. Sayılarla:

• İsabet aynı: 14/15. Fark isabette değil.
• Maliyet 72 kat (1.000 karar için $0,0275 / $1,99), gecikme medyanda 4 kat, p95'te 10 kat.
• Güven ekseni: tipli modelde 25 farklı değer ve 0,22-0,98 aralığı; sohbet modelinde 6 değer ve 0,80-0,99. Şemaya "güven" alanı koymak, güven ölçmek değildir.
• Sohbet modelinde ilk turda 14/60 sessiz kesilme — finish_reason: "stop" diyerek. Tipli modelde 446 istekte 0 ayrıştırma hatası.
• Denetim, kataloğumuzda aktif duran gerçek bir modeli buldu; aynı gün kapatıldı ve kural kalıcı hâle getirildi.

En çok işimize yarayan ders ise tabloda görünmüyor: tipli model soruyu sizin yerinize tasarlamaz. Aynı istekte yanlış sorduğumuz soru 15'te 3, doğru sorduğumuz soru 15'te 14 getirdi. İş, soruyu yazmakta.

Katalogdaki modelleri /models sayfasından inceleyebilir, denemek için ücretsiz hesap oluşturabilirsiniz.