RAG mı Fine-tuning mi? Production LLM Kararları için Kesin Rehber

# RAG mı Fine-tuning mi? Production LLM Kararları için Kesin Rehber

"Modelimizi şirket verilerimizle akıllı hale getirmek istiyoruz" — bu cümleyi duyan her AI mimarının ilk sorusu şu olur: RAG mi yapayım, fine-tuning mi? Yanlış seçim, hem maliyet hem kalite hem de geliştirme süresi açısından ciddi kayıplara yol açar. 2026'da bu karar daha da kritik çünkü seçenekler çoğaldı, araçlar olgunlaştı ve production başarısızlıkları hakkında gerçek deneyimler birikti. Bu rehber, her iki tekniği de teknik derinlikte inceliyor, gerçek maliyet hesapları yapıyor ve hangi durumda hangisinin doğru olduğunu somut kriterlerle ortaya koyuyor.

💡 Pro Tip: RAG ve fine-tuning rakip değil tamamlayıcıdır. Doğru soru "hangisi?" değil "hangi bileşen için hangisi?" olmalı.

İçindekiler

• RAG ve Fine-tuning'in Temel Farkı
• RAG Mimarisi: Bileşenler ve Varyantlar
• Embedding Modelleri: Seçim Rehberi
• Vector Database Karşılaştırması
• Fine-tuning Teknikleri: LoRA, QLoRA, DPO
• Maliyet ve Performans Analizi
• Karar Matrisi: Ne Zaman Hangisi?
• Hibrit Yaklaşım: RAG + Fine-tuning
• Production'da Yaygın Hatalar
• Sonuç ve Öneriler

RAG ve Fine-tuning'in Temel Farkı

Önce sezgisel anlamda netleştirelim:

• Fine-tuning:: Modelin _ağırlıklarını_ değiştiriyorsun. Bilgi modelin içine "gömülüyor". Sonrasında bu bilgiye erişmek için ekstra adım yok ama bilgiyi güncellemek yeni bir training gerektiriyor.

• RAG (Retrieval-Augmented Generation):: Modelin ağırlıkları değişmiyor. Sorgu geldiğinde dışarıdaki bir bilgi deposundan ilgili belgeler çekiliyor, bu belgeler prompt'a ekleniyor, model cevabı bu bağlamla üretiyor. Bilgi güncellemek = vektör veritabanını güncellemek.

1Fine-tuning Akışı:
2[Özel Veriler] → [Training] → [Güncellenmiş Model] → [Sorgu] → [Yanıt]
3 
4RAG Akışı:
5[Sorgu] → [Embedding] → [Vector DB Arama] → [Bağlam Belgeler]
6         ↓
7[Sorgu + Bağlam] → [Temel LLM] → [Yanıt]

Bu mimari fark, tüm maliyet, güncelleme kolaylığı ve performans trade-off'larını belirliyor.

RAG Mimarisi: Bileşenler ve Varyantlar

Temel RAG

En basit RAG pipeline'ı 4 bileşenden oluşur:

1interface RAGPipeline {
2  // 1. Indexing: belgeler önce işlenir
3  indexDocument(doc: Document): Promise;
4 
5  // 2. Retrieval: sorgu ile ilgili belgeler bulunur
6  retrieve(query: string, topK: number): Promise;
7 
8  // 3. Augmentation: bağlam prompt'a eklenir
9  buildPrompt(query: string, chunks: Chunk[]): string;
10 
11  // 4. Generation: LLM cevap üretir
12  generate(prompt: string): Promise;
13}
14 
15// Örnek implementasyon
16class SimpleRAG implements RAGPipeline {
17  constructor(
18    private embedder: EmbeddingModel,
19    private vectorDB: VectorDatabase,
20    private llm: LLMClient
21  ) {}
22 
23  async indexDocument(doc: Document): Promise {
24    const chunks = chunkDocument(doc, { size: 512, overlap: 64 });
25    for (const chunk of chunks) {
26      const embedding = await this.embedder.embed(chunk.text);
27      await this.vectorDB.upsert({
28        id: chunk.id,
29        vector: embedding,
30        metadata: { text: chunk.text, source: doc.source }
31      });
32    }
33  }
34 
35  async retrieve(query: string, topK = 5): Promise {
36    const queryEmbedding = await this.embedder.embed(query);
37    const results = await this.vectorDB.search(queryEmbedding, topK);
38    return results.map(r => r.metadata as Chunk);
39  }
40 
41  buildPrompt(query: string, chunks: Chunk[]): string {
42    const context = chunks.map(c => c.text).join('
43 
44---
45 
46');
47    return `Aşağıdaki bağlamı kullanarak soruyu yanıtla:
48 
49BAĞLAM:
50${context}
51 
52SORU: ${query}
53 
54YANIT:`;
55  }
56 
57  async generate(prompt: string): Promise {
58    return this.llm.complete(prompt);
59  }
60}

Advanced RAG Teknikleri

Naive RAG'ın sorunları gerçek production'da hızla ortaya çıkıyor: gürültülü retrieval, yanlış chunk boyutları, sorgu-belge semantik uyuşmazlıkları. Bu sorunları çözen gelişmiş teknikler:

1. Query Rewriting: Kullanıcının sorusunu retrieval için optimize ederek daha iyi belge çekimi.

1async function rewriteQueryForRetrieval(
2  originalQuery: string,
3  llm: LLMClient
4): Promise {
5  const prompt = `Aşağıdaki soruyu belge arama için 3 farklı şekilde yeniden yaz.
6Her varyant farklı bir perspektiften yaklaşmalı.
7 
8Soru: ${originalQuery}
9 
10JSON formatında 3 sorgu döndür: {"queries": ["...", "...", "..."]}`;
11 
12  const response = await llm.complete(prompt);
13  const parsed = JSON.parse(response) as { queries: string[] };
14  return parsed.queries;
15}

2. HyDE (Hypothetical Document Embedding): Sorgu için varsayımsal bir belge üretip onu da arama vektörü olarak kullan.

3. Reranker kullanımı: Cross-encoder modellerle retrieval sonuçlarını yeniden sırala. Cohere Rerank, bge-reranker-v2 bu alanda öne çıkıyor.

4. Hybrid Retrieval: Dense (embedding) + sparse (BM25/TF-IDF) aramaları birleştir. Özellikle teknik terimler, ürün adları gibi exact-match gerektiren durumlarda kritik.

Embedding Modelleri: Seçim Rehberi

Embedding kalitesi RAG performansının en kritik belirleyicisi. 2026'da öne çıkan modeller:

OpenAI text-embedding-3-large

• Boyut:: 3072 (truncatable)
• MTEB Skoru:: ~64.6
• Maliyet:: $0.13/1M token
• En iyi:: Genel amaçlı, çok dilli belgeler

Voyage AI voyage-3-large

• Boyut:: 1024
• MTEB Skoru:: ~68.2
• Maliyet:: $0.18/1M token
• En iyi:: Kod ve teknik dokümantasyon

Cohere embed-v4

• Boyut:: 1024
• MTEB Skoru:: ~67.1
• Özellik:: Compressed embeddings (int8), %4x daha az depolama
• En iyi:: Büyük ölçekli kurumsal uygulamalar

BGE-M3 (Açık Kaynak)

• Boyut:: 1024
• MTEB Skoru:: ~66.5
• Maliyet:: Kendi altyapında sıfır
• En iyi:: On-prem, veri gizliliği gereksinimleri

1# Embedding model karşılaştırma örneği
2from openai import OpenAI
3import voyageai
4 
5def compare_embeddings(texts: list[str], queries: list[str]) -> dict:
6    # OpenAI
7    openai_client = OpenAI()
8    openai_result = openai_client.embeddings.create(
9        model="text-embedding-3-large",
10        input=texts
11    )
12    openai_vectors = [item.embedding for item in openai_result.data]
13 
14    # Voyage AI
15    voyage_client = voyageai.Client()
16    voyage_result = voyage_client.embed(
17        texts,
18        model="voyage-3-large",
19        input_type="document"
20    )
21    voyage_vectors = voyage_result.embeddings
22 
23    return {
24        "openai_retrieval_score": score_retrieval(openai_vectors, queries),
25        "voyage_retrieval_score": score_retrieval(voyage_vectors, queries)
26    }

Vector Database Karşılaştırması

Pinecone

Fully-managed SaaS. Kurulum sıfır, ölçek otomatik. Aylık sabit maliyet + kullanım. Gerçek production'da Pinecone'u tercih eden ekiplerin en çok değer verdiği şey: operasyonel yük sıfır.

Maliyeti: Serverless tier ~$0.033/1M sorgu, dedicated pod'lar GB başına ücretli.

Weaviate

Açık kaynak + SaaS seçeneği. Multi-modal (metin + görsel). Built-in BM25 hybrid search. Kubernetes üzerinde kendi altyapına kurabilirsin.

pgvector (PostgreSQL Uzantısı)

Production'da en az değerlendirilen ama çoğu zaman en akıllı seçim. Halihazırda PostgreSQL kullanıyorsan pgvector ile aynı veritabanında vektör araması yapabilirsin.

1-- pgvector kurulum ve kullanım
2CREATE EXTENSION vector;
3 
4CREATE TABLE documents (
5  id bigserial PRIMARY KEY,
6  content text,
7  embedding vector(1536),
8  metadata jsonb,
9  created_at timestamptz DEFAULT now()
10);
11 
12-- IVFFlat index (yaklaşık, hızlı)
13CREATE INDEX ON documents
14USING ivfflat (embedding vector_cosine_ops)
15WITH (lists = 100);
16 
17-- HNSW index (daha doğru, daha fazla bellek)
18CREATE INDEX ON documents
19USING hnsw (embedding vector_cosine_ops)
20WITH (m = 16, ef_construction = 64);
21 
22-- Benzer belge arama
23SELECT content, metadata,
24       1 - (embedding <=> $1::vector) AS similarity
25FROM documents
26ORDER BY embedding <=> $1::vector
27LIMIT 5;

Qdrant

Rust ile yazılmış, yüksek performanslı açık kaynak. Payload filtering özelliği güçlü.

Fine-tuning Teknikleri: LoRA, QLoRA, DPO

Ne Zaman Fine-tuning Düşünmelisin?

Fine-tuning'i düşünmen gereken başlıca senaryolar:

1. Format/stil adaptasyonu: Model çıktılarının belirli bir formatta olması gerekiyor.
2. Domain terminolojisi: Tıp, hukuk, finans gibi alanlarda özel terim ve kavramlar.
3. Tool use fine-tuning: Fonksiyon çağırma formatını daha güvenilir hale getirme.
4. Maliyet optimizasyonu: Küçük bir fine-tuned model ile GPT-4 seviyesi görev çözme.

LoRA (Low-Rank Adaptation)

Full fine-tuning yerine modelin yalnızca küçük rank-decomposition matrislerini eğitir. Orijinal ağırlıklar donuk kalır.

1from peft import LoraConfig, get_peft_model, TaskType
2from transformers import AutoModelForCausalLM
3 
4# LoRA konfigürasyonu
5lora_config = LoraConfig(
6    task_type=TaskType.CAUSAL_LM,
7    r=16,               # rank — düşük = az parametre
8    lora_alpha=32,      # scaling faktörü
9    target_modules=[
10        "q_proj",
11        "v_proj",
12        "k_proj",
13        "o_proj"
14    ],
15    lora_dropout=0.05,
16    bias="none"
17)
18 
19# Modeli yükle ve LoRA uygula
20base_model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-4-Scout")
21peft_model = get_peft_model(base_model, lora_config)
22 
23# Trainable parametre yüzdesini kontrol et
24peft_model.print_trainable_parameters()
25# Örnek çıktı: trainable params: 4,194,304 || all params: 8,030,261,248 || trainable%: 0.05

QLoRA (Quantized LoRA)

LoRA'nın 4-bit quantization ile birleşimi. 70B model bile tek bir A100 GPU'ya sığıyor. Tim Dettmers ve ekibinin geliştirdiği bu teknik, fine-tuning maliyetini dramatik ölçüde düşürdü.

DPO (Direct Preference Optimization)

RLHF'in daha kararlı ve basit alternatifi. Tercih çiftleri (tercih edilen / tercih edilmeyen yanıt) ile modeli doğrudan eğitir. Özellikle instruction following ve güvenlik fine-tuning'inde kullanılıyor.

Maliyet ve Performans Analizi

Gerçek Maliyet Karşılaştırması (Orta Ölçek: 10K Sorgu/Gün, 10K Doküman)

RAG Maliyeti:

• Embedding indexleme (tek seferlik): 10K doküman × 1000 token = 10M token → ~$1.30
• Günlük query embedding: 10K sorgu × 100 token = 1M token → ~$0.13/gün
• Vector DB (pgvector + PostgreSQL): Zaten kullanıyorsan ~$0
• LLM inference (RAG context ~2K token): 10K × 2K = 20M token → ~$30-60/gün
• Toplam (ilk ay):: ~$1000-1800

Fine-tuning Maliyeti:

• Veri hazırlama: 1000-5000 örnek, insan emek maliyeti $2000-8000
• Training (LoRA, Llama 4 Scout): ~$50-200 (A100 saatlik kira)
• Inference (fine-tuned, küçük model): 10K × 500 token = 5M token → ~$5/gün
• Toplam (ilk ay):: $2500-9000 + $150/ay

Uzun vadede: Fine-tuned küçük model inference'ta çok daha ucuz olabilir ama güncelleme maliyeti ekstra.

Karar Matrisi: Ne Zaman Hangisi?

1Karar Ağacı:
2 
3Bilgi sık sık güncelleniyor mu?
4├── EVET → RAG
5└── HAYIR → Devam
6 
7Format/stil tutarlılığı kritik mi?
8├── EVET → Fine-tuning(veya hibrit)
9└── HAYIR → Devam
10 
11Gizli/hassas veriler var mı?
12├── EVET → RAG(on-prem vector DB) veya Fine-tuning(private)
13└── HAYIR → Devam
14 
15Inference maliyeti çok yüksek mi?
16├── EVET → Fine-tuned küçük model
17└── HAYIR → Devam
18 
19Temel domain bilgisi gerekiyor mu?
20├── EVET → Fine-tuning + RAG
21└── HAYIR → RAG

Spesifik Senaryolar

Hibrit Yaklaşım: RAG + Fine-tuning

En güçlü production sistemleri her ikisini birleştiriyor:

1. Fine-tuning ile: Domain adaptasyonu, format tutarlılığı, tool use güvenilirliği
2. RAG ile: Güncel bilgi, gerçek dokümanlar, kaynaklandırma

1class HybridRAGSystem:
2    """Fine-tuned model + RAG pipeline"""
3 
4    def __init__(self):
5        # Fine-tuned model — domain adaptasyonu sağlandı
6        self.llm = load_fine_tuned_model("our-domain-llama-4")
7 
8        # RAG pipeline — güncel bilgi için
9        self.retriever = VectorDBRetriever(
10            db_url="http://localhost:6333",
11            model="voyage-3-large"
12        )
13 
14    async def answer(self, query: str) -> dict:
15        # 1. Güncel bilgi al
16        chunks = await self.retriever.retrieve(query, top_k=5)
17 
18        # 2. Fine-tuned modele gönder
19        context = "
20".join(c.text for c in chunks)
21        prompt = f"BAĞLAM:
22{context}
23 
24SORU: {query}
25YANIT:"
26        response = await self.llm.generate(prompt)
27 
28        # 3. Kaynakları döndür (hallucination azaltma)
29        return {
30            "answer": response,
31            "sources": [c.source for c in chunks]
32        }

Production'da Yaygın Hatalar

1. Chunk boyutunu optimize etmemek: 512 token her zaman doğru değil. Teknik dokümantasyon için 256, narratif içerik için 1024 daha iyi olabilir. A/B testi yap.

2. Embedding modelini görev tipine göre seçmemek: "text-embedding-3-small ile başla" güzel bir default ama kod araması için özel modeller çok daha iyi.

3. Fine-tuning için yetersiz veri: LoRA için minimum 500-1000 yüksek kaliteli örnek gerekiyor. 100 örnekle başlamak overfitting'e yol açar.

4. RAG'da retrieval kalitesini ölçmemek: Retrieval precision ve recall'u ayrıca izle. LLM çıktısı iyi görünse bile yanlış chunk'lar çekiliyor olabilir.

5. Latency bütçesini görmezden gelmek: RAG pipeline 200-500ms ekliyor. Bu bazı real-time uygulamalar için kabul edilemez.

Sonuç

RAG mı fine-tuning mi sorusunun tek bir cevabı yok — ama çoğu production sistemi için başlangıç noktası RAG olmalı çünkü daha hızlı prototipleme, daha kolay güncelleme ve daha iyi kaynaklandırma sunuyor. Fine-tuning'i ekle: format tutarlılığı, domain adaptasyonu veya inference maliyet optimizasyonu gerektiğinde.

Eğer şu anda bir sistem kuruyorsan, bu sırayla git:

1. Temel RAG kur ve baseline metriklerini ölç
2. Embedding ve chunk stratejisini optimize et
3. Reranker ekle
4. Gerekiyorsa fine-tuning ile tamamla

Daha fazla AI production mimarisi için MCP Protocol ve Firebase AI Logic yazılarına da göz atabilirsin.