Pratik Prompt Mühendisliği: LLM'lerle Güvenli ve Etkili İş Akışları

Bu makalede, büyük dil modelleri (LLM) ile gerçek üretim problemlerini çözmek isteyen geliştiriciler için uygulamalı prompt mühendisliği stratejileri, test ve izleme yaklaşımları ile maliyet/güvenlik optimizasyonlarını ele alacağım. Hedef; yalnızca iyi çalışan bir prompt değil, sürdürülebilir, denetlenebilir ve ölçeklenebilir bir iş akışı tasarlamak.

Neden prompt mühendisliği artık sadece "iyi bir prompt" yazmaktan daha fazlası?

Başlangıçta prompt mühendisliği, tek bir girdiyle en iyi cevabı almak olarak algılandı. Ancak üretimdeki beklentiler farklıdır: tutarlılık, yanlılık kontrolü, gizlilik, maliyet ve gecikme. Bu nedenle prompt tasarımı; model seçimi, sıcaklık (temperature), token sınırları, few-shot örnekleri ve sistem mesajları ile birlikte düşünülmelidir.

Bir promptun üretime alınması, aynı zamanda test edilmesi, sürümlenmesi ve izlenmesi anlamına gelir. Bu süreçte insanlar modeli nasıl istismar edebilir, model hangi sorgularda başarısız oluyor, ve cevaplar iş kurallarına uygun mu soruları net prosedürlerle cevaplanmalıdır.

Temel stratejiler: İskelet promptlar ve rol tabanlı ayrım

İyi bir yaklaşım, promptu üç katmana ayırmaktır: sistem (rollere dair yönergeler), kullanıcı sorgusu ve yardımcı (assistant) şablonları. Sistem mesajı, modelin davranış sınırlarını ve güvenlik/etik kurallarını belirtir. Kullanıcı kısmı, gerçek soruyu taşır. Yardımcı şablonları ise çıktıyı normalize eder (ör. JSON, adım adım, kısa özet).

<!-- Örnek JSON çıktı isteği -->
{"role": "system", "content": "Sen bir teknik dokümantasyon asistanısın. Cevapları Türkçe, kısa ve madde madde ver."}
{"role": "user", "content": "Bir REST API'de rate limiting nasıl uygulanır?"}

Çıktıyı yapılandırmak, downstream işlemleri (parsing, validation) kolaylaştırır. Örnek yapılar: JSON Schema, YAML veya özel ayrılmış işaretler. Modelin üretimini doğrudan makine tarafından okunur hale getirmek hata oranını düşürür.

Few-shot, chain-of-thought ve talimat tasarımı (instruction tuning) farkları

Few-shot örnekleri, modelin istenen cevap stilini daha iyi öğrenmesini sağlar. Ancak çok fazla örnek token maliyetini artırır ve cache faydasını düşürebilir. Few-shot kullanıyorsanız örneklerin kısa ve temsil edici olmasına dikkat edin.

Chain-of-thought (CoT) tarzı yanıtlar; hesaplama, mantık yürütme gibi senaryolarda faydalıdır fakat CoT açık şekilde istenirse yanlış veya hassas bilgiyi de ortaya çıkarabilir. Üretimde CoT kullanırken sonuçları mutlaka özetleyip doğrulama adımı ekleyin.

Retrieval-Augmented Generation (RAG) ile güncel ve doğrulanabilir cevaplar

LLM'lerin kesim tarihinden sonra oluşan bilgileri güvenilir şekilde vermek için RAG mimarileri kullanılır. RAG; kullanıcı sorgusunu önce vektör veritabanına sorgular, ilişkili dokümanları alır, sonra bu bağlamla birlikte LLM'e gönderir. Böylece modelin söyledikleri kaynağa bağlanabilir hale gelir.

Basit bir RAG akışı şu şekildedir:

• Sorgu -> embed oluşturma
• Vektör arama -> en yakın k belge
• Seçilen belgelerin özeti veya alıntıları ile prompt oluşturma
• LLM'den cevap alma ve kaynakları ilişkilendirme

<!-- Örnek prompt: RAG ile birleştirilmiş -->
{"role": "system", "content": "Soruya sadece verilen kaynaklardaki bilgiler ışığında cevap ver. Eğer kaynaklarda bilgi yoksa bunu açıkla."}
{"role": "user", "content": "Kaynak1: ...\nKaynak2: ...\nSoru: X nedir?"}

Güvenlik, denetim ve güvenilirlik: toxic, hallucination ve veri sızıntısı

Üretimde en sık karşılaşılan problemler; modelin uydurma (hallucination) cevaplar üretmesi, zararlı içerik oluşturması veya gizli veriyi sızdırmasıdır. Bu riskleri azaltmanın yolları:

• İçerik filtreleri ve detektörler eklemek
• RAG ile kaynak bağlamı zorunlu kılmak
• Sorgu-metin eşleştirme ile hassas veri tanıma (PII detection) yapmak

Ayrıca modellerin cevaplarını doğrulamak için otomatik test kümeleri (unit/integration tests) ve insan denetimi (human-in-the-loop) kombinasyonu kurun. Modelin verdiği kritik kararlar için kesinlikle insan onayı gerektiren adımlar belirlenmelidir.

Performans, maliyet optimizasyonu ve izleme

Model seçimi (büyük vs küçük), konteks uzunluğu, token başına maliyet ve latency kararlarını etkiler. Her sorgu için en uygun model boyutunu seçmek, maliyetleri düşürür. Mesela basit sınıflandırma işleri için küçük modelleri kullanıp, yalnızca karmaşık doğal dil üretiminde büyük modelleri çağırabilirsiniz.

İzleme açısından aşağıdaki metrikleri öneririm:

• Yanıt doğruluğu (doğrulama setlerine göre)
• Hallucination oranı (otomatik testler + rastgele insan denetimleri)
• İstek başına token maliyeti ve gecikme
• Güvenlik olayları ve kullanıcı raporları

Uygulamalı örnek: Bir destek botu için prompt şablonu ve testler

Aşağıda, destek botu için basit, güvenli ve yapılandırılmış bir prompt şablonu örneği var. Amaç: kullanıcının sorusunu al, ilgili KB (knowledge base) belgelerini ekle, ardından JSON formatında cevap üret.

<!-- Prompt şablonu -->
{"role": "system", "content": "Sen müşteri destek asistanısın. Cevapları Türkçe, kısa başlık, 3 madde ve kaynak listesi olarak JSON formatında ver. Eğer belirsizlik varsa 'emin değilim' yaz."}
{"role": "user", "content": "KB_BELGELERI: [doc1, doc2]\nSoru: Uygulama neden 500 hatası veriyor?"}

<!-- Beklenen JSON şablonu -->
{
  "title": "Kısa başlık",
  "steps": ["adım1","adım2","adım3"],
  "sources": ["doc1","doc2"],
  "confidence": "yüksek|orta|düşük"
}

Bu şablonun otomatik testleri şöyle olabilir: set edilen KB'den beklenen cevabın parça parçaları çıkarılıp, model çıktısının kaynaklarda olup olmadığı kontrol edilir. Confidence alanı ise modelin cevapta dayandığı bağlam sayısına veya retrieval skoruna göre otomatik olarak belirlenir.

Sık Sorulan Sorular

Prompt çok uzun olunca model neden daha kötü cevap veriyor?

Uzun promptlarda modelin dikkat dağılımı değişir ve token sınırına yaklaşınca bağlam kesilebilir. Ayrıca çok fazla örnek veya gereksiz bilgi gürültü oluşturur. Kısa, öz ve bilgi açısından zengin promptlar daha tutarlı sonuç verir.

LLM sonuçlarını otomatik olarak nasıl doğrulayabilirim?

RAG kullanarak kaynaklara dayandırma, unit/integration testleri, otomatik fact-checking araçları ve rastgele insan denetimleri birleşik çözüm sunar. Kritik kararlar için insan onayı mekanizması uygulayın.

Gizli veriyi yanlışlıkla modele gönderirsem ne yapmalıyım?

Öncelikle gizli veriyi göndermemek için input filtreleri kurun. Eğer gönderilmişse, model sağlayıcınızın veri kullanımı politikasına göre işlem yapın ve erişim/kayıt loglarını inceleyerek etkilenen istekleri tespit edip bildirin.

Sonuç

Prompt mühendisliği, yalnızca tek tek iyi yazılmış metinlerden ibaret değil; model seçimi, RAG entegrasyonu, test ve izleme süreçleri, güvenlik ve maliyet optimizasyonu ile birlikte ele alınması gereken bir tüm sistem problemidir. Üretime geçerken otomatik doğrulama, kaynak dayanaklı cevaplar ve insan denetimini bir arada kullanmak güvenilir, ölçeklenebilir çözümler sağlar. Bu makaledeki yaklaşımları küçük bir pilot projede deneyip, ölçümlerle iyileştirerek kendi iş akışınıza adapte etmenizi öneririm.