Bir yapay zekâ isteminde aynı anda “metni çok kısa tut”, “hiçbir ayrıntıyı çıkarma”, “yalnızca onaylı bilgiyi kullan” ve “eksik yerleri tamamla” denildiğinde talimatlar birbiriyle çatışabilir. Çıktı bu durumda rastgele uzayabilir, önemli bir koşulu atlayabilir ya da doğrulanmamış bir ayrıntıyı tamamlanmış gibi sunabilir. Sorun yalnızca kullanılan kelimelerde değildir; modelden hangi koşulun önce geldiği ve koşullar aynı anda karşılanamazsa ne yapacağı açıkça belirtilmemiştir. Özellikle müşteri, fiyat, teslimat, sağlık, finans veya hukuki kararları etkileyebilecek metinlerde son karar yetkisi ilgili kişide kalmalıdır.

Çelişkiyi sonuçtan önce tarif edin

İlk adım, “iyi yanıt” ifadesini gözlenebilir koşullara çevirmektir. “Kısa olsun” tek başına ölçülebilir değildir. Bunun yerine “en fazla 120 kelime” gibi bir sınır verilebilir. Fakat kaynak metinde korunması gereken altı ayrı koşul varsa, 120 kelime sınırı bunları açıklamaya yetmeyebilir. Bu durumda istem, hangi unsurun korunacağını ve diğer koşul karşılanamadığında ne yapılacağını söylemelidir.

Talimatları yazmadan önce istenen çıktı ile değiştirilemeyecek bilgileri ayırın. Örneğin taslak bir duyuruda tarih ve iptal koşulu sabit bilgi; ton ve paragraf sayısı ise düzenlenebilir tercih olabilir. Bu ayrım gerçek bir olay veya işletme iddiası değildir; yalnızca kurgusal bir çalışma örneğidir. Bir kural sabit bilgi olarak işaretlenmişse modelin onu kısalık uğruna silmesine izin verilmediği açıkça yazılmalıdır.

Talimatları üç düzeyde gruplayın

Basit bir öncelik sırası çoğu işte yeterli olur. Birinci düzey, doğruluğu ve yetki sınırını koruyan vazgeçilmez kurallardır: verilen kaynak dışından olgu eklememek, bilinmeyen bilgiyi uydurmamak ve gerekli uyarıyı silmemek. İkinci düzey, görevin tamamlanması için zorunlu içerik koşullarıdır: istenen ana noktalar, hedef kitle ve kullanılacak kaynak. Üçüncü düzey ise biçim tercihleridir: kısa anlatım, madde sayısı, ton veya başlık uzunluğu.

Bir görevde kaynak sadakati ile kısa olma çatışırsa, önce kaynak sadakatinin korunacağı; metnin kısaltılamadığı yerde ise sistemin bunu belirtip açıklama isteyeceği yazılabilir. Böylece model, görünmez bir tercih yapmak yerine hangi koşulu karşılayamadığını görünür kılar.

“Önce şunu koru, sonra bunu iyileştir” biçiminde yazın

Bir talimat yığını yerine sıralı bir çalışma emri kurun. Önce temel görevi belirtin. Sonra hangi bilgilerin değiştirilemeyeceğini söyleyin. Ardından düzenleme alanını tanımlayın. En son uzunluk ve biçim koşullarını verin. Bu akış, “her şeyi yap” şeklindeki belirsiz bir istekten daha iyi denetlenir; çünkü taslağı incelerken her sonucun hangi şartla ilgili olduğunu bulabilirsiniz.

Örnek bir iskelet şöyle olabilir: “Verilen metni müşteri bilgilendirme taslağına dönüştür. Yalnız kaynakta bulunan tarih, tutar ve koşulları kullan. Kaynakta olmayan yanıtı ekleme; alan eksikse [TEYİT GEREKİYOR] etiketi koy. Bu korumalar sağlandıktan sonra gereksiz tekrarları kısalt. Sonucu başlık ve iki paragraf olarak ver.” Buradaki köşeli etiket yalnız örnek bir işaretleyicidir; gerçek sistemde ekibin kolay tanıyacağı sabit bir ifade seçilebilir.

İmkânsız istek için güvenli çıkış tanımlayın

Bazen tüm koşullar aynı anda karşılanamaz. Verilen bir paragrafı 30 kelimeye indirmek, her istisnayı ve açıklamayı korumakla mümkün olmayabilir. İstem, bu durumda modelin hangisini feda edeceğini kendi başına seçmemesini söylemelidir. Örneğin “koşullar birlikte sağlanamıyorsa taslak üretme; çelişen iki şartı kısa biçimde bildir ve hangi şartın gevşetilebileceğini sor” yönergesi kullanılabilir.

Güvenli çıkış, boş bir yanıt veya genel bir özürden daha kullanışlı olmalıdır. Çelişkiyi adlandırmalı, eksik olan kararı göstermeli ve insanın devam edebilmesi için gereken bilgiyi istemelidir. Eğer iş akışı beklemeye izin vermiyorsa alternatif olarak “yalnız doğrulanmış bölümleri hazırla, teyit gerektiren alanları ayrı listele” denebilir. Bu yaklaşım, tamamlanmamış bölümü tamamlanmış gibi göstermeyi önlemeye yardımcı olur; sonucu garanti etmez.

Değiştirilebilir ve sabit alanları ayırın

İstem içinde sabit alanları açık etiketlerle ayırmak, düzenleme sırasında korunması gerekenleri görmeyi kolaylaştırır. Örneğin “Sabit: ürün adı, onaylı ücret, son tarih. Düzenlenebilir: giriş cümlesi, geçiş ifadeleri ve kapanış tonu.” Sabit alanda hata görülürse modelden bunu düzeltmesini değil, bildirmesini isteyin.

Şablon değişkenleri kullanılıyorsa bunların doldurulmamış halini de tarif edin. “{TESLİM_TARİHİ}” boşsa tahmin yürütme; taslağı durdur ve alanı sor gibi bir kural, modelin eksik alanı kendiliğinden doldurması riskini azaltmaya yardımcı olur; oluşan çıktıyı yine kontrol edin. Bir değişkenin bazen boş kalması normal olabilir; o zaman boş değerin çıktıda gösterilip gösterilmeyeceğini, alternatif metnin kullanılıp kullanılmayacağını ve kimden teyit alınacağını belirtin.

Önceliği küçük örneklerle sınayın

İstem hazır olduğunda yalnız ideal örnekle yetinmeyin. İki veya üç kısa sınama durumu oluşturun: bütün bilgi mevcut; kritik bilgi eksik; uzunluk sınırıyla zorunlu içerik çatışıyor. Her durumda beklenen davranışı önceden yazın. Örneğin eksik tarih varsa tarih uydurmamak, kısa sınır yüzünden iptal koşulu çıkarılamıyorsa çelişkiyi bildirmek beklenen sonuç olabilir.

Sınama örneğinin yapay ve kurgusal olduğunu açık tutun; gerçek müşteri verisini veya özel bilgiyi gereksiz yere kullanmayın. Aynı örnek üzerinde istemi bir kez değiştirip sonucu karşılaştırın. Birden çok kuralı aynı anda değiştirirseniz hangi değişikliğin davranışı etkilediği anlaşılmaz. Deneme kaydında istem sürümü, verilen örnek, beklenen davranış, gerçekleşen davranış ve değerlendiren kişi bulunabilir.

Çıktıyı kontrol edilebilir bir sırayla inceleyin

İncelemeyi önce sabit bilgilerden başlatın: tarih, isim, miktar, koşul ve bağlantı kaynakla aynı mı? Sonra yasaklanan bir ekleme yapılmış mı diye bakın. Ardından zorunlu ana noktaların tamamının bulunup bulunmadığını kontrol edin. En son ton, uzunluk ve biçimi değerlendirin. Böylece düzgün görünen bir metnin içinde kritik bir bilginin değişmiş olması, yalnızca üslup kontrolüne takılıp kalmaz.

Kontrol sonucu ikili bir “iyi/kötü” notundan ibaret olmak zorunda değildir. “Kaynağa uygun”, “teyit bekliyor”, “koşullar çatışıyor” veya “yeniden düzenlenecek” gibi durumlar ekip içi izleme için daha açıklayıcı olabilir. Her durumun kim tarafından verileceğini belirleyin. Modelin kendi çıktısına verdiği uygunluk beyanını bağımsız doğrulama olarak kabul etmeyin; kontrolü kaynak ve görev sahibi yapmalıdır.

Sürüm ve değişiklik kaydı tutun

İstem değiştiğinde önceki sürümün ne işe yaradığını ve neden düzenlendiğini saklayın. Yeni sürümü kısa bir adla numaralandırın; değişen kuralı, beklenen etkiyi ve yeniden çalıştırılacak sınama örneklerini kaydedin. Küçük bir değişiklik bile daha önce çalışan bir sınır kuralını etkileyebilir. Sürüm kaydı yoksa ekip, hangi istemin hangi çıktıyı ürettiğini sonradan ayırt edemez.

Bir değişikliği devreye almadan önce daha önce kullanılan örnekleri tekrar çalıştırmak yararlıdır. Ama birkaç başarılı örnek, bütün olası girişlerde aynı davranışın olacağını kanıtlamaz. Bu nedenle kayıt “kontrol edildi” diyebilir; “her durumda hatasız” sonucunu çıkarmamalıdır. Özellikle farklı kullanıcı grupları, uzun girdiler veya eksik alanlar söz konusuysa yeni sınama durumlarını ekleyin.

Ekibin kullanabileceği kısa istem şablonu

Görev: [beklenen çıktı]. Kaynak: [kullanılabilecek metin veya veri]. Vazgeçilmezler: [değiştirilmeyecek bilgiler ve yetki sınırları]. Düzenleme alanı: [değiştirilebilecek ton veya anlatım]. Biçim: [uzunluk ve çıktı yapısı]. Öncelik: koşullar çatışırsa önce vazgeçilmezleri, sonra görev kapsamını koru; biçim tercihini ancak bunlar sağlandığında uygula. Eksik bilgi: uydurma; [TEYİT GEREKİYOR] olarak işaretle veya soru sor. Başarısızlık davranışı: koşullar birlikte sağlanamıyorsa çelişkiyi söyle, kendi başına seçim yapma. Kontrol: yanıtı kaynakla karşılaştır ve sabit alanları ayrıca listele.

Bu şablonu aynen her işte kullanmak gerekmez. Görev basitse kısa bir sürüm yeterli olabilir. Kritik bir bilgi taşınıyorsa, sabit alanları örnek metnin içine gömmek yerine görünür başlıklarla belirtmek incelemeyi kolaylaştırır. İstem uzadıkça daha güvenilir hale gelmez; her satırın gerçek bir amacı bulunmalı, birbiriyle aynı şeyi söyleyen veya çakışan kurallar ayıklanmalıdır.

Uygulama öncesi kontrol listesi

Görev, kaynak ve istenen çıktı ayrı ayrı yazıldı mı?
Değiştirilemeyecek bilgiler ile biçim tercihleri birbirinden ayrıldı mı?
Talimatlar çatıştığında hangi kuralın önce geleceği açık mı?
Eksik veya belirsiz bilgi için uydurma yerine kullanılacak bir çıkış tanımlandı mı?
En az bir eksik bilgi ve bir koşul çatışması örneğiyle sınama yapıldı mı?
Kontrolü kimin yapacağı ve hatalı taslağın nasıl geri döneceği belirlendi mi?
İstem sürümü ve yapılan değişiklik kayda geçirildi mi?

Bu kontroller bir otomasyon ya da sonuç garantisi değildir; ekip içinde kararların görünür kalmasını sağlayan çalışma adımlarıdır. Canlı iş akışında taslakların kim tarafından onaylanacağı, ne zaman yayıma geçeceği ve hatanın kime aktarılacağı ayrıca belirlenmelidir. Özellikle gerçek kişi veya kurumu etkileyen içerikler, son kez sorumlu kişi tarafından incelenmeden yayımlanmamalıdır.

Sık sorulan sorular

Bir istemde iki talimat çelişiyorsa yapay zekâ hangisini seçer?

Önceden açık bir öncelik sırası yazılmadıysa sonuç değişebilir. Bu nedenle hangi bilginin korunacağı, hangi tercihin esneyebileceği ve ikisi birlikte sağlanamıyorsa modelin soru sorması gerektiği belirtilmelidir. Son çıktıyı yine görev sahibi denetlemelidir.

Öncelik sırası her istemde uzun uzun açıklanmalı mı?

Hayır. Basit bir düzeltmede kısa yönerge yeterli olabilir. Fakat kaynakta korunması gereken bilgi, eksik alan veya birbiriyle çelişen biçim koşulları varsa bunları açıkça sıralamak sonradan düzeltme ihtiyacını azaltır.

Kısa yanıt isteği önemli bilgileri çıkarmaya izin verir mi?

İstem bunu açıkça söylemiyorsa, kısalık talebinin hangi noktaya kadar uygulanacağı belirsizdir. “Zorunlu bilgileri koru, yalnız tekrarları kısalt; sınır yetmiyorsa eksikliği bildir” gibi bir kural, önemli koşulların sessizce atılmasını engellemeye yardımcı olur.

Eksik bir tarih veya ücret için nasıl yönerge vermeliyim?

Kaynakta yoksa tahmin edilmemesini ve taslağın teyit beklemesini belirtin. Kullanılan işaretleyiciyi ekipçe tanınır seçin ve kimin bu alanı dolduracağını tanımlayın. Sonradan işaretleyicinin yayımlanan metinde kalıp kalmadığı ayrıca kontrol edilmelidir.

Modelden çelişkiyi kendi başına çözmesini isteyebilir miyim?

Yalnızca tercihlerin gerçekten önceliklendirilmesi güvenliyse ve bu sıra sizin tarafınızdan verildiyse. Doğruluğu, kapsamı veya yetkiyi etkileyen bir çelişkide modelin varsayım kurması yerine durup soru sormasını istemek daha izlenebilir bir iş akışı sağlar.

İstem şablonu yanlış bilgiyi tamamen önler mi?

Hayır. Şablon kuralları görünür kılar ve kontrolü kolaylaştırabilir; fakat her girdide aynı biçimde çalışacağını garanti etmez. Kaynakla karşılaştırma, kritik alanların elle kontrolü ve hata halinde taslağın durdurulması gerekir.

Öncelik değiştiğinde eski sınama örneklerini neden yeniden çalıştırmalıyım?

Yeni kural, önceki davranışı beklenmedik biçimde değiştirebilir. Aynı örneği eski ve yeni istemle karşılaştırmak farkı görünür kılar. Bu karşılaştırma kapsamlı kanıt değildir; yalnızca bilinen durumlarda değişikliği incelemeye yarar.

Hatalı çıktı bulunduğunda ne kaydedilmelidir?

İstem sürümü, sınama girdisi, beklenen davranış, gerçekleşen fark ve alınan karar kaydedilebilir. Gerçek kişisel veya gizli bilgileri gereksiz yere notlara eklemeyin. Kayıt, hatanın yeniden üretilmesine yetecek kadar açıklayıcı olmalıdır.

Yapay zekâ çıktısı ön onay olmadan yayımlanabilir mi?

Bu, kuruluşun iş akışı ve içeriğin riskine bağlıdır. Müşteriye, fiyata veya taahhüde dokunan metinlerde yetkili kişinin onayı açıkça tanımlanmalıdır. İstemin uygun görünmesi, yayıma izin verildiği anlamına gelmez.

İlgili rehberler

İçeriğin kaynağını talimatlardan ayırma konusunda kaynak ve talimat ayrımı rehberi yardımcı olabilir. Mevcut metinleri ölçütlerle değerlendirmek için taslak inceleme rehberini, çıktı alanlarını yapılandırmak için şemaya uygun çıktı kontrolünü inceleyin. Hizmet kapsamı için dijital pazarlama sayfasına bakabilirsiniz.