Fine-tuning vs RAG vs prompting: when each is the right tool

[Aior]

En çok para harcatan karar​

"Fine-tune etmeli miyiz?" LLM işinde en çok sorulan, en çok overdone kararlardan biridir. Fine-tuning pahalıdır, sizi bir modelin snapshot'ına kilitler ve sıkça prompting + RAG'ın daha ucuza çözebileceği bir probleme yanlış cevaptır.

Hiyerarşi: ucuzdan pahalıya​

1. Daha iyi prompting — neredeyse her zaman önce denenir. Ucuz, geri alınabilir, hızlı.
2. Few-shot örnekler — bağlam aracılığıyla yetenek ekler. Bağlam pencere maliyetiyle sınırlı.
3. RAG — retrieval aracılığıyla bilgi ekler. Bilgiyi modelden ayırır.
4. Tool use — dış fonksiyonlar aracılığıyla yetenek ekler.
5. Fine-tuning — modeli uyarlar. Pahalı, iterasyon daha yavaş, snapshot'ı kilitler.
6. Pretraining — bir ürün ekibi için neredeyse hiçbir zaman doğru çağrı değil.

Önceki adım problemi gösterilebilir şekilde çözemiyorsa listede aşağı inin.

Fine-tuning gerçekten ne zaman yardım eder​

• Stil / format tutarlılığı — model milyonlarca çağrıda spesifik çıktı stili üretmeli.
• Daha küçük modelde gecikme / maliyet — fine-tune edilmiş daha küçük model dar görevde daha büyük modeli daha düşük maliyetle eşleyebilir.
• Domain-spesifik davranış — model prompting'in güvenilir üretmediği nadir terminoloji/desenleri ele almalı.
• Kapalı-domain sınıflandırma / extraction — bol etiketli veri olan dar görevler için.

Fine-tuning ne zaman yanlış cevap​

• "Bilgi eklemek" — fine-tuning olguları enjekte etmede zayıftır. RAG daha iyi araç.
• "Modelin akıl yürütmesini iyileştirmek" — pretrained modellerin akıl yürütme yeteneği çoğunlukla foundation düzeyinde sabittir.
• "Kişiliği özelleştirmek" — sistem prompt + few-shot bunu daha az maliyetle %95'ine kadar yapar.
• "Halüsinasyonları düzeltmek" — fine-tuning halüsinasyonu güvenilir şekilde azaltmaz.

İşleyen fine-tuning pipeline'ı​

• Üretim sisteminin kullanacağı formatta giriş-çıkış çiftlerinden temiz veri seti inşa edin.
• Test setini ayrıştırın — asla onun üzerinde eğitim yapmayın.
• Yenmeye çalıştığınızı bilmek için test setinde baseline (prompted) eval çalıştırın.
• Fine-tune edin (maliyet-etkili parameter-efficient tuning için LoRA / QLoRA).
• Fine-tune edilmiş modeli test setinde değerlendirin; baseline'a karşılaştırın.
• Sadece curated test setinde değil, üretim-dağılım verisinde çalıştırın.
• Base model yükseltildiğinde yeniden tuning için planlayın.

LoRA / QLoRA 2026'da parameter-efficient fine-tuning'e hakim. Tam fine-tune'lar ürün kullanım durumları için nadir.

Open-weight vs closed​

• Closed (Anthropic, OpenAI, Google) — bazı modellerde fine-tuning mümkün, daha az kontrol, offline deploy yok, daha basit ops.
• Open weights (Llama, Qwen, Mistral vb.) — tam kontrol, herhangi bir yerde çalışabilir, daha fazla mühendislik yatırımı.

Veri kalitesi her şeye hakim​

Fine-tuning sonucu veri seti tarafından sınırlandırılır. 1.000-örneklik temiz veri seti tipik olarak 10.000-örneklik gürültülü olanı yener.

Uyaracağımız bir desen​

Eval'lar var olmadan önce projede erken fine-tuning. Eval'lar olmadan fine-tune'un yardım edip etmediğini söyleyemezsiniz.

Her zaman karşılığını veren bir desen​

Test setinde küçük-modelin-fine-tune'unu vs prompted-büyük-modeli maliyet/gecikme/kalite için karşılaştırmak.

Fine-tune etmek için karar süreciniz nedir?

The decision that wastes the most money​

"Should we fine-tune?" is one of the most-asked, most-overdone decisions in LLM work. Fine-tuning is expensive, locks you into a snapshot of a model, and is often the wrong answer to a problem that prompting + RAG could have solved cheaper.

The hierarchy: cheaper to more expensive​

1. Better prompting — almost always tried first.
2. Few-shot examples — adds capability via context.
3. RAG — adds knowledge via retrieval.
4. Tool use — adds capability via external functions.
5. Fine-tuning — adapts the model.
6. Pretraining — almost never the right call for a product team.

When fine-tuning actually helps​

• Style / format consistency.
• Latency / cost on a smaller model.
• Domain-specific behaviour.
• Closed-domain classification / extraction.

When fine-tuning is the wrong answer​

• "Adding knowledge" — RAG is the better tool.
• "Making the model better at reasoning" — pretrained models' reasoning capability is mostly fixed.
• "Customising the personality" — system prompt + few-shot does this for less cost.
• "Fixing hallucinations" — fine-tuning doesn't reliably reduce hallucination.

The fine-tuning pipeline that works​

• Build a clean dataset of input-output pairs.
• Hold out a test set — never train on it.
• Run a baseline (prompted) eval on the test set.
• Fine-tune (LoRA / QLoRA for parameter-efficient tuning).
• Evaluate the fine-tuned model on the test set.
• Run on production-distribution data.
• Plan for re-tuning when the base model upgrades.

Open-weight vs closed​

• Closed (Anthropic, OpenAI, Google) — fine-tuning available on some models, less control, simpler ops.
• Open weights (Llama, Qwen, Mistral) — full control, can run anywhere, more engineering investment.

Data quality dominates everything​

The fine-tuning result is bounded by the dataset.

One pattern we'd warn about​

Fine-tuning early in a project before evals exist.

One pattern that always pays off​

Comparing fine-tune-of-small-model against prompted-larger-model.

What's your decision process for when to fine-tune?