Jev primitives üç tipli soru. TypeSafe’in System One modeli bunları kabul ediyor: Choice (kapalı listeden bir seçenek), Score (sıralı rubrik basamaklarında bir konum), Noul (evet/hayır ifadesinin doğru olma olasılığı). Yapılandırılmış state ile isimli soru haritasını gönderirsiniz. Kodunuzun eşik koyabileceği, sıralayabileceği ya da bir sonraki çağrıya taşıyabileceği tipli cevaplar alırsınız. Serbest metin üretimi yok. Serinin 1. gününde ürün yüzeyi bu kadar.
Dünkü TypeSafe Jev hub yazısı System One’ın neden var olduğunu anlattı. Bugün API’de kalıyorum: soru nasıl tanımlanır, hangi tip ne zaman seçilir, cevapta ne döner, alan yolları nasıl çalışır, paralel spekülatif sorular neden tek-soru-tek-çağrı alışkanlığını yener. Geniş masa için yapay zeka hub’ı açık dursun. Ana kaynak: docs.typesafe.ai/primitives.
⚡ Jev primitives nedir?
TypeSafe’in primitives sayfası net. Soru başına bir ani yargı isteyin. “Bu mesaj aciliyet mi taşıyor?” iyi soru. “Bu mesajı analiz edip en iyi aksiyonu belirle” değil. İkincisi yavaş muhakeme ister. Küçük sorulara bölün. Cevapları kendi kodunuzda birleştirin.
Her sorunun bir ID’si var (sizin anahtarınız, örneğin refund_requested), bir type’ı (choice, score veya noul) ve instructions metni (asıl yargı). Choice ve Score ayrıca criteria alır: Choice için seçenek haritası, Score için sıralı seviye listesi. Noul’da evet/hayırın ne anlama geldiğini netleştiren isteğe bağlı criteria olabilir. ID’ler kodunuz içindir; modele gitmez. ID bariz görünse bile soruyu instructions içinde tam yazın.
🧩 Choice, Score, Noul: ne zaman hangisi?
Choice, sırasız kapalı kümeler için. Bileti bir birime yönlendir. Belge tipini sınıfla. Dili tespit et. Tüm seçenekleri yazın. Liste her girdiyi kapsamayabilir diye other veya none of the above ekleyin.
Score, adlandırabildiğiniz spektrumlar için: hata ciddiyeti, müşteri siniri, beceri düzeyi. Seviyeleri siz tanımlarsınız. Model o çizgi üzerinde bir konum döner. Konum iki etiket arasında da kalabilir.
Noul, olasılığın kendisinin sinyal olduğu temiz evet/hayır için. Mesajda PII var mı? Müşteri iade mi istiyor? Özgeçmişte dağıtık sistemler geçiyor mu? 0.5 Noul, evet ve hayıra eşit olasılık demektir. “Orta seviye beceri” anlamına gelmez. Beceri seviyesi istiyorsanız tanımlı seviyeli Score kullanın. İkili kapı istiyorsanız talimatı keskin yazın.
İki tip de oturuyor gibi görünüyorsa, kodunuzun doğrudan işleyeceğini seçin. Choice switch dallarına gider. Score eşiğe gider. Noul bir if’e gider.
📊 Cevapta ne döner?
Cevaplar da primitive. Verdiğiniz seçeneklere sıkışır. Aynı istekteki diğer sorulardan bağımsızdır.
| Tip | Alanlar | Nasıl okunur |
|---|---|---|
| Choice | choice, probabilities, confidence |
Seçilen seçenek, tam dağılım, sivrilik özeti |
| Score | score, legend, probabilities, confidence |
Seviyelerinizdeki konum (arada kalabilir), legend, dağılım |
| Noul | noul |
[0, 1] aralığında P(evet). 1’e yakın güçlü evet, 0’a yakın güçlü hayır, 0.5 belirsiz. Ayrı confidence alanı yok |
Bu bağımsızlık mimari kazanç. Bir soruyu ekleyip çıkarmak diğerlerini bozmaz. Üretilmiş prozadan etiket kazımak zorunda kalmazsınız.
🧠 State, alan yolları ve paralel fan-out
State çoğu zaman JSON’dur: bilet, sipariş, politika. Soru tek bir parçaya bakıyorsa, talimatta backtick’li nokta ve indeks yolu yazın: `ticket.messages[0].text` veya `order.charges`. Açık yollar modele hangi dilimi yargılayacağını söyler.
Aynı state’i paylaşan her soruyu tek istekte gönderin. Tipleri karıştırın. System One bunları paralel değerlendirir. Ek sorular gecikmeyi neredeyse oynatmaz; maliyet birkaç soru token’idir. TypeSafe’in parallel-questions cookbook’u, 13 soruyu tek çağrıda toplamanın 13 ayrı çağrıya göre yaklaşık 11.5x ucuz ve 9.6x hızlı olduğunu, cevapların aynı kaldığını yazar.
Spekülatif fan-out benim sürekli önerdiğim kalıp. Kodunuzun ihtiyaç duyabileceği her soruyu sorun. Bazı girdilerde işe yaramayanları uygulama mantığında yok sayın. Bilet hata raporu değilse severity Score’unu düşürün. Kod agent’ları tek soru / tek çağrıya bayılır. O alışkanlığa karşı durun. Resmi TypeSafe agent skill’leri de aynı yönde iter.
Aynı istekteki sorular birbirinin gizli bağlamı değildir. Sonraki yargı gerçekten önceki cevaba bağlıysa (daha fazla veri çekmek, state’i yeniden şekillendirmek veya sonraki Choice seçeneklerini seçmek için) kodda ikinci istek açın. Değilse birlikte sorun, ağırlıkları sizde birleştirin.
🛠️ Primitive konuşan SDK’lar ve araçlar
cobanov/awesome-jev içindeki Start here bölümü en kısa dürüst özet: state + tipli sorular, şema-geçer ≠ doğru, kendi verinizde doğrulayın. Primitive’leri saran somut repolar:
- typesafe-sdk-js ve typesafe-sdk-python: resmi istemciler; tipli
Choice,Score,Noulkurucuları ve çıkarılmış cevap tipleri. Python 0.7.0 (18 Eyl 2026) serileştirmeyi Pydantic’e taşıdı. - hunch: Ruby’de olasılıksal kontrol akışı.
Hunch.likely?("fraudulent", given: order)tipli cevaba göre dallanır;possibly?’dendefinitely?’ye kademeli yüklemler var. - zod-jev: yerelde Zod şekil doğrulaması, yanında Jev anlamsal doğrulaması. Önce yapı, sonra yargı.
- jev-axi: kabuktan pick / rate / check / rank / triage / guard için CLI.
- advocaat ve jevclient: veri seti soruları ve async Python için küçük tipli istemciler.
İleriki günler için sağlayıcı notu: Vercel AI Gateway’deki Boolean primitive, TypeSafe Noul’una karşılık gelir. Karşılaştırırken model ID’lerini sabitleyin.
✅ Şema-geçer, doğru demek değildir
Jev şema dışı string üretemez. “Halüsinasyon yok” pazarlama cümlesi budur; The Register kategori oyununu zaten işaret etti. Choice yanlış birimi seçebilir. Score sakin müşteriyi öfkeli sayabilir. Noul yanlış bir iddiada 0.9 olabilir. Sizin işiniz: eşikler, kendi trafiğinizde eval, geri dönüşsüz araçların önünde deterministik kontroller, insan yedek yolu. awesome-jev Start here aynı şeyi söyler. Yarın confidence ve RLCD’ye ineriz. Şimdilik: primitives temiz bir arayüzdür, denetim mührü değildir.
