Jev nedir? TypeSafe'in tarayıcı ajanları için seçime dayalı karar modeli

Jev ve TypeSafe nedir?

Jev, TypeSafe adlı şirketin "System One" adını verdiği model ailesinin öne çıkan üyesidir. Modelin işi serbest metin üretmek değildir; bir listeden seçim yapmak (Choice), bir durumu bir rubriğe göre puanlamak (Score) veya bir ifadenin doğruluğunu 0 ile 1 arasında değerlendirmektir (Noul). Şirketin kendi tanıtım sayfası bunu "Ask Jev, up to a million times" cümlesiyle özetler.

Tasarımın can alıcı noktası paralelliktir: bir istekteki tüm sorular aynı duruma karşı, birbirinden bağımsız ve tek seferde değerlendirilir. TypeSafe'in dokümantasyonuna göre bir soru eklemek yanıt süresini neredeyse hiç etkilemez, çünkü sorular izole ve paralel işlenir. Önerilen tasarım felsefesi, karmaşık bir kararı büyük tek bir soruya sıkıştırmak yerine küçük, net sınırlı sorulara bölüp sonucu kod tarafında birleştirmektir.

• Kaynak: TypeSafe dokümantasyonu (kontrol 17 Eylül 2026)
• Kaynak: askjev.ai (kontrol 17 Eylül 2026)

Tarayıcı ajanlarının alışılmış yavaşlığı

Yaygın bir ajan mimarisinde önce ekran görüntüsü alınır, görsel bir modele gönderilir, model serbest metinle "şu koordinata tıkla" der ve kod bu metni ayrıştırıp yürütür. Bu döngünün her adımı görsel işleme, serbest metin üretme ve ayrıştırma maliyeti taşır; adım sayısı arttıkça tarayıcıyla kurulan düşük seviyeli protokol çağrısı sayısı da katlanarak büyür.

jev-ultrafast'ın kendi ölçümünde bu daha eski yaklaşım aynı görevi tamamlamak için medyan 1.092 tarayıcı protokol çağrısına ihtiyaç duymuştur. Sorun tek bir yavaş adım değildir; her adımın taşıdığı sabit maliyetin toplamıdır.

jev-ultrafast: karar ve metin üretimini ayırmak

jev-ultrafast, Browser Use ile TypeSafe'in birlikte yayımladığı, MIT lisanslı açık kaynak bir demodur. Her sayfa gözleminde görünür kontrollerden (buton, açılır kutu, metin alanı) indeksli bir tablo çıkarılır. Tek bir Jev isteği hangi işlemin (CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, BLOCKED) yapılacağını ve o işlemle uyumlu her hedef için adayı aynı anda sorar; yürütücü yalnızca seçilen işlemin hedef cevabını kullanır.

Yani işlem ve hedef kararı seri iki çağrı yerine tek bir ağ gidiş-dönüşünde alınır. Gerçek bir metin üreten dil modeli yalnızca TYPE_TEXT işlemi seçildiğinde devreye girer; o da yalnızca seçilen alana yazılacak metni üretir, işlem veya hedef kararını vermez. Tarayıcı bağlantısı ayrı bir açık kaynak bileşen olan Browser Harness üzerinden kurulur.

Kaynağında ölçülen hız farkı

Aşağıdaki tablo jev-ultrafast'ın kendi ölçüm dosyasından alınmıştır; LLMTR tarafından bağımsız olarak tekrar üretilmemiştir. Kaynağın kendisi de bunun genel bir güvenilirlik testi olmadığını, tek bir görevin tek bir tarayıcı profilinde birkaç kez tekrarı olduğunu açıkça belirtir.

• Kaynak: jev-ultrafast ölçüm dosyası (kontrol 17 Eylül 2026)

Sınırları ve doğrulama gerekliliği

DONE seçimi görevin gerçekten tamamlandığının kanıtı değildir; kaynağın kendi rehberi bile bağımsız bir doğrulama adımı önerir. Kapsam da sınırlıdır: shadow DOM, iframe, canvas, dosya yükleme, açılır pencere ve iç içe kaydırma bu ilk sürümün dışında bırakılmıştır.

İki örnek sitede (Google Flights, Wikipedia) çalışması genel bir güvenilirlik kanıtı değildir; kaynağın kendisi de politikanın genel olduğunu ama iki sitenin geniş güvenilirlik anlamına gelmediğini yazar. Geçerli bir işlem seçimi bile yine de yanlış olabilir.

Bu mimari neden şimdi konuşuluyor

Tarayıcıyı kontrol edebilen yapay zekâ ajanları farklı sağlayıcılarda ve açık kaynak projelerinde hızla yaygınlaşıyor; hepsi aynı ödünleşimi paylaşıyor: her adımda ne kadar görsel işleme ve serbest metin üretimi gerekir, bunun karşılığında gecikme ve maliyet ne olur. jev-ultrafast, karar üretimini seçime indirgeyip serbest metin üretimini yalnızca gerçekten gerekli olduğu tek ana (bir alana yazılacak değer) sıkıştırarak bu ödünleşime somut bir yanıt öneriyor.

Bu ayrım aynı zamanda pratik bir sonuç doğuruyor: metin üretme adımı, karar motorundan bağımsız, sıradan bir OpenAI uyumlu istek haline geliyor. Bu da onu, kararları farklı bir sistem veren mimarilere de taşınabilir kılıyor.

Tarayici ajani disinda: kodunuzda nerede ise yarar

Jev'in yaptigi is tarayici ajanina ozgu degil. Kodunuzda "bunu bir dil modeline sorsam iyi olurdu ama cevabini ayristirmak zorunda kalacagim" dediginiz her yer ayni kaliba giriyor: karari tipli bir soruya cevirin, esigi kodda tutun.

Asagidaki tablo ayni deseni dort farkli iste gosteriyor. Ortak nokta son kolon: karari model vermiyor, kararin girdisini veriyor.

Tek istek, dort soru, esikler kodda

Asagidaki fonksiyon bir destek kaydini tek istekte dort soruyla degerlendiriyor. Dikkat edilecek uc sey var.

Birincisi: sorular tek istekte gidiyor. Ayni istekteki sorular paralel ve birbirinden bagimsiz degerlendirildigi icin soru eklemek yanit suresini belirgin bicimde uzatmiyor, yalnizca o sorunun tokenlarini ekliyor. Bu yuzden iade sorusu her kayitta sorulabilir; yalnizca faturalama kayitlarinda ise yarasa da ikinci bir gidis-donusten ucuzdur.

Ikincisi: yuksek oncelik tanimi kodda. Model olasilik dondurur, esigi ve agirligi siz koyarsiniz; ekip oncelik tanimini degistirdiginde bir katsayi degisir, prompt yeniden yazilmaz.

Ucuncusu: dagilim tepe yapmadiginda karar insana devrediliyor. confidence alani tam bunun icin var, otomatik davranmakla bir kisiye sormak arasindaki cizgiyi cizmek icin.

Destek kaydi triyaji, tek istek

import os, requests

QUESTIONS = {
    "departman": {
        "type": "choice",
        "instructions": "Bu talebi hangi ekip karsilamali?",
        "criteria": {
            "faturalama": "Odeme, fatura, iade",
            "teknik": "Hata, kesinti, entegrasyon",
            "satis": "Fiyatlandirma, hesap acma",
            "diger": None,
        },
    },
    "acil": {
        "type": "noul",
        "instructions": "Mesaj zaman baskisi bildiriyor mu?",
    },
    "memnuniyetsizlik": {
        "type": "score",
        "instructions": "Musteri ne kadar rahatsiz gorunuyor?",
        "criteria": ["Sakin", "Rahatsiz ama nazik", "Cok ofkeli"],
    },
    # Yalnizca faturalama kaydinda ise yarar; yine de ayni istekte sorulur.
    "iade_talebi": {
        "type": "noul",
        "instructions": "Musteri para iadesi istiyor mu?",
    },
}


def triage(ticket: str) -> dict:
    res = requests.post(
        f"{os.environ['LLMTR_BASE_URL']}/v1/systemone",
        headers={"Authorization": f"Bearer {os.environ['LLMTR_API_KEY']}"},
        json={"model": "typesafe/jev", "state": ticket, "questions": QUESTIONS},
    )
    res.raise_for_status()
    a = res.json()["answers"]

    # Esikler ve agirliklar TEK yerde. Model yalnizca olasilik dondurur;
    # "yuksek oncelik" tanimi sizin kodunuzda yasar ve bir katsayi
    # degistirilerek revize edilir.
    oncelik = 2 * a["acil"]["noul"] + a["memnuniyetsizlik"]["score"] / 2

    return {
        "kuyruk": a["departman"]["choice"],
        "oncelik": "yuksek" if oncelik > 1.5 else "normal",
        # Dagilim tepe yapmadiysa karari insana birak.
        "insana_devret": a["departman"]["confidence"] < 0.7,
        "iade_akisi": a["iade_talebi"]["noul"] > 0.8,
    }

Ne zaman uygun degil

Serbest metne ihtiyaciniz varsa bu model o isi yapmaz: ozet, yanit taslagi veya aciklama uretmek icin sohbet modeli gerekir. Iki isi ayni akista birlestirmek de normaldir; karari Jev'e, metni bir sohbet modeline verirsiniz.

Uzun akil yurutme gerektiren ya da birden fazla bagimsiz etkeni tartan bir yargiyi tek soruya sigdirmaya calismayin; parcalayin ve cevaplari kodda birlestirin. Bir girisim sunumunu tek soruda puanlamak yerine pazar buyuklugu, teknik uygulanabilirlik ve farklilasmayi ayri ayri sorup kendi formulunuzle toplamak hem daha guvenilir hem de sonradan revize edilebilir.

Kararin gerekcesini metin olarak gormeniz gerekiyorsa da uygun degil: geri donen sey olasilik dagilimidir, aciklama degil. Dagilim cogu zaman gerekceden daha kullanisli bir sinyaldir, ama ayni sey degildir.

LLMTR bu mimaride nereye oturur

LLMTR bu mimarinin iki ayrı adımını da karşılayabilir. TYPE_TEXT işleminde çağrılan küçük dil modeli standart bir OpenAI uyumlu chat completions isteğidir; bu da tam olarak LLMTR'nin sunduğu uç nokta şeklidir.

Karar adımı için de bir seçenek vardır: Jev, LLMTR kataloğunda `typesafe/jev` kimliğiyle yer alır ve `/v1/systemone` uç noktasında yanıt verir. Aynı `state` ve `questions` gövdesi, aynı yanıt biçimi; değişen tek şey isteği hangi adrese ve hangi anahtarla gönderdiğinizdir. İstek ve yanıt alanlarının tamamı için aşağıda bağlantısı verilen Yapılandırılmış Kararlar dokümanına bakın.

İki adımı birbirinden bağımsız taşıyabilirsiniz: yalnızca metin üretme adımını, yalnızca karar adımını ya da ikisini birden. Ortam değişkeni değişikliklerini, gerçek istek şeklini ve dikkat edilmesi gereken noktaları serinin entegrasyon yazısında adım adım bulabilirsiniz.

Sık sorulan sorular

Jev nedir?

Jev, TypeSafe şirketinin "System One" model ailesindeki öne çıkan üyedir. Serbest metin yerine seçim, puanlama ve doğruluk değerlendirmesi gibi yapılandırılmış kararlar üretir; tüm sorular bir istekte paralel ve izole olarak değerlendirilir.

jev-ultrafast LLMTR'nin bir ürünü mü?

Hayır. jev-ultrafast, Browser Use ile TypeSafe'e ait, MIT lisanslı açık kaynak bir demodur. LLMTR bu projenin sahibi veya işletmecisi değildir; bu yazı yalnızca mimarisini ve LLMTR ile nerede kesiştiğini inceler.

Bu yazıdaki hız ölçümlerini LLMTR mi yaptı?

Hayır. Rakamlar jev-ultrafast deposunun kendi ölçüm dosyasından alınmıştır ve kaynağın kendisi bunun genel bir güvenilirlik testi olmadığını belirtir. LLMTR bu ölçümleri bağımsız olarak tekrar üretmemiştir.

Jev'in karar API'sini LLMTR üzerinden çağırabilir miyim?

Evet. Jev, LLMTR kataloğunda `typesafe/jev` kimliğiyle yer alır ve `/v1/systemone` uç noktasında yanıt verir; istek ve yanıt gövdesi TypeSafe'in kendi biçimiyle aynıdır. Bu yazı ilk yayımlandığında durum böyle değildi, sonradan eklendi. LLMTR aynı zamanda mimarinin metin üretme adımına (TYPE_TEXT) da uygundur.

Bu mimariyi kullanmak için jev-ultrafast'a ihtiyacım var mı?

Hayır. Kararları yapılandırılmış bir seçim API'sine, metin üretimini ise ayrı ve dar bir LLM çağrısına ayırmak jev-ultrafast'a özgü değildir; kendi ajan mimarinizde aynı ayrımı kurup metin üretme adımını LLMTR'ye yönlendirebilirsiniz.

İlgili yazılar

• jev-ultrafast'ın metin üretme adımını LLMTR ile çalıştırma
• AI agent API mimarisi: tool calling, güvenlik ve LLM gateway
• MCP nedir? LLM API ve AI agent entegrasyonu için rehber
• Leyla: Türkiye'de barındırılan ilk System One karar modeli
• Metin sınıflandırma modeli seçimi: Leyla, Leyla English ve Leyla Typed Decisions

• Model kataloğu
• Yapılandırılmış Kararlar dokümanı
• Chat Completions dokümanı
• Fiyatlandırma