İleri istem teknikleri

Bu beş basamak nedir ve üst basamak ne demek

Bu dersteki beş tekniğin hepsi tek bir şey yapar: isteme, orada olmayan bir şey ekler. Örneksiz, yalnızca sormak demektir. Örnekli, birkaç doğru girdi ve çıktı çiftini de koymak demektir. Düşünce zinciri, yanıttan önce adımları istemek demektir. Yapılandırılmış çıktı, yanıtın biçimini bir programın okuyabileceği şekilde sabitlemek demektir. Sistem istemi ise her mesaja uygulanan ve her seferinde tekrarlanmayan kurallar demektir.

Çoğu anlatımın kaçırdığı nokta şu: bu merdiven bir kalite ölçeği değil. Üst basamak daha iyi bir yanıt vermez, daha büyük bir istem yapar. Çıktığınız her basamak üç şey ekler: token, gecikme ve yanlış olabilecek bir şey daha. Kendi kurallarınızla çelişen bir örnek, örneksizlikten kötüdür.

Yani çalışma kuralı şu: birinci basamaktan başlayın ve ancak bir çıktı size nerede yetersiz kaldığını gösterdiğinde çıkın. Gerçek işteki her beş istemin dördü birinci basamakta kalır ve bu, acemilik işareti değildir.

Örnek vermek: kaç tane yeter ve ne zaman ters teper

Few shot terimi, OpenAI'ın 2020 tarihli "Language Models are Few-Shot Learners" başlıklı makalesinden geliyor ve fikri basit: işi tarif etmek yerine ondan birkaç örnek gösterin. Biçimi tarif edilmekten kolay görülen işlerde bu basamak gerçekten işe yarar: sınıflandırma, ton ve ayrıntısı çok olan her kalıp.

Gerçek bir örnek. Gelen müşteri mesajlarını dört kovaya ayırmak istediğinizi varsayın. Örneksizken istem "bu mesajı şu dört kovadan birine koy" der; model çoğunu doğru yapar ve sınırdakilerde kendi kafasına göre davranır. Örnekliyken o sınırdakileri siz seçersiniz:

Mesaj: Merhaba, 123 numaralı sipariş dün geldi ama kutu ezikti. İçindeki ürün sağlam.
Kova: şikayet

Mesaj: 123 numaralı sipariş ne zaman gelir, söyleyebilir misiniz?
Kova: sipariş durumu

Mesaj: Merhaba. Geçen aldığımdan üç tane daha istiyorum.
Kova: yeni sipariş

Bu üç satırın değeri, yazıya dökemediğiniz şeyde: "kutu ezik, ürün sağlam" durumunun yine de şikayet sayılması genel bir kural değil, sizin kararınız. Örnekler tam da o sınır kararlarını taşır.

Kaç tane olacağına gelince, sihirli bir sayı yok ve size bir sayı veren kişi tahmin yürütüyordur. OpenAI'ın akıl yürüten modeller için kendi yönergesi önce örneksiz denemeyi, gerekirse örnek eklemeyi söylüyor ve aynı sayfada örneklerin yönergelerle sıkı sıkıya uyuşması gerektiği uyarısını yapıyor; çünkü ikisi arasındaki tutarsızlık kötü çıktı üretiyor.

Örneklerin ters teptiği üç yer: hepsi tek bir kovadan geldiğinde model o dağılımı kopyalar; bir örnek kendi kurallarınızdan biriyle çeliştiğinde model kurala değil örneğe inanır; ve örnekler gerçek müşteri verisinden alındığında, o veri bundan sonra her çalıştırmada birlikte yolculuk eder.

Düşünce zinciri nereden geldi ve bugün neden daha az gerekiyor

Ocak 2022'de Google araştırmacılarından "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" başlıklı bir makale çıktı. İddiası şuydu: örnekleriniz yanıta giden ara adımları da gösterirse, yeterince büyük modeller aritmetik ve mantık problemlerinde daha iyi sonuç veriyor. "Adım adım düşün" ifadesi bütün anlatımlara o makaleden girdi.

Yaklaşık beş yıl sonra üreticilerin kendi yönergeleri başka bir şey söylüyor. OpenAI'ın akıl yürüten modellerden en iyi verimi almaya dair sayfası, istemleri sade ve doğrudan tutmayı ve düşünce zinciri istemlerinden kaçınmayı söylüyor; çünkü bu modeller akıl yürütmeyi içeride yapıyor ve onlara adım adım düşünmelerini söylemek gereksiz. Anthropic'in genişletilmiş düşünme belgeleri de betimleyici adımlar yerine genel yönergeleri tercih etmeyi söylüyor: "iyice düşün" gibi bir istem, çoğu zaman elle yazılmış adım adım bir plandan daha iyi akıl yürütme üretiyor.

Yani teknik yanlış hale gelmedi; yer değiştirdi. Modelin içine girdi. İki yer onu hâlâ istiyor: iç akıl yürütmesi olmayan daha küçük ve eski modeller ve adımları tartışabilmek için görmek istediğiniz her durum. İkincisi iyi bir gerekçedir ve gerekçesi yanıt kalitesi değil denetimdir.

Nadiren okuyacağınız bir uyarı: modelin yazdırdığı adımlar, içinde olup bitenin raporu değildir. O metin de geri kalan metinle aynı yolla üretildi. Yanıt doğru olup adımlar alakasız olabilir ya da adımlar ikna edici olup yanıt yanlış olabilir. Onu size sunulan bir açıklama sayın, damgalı bir makbuz değil. Bu bizim tutumumuz ve büyük dil modeli dersinde anlatılan mekanizmadan çıkıyor.

Sayfanın üstündeki tarihi ciddiye alın. Burada hızla dönen şey tam da üretici yönergeleridir ve bu paragraf, bir yıl sonra yarısı yanlış olabilecek türden bir iddiadır.

Yapılandırılmış çıktı: yanıt bir programa girecekse

Gerçek işte neredeyse her zaman kendini amorti eden tek basamak budur ve nedeni metin kalitesi değil: sabit biçimli bir yanıt makineyle denetlenebilir. Çıktı akıcı bir paragraf olduğu sürece onu değerlendirmenin tek yolu okumaktır. Çıktı adlandırılmış anahtarları olan bir kayıt olduğunda, beş satır kod size hangi kaydın bozuk olduğunu söyler.

Bunu almanın iki yolu var ve aralarındaki fark önemli. Birincisi biçimi istemde istemek ve ummak. İkincisi üreticilerin bunun için kurduğu, çıktıyı belirli bir şemaya bağlayan kipi kullanmak; Anthropic ve Google bunun için ayrı belgeler tutuyor. Bir API üzerinden çalışıyorsanız ikincisini seçin. Sohbet penceresinde çalışıyorsanız birincisi tek seçeneğinizdir ve o zaman çıktıyı denetlemek tek garantinizdir.

Farsça ve Arapça yazanlara özgü, hiçbir İngilizce belgede bulamayacağınız bir tuzak: kurallarınız "1 ile 3 arasında bir sayı" ifadesini o dillerin rakamlarıyla yazarsa, model de o rakamlarla yanıtlayabilir ve çıktı geçerli JSON olmaktan çıkar, çünkü JSON yalnızca Latin rakamlarını kabul eder. Çözümü tek cümle: kuralda rakamların Latin olacağını söyleyin. Bunu aşağıdaki reçeteye koyduk.

Ve tekniğin kendisinden değerli bir alışkanlık: yapılandırılmış bir çıktının, geri alınması zor bir şeyi doğrudan yapmasına asla izin vermeyin. Müşteriye e-posta göndermek, iade kaydı açmak, fiyat değiştirmek. Çıktı ile eylem arasına bir insan koyun; en azından yüz gerçek kayıtta denemiş olana kadar.

Sistem istemi: her seferinde tekrarlamadığınız kurallar

Sistem istemi, işinizin kalıcı kurallarının durduğu ve o konuşmadaki her mesaja uygulanan yerdir. API'de ayrı bir parametredir ve Anthropic bunun için ayrı bir belge sayfası tutar. Sohbet ürünlerinde ise özel yönergeler ya da proje yönergeleri gibi adlarla karşınıza çıkan şeydir.

Oraya ait olanlar: kim olduğunuz ve kimin için yazdığınız, hiç değişmeyen kısıtlar ve asla madde işaretli liste istememek gibi çıktı gelenekleri. Oraya ait olmayanlar: tek bir işin ayrıntıları, her istekte değişen her şey ve elbette hiçbir parola veya anahtar.

Çoğu anlatımda bulunmayan bir nokta: sistem istemi bir güvenlik sınırı değildir. Modelin genellikle uyduğu bir kuraldır, hiçbir şeyin geçemediği bir duvar değil. Bir sonraki mesajınızda yapıştırdığınız metin, bir web sayfasının içeriği ya da bir müşteri mesajı, içinde kurallarınızla çelişen bir yönerge taşıyabilir. Bu sayfanın aşağısındaki blokta doğru adıyla anılan şey budur.

Bu teknikleri nereye koymamalı

Merdivene çıkmanın yalnızca maliyet olduğu dört durum var. Birincisi tek seferlik iş: bir kez yaptığınız şey örneklere, bir şemaya ve sistem istemine değmez; sorun, yanıtı okuyun, bitti. İkincisi sorun bilgi eksikliğiyken: doğru yanıt modelin sahip olmadığı bir veriye ihtiyaç duyuyorsa hiçbir basamak onu yaratmaz ve çözüm veriyi vermektir.

Üçüncüsü çıktı bir programa değil bir insana gidiyorken. Yapılandırılmış çıktı orada yalnızca sürtünme ekler ve metni katılaştırır. Dördüncüsü ve en büyüğü: sonucu denetleyecek hiçbir yolunuz yokken. Daha çok teknik, yanlış bir yanıtı daha kendinden emin ve daha düzenli gösterir; bu da onu daha tehlikeli yapar. Doğru bir çıktının neye benzediğini söyleyemiyorsanız, önce onu çözün.

Tekrarlamaya değer bir özet: bu beş basamaktan gündelik işte getirisi en yüksek olanı yapılandırılmış çıktıdır, çünkü kaliteyi ölçülebilir kılan tek basamak odur. Diğerleri kaliteyi değiştirir, ölçmeyi olduğu yerde bırakır.