Jev: LLM'lerin Yerine Değil, Yazılımın İçine Giren Karar Modeli

Jev: LLM'lerin Yerine Değil, Yazılımın İçine Giren Karar Modeli

Jev, TypeSafe AI tarafından 15 Eylül 2026'da erken erişime açılan yeni bir yapay zekâ modeli. Fakat Jev'i anlamak için onu ChatGPT, Claude veya başka bir sohbet modeliyle aynı yarışa koymak yanlış başlangıç olur. Jev metin üretmiyor. Bir uygulamanın durumunu, soruları ve mümkün cevapları alıp yapılandırılmış kararlar ile olasılık dağılımları döndürüyor.

Bu ayrım küçük görünse de üretim sistemlerinde ciddi bir probleme dokunuyor. Bir LLM'den “bu destek talebi teknik ekibe mi gitmeli?” diye sorup JSON beklediğimizde model önce metin üretir, sonra uygulama bu metni ayrıştırır, doğrular ve iş akışına sokar. Araya biçim hataları, anlamsız alanlar ve güvenilir olmayan “%92 eminim” cümleleri girer. Jev'in iddiası, bu aradaki metin katmanını kaldırıp yazılıma doğrudan karar sağlayabilmek.

TypeSafe'in kendi değerlendirmelerini, LangChain entegrasyonunu, bağımsız incelemeleri ve topluluk deneylerini birlikte okuyunca ortaya şu resim çıkıyor: Jev, genel amaçlı LLM'lerin rakibi değil. Daha çok LLM çağrılarından önce veya sonra çalışan, sık tekrarlanan anlamsal kararlar için tasarlanmış yeni bir katman.

Jev tam olarak ne yapıyor?

TypeSafe bu yaklaşımı System One modeli olarak adlandırıyor. İsim, Daniel Kahneman'ın hızlı ve sezgisel System 1 düşüncesine gönderme yapıyor. Buradaki fikir, uzun cevaplar yazan bir yardımcı yerine birkaç yüz milisaniyede bir yazılım bileşeninin kullanabileceği yargılar üretmek.

Temel akış basit:

durum + sorular + izin verilen cevaplar
                  ↓
                Jev
                  ↓
tip güvenli cevaplar + olasılıklar + güven bilgisi
                  ↓
              uygulama kodu

Durum (state) bir müşteri mesajı, ödeme işlemi, JSON nesnesi, oyun durumu veya bir ajanın ürettiği sonuç olabilir. Sorular (questions) ise modelin bu durum hakkında cevaplamasını istediğiniz küçük kararlar. Cevapların biçimi önceden belirlenir, fakat sınıfların anlamını uygulama geliştiricisi tanımlar.

Dokümantasyonda üç temel soru tipi bulunuyor. Noul bir önermenin doğru olma olasılığını döndürüyor. Choice verilen seçenekler arasından seçim yapıyor ve her seçenek için olasılık sağlıyor. Score ise bir durumu sıralı bir ölçek üzerinde puanlıyor. Örneğin düşük, orta ve yüksek aciliyet.

Tek çağrıda bu soru tipleri karıştırılabiliyor. Aynı destek talebi için “hangi ekip?”, “acil mi?” ve “müşteri ne kadar öfkeli?” sorularını birlikte sorabiliyorsunuz. Jev bu soruları paralel ve birbirinden izole değerlendirmeyi hedefliyor.

Fintech örneği: Dolandırıcılık kararında Jev nerede durur?

Fintech tarafında bir işlemi şu bilgilerle ele alalım: tutar, para birimi, gönderen ve alıcı ülke, işlem kanalı, cihaz bilgisi, hesabın yaşı ve önceki işlem örüntüleri. Jev'e doğrudan “bu işlem dolandırıcılık mı?” diye sorabilirsiniz. Fakat burada önemli bir mühendislik ayrımı var.

Elinizde binlerce etiketli işlem ve güçlü özellikler varsa XGBoost, lojistik regresyon veya özel bir sinir ağı çoğu zaman daha uygun ve daha ucuz olabilir. Jev, denetimli tabular fraud modelinin otomatik alternatifi değil. Özellikle sayısal örüntüler, zaman serileri ve şirketin kendi geçmiş verisi belirleyiciyse klasik makine öğrenmesi modellerini çöpe atmak için sebep yok.

Jev'in değeri, kuralların ve etiketli verinin yetersiz kaldığı anlamsal katmanda ortaya çıkabilir. İşlem açıklamasının şüpheli bir sosyal mühendislik kalıbı içerip içermediği, bir alıcının riskli bir bağlamla ilişkilendirilip ilişkilendirilemeyeceği veya manuel inceleme gerekip gerekmediği gibi sorular ayrı ayrı sorulabilir. Kod da sonuçları birleştirir:

risk_questions = {
    "suspicious_context": ...,   # Noul
    "review_required": ...,      # Noul
    "risk_band": ...             # Score
}

# Modelin kararı tek başına para hareketi başlatmaz.
# Eşikler, limitler ve insan incelemesi kodda kalır.

Bu tasarım daha denetlenebilir. Jev “yüksek risk” diyebilir, fakat işlemi durdurma, müşteriden ek doğrulama isteme veya analiste gönderme kararını uygulama kodu verir. Modelin olasılığı, politikanın yerine geçmez; politikaya veri sağlar.

Metin üretmek yerine doğrudan olasılık üretmek

Bir LLM'in “bu talep teknik ekibe gitmeli, güvenim yüzde 85” demesi ile Jev'in teknik seçeneğine 0,85 olasılık vermesi aynı şey değil. İlkinde sayı da diğer kelimeler gibi üretilmiş bir metin parçası. İkincisinde sayı, modelin karar dağılımının parçası olarak API'den dönüyor.

Jev'in hız iddiasının merkezinde bu fark var. Geleneksel bir LLM, cevabı token token üretir. “technical” kelimesi, JSON anahtarları, noktalama işaretleri ve açıklama metni sırayla yazılır. Yapılandırılmış çıktı kullansanız bile modelin metin üretimini bir şema içine sıkıştırmaya çalışırsınız.

Jev'in açıkladığı yaklaşımda soru seçenekleri bellidir ve çıktı için yeni bir cümle kurmak gerekmez. Modelin son temsili, izin verilen cevaplara ait olasılıklara okunur. Bu yüzden bütün sorular aynı çağrıda değerlendirilebilir. JSON serileştirme ve anahtarların yazılması uygulama katmanında yapılır.

Archer Hume'un bağımsız mimari incelemesi bu fikri daha ileri götürüyor. API davranışlarından hareketle Jev'in ortak durumu bir kez kodlayıp her soruyu ayrı bir dalda değerlendiren, doğrudan sayısal okuma yapan nedensel bir transformer'a benzeyebileceğini öne sürüyor. Ortak ön ekin ve soru dallarının nasıl paylaşıldığına dair gözlemler ilginç, fakat yazar da bunun kara kutu API üzerinden yapılmış bir yeniden kurma olduğunu açıkça belirtiyor.

Yani bugün güvenle söyleyebileceğimiz şeyler ile tahminleri ayırmak gerekiyor. TypeSafe, paralel çıktı, typed sorular ve RLCD eğitim yaklaşımını açıklıyor. Tam katman yapısını, parametre sayısını veya Jev'in gerçekten seyrek Uzmanlar Karışımı (Mixture of Experts) kullanıp kullanmadığını açıklamıyor. “Jev kesin olarak şu mimariyi kullanıyor” demek için erken.

“Halüsinasyon yapamaz” cümlesi ne kadar doğru?

TypeSafe'in pazarlama cümlesi teknik olarak dar bir anlamda doğru: Jev, önceden tanımlanan tiplerin ve seçeneklerin dışına çıkamaz. “billing”, “technical” veya “sales” seçenekleri verdiyseniz model dördüncü bir anahtar uyduramaz. Bir araç çağrısının adını, parametresini veya JSON yapısını yanlış biçimde yazamaz.

Fakat bu, anlamsal olarak doğru karar vereceği anlamına gelmiyor. Jev izin verilen seçeneklerden birini seçip yine de yanlış seçim yapabilir. Bir dolandırıcılık işlemini güvenli, güvenli işlemi riskli veya teknik bir talebi satış olarak sınıflandırabilir. The Register de bu ayrımı vurguluyor: model doğal dilde uydurma kaynaklar üretmeyecek, fakat bu onun yanlış yargı üretemeyeceği anlamına gelmiyor.

Bu nedenle Jev'in asıl önemli vaadi “sıfır halüsinasyon” değil, kalibrasyon. Bir model benzer örneklerde 0,90 olasılık veriyorsa bu grubun yaklaşık yüzde 90'ında doğru olması beklenir. Bu ilişkiyi kendi veriniz üzerinde ölçmeden güven skorunu otomatik işlem izni gibi kullanamazsınız. Üstelik aynı sorunun farklı sektörlerde, dillerde ve veri kalitesinde kalibrasyonu değişebilir.

Pratikte güvenli desen şuna benziyor: yüksek güven ve düşük maliyetli hata varsa otomatik ilerle, orta bölgede ek bilgi iste, düşük güvende insan incelemesine yönlendir. Yanlış kararın bedeli yükseldikçe eşik de yükselmeli. Kredi, ödeme, sağlık veya güvenlik kararlarında Jev tek başına son merci olmamalı.

Hız ve maliyet: Etkileyici rakamlar, fakat karşılaştırmayı doğru yapmak gerek

TypeSafe, Jev için milyon giriş token'ı başına 0,042 dolar ücret ve çıktı token'ı için sıfır ücret açıklıyor. Şirket kendi workflow değerlendirmelerinde 70 ile 500 milisaniye arası uçtan uca süreler ve bazı iş yüklerinde 193,6 kata kadar hız, 444,6 kata kadar maliyet farkı bildiriyor. Bu rakamlar şirketin seçtiği iş akışları, kendi servis konumu ve referans model kurulumlarıyla ölçülmüş sonuçlar.

Bu ayrıntı önemli. TypeSafe, LLM karşılaştırmalarında GPT-6 Astra ve Fable 5.1 modellerinin ortalama tahminlerini referans aldığını, LLM'leri kendi System One uyumluluk katmanıyla yapılandırılmış cevap vermeye zorladığını söylüyor. Bu, Jev'in gerçek üretim avantajını göstermeye çalışıyor, fakat yine de tamamen bağımsız bir laboratuvar testi değil.

Bağımsız küçük deneyler daha dengeli bir tablo sunuyor. Every'den Mike Taylor, 37 metin üzerinde 21 soruyu aynı anda çalıştırıp 777 yargıyı 0,7 saniyeden kısa sürede ve çeyrek sentten daha düşük tahmini maliyetle aldığını yazdı. Başka bir testte Jev, 12 yapay pasajdaki yedi kusurun altısını yakalarken Fable 5.1 yedisini de yakaladı. Jev'in medyan süresi 0,35 saniye, Fable'ın yüksek çaba modunda süresi 8,83 saniyeydi.

Bu sonuçların anlamı “Jev her işte daha iyi” değil. Daha doğru cümle şu: Aynı anlamsal kontrolü yüzlerce veya binlerce kez yapmanız gereken bir işte, metin üretmeyen ve soruları paralel değerlendiren bir modelin ekonomik avantajı çok büyük olabilir. Üretim ortamında p95 gecikme, yoğunluk altında süre, veri aktarımı, hata oranı, insan incelemesi ve yanlış karar maliyeti birlikte ölçülmeli.

Jev ile neler yapılabilir?

1. Destek taleplerini yönlendirme

Bir talebi faturalandırma, teknik destek veya satış ekiplerinden birine göndermek için ayrı bir Choice sorusu kullanılabilir. Aynı çağrıda aciliyet, öfke seviyesi ve müşteri kaybı riski de ölçülebilir. Son yanıtı yazmayı ise sohbet LLM'i yapar. Böylece hızlı karar ile doğal dil üretimi aynı sistemde farklı katmanlara ayrılır.

2. Ajan güvenlik katmanı

Bir kodlama veya tarayıcı ajanı her araç çağrısından önce “bu komut geri döndürülemez bir işlem mi?”, “üretim verisine dokunuyor mu?” ve “kullanıcının açık izni var mı?” gibi sorular sorabilir. LangChain'in Jev yazısı, model yönlendirme ve riskli araç çağrılarını engelleyen Auto Mode middleware örneklerini bu nedenle öne çıkarıyor.

3. Arama, sıralama ve bağlam seçimi

Bir ajanın binlerce belge arasından hangilerini okuyacağı, hangi aracın çağrılacağı veya hangi sonuçların üst sıralara çıkacağı Jev ile puanlanabilir. LangChain tarafındaki öneri, güçlü LLM'i tamamen kaldırmak değil, onu yalnızca gerçekten gerektiğinde çağırmak. Jev hızlı bir filtre ve yönlendirici, LLM ise daha yavaş ama açık uçlu düşünme katmanı olur.

4. Gerçek zamanlı sistemler

TypeSafe'in Doom demosunda model görüntü piksellerini doğrudan okumuyor. Oyun durumu yapılandırılmış veri ve metin olarak modele veriliyor, Jev de mümkün hareketler arasından seçim yapıyor. Bu ayrıntı demoyu küçültmez, ama neyi kanıtladığını doğru anlatır: düşük gecikmeli yapılandırılmış durumdan eylem seçimi. Robotik ve tarayıcı ajanları için de benzer bir ara katman düşünülebilir. Kritik fiziksel kontrol döngüsü yine deterministik kodda veya özel kontrol modellerinde kalmalı.

Jev, LLM, klasik makine öğrenmesi ve encoder modelleri

Jev'i doğru yere koymak için dört yaklaşımı ayırmak gerekiyor.

• Genel amaçlı LLM: Açıklama, kod, plan, özet ve açık uçlu üretim için güçlü. Karar verirken metin üretir, yapılandırılmış cevap için ek şema ve doğrulama katmanı ister.
• Jev: Önceden tanımlanmış seçenekler, skorlar ve önermeler üzerinde hızlı, tip güvenli ve olasılıklı kararlar için tasarlanmış. Metin yazamaz, sınırsız JSON üretemez, kendi başına plan anlatamaz.
• Klasik denetimli model: Yeterli etiketli veri ve sabit özellikler varsa fraud, churn, kredi riski veya tahmin işlerinde daha iyi bir üretim seçeneği olabilir. Jev'in avantajı, sıfır veya az örnekle anlamsal kriterleri hızlı denemek ve farklı soruları yeniden eğitim olmadan tanımlayabilmek olabilir.
• Encoder ve zero-shot sınıflandırıcı: Metin sınıflandırmada zaten güçlü bir geçmişe sahip. GLiClass gibi açık kaynak projeler, seçenekler üzerinde doğrudan sınıflandırma yapılabildiğini gösteriyor. Jev'in farkı, geniş bir modelin bilgisiyle birlikte API düzeyinde soru tiplerini, paralel fan-out'u ve kalibre olasılık hedefini bir ürün olarak sunması olabilir.

Bu karşılaştırma Jev'in yeni hiçbir şey yapmadığı anlamına gelmez. Daha çok uzun süredir ayrı ayrı bulunan fikirleri tek bir geliştirici arayüzünde birleştirme iddiası var: doğal dille tarif edilen kriterler, seçeneklerden bağımsız soru yapısı, çoklu paralel değerlendirme ve yazılımın kullanabileceği olasılıklar. Bunun ne kadar iyi çalıştığı, bağımsız benchmark'lar ve gerçek müşteri verileriyle belli olacak.

Asıl fikir: LLM'den önce çalışan karar katmanı

Bence Jev'in en ilginç tarafı yeni bir sohbet deneyimi sunması değil. Yazılım mimarisinde LLM'lerin bugün üstlendiği küçük kararları ayırması. Bir ajan her adımda hangi aracı seçiyor, kullanıcıdan onay istemeli mi, yanıtı yeniden kontrol etmeli mi, hangi modeli çağırmalı, hangi belgeyi bağlama eklemeli? Bu soruların her biri bazen tek satırlık bir if-ifadesi kadar küçük, fakat semantik olduğu için klasik kurallarla yazması zor.

Bugün bu kararlar için çoğu ekip büyük bir LLM çağırıyor. Model bir paragraf yazıyor, uygulama JSON'u parse ediyor, bir hata durumunu yönetiyor ve sonra sonraki adıma geçiyor. Jev benzeri modeller bu döngüdeki tekrarlı mikro kararları üstlenebilirse büyük LLM sadece planlama, açıklama ve açık uçlu üretim için çağrılır.

Bu mimari şuna benzeyebilir:

kullanıcı isteği
      ↓
Jev: niyet, risk, model ve araç seçimi
      ↓
LLM: planlama veya metin üretimi
      ↓
Jev: çıktı ve araç çağrısı kontrolü
      ↓
kod: politika, eşikler ve yan etkiler

Bu yalnızca bir tahmin. Jev henüz erken erişimde ve TypeSafe'in güçlü performans sonuçlarının önemli bölümü şirketin kendi testlerinden geliyor. Ayrıca fiyatın yoğun üretim altında sürdürülebilirliği, farklı dillerde kalibrasyon, uzun bağlam davranışı ve yanlış kararların gerçek maliyeti henüz yeterince görünür değil.

Bugün denemek isteyen ekipler neyi ölçmeli?

Jev'i bir demoda hızlı görmek kolay. Üretim kararını vermek için daha disiplinli bir test gerekir.

1. Gerçek iş akışından etiketli bir test seti çıkarın. Sadece modelin kendi örneklerini kullanmayın.
2. Her büyük soruyu küçük atomik sorulara ayırın. “Bu talebi değerlendir” yerine aciliyet, ekip, risk ve izin gibi ayrı sorular yazın.
3. Olasılık kalibrasyonunu ölçün. 0,8 güven verilen örneklerin gerçekten ne kadarında doğru karar çıktığına bakın.
4. Belirsizlik politikasını kodlayın. Hangi eşikte otomasyon, hangi aralıkta ek soru, hangi durumda insan incelemesi var?
5. LLM, klasik ML ve Jev'i aynı veri üzerinde karşılaştırın. Sadece ortalama gecikmeye değil p95, hata maliyetine ve bakım yüküne bakın.
6. Yanlış pozitif ve yanlış negatif maliyetlerini ayırın. Özellikle ödeme ve güvenlikte tek bir doğruluk sayısı yeterli değil.

Topluluğun hazırladığı Awesome TypeSafe listesi resmi dokümantasyonun yanında tarayıcı ajanları, oyunlar, robotik denemeleri ve bağımsız benchmark'ları da topluyor. Bunları fikir bulmak için kullanmak iyi, fakat topluluk projesindeki tekil sonuçları üretim kanıtı gibi okumamak gerekiyor.

Sonuç: Her yapay zekâ özelliği chatbot olmak zorunda değil

Jev, sohbet modellerinin bittiğini veya her uygulamanın bundan sonra Jev kullanması gerektiğini göstermiyor. Daha dar ve daha pratik bir şey öneriyor: yazılımın sürekli sorduğu anlamsal soruları, metin üretimi yerine doğrudan olasılıklı kararlara çevirmek.

TypeSafe'in “halüsinasyon yapamaz” söylemini anlamsal doğruluk garantisi olarak değil, tip ve biçim garantisi olarak okumak gerekiyor. Model yine yanılabilir. Fakat seçenekleri, olasılıkları ve belirsizlik eşiklerini kodun içine koyduğunuzda sistemin davranışını denetlemek daha kolay hale geliyor.

Benim tahminim, Jev benzeri modellerin LLM'lerden önce çalışan bir katman olarak yaygınlaşacağı yönünde. Sınıflandırma, yönlendirme, sıralama, politika kontrolü, ajan ve araç seçimi gibi küçük ama sık yapılan işleri üstlenebilirler. Büyük model ise gerektiğinde devreye girer. Bu yaklaşım hız, maliyet ve güvenilirlik arasında daha dengeli bir mimari kurabilir.

Kesin hüküm vermek için erken. Fakat fikir önemli: Yapay zekânın her yerde konuşması gerekmiyor. Bazen uygulamanın ihtiyacı yalnızca hızlı, ucuz, sınırları belli ve olasılığı ölçülebilen bir karardır. Geleceğin akıllı yazılımları belki de daha az konuşup daha çok doğru yerde dallanacak.

Jev'i denediyseniz hangi kararı çözdüğünü ve nerede zorlandığını paylaşın. Özellikle gerçek veri üzerindeki kalibrasyon sonuçları, bu model sınıfının reklamdan üretim aracına dönüşüp dönüşmeyeceğini gösterecek.

Kaynaklar

• TypeSafe AI, Introducing System One Models & Jev
• TypeSafe AI dokümantasyonu
• Archer Hume, Jev's Architecture Unmasked
• LangChain, Building a Harness with Jev
• The Register, TypeSafe AI debuts model for machines that plays Doom
• Every, Mini-Vibe Check: TypeSafe's Jev Judged Everything in 0.7 Seconds
• Vercel AI Gateway duyurusu
• TypeSafe workflow değerlendirmeleri