LitJev nedir? En kısa yanıtı şu: Hazır bir Hugging Face Qwen checkpoint’ini, eğitim yapmadan Jev biçiminde karar veren yerel bir API’nin arkasına yerleştiren bağımsız araştırma projesi. Metin üretmek yerine seçeneklerin olasılıklarını döndürüyor. Jev’in herkese açık JSON şemasını izliyor ama TypeSafe’ın resmi modeli, özel ağırlıkları ya da RLCD sistemi değil.
Bu son ayrım küçük puntolu bir dipnot sayılmaz. LitJev’i doğru yere koyan asıl bilgi bu.
LitJev’in yaptığı iş
Zhengxu Yu’nun geliştirdiği LitJev, Qwen modellerinden Jev tarzı yapılandırılmış kararlar almayı deniyor. Uygulama ortak bir state, sorular ve izin verilen seçenekleri gönderiyor; karşılığında serbest metin değil, tip bilgisi taşıyan JSON geliyor.
Ana karar API’si için fine-tune gerekmiyor. Önce uzun bir cevap yazdırıp içinden sonuç ayıklama işi de yok. Modelin output head’indeki skorlar okunuyor, dağılıma çevriliyor, yanıt kod tarafında hazırlanıyor.
LitJev README’sine göre Qwen3.x ailesindeki metin ve vision checkpoint’leri, farklı model boyutlarıyla birlikte destekleniyor. Projenin varsayılan ve en çok test ettiği seçenek Qwen/Qwen3.8-27B. README bu modeli 80 GB belleğe sahip tek bir H100 üzerinde çalıştırdığını söylüyor. Bu yazı için yaptığım bir benchmark değil; projenin verdiği kurulum bilgisi.
Ekran görüntüsü üstünden karar almak isteyenlerin Qwen vision checkpoint’i kullanması gerekiyor. Qwen dışındaki model aileleri içinse güvence verilmiyor. Depoda Playground arayüzü, MMLU-Pro, Doom ve satranç ekran görüntülerine yönelik benchmark modülleri, isteğe bağlı calibration araçları ve deneysel bir System Two endpoint’i de bulunuyor. Yine de LitJev’in esas meselesi daha dar: /v1/systemone üzerinden Qwen skorlarını tipli kararlara çevirmek.
Kodun özgün bölümü Apache-2.0 lisansıyla açık. Uyarlanan jevlike örneklerinde MIT lisansı korunmuş. README ayrıca projenin TypeSafe AI ile bağlantılı ya da şirket tarafından onaylanmış olmadığını açıkça yazıyor. Yöntem, kamuya açık bilgilerden çıkarılmış bir hipoteze dayanıyor; resmi Jev uygulaması değil.
Jev tarafına ilk kez bakıyorsanız TypeSafe Jev System One yazısıyla başlamak daha kolay olabilir. Serinin diğer notları yapay zeka bölümünde duruyor.
Cevap yazmadan karar nasıl çıkıyor?
Süreç state içeriğinin bütün prompt’ların başına eklenmesiyle açılıyor. SGLang backend’i bu ortak bölümü bir kez cache’e alabiliyor. Varsayılan Transformers backend’i ise seçenek satırlarını batch halinde işliyor.
Ardından her soru, seçenekleri düz metin olarak içeren ve Answer: ile biten ayrı bir kalıba giriyor. LitJev her aday seçeneğin kelimelerini modele teacher-forcing yöntemiyle veriyor. Token’ların log-olasılıklarını topluyor, çıkan değeri o seçeneğin skoru sayıyor. Bütün seçeneklere softmax uygulanınca dağılım elde ediliyor. Tipli JSON yanıtı model değil, Python kodu kuruyor.
Varsayılan yöntem A, B, C gibi harfleri değil, doğrudan seçeneklerin kelimelerini puanlıyor. Projeye göre böylece harf token’larının önceden taşıdığı eğilimler aradan çıkarılıyor. Harf kodlarıyla denemek isteyenler için --readout coded seçeneği de bırakılmış.
Aynı istekteki sorular birbirinin yanıtını görmüyor. Ortak state hepsinde var ama ilk sorunun sonucu ikinci soruya sızmıyor. README’ye göre tek istekte en fazla on soru gönderilebiliyor.
Burada kolayca gözden kaçan bir ayrıntı var. Softmax sonucu ekranda 0.85 görünüyorsa, bu tek başına olayın yüzde 85 ihtimalle gerçekleşeceğini kanıtlamaz. LitJev README’si olasılıkların varsayılan olarak kalibre edilmediğini özellikle belirtiyor. Gerçek bir işlem eşik değere bağlanacaksa önce o işe ait örneklerle ölçüm yapmak şart.
API üç soru tipini kullanıyor:
choice, verilen seçenekler arasından tercih ve olasılık dağılımı çıkarıyor.score, tanımlanan ölçek üzerinde skor ve buna ait dağılım veriyor.noul, 0 ile 1 arasında değer döndürüyor.
TypeSafe’ın resmi Jev sözleşmesinde Choice ve Score için confidence alanı da var. Noul adının nereden geldiğini ve üç tipin farkını Choice, Score ve Noul rehberinde ayrıca ele almıştım.
Yerel LitJev ile resmi Jev aynı şey mi?
Hayır. İstek ve yanıt biçimleri benziyor; modeli ve sayısal sonuçları aynı değil. İki tarafta da POST /v1/systemone adresine model, state ve questions gönderiliyor, answers ile usage alınıyor. Uyumlu istemci yazmak için kıymetli olan bölüm burası.
| Ayrıntı | Yerel LitJev | Hosted Jev |
|---|---|---|
| URL | http://127.0.0.1:8000/v1/systemone |
https://api.typesafe.ai/v1/systemone |
| Kimlik doğrulama | Varsayılan yerel kurulumda yok | Authorization: Bearer API_KEY |
model değeri |
litjev veya yüklü checkpoint kimliği |
jev-latest |
| Alttaki model | Kullanıcının yüklediği Qwen checkpoint’i | TypeSafe’ın resmi Jev modeli |
| Olasılıklar | Varsayılan olarak kalibre değil | Resmi Jev davranışı ve confidence sözleşmesi |
TypeSafe belgeleri, Jev’i şirketin System One modeli olarak tanımlıyor. Choice, Score ve Noul sorularına yapılandırılmış yanıt vermesi için RLCD ile eğitildiğini söylüyor. LitJev bu özel eğitimi tekrarlamıyor, TypeSafe ağırlıklarını da içermiyor. Genel amaçlı Qwen checkpoint’ine açık bir readout yöntemi uyguluyor.
Dolayısıyla şema uyumu, jev-latest ile aynı cevabı alma vaadi değil. README de iç yapının, confidence değerlerinin ve performansın resmi Jev ile aynı olmadığını yazıyor. İki sistemde aynı seçeneklere farklı oranlar gelmesi beklenebilir.
Resmi Jev’e OpenRouter, Vercel ve Cloudflare taraflarından ulaşmanın yolları da var. Bunları Jev ekosistemi yazısında toplamıştım. Tercihi belirleyen şey JSON alanlarından çok ihtiyaç: Bir tarafta yerel kontrol ve kodu inceleme imkanı, diğer tarafta resmi model ile yönetilen altyapı.
README’deki yerel kurulum
Bu bölüm için depodaki talimatları okudum; LitJev’i bu yazıyı hazırladığım makinede çalıştırmadım. README’nin hızlı başlangıç adımları şöyle:
git clone https://github.com/zhengxuyu/litjev.git
cd litjev
uv run --locked litjev --model Qwen/Qwen3.8-27BSunucu açıldığında Playground http://127.0.0.1:8000/, karar API’si ise http://127.0.0.1:8000/v1/systemone adresinde çalışıyor. İlk istek sırasında model indirilip belleğe yüklendiği için işlem dakikalar sürebiliyor. README’nin kapsadığı tarihte LitJev henüz PyPI’da yok; kurulum kaynağı GitHub deposu.
Basit bir Choice isteği şu biçimde:
{
"model": "litjev",
"state": "Müşteri yazıyor: siparişim kırık geldi, bugün yenisi lazım.",
"questions": {
"intent": {
"type": "choice",
"instructions": "Müşteri ne istiyor?",
"criteria": {
"refund": "Paranın iadesi",
"replace": "Yenisi",
"info": "Sadece bilgi"
}
},
"escalate": {
"type": "noul",
"instructions": "Bir insan devralmalı mı?"
}
}
}Dönecek oranlar checkpoint’e ve prompt’a göre değişir. Depodaki örnek sayılar da bu yazının ölçümü değil, kullanım biçimini göstermek için verilen değerler.
Transformers varsayılan backend. SGLang için README şu iki komutu veriyor:
uv pip install sglang
uv run litjev --model Qwen/Qwen3.8-27B --backend sglangDonanım ihtiyacını atlamamak gerek. Projenin öne çıkardığı 27B model, H100 80 GB üzerinde denenmiş. Tipik bir dizüstünün GPU’suyla aynı sınıfta değil. Daha küçük Qwen checkpoint’leri başlangıç maliyetini düşürebilir; fakat model küçüldükçe karar kalitesinin aynı kalacağına dair bir iddia yok. Destek başka şey, eşit sonuç başka.
Kullanım alanı ve sınırları
LitJev, yöntemi kurcalamak isteyenler için anlamlı. Prompt kalıbı, seçenek puanlama kodu ve çıkan dağılım yerel ortamda incelenebiliyor. API anahtarı almadan Jev şemasına uygun istemci geliştirilebilir. Uygun GPU varsa internet bağlantısına ihtiyaç duymayan bir laboratuvar kurulabilir; vision checkpoint’iyle ekran görüntüleri de kurum içinde tutulabilir.
Üretimde aranan şey resmi Jev davranışıysa adres değişiyor. TypeSafe’ın RLCD ile eğittiği model, resmi confidence çıktıları, yönetilen servis ve üretim operasyonu gerekiyorsa hosted Jev daha doğrudan seçenek. Yerel kurulum API faturasını kaldırabilir ama model indirme, GPU belleği, servis, izleme ve bakım yükünü işletmeciye bırakır. Ücretsiz ile zahmetsiz aynı kelime değil.
Calibration konusu ayrıca ele alınmalı. LitJev varsayılan dağılımların kalibre olmadığını zaten söylüyor. Bir otomasyonu “olasılık 0.8’i geçince çalıştır” kuralına bağlamadan önce, gerçek örnekler ve gerçek sonuçlarla dağılımın ne söylediğini ölçmek gerekiyor. Ondalık hanenin fazla olması güvenilirliği artırmıyor.
Benim README ve dokümanlardan çıkardığım çerçeve bu kadar: LitJev, Jev’in açık şemasını Qwen üzerinde incelemek için anlaşılır ve denetlenebilir bir deney. TypeSafe’ın özel sisteminin açık kaynak kopyası değil. Projenin değerini abartmadan anlatmanın yolu da bu iki cümleyi yan yana tutmak.
Kaynaklar
- LitJev GitHub deposu ve README: kurulum, çalışma yöntemi, lisans ve proje uyarıları
- TypeSafe AI Introduction: resmi Jev ve System One sözleşmesi
- TypeSafe Jev System One karar modeli
- Jev ekosistemi: OpenRouter, Vercel ve Cloudflare
- Jev primitives: Choice, Score ve Noul
2 yorum