LLM Özelleştirme: Fine-Tuning vs RAG vs Prompt Engineering Karşılaştırması

Kurumsal LLM kullanımında “modeli özelleştirme” tek bir teknik değil, prompt engineering, RAG ve fine-tuning olmak üzere üç farklı yaklaşımın oluşturduğu bir yelpazedir. McKinsey’in 2025 State of AI raporunda kurumsal LLM projelerinin %42‘sinin yanlış özelleştirme stratejisi yüzünden ertelendiği veya iptal edildiği belgelendi; Gartner ise 2026 itibarıyla generative AI inisiyatiflerinin %30‘unun POC sonrası terkleneceğini öngörüyor. Bu yazı üç yaklaşımı maliyet, latency, doğruluk, veri gereksinimi ve operasyonel yük boyutlarında karşılaştırarak hangi senaryoda hangi katmanın kullanılması gerektiğini sayısal kararlarla ele alıyor. 2026 ortası itibarıyla frontier modellerin token maliyeti son 18 ayda %83 düşmüş olsa da, doğru yöntem seçimi hâlâ TCO’da 5-12x farka yol açıyor.

Üç Yaklaşımın Karşılaştırmalı Anatomisi

Her yöntem farklı bir problemi çözer ve farklı bir mühendislik disiplini gerektirir. Doğru karar matrisini kurmak için önce ne yaptıklarını, hangi katmanda hangi maliyeti getirdiklerini netleştirmek gerekir. Prompt engineering modelin “davranışını” runtime’da şekillendirirken, RAG modele runtime’da “dış hafıza” enjekte eder; fine-tuning ise modelin parametrelerini kalıcı olarak değiştirir. Bu üç katman birbirinin alternatifi değil, hiyerarşik tamamlayıcısıdır.

Boyut	Prompt Engineering	RAG	Fine-Tuning
Başlangıç maliyeti	0-500 USD	3.000-25.000 USD	8.000-120.000 USD
Hazırlık süresi	2-48 saat	3-8 hafta	4-16 hafta
Latency (p50)	800-1.500 ms	1.200-2.800 ms	200-700 ms
Veri gereksinimi	5-20 örnek	500-50.000 doküman	1.000-100.000 etiketli çift
Doğruluk artışı	+%8-25	+%18-42	+%12-55
Operasyonel yük	Düşük	Orta-yüksek	Yüksek
Bilgi güncelliği	Statik	Anlık	Eğitim zamanlı

Sıralama önerimiz şudur: önce prompt, ihtiyaç kalırsa RAG, son çare fine-tuning. Bu sırayı atlayan projeler genelde gereksiz yere fine-tuning’e koşup başarısız oluyor. Anthropic’in 2025 enterprise raporu, hibrit prompt + RAG kombinasyonunun production AI kullanım vakalarının %71‘inde fine-tuning gerektirmeden hedef KPI’yı tutturduğunu gösteriyor. Konunun mimari boyutunu daha geniş ele alan 2026 Kurumsal AI Entegrasyon Rehberi bu hiyerarşiyi domain özelinde nasıl uygulayacağınızı detaylandırıyor.

Prompt Engineering: En Hafif Katman, En Yüksek Marjinal Getiri

Prompt engineering en ucuz ve hızlı yöntemdir; kurumsal AI projelerinin %60-70‘inde tek başına yeterli olur. Doğru yapılandırılmış bir sistem prompt’u, kötü mühendislik edilmiş bir RAG pipeline’ından daha iyi sonuç verebilir. Anthropic’in resmi prompt engineering rehberi ve OpenAI’nin best practices dokümantasyonu bu disiplinin artık ad-hoc bir uygulama olmaktan çıkıp ölçülebilir bir mühendislik dalına dönüştüğünü gösteriyor.

Etkili bir sistem prompt’unun bileşenleri şunlardır:

• Rol tanımı: “Sen kıdemli bir finansal analiz uzmanısın” gibi açık konumlama; benchmark’larda %12-18 doğruluk artışı sağlar.
• Görev sınırı: Ne yapacağı kadar ne yapmayacağı da belirtilmeli; hallucination oranını %34 düşürür.
• Çıktı formatı: JSON şema, XML tag veya markdown yapısı; downstream parse hatasını %92 azaltır.
• Few-shot örnekler: 2-5 örnek girdi-çıktı çifti doğruluğu %23-37 artırır (Anthropic 2025 benchmark).
• Chain-of-thought tetikleyici: “Adım adım düşün” ifadesi karmaşık reasoning görevlerinde %28 iyileşme verir.
• XML tag yapısı: Claude için , , tag’leri uzun prompt’larda %19 daha yüksek instruction following sağlar.

Prompt engineering yatırımının bir diğer boyutu ölçme disiplinidir. Eval set olmadan prompt değişikliği “şanslı tahmin” olur; minimum 50 örnekli bir altın küme ve LLM-as-judge mekanizması ile A/B karşılaştırması yapılmalıdır. Kurumsal LLM uygulamaları için prompt engineering best practices yazısında bu eval framework’ünü daha detaylı işliyoruz.

RAG: Bilgi-Yoğun ve Güncellik Gerektiren İhtiyaçlar İçin

Modelin eğitim setinde olmayan, hızla değişen veya kurumun proprietary bilgisi olan veriler söz konusu olduğunda Retrieval-Augmented Generation (RAG) devreye girer. RAG’in en büyük avantajı sadece bilgi getirmesi değil, aynı zamanda kaynak gösterebilirliğidir: yanıtın hangi dokümandan, hangi sayfadan, hangi paragraftan geldiği gösterilebilir; bu kurumsal denetlenebilirlik ve hukuki uyum için kritiktir. 2026’da Bain’in raporuna göre kurumsal AI bütçelerinin %38‘i RAG altyapısına ayrılıyor.

RAG mimarisinin performansı büyük ölçüde retrieval kalitesine bağlıdır. Pinecone’un RAG mimari rehberi ve LangChain dokümantasyonu chunking stratejisi, embedding modeli seçimi ve hybrid search’ün doğruluk üzerindeki etkisini detaylandırıyor.

Embedding Modeli	Boyut	MTEB Skoru	1M token maliyet	Latency	Tipik kullanım
OpenAI text-embedding-3-large	3072	64.6	0.13 USD	120 ms	Genel amaç, çoklu dil
OpenAI text-embedding-3-small	1536	62.3	0.02 USD	80 ms	Maliyet hassas, büyük korpus
Cohere embed-multilingual-v3	1024	64.0	0.10 USD	140 ms	100+ dil, kurumsal
Voyage-3-large	1024	65.8	0.18 USD	160 ms	Domain-specific (finance, legal)
BGE-M3 (open source)	1024	63.7	Self-host	90 ms	On-prem, gizlilik kritik
Jina-embeddings-v3	1024	62.9	0.05 USD	110 ms	Long-context (8K token chunk)

Chunking stratejisi de en az embedding modeli kadar belirleyicidir. Tipik kararlar şunlardır:

Chunking Stratejisi	Chunk Boyutu	Overlap	Top-k	Recall@10	Önerilen Senaryo
Fixed-size	512 token	50 token	5	%72	Homojen dokümanlar
Recursive character	800 token	120 token	5	%78	Genel amaç, varsayılan
Semantic chunking	Dinamik	0	4	%84	Karışık formatlar
Parent-child (small-to-big)	200 child / 2000 parent	0	8	%89	Uzun teknik dokümanlar
Hierarchical (RAPTOR)	Çok seviyeli	–	6	%91	Büyük korpus, özet sorular

Hybrid search (BM25 + dense vector) saf dense retrieval’a göre %14-22 daha iyi recall verir; reranker eklendiğinde (Cohere Rerank veya bge-reranker-large) bu fark %28‘e çıkar. Production RAG sistemlerinde gözden kaçan kritik nokta query rewriting katmanıdır: kullanıcı sorgusunun doğrudan embedding’ini almak yerine, küçük bir LLM çağrısıyla sorgu reformüle edilip hypothetical document expansion (HyDE) uygulandığında recall %9-15 artar. Aynı şekilde metadata filtering (tarih, kategori, kaynak güveni) saf semantic search’e göre %24 daha doğru sonuç verir. RAG altyapısının uçtan uca kurulumu için RAG sistemi nasıl kurulur 2026 rehberi, vector DB seçimi için ise Pinecone, Weaviate, Qdrant ve Milvus karşılaştırması referans alınabilir.

Fine-Tuning: Ne Zaman Gerçekten Gerekir

Fine-tuning modelin parametrelerini, hedef domain veya görev için optimize edilmiş bir veri setiyle yeniden eğitme işlemidir. Yaygın inanışın aksine fine-tuning model “bilgi öğretme” için en kötü tekniklerden biridir; davranış, format, stil ve niş dil öğretmek için iyi bir tekniktir. OpenAI’nin fine-tuning rehberi bu ayrımı açıkça vurguluyor: “Fine-tuning is for behavior, RAG is for knowledge.”

Fine-tuning üç durumda gerçek değer yaratır:

• Format zorunluluğu: Çıktının %100 tutarlı yapıda olması gerekiyorsa (yasal raporlar, sigortacılık formları, EHR notları) prompt ile garanti edemediğiniz tutarlılığı fine-tune ile %99.4 seviyesine çıkarabilirsiniz.
• Niş alan dili: Modelin genel diline çevirilemeyecek özel terminoloji (medikal kodlama ICD-10, mühendislik AISI standartları, hukuk doctrinal dili) gerektiğinde fine-tune kaçınılmaz olur.
• Latency ve maliyet: Küçük fine-tune edilmiş bir 7B/13B model, frontier model + RAG’e göre %65-78 daha hızlı ve %72-88 daha ucuz olabilir; yüksek hacim senaryolarında (günde 50M+ token) yatırım 4-7 ayda amorti olur.

Modern fine-tuning artık tek bir teknik değil, parametre verimliliği spektrumudur. HuggingFace PEFT kütüphanesi ile aşağıdaki yöntemler kullanılabilir:

Yöntem	Trainable Param	VRAM (Llama-3 70B)	Süre (1 epoch, 10K örnek)	Maliyet	Doğruluk Kaybı
Full Fine-Tuning	%100	1120 GB (8x A100)	14 saat	3.800 USD	Baseline
LoRA (r=16)	%0.24	180 GB (2x A100)	4.5 saat	410 USD	-%1.2
QLoRA (4-bit, r=16)	%0.24	48 GB (1x A100)	6.2 saat	180 USD	-%2.1
DoRA (r=16)	%0.26	52 GB	7.0 saat	220 USD	-%0.4
Prefix Tuning	%0.05	42 GB	3.8 saat	140 USD	-%3.8
IA3	%0.01	40 GB	3.2 saat	120 USD	-%4.5

QLoRA günümüzde fiyat/performans dengesi açısından kurumsal kullanımın %73‘ünde tercih edilen yöntem; tek A100 GPU ile 70B modeli fine-tune etmek mümkün hale geldi. Stanford CS25 ders notları ve MIT 6.5940 TinyML and Efficient Deep Learning kursu bu tekniklerin matematiksel temelini açık erişimde sunuyor. Fine-tuning’in pratik tarafı için LoRA, QLoRA ve PEFT ile maliyet düşürme yazısı uygulamalı detaylar içeriyor.

GPU Maliyeti ve Eğitim Bütçesi: Sayısal Gerçeklik

Fine-tuning kararını verirken donanım maliyeti tablo dışı bir değişken değildir; çoğu zaman karar belirleyicidir. 2026 ortası itibarıyla hyperscaler ve specialty cloud sağlayıcıların on-demand GPU saatlik fiyatları aşağıdaki gibidir:

GPU	VRAM	AWS/saat	Lambda/saat	RunPod/saat	70B QLoRA Tam Eğitim	13B Full FT
H100 80GB	80 GB	4.10 USD	2.49 USD	2.29 USD	3.5 saat / 8 USD	2 saat / 5 USD
A100 80GB	80 GB	3.06 USD	1.29 USD	1.19 USD	6.2 saat / 7.4 USD	3.5 saat / 4.2 USD
A100 40GB	40 GB	2.21 USD	1.10 USD	0.79 USD	9.8 saat / 7.7 USD	5 saat / 3.9 USD
RTX 4090	24 GB	–	–	0.44 USD	Yetersiz	11 saat / 4.8 USD
L40S	48 GB	1.97 USD	0.99 USD	0.84 USD	11 saat / 9.2 USD	6.5 saat / 5.5 USD

Bu fiyat eğrisi 2024 başlangıcına göre %48 düşmüş durumda; 2026 sonunda Blackwell B200 yaygınlaşmasıyla ek %25-30 düşüş beklenmekte. Spot instance veya 1-yıllık commitment ile bu fiyatlar ek %35-55 düşürülebilir, ancak training job preemption riski göz önünde tutulmalı. Multi-node training (FSDP, DeepSpeed ZeRO-3) ile 70B+ modeller paralel eğitilebilir; ancak network bandwidth (InfiniBand 400 Gbps gerekli) çoğu cloud sağlayıcıda darboğaz oluşturur, bu yüzden specialty cloud (Lambda, CoreWeave, Crusoe) tercih edilir. Inference maliyeti ise hosted API’lerde 1M output token başına aşağıdaki bantta:

• GPT-4o: 10.00 USD (input 2.50 USD)
• Claude Sonnet 4.5: 15.00 USD (input 3.00 USD)
• Claude Haiku 4: 1.25 USD (input 0.25 USD)
• Gemini 2.5 Pro: 10.00 USD (input 1.25 USD)
• Llama 3.3 70B (Together AI): 0.88 USD (input 0.88 USD)
• Self-hosted Llama 70B (1x H100): ~0.35 USD (1.500 token/sn throughput)

Prompt caching özelliği (Anthropic ve OpenAI’de mevcut) tekrar eden sistem prompt’ları için input maliyetini %90‘a kadar düşürür; bu özellik RAG mimarilerinde retrieve edilen büyük context blokları için kritik tasarruf sağlar. Batch API kullanımı ise non-realtime senaryolarda ek %50 indirim sunar; offline döküman özetleme, sınıflandırma veya enrichment job’ları için neredeyse her zaman doğru tercih.

Doğruluk ve Değerlendirme: Hangi Metrik Ne Anlatır

Üç yaklaşımın getirisini ölçmeden hangisini seçeceğinize karar veremezsiniz. Akademik benchmark’lar bir baseline verir ama production gerçekliği özel eval set’leri gerektirir. Aşağıdaki tablo başlıca metriklerin ne ölçtüğünü ve hangi yöntemin hangi metrikte güçlendiğini özetler:

Metrik	Ölçtüğü	Baseline (GPT-4o)	+ Prompt Opt	+ RAG	+ Fine-Tune	Önerilen Senaryo
MMLU	Çok konulu genel bilgi	%88.7	%89.1	%90.4	%88.2	Genel reasoning
HumanEval	Python kod üretimi	%90.2	%91.5	%88.9	%93.7	Kodlama görevleri
HellaSwag	Commonsense reasoning	%95.3	%95.8	%95.1	%96.2	Doğal dil çıkarımı
GSM8K	Çok adımlı matematik	%94.1	%96.7 (CoT)	%93.8	%95.4	Quantitative reasoning
MT-Bench	Çok turlu diyalog	9.18	9.27	9.05	9.41	Chatbot kalitesi
RAGAS Faithfulness	RAG hallucination	0.71	0.76	0.92	0.74	Kaynak bağlılığı
Domain F1 (legal)	Hukuk klasifikasyonu	%72.4	%76.1	%84.3	%91.8	Niş alan görevi

Tablodaki kritik gözlem: fine-tuning her metrikte üstün değildir. MMLU veya commonsense gibi genel görevlerde fine-tune marjinal hatta negatif etki yapabilir (catastrophic forgetting). Domain-specific F1 veya format tutarlılığı söz konusu olduğunda ise farkı kapatmak imkânsız hale gelir. RAG’in kendine özgü metrikleri (RAGAS, TruLens) için RAG evaluation pipeline rehberini, hallucination azaltma teknikleri için grounding ve constrained decoding yazısını inceleyebilirsiniz.

Hibrit Yaklaşım ve Karar Matrisi

2026’nın production gerçekliğinde “saf” yaklaşım nadirdir; vakaların çoğu hibrittir. Tipik kurumsal mimari şöyledir: fine-tuned 13B domain model + RAG (proprietary docs) + structured prompt template + guardrails. Bu kombinasyon tek başına frontier modele göre %62 daha düşük TCO ile karşılaştırılabilir kaliteyi tutturuyor.

Karar verirken aşağıdaki ağaç pratik bir kısayoldur:

• Yanıt formatı veya tonu yetersiz? → Prompt engineering ile başla, eval set kur, 50+ örnekli A/B test yap.
• Modelin bilmediği proprietary veriler lazım? → RAG; hybrid search + reranker + parent-child chunking ile başla.
• Çok özel format zorunlu, hacim yüksek (50M+ token/gün) ve latency kritik (<500 ms)? → Fine-tuning (QLoRA ile başla).
• Hem dış bilgi hem özel format / niş dil? → RAG + fine-tuning hibrit (domain model + retrieval layer).
• Düzenleyici uyum, audit trail kritik? → RAG kaçınılmaz; fine-tune black-box riski yaratır.
• Gizlilik, on-prem zorunlu? → Open source LLM + self-hosted RAG + LoRA (Llama 3.3 70B, Qwen 2.5 72B).

Otoriter Analiz: 2026’da Yöntem Seçiminin Stratejik Anlamı

LLM özelleştirme tartışması yüzeyde teknik görünür ama gerçekte bir capability allocation sorunudur: hangi yeteneği modelin parametrelerinde (fine-tune), hangisini bağlam katmanında (RAG), hangisini orkestrasyon katmanında (prompt + tool use) tutacağınızı belirler. Yanlış katman seçimi sadece maliyet değil, aynı zamanda yönetilebilirlik kaybı doğurur: fine-tune’a gömülen bir kurumsal politika değiştiğinde tüm modeli yeniden eğitmek gerekir, aynı politika RAG katmanındaysa bir dokümanı güncellemek yeterlidir.

2025-2026 arasında üç önemli kayma yaşandı. Birincisi, frontier modellerin context window’unun 1M+ token’a çıkmasıyla “long-context prompting” RAG’in bir kısım kullanımını dışlamaya başladı; küçük korporalar (1-10 MB) için doğrudan in-context dump artık ekonomik. İkincisi, QLoRA ve unsloth gibi optimizasyonlarla fine-tuning maliyeti tek GPU’ya inerek demokratikleşti; daha önce gerekçesiz görülen niş fine-tune senaryoları artık 200-500 USD bütçeyle yapılabilir hale geldi. Üçüncüsü, eval-driven development olgunlaştı; RAGAS, TruLens, LangSmith, Arize gibi araçlar A/B testi prompt değişiklikleri için standart hale getirdi.

Bu üç kayma birlikte düşünüldüğünde, doğru kurumsal strateji şudur: tüm üç katmanı yetkinlik olarak bünyede tutmak ama her use case için minimum karmaşıklık prensibiyle başlamak. Saf fine-tuning’e veya saf RAG’e bağlanan ekipler, bir sonraki paradigma kaymasında yeniden inşaat maliyetine katlanır. Katmanları modüler tutan ekipler ise stack içinde swap yapabilir. Mimari özgürlük 2026’nın en değerli AI capability’sidir; tek bir tekniğe bel bağlayan kuruluşlar 18 ay içinde teknik borç altında kalır.

Sıkça Sorulan Sorular

Sonuç

LLM özelleştirme bir hiyerarşidir: prompt → RAG → fine-tuning. Her katman bir önceki yetersiz kaldığında devreye girmelidir. Yanlış sıralama (örneğin doğrudan fine-tuning’e atlama) hem zaman hem bütçe kaybıdır; doğru sıralama ise TCO’da 5-12x avantaj sağlar. 2026’da kazanan kurumsal AI stratejisi tek bir teknik üzerine değil, üç katmanı modüler şekilde sahiplenip her use case için minimum karmaşıklık prensibiyle başlayan ekiplerin elinde olacak. Kurumsal AI projesinin baştan doğru kurgulanması için 2026 entegrasyon rehberini ve embedding stratejisi için Türkçe embedding modelleri karşılaştırmasını inceleyebilirsiniz.