LLM yönlendirme ve koruma bariyerleri nasıl yapılır? Jev ile büyük dil modelleri arasındaki işbirliği örneği

Çıkar ve kanıt açıklaması: PandaNpc, Jev kullanan Agent karar katmanını geliştiriyor. Aşağıda sırasıyla TypeSafe resmi dokümantasyonuna, resmi cookbook'a ve depomuzdaki gerçek Jev çağrıları ile sentetik senaryo kalibrasyonuna atıf yapılmıştır. Kalibrasyonumuz betikleştirilmiş sahte LLM sağlayıcısı kullanır; gerçek kullanıcı trafiğini veya tam üretim hattı performansını temsil edemez.

LLM yönlendirme şöyle yapılabilir: önce Jev isteğin hangi kategoriye girdiğini ve riskinin ne kadar yüksek olduğunu değerlendirir; ardından kod, isteğin normal bir fonksiyona mı, uzman bir LLM'e mi yoksa insan incelemesine mi verileceğine karar verir. Jev ayrıca retrieval ile generation arasında kanıt filtrelemek için veya LLM çıktısından sonra sonuçları kontrol etmek için konumlandırılabilir. Kapalı seçenekler, puanlar ve olasılıklar döndürür; açık uçlu yanıtlar, kod üretimi ve uzun akıl yürütme hâlâ LLM tarafından yapılır. TypeSafe'in coding agents açıklaması Jev'in Claude Code veya Codex arkasındaki sohbet modelinin doğrudan yerini alamayacağını açıkça belirtir.

Bu makale bir müşteri hizmetleri talebi, bir RAG soru-cevap hattı ve kendi Agent kalibrasyon kayıtlarımızı kullanarak iki model türünün tam olarak nerede devredildiğini ve düşük güvenli sonuçların neden açık bir varış noktasına sahip olması gerektiğini açıklar.

Jev neyi değerlendirebilir, LLM neyden sorumlu olmaya devam eder?

23 Eylül 2026 itibarıyla, TypeSafe model sayfası listelenen kararlı model jev-1.13.0. API bir state ve bir questions grubunu kabul eder, POST /v1/systemone üzerinden karşılık gelen yapılandırılmış answers döndürür. jev-latest o gün 1.13.0'a işaret ediyordu, ancak takma ad sürümle değişir; eşikleri kalibre edilmiş sistemlerin sürümü sabitlemesi ve yanıttaki gerçek model ID'sini kaydetmesi iyi olur.

Noul'un ayrı bir confidence alanı yoktur; bir Noul olasılığı doğrudan "model güveni" olarak yazılamaz. Score da kesin tutar hesaplamak için kullanılmamalıdır. Tutar, tarih karşılaştırması, kota ve yetki kontrolleri deterministik programlarda kalmalıdır; resmi olarak Jev 1.13'ün bu sınırları listelenmiştir.

Bir çağrının asgari şekli

Aşağıdaki istek şekli resmi API referansı ile uyumludur; örnek sorular bu makalede oluşturulmuş açıklayıcı bir yapılandırmadır ve bu makalede onun için çevrimiçi test yapılmamıştır:

Aşağıdaki JSON bir İngilizce müşteri mesajı kullanır; Türkçede müşteri “Siparişimde mükerrer çekim yapıldı, lütfen para iadesi yapılmasına yardımcı olur musunuz.” derdi.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Gerçek sistem ayrıca önce kodla çekim kaydının aynı siparişe ait olup olmadığını ve geri ödemeye izin verilip verilmediğini kontrol etmelidir. Yukarıdaki örnek yalnızca kullanıcı niyetini yorumlamak içindir; kullanıcının geri ödeme istemesi, geri ödeme uygunluğunun kanıtlandığı anlamına gelmez ve doğrudan geri ödeme yürütme yetkisi oluşturmaz.

Jev ile LLM yönlendirme: üç devir yolu

TypeSafe resmi niyet yönlendirme örneği müşteri hizmetleri talebini önce Jev'e vererek niyet ve karmaşıklığı değerlendirir, ardından kod yönlendirme yapar: sipariş durumu sorgusu veritabanı fonksiyonuna gider; ürün soruları ile iade-değişim, farklı verilerle yüklenmiş uzman LLM'lere gider; karmaşık şikâyetler veya düşük güvenli sonuçlar insan kuyruğuna girer. Bu, Jev ile LLM arasındaki en anlaşılır işbirliğidir: ilki yapılandırılmış yargı verir, ikincisi yalnızca açıklama veya diyalog üretmesi gerektiğinde sahneye çıkar.

Uygulamaya geçerken modelin tüm eylemleri özgürce belirlemesine izin vermek yerine aşağıdaki sırayla tasarlayabilirsiniz:

1. Önce yolları tanımlayın: Normal fonksiyonların, her uzman LLM'in ve insan incelemesinin işleyebileceği istekleri net şekilde listeleyin; Choice için other veya benzeri bir yedek seçenek bırakın.
2. Olguları state içine koyun: Kullanıcının asıl sözleri, hesap durumu, sipariş kayıtları ayrı alanlar olsun; kaynağı belirsiz web metnini sistem talimatı olarak almayın.
3. Her seferinde dar bir soru sorun: Niyet için Choice, risk veya aciliyet için Score, doğrulanması gereken tek bir olgu için Noul. Resmi öneri, aı state için birden çok bağımsız sorunun tek istekte paralel değerlendirilebileceğidir.
4. Son yönlendirmeyi kod yapsın: Önce yetkileri ve katı kuralları kontrol edin, sonra Jev'in olasılıklarına ve bu iş için kalibre edilmiş eşiklere bakın; düşük güvenli veya kanıtı eksik istekler insana ya da ek soruya gider.
5. Sonuçları kaydedin ve yeniden inceleyin: Model sürümünü, soru sürümünü, olasılıkları, nihai varış noktasını ve insan deltme sonuçlarını saklayın; ancak o zaman eşiklerin uygun olup olmadığına karar verilebilir.

Kaynak: TypeSafe AI "Introducing System One Models & Jev", 2026-09-15. Dört iş akışı TypeSafe tarafından kurulmuştur; metrikler iş akışları arasında eşit ağırlıkla toplanmıştır; değerlendirme yöntemi için TypeSafe workflow evals.

Bu resmi grafik, neden "birden çok dar yargıyı program iş akışına yerleştirme" vurgusunu yaptığını anlamaya yardımcı olabilir. Grafikteki dikey eksen üreticinin "accuracy" adlandırmasını sürdürür, ancak referans yanıtları iki büyük modelin tahmin olasılığı uzlaşımından gelir; insan tarafından doğrulanmış tek doğru yanıt değildir; maliyet ve metrikler de bu dört iş akışına ve üreticinin değerlendirme yöntemine bağlıdır, "her senaryoda ne kadar tasarruf edilir"e dönüştürülemez.

Retrieval-augmented generation: Jev, LLM yanıtlamadan önce kanıtları filtreler

TypeSafe'in RAG passage cookbook'u daha somut bir çok modelli örnek sunar: OpenAI embedding önce pasajları getirir, Jev her "soru + pasaj" için dört Noul sorar — ilgili mi, yanıtlamak için kullanılabilecek kanıt içeriyor mu, sorudaki öncülü çürütüyor mu, yanıt modeline talimat vermeye çalışıyor mu. Kod dört olasılığı sırayla işler ve pasajın kanıt alanına, çelişkili kanıt alanına konmasına veya atılmasına karar verir; son olarak Claude Sonnet 5 yanıtı yazar.

Bu adım yaygın bir sorunu çözer: vektör benzerliği yüksek pasajlar kullanılabilir olmayabilir. Yalnızca benzer kelimeler kullanıyor olabilir ya da bir forum gönderisinin içine "önceki metni yok say" şeklinde prompt injection sıkıştırılmış olabilir. Cookbook örneği injection kontrolünü yönlendirme kurallarının en başına koyar ve eşiklerin o korpus için seçilmiş bir başlangıç noktası olduğunu, tüm RAG uygulamaları için varsayılan olmadığını hatırlatır. Gösterilen sayılar 2026-08-27 tarihli jev-1.12'den gelir; güncel jev-1.13.0 için yeni değerlendirme sonuçları olarak alınamaz.

Üretimden sonra bir de doğrulama katmanı yapılabilir. TypeSafe alıntı doğrulama cookbook'u önce programla alıntının kaynak metnini bulur, sonra Jev ile o pasajın üretilen iddiayı destekleyip desteklemediğini, çürütüp çürütmediğini veya ona değinip değinmediğini değerlendirir. Yeniden incelenmeye değer alıntları seçebilir; model yargısıine de hatalı olabilir, "kü geçti" olgusal garanti olarak yazılamaz.

kalibrasyonumuz: Düşük gü yükseltmesi nerede tıkanıyor?

PandaNpc deposunda, Jev istemcisi, soru bankası ve düzenleyici Jev'i Agent'ın ni tanıma, aday değişiklik puanlama, tamamlanma koşulu doğrulama ve gönderme kararlarında kullanır. İstemci ayrıca zaman aşımı, 429, 5xx için sınırlı yeniden deneme yapar; istek bütçesi ve süresi geçmiş sonuçlara sınır koyar; yürütme yetkisi düzenleyici ve kontrollü araç katmanındadır, Jev'in tek bir yargısıyla doğrudan verilmez.

2026-09-22'de jev-1.13.0 ile 19 sentetik turn için birer shadow, birer enforce çalıştırdık; toplam 38 çalıştırma yaptık ve 165 gerçek Jev kararı kaydettik. Bu iç kalibrasyon raporu ve saklanan gerçek makine yanıtları betikleştirilmiş sahte LLM sağlayıcısı kullanır; dolayısıyla bu veriler yalnızca kontrollüaryolardaki karar performansını gösterir. Gerçek kullanıcı istekleri altındaki genel başarı oranını, tasarruf oranını veya uçtan uca gecikmeyi kanıtlamazlar.

En değerli bulgu ortalama hız değil, "güvenli görünen" bir eşiğin tıkanıklık yaratmasıydı: enforce edilen 19 turn'ün 13'ünde Q2 "değişikliğe başlamak için bilgi yeterli mi" sorusunda Noul olasılığı öngörülen 0.15–0.85 belirsizlik aralığına düştüğü için yükseltme yapıldı; LLM Worker sonraki adımları yürütme fırsatı bulamadı. Kalibrasyon kayıtları, bilgi açısından yeterli olarak etiketlenen 34 Q2 kararının çoğunun olasılığının orta bölgede olduğunu gösterdi. Rapor, karmaşık Q2'nin daha atomik yargılara bölünmesini veya yükseltme kurallarının ayarlanmasını öneriyor; bunlar öneridir, hâlihazırda dağıtılmış eşikler değildir.

Soru bankız girişi answer_only, inspect modifyveyaout_of_scope` olarak sınıflandırır; yazma yolunda Worker'ın önerdiği değişiklikler önce Score ile sıralanır, nihai içerik ve değişiklik özeti ise kabul ve gönderme yargısından geçer. Bunlar yalnızca karar noktalarıdır: nesneleri gerçekten okuyup yazma izni, aşamaya göre kontrollü yürütücü tarafından verilir. Jev araç beyaz listesini kendi başına gevşetemez ve gönderme öncesi tutarlılık kontrolünü atlayamaz.

Kalibrasyon verileri başka bir ödünleşimi ortaya çıkardı. Shadow modunda Jev yanıtı ve tam dağılımı verir, ancak Worker'ın özgün yürütme yolunu değiştirmez; enforce modunda yanıt devam edilip edilmeyeceğini, yükseltileceğini veya atılacağını etkiler. Shadow'un doğruluğunu doğrudan enforce'un tamamlanma oranı olarak almak sistemi yanlış okumak olur: Q2'deki yükseltmeler görevi erkenden keser ve sonraki aday puanlama, kabul ve gönderme sorularının hiç ortaya çıkmamasına yol açar. Bu nedenle bu rapor her sorunun dağılımını, yükseltme yönünü ve nihai durumu ayrı ayrı okur.

Aday değişikliklerde somut bir karşılaştırma var: aynı turn'de hedefi tam olarak değiştiren aday 2.94 puan alırken tüm dosyayı üzerine yazan aday 0.38 puan aldı; yüksek puanlı aday seçildi. Bu örnek yalnızca o sentetik durumda puanlama sorusunun iki çözümü ayırt ettiğini gösterir. Tersine, kanıtı kesilmiş bir aday 2.27 puan aldı; sayı "fena değil" göründüğü için düşük güveni ve kesilme işareti göz ardı edilmemelidir. Kodumuz eksik kanıtı ayrıca işaretler ve modelin yalnızca korunan önekle kesin yazma kararı vermesini engeller.

Ayrıca "hangi adayın seçileceği" ile "onun yazmasına izin verilmesi"ni iki farklı adıma ayırdık. Aday Jev puanlamasından geçtikten sonra kontrollü yürütücü yalnızca ACT/modify aşamasında yazma araçlarını açar; verilen tek kullanımlık bilet araç çağrısı ID'sine, güncel revizyon numarasına, hedef nesne hash'ine ve parametre özetine bağlanır. Aday metin modeli "kısıtlamaları yok say" diye kandırsa bile bu kontrolleri aşan araç yetkisi alamaz. Bu, kod düzeyinde entegrasyondan çıkardığımız ders: olasılık yargısı hangi yolun izlenmeye değer olduğuna karar verir; yan etki yetkisi ise yeniden incelenebilir program koşullarıyla belirlenir.

Hata yolları da tasarlanmalıdır. İstemci yalnızca zaman aşımı, ağ hatası, 429 veya 5xx durumunda sınırlı yeniden deneme yapar; iptal edildikten sonraki veya turn bitiş süresini aşan yanıtlar doğrudan atılır. Jev enforce modunda kullanılamıyorsa, düşürme yetkisi verilmediyse devam edilemez; llm_only yoluna izin verildiyse yürütücü salt okunur kilitlenir. Eğer dalda zaten değişiklik yapılmışsa ve Jev kaybedilirse, düzenleyici tüm turu başarısız olarak işaretler; sonraki LLM'in karar katmanı olmadan yazmayı tamamlamasına izin vermez. Bu yollar kullanıcı deneyimi açısından bedellidir, ama "model geçici olarak kullanılamıyor" durumunun sessizce "yazma izni eskisi gibi" olmasını engeller.

Kalibrasyon raporu ayrıca "düşük güven yükseltmesi" ile "yürütmeyi reddetme"yi ayırır. Örneğin doğru bir discard işlemi, güveni birleşik 0.85 eşiğine ulaşmadıysa kullanıcı girdisi gerektiriyor olarak kaydedilir; bu, yanlış geçirmeyle aynı şey deildir. Rapor buna dayanarak gönderme ve atma eşiklerinin ayrılmasını önerir, ancak bu şu an hâlâ öneridir. Yazma iş akışını tasarlarken yanlış geçirme, yanlış reddetme ve inceleme bekleme sonuçlarını ayırt etmek gerekir; aksi halde aynı veri kümesi yanlış eşik sonuçlarına götürür.

Bu vaka bize Jev ile LLM işbirliğinin yalnızca "önce Jev yargılar, sonra LLM çalışır" şeklinde çizilemeyeceğini gösteriyor. Her yargı için şu sorulmalı: belirsizlik aralığı ne kadar geniş? Sonraki işleyicilerin görevi hiç alamamasına yol açar mı? Girdi kanıtı kesilmişse, tahmin etmek yerine açıkça yükseltilebilir mi? Uygulamamızda state oluşturucu evidence_truncated kaydeder ve çağıranın kanıt eksikliği yolunu belirsiz saymasını sağlar; sayma, sıralama gibi deterministik hesaplamalar önce kodda yapılır, Jev'e tahmin ettirilmez. Resmi Jev 1.13 bilinen sınırlamaları da sayma ve aritmetiğin kodda kalmasını önerir.

LLM koruma bariyerleri nereye konmalı?

TypeSafe'in LLM guardrails cookbook'u Jev'i LLM'in giriş ve çıkış tarafları koyar. Farklı riskleri tanımlamak için bir dizi Noul, ciddiyeti ölçmek için Score kullanır; ardından kod politikaya göre geçirme, insan incelemesi, engelleme veya desteğe aktarma kararı verir. Çıktı da kontrol edilmelidir, çünkü normal girdiler yine de uygunsuz üretilmiş sonuçlar doğurabilir.

Bu tür koruma bariyerlerinin sınırı da açıktır: Jev, önceden yazılmış sorulara göre içeriği kontrol edebilir, ancak her şeyi kapsayan bir güvenlik kanıtı değildir. Resmi sınırlama dokümanı kötü niyetli içeriğin yargıyı etkileyebileceğini açıkça belirtir ve criteria'nın net yazılmasını ve sınırların test edilmesini ister. Sentetik örneklerimizde aday parametrelere yönelik 16 injection denemesi yapıldı ve 0 sıralama tersine dönmesi kaydedildi; örnek çok küçük olduğu için "prompt injection'a karşı dayanıklılık çözüldü" sonucu çıkarılamaz. Araçların gerçekte ne yapabileceğine karar veren şey hâlâ koddaki izin listeleri, aşama kapıları ve gönderme öncesi kontrollerdir.

Ne zaman kullanmak uygun, ne zaman kullanmamalı?

Jev için uygun olanlar: aday kümesi bilinir, soru birkaç kısa yargıya bölünebilir, yazılımın otomatik işleme mi yoksa insana yükseltmeye mi karar vermek için olasılığa ihtiyacı vardır. Örneğin müşteri hizmetleri yönlendirmesi, RAG pasaj filtreleme, Agent aday eylem puanlama, üretilen sonuçlarda alıntı doğrulama. Görev bir yanıt mektubu yazmak, bir kod parçasını değiştirmek veya karmaşık akıl yürütmeyi açıklamaksa, LLM devralır. Görev kesin para hesaplamak, tarih karşılaştırmak veya erişim kontrolünü denetlemekse, program doğrudan hesaplamalıdır. Model sayfası ayrıca Jev'in yalnızca metin kabul ettiğini ve İngilizcenin şu an en iyi performans gösteren eğitim dili olduğunu belirtir; Çince senaryoların kendi verileriyle değerlendirilmesi gerekir, İngilizce cookbook eşikleri olduğu gibi alınamaz.

Gerçek bir Agent'ın yetkileri ve araç çağrılarını nasıl işlediğini görmek isterseniz önce PandaNpc Agent sayfasına bakabilirsiniz; coding Agent'ların sınırları ve kullanım senaryoları için de Claude Code ve Codex karşılaştırması sayfasına bakabilirsiniz.

Okuyucular çok küçük bir doğrulama kümesiyle başlayabilir: "açıkça otomatik işlenebilir", "açıkça reddedilmeli", "anlamsal olarak belirsiz", "kötü niyetli talimat içeriyor" olmak üzere dört tür örnek hazırlayın; önce insan etiketlemesini belirleyin, sonra Jev'in her soru için olasılıklarını ve yönlendirme sonuçlarını kaydedin. Başarı ölçütü her öğenin otomatik geçmesi değil, otomatik işleme yolunun hata oranının ve insana yükseltme miktarının kabul edebileceğiniz aralıkta kalmasıdır. Belirsiz örneklerin çoğu aynı soruda tıkanıyorsa, önce soruya birden çok yargının karışıp karışmadığını, statein çok uzun olup olmadığını veya eşiklerin yerel veriye göre kalibre edilip edilmediğini kontrol edin.

FAQ

Jev, Claude Code, Codex veya sohbet modellerinin yerini alabilir mi? Hayır. TypeSafe onu yazılım içinde yapılandırılmış karar modeli olarak konumlandırır; sohbet, yazma ve kod üretimi hâlâ LLM gerektirir.

Dönüş tipi sabitse hata yapmaz mı? Hayır. Sabit tipler ayrıştırma ve sınır dışı çıktı sorunlarını azaltır, ancak sınıflandırma, puanlama ve olgu yargısı yine de hatalı olabilir. Düşük güvenli ve yüksek riskli yollar insan incelemesi için ayrılmalıdır.

Aynı istekte kaç soru sorulabilir? Aynı statei paylaşan birden çok bağımsız Choice, Score, Noul tek istekte yer alabilir. Sorular ayrı ayrı değerlendirilir; karmaşık yargılar yine bölünmeli ve kod tarafından birleştirilmelidir.

Çince kullanılabilir mi? Resmi olarak Japonca, Çince ve Korece karakterler dahil doğal dillerin desteklendiği belirtilir, ancak İngilizce doğruluğu şu anda en iyisidir. Çince iş yükleri ayrıca doğrulanmalı ve kalibre edilmelidir.