Olasılıksal ürün mantığı
Yapay zekâ ürününü klasik yazılımdan ayıran üç şeyi öğretir: çıktının bir dağılım olması, girdi kapsamının açık uçlu kalması ve hata sınıflarının değişmesi. Bunların şartname, kabul ölçütü ve test pratiğinde ne değiştirdiğini gösterir.
BU DERSİN SONUNDA
- Belirlenimci ve olasılıksal bir özelliğin kabul ölçütünü ayırt etmek
- Yapay zekâ ürününe özgü hata sınıflarını adlandırmak ve birbirinden ayırmak
- Açık uçlu girdi kapsamını girdi sınıflarına bölerek kapatmak
- Bir özelliği davranış sözleşmesi biçiminde yazmak
- 1
Teori
Kavramın çalışma mantığı
- 2
Örnek
Gerçek bir senaryo üzerinde gösterim
- 3
Lab
Uygulamalı alıştırma
- 4
Test
Kısa ölçüm
- 5
Proje
Rotadaki projeye katkı
Kısa cevap
Klasik yazılımda bir özelliği "çalışıyor" ilan etmek için tek bir doğru çıktı yeter; yapay zekâ ürününde çıktı bir dağılımdır, dolayısıyla kabul ölçütü de tek örnek değil orandır. Bunun ürün tarafında üç sonucu var: şartname girdi–davranış sözleşmesine dönüşür, girdi kapsamı hiçbir zaman tam kapanmaz ve sessiz yanlışlık gibi yeni bir hata sınıfı doğar.
Teori: aynı girdi, farklı çıktı#
Belirlenimci bir fonksiyonun sözleşmesi basittir: şu girdi gelirse şu çıktı döner. Test yazmak bu yüzden ikili bir iştir, ya eşleşir ya eşleşmez. Dil modeli tabanlı bir özellik ise her istekte aynı cevabı vermek zorunda değildir ve vermesi de beklenmez: model, olası devam dizileri üzerinde bir olasılık dağılımı üretir, sistem de bu dağılımdan örnekler. Örnekleme rastgeleliği kapatılsa bile girdinin en küçük değişimi çıktıyı değiştirebilir.
Bu yüzden "çalışıyor mu" sorusu tek örnekle cevaplanamaz. Anlamlı soru şudur: temsilî bir girdi kümesinde kabul edilebilir çıktı oranı nedir ve bu oran kümenin hangi diliminde düşüyor? Ürün kararı artık yalnızca bir hata ayıklama işi değil, bir ölçüm ve eşik işidir.
İkinci fark kapsamda. Klasik bir formda girdi uzayı alanların tipiyle sınırlıdır; serbest metin kabul eden bir özellikte girdi uzayı pratikte sonsuzdur. Kapsamı tek tek girdilerle kapatmaya çalışmak boşa kürektir; kapsam girdi sınıflarıyla kapatılır: hangi niyet türleri var, hangi diller, hangi uzunluklar, hangi kötücül kullanım biçimleri.
Yeni hata sınıfları#
| Hata sınıfı | Nasıl görünür | Ürün tarafındaki sonucu |
|---|---|---|
| Uydurma | Kaynağı olmayan bilgi kendinden emin biçimde sunulur | Kaynak gösterimi ve kapsama beyanı zorunlu hale gelir |
| Sessiz yanlışlık | Çıktı biçimsel olarak kusursuz, içerik yanlış | Otomatik denetim yakalamaz; insan örneklemi gerekir |
| Biçim ihlali | Beklenen alan eksik veya tipi yanlış | Şema doğrulaması ve yeniden deneme akışı gerekir |
| Aşırı reddetme | Meşru istek gereksiz yere geri çevrilir | Kullanılabilirlik düşer; kaçış yolu tasarlanır |
| Talimat kaçırma | Girdideki metin sistem talimatının önüne geçer | Güvenilmeyen içerik veri olarak işaretlenir |
| Kayma | Aynı akış zamanla farklı sonuç verir | Sürüm ve tedarikçi değişimi ölçümle izlenir |
Ürün pratiğinde ne değişir#
- Kabul ölçütü tek örnek değil, tanımlı bir küme üzerindeki orandır.
- Şartname "şu düğme şunu yapar" değil, "şu girdi sınıfı gelirse şu davranış beklenir" biçiminde yazılır.
- Regresyon testi yerini örneklem tabanlı değerlendirmeye bırakmaz, onunla yan yana çalışır: biri çevredeki belirlenimci kodu, öteki üretilen içeriği ölçer.
- Hata ayıklama "kodun neresinde" sorusundan "hangi girdi sınıfında ve hangi katmanda" sorusuna kayar.
- Sürüm notu modelin kendisini değil davranış değişimini anlatır: hangi girdi sınıfında ne farklılaştı.
Karar: kapsamı nasıl kapatırsınız#
- 1Girdi sınıflarını listeleyin
Gerçek kullanıcı isteklerinden yola çıkarak niyet türlerini yazın ve her sınıfa bir ad verin.
- 2Her sınıf için beklenen davranışı yazın
Cevap ver, soru sor, reddet, insana devret — dördünden birini seçin; hiçbir sınıfı boş bırakmayın.
- 3Kapsam dışını açıkça yazın
Ürünün yapmayacağı işleri sözleşmeye ekleyin; yazılmayan kapsam dışı, kullanıcıda beklenti olarak kalır.
- 4Her sınıfa örnek girdi bağlayın
Sınıf başına birkaç gerçek örnek yeter; bunlar dördüncü bölümde kuracağınız ölçüm kümesinin çekirdeği olur.
Sık yapılan hata#
En yaygın yanılgı, olasılıksal davranışı bir kalite kusuru sanmak: "model kararsız, düzeltelim" cümlesi çoğu zaman yanlış teşhistir. Kararsızlık aracın çalışma biçimidir; ürün işi bunu sıfırlamak değil, kabul edilebilir oranı peşinen yazmak ve kullanıcının hata gördüğünde ne yapacağını tasarlamaktır. İkinci yaygın hata, tek bir başarılı gösterimi kanıt sayıp kapsamı hiç ölçmeden yayına çıkmaktır.
LAB · UYGULAMALI ALIŞTIRMA
Bir özelliği davranış sözleşmesine çevirin
- 1Ekibinizin üzerinde çalıştığı yapay zekâ özelliğini seçin ve gerçek kullanıcı isteklerinden yirmi tanesini bir tabloya yazın; elinizde yoksa destek kayıtlarından veya site içi arama sorgularından toplayın.
- 2İstekleri niyetlerine göre gruplayın; dört ile altı arası girdi sınıfı çıkana kadar birleştirip ayırın ve her sınıfa ad verin.
- 3Her sınıfın karşısına beklenen davranışı yazın: cevap ver, soru sor, reddet, insana devret.
- 4Aynı tabloya ikinci bir kolon açın ve her sınıfta en olası hata sınıfını işaretleyin: uydurma, sessiz yanlışlık, biçim ihlali, aşırı reddetme, talimat kaçırma.
- 5Kapsam dışı listesini yazın: ürünün bu sürümde yapmayacağı üç iş ve her biri için kullanıcıya verilecek yanıt.
- 6Tabloyu ekipteki bir mühendise ve bir destek çalışanına okutun; üçünüzün aynı fikirde olmadığı satırları işaretleyin.
Beklenen çıktı
Girdi sınıfı, beklenen davranış, olası hata sınıfı ve kapsam dışı kolonlarından oluşan tek sayfalık davranış sözleşmesi.
Sık sorulan sorular
Sıcaklığı sıfıra çekmek çıktıyı belirlenimci yapmaz mı?
Örnekleme rastgeleliğini büyük ölçüde azaltır ama sözleşmeyi belirlenimci yapmaz. Girdideki küçük bir değişim, sistem talimatındaki bir güncelleme veya tedarikçi tarafındaki bir sürüm değişimi çıktıyı yine değiştirir. Ayrıca çeşitliliğin işe yaradığı senaryolarda sıcaklığı sıfırlamak kaliteyi düşürür.
Klasik birim testleri artık gereksiz mi?
Hayır, yer değiştiriyor. Modelin çevresindeki her şey — biçim doğrulaması, araç çağrısı, yetki filtresi, yeniden deneme, zaman aşımı — belirlenimcidir ve birim testiyle test edilir. Örneklem tabanlı değerlendirme yalnızca modelin ürettiği içeriğin kalitesi için gerekir.
Kabul edilebilir hata oranını kim belirler?
Ürün, hata maliyetini taşıyan tarafla birlikte belirler; mühendislik tek başına belirlemez. Oranın gerekçesi teknik kapasite değil, hatanın kime ve ne kadara mal olduğudur. Bu bağın nasıl kurulacağı üçüncü bölümün konusu.
LEARN
AI Product Manager rotasına devam et
Dersler tek başına da okunabilir, ama sıralı ilerlemek önkoşul boşluklarını kapatır.