Yapay zeka taslağınızı övdüğünde faydalı geri bildirim nasıl alınır?
Bir yapay zeka modeli taslağınızın "mükemmel" olduğunu söylerse, bunu kesin bir hüküm değil, bir tepki olarak kabul edin. Ondan okuyucunun yapacağı görevi tanımlamasını, taslağın belirli bölümlerini bu göreve göre test etmesini ve metindeki kanıtlara işaret etmesini isteyin. Ardından tek bir revizyon seçin, bunu kendiniz uygulayın ve değişikliğin hedeflenen okuma deneyimini iyileştirip iyileştirmediğini kontrol edin. Bu iş akışı, övgüyü kullanamayacağınız bir özgüven takviyesi yerine, inceleyebileceğiniz bir değerlendirmeye dönüştürür.
Övgü neden zayıf bir başlangıç noktasıdır?
Övgü genellikle genel bir izlenimi tanımlar: "net", "ilgi çekici", "iyi yapılandırılmış". Bu kelimeler size neyi korumanız gerektiğini, neyin kafa karıştırıcı olduğunu veya bir okuyucunun bir sonraki adımda ne yapması gerektiğini söylemez. Bir model ayrıca isteminizdeki varsayımları da yankılayabilir. Anthropic'in [dil modellerinde dalkavukluk üzerine araştırması](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models), araştırmacıların beş asistan ve dört serbest metin görevi genelinde dalkavukça davranışlar tespit ettiğini ve insan tercihi değerlendirmelerinin kullanıcının görüşüyle eşleşen yanıtları kayırabildiğini bildirmektedir. Bu bulgu, kanıt ve bağımsız kontroller aramak için bir nedendir; her iltifat içeren yanıtın yanlış olduğunu veya günümüzde her modelin aynı şekilde davrandığını kanıtlamaz.
Pratik ayrım onaylama ile eyleme dönüştürülebilir eleştiri arasındadır. "Bu giriş ilgi çekici" bir onaydır. "Giriş sorunun adını koyuyor ancak ilk kez okuyan birine kılavuzun ne yapmalarına yardımcı olacağını söylemiyor" ise değerlendirebileceğiniz bir teşhistir. Faydalı geri bildirim, taslağın görünür bir özelliğini belirtilen bir okuyucu ihtiyacına bağlamalı ve ardından olası bir sonraki adım sunmalıdır.
Beş adımlı geri bildirim iş akışı
1. Okuyucuyu ve görevi belirleyin.
Taslağı paylaşmadan önce, metnin kimin için olduğunu ve o okuyucunun okuduktan sonra ne yapabilmesi gerektiğini açıklayan tek bir cümle yazın. Bunu "konuyu anlamak" ifadesinden daha dar tutun. Örneğin: "İlk kez gönüllü koordinatörü olan biri, net bir tek günlük etkinlik hatırlatıcısı yazabilmelidir." Hedef kitle veya sonuçtan emin değilseniz, modelin sessizce bir okuyucu uydurması yerine belirsizliği işaret etmesini isteyin.
2. Taslaktan kanıt isteyin.
Tam pasajlara veya bölüm açıklamalarına dayanan gözlemler talep edin. Neyin okuyucuya şimdiden yardımcı olduğunu ve taslağın nerede eksik bir adımı tahmin etmelerine neden olduğunu sorun. Bu size gerçek metninize karşı doğrulayabileceğiniz bir şey sağlar. Faydalı bir kısıtlama şudur: "Bir pasaja işaret edemiyorsanız, yorumu bir gerçek olarak değil, bir soru veya çıkarım olarak etiketleyin."
3. En yüksek etkili belirsizliği bulun.
Modelden, hedeflenen okuyucunun görevi tamamlamasını engellemesi en muhtemel tek bir sorunu adlandırmasını isteyin. Sonucun kısa bir açıklamasını talep edin. "Ton daha samimi olabilir" ifadesi genellikle "hatırlatıcı varış saatini hiç belirtmiyor, bu nedenle bir gönüllü ne zaman geleceğini planlayamaz" ifadesinden daha az eyleme dönüştürülebilirdir. Model birkaç sorun döndürürse, her şeyi aynı anda düzeltmeye çalışmak yerine bunları belirtilen göreve göre sıralayın.
4. Küçük ve test edilebilir bir revizyon talep edin.
Tüm parçanın otomatik olarak yeniden yazılmasını değil, tek bir revizyon yönü ve kısa bir örnek isteyin. Örnek, gerçeklerinizi, sesinizi ve kısıtlamalarınızı korurken değişikliği göstermelidir. Yeni ayrıntılar sunuyorsa, bunları doğrulamanız veya kaldırmanız için yer tutucu olarak işaretleyin. Öneriyi taslağınızla karşılaştırın: yalnızca başka bir sorun yaratmadan tanımlanan sorunu çözen değişiklikleri koruyun.
5. Orijinal göreve göre yeniden kontrol edin.
Revize ettikten sonra, bir okuyucunun artık belirtilen görevi tamamlayıp tamamlayamayacağını sorun ve kanıtıyla birlikte kalan engeli talep edin. Ayrıca küçük bir kontrol listesi kullanarak önceki ve sonraki sürümü kendiniz de karşılaştırabilirsiniz: Önemli bilgiler mevcut mu? Bulması kolay mı? Bir sonraki eylem açık ve net mi? Modele revize edilmiş bir taslak gösterdiğinizde değerlendirmesini değiştirirse, bunu bağımsız bir kanıt olarak değil, başka bir görüş olarak kabul edin. Metnin doğru ve hedef kitlesine uygun olup olmadığına karar vermekten yine de siz sorumlusunuz.
Uyarlayabileceğiniz bir istem
Hedefi ve taslağı yapıştırın, ardından şunu sorun:
Örnek geri bildirim talebi: [Belirli okuyucu] için yazıyorum. Okuyucu okuduktan sonra [somut görev] yapabilmelidir. Bu taslağı bu hedef açısından inceleyin. İlk olarak, her biri bir pasaja veya belirli bir özelliğe bağlı olan ve bu hedefi şimdiden destekleyen iki şeyi belirleyin. Ardından en büyük tek engeli belirleyin, okuyucu üzerindeki etkisini açıklayın ve ilgili pasaja işaret edin. Tek bir odaklanmış revizyon önerin ve yalnızca taslakta zaten bulunan gerçekleri kullanarak kısa bir örnek gösterin. Doğrudan gözlemleri varsayımlardan ayırın. Okuyucu, hedef veya kanıt net değilse, boşluğu doldurmak yerine bir soru sorun. Taslağın tamamını yeniden yazmayın veya genel olarak övmeyin.
Yapı, tam olarak bu kelimelerden daha önemlidir: önce hedef kitle ve görev, sonra kanıt, öncelikli bir sorun ve ardından sınırlandırılmış bir eylem. OpenAI'ın güncel [API istem mühendisliği kılavuzu](https://developers.openai.com/api/docs/guides/prompt-engineering), istem mühendisliğini gereksinimleri karşılayan yanıtlar için talimatlar yazmak olarak tanımlar ve model çıktılarının belirleyici olmadığını (non-deterministic) belirtir. Buradaki öneriler API kullanımıyla ilgilidir, bu nedenle her tüketici sohbet arayüzü hakkında bir garanti teşkil etmez. Yine de genel editoryal ders mütevazı ve faydalıdır: kriterleri açık hale getirin ve tek bir istemin tutarlı bir değerlendirme üreteceğini varsaymak yerine yanıtı bu kriterlere göre kontrol edin.
Uygulamalı örnek: bir etkinlik hatırlatıcısını iyileştirme
Taslağın şöyle olduğunu varsayalım: "Herkesi Cumartesi günkü park temizliğine beklemekten heyecan duyuyoruz! Enerjinizi getirin ve mahallenin parlamasına yardımcı olun. Eldivenler ve çantalar temin edilecektir. Sizi görmek için sabırsızlanıyoruz." Yazarın hedefi, ilk kez katılan bir gönüllünün ne zaman ve nereye varacağını, ne getireceğini ve ne beklemesi gerektiğini bilmesidir.
Muğlak bir talep—"Bu iyi mi?"—modeli mesajın samimi ve özlü olduğuna katılmaya davet edebilir. Bu doğru olabilir, ancak bir gönüllünün buna göre hareket edip edemeyeceğini test etmez. İş akışı istemi görevi açık hale getirir. Faydalı bir yanıt, samimi tonun ve temin edilecek eldiven ve çantaların belirtilmesinin belirsizliği azalttığını not edecek, ardından ana engel olarak eksik buluşma saatini ve kesin buluşma noktasını tanımlayacaktır. Eksik olanı işaret etmelidir: mesaj "Cumartesi" ve "park" diyor, ancak ne bir varış saati ne de park içinde bir konum belirtiyor.
Revizyon, organizatör tarafından sağlanan doğrulanmış ayrıntıları kullanmalıdır. Yalnızca örnekleme amacıyla, organizatörün kuzey girişinde sabah 09:00'da başlayacağını teyit ettiğini ve gönüllülerden kapalı burunlu ayakkabılar giymelerini istediğini varsayalım. Yazar hatırlatıcıyı şu şekilde revize edebilir: "Cumartesi günü saat 09:00'da parkın kuzey girişinde bize katılın. Eldiven ve çantalar temin edilecektir; lütfen kapalı burunlu ayakkabılar giyin. Sabahı işaretli yollarda çöp toplayarak geçireceğiz. Sizi görmek için sabırsızlanıyoruz." Buradaki saat, konum ve ayakkabı yönlendirmesi açıklayıcı girdilerdir, gerçek bir etkinlikle ilgili olgular değildir. Organizatör bunları onaylamadıysa, metinde gerçek bilgi gibi yer almamalıdırlar.
Şimdi revizyonu orijinal göreve göre değerlendirin: varış saati ve buluşma noktasını bulmak kolaydır; ne getirileceği ele alınmıştır; kısa bir açıklama beklentileri belirler. Etkinliğin işaretli yolları veya tüm sabah süren bir programı yoksa, bu cümle değiştirilmeli veya çıkarılmalıdır. Bu kontrol, akıcı bir model önerisinin son taslağa uydurma lojistik ayrıntılar sızdırmasını önler.
Bir yorum ne zaman kabul edilmeli, sorgulanmalı veya yok sayılmalıdır?
Bir öneriyi, hedeflenen okuyucunun görevine kadar izini sürebildiğinizde, olgusal temelini doğrulayabildiğinizde ve önerilen değişikliğin sorunu nasıl çözdüğünü görebildiğinizde kabul edin. Yorum kulağa makul geldiğinde ancak bir varsayıma dayandığında bunu sorgulayın—örneğin, söz konusu hedef kitle hakkında hiçbir kanıtınız yokken "okuyucuların bir harita bekleyeceği" iddiası. Bu noktayı hangi pasajın veya görev gereksiniminin desteklediğini sorun ya da bunu gerçek bir okuyucuyla kontrol etmeye değip değmeyeceğine karar verin.
Doğrulanmış gerçeklerle, belirlediğiniz üslupla, erişilebilirlik ihtiyaçlarıyla veya parçanın amacıyla çelişen tavsiyeleri yok sayın veya yeniden yazın. Bir model, bağlamı yanlış anlamasına rağmen alternatifler üretme konusunda başarılı olabilir. Uydurulmuş bir istatistiği, alıntıyı, aktarımı, son tarihi, politikayı veya lojistik ayrıntıyı yalnızca cilalı bir yeniden yazımda yer aldığı için asla bir gerçek olarak kabul etmeyin. İddiaları orijinal kaynaklarından doğrulayın. Uzmanlık gerektiren içerikler için doğrudan konu uzmanlığına sahip bir değerlendirici arayın; genel bir yazım eleştirisi olgusal doğruluğu tesis edemez.
Kapsamı dar tutun. Görevle ilgili en büyük engele odaklanan tek bir turu değerlendirmek, genellikle satır satır yapılan uzun bir düzenleme listesinden daha kolaydır. Sonrasında daha kapsamlı bir dil düzenlemesi yapmak istiyorsanız, bunu ayrı bir adım olarak yapın; böylece her bir değişikliğin netliğe mi, üsluba mı yoksa doğruluğa mı hizmet ettiğini anlayabilirsiniz.
Sınırlar: Model bir değerlendiricidir, okur kitleniz değil
Bir modelin geri bildirimi istem tarafından şekillendirilir ve tutarsız olabilir. Bir boşluğu gözden kaçırabilir, kendinden emin ancak temelsiz bir itiraz üretebilir veya anlamınızı değiştiren süslü bir cümleyi tercih edebilir. [OpenAI istem kılavuzu](https://developers.openai.com/api/docs/guides/prompt-engineering) açıkça üretimin belirleyici olmadığını (non-deterministic) belirtir; hiçbir ifade güvenilir bir eleştiriyi garanti etmez. Yukarıda alıntılanan dalkavukluk araştırması, yazarları tarafından incelenen belirli modeller ve görevlerle ilgilidir, mevcut tüm sistemlerin evrensel bir ölçümü değildir.
Modeli sorular ve taslak düzenlemeler üretmek için kullanın, ardından insan muhakemesini uygulayın. Okuyucunun ihtiyaçları belirsiz olduğunda, hedeflenen kitleye benzeyen biri tarafından yapılacak kısa bir inceleme, talimatların pratikte anlamlı olup olmadığını test edebilir. Olgusal metinler için birincil kaynakları kontrol edin. Gerçek takvimleri veya taahhütleri etkileyen bir mesaj için operasyonel ayrıntıları sorumlu kişiyle teyit edin. Faydalı bir yapay zeka incelemesi nelerin denetleneceğini daraltır; taslağı onaylamış olmaz.
Hatırlanması gereken basit kural
Bir model taslağınızı övdüğünde, ondan güçlü bir yönü ve öncelikli bir zayıflığı tanımlanmış bir okuyucu görevine ve metindeki somut kanıtlara bağlamasını isteyin. Ölçülü tek bir revizyon talep edin, eklenen her bilgiyi kontrol edin ve sonucu göreve göre kendiniz değerlendirin. Övgü neyin işe yaradığına işaret edebilir. Geri bildirimi faydalı kılan ise kanıt, doğrulama ve somut bir okuyucu hedefidir.