Yapay zekâyla iletişim: talimat hiyerarşisi ve rol atama (persona) teknikleri

Yapay zekâdan tutarlı ve güvenilir çıktılar almak, çoğu zaman “daha uzun yazmak” değil, doğru sırada ve doğru kapsamda talimat vermek demektir. Günlük kullanımda tek bir mesaj yazıyor olsanız bile, modern sohbet tabanlı modeller genellikle farklı talimat katmanları (ör. system/developer/user) mantığıyla çalışır. Bu katmanları bilmek, aynı zamanda ekip içinde paylaşılan şablonlar oluşturmayı, hataları daha hızlı teşhis etmeyi ve çıktıları ölçülebilir biçimde iyileştirmeyi kolaylaştırır.

Bu yazıda, talimat hiyerarşisini (hangi kuralın hangisini “yendiğini”), rol/persona atama tekniğini (ne zaman faydalı, ne zaman gereksiz) ve üretim ortamında prompt’ları nasıl yöneteceğinizi adım adım ele alacağız. Not: Model davranışları ve API terimleri hızla değişebilir; bu yüzden kullandığınız sağlayıcının güncel dokümantasyonunu kontrol etmek iyi bir alışkanlıktır.

1) Talimat hiyerarşisi nedir ve neden önemlidir?

Talimat hiyerarşisi, model birden fazla talimatla karşılaştığında hangisini öncelikli sayacağını anlatır. Örneğin bir yerde “kısa yaz” derken başka bir yerde “tüm detayları ver” derseniz, modelin karar vermesi gerekir. Hiyerarşi net değilse çıktılar rastlantısal görünebilir.

OpenAI’nin geliştirici odaklı rehberlerinde, sistem ve geliştirici katmanlarının model davranışını belirlemede yüksek öncelikli olduğu vurgulanır; özellikle “developer messages” kavramı ve mantık/öncelik önerileri bu çerçevededir (OpenAI Reasoning best practices).

En yaygın katmanlar (genel çerçeve)

• System: En üst seviye “oyunun kuralları”. Güvenlik, stil çerçevesi, temel görev tanımı, yasaklar/izinler gibi “kalıcı” kurallar.
• Developer: Ürüne/uygulamaya özel politikalar ve davranış standardı. Örn. “Yanıtları şu şablonda ver”, “bu veri kaynaklarını öncelikle kullan”. (Bazı platformlarda system/developer ayrımı terimsel olarak değişebilir; güncel dokümantasyon belirleyicidir.)
• User: Son kullanıcının anlık isteği. Örn. “Bu metni özetle”, “Bana 5 maddede anlat”.
• Bağlam / içerik: Sohbet geçmişi, verilen dokümanlar, alıntılanan metinler. Bunlar her zaman “talimat” değildir; çoğu zaman sadece “veri”dir.

Pratik sonuç: Kritik kuralları (çıktı formatı, kapsam sınırları, uyması gereken politika ilkeleri) üst katmanlara koymak; kullanıcıdan gelen değişken istekleri ise alt katmanda karşılamak daha stabil sonuç verir.

Çelişki olduğunda ne yapmalı?

Çelişkiler, “model anlamadı”dan çok “model iki farklı şeye aynı anda uymaya çalıştı” durumudur. Çözüm yaklaşımı:

1. Tek bir “otorite cümlesi” belirleyin: Örn. “Çıktı her zaman tablolu olacak” gibi bir kural varsa bunun nerede duracağı sabit olsun.
2. Öncelik belirtin: “Kullanıcı farklı istese bile şu format korunur” gibi.
3. İstisnaları yazın: “Eğer kullanıcı özellikle X isterse, Y formatına geç” gibi kontrollü esneklik.

2) System prompt ve developer mesajları: “Sözleşme” gibi düşünün

System/developer katmanını, modele imzalattığınız bir çalışma sözleşmesi gibi düşünmek işe yarar: görev tanımı, sınırlar, kalite standardı ve çıktı formatı bu sözleşmede yer alır. OpenAI rehberinde de talimatların açık, önceliklendirilmiş ve çelişkisiz tutulmasının önemi vurgulanır (s1).

İyi bir üst-katman talimatının özellikleri

• Kısa ve öncelikli: Uzun metin, her zaman daha iyi kontrol sağlamaz; bazen beklenmedik yorumlara yol açabilir (OpenAI rehberi ve bağlam mühendisliği ders notlarında bu risklere dikkat çekilir: s1, s4).
• Test edilebilir: “İyi yaz” yerine “3 başlık, 5 madde, her madde 1–2 cümle” gibi doğrulanabilir kriterler.
• Rolü değil davranışı tarif eder: “Uzman ol” demektense “Varsayım yapma, gerekirse soru sor, kaynak linki ver” gibi.

Kullanıma hazır (kısa) system/developer şablonu

Aşağıdaki şablonu kendi ürününüze uyarlayabilirsiniz. (Bu metni üst katmana koyduğunuzu varsayın.)

Görev: Kullanıcının sorusunu anlaşılır ve eyleme dönük biçimde yanıtla.

Öncelikler: (1) Güvenlik/politika kuralları, (2) Çıktı formatı, (3) Kullanıcı talebi.

Çıktı formatı: Önce kısa özet, sonra adım adım liste, sonra varsa kontrol listesi.

Belirsizlik kuralı: Bilgi eksikse önce 1–3 netleştirici soru sor; varsayım yapman gerekiyorsa bunu açıkça belirt.

Bu tür bir çerçeve, “yapay zeka komutları” yazarken en sık karşılaşılan sorunlardan biri olan format kaymasını azaltır ve ekip içinde standartlaştırmayı kolaylaştırır.

3) Rol atama (persona) tekniği: Ne işe yarar, ne zaman abartılır?

Role prompting veya persona atama, modele “Sen bir X’sin” diyerek belirli bir üslup, yaklaşım veya uzmanlık çerçevesi vermektir. Örneğin: “Sen bir öğretmensin; basit anlat.”

Burada kritik ayrım: Persona, çoğu zaman üslup ve biçimi iyileştirir; ancak doğruluğu her modelde ve her görevde tutarlı biçimde artırmayabilir. Persona ifadelerinin performansı otomatik olarak yükseltmediğini raporlayan deneysel çalışmalar vardır (arXiv: 2311.10054).

Persona’nın gerçekten faydalı olduğu durumlar

• Ton hedefi netse: Örn. “resmi”, “samimi”, “kısa”, “öğretici”.
• Hedef kitle farklıysa: Örn. “8. sınıf seviyesinde anlat”, “teknik ekip için maddeler halinde”.
• Çıktı tutarlılığı isteniyorsa: Aynı marka sesini korumak gibi.

Persona’nın tek başına yetmediği durumlar

• Hassas doğruluk gereken işler: Persona yerine doğrulama adımları, açık veri kaynağı ve kontrol listeleri daha etkili olur.
• Çıktı formatı karmaşıksa: “Uzman” demektense formatı ve kabul kriterlerini belirtmek gerekir.

Daha iyi alternatif: “Rol” yerine “Davranış sözleşmesi”

“Sen bir uzmansın” yerine şu yaklaşımı deneyin:

• Yanıt yapısı (başlıklar, maddeler, tablo)
• Varsayım kuralları (ne zaman soru soracak?)
• Kaynak kullanımı (varsa linkleme, hangi kaynak öncelikli?)
• Kapsam sınırları (neye girmeyecek?)

Bu, persona’nın sağlayacağı üslup faydasını korurken “rolün büyüsüne” fazla bel bağlamayı azaltır.

4) “Politika/Anayasa” katmanı: Davranış kurallarını ayrı tutmak

Bazı sağlayıcılar, davranış ve etik ilkeleri ayrı bir kural seti gibi ele almayı önerir. Anthropic’in yayımladığı “Constitution” yaklaşımı, modele uyması gereken ilkeleri bir “üst kural katmanı” şeklinde tanımlamaya örnektir (Anthropic Constitution).

Bu yaklaşımı ürün tasarımına çevirirsek: Üst katmanda (system/developer) değişmeyen politika ilkeleri, alt katmanda (user) görev yer alır.

Örnek: Basit bir politika ilkeleri listesi

Politika ilkeleri:

• Belirsiz veya eksik bilgi varsa netleştirici soru sor.
• Kullanıcı talebi ile politika çelişirse politika önceliklidir.
• Yanıtta gerekirse sınırlılıkları açıkça belirt.

Bu tarz bir “ilke listesi”, ekibiniz büyüdükçe veya birden fazla prompt şablonu kullanmaya başladığınızda tutarlılık sağlar.

5) Pratik yapı: İyi bir komut (prompt) nasıl kurulmalı?

İster tek mesajla çalışın ister katmanlı bir sisteminiz olsun, iyi bir komut genellikle şu bileşenleri taşır:

A) Amaç + başarı kriteri

• Amaç: “Şunu üret”, “şunu karşılaştır”, “şunu özetle”.
• Başarı kriteri: “5 madde”, “her madde 1 örnek”, “şu hedef kitle”.

B) Girdi bağlamı (veri) + sınırlar

• Modelin kullanacağı metin/doküman/parça.
• Girmemesini istediğiniz alanlar.

C) Çıktı formatı

• Başlık yapısı
• Tablo isteniyorsa kolonlar
• Dil tercihi

D) Değerlendirme adımı (kendini kontrol)

Modelden “yanıtını şu maddelere göre kontrol et” istemek bazen hataları azaltabilir; ancak bu da model ve göreve göre değişir. En güvenilir yöntem, harici test setleriyle ölçmektir (prompt yönetimi ve ölçümleme fikri için bkz. s4).

6) Uygulamalı örnekler: Aynı işi 3 farklı şekilde istemek

Örnek 1: Basit kullanıcı komutu (hızlı ama oynak)

“Bu metni özetle ve bana önemli maddeleri çıkar.”

Sonuç bazen iyi olur; ama “kaç madde”, “hangi ton”, “hangi uzunluk” belirsizdir.

Örnek 2: Formatı netleştiren komut (genellikle daha tutarlı)

“Aşağıdaki metni Türkçe özetle. Çıktıyı şu formatta ver: (1) 2 cümlelik özet, (2) 5 madde ana fikir, (3) 3 madde ‘aksiyon’ önerisi. Her madde 1–2 cümleyi geçmesin.”

Örnek 3: Persona + davranış kuralları (ton kontrolü için)

“Bir eğitmen gibi açık ve sade anlat. Aşağıdaki metni Türkçe özetle. Önce 2 cümlelik özet ver, sonra 5 madde ana fikir çıkar. Terim kullanman gerekirse parantez içinde kısa açıklama ekle.”

Burada persona, daha çok “anlatım tarzını” hizalar. Doğruluk artışı ise görev, veri ve modele göre değişebilir (s3).

7) Prompt’ları üretimde yönetmek: Versiyonlama, test, ölçüm

Prompt’lar pratikte birer “ürün bileşeni” gibidir: değişir, sürümlenir, ölçülür. Bağlam mühendisliği ve veri stratejisi odaklı kaynaklar, prompt yönetiminde versiyonlama ve test disiplininin önemini vurgular (s4).

Minimum uygulanabilir süreç (küçük ekipler için)

1. Prompt envanteri: Hangi prompt nerede kullanılıyor? (Dosya adı, amaç, sahiplik)
2. Versiyon etiketi: v1.0, v1.1 gibi; değişiklik notu yazın.
3. Test seti: 20–50 gerçek örnek soru/istek; beklenen format kriterleri.
4. Basit puanlama: Format uyumu, kapsam uyumu, okunabilirlik (1–5).
5. A/B deneyi: Yeni sürümü küçük bir trafikte deneyin (mümkünse).

Sık görülen sorunlar ve hızlı teşhis

• Yanıt formatı kayıyor → Format kuralını üst katmana taşıyın ve tek cümleyle netleştirin.
• Çok uzun yanıtlar → “Maksimum X madde / maksimum Y kelime” gibi sınır ekleyin.
• Yanıtlar gereğinden temkinli veya belirsiz → “Belirsizlikte soru sor; aksi halde mevcut bilgiyle ilerle ve varsayımı belirt” dengesini yazın.
• Farklı model sürümlerinde tutarsızlık → Sağlayıcı dokümantasyonunu ve model notlarını takip edin; aynı prompt her yerde aynı davranmayabilir (s1, s2).

8) Kontrol listesi: Daha iyi talimat hiyerarşisi için 10 madde

• Üst katmanda yalnızca “kalıcı” kurallar var mı?
• Geliştirici katmanında ürününüzün çıktı standardı net mi?
• Kullanıcı komutu sadece “görev” mi istiyor, yoksa politika/formatla çelişiyor mu?
• Çelişki halinde hangi kuralın öncelikli olduğu yazıyor mu?
• Format gereksinimleri ölçülebilir mi?
• Belirsizlikte ne yapılacağı tanımlı mı (soru sorma/varsayım)?
• Persona, sadece ton/biçim ihtiyacı için mi kullanılıyor?
• Prompt metni gereksiz tekrar içeriyor mu?
• En azından küçük bir test setiniz var mı?
• Değişiklikler versiyonlanıyor ve not ediliyor mu?

Sonuç

Yapay zekâyla etkili iletişim kurmanın omurgası, talimat hiyerarşisini doğru kurmak ve çelişkileri baştan engellemektir. System/developer katmanını “sözleşme”, user katmanını “görev bileti” gibi düşündüğünüzde, hem daha tutarlı çıktılar alır hem de ekip içinde yeniden kullanılabilir şablonlar oluşturursunuz. Persona/rol atama ise çoğunlukla üslup ve biçim için yararlıdır; doğruluğu otomatik artıracağı varsayımı her zaman desteklenmez ve hedef modelde test edilmesi gerekir (s3).

Bir sonraki adım olarak, en sık kullandığınız 3–5 prompt’u seçip kısa bir test setiyle ölçmeye başlayın; ardından kuralları kısaltıp önceliklendirin. Bu yaklaşım, zamanla daha güvenilir ve bakımı kolay bir prompt mimarisi oluşturur.