Microsoft'un Decision-1 olasılık modeli, AI tool call'ları için ucuz bir doğrulayıcı olarak çalışıyor

Yalnızca olasılık çıktısı veren bir model

Microsoft, OpenRouter üzerinde Microsoft-Decision-1 adıyla küçük, özelleşmiş bir model listeledi. Genel amaçlı bir chat modelinden farklı olarak, bu model tanımlanmış bir durum artı sabit bir adlandırılmış cevap kümesine sahip bir soru alıyor ve her seçenek için bir olasılık döndürüyor. Spanda Works'ten Tom Jones'un bir dev.to yazısına göre, modelin yaptığı iş tam olarak bu.

Spanda Works ekibi, isteklerin çoğunu ucuz modellere gönderen ve sonuçları dışarı çıkmadan önce inceleyen bir gateway çalıştırıyor. Herhangi bir soruyu bir güven numarasıyla birlikte evet ya da hayıra indirgeyen bir bileşen, uzun zamır inşa etmeye çalıştıkları doğrulama katmanı gibi görünüyordu; bu yüzden bir günlerini etrafına bir denetleyici kurmaya harcadılar.

Olgularda kararlı, yargıda kararsız

Yazıya göre ilk deneyler umut kırıcıydı. Bir insan hakeme yöneltebileceğiniz açık uçlu sorular sorulduğunda — örneğin bir notun bir agent'ın bir sonraki adımıyla ilgili olup olmadığı — model tutarsız olasılıklar döndürdü. Özdeş alaka sorguları çağrılar arasında 0,17'ye varan farklar gösterdi.

Sağlam durduğu yer ise doğrulanabilir olgulardı. Bir kullanıcının mesajında belirli bir şehir adının bulunup bulunmadığı gibi bir soru her seferinde aynı ve doğru geri döndü. Bu gözlem, o gün için tasarım kuralını belirledi: deterministik kod olguları belirler ve Decision-1'a yalnızca önüne konmuş olgular hakkında net sorular sorulur. Gerçek yargı gerektiren sorular UNSURE döndürür ve daha güçlü bir modele yükseltilir.

Denetleyici hattı

Ortaya çıkan sistem bilinçli olarak sade. Kod her tool call'u doğrular, Decision-1 birkaç tek olgulu soruyu yanıtlar ve düzeltilebilir bir yanlışlık varsa ucuz bir onarım modeline bir deneme hakkı verilir. Onarılan call daha sonra aynı kontrollerden geçer. Her çalışma APPROVE, REJECT veya UNSURE ile sonuçlanır ve yürütülen her kontrolün bir kaydı tutulur.

En çok işe yarayan geç kural şu oldu: bir onarım yalnızca denetleyici onu sonradan onaylarsa korunur. Aksi halde özgün call olduğu gibi gönderilir; son sürümin önceden doğru olan hiçbir şeyi bozmamasının nedeni de bu.

Dört sürüm boyunca ölçülmüş sonuçlar

Ekip üç başarısızlık modu tanımladı ve geçme/kalma ölçütlerini, onların sonuçlarını görmemiş ayrı bir model tarafından önceden yazılmış halde kilitledi. Her sürüm, hiç karşılaşmadığı 300 tool call üzerinde bir kez çalıştı; puanlama, yazılı bir ölçüte göre çalışan, bir call'un özgün mü yoksa onarılmış mı olduğunu bilmeyen yeni AI etiketleyicileri tarafından yapıldı.

Yanlış onaylar sürüm 2.1'de 48'de 9'dan sürüm 2.4'te 72'de 0'a düştü. Onarılıp onaylanan yanlış call'lar 100'de 25'ten 96'da 20'ye indi. Onarımın bozduğu call'lar 200'de 2'den 201'de 0'a geriledi. İyileşmenin büyük kısmı, önceki başarısızlıkları incelemekten ve kodun görebildiği biçimler için kontroller eklemekten geldi — örneğin metin olarak serialize edilmiş bir liste ya da beşten az öğe isteyip tam olarak beş limiti alan bir kullanıcı.

Yazının kendi hakem modeli bu sıfıra itiraz etti: her sürümün farklı etiketleyicilerle call'ların farklı bir seçimi üzerinde çalıştığını, bunun gürültü eklediğini ve 96'da 20'lik onarım oranının yüzde 20'lik alt sınırını ancak zor geçtiğini belirtti. Yazar ise ham sayıların kendi başına durduğunu savunuyor: dört sürüm boyunca denetleyici 164, 150, 120 ve 110 call'u onayladı ve bunlardan 9, 4, 2 ve 0'ında yanılıyordu. Takas şudur ki sürüm 2.4 çok daha seyrek evet diyor.

Görev başına maliyet, token başına değil

Decision-1 neredeyse görünmez olacak kadar ucuz: 300 call'luk tam test bir sentin altına maloldu ve 1.417 ek kayıtlı call üzerinde çağrı başına yaklaşık binde iki sent maliyetle, bir saniyenin altında medyan gecikmeyle çalıştı.

Yazarın daha ilginç bulduğu kayma ise bir denetleyicinin fiyatlama hakkındaki değiştirdiği şey. Denetleyici olmadan token başına öder ve cevabın doğru olduğunu umarsınız. Denetleyiciyle birlikte birim doğrulanmış bir cevap haline gelir ve fiyatı, denetleyicinin onaylamayı reddedip daha pahalı bir yere göndermek zorunda kaldığı her call'u kapsar. Kayıtlı çalışmalarda, ucuz model artı denetleyici artı yükseltme, aynı görevleri doğrudan premium bir modelde çalıştırmakla kıyaslandığında çok daha düşük bir maliyet oluşturdu; bu oranın büyüklüğü neredeyse tamamen denetleyicinin ne kadar sık evet diyebildiğine bağlı.

Kalan boşluk

Call'ların yaklaşık dörtte biri hâlâ UNSURE dönüyor; çoğunlukla doğruluğun bir değerin mevcut olup olmadığına değil ne anlama geldiğine bağlı olduğu durumlar. Kod anlamı inceleyemez ve onu yargılaması istenen karar modeli tutarsızlaşır. Ekibin ileri taşıdığı soru şu: denetleyiciye onaylamaması gereken şeyleri onaylamayı öğretmeden, anlam hakkındaki bir yargıyı düz kodun doğrulayabileceği bir olguya nasıl dönüştürebiliriz.

Neden önemli

Doğrulama, ucuz modellere üretim işlerinde güvenmenin ana engelidir. Bu yazı uygulanabilir bir örüntü öneriyor: hızlı ve neredeyse bedava bir olgu denetleyicisi olarak özelleşmiş bir olasılık modeli, stabiliteyi sağlayan deterministik kod ve belirsizliği üstlenen daha güçlü bir model. Kontrol başına binde bir sentlerle sıfır yanlış onay, gözetim maliyetlerinin ucuz modelleri gerçek görevler için geçerli kılacak kadar düşürülebileceğini gösteriyor — yeter ki call'ların büyük bir kısmının hâlâ yükseltme gerektirdiğini ve hassasiyetin daha az onaylayarak satın alındığını kabul edin.