Karar modelleri: cevap bir olasılık olduğunda

Bir destek talebi gelir: “Bu ay benden iki kez ücret alındı.” Uygulamanın faturalandırma üzerine bir yazıya ihtiyacı yoktur. Talebin yönlendirileceği birim, belirsizlik bilgisi ve bir sonraki adımı belirleyen kural gerekir.

Üretim yazılımlarının çoğu bu şekle sahiptir. Bir iletinin bir kategoriye ihtiyacı vardır. İş akışı bir şubeye ihtiyaç duyar. Bir ajanın önerilen eyleminin bir çeke ihtiyacı vardır. Dil girdiyi yorumlamaya yardımcı olur, ancak çıktı genellikle sıradan kontrol akışına aittir.

TypeSafe AI'nın Jev, 15 Eylül 2026'da tanıtıldı, bu gözlemi başlangıç noktası olarak alır. Şirket buna System One Model diyor: düzyazıdan ziyade yazılı olasılıksal kararları döndürmek için inşa edilmiş bir model. Lansmandan beş gün sonra, ürün hakkında karar vermek için çok erken. Arayüz zaten incelemeye değer.

Yazılımın ihtiyaç duyduğu kararla başlayın

TypeSafe’in API tasarımı yaklaşımında istek, mevcut durumu ve türü belirlenmiş bir veya daha fazla soruyu içerir. Sonuç, ilan edilmiş bir yapıya uyar; uygulama doğrudan ona göre dallanabilir. Aynı çağrıdaki sorular ortak duruma göre birbirinden bağımsız değerlendirilir.

Üç ilkel, farklı yargılama türlerini kapsar.

Tasarım, dar soruları teşvik eder. Bir talebin otomatik işlenip işlenmemesi gerektiğini tek seferde sormak yerine; konusunu, eksik bilgi olup olmadığını ve uzman incelemesi gerektirip gerektirmediğini sorun. Sonra bu sonuçları kodda açıkça birleştirin.

Benim için mimari cazibe budur. Yargı öğrenilmiş kalır; iş akışının yapısı bir ekibin okuyabileceği, test edebileceği ve değiştirebileceği bir şey haline gelir.

Geçerli bir şekil sadece ilk garantidir

Bunu bir modelden güvenilir JSON almanın ilk yolu gibi anlatmak yanıltıcı olur. Modern yapılandırılmış çıktı sistemleri, üretimi çözümleme sırasında desteklenen bir şemayla sınırlayabiliyor. OpenAI’nin Structured Outputs özelliği bir örnek. Alternatif artık yalnızca serbest metin ve ardından kırılgan bir ayrıştırıcı değil.

TypeSafe’in farkı, karar odaklı modeli ve arayüzüdür: sabit çıktı türleri, olasılık dağılımları ve kısa değerlendirmelere odaklanan tasarım. Belirli bir iş yükünde doğruluk, gecikme veya maliyeti iyileştirip iyileştirmediği deneyle yanıtlanmalıdır.

Şirketin şema garantisi de dikkatle okunmalı. billing, technical veya sales değerlerinden birini döndürmek, tanımlanmamış dördüncü bir kategoriyi engeller. Teknik bir sorunun faturalandırma birimine yönlendirilmesini engellemez. Biçimi doğru bir yanıt, içerik olarak yanlış olabilir.

Bu, fikri reddetmek için bir neden değil, yararlı bir sınırdır. Yazılım, bilinen bir hata türünü beklenmedik bir çıktı biçiminden daha kasıtlı olarak ele alabilir. Yine de belirsizliği tespit etmek ve hataları ölçmek için bir yola ihtiyaç duyar.

Olasılık ve güven farklı göstergelerdir

Modelin P(refund_requested) = 0.03 tahminini verdiğini düşünelim. Bu, “büyük olasılıkla hayır” şeklinde güçlü bir yanıttır; modelin kendi yanıtına neredeyse hiç güvenmediği anlamına gelmez. Aynı ikili soru için 0.5 çevresindeki değerler çok daha belirsizdir.

Choice ve Score farklı bir sinyal sunar. confidence alanları, dönen dağılımın ne kadar yoğunlaştığını özetler. TypeSafe’in güven düzeyi belgeleri belgesi bunu dağılımdan türetilen bir istatistik olarak tanımlar. Otomatik olarak seçilen yanıtın doğru olma olasılığı diye okunmamalıdır.

Bir bilet yönlendiricisi için, güven hemen rotayı belirlemek, daha fazla bilgi toplamak veya bir kişiye sormak olabilir. İkili risk sorusu için, yüksek bir olasılık bunun yerine durma anlamına gelebilir. Eylemin yönü, sorunun anlamından gelir.

Sayıların temsili veriler üzerinde test edilmesi gerekir. Bir uygulamanın yanlış bir kuyruk için toleransı, yanlış bir hesap eylemi için toleransından farklıdır. Çok emin bir cevap bile erişim kontrollerine ve gerekli onaylara tabi kalmalıdır.

Kalibrasyon kendi verilerinizde de geçerli olmalı

Kalibrasyon, tahminlerle gözlenen sonuçlar arasındaki ilişkidir. Yaklaşık 0.8 olasılık verilen benzer vakalarda olayın on seferde yaklaşık sekiz kez gerçekleşmesi gerekir. Tek bir yanıt bu ilişkiyi gösteremez.

Kendi değerlendirmemde, hedeflenen iş akışından etiketli örneklerle başlardım. Eşikleri belirleyen verilerle onları değerlendiren verileri ayırır, önemli her alt gruptaki hataları incelerdim. İyi bir genel sonuç; belirli bir dilde, müşteri grubunda veya alışılmadık talep türünde zayıflığı gizleyebilir.

Ayrıca işletme takasını da ölçeceğim: sistemin otomatik olarak kaç vakayı ele aldığı, inceleme için kaç tane gönderdiği ve bu ayarda kaç hata kaldığı. Bir kişiye her şeyi göndermek otomasyonun amacını yenerken güvenli görünebilir.

Bu yaklaşım, QANTIS araştırmaları arkasındaki disipline yakındır: referansı, koşulları ve sonucun sınırını belirtmek. “Kalibre edilmiş” ifadesi; veri kümesi, yöntem ve iddianın hangi koşullarda geçerliliğini yitirdiğiyle birlikte anlam kazanır.

Karar dalının sorumluluğu kodda kalsın

Küçük bir örnek bu ayrımı görünür kılar. Aşağıdaki kod, TypeSafe SDK örneği değil, açıklayıcı uygulama mantığıdır. Girdisi doğrulanmış bir Choice sonucudur; güven eşikleri şemadakilerle aynıdır.

def route_ticket(ticket, decision, policy):
    if decision.confidence < 0.70:
        return send_to_reviewer(ticket)

    if decision.confidence < 0.98:
        return request_more_context(ticket)

    if not policy.allows_route(ticket, decision.choice):
        return send_to_reviewer(ticket)

    return assign_queue(ticket, decision.choice)

Model kategoriyi ve belirsizliği sağlar. Koşulları, izin verilen yönlendirme hedeflerini ve alternatif yolu kod belirler. Eşik değiştirmek; değerlendirilebilen, incelenebilen ve geri alınabilen sürümlü bir politika değişikliğine dönüşür.

Bu, doğrudan ajan çalışma altyapısı mühendisliği argümanına bağlanır. Dar bir model çağrısı, bir girdinin yorumlanmasına veya bir endişeye işaret etmesine yardımcı olabilir. Bir işleme izin verilip verilmediğine dair tek otorite olmamalıdır.

NowFlow içinde onay aşaması açıkça tanımlanmış bir yoldur. NODERIQ içinde bulgular kararı verecek kişiye ulaşmalıdır. QANTIS’te planlayıcı klasik kalır; inanç durumunu ise ayrı bir bileşen günceller. Bunlar aynı yararlı sınırın farklı uygulamalarıdır: Olasılıksal bir değerlendirme, eylem yetkisini üstlenmeden bir karara bilgi sağlayabilir.

Fırlatma numaralarını başlangıç noktası olarak okuyun

TypeSafe’in lansman yazısı, kendi iş akışı değerlendirmelerinde büyük hız ve maliyet avantajları bildiriyor. Aynı yazı, bu iş akışlarını şirketin model yetenekleri ekibinin hazırladığını, yanlılık içerebileceğini ve beklenen kazançların üst sınırına yakın olduğunu da söylüyor. Bu kayıtlar iddiaların yanında yer almalı.

Üretime alma kararında bütün iş akışını karşılaştırırdım: görev doğruluğu, gecikme dağılımı, toplam maliyet, inceleme oranı, tekrarların ve ek kontrollerin etkisi. Hızlı model çağrısı değerlidir; fakat ölçüm uygulamanın işe yarar çıktısına kadar sürmelidir.

20 Eylül 2026 itibarıyla bu, kısa bir kamuya açık geçmişi bulunan erken erişim ürünüdür. Farklı alanlardaki performansı, veri dağılımı değişimleri ve sürekli üretim kullanımı konusunda önemli sorular hâlâ açık. Lansmanı yeni bir bileşeni değerlendirme çağrısı olarak görüyorum.

Yararlı sınır yargı ve otorite arasındadır.

Generatif modellerin açık uçlu problemlerin yazılmasında, planlanmasında ve çalışılmasında hala bir rolü vardır. Karar modelleri, bu görevler arasında oturan daha dar yargılar için farklı bir arayüz sunar.

Umut verici mimari bu yetenekleri açık kontrolle birleştirir. Bir model dağınık girdiyi yorumlar. Yazılı bir sonuç yargıyı ortaya çıkarır. Kod politika uygular. Çevre kontrol edilebilecek bir sonuç sağlar.

Bu, herhangi bir ürünün ötesinde önemli olmasını beklediğim fikrin bir parçası: belirsizliği çalışmak için yeterince görünür hale getirmek ve insanların inceleyebileceği bir yerde hareket etme kararını korumak.