Prompt mühendisliğindeki gelişmeler: büyük dil modellerinden en iyi sonucu almanın geleceği

Prompt hilelerinden konuşma mühendisliğine

Büyük dil modelleri yazabilir, soruları yanıtlayabilir, özetleyebilir ve akıl yürütebilir. Ama sesli bir agent'ın makul bir cümle kurmaktan fazlasını yapması gerekir. Arayanın niyetini bulmalı, operasyon sınırının içinde kalmalı, bir araç çağrısının gerekli olup olmadığına karar vermeli ve ses tur tur gelirken konuşmayı ilerletmeli. 50-100 kişilik bir şirket için bu pratik bir mühendislik disiplinidir. Küçük bir ekibin, gerçek bir iş akışını taşıyacak kadar tutarlı davranan bir agent'a ihtiyacı vardır; onu iyileştirmenin yolu da en son paragrafı kimin düzenlediğine bağlı olmamalıdır.

Bu yüzden prompt mühendisliği daha geniş bir pratiğin yalnızca bir katmanıdır. Konuşma mühendisliği talimatları, söz sırasını, araçları, bağlamı, sonuçları ve incelemeyi birbirine bağlar. Zero-shot talimatlar ilk taslak için hâlâ işe yarar, few-shot örnekler tercih edilen bir kalıbı somutlaştırabilir, rol ya da persona tanımı da uygun bir ses tonu kurabilir. Bu tekniklerin hiçbiri tanımlı bir sınırın ya da test edilebilir bir sonucun yerini tutmaz. Asıl soru bir prompt'un kulağa gelişmiş gelip gelmediği değil, konuşmanın bütününün normal ve zor koşullarda doğru sonraki adımı üretip üretmediğidir.

Canlıdaki prompt'u katman katman kurun

Her katmanın tek bir işi olduğunda canlıdaki bir prompt'u anlamak kolaylaşır. Katmanları ayrı tutmak bir değişikliği incelemeyi de kolaylaştırır: bir ton ayarı iade yetkisini sessizce değiştirmemeli, yeni bir araç da başarılı çağrının tanımını fark ettirmeden değiştirmemeli.

Niyeti ve sınırları tanımlayın

Agent'ın yapmaya yetkili olduğu işle başlayın. Desteklenen niyetleri gündelik dille adlandırın: randevu almak, sipariş durumunu kontrol etmek, mesaj almak ya da teknik bir sorunu yönlendirmek gibi. Sonra reddetmesi, netleştirmesi ya da devretmesi gereken komşu talepleri adlandırın. Bir sınır belirsiz bir karakter özelliğini değil, işlemi tarif etmeli. “Yardımcı ol” test edilmesi zor bir talimattır. “Arayanı ve yeni saati teyit ettikten sonra mevcut bir randevuyu değiştirebilirsin, ama mali sonucu olan bir hizmeti iptal edemezsin” ise operasyon ekibine inceleyebileceği somut bir şey verir.

Birbirine benzeyen niyetleri ayırt etmek için gereken bilgiyi de ekleyin. “Yarını değiştirmek istiyorum” diyen bir arayan teslimat aralığını, bir rezervasyonu ya da iletişim tercihini kastediyor olabilir. Agent işe yarayacak en kısa netleştirme sorusunu sormalı, sonra seçilen yoldan devam etmeli. Bu, kendinden emin bir cevabın yanlış bir sınıflandırmayı örttüğü yaygın hatayı önler.

Politikayı araç talimatlarından ayırın

Politika neyin izinli olduğunu söyler. Araç talimatları ise izinli bir işlemin nasıl yapılacağını söyler. İkisini de açıkça yazın. Her araç için gerekli alanları, kabul edilen değerleri, teyit noktasını, beklenen sonucu ve araç erişilemez olduğunda izlenecek yedek yolu tanımlayın. Agent'ın sonucu arayana okuyup okumayacağını, işlemi kaydetmeden önce teyit isteyip istemeyeceğini ya da bir sorguyu kısaca onaylayıp geçeceğini belirtin. Eksik, eski ya da çelişkili veriyi tahmin için bir davet olarak değil, tanımlı bir durum olarak ele alın.

İşe yarar bir önce-sonra kalıbı, bir temenniyi bir karar kuralıyla değiştirmektir:

Önce: “Arayanın rezervasyonunu güncellemesine yardım et, gerektiğinde rezervasyon sistemini kullan.” Sonra: “Önce rezervasyonu bul ve arayanın istediği değişikliği teyit et. Gerekli tüm alanlar tamamsa ancak o zaman update_booking aracını kullan. Ücrete tabi bir değişiklikten önce ücreti açıkla ve açık bir teyit iste. Araç eşleşen bir rezervasyon döndürmezse sonuç uydurma, insana devir ya da mesaj bırakma seçeneği sun.”

Amaç her prompt'u devasa hale getirmek değil. Amaç, yüksek riskli kararları görülebilecekleri, test edilebilecekleri ve sahiplenilebilecekleri yere koymak.

Tonu doğruluğa hizmet ettirin

Ton önemlidir, çünkü arayanın sırada ne olacağını anlaması gerekir. Ama ton doğruluğun yerini tutmaz. Gözlemlenebilir birkaç davranış tarif edin: kısa cümleler, hayal kırıklığını doğrulanmamış bir iddiaya katılmadan kabul etmek, her seferinde tek soru, araç çalışırken boşluğu dolgu cümleleriyle doldurmamak. Samimi, sıcak, profesyonel ve empatik gibi uzun sıfat listelerinden kaçının. Bu kelimeler birbiriyle çatışabilir ya da kulağa hoş gelen ama kaçamak bir ses ortaya çıkarabilir.

Ton ile doğruluk çatıştığında doğruluk ve dürüst belirsizlik kazanır. Sakin bir “Henüz teyit edilmiş bir teslimat saatim yok. İsterseniz kontrol edeyim ya da sizi ekibe bağlayayım.” cümlesi, arayanı rahatlatan bir tahminden iyidir. Tonu görev başarısıyla birlikte değerlendirin, çünkü bir agent kulağa kusursuz gelirken arayanı yanlış bir beklentiyle bırakabilir.

Konuşmayı telefondaki gerçek davranışa göre tasarlayın

Söz kesmeyi ve sessizliği bilinçli yönetin

Ses, üstüne konuşma eklenmiş bir yazılı sohbet değildir. İnsanlar cevabı anladığında, katılmadığında, başka bir ayrıntıyı hatırladığında ya da sadece kontrolü ele almak istediğinde sözü keser. Arayan agent'ın sözünü kestiğinde ne olacağını tanımlayın: mevcut cevap durur ya da kısalır, arayanın söyledikleri korunur ve agent metni baştan başlatmak yerine yeni bilgiden devam eder. Uzun bir açıklama için seçenek sunun: “Kısaca özetleyebilirim ya da ayrıntılı anlatabilirim.” Agent'ın titiz olduğunu kanıtlamak için arayanı bir paragraf boyunca bekletmeyin.

Sessizliğin de bir politikası olmalı. Kısa bir duraklama, arayanın düşündüğü, bir belgeye baktığı ya da ses gecikmesiyle uğraştığı anlamına gelebilir. Agent soru sormadan önce beklemeli, sonra aynı soruyu uzun haliyle tekrarlamak yerine hafifçe yoklamalı. Daha uzun bir sessizlikten sonra net bir toparlanma yolu sunmalı: son soruyu tekrarlamak, arayanı “temsilci” demeye davet etmek ya da çağrıyı yalnızca tanımlı bir kurala göre kapatmak. İlgili eşikler metnin içinde sorgulanmamış bir varsayım olarak değil, çalışma zamanı yapılandırmasında ve test vakalarında yer almalı.

Telefon katmanı bağlantı durumu, devir ve ses davranışı hakkında önemli sinyaller verir. Ama agent'ın bu durumlara nasıl karşılık vereceğini yine konuşma talimatları söylemeli. Prompt çalışması ile telefon altyapısı çalışması birlikte incelenmeli.

Bağlama ve hafızaya bir görev verin

Bağlam, sahte bir güven yaratmadan tekrarı azaltmalı. Agent'ın çağrının başında ne alacağına, çağrı sırasında neyi hatırlayabileceğine ve hangi bilgilerin çağrılar arasında güvenle taşınabileceğine karar verin. Arayanın adı, seçilen randevu ve arama nedeni o anki görüşmede işe yarayabilir. Tahmin edilmiş bir tercih, eski bir adres ya da çözülmemiş bir şikayet doğrulanmadan güncel gerçek sayılmamalı.

Modelden yapısız bir transkripti hatırlamasını istemek yerine derli toplu bir durum modeli kullanın. İşe yarar alanlar şunlar olabilir: intent, identity_status, requested_action, required_fields_missing, tool_status, handover_reason ve next_step. Bu yapı, bir sonraki tura ve insan ekip arkadaşına ortak bir resim verir. Agent'ın bir söz kesmeden ya da araç yanıtından sonra önemli bir ayrıntıyı kaybedip kaybetmediğini test etmeyi de mümkün kılar.

Bilgi getirme (retrieval) güncel politika ya da hesap bilgisi sağlayabilir, ama getirilen metin bağlamdır, tek başına yetki değildir. Hangi kaynağın esas alınacağını, kaynaklar çeliştiğinde ne olacağını ve arayana bilginin mevcut olmadığının ne zaman söylenmesi gerektiğini belirleyin. Hafıza konuşmayı daha tutarlı kılmalı, ama onu kanıtın izin verdiğinden daha kesin hale getirmemeli.

Yapılandırılmış sonuçlar döndürün

Başarılı bir çağrı her zaman tamamlanmış bir işlem değildir. Bazen doğru sonuç doğrulanmış bir rezervasyon, bazen bekleyen bir talep, bazen de temiz bir devirdir. Prompt'u yazmadan önce sonuç sözlüğünü tanımlayın. Az sayıda sabit durum, bir paragraf nottan genellikle daha işe yarar: completed, pending_customer, pending_team, handover_required ve not_supported yalnızca örnektir, evrensel bir şema değildir.

Her sonuç, bir sonraki sistemin ya da kişinin ihtiyaç duyduğu alanları taşımalı: arayanın amacı, denenen işlem, teyit edilen bilgiler, eksik bilgi, araç sonuçları ve durumun nedeni. Agent'tan iş akışının sonunda bu yapıyı üretmesini ya da doldurmasını isteyin, sesli kapanışı ise kısa tutun. Böylece arayanın duyduğu ile operasyonun incelemesi gereken şey birbirinden ayrılır.

Sonuç tasarımını şirketinizin entegrasyonlarına bağlayın. Bir CRM, takvim ya da ticket sistemi tutarsız etiketler alırsa, konuşma kulağa iyi gelse bile raporlama ve takip zamanla kayar.

İnsana devri birinci sınıf bir sonuç yapın

Devir saklanacak bir hata değildir. Talep kapsam dışındaysa, politika bir insanı zorunlu kılıyorsa, arayan insan istiyorsa, netleştirmeden sonra güven düşük kalıyorsa ya da bir araç sonuç doğuran bir işlemi tamamlayamıyorsa doğru sonuç devirdir. Agent'a ne söyleyeceğini söyleyin, ama neyi aktaracağını da tanımlayın. Sıcak bir devir aktarım nedenini, konuşmanın durumunu ve tamamlanmış doğrulamaları korumalı, arayanı hassas bilgileri tekrar etmeye zorlamamalı.

Sıcak devir mümkün olmadığında agent bir sonraki adım için dürüst bir beklenti oluşturmalı ve yalnızca ekibin üzerinde işlem yapabileceği bilgiyi toplamalı. Devir nedeni işi yönlendirecek kadar net olmalı: “inceleme gerektiren fatura itirazı”, “temsilci istendi” notundan çok daha işe yarar. Yalnızca aktarımın bağlanıp bağlanmadığını değil, devralan ekibin vakayı hızla anlayıp anlayamadığını ölçün.

İyileştirmeyi bir operasyon sürecine dönüştürün

Test setleri ve regresyon vakaları kurun

İdeal sorulardan oluşan bir koleksiyonla değil, işi temsil eden küçük bir test setiyle başlayın. Net talepleri, belirsiz talepleri, yanlış numaraları, söz kesmeleri, sessizliği, tekrar arayanları, araç hatalarını, politika uç durumlarını, desteklenmeyen talepleri ve açıkça insan isteyen arayanları ekleyin. Arayanın fikrini değiştirdiği vakaları da katın. Her vaka için beklenen niyeti, izin verilen işlemi, gereken netleştirmeyi, kabul edilebilir tonu ve nihai sonucu tanımlayın.

Few-shot örnekler en çok burada, bir sınırı ya da toparlanma kalıbını gösterdiklerinde değerlidir. Örnekleri kısa tutun ve neden eklendiklerini not edin. Chain-of-thought tarzı bir “adım adım düşün” talebi, karar ölçütlerinin güvenilir bir ikamesi değildir. Canlıdaki sesli bir agent'ta, açığa yazılmış akıl yürütme metnine güvenmek yerine gereken iç kararı ya da yapılandırılmış alanı isteyin ve sonucu değerlendirin.

Anlamlı her değişiklik mevcut vakalara karşı çalıştırılmalı. Bir prompt randevu almayı iyileştirirken söz kesmeden sonra toparlanmayı kötüleştirebilir. Sonucu niyete ve hata türüne göre izleyin, nitel inceleme için küçük bir tam transkript örneklemi de tutun. Kalite ve değerlendirme pratiği, regresyonları geniş bir yayından önce görünür kılmalı.

Canlı geri bildirimi, gürültüyü prompt'a taşımadan kullanın

Canlı görüşmeler yeni vakaların en zengin kaynağıdır, ama ham geri bildirimin ayıklanması gerekir. Çağrıları niyete, sonuca, politika riskine, araç davranışına, konuşma ya da söz sırası sorununa ve devir kalitesine göre etiketleyin. Tek seferlik bir transkripsiyon sorununu tekrarlanan bir talimat boşluğundan ayırın. Başarılı ve başarısız çağrıları birlikte inceleyin: başarı işe yarayan ifadeleri ve verimli yolları gösterir, başarısızlık ise tasarımın nerede yeni bir sınıra, duruma, teste ya da ürün değişikliğine ihtiyaç duyduğunu ortaya koyar.

Her kötü çağrıya prompt'a bir cümle daha ekleyerek karşılık vermeyin. Önce hangi katmanın başarısız olduğunu sorun. Çözüm eksik bir araç alanı, yanlış bir entegrasyon eşlemesi, belirsiz bir politika, bir telefon ayarı, bir bilgi kaynağı ya da insanların yürüttüğü bir iş akışı olabilir. Çözüm bir prompt değişikliği olduğunda, tetikleyen görüşmeyi regresyon setine ekleyin ki düzeltme gözlemlenebilir kalsın.

Operasyonel analitik bu sinyalleri niyete ve sonuca göre gruplamaya yardım eder. Asıl önemli olan örüntüleri adı konmuş işe dönüştürmektir: bir hata kategorisi, bir sorumlu, önerilen bir değişiklik ve sonucunun değişmesi beklenen bir test.

Riske uygun yayın kapıları koyun

Yayın kapılarının işe yaraması için karmaşık olması gerekmez. Bir değişikliği yayınlamadan önce şunları teyit edin: hedef davranış kendi test vakalarında iyileşti, desteklenen niyetler hâlâ tamamlanıyor, sınırlar hâlâ tutuyor, araç çağrıları geçerli girdiler içeriyor, devirler işe yarar bağlamı koruyor ve arayan agent'ın sözünü hâlâ kesebiliyor. Hatanın bedeli yüksek bir iş akışında temsili transkriptlerin insan tarafından incelenmesini ve net bir geri dönüş noktası olan aşamalı bir yayını şart koşun.

Bir prompt'u kimin onaylayabileceğini, bağlı araç ya da politikanın sahibinin kim olduğunu ve ilk canlı çağrıları kimin izleyeceğini yazın. 50-100 kişilik bir şirketin büyük bir komiteye ihtiyacı yoktur, ama adı belli sorumlulara ihtiyacı vardır. Prompt'u ve test setini birlikte sürümleyin, değişikliğin nedenini kaydedin ve bilinen son sağlam sürümü elinizin altında tutun. Böylece iyileştirme geri alınabilir hale gelir, hafızaya dayalı tartışmalar da azalır.

Agent Factory iyileştirme döngüsü

Prompt mühendisliğindeki en kalıcı ilerleme, tek tek düzenlemeden tekrarlanabilir bir iyileştirme döngüsüne geçiştir. Agent Factory modelinde ekip işi ve sınırlarını tanımlar, konuşmayı ve araçları bir araya getirir, agent'ı gerçekçi senaryolarla test eder, uygun kapılarla yayına alır ve gözlenen sonuçları bir sonraki tasarım döngüsüne geri besler. Döngünün değeri, prompt'lara bir operasyon sistemi içinde yer açmasından gelir: prompt'lar sorumlusu, kanıtı ve değişme nedeni olan sürümlü çıktılardır.

Büyüyen bir şirkette döngüyü görünür tutun. Yeni niyetler, sınır kararları, araç ya da entegrasyon boşlukları, test vakaları ve prompt değişiklikleri için tek bir iş listesi tutun. Düzenli aralıklarla küçük bir çağrı setini inceleyin. Tekrarlanan hataları regresyon testine dönüştürün, arkasındaki iş akışı değiştiğinde de testleri emekliye ayırın. Agent Factory çerçevesi (DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği süreç) tam da bu yüzden işe yarar: canlıya çıkışı bitiş çizgisi saymak yerine agent kurulumunu değerlendirmeye ve süregelen operasyona bağlar.

Pratik mühendislik kontrol listesi

• Agent'ın desteklediği niyetleri ve kapsam dışı sınırları açıkça yazın.
• Her belirsiz yol için en kısa netleştirme sorusunu tanımlayın.
• Politika kurallarını araç girdilerinden, çıktılarından ve hata yönetiminden ayırın.
• Sonuç doğuran bir işlemden önce agent'ın neyi doğrulaması gerektiğini yazın.
• Tonu gözlemlenebilir davranış olarak tarif edin, doğruluk ve dürüst belirsizlik önce gelsin.
• Söz kesmelerin, araya girmenin (barge-in), kısa duraklamaların ve uzun sessizliğin nasıl ele alınacağını belirtin.
• Hangi bağlamın o anki çağrının durumu olduğunu, hangi bilginin yeniden doğrulama gerektirdiğini seçin.
• Yapılandırılmış sonuçları ve bir insanın ya da sonraki sistemin ihtiyaç duyduğu alanları tanımlayın.
• Arayanın istediği ve politikanın gerektirdiği insana devrin kolayca tetiklenmesini sağlayın.
• Araç zaman aşımlarını, boş sonuçları, çelişkili verileri ve erişilemeyen sistemleri test edin.
• Yalnızca sorunsuz akışları değil, zor görüşmeleri de içeren temsili bir test seti kurun.
• Anlamlı her prompt, politika, model ya da entegrasyon değişikliğinden sonra regresyon testlerini çalıştırın.
• Talimatları düzenlemeden önce canlı geri bildirimi niyete, sonuca ve hatanın katmanına göre etiketleyin.
• Her yayın için bir sorumlu, inceleyen, sürüm ve geri dönüş noktası belirleyin.
• Canlıda tekrarlanan hataları yeni testlere dönüştürün ve bir sonraki iyileştirme döngüsüne katın.

Özetle

Sesli yapay zeka operasyonları için prompt mühendisliği sihirli kelimeler aramak değil, güvenilir bir karar ortamı tasarlamaktır. En güçlü sistemler net niyet sınırlarını güvenli araç kullanımı, doğal söz sırası, disiplinli bağlam, yapılandırılmış sonuçlar ve saygılı bir devirle birleştirir. Bu sistemler test setleri, canlı kanıt ve yayın kapılarıyla iyileştirilir, modelin etrafındaki kararların hesabını da insanlar verir. Modeller ve araçlar geliştikçe, 50-100 kişilik bir şirketin müşteri deneyiminin kontrolünü kaybetmeden yetenek kazanmasını sağlayan şey bu operasyon disiplinidir.

Kaynaklar

• LLMs as Optimizers
• Automatic Prompt Optimization with Gradient Descent and Beam Search
• Large Language Models Are Human-Level Prompt Engineers
• PromptAgent