Prompt, RAG, Eval: LLM Mühendisleri İçin Kapsamlı Kılavuz

Büyük Dil Modelleri (LLM) ile uygulamalar geliştirmek, modern mühendisliğin en heyecan verici alanlarından biri haline geldi. Ancak, ham bir LLM’i alıp doğrudan üretime sunmak, çoğu zaman yetersiz veya yanlış sonuçlar doğurabilir. İşte tam bu noktada, LLM mühendisleri için Prompt Mühendisliği, Geri Çağırma Destekli Üretim (RAG) ve sistem Değerlendirmesi (Evaluation) süreçleri kritik bir önem taşıyor. Bu makale, bu üç temel bileşeni sıfırdan ele alarak, LLM tabanlı çözümlerinizi başarıyla hayata geçirmenize yardımcı olacak kapsamlı bir rehber sunuyor. Hazırsanız, geleceğin uygulamalarını inşa etme yolculuğumuza başlayalım.

Son yıllarda, üretken yapay zeka (Generative AI) teknolojileri ve özellikle Büyük Dil Modelleri (LLM’ler), dijital dünyamızda devrim niteliğinde bir değişimi tetikledi. ChatGPT gibi uygulamaların yaygınlaşmasıyla birlikte, doğal dil işleme yetenekleri bambaşka bir seviyeye ulaştı. Artık karmaşık metinleri anlayan, yaratıcı içerikler üreten, özetleyen ve hatta kod yazabilen yapay zeka modelleriyle etkileşim kurabiliyoruz. Bu durum, teknoloji dünyasında yeni bir mühendislik disiplininin doğmasına zemin hazırladı: LLM Mühendisliği. Peki, bu alan neden bu kadar hızla önem kazanıyor?

Öncelikle, LLM’ler inanılmaz güçlü araçlar olsalar da, kendi başlarına her zaman mükemmel sonuçlar üretmezler. Onların “zekası”, eğitildikleri devasa veri setlerinin bir yansımasıdır ve bu veri setleri, güncel olmayan bilgiler, yanlılıklar veya belirli bir alana özgü eksiklikler içerebilir. Dolayısıyla, bir LLM’den belirli bir görev için istenen, doğru ve güvenilir çıktıyı almak, sıradan bir kullanıcı için bile bir “sanat” haline gelmiştir. İşte burada prompt mühendisliği devreye girer. Prompt mühendisleri, LLM’lerle en verimli şekilde iletişim kurmanın yollarını arar, onlara neyi, nasıl yapacaklarını en net şekilde anlatan talimatlar (promptlar) tasarlar. Bu, LLM’in potansiyelini tam olarak ortaya çıkarmak ve “halüsinasyon” olarak adlandırılan yanlış veya uydurma bilgileri en aza indirmek için hayati bir adımdır.

İkinci olarak, birçok kurumsal veya özel uygulama, genel internet bilgisinin ötesinde, şirket içi belgeler, tescilli veritabanları veya niş alanlara ait güncel bilgilerle beslenmelidir. Ham bir LLM, bu özel bilgilere erişemez ve dolayısıyla bu tür sorgulara doğru cevaplar veremez. Bu sorunu aşmak için Geri Çağırma Destekli Üretim (Retrieval Augmented Generation – RAG) mimarisi geliştirilmiştir. RAG, LLM’lere harici bir bilgi tabanından ilgili verileri “okuma” yeteneği kazandırarak, onların bilgi ufkunu genişletir. Bu sayede, LLM’ler sadece genel bilgilere değil, aynı zamanda en güncel ve spesifik verilere de dayalı, bağlam açısından zengin ve doğru yanıtlar üretebilirler. RAG, özellikle kurumsal çözümlerde, LLM’lerin katma değerini inanılmaz derecede artıran bir teknolojidir.

Son olarak, bir LLM veya RAG tabanlı sistem geliştirdiğinizde, onun gerçekten beklenen performansı sergileyip sergilemediğini nasıl anlarsınız? İşte burada değerlendirme (evaluation) süreçleri devreye girer. Bir sistemin doğruluğunu, alaka düzeyini, tutarlılığını ve güvenilirliğini ölçmek için sağlam metrikler ve yöntemler geliştirmek, başarılı bir LLM uygulamasının temelidir. Değerlendirme olmaksızın, yaptığınız iyileştirmelerin etkisini bilemez, potansiyel sorunları tespit edemez ve kullanıcılarınız için istikrarlı bir deneyim sunamazsınız. Kısacası, değerlendirme, geliştirme döngüsünün kritik bir geri bildirim mekanizmasıdır. Bu makale boyunca, bu üç temel direği derinlemesine inceleyerek, siz değerli LLM mühendislerinin bu heyecan verici alanda sağlam adımlarla ilerlemesini sağlayacağız.

Prompt Mühendisliği: LLM’lerden İstenen Cevapları Nasıl Alırız?

Prompt mühendisliği, LLM’lerin istenen görevleri en doğru ve verimli şekilde yerine getirmesi için onlara verilen talimatların, yani “prompt”ların tasarlanması ve optimize edilmesi sürecidir. Bir LLM ile etkileşim kurmak, sıradan bir arama motoru sorgusu yazmaktan çok daha fazlasını gerektirir. Burada, modelin dil anlayışını ve üretim yeteneklerini en üst düzeye çıkaracak stratejik bir yaklaşım benimsenmelidir. Aslında, prompt mühendisliği, modelle bir sohbet veya talimat dizisi aracılığıyla onun yeteneklerini yönlendirme sanatıdır diyebiliriz. Bu, LLM’lerin “kara kutu” doğasını biraz olsun şeffaflaştırarak, çıktılar üzerinde daha fazla kontrol sağlamamızı mümkün kılar.

Prompt mühendisliğinin temel amacı, belirsizliği ortadan kaldırmak ve LLM’ye ne istediğimizi mümkün olan en açık ve kesin şekilde iletmektir. Aksi takdirde, model genel ve bazen yanlış veya alakasız cevaplar üretebilir. Etkili bir prompt tasarlarken kullanılan çeşitli teknikler vardır:

1. Sıfır Atış (Zero-shot) Prompting: Modele sadece görevi ve soruyu verirsiniz, herhangi bir örnek sunmazsınız. Örneğin: “Bu metni özetle: [Metin]”. Bu, modelin genel bilgi birikimine dayanmasını gerektirir ve genellikle daha basit görevler için yeterlidir.
2. Tek Atış (One-shot) Prompting: Modele bir örnek soru-cevap çifti sunarak, istenen çıktı formatını ve stilini gösterirsiniz. Örneğin: “Soru: Elmalar hangi ağaçta yetişir? Cevap: Elma ağacı. Soru: Portakallar hangi ağaçta yetişir?” Bu, modelin benzer bir desen izlemesini sağlar.
3. Çoklu Atış (Few-shot) Prompting: Tek atış promptinge benzer şekilde, ancak birden fazla örnek sunulur. Bu, modelin öğrenme yeteneğini artırır ve daha karmaşık görevlerde daha tutarlı sonuçlar verir.
4. Zincirleme Düşünme (Chain-of-Thought – CoT) Prompting: Modele sadece cevabı değil, cevaba nasıl ulaştığını adım adım düşünmesini de söyleyen bir tekniktir. Örneğin: “Adım adım düşünerek şu problemi çöz: [Problem]”. Bu, özellikle matematiksel problemler veya karmaşık muhakeme gerektiren görevlerde performansı önemli ölçüde artırır.
5. Persona Atama: Modele belirli bir rol veya persona atayarak, o persona’ya uygun bir dil ve ton kullanmasını istersiniz. Örneğin: “Uzman bir finans danışmanı gibi davran ve bana enflasyon hakkında bilgi ver.”
6. Sınırlamalar ve Formatlama Talimatları: Cevabın uzunluğunu, dilini, formatını (maddeleme, tablo vb.) belirten net talimatlar vermek. Örneğin: “Cevabın 3 cümleyi geçmesin ve anahtar kelimeleri kalın harflerle vurgula.”

Bir gerçek dünya senaryosu düşünelim: Bir e-ticaret sitesi için müşteri hizmetleri botu geliştiriyorsunuz. Müşteriler “Siparişimi iptal etmek istiyorum” veya “Ürün iadesi nasıl yapabilirim?” gibi sorular sorabilir. Ham bir LLM, çok genel veya yüzeysel cevaplar verebilir. Ancak prompt mühendisliği ile bu botu çok daha kullanışlı hale getirebiliriz:


"Sen bir e-ticaret sitesinin nazik ve yardımcı müşteri hizmetleri temsilcisisin. Kullanıcının sorusuna en fazla 3 cümleyle ve empatik bir dille cevap ver. Eğer sipariş iptali veya iade hakkında soruyorsa, öncelikle sipariş numarasını ve e-posta adresini iste. Örnek: 'Merhaba! Siparişinizi iptal etmek için lütfen sipariş numaranızı ve kayıtlı e-posta adresinizi paylaşır mısınız? Size hemen yardımcı olabilirim.' Şimdi kullanıcının sorusuna cevap ver: 'Ürün iadesi nasıl yapabilirim?'"


Bu prompt, modele bir persona, bir sınırlama (3 cümle), bir ton (empatik) ve belirli bir eylem için bir örnek talimat veriyor. Bu sayede modelin çıktısı çok daha tutarlı ve işlevsel hale gelir. Prompt mühendisliği, sürekli bir deneme-yanılma ve iterasyon sürecidir. En iyi prompt’u bulmak, çoğu zaman dikkatli gözlem ve yaratıcılık gerektirir.

Etkili Promptlar Oluşturmak İçin En İyi Pratikler Nelerdir?

Etkili promptlar tasarlamak, LLM uygulamalarınızın başarısının temelini oluşturur. İşte bu süreçte size yol gösterecek bazı en iyi pratikler:

• Açık ve Kesin Talimatlar Verin: Modelin ne yapmasını istediğinizi net bir şekilde belirtin. Muğlak ifadelerden kaçının. “Bana bu konuda bilgi ver” yerine “Bu metni üç ana başlık altında özetle ve her başlığa birer madde işareti ekle” gibi spesifik olun.
• Bağlam Sağlayın: Modele görevi yerine getirmesi için yeterli bağlamı sunun. Örneğin, bir metni özetlemesini istiyorsanız, o metni prompt’a dahil edin. Bir kod parçacığı oluşturmasını istiyorsanız, o kodun ne işe yarayacağını, hangi dilde yazılması gerektiğini ve hangi kısıtlamaları olduğunu açıklayın.
• İstenmeyen Çıktıları Engelleyin: Modelin yapmamasını istediğiniz şeyleri de belirtin. “Yanlış bilgi uydurma” veya “kişisel görüşlerini katma” gibi direktifler, halüsinasyon riskini azaltabilir.
• Tekrarlama ve Örneklerle Destekleyin (Few-shot): Özellikle karmaşık görevlerde, birkaç iyi örnek vermek, modelin istenen formatı veya yaklaşımı anlamasına yardımcı olur. Örnekler, modelin genelleme yapma yeteneğini artırır.
• Rol Ataması Yapın (Persona): Modelin belirli bir karakter veya uzmanlık alanı gibi davranmasını sağlayın. Bu, çıktının tonunu, dilini ve içeriğini büyük ölçüde etkileyebilir. “Sen deneyimli bir pazarlama uzmansın” gibi.
• Çıktı Formatını Belirleyin: Cevabın nasıl yapılandırılması gerektiğini açıkça belirtin. JSON, maddeleme, tablolar, belirli bir karakter uzunluğu gibi format kısıtlamaları modelin daha düzenli çıktılar vermesini sağlar.
• Duyarlılık ve Tarafsızlık İsteyin: Hassas konularla ilgili promptlarda, modelden tarafsız, saygılı ve dengeli bir dil kullanmasını isteyin.

RAG (Retrieval Augmented Generation) ile LLM Bilgisini Nasıl Genişletebiliriz?

Büyük Dil Modelleri (LLM’ler), eğitim verilerindeki bilgilere dayalı olarak şaşırtıcı derecede yetenekli yanıtlar üretebilirler. Ancak, LLM’lerin kendi içinde barındırdığı iki önemli sınırlama vardır: bilgi güncelliği ve spesifik domain bilgisi eksikliği. LLM’ler belirli bir tarihe kadar olan verilerle eğitilirler ve bu tarihten sonraki olaylar veya bilgiler hakkında doğal olarak “bilgisiz”dirler. Ayrıca, bir şirketin iç politikaları, özel ürün katalogları veya niş bir araştırma alanındaki son gelişmeler gibi spesifik bilgilere de doğrudan erişemezler. İşte bu noktada, Geri Çağırma Destekli Üretim (Retrieval Augmented Generation – RAG) devreye girer ve LLM’lerin bu bilgi boşluklarını doldurmasına olanak tanır.

RAG, temel olarak bir LLM’in bir soruya cevap vermeden önce, harici bir bilgi tabanından ilgili bilgileri “geri çağırması” ve bu bilgileri kullanarak daha doğru, bağlam açısından zengin ve güncel bir yanıt üretmesidir. Bu süreç, LLM’in halüsinasyon yapma (yani yanlış veya uydurma bilgi üretme) riskini önemli ölçüde azaltırken, aynı zamanda güvenilirliğini ve uygulanabilirliğini artırır. RAG, bir “açık kitap sınavı” stratejisi gibidir; modelin her zaman güncel ve doğru kaynaklara başvurmasını sağlar.

RAG mimarisinin çalışma prensibini iki ana aşamaya ayırabiliriz:

1. Geri Çağırma (Retrieval): Bu aşamada, kullanıcının sorgusuna en uygun bilgileri, önceden hazırlanmış harici bir bilgi tabanından (dokümanlar, veritabanları, web sayfaları vb.) bulup çıkarırız. Bu süreç genellikle aşağıdaki adımları içerir:
   • Doküman Yükleme ve Parçalama (Chunking): Büyük metin belgeleri, LLM’lerin bağlam penceresine sığacak daha küçük, yönetilebilir “parçalara” (chunks) ayrılır. Bu parçaların boyutu ve birbiriyle örtüşmesi, geri çağırma kalitesi için kritiktir.
   • Gömme (Embedding) Modelleri: Her bir metin parçası ve kullanıcının sorgusu, sayısal vektörlere (embeddings) dönüştürülür. Bu vektörler, metinlerin anlamsal anlamını temsil eder. Benzer anlama sahip metinler, vektör uzayında birbirine daha yakın konumlanır.
   • Vektör Veritabanı: Oluşturulan tüm metin parçalarının vektörleri, bir vektör veritabanında depolanır. Bu veritabanları, yüksek boyutlu vektörler arasında hızlı benzerlik aramaları yapmak için optimize edilmiştir.
   • Geri Çağırma (Retriever): Kullanıcının sorgusu vektöre dönüştürüldükten sonra, bu vektör, vektör veritabanındaki diğer parçaların vektörleriyle karşılaştırılır. En benzer (yani anlamsal olarak en alakalı) parçalar geri çağrılır.
2. Üretim (Generation): Geri çağrılan ilgili metin parçaları, orijinal kullanıcı sorgusuyla birlikte LLM’e bir prompt olarak beslenir. LLM, bu bağlamı kullanarak ve kendi genel bilgi birikimini de devreye sokarak, daha bilgilendirilmiş ve doğru bir cevap üretir. Modelin talimatları, sadece geri çağrılan bilgilerle sınırlı kalmasını veya bu bilgileri kullanarak özet, analiz gibi görevler yapmasını içerebilir.

Bir gerçek dünya senaryosuyla açıklayalım: Büyük bir hukuk firmasının, kendi devasa hukuki döküman arşivinden (emsal kararlar, kanunlar, sözleşmeler) bilgi çeken bir asistan kurmak istediğini düşünelim. Ham bir LLM, bu özel arşivden bilgi edinemez. Ancak RAG ile bu mümkündür:

1. Hukuk firmasının tüm dökümanları (PDF’ler, Word dosyaları vb.) sisteme yüklenir.
2. Bu dökümanlar anlamlı parçalara ayrılır (örn: bir yasa maddesi, bir dava özetinin paragrafı).
3. Her parça, bir embedding modeli (örn: OpenAI’ın text-embedding-ada-002’si veya açık kaynaklı Sentence Transformers) kullanılarak bir vektöre dönüştürülür ve Pinecone, Weaviate veya ChromaDB gibi bir vektör veritabanına kaydedilir.
4. Bir avukat “X yasasına göre şirketin sorumluluğu nedir?” diye sorduğunda, bu sorgu da vektöre dönüştürülür.
5. Vektör veritabanı, sorgu vektörüne en yakın olan (en alakalı) yasa maddelerini veya emsal kararları geri çağırır.
6. Geri çağrılan bu metin parçaları, avukatın sorgusuyla birlikte LLM’e gönderilir (örn: “Aşağıdaki hukuki metinleri dikkate alarak, X yasasına göre şirketin sorumluluğunu açıkla: [Geri çağrılan metinler]”).
7. LLM, bu bağlamı kullanarak, avukatın sorusuna spesifik, doğru ve dayanağı olan bir cevap üretir.

Bu süreç, LLM’in “bilgisini” dinamik olarak genişleterek, onu çok daha güçlü ve işlevsel bir araca dönüştürür. RAG, özellikle kurumsal LLM uygulamalarının bel kemiğidir.

RAG Sistemleri Kurarken Karşılaşılan Zorluklar ve Çözümler Nelerdir?

RAG sistemleri, LLM’lerin bilgi tabanını genişletmek için güçlü bir çözüm sunsa da, başarılı bir implementasyon bazı zorlukları beraberinde getirir. İşte sık karşılaşılan sorunlar ve olası çözümleri:

• Chunking Stratejileri: Metinleri anlamlı parçalara bölmek kritik öneme sahiptir. Çok küçük parçalar bağlamı kaybederken, çok büyük parçalar LLM’in bağlam penceresini aşabilir veya alakasız bilgileri de içerebilir.
  • Çözüm: Alan bilgisine dayalı akıllı chunking (örn. paragraf, başlık veya belirli bölüm bazlı). Overlap (örtüşme) ile parçalar arasında bağlam geçişini sağlamak. Farklı chunk boyutları ve stratejileriyle denemeler yapmak.
• Vektör Veritabanı Seçimi ve Optimizasyonu: Yüz binlerce hatta milyonlarca vektör arasında hızlı ve doğru arama yapabilen bir veritabanı seçmek önemlidir. Performans, maliyet ve ölçeklenebilirlik dengelemelidir.
  • Çözüm: Pinecone, Weaviate, ChromaDB, Faiss gibi seçenekleri projenizin ihtiyaçlarına göre değerlendirmek. Endeksleme stratejilerini (örn. HNSW) anlamak ve optimize etmek.
• Alaka Düzeyi (Relevance) ve Hassasiyet (Precision) Sorunları: Geri çağrılan parçalar her zaman kullanıcının sorgusuyla %100 alakalı olmayabilir veya en alakalı parçalar gözden kaçabilir.
  • Çözüm: Daha iyi embedding modelleri kullanmak. Gelişmiş geri çağırma teknikleri (örn. hyprid search – anahtar kelime ve vektör aramasının birleşimi), yeniden sıralama (re-ranking) modelleri (örn. Cohere Rerank) ile geri çağrılan parçaların alaka düzeyini artırmak.
• Güncelleme Mekanizmaları: Harici bilgi tabanı sürekli güncelleniyorsa, vektör veritabanını da düzenli olarak güncel tutmak gerekir.
  • Çözüm: Artımlı indeksleme, veritabanını belirli aralıklarla senkronize etme veya değişiklik izleme mekanizmaları kurmak.
• Model Bağlam Penceresi Sınırlamaları: Geri çağrılan çok fazla parça, LLM’in maksimum bağlam penceresini aşabilir.
  • Çözüm: En alakalı ilk N parçayı seçmek. Geri çağırma ve re-ranking adımlarını daha hassas hale getirmek. Uzun bağlam pencereli yeni nesil LLM’leri değerlendirmek.

Değerlendirme (Evaluation): LLM ve RAG Sistemlerinin Performansını Nasıl Ölçeriz?

Bir LLM veya RAG tabanlı sistem geliştirmek, işin sadece bir kısmıdır. Asıl zorluk ve kritik aşama, bu sistemin gerçek dünya koşullarında ne kadar iyi çalıştığını anlamak ve doğrulamaktır: yani değerlendirme (evaluation). Değerlendirme olmaksızın, bir modelin güvenilirliği, doğruluğu ve kullanıcılara sağladığı değer hakkında sağlam bir fikrimiz olamaz. Rastgele testler veya sezgisel yaklaşımlar, genellikle sistemdeki kritik hataları veya zayıflıkları gözden kaçırabilir. Bu nedenle, sistematik ve kapsamlı bir değerlendirme süreci, LLM mühendisliği yaşam döngüsünün vazgeçilmez bir parçasıdır.

Değerlendirme, sisteminizin bir dizi önceden belirlenmiş metrik ve kriter üzerinden performansını ölçmeyi içerir. Temel olarak, “Modelim doğru cevaplar üretiyor mu?”, “Cevapları kullanıcının sorusuyla ne kadar alakalı?”, “Verilen bağlamdan sapıyor mu?”, “İstenmeyen veya zararlı içerik üretiyor mu?” gibi sorulara yanıt ararız.

LLM ve RAG sistemlerini değerlendirirken kullanılan bazı önemli metrikler şunlardır:

• Doğruluk (Accuracy): Üretilen cevabın gerçekle ne kadar örtüştüğünü ölçer. Özellikle olgusal sorular için hayati öneme sahiptir. Yanlış bilgi veya halüsinasyon riskini değerlendirmek için kullanılır.
• Alaka Düzeyi (Relevance): Üretilen cevabın, kullanıcının orijinal sorgusuyla ne kadar ilgili olduğunu gösterir. Bazen doğru cevaplar bile, sorulan şeyle doğrudan alakalı olmayabilir.
• Tutarlılık (Coherence): Cevabın akıcı, anlaşılır ve mantıksal bir bütünlük içinde olup olmadığını değerlendirir. Dilbilgisi, imla ve cümle yapısı gibi unsurlar bu kategoriye girer.
• Güvenilirlik (Faithfulness): Özellikle RAG sistemlerinde kritik olan bu metrik, cevabın geri çağrılan kaynaklardan ne kadar türetildiğini ve bu kaynakların ötesine geçip geçmediğini (yani halüsinasyon yapıp yapmadığını) ölçer. Cevabın destekleyici kanıtlarla ne kadar uyumlu olduğu önemlidir.
• Yardımseverlik (Helpfulness): Cevabın kullanıcının amacına ne kadar hizmet ettiğini, sorunu çözüp çözmediğini veya bilgi ihtiyacını karşılayıp karşılamadığını gösterir.
• Toksisite ve Yanlılık (Toxicity & Bias): Modelin zararlı, offensive, ayrımcı veya yanlı içerik üretme eğilimini ölçer. Bu, etik AI geliştirmenin önemli bir parçasıdır.

Değerlendirme yöntemlerine geldiğimizde, farklı yaklaşımlar bulunmaktadır:

1. İnsan Değerlendirmesi (Human Evaluation): En güvenilir ama en pahalı ve zaman alıcı yöntemdir. Uzman insan anotatörler, test setindeki sorulara verilen model cevaplarını yukarıdaki metrikler açısından puanlar. Bu, ince nüansları yakalamak ve sübjektif kaliteyi değerlendirmek için vazgeçilmezdir.
2. Otomatik Metrikler (Automatic Metrics): BLEU ve ROUGE gibi geleneksel metrikler, üretilen metni referans metinlerle kelime veya n-gram örtüşmesi üzerinden karşılaştırır. Ancak bu metrikler, anlamsal farklılıkları veya farklı ama doğru cevapları yakalamakta yetersiz kalabilir. Daha yeni otomatik metrikler (örn. BERTScore, MoverScore) anlamsal benzerliğe daha fazla odaklanır.
3. LLM Tabanlı Değerlendirme (LLM-as-a-Judge): Başka bir LLM’i, orijinal modelin çıktılarını değerlendirmek için kullanmak giderek popülerleşen bir yaklaşımdır. Bir “hakem LLM”e hem orijinal soru, hem modelin cevabı, hem de bazen referans cevaplar veya bağlam verilerek bir değerlendirme promptu sunulur. Hakem LLM, belirlenen kriterlere göre cevabı puanlar veya geri bildirim sağlar. Bu yöntem, insan değerlendirmesine göre daha hızlı ve ölçeklenebilir olabilir, ancak hakem LLM’in kendi yanlılıkları ve sınırlılıkları da göz önünde bulundurulmalıdır.

Bir e-ticaret müşteri destek botunun performansını değerlendirdiğimizi varsayalım. Binlerce müşteri sorusunu içeren bir test seti oluşturduk. Her soru için botun verdiği cevabı kaydediyoruz. Daha sonra:

• Bir grup insan anotatör, botun cevaplarını “Doğru mu?”, “Soruyla alakalı mı?”, “Anlaşılır mı?”, “Yardımcı oldu mu?” gibi 1-5 arası bir ölçekte puanlar.
• Aynı zamanda, Python’da geliştirilen bir script ile bazı temel otomatik metrikleri (örn. cevapta anahtar kelime varlığı, cevap uzunluğu) kontrol edebiliriz.
• Gelişmiş bir yöntem olarak, GPT-4 gibi daha güçlü bir LLM’i “hakem” olarak kullanarak, her cevabı belirli bir prompt çerçevesinde değerlendirmesini isteyebiliriz. Örneğin:

  
            "Sen bir AI asistanı değerlendirme uzmanısın. Aşağıdaki müşteri sorusuna verilen cevabı doğruluğu, alaka düzeyi ve yardımseverliği açısından 1'den 5'e kadar puanla. Ayrıca kısa bir yorum yap.
            Müşteri Sorusu: 'Ayakkabı iadesi nasıl yapılır?'
            Bot Cevabı: 'Ayakkabı iadesi için web sitemizdeki iade formunu doldurmanız ve ürünü orijinal kutusunda, faturasıyla birlikte anlaşmalı kargo şirketimiz aracılığıyla bize göndermeniz gerekmektedir.'
            Değerlendirme Kriterleri:
            1. Doğruluk (1-5): Cevap doğru bilgi içeriyor mu?
            2. Alaka Düzeyi (1-5): Cevap doğrudan soruyla ilgili mi?
            3. Yardımseverlik (1-5): Cevap müşterinin sorununu çözmeye yardımcı oluyor mu?
            Yorum:"
          

  Bu şekilde, sistemli bir yaklaşımla botun performansını nicel ve nitel olarak ölçebiliriz. Elde ettiğimiz veriler, promptlarımızı iyileştirmek, RAG stratejilerimizi gözden geçirmek veya hatta temel LLM'i değiştirmek için değerli geri bildirimler sağlar.

LLM Tabanlı Değerlendirme Nasıl Yapılır ve Ne Zaman Kullanılmalıdır?

LLM'leri kullanarak başka LLM'lerin veya RAG sistemlerinin performansını değerlendirme fikri, "LLM-as-a-Judge" (Hakem Olarak LLM) olarak bilinir. Bu yöntem, insan değerlendirmesinin maliyetini ve ölçeklenebilirlik sorunlarını azaltmak için cazip bir alternatif sunar. İşte nasıl çalıştığı ve ne zaman kullanılması gerektiği:

Nasıl Yapılır?

1. Değerlendirme Kriterlerini Tanımlayın: İlk adım, modelden ne beklediğinizi netleştirmektir. Doğruluk, alaka düzeyi, tutarlılık, yardımseverlik, toksisite, kısalık gibi kriterleri belirleyin.
2. Hakem LLM Seçimi: Genellikle, değerlendirilecek modelden daha yetenekli ve daha az "halüsinasyon" yapma eğiliminde olan daha büyük, daha güçlü bir LLM (örn. GPT-4, Claude Opus) hakem olarak seçilir.
3. Değerlendirme Promptunu Tasarlayın: Bu, en kritik adımdır. Hakem LLM'e şu bilgileri sağlamalısınız:
   • Hakem LLM'in rolü (örn. "Sen bir AI asistanı değerlendirme uzmanısın.").
   • Değerlendirilecek orijinal soru/görev.
   • Değerlendirilecek modelin ürettiği cevap.
   • İsteğe bağlı olarak, doğru kabul edilen referans cevap(lar) veya RAG sistemleri için kullanılan bağlam metinleri.
   • Her bir kriter için açık puanlama talimatları veya derecelendirme ölçekleri (örn. 1-5 arası puanlama, "Evet/Hayır" kararları).
   • Çıktı formatı (JSON, serbest metin yorumu vb.).

   
             "Sen, bir teknik metin özetleyici değerlendiren bir uzmansın. Aşağıdaki metni ve özetini dikkatlice oku. Özetin orijinal metindeki ana fikirleri ne kadar iyi yakaladığını (Doğruluk) ve akıcı, anlaşılır olup olmadığını (Tutarlılık) 1'den 5'e kadar puanla. Puanlamadan sonra kısa bir açıklama yap.
             [Orijinal Metin]
             [Model Tarafından Üretilen Özet]
             Doğruluk:
             Tutarlılık:
             Açıklama:"
           

4. Toplu Değerlendirme ve Analiz: Hazırlanan değerlendirme promptu, test setindeki her bir soru-cevap çifti için hakem LLM'e gönderilir. Gelen puanlar ve yorumlar toplanarak istatistiksel analizler yapılır.

Ne Zaman Kullanılmalıdır?

• Hızlı ve Ölçeklenebilir Geri Bildirim İhtiyacı: İnsan değerlendirmesi için yeterli bütçe veya zamanınız olmadığında, ancak yine de niteliksel geri bildirime ihtiyaç duyduğunuzda idealdir.
• İlk Geliştirme Aşamaları: Modeli veya promptu geliştirmenin erken aşamalarında, hızlı iterasyonlar yapmak ve farklı yaklaşımların etkisini görmek için kullanılabilir.
• İnsan Değerlendirmesini Desteklemek: İnsan değerlendirmesine ek olarak, daha geniş bir veri seti üzerinde hızlı bir ön eleme veya ikincil doğrulama katmanı olarak işlev görebilir.
• Sübjektif Metrikler İçin: Doğruluk gibi objektif metrikler için otomatik metrikler yeterli olsa da, tutarlılık, akıcılık, yaratıcılık gibi daha sübjektif metrikler için LLM-as-a-Judge insan değerlendirmesine daha yakın sonuçlar verebilir.

Ancak, LLM-as-a-Judge kullanırken, hakem LLM'in kendi yanlılıkları, tutarsızlıkları ve "gerçeklikten sapma" potansiyeli (halüsinasyon) olduğu unutulmamalıdır. Bu nedenle, kritik uygulamalarda her zaman bir miktar insan değerlendirmesiyle desteklenmesi önerilir.

Prompt, RAG ve Eval Döngüsünü Gerçek Dünya Projelerine Nasıl Uygularız? (Vaka Analizi ve İleri Düzey)

Şimdiye kadar prompt mühendisliğinin, RAG sistemlerinin ve değerlendirme süreçlerinin temel prensiplerini ayrı ayrı ele aldık. Ancak gerçek dünya projelerinde, bu bileşenler izole bir şekilde değil, birbirini tamamlayan entegre bir döngü içinde çalışır. Bu bölümde, bir şirketin kendi iç dökümanlarından bilgi çeken bir kurumsal asistan geliştirme senaryosu üzerinden bu döngüyü adım adım inceleyelim. Bu vaka analizi, LLM mühendislerinin karşılaşabileceği zorlukları ve ileri düzey stratejileri de kapsayacaktır.

Vaka Analizi: Büyük Bir Enerji Şirketinin İç Doküman Asistanı

Büyük bir enerji şirketi, binlerce sayfalık teknik şartname, güvenlik prosedürü, proje raporu ve şirket içi kılavuzdan oluşan devasa bir bilgi havuzuna sahip. Mühendisler ve saha çalışanları, aradıkları bilgilere ulaşmakta zorlanıyor, bu da verimlilik kaybına ve operasyonel gecikmelere yol açıyor. Şirket, bu sorunu çözmek için bir "Akıllı Doküman Asistanı" geliştirmeye karar veriyor.

Faz 1: Temel Prompt ve Ham LLM Testi (Keşif ve Başlangıç)

• Amaç: Genel bir LLM'in, temel promptlarla ne kadar başarılı olabileceğini anlamak.
• Uygulama:
  • Öncelikle, bir açık kaynaklı LLM (örn. Llama 2 7B) veya bir API tabanlı model (örn. GPT-3.5) seçilir.
  • Mühendisler, birkaç basit prompt ile modelin genel bilgi sorularına veya şirkete özel olmayan sorulara nasıl yanıt verdiğini test eder. Örneğin: "Bir enerji santralinde güvenlik prosedürleri neden önemlidir?"
  • Bu aşamada, modelin şirkete özel bilgilere (örn. "Bizim X projesindeki güvenlik protokolleri nedir?") cevap veremediği veya halüsinasyon yaptığı hızlıca anlaşılır. Bu, RAG'ye olan ihtiyacı netleştirir.
• Değerlendirme: Bu fazda informal bir insan değerlendirmesi yapılır. Temel çıktı kalitesi ve halüsinasyon eğilimi gözlemlenir.

Faz 2: RAG Entegrasyonu (Bilgi Temeli Oluşturma)

• Amaç: Şirket içi dokümanları LLM'e erişilebilir hale getirmek ve güncel, doğru bilgi sağlamak.
• Uygulama:
  • Doküman Toplama ve Hazırlık: Tüm teknik şartnameler, kılavuzlar, raporlar toplanır. OCR (Optik Karakter Tanıma) ile taranmış PDF'ler metin formatına dönüştürülür.
  • Akıllı Chunking Stratejisi: Enerji mühendisleriyle iş birliği içinde, dokümanların yapısal özelliklerine göre parçalama stratejisi belirlenir. Örneğin, teknik şartnameler bölüm bazında, güvenlik prosedürleri ise madde bazında parçalanır. Parçalar arasında küçük örtüşmeler eklenerek bağlamın korunması sağlanır.
  • Embedding Modeli ve Vektör Veritabanı: Sektöre özgü terimleri daha iyi anlayabilen Sentence Transformers tabanlı bir embedding modeli (örn. belirli bir alanda ince ayarlı olanlar) seçilir. Milvus veya Qdrant gibi kendi kendine barındırılan (self-hosted) bir vektör veritabanı kurulur ve tüm doküman parçalarının embedding'leri buraya indekslenir.
  • Retriever ve Prompt Oluşturma: Kullanıcı sorgusu alındığında, vektör veritabanından en alakalı N adet parça geri çağrılır. Bu parçalar, LLM'e verilen prompt'a eklenir. Prompt, LLM'den bu bağlamı kullanarak ve "sadece bu bağlamdaki bilgilerle" cevap vermesini ister.

  
                "Sen bir enerji şirketi doküman asistanısın. Aşağıdaki bağlamı kullanarak, kullanıcının sorusuna net ve kısa bir cevap ver. Bağlamda bulunmayan bilgileri uydurma.
                Bağlam:
                [Geri Çağrılan Doküman Parçaları]
                Kullanıcı Sorusu: 'X projesinde acil durum kapatma prosedürü nedir?'"
              

Faz 3: Kapsamlı Değerlendirme ve İyileştirme Döngüsü (Optimizasyon)

• Amaç: Sistemin performansını nicel ve nitel olarak ölçmek, zayıflıkları belirlemek ve sürekli iyileştirme için bir döngü oluşturmak.
• Uygulama:
  • Test Seti Oluşturma: Şirket içinden gerçek kullanıcı soruları (anonimleştirilmiş) toplanarak kapsamlı bir test seti oluşturulur. Her soru için uzmanlar tarafından referans cevaplar yazılır.
  • Metrik Tabanlı Değerlendirme:
    • Doğruluk: Referans cevaplarla karşılaştırılarak puanlanır.
    • Güvenilirlik (Faithfulness): Cevabın geri çağrılan dokümanlarda bulunup bulunmadığı kontrol edilir.
    • Alaka Düzeyi: Cevabın sorulan soruyla ne kadar ilgili olduğu değerlendirilir.
    • Yardımseverlik: Cevabın kullanıcının ihtiyacını karşılayıp karşılamadığı (insan değerlendirmesiyle).
  • LLM Tabanlı Değerlendirme: GPT-4 gibi bir hakem LLM kullanılarak, test setindeki tüm cevaplar otomatik olarak puanlanır ve yorumlanır. Bu, insan değerlendirmesine göre daha hızlı ve ölçeklenebilir geri bildirim sağlar.
  • İnsan Geri Bildirimi: Belirli aralıklarla (örn. haftalık), gerçek kullanıcıların sistemle etkileşimlerinden alınan geri bildirimler (beğenme/beğenmeme butonları, serbest metin yorumları) toplanır ve analiz edilir.
  • A/B Testleri: Farklı prompt stratejileri, chunking yöntemleri veya retriever optimizasyonları A/B testleriyle karşılaştırılarak hangi konfigürasyonun daha iyi performans gösterdiği belirlenir.
• Geri Bildirim Döngüsü: Değerlendirme sonuçları analiz edilir. Eğer sistem halüsinasyon yapıyorsa, RAG'deki chunking veya retriever optimize edilir. Cevaplar yetersizse, promptlar iyileştirilir. Düşük alaka düzeyi varsa, embedding modeli veya re-ranking stratejileri gözden geçirilir.

Faz 4: Sürekli İyileştirme ve Bakım (İleri Düzey Stratejiler)

• Amaç: Sistemin canlıda (production) sürekli olarak yüksek performans göstermesini sağlamak.
• Uygulama:
  • Aktif Öğrenme (Active Learning): Düşük güvenilirlikli veya olumsuz geri bildirim alan cevaplar otomatik olarak insan incelemesine yönlendirilir. Bu örnekler, yeni test setleri oluşturmak ve modeli daha da geliştirmek için kullanılır.
  • Model Güncellemeleri: Periyodik olarak daha yeni, daha yetenekli LLM'ler veya embedding modelleri değerlendirilir ve entegre edilir.
  • Doküman Güncelleme Otomasyonu: Şirketin yeni dokümanları yayınlandığında, RAG sisteminin bilgi tabanını otomatik olarak indekslemesi ve güncellemesi için CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) süreçleri kurulur.
  • Monitoring ve Alarm Sistemi: Canlı sistemin performans metrikleri (cevap süresi, hata oranı, kullanıcı memnuniyeti) sürekli izlenir. Anormallikler durumunda otomatik alarmlar tetiklenir.

Bu vaka analizi, Prompt, RAG ve Eval'ın bir LLM mühendisliği projesinde ayrılmaz bir üçlü olduğunu göstermektedir. Her bileşen, bir sonraki adım için gerekli veriyi ve içgörüyü sağlar. Bu sürekli iyileştirme döngüsü, sadece başlangıçta değil, bir ürünün tüm yaşam döngüsü boyunca sürdürülmesi gereken kritik bir süreçtir.

Sonuç: LLM Mühendisliğinde Sürekli İyileştirmenin Önemi

Büyük Dil Modelleri (LLM'ler) ve etrafında gelişen ekosistem, şüphesiz ki teknoloji dünyasının en dinamik ve dönüştürücü alanlarından biri. Bu makale boyunca ele aldığımız Prompt Mühendisliği, Retrieval Augmented Generation (RAG) ve Değerlendirme (Evaluation) süreçleri, bir LLM mühendisinin araç kutusunun temel taşlarını oluşturuyor. Gördüğümüz gibi, ham bir LLM'i alıp doğrudan kullanmak çoğu zaman yetersiz kalırken, bu üç bileşeni entegre ve döngüsel bir yaklaşımla uygulamak, sağlam, güvenilir ve yüksek performanslı yapay zeka uygulamaları geliştirmenin anahtarıdır.

Prompt mühendisliği, LLM'ler ile etkin bir diyalog kurmamızı sağlayarak, onların geniş bilgi ve dil üretim yeteneklerini belirli görevlere yönlendirir. Doğru tasarlanmış promptlar, modelin istenen çıktıyı üretme olasılığını artırır ve istenmeyen "halüsinasyonları" minimize eder. RAG ise, LLM'lerin bilgi ufkunu güncel ve spesifik harici veri tabanlarıyla genişleterek, onları kurumsal ve niş uygulamalar için vazgeçilmez kılar. Bu sayede, modeller sadece öğrendikleri genel bilgilere değil, aynı zamanda anlık ve özel verilere de dayalı, bağlam açısından zengin cevaplar üretebilirler. Son olarak, değerlendirme, tüm bu çabaların gerçekten işe yarayıp yaramadığını anlamamızı sağlayan kritik bir geri bildirim mekanizmasıdır. Performansı ölçmeden, iyileştirmelerin etkisini anlamak ve sistemdeki zayıflıkları gidermek mümkün değildir. İnsan değerlendirmesinden otomatik metrikler ve LLM tabanlı hakem sistemlerine kadar çeşitli değerlendirme yöntemleri, sistemlerimizin kalitesini sürekli olarak güvence altına almamızı sağlar.

Bir LLM mühendisi olarak, bu üç alanın birbirini besleyen dinamik bir döngü içinde olduğunu asla unutmamalısınız. Bir promptu iyileştirmek, RAG'in daha alakalı bilgi getirmesine yardımcı olabilir; RAG'den gelen daha iyi bağlam, promptun daha basit olmasını sağlayabilir. Her ikisinin de değerlendirilmesi, bir sonraki iyileştirme adımının ne olacağını gösterir. Bu sürekli iyileştirme (continuous improvement) felsefesi, başarılı LLM tabanlı ürün ve hizmetlerin temelidir. Yapay zeka teknolojileri hızla gelişmeye devam ederken, bu temel prensiplere hakim olmak ve bunları etkin bir şekilde uygulamak, LLM mühendislerini geleceğin inovasyonlarında öncü kılacaktır. Unutmayın, en iyi sistemler, sürekli öğrenen ve adapte olan sistemlerdir.

Sıkça Sorulan Sorular

1. RAG mi, yoksa LLM'e ince ayar (fine-tuning) mı yapmalıyım?

Cevap: Bu, projenizin ihtiyaçlarına bağlıdır. RAG, modelin güncel ve dinamik olarak değişen bilgilere erişmesi gerektiğinde idealdir, çünkü veritabanını güncellemek LLM'i yeniden eğitmekten çok daha kolaydır. İnce ayar ise, modelin belirli bir görevde (örn. belirli bir tarzda yazma, sınıflandırma yapma) veya belirli bir alandaki dilsel nüansları öğrenmesi gerektiğinde daha etkilidir. Çoğu durumda, en iyi sonuçlar RAG ve ince ayarın birleşimiyle elde edilir: RAG ile bilgi erişimi sağlanır, ince ayar ile de modelin çıktısının istenen ton ve formatta olması sağlanır.

2. Hangi vektör veritabanını seçmeliyim?

Cevap: Seçim, ölçeklenebilirlik ihtiyacınız, maliyet bütçeniz, dağıtım modeliniz (bulut tabanlı mı, kendi kendine barındırılan mı?) ve spesifik özellikler (filtreleme, meta veri yönetimi) gibi faktörlere göre değişir. Popüler seçenekler arasında bulut tabanlı hizmetler olarak Pinecone, Weaviate Cloud ve kendi kendine barındırılabilenler olarak ChromaDB, Milvus, Qdrant ve Faiss (sadece indeksleme kütüphanesi) bulunmaktadır. Küçük projeler için ChromaDB gibi lightweight çözümler yeterli olabilirken, kurumsal düzeyde büyük ölçekli uygulamalar için Pinecone veya Milvus/Qdrant gibi daha robust çözümler tercih edilebilir.

3. LLM değerlendirmesi için ne kadar insan gücü gerekir?

Cevap: İnsan değerlendirmesi, LLM sistemlerinin kalitesi için altın standarttır ancak oldukça zaman ve kaynak yoğun olabilir. Gereken insan gücü, test setinizin büyüklüğüne, değerlendirme metriklerinin karmaşıklığına ve gereken detay seviyesine göre değişir. Genellikle, kritik performans değerlendirmeleri için küçük bir uzman panel (3-5 kişi) ile başlayıp, daha sonra örnekleminizi genişletebilirsiniz. İlk iterasyonlarda ve hızlı geri bildirim döngülerinde LLM-as-a-Judge yöntemlerini kullanarak insan gücü ihtiyacını azaltabilirsiniz. Ancak üretime çıkmadan önce veya kritik güncellemelerden sonra her zaman bir miktar insan kontrolü önerilir.

4. LLM'lerin halüsinasyonlarını tamamen ortadan kaldırmak mümkün müdür?

Cevap: Şu anki teknolojiyle LLM'lerin halüsinasyon yapma eğilimini tamamen ortadan kaldırmak maalesef mümkün değildir. Ancak, bu eğilimi önemli ölçüde azaltmak için birçok strateji mevcuttur. RAG, en etkili yöntemlerden biridir çünkü LLM'e bilgi tabanlı kanıtlar sunar. Ayrıca, prompt mühendisliği (net talimatlar, "uydurma" direktifleri), daha yetenekli ve daha az halüsinasyon yapan modellerin kullanılması ve kapsamlı değerlendirme süreçleriyle potansiyel halüsinasyonların tespit edilip düzeltilmesi, bu riski minimize etmek için kritik adımlardır.