Noul ne demek? Kısa cevap: TypeSafe’in soru tiplerinden biri. Şirketin System One modeli Jev’e evet/hayır biçiminde bir önerme verirsiniz, o da önermenin doğru olma olasılığını 0 ile 1 arasında bir sayı olarak döndürür. Noul sohbet modeli değil; genel amaçlı programlama dili ya da Python’daki bool gibi yerleşik veri tipi de değil. TypeSafe API’sinde Choice ile Score’un yanında duran üç karar primitive’inden biri.
“Bu mesaj iade talebi içeriyor mu?” diye sorarsınız, noul alanında sayısal cevap alırsınız. Kod da uzun bir model açıklamasını didiklemek yerine bu olasılığı kendi eşiğiyle değerlendirir.
Konuya yapay zekanın daha geniş tarafından geldiyseniz Yapay Zeka sayfasına bakabilirsiniz. TypeSafe’in neden uzun metin üretmek yerine dar kararlar peşinde olduğunu ise Jev ve System One genel bakış yazısında anlatmıştım. Burada işin API tarafındayız.
Tek satırda Noul
En küçük işe yarar örnek, minik bir state ile tek Noul:
from typesafe_sdk import Noul, TypeSafeClient
with TypeSafeClient() as client:
response = client.system_one(
state={"ticket_message": "Uçuşum iptal oldu. İade alabilir miyim?"},
questions={
"refund_requested": Noul(
instructions="`ticket_message` açıkça iade talep ediyor mu?",
),
},
)
p_evet = response.answers["refund_requested"].noul # [0, 1] aralığında floatDönen değer, verdiğiniz soru ve state altında “evet” olasılığıdır. Eşiği kod seçer. Aşağıdaki daha uzun örnekte aynı çağrıya Choice ve Score da ekleniyor.
Noul ne demek, dönen sayı nasıl okunur?
Adı ilk bakışta pek ipucu vermiyor. Çalışma biçimi hayli açık:
1civarı, eldeki verinin “evet” cevabını güçlü biçimde desteklediğini gösterir.0civarı, “hayır” tarafının ağır bastığını söyler.0,5civarında model iki okuma arasında kalmıştır.
Ortadaki değer “orta seviye” değildir. Çünkü Noul bir seviye ölçmüyor, önermenin doğru olup olmadığını tartıyor. “Bu hata ciddi mi?” netleştirilmiş bir evet/hayır sorusu olabilir. “Bu hata ne kadar ciddi?” ise Score işidir.
“Noul data type” aramasındaki veri tipi ifadesini de doğru yere koyalım. Anlam yine yukarıdaki evet/hayır olasılık sorusu. Noul, Jev API’sindeki tipli soru ve cevap primitive’idir; dönen değer sayısal olsa da genel programlama dillerine eklenen yeni bir skaler veri türü değil. “Noul programming” diye ayrı bir dil de yok. Terim, TypeSafe’in kısıtlı ve kodun kullanabileceği karar arayüzüne ait.
Noul cevabında ayrıca confidence alanı bulunmuyor. İki ihtimalli bir dağılımı tek sayı zaten tümüyle anlatıyor, yani olasılığın kendisi sinyal. Choice ve Score’daki confidence mantığını Jev confidence yazısında açmıştım. Örneğin 0,93, verilen state ve soruya göre evet ihtimalinin yüzde 93 hesaplandığını anlatır; cevabın yüzde 93 doğruluk garantisi taşıdığını değil. Aradaki fark, üretimde epey masraf çıkarabilir.
Noul ile boolean farkı: neden true/false değil?
“Noul boolean” ya da “noul vs bool” arayanlar genelde şunu soruyor: Jev neden doğrudan true / false döndürmüyor?
Boolean sert bir kesim ister. Kanıt zayıf, çelişkili ya da eksik olsa bile model bir taraf seçmek zorunda kalır. Noul sürekliliği korur: 0 ile 1 arasında bir float. Politika uygulama kodunda kalır. İade incelemesi 0,9 üstünde, insan kontrolü 0,4 ile 0,7 arasında, otomatik red 0,2 altında. Bu eşikler depoda durur; soruyu yeniden yazmadan değiştirilebilir.
Yani Noul, Python’daki bool yerine geçen bir tip değil. TypeSafe API’sinde olasılık taşıyan tipli bir evet/hayır sorusu. Eşiği kodda kestikten sonra dal için boolean elde edersiniz. Şeklin dokümanı: docs.typesafe.ai/primitives/noul.
Üç primitive, üç ayrı kod yolu
Bir destek kaydını düşünelim. Mesaj hangi ekibe gidecek? Müşteri ne kadar öfkeli? İade istiyor mu? Kulağa aynı türden sorular gibi geliyor, ama kod açısından üçünün yapısı farklı.
- Choice, önceden belirlenmiş ve sırasız seçeneklerden birini seçer.
- Score, yazdığınız sıralı seviyeler üzerinde konum verir.
- Noul, tek ve açık bir önermenin evet olasılığını hesaplar.
Sonucun gideceği yere bakmak iyi bir kestirme. switch dalı gerekiyorsa Choice, sıralı eşikler gerekiyorsa Score, doğrudan bir if koşulu gerekiyorsa Noul çoğu zaman doğru başlangıçtır.
Choice için menünün tamamını yazın
Destek talebi billing, technical, sales ya da other kuyruklarından birine gidecekse Choice kullanılır. Seçenekler arasında iyiden kötüye sıralama yoktur. Model kapalı listedeki anahtarlardan birini seçer.
Cevapta seçilen choice, bütün seçeneklere dağıtılan probabilities ve dağılımın ne kadar tek noktada toplandığını özetleyen confidence yer alır. Seçilen anahtar doğrudan kod dalına bağlanabilir.
Liste eksikse sorun başlar. Gerçek hayatta dördüncü ihtimal varsa ama siz üç seçenek verdiyseniz model yine onlardan birini döndürür. other ya da none_of_the_above kaçış yolu bu yüzden süs değil. Şemaya uygun yanlış cevap hâlâ yanlış cevaptır.
Score için cetveli tarif edin
Öfke, risk, beceri ve hata şiddeti sıralı ölçülerdir. Score bu çizgi üstünde sayısal konum döndürür; değer iki tarifin arasına da düşebilir. Cevaba legend, seviye olasılıkları ve confidence eşlik eder.
“Düşük, orta, yüksek” yazmak kolay. Ne var ki destek ekibindeki iki kişi aynı kayda farklı anlam yüklüyorsa modelden tutarlılık beklemek iyimserlik olur. “Görsel kusur”, “geçici çözümü olan iş akışı engeli”, “veri kaybı ya da güvenlik riski” gibi tarifler daha işe yarar.
Eşikler de hazır gelmiyor. Etiketli örnekleri çalıştırıp hangi aralığın hangi eyleme bağlanacağını ölçmeniz gerekir. Tek cevap hoş göründü diye 2,3 üstünü acil ilan etmek politika sayılmaz.
Noul sorusunu küçültün
Noul’un sevdiği cümleler kısa ve denetlenebilir:
ticket_messageaçıkça iade talep ediyor mu?ticket.messages[0].textkişisel veri içeriyor mu?- Özgeçmiş, adayın ücretli bir işte Python kullandığını söylüyor mu?
Son örnekte beceri seviyesi sorulmuyor. Belgede belirli bir iddianın bulunup bulunmadığı kontrol ediliyor. “Aday Python’da ne kadar iyi?” derseniz Score’a geçmek gerekir.
Noul dokümanı iki kural daha koyuyor. Birincisi, her Noul tek koşul sorsun. “Müşteri hem öfkeli hem iade istiyor mu?” derseniz model iki şeyi birden tartar ve çıkan sayı bulanıklaşır; iki ayrı Noul sorup sonucu kodda birleştirin. İkincisi, soruyu yüksek değer “evet” anlamına gelecek şekilde kurun. “Mesajda kişisel veri yok mu?” gibi ters kurulmuş bir soru, eşiği sonradan okuyan geliştiricinin kafasını karıştırır.
TypeSafe primitive dokümanındaki pratik ölçü şu: Bilgili biri, önündeki kanıta bakarak bu yargıya hızlıca varabilir mi? “Hesabı incele, politikayı yorumla, en uygun çözümü bul ve müşteriye yanıt yaz” bu ölçüyü geçmez. Veri toplama, politika kontrolü, karar ve metin üretimi aynı cümleye sıkışmış. Ayırın, aradaki bağı kod kursun.
Jev sorusunun içinde ne var?
Primitive’ler farklı cevap verse de soru yapısında tanıdık parçalar bulunur:
- Kodun cevabı bulacağı ID, örneğin
refund_requested. choice,scoreya danouldeğerlerinden oluşan type.- Modelin okuyacağı yargıyı taşıyan instructions.
- Gereken tiplerde seçenekleri veya seviyeleri açıklayan criteria.
ID kod içindir. Değişkene policy_match adını vermek; hangi politikanın, hangi olayla, state içindeki hangi alanlara bakılarak karşılaştırılacağını modele anlatmaz. Instructions alanında tam soruyu yazmak gerekiyor.
Noul’da evet ve hayır zaten belli olduğu için seçenek listesi aranmaz. Yine de alanınıza özgü sınırı, true ve false tariflerinden oluşan isteğe bağlı criteria ile açıklayabilirsiniz. Mesela “iade talebi” chargeback tehdidini kapsıyor ama mağaza kredisi isteğini kapsamıyorsa bu ayrımı modele bırakmayın.
Tek state içinde Choice, Score ve Noul
Uçuşu iptal edilen müşteri örneğini Python SDK ile kuralım:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
state = {
"ticket_message": "Uçuşum iptal oldu. Paramı geri alabilir miyim?",
"refund_policy": "İptal edilen uçuşlarda ücretin tamamı iade edilir.",
}
questions = {
"request_type": Choice(
instructions="`ticket_message` içindeki ana talep nedir?",
criteria={
"refund": "Müşteri ücretin geri ödenmesini istiyor.",
"rebooking": "Müşteri yeni uçuş istiyor.",
"information": "Müşteri yalnız bilgi istiyor.",
"other": "Talep diğer seçeneklere uymuyor.",
},
),
"frustration": Score(
instructions="`ticket_message` içindeki öfke düzeyi nedir?",
criteria=[
"Sakin ve nötr.",
"Endişeli fakat ölçülü.",
"Çok öfkeli ya da sert ifadeler kullanıyor.",
],
),
"refund_requested": Noul(
instructions="`ticket_message` açıkça iade talep ediyor mu?",
),
}
with TypeSafeClient() as client:
response = client.system_one(state=state, questions=questions)state bir kez gönderiliyor. Sorular aynı veriyi görüyor, bağımsız çalışıyor ve seçtiğiniz ID altında dönüyor.
Buradaki “bağımsız” sözcüğü önemli. Aynı çağrıdaki request_type sonucu, refund_requested sorusuna gizli bilgi olarak aktarılmaz. İkinci soru ilk cevaba göre kurulacaksa önce cevabı kodda alın, gereken veriyi çekin ya da state’i yeniden hazırlayın, ardından yeni çağrı yapın. İkisi de ilk state’ten yanıtlanabiliyorsa ayırmanın pek anlamı yok.
JSON büyüdüğünde field path kullanın
Gerçek destek kaydında mesajlar, sipariş, ödeme hareketleri, iade politikası ve iç notlar yan yana durur. “Müşteri iade istiyor mu?” sorusu modelin yanlış parçaya bakmasına izin verebilir.
İlgili alanı backtick içinde nokta ve indeks yoluyla gösterin:
`ticket.messages[0].text` iade talebi içeriyor mu?İki alanı karşılaştıran soru da açıkça yazılabilir:
`refund_policy`, `order.charges` içindeki çift çekimi kapsıyor mu?Field path, instructions metninin içinde duruyor. Kodun çalıştırdığı bir sorgu gibi değil, modele “şuraya bak” diyen bir adres gibi düşünün. Sonradan soruyu gözden geçiren geliştirici de cevabın hangi kanıta dayanması gerektiğini hemen görür.
On üç ayrı çağrının faturası
System One, aynı state’e bakan soruları paralel değerlendirebiliyor. Bu yüzden bağımsız Choice, Score ve Noul sorularını tek istekte toplamak çoğu durumda daha akıllıca.
TypeSafe’in parallel-questions cookbook örneğinde Wikipedia’daki GDPR maddesinin sabitlenmiş bir sürümüne (yaklaşık 54 bin karakter) 13 soru soruluyor: 8 Noul, 2 Choice, 3 Score. jev-1.12 ile her iki yöntem beşer kez koşulmuş. Tek paket, 13 ayrı çağrıya göre 12,2 kat ucuz ve 10,0 kat hızlı çıkmış, cevaplar değişmemiş. Primitive’ler sayfası aynı cookbook’un önceki koşusundan 11,5 ve 9,6 kat rakamlarını aktarmaya devam ediyor. Hangisini alırsanız alın, bunlar o belgenin ve o kurulumun sonuçları. Hız rakamı ayrıca 13 çağrının arka arkaya yapıldığını varsayıp süreleri topluyor.
Nedeni gayet sıradan. Uzun belgeyi bir kez göndermek, aynı token’ları 13 defa ücretlendirmekten ucuz. Sıralı istekler 13 ağ turu da ekliyor. Çağrıları eşzamanlı yapınca süre farkı daralabilir fakat tekrar gönderilen girdi ortadan kalkmaz.
TypeSafe bu yaklaşıma speculative fan-out diyor. Programın ihtiyaç duyabileceği bağımsız soruları baştan gönderiyor, o vakada gerekmeyen cevapları kodda kullanmıyorsunuz. Destek kaydı; departman için Choice, iade isteği ve PII için iki Noul, öfke ile hata şiddeti için iki Score taşıyabilir. Kayıt hata raporu değilse şiddet cevabı çöpe gider.
Gerçek bağımlılığı paket uğruna gizlemeyin. İlk cevap hangi veritabanı kaydının çekileceğini ya da sonraki Choice seçeneklerini belirliyorsa iki aşama daha doğru.
Karar politikasının yeri kod
Jev dar yargılar üretir. Bu yargıların ne zaman ödeme, iptal ya da insan incelemesi başlatacağını uygulama belirlemeli.
Destek kaydının önceliği iş etkisi, müşteri öfkesi ve kanıt kalitesine bağlıysa üç Score sorun. Sonuçları normalize edin, ağırlıkları kodda verin. Destek politikası değiştiğinde büyük prompt’ın içine yeni paragraf saklamak yerine katsayıyı değiştirirsiniz. Fark da git geçmişinde görünür.
İsteğe refund_policy alanının vakayı kapsayıp kapsamadığını soran ikinci bir Noul, policy_supports_refund, eklediğimizi varsayalım. İki koşulun birlikte arandığı karar şöyle kurulabilir:
answers = response.answers
refund_requested = answers["refund_requested"].noul
policy_ok = answers["policy_supports_refund"].noul
if refund_requested > 0.85 and policy_ok > 0.90:
queue_for_refund_review()
else:
send_to_human()0,85 ve 0,90 örnek değerler, Jev’in hazır eşiği değiller. TypeSafe’in önerisi şöyle: yanlış “evet” ile yanlış “hayır” aynı maliyetteyse 0,5’ten başlayın; yanlış “evet” pahalıysa (iade, gece nöbetçisini uyandırmak) eşiği yükseltin; gerçek bir “evet”i kaçırmak daha kötüyse düşürün. Ortada kalan değerleri insana yollamak da bir seçenek. Son eşikleri kendi etiketli vakalarınızda false positive ile false negative’i ayrı ölçerek belirleyin.
Tipli cevap doğruluk garantisi vermez
Choice izinli anahtarlardan yanlış olanı seçebilir. Score sakin müşteriyi öfkeli sanabilir. Noul hatalı okumaya 0,9 verebilir. Temiz şema, entegrasyonu kolaylaştırır; sonucu kendiliğinden güvenilir kılmaz.
Geri çevrilmesi zor bir tool çağrısından önce üretime benzeyen veriyle eval çalıştırın, deterministik izin ve politika kontrollerini koruyun, insana giden güvenli yolu kapatmayın. Test ettiğiniz model ile sağlayıcı sürümünü sabitlemek de sonradan neyin değiştiğini anlamayı kolaylaştırır.
Akılda tutulacak ayrım şu: Choice kodunuza dal, Score konum, Noul ise evet olasılığı verir. System One yargıyı üretir. O yargının yetkisini uygulamanız belirler.
3 yorum